Advertisement for multi-source endpoint multiplexing multiple media type in the same RTP session
draft-wu-avtcore-multisrc-endpoint-adver-01

Audio/Video Transport Working Group                                Q. Wu
Internet-Draft                                                    Huawei
Intended status: Standards Track                        October 19, 2012
Expires: April 22, 2013

Advertisement for multi-source endpoint multiplexing multiple media type
                        in the same RTP session
            draft-wu-avtcore-multisrc-endpoint-adver-01.txt

Abstract

   When two endpoints with multiple media sources are in communication,
   each media source or each receiver within either endpoint may send or
   receive reception report independently.  This may incur a lot of
   duplicated reception report to and from the endpoint with multiple
   sources.  This document discusses how to tackle these problems and
   propose three phases for suppressing reception reports.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 22, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Wu                       Expires April 22, 2013                 [Page 1]
Internet-Draft        Multiple Source Advertisement         October 2012

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Standards Language . . . . . . . . . . . . . . . . . . . .  4
   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Report Source Grouping . . . . . . . . . . . . . . . . . .  5
     3.2.  Report Source Election . . . . . . . . . . . . . . . . . .  5
     3.3.  Report Source Advertisement  . . . . . . . . . . . . . . .  5
   4.  Protocol formats . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  SDES item for Reception Report Sending . . . . . . . . . .  7
       4.1.1.  RRS: Reception Report Sending SDES Item  . . . . . . .  7
     4.2.  SDES item for Reception Report Monitoring  . . . . . . . .  7
       4.2.1.  RRM: Reception Report Monitoring SDES Item . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  New RTCP SDES Type values  . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12

Wu                       Expires April 22, 2013                 [Page 2]
Internet-Draft        Multiple Source Advertisement         October 2012

1.  Introduction

   For some applications that use unicast transport, e.g., in RTCWeb
   application, an endpoint with multiple media sources (i.e.,multiple-
   source hosts, e.g., a client with several cameras) may use a
   different SSRC for each medium but sending them in the same RTP
   session, which reduces communication failure due to NAT and firewall
   when using multiple RTP sessions or transport flows.

   However when two endpoints with multiple media sources are in
   communication, each media source within either endpoint may send
   reception report independently and the receiving endpoint may not
   know the reception reports received from different media source are
   from the same sending endpoint.  This creates the following three
   problems:

   o  An endpoint with multiple media sources involved in one RTP
      session may send the reception report with duplicated information
      about the same remote media source from each of local media
      sources.

   o  An endpoint with multiple media sources involved in one RTP
      session may receive the reception report with duplicated
      information about the same local media source from each of remote
      media sources.

   o  An endpoint with multiple media sources involved in one RTP
      session also may send reception reports about one of its own media
      sources from another of its own (This is also referred to as RTCP
      self-reporting).  Such reception reports cause additional traffic
      travelling over the link between sending endpoints and receiving
      endpoint, which may cause network congestion issue and affect the
      media qualities.

   This document discusses how to tackle these problems.  Three phases
   for suppressing reception reports are proposed.

   o  Grouping of media sources originate from a single endpoint and
      classifying these media sources into multiple groups.

   o  Electing one single SSRC for reception report sending and one
      single SSRC for reception report monitoring based on local policy.

   o  Advertising the SSRC that is used either for reception report
      sending or reception report monitoring.

Wu                       Expires April 22, 2013                 [Page 3]
Internet-Draft        Multiple Source Advertisement         October 2012

2.  Terminology

2.1.  Standards Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Wu                       Expires April 22, 2013                 [Page 4]
Internet-Draft        Multiple Source Advertisement         October 2012

3.  Protocol Overview

   In order to suppress unnecessary reception reports to and from multi-
   source endpoint, multi-source endpoint should group media sources
   originating from a single endpoint and elect one or a set of
   specified SSRCs for reception report processing (e.g., reception
   report sending, reception report receiving and reception report
   monitoring).

3.1.  Report Source Grouping

   When an endpoint with multiple sources multiplexes multiple media
   types in the same RTP session, the media source originating from the
   same endpoint should be grouped together.  Similarly the endpoint
   with multiple sources may have multiple one or more than one report
   source for monitoring.  These report sources for monitoring should
   also be grouped together.  Therefore an endpoint with multiple
   sources should at least split all its own media sources or receivers
   into two groups(i.e., split SSRCs into two groups): One is sending
   group, the other is monitoring group.  Each group may have one or
   several group members.  Each group member is identified by a
   different SSRC.

3.2.  Report Source Election

   When grouping for each endpoint with multiple sources is available,
   in order to prevent group members receiving duplicated data, one or
   more than one group member MUST be elected from sending group as
   report source for reception report sending.  When one report source
   leaves the session or is down, another candidate report source can
   replace instead.  If the monitoring is used, each endpoint with
   multiple sources MUST have at least one report source for monitoring
   purpose.  One or more than one reporting sources MUST be selected
   from monitoring group for monitoring use.

   Each endpoint with multiple sources at least has one SSRC for
   reception report sending.  If the monitoring is used, the endpoint
   with multiple sources should choose another SSRC from monitoring
   group as monitoring report source.

3.3.  Report Source Advertisement

   When report sources are elected for reception report sending, and
   monitoring purpose respectively, it is necessary to signal which
   report source is used for which purpose.

   In this document we define two new SDES items to advertise the
   reporting sources from endpoint with multiple sources that are used

Wu                       Expires April 22, 2013                 [Page 5]
Internet-Draft        Multiple Source Advertisement         October 2012

   for reception report sending and monitoring respectively (See section
   5.1 and section 5.2 for protocol format details).

   When report source is advertised, the selected report source can send
   reception report about the same remote media source on behalf of the
   media sources of its own.

   In order to prevent duplicated reception report sent from one of its
   own media sources to another of its own within the same endpoint with
   multiple sources(i.e., self-reporting), the report source should know
   the other media sources of its own and suppress sending the reception
   report on remote source to its own media sources.

