| AVTCORE | R.P. Ejzak |
| Internet-Draft | Alcatel-Lucent |
| Intended status: Informational | June 04, 2012 |
| Expires: December 04, 2012 |
Media multiplexing with Real-time Transport Protocol (RTP) subsessions
draft-ejzak-avtcore-rtp-subsessions-00
This document describes a means of multiplexing RTP streams having different media types within a single transport connection and how to represent this multiplexing option in SDP. This mechanism is an alternative to the BUNDLE and SHIM proposals currently under active consideration in AVTCORE. Instead of adding an extra multiplexing header as in SHIM to allow multiple RTP sessions within a single transport connection, or using the payload type field to separate different media streams within a single RTP session, this document describes how to partition the existing SSRC space to create RTP subsessions from a single RTP session. A filter can be used to identify each RTP subsession for different QoS handling as necessary. RTP subsessions can be treated like RTP sessions with a few restrictions. In particular, SSRC mapping may be needed when forwarding RTP streams into an RTP subsession to avoid SSRC conflicts, but there are few use cases in which this limitation is a concern and RTP subsessions can be disabled if necessary.
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 December 04, 2012.
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.
The subject of RPT multiplexing has received significant attention within RTCWEB and AVTCORE in the last year. It would be highly desirable to multiplex RTP streams associated with a communications session onto as few transport connections as possible to reduce the messaging required to complete ICE connectivity checks [RFC5245] and DTLS key exchange [RFC6347] prior to being able to send media. RTP is specified in [RFC3550]. This document focuses specifically on how to multiplex multiple media types on the same transport connection since RTP is already capable of multiplexing RTP streams of the same media type using the SSRC field. The following drafts provide key background and context, which will not be duplicated here: [I-D.ietf-rtcweb-rtp-usage], [I-D.westerlund-avtcore-multiplex-architecture] and [I-D.westerlund-avtcore-max-ssrc]. The BUNDLE solution [I-D.ietf-mmusic-sdp-bundle-negotiation] uses SDP [RFC4566] to assign different sets of payload type values for each media line sharing an RTP session. The SHIM solution [I-D.westerlund-avtcore-transport-multiplexing] extends the RTP frame with an RTP session identifier to allow multiple RTP sessions to share a single transport connection. Schemes no longer under consideration based on SSRC are described in [I-D.rosenberg-rtcweb-rtpmux] and [I-D.peterson-rosenberg-avt-rtp-ssrc-demux]. This document describes an alternative approach with advantages compared to the current preferred BUNDLE and SHIM approaches.
An RTP subsession is a set of RTP streams and corresponding RTCP packets that use a subset of the entire range of SSRC values. Each RTP subsession has most of the characteristics of a complete RTP session with some exceptions described below. RTP subsessions that are assigned non-overlapping SSRC value ranges can share a single transport connection.
Each RTP subsession sharing a single transport connection is assigned a unique 16 bit SSRC prefix for each direction of transmission, i.e., the first 15 (highest order) bits of the 32 bit SSRC field have a fixed value for all RTP streams associated with the RTP subsession and the 16th bit is reserved to indicate each direction of transmission. The SDP offerer selects one value of the 16th bit and the SDP answerer selects the other. The final 16 bits of the SSRC are available to specify separate RTP streams within the RTP subsession. The first 15 bits of the SSRC prefix are assigned randomly for each RTP subsession. The SDP offerer is allowed to specify either value for the 16th bit of the SSRC to allow the offerer and answerer to change roles during subsequent session modifications while allowing continued use of already assigned SSRC values.
When concatenating multiple RTP or RTCP packets within a single IP packet, as allowed by existing specifications, RTP systems will only combine packets from the same RTP subsession. RTP subsessions are thus segregated into separate IP packets to allow differential treatment in the network.
The use of RTP subsessions is negotiated during the SDP offer/answer exchange as follows. All media lines in an SDP offer that are to share a transport connection will include identical connection and port information. If more than one port is specified for any media line then the first ports specified for the media lines are identical. Endpoints supporting RTP subsessions will include the rtcp-mux attribute [RFC5761] for each media line sharing the same transport connection. Each media line in a sharing group will include an "ssrc-prefix" attribute with a number of parameters corresponding to the number of ports assigned to the media line (usually one). If use of RTP subsessions is agreed during the SDP offer/answer negotiation and more than one port is specified for the media line, then a separate RTP subsession (and ssrc-prefix) will be assigned to each specified port but all RTP subsessions will be multiplexed onto the first port and the other specified ports will remain unused. Each parameter of the ssrc-prefix attribute is a hex representation of the 16 bit SSRC prefix to be used by the RTP subsession associated with each port for the m line. When there is only one port specified for a media line, then the ssrc-prefix attribute has only one parameter and there is only one RTP subsession for the media line.
The SDP offer includes the ssrc-prefix attribute for each media line in the sharing group. The use of a grouping construct to explicitly define the sharing group (as in [I-D.ietf-mmusic-sdp-bundle-negotiation]) is not strictly necessary and its potential use is for further study. If the SDP answerer agrees to use RTP subsessions, then it also includes in the SDP answer the ssrc-prefix attribute for each media line in the sharing group, with the same parameter values as the corresponding ones from the SDP offer, but with the 16th bit changed, i.e., '0' becomes '1' or '1' becomes '0'. The SDP answerer can disable the use of RTP subsessions by ignoring the ssrc-prefix attributes and including a different port for each m line in the SDP answer. If the SDP answerer includes matching ssrc-prefix attributes for the media lines in a sharing group but not all port values are identical, then the systems will limit the allocation of SSRC values to RTP streams as indicated by the ssrc-prefix attribute but the RTP subsessions will only be multiplexed for subsets of matching port values, if any.
Each RTP subsession is able to provide most of the capabilities of a full RTP session with some limitations described below associated with constraints on SSRC assignment. No changes are required to RTP or SRTP to realize RTP subsessions. The RTP streams associated with an individual media line can be easily identified for separate handling (e.g., to provide separate QoS treatment) by filtering on the first 16 bits of the SSRC field in addition to the five-tuple. RTP systems can enable successful filtering on the port and SSRC fields, which are above the IP layer, by adhering to MTU limits to avoid IP fragmentation.
[RFC3550] describes three kinds of systems that can use RTP: end systems, translators and mixers. RTP subsessions can be freely used by end systems and mixers since these systems can freely assign any SSRC value to each RTP stream. In particular, a mixer can reassign the SSRC value associated with an RTP stream before forwarding. A translator can be realized as a mixer with two differences. RTCP is handled differently, as discussed in [I-D.westerlund-avtcore-multiplex-architecture], but these differences are well understood and manageable. In addition, SRTP forwarding is more complex when SSRC is changed, as discussed in [I-D.westerlund-avtcore-multiplex-architecture]. While there is some additional processing needed to change SSRC when forwarding SRTP, there seems to be no consensus to require forwarding with SSRC preservation. Systems forwarding RTP streams frequently need to provide additional media processing functions, which require the decrypting of SRTP packets anyway.
Some applications require the ability to allocate the same SSRC value across multiple ports or media lines. RTP streams in different RTP subsessions are considered to use identical SSRC values if they match on the last 16 bits of the SSRC, so RTP subsessions can also be used for these applications.
Most RTP capabilities and extensions depend primarily on the use of a different SSRC for each RTP stream. Since RTP subsessions retain this characteristic, they introduce no new compatibility issues. Examples of such extensions include FEC, interleaving and RTP retransmissions.
An SDP offerer desiring to use a single transport connection for a one port audio m line and a two port video m line might construct the following SDP offer.
c=...
m=audio 49170 RTP/AVP 96 97
a=rtcp-mux
a=ssrc-prefix: 0xffc0
...
m=video 49170/2 RTP/AVP 98 99
a=rtcp-mux
a=ssrc-prefix: 0xd378 0x2fac
...
The SDP answerer that agrees to use SDP subsessions as described in the SDP offer might respond with the following SDP answer.
c=...
m=audio 36008 RTP/AVP 96 97
a=rtcp-mux
a=ssrc-prefix: 0xffc1
...
m=video 36008/2 RTP/AVP 98 99
a=rtcp-mux
a=ssrc-prefix: 0xd379 0x2fad
...
The endpoints will establish one audio and two video SDP subsessions associated with the SDP offer/answer exchange. These SDP subsessions and their corresponding RTCP will each share a single transport connection using ports 49170 and 36008, respectively. Media flows associated with each SDP subsession can be identified by filtering on the first 16 bits of the SSRC field as necessary for differential handling, e.g., to assign separate QoS treatment. Each RTP stream sharing the transport connection uses a unique SSRC field so there is no ambiguity in associating RTCP messages with their RTP streams.
BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] constrains the assignment of SSRC values, so it has similar limitations for use with translators. It must be assured that different RTP streams do not share the same SSRC even though they use non-overlapping payload type values so that each RTCP packet can be uniquely associated with a particular RTP stream. The biggest problem with BUNDLE is that it is difficult to partition the RTP streams associated with different media lines since this requires filtering on sets of payload type values. RTP subsessions is superior for this purpose since it is only necessary to screen for a single value in the first 16 bits of the SSRC. It is also not possible with BUNDLE to associate RTP streams from different m lines using a single SSRC value (as it is possible to do using the last 16 bits of the SSRC with RTP subsessions) due to the need to separate the RTCP messages for each RTP stream. The only short term disadvange of RTP subsessions is that the ssrc-prefix attribute has not yet been specified.
The author proposes that RTP subsessions be considered as a long-term replacement for BUNDLE.
SHIM [I-D.westerlund-avtcore-transport-multiplexing] is the most successful scheme in preserving all aspects of each RTP session when multiplexing those RTP sessions onto a single transport connection. Unfortunately, it changes RTP so can potentially impact many different middleboxes. It also slightly increases the size of each media packet, which can be of concern in some bandwidth limited deployments. Since SHIM also requires SDP extensions, there is no advantage to either in the time needed to stabilize an RFC. In considering the applicability of RTP subsessions as described in section 3 and the disadvantage of modifying RTP, the author does not consider the narrow range of applicability of SHIM to justify standardization.
The author proposes that RTP subsessions be considered for standardization instead of SHIM.
Two expired drafts ([I-D.rosenberg-rtcweb-rtpmux] and [I-D.peterson-rosenberg-avt-rtp-ssrc-demux]) propose other means of multiplexing based on the SSRC field. [I-D.rosenberg-rtcweb-rtpmux] uses a portion of the SSRC to identify the media type for the RTP stream. This scheme redefines the SSRC field and has significant limitations when multiple m lines share the same media type, since some other mechanism is still needed to separate them. [I-D.peterson-rosenberg-avt-rtp-ssrc-demux] assumes a single SSRC value per m line so is not consistent with current RTP multiplexing requirements.
Neither earlier SSRC based scheme fully addresses the requirements for multiplexing agreed in the working groups.
To be completed.
To be completed.