| Audio/Video Transport Working Group | Q. Wu |
| Internet-Draft | Huawei |
| Intended status: Standards Track | October 12, 2012 |
| Expires: April 13, 2013 |
Advertisement for multi-source endpoint multiplexing multiple media type in the same RTP session
draft-wu-avtcore-multisrc-endpoint-adver-00.txt
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.
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 13, 2013.
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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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:
This document discusses how to tackle these problems. Three phases for suppressing reception reports are proposed.
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].
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).
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.
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.
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.
One way is to define three new SDES items to advertise the reporting sources from endpoint with multiple sources that are used for reception report sending, receiving and monitoring respectively (See section 5.1 and section 5.2 for protocol format details).
As described in section 6.2.1 of RFC3550, Calculation of the RTCP packet interval mainly depends upon the number of members. For an endpoint with multiple sources in communication with another endpoint with multiple sources, it is more desirable to set the number of sender for such endpoint as one and the number of receiver as one. However according to RFC3550, each source within such endpoint is considered valid until multiple packets carrying the new SSRC have been received, or until an SDES RTCP packet containing a CNAME for that SSRC has been received. In order to invalid the source that are not elected as report source, it is necessary to define new SDES item to indicate other sources that are not chosen as report sources(See section 5.4 for more details). Also we can define an RTP header extension [RFC5285] to indicate the other sources that are not chosen as report sources(See section 5.4 for more details).This extension can be sent by the endpoint with multiple sources either at the beginning of the RTP session or in the middle of the RTP session. Another way is to use RTCP NACK packet [RFC4585] to suppress the unnecessary reception report from an endpoint with multiple sources. The NACK can be sent by the endpoint with multiple source when the endpoint with multiple sources is aware of reception report duplication.
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).
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.
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).
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.
This sub-section defines the format of the Invalid Report Source list 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).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IRSL=TBD | length | Invalid Report Source SSRC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ....
+-+-+-+-+-+-+-+-+
The Invalid Report Source list Item is not mandatory item and intended for indicating the invalid report source(s) for an endpoint with multiple sources. The invalid Report Source is one that is not elected as report source for an endpoint with multiple sources and SHOULD not be counted as session member or RTP packet sender if multiplexing multiple media type in the same RTP session is used. This item may carry one or more than one invalid Report Source SSRCs. The invalid 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. The SSRC/CSRC identifier field at the beginning of the chunk is the SSRC of one elected report source from multiple source for the same endpoint. This item MUST be ignored by applications that are not configured to make use of it.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x10 | 0x00 | length=TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | length | Invalid Report Source SSRC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... ... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-section defines the format of RTP header extension [RFC5285]for carrying a list of Invalid Report Sources. The RTP header extension is composed of a header with fixed-length fields for the fixed bit pattern “0x1000”, and length, followed by zero or more extension elements. Each extension element is followed by one two type header and one Invalid Report Source for an endpoint with multiple sources. The invalid report source is carried in 32 bit field and identified using SSRC.
RTCP reports or RTP header extension elements 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. In addition, the RTP header extension elements can be protected using mechanisms defined in [I-D.ietf-avtcore-srtp-encrypted-header-ext].
New SDES types for RTCP SDES are subject to IANA registration. For general guidelines on IANA considerations for RTCP SDES, refer to[RFC3550].
abbrev. name value RRSS: Reception Report Sending Source TBD RRRS: Reception Report Receiving Source TBD RRMS: Reception Report Monitoring Source TBD IRSL: Invalid Report Source List TBD
This document assigns four additional SDES type in the IANA "RTCP SDES Item Types Registry" to the new SDES items as follow:
[Note to RFC Editor: please replace NDEL with the IANA provided RTCP XR block type for this block.]
| [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. |
| [RFC5285] | Singer, D. and H. Desineni, "A General Mechanism for RTP Header Extensions", RFC 5285, July 2008. |
| [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. |
| [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.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.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. |