Advertisement for multi-source endpoint multiplexing multiple media type in the same RTP session
draft-wu-avtcore-multisrc-endpoint-adver-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Qin Wu | ||
| Last updated | 2012-10-12 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wu-avtcore-multisrc-endpoint-adver-00
Audio/Video Transport Working Group Q. Wu
Internet-Draft Huawei
Intended status: Standards Track October 12, 2012
Expires: April 15, 2013
Advertisement for multi-source endpoint multiplexing multiple media type
in the same RTP session
draft-wu-avtcore-multisrc-endpoint-adver-00.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 15, 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 15, 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. Consideration for Session member numbers updating . . . . . . 7
5. Protocol formats . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. SDES item for Reception Report Sending . . . . . . . . . . 8
5.1.1. RRS: Reception Report Sending SDES Item . . . . . . . 8
5.2. SDES item for Reception Report Monitoring . . . . . . . . 8
5.2.1. RRM: Reception Report Monitoring SDES Item . . . . . . 9
5.3. SDES item for Invalid Report Source list . . . . . . . . . 9
5.3.1. IRSL: Invalid Report Source List SDES Item . . . . . . 9
5.4. RTP header extension for Invalid Report Source list . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. New RTCP SDES Type values . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Wu Expires April 15, 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 15, 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 15, 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.
One way is to define three new SDES items to advertise the reporting
sources from endpoint with multiple sources that are used for
Wu Expires April 15, 2013 [Page 5]
Internet-Draft Multiple Source Advertisement October 2012
reception report sending, receiving and monitoring respectively (See
section 5.1 and section 5.2 for protocol format details).
Wu Expires April 15, 2013 [Page 6]
Internet-Draft Multiple Source Advertisement October 2012
4. Consideration for Session member numbers updating
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.
Wu Expires April 15, 2013 [Page 7]
Internet-Draft Multiple Source Advertisement October 2012
5. Protocol formats
5.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).
5.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.
5.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 15, 2013 [Page 8]
Internet-Draft Multiple Source Advertisement October 2012
5.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.
5.3. SDES item for Invalid Report Source list
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).
5.3.1. IRSL: Invalid Report Source List 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Wu Expires April 15, 2013 [Page 9]
Internet-Draft Multiple Source Advertisement October 2012
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.
5.4. RTP header extension for Invalid Report Source list
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... ... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RTP Header Extension Block
Wu Expires April 15, 2013 [Page 10]
Internet-Draft Multiple Source Advertisement October 2012
6. Security Considerations
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].
Wu Expires April 15, 2013 [Page 11]
Internet-Draft Multiple Source Advertisement October 2012
7. 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].
7.1. New RTCP SDES Type values
This document assigns four 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
RRMS: Reception Report Monitoring Source TBD
IRSL: Invalid Report Source List TBD
[Note to RFC Editor: please replace NDEL with the IANA provided RTCP
XR block type for this block.]
Wu Expires April 15, 2013 [Page 12]
Internet-Draft Multiple Source Advertisement October 2012
8. References
8.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.
8.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 15, 2013 [Page 13]
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 15, 2013 [Page 14]