Wu                       Expires April 22, 2013                 [Page 6]
Internet-Draft        Multiple Source Advertisement         October 2012

4.  Protocol formats

4.1.  SDES item for Reception Report Sending

   This sub-section defines the format of the Reception Report Sending
   SDES item.  The SDES item is carried in the RTCP SDES packet.  The
   packet format for the RTCP SDES is defined in Section 6.5 of
   [RFC3550].  Each SDES packet is composed of a header with fixed-
   length fields for version, source count, packet type (PT), and
   length, followed by zero or more chunks.  Each chunk consists of an
   SSRC/CSRC identifier followed by zero or more SDES items.  In the
   SDES packet, the PT field is set to SDES(202).

4.1.1.  RRS: Reception Report Sending SDES Item

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    RRS=TBD    |     length    | Candidate Report Source SSRC
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   ....
       +-+-+-+-+-+-+-+-+

   The Reception Report Sending Item is not mandatory item and intended
   for indicating the elected report source for an endpoint with
   multiple sources, which is responsible for reception report sending.
   The SSRC/CSRC identifier included in the same chunk (at the beginning
   of this chunk) as the item is the SSRC of elected sending report
   source.  Additionally, this item may carry one or more than one
   Candidate Report Source SSRCs.  The candidate Report Source SSRC
   follows the same format as SSRC/CSRC identifier defined in RFC3550.
   Its length is described by the length field.  The value of the length
   field does not include the two octet SDES item header.  This item
   MUST be ignored by applications that are not configured to make use
   of it.

4.2.  SDES item for Reception Report Monitoring

   This sub-section defines the format of the Reception Report
   Monitoring SDES item.  The SDES item is carried in the RTCP SDES
   packet.  The packet format for the RTCP SDES is defined in Section
   6.5 of [RFC3550].Each SDES packet is composed of a header with fixed-
   length fields for version, source count, packet type (PT), and
   length, followed by zero or more chunks.  Each chunk consists of an
   SSRC/CSRC identifier followed by zero or more SDES items.  In the
   SDES packet, the PT field is set to SDES(202).

Wu                       Expires April 22, 2013                 [Page 7]
Internet-Draft        Multiple Source Advertisement         October 2012

4.2.1.  RRM: Reception Report Monitoring SDES Item

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    RRM=TBD    |     length    | Candidate Report Source SSRC
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   ....
       +-+-+-+-+-+-+-+-+

   The Reception Report Sending Item is not mandatory item and intended
   for indicating the report source for an endpoint, which is
   responsible for reception report monitoring.  The SSRC/CSRC
   identifier included in the same chunk as the item (at the beginning
   of this chunk) is the SSRC of elected sending report source.
   Additionally, this item may carry one or more than one Candidate
   Report Source SSRCs.  The candidate Report Source SSRC follows the
   same format as SSRC/CSRC identifier defined in RFC3550.  Its length
   is described by the length field.  The value of the length field does
   not include the two octet SDES item header.  This item MUST be
   ignored by applications that are not configured to make use of it.

Wu                       Expires April 22, 2013                 [Page 8]
Internet-Draft        Multiple Source Advertisement         October 2012

5.  Security Considerations

   RTCP reports can contain sensitive information, including information
   about report source grouping for endpoint with multiple source and
   member of a session established between two or more endpoints.
   Therefore, the use of security mechanisms with RTP, as documented in
   Section 9 of [RFC3550] applies.

Wu                       Expires April 22, 2013                 [Page 9]
Internet-Draft        Multiple Source Advertisement         October 2012

6.  IANA Considerations

   New SDES types for RTCP SDES are subject to IANA registration.  For
   general guidelines on IANA considerations for RTCP SDES, refer
   to[RFC3550].

6.1.  New RTCP SDES Type values

   This document assigns two additional SDES type in the IANA "RTCP SDES
   Item Types Registry" to the new SDES items as follow:

   abbrev.      name                          value
   RRSS: Reception Report Sending Source       TBD
   RRRS: Reception Report Receiving Source     TBD

   [Note to RFC Editor: please replace RRSS and RRMS with the IANA
   provided RTCP SDES Item Types.]

Wu                       Expires April 22, 2013                [Page 10]
Internet-Draft        Multiple Source Advertisement         October 2012

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

   [RFC3550]  Schulzrinne, H., "RTP: A Transport Protocol for Real-Time
              Applications", RFC 3550, July 2003.

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4595,
              July 2006.

   [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
              Header Extensions", RFC 5285, July 2008.

7.2.  Informative References

   [I-D.lennox-avtcore-rtp-multi-stream]
              Lennox, J. and M. Westerlund, "Real-Time Transport
              Protocol (RTP) Considerations for Endpoints Sending
              Multiple Media Streams",
              ID draft-lennox-avtcore-rtp-multi-stream-00, July 2012.

   [I-D.westerlund-avtcore-multiplex-architecture]
              Westerlund, M., "Guidelines for using the Multiplexing
              Features of RTP",
              ID draft-westerlund-avtcore-multiplex-architecture-02,
              July 2012.

   [I-D.wu-avtcore-multiplex-multisource-endpoint]
              Wu, Q., "Bandwidth and RTCP timing issues for multi-source
              endpoint",
              ID draft-wu-avtcore-multiplex-multisource-endpoint-00,
              October 2012.

Wu                       Expires April 22, 2013                [Page 11]
Internet-Draft        Multiple Source Advertisement         October 2012

Author's Address

   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: sunseawq@huawei.com

Wu                       Expires April 22, 2013                [Page 12]