One document matched: draft-ejzak-avtcore-rtp-subsessions-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY BUNDLE SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mmusic-sdp-bundle-negotiation-00.xml">
<!ENTITY SHIM SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-westerlund-avtcore-transport-multiplexing-02.xml">
<!ENTITY muxarchitecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-westerlund-avtcore-multiplex-architecture-01.xml">
<!ENTITY maxssrc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-westerlund-avtcore-max-ssrc-01.xml">
<!ENTITY rtpmux SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-rosenberg-rtcweb-rtpmux-00.xml">
<!ENTITY rtpusage SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtcweb-rtp-usage-02.xml">
<!ENTITY ssrcdemux SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.peterson-rosenberg-avt-rtp-ssrc-demux.xml">
<!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC5245 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY RFC6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC5761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5761.xml">
<!ENTITY RFC4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ejzak-avtcore-rtp-subsessions-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="RTP subsessions">Media multiplexing with Real-time Transport Protocol (RTP) subsessions</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Richard Ejzak" initials="R.P."
surname="Ejzak">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>1960 Lucent Lane</street>
<!-- Reorder these if your country does things differently -->
<city>Naperville</city>
<region>Illinois</region>
<code>60563-1594</code>
<country>US</country>
</postal>
<phone>+1 630 979 7036</phone>
<email>richard.ejzak@alcatel-lucent.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2012" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>RAI</area>
<workgroup>AVTCORE</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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 <xref target="RFC5245"></xref> and DTLS key exchange <xref target="RFC6347"></xref> prior to being able to send media. RTP is specified in <xref target="RFC3550"></xref>. 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: <xref target="I-D.ietf-rtcweb-rtp-usage"></xref>, <xref target="I-D.westerlund-avtcore-multiplex-architecture"></xref> and <xref target="I-D.westerlund-avtcore-max-ssrc"></xref>. The BUNDLE solution <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref> uses SDP <xref target="RFC4566"></xref> to assign different sets of payload type values for each media line sharing an RTP session. The SHIM solution <xref target="I-D.westerlund-avtcore-transport-multiplexing"></xref> 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 <xref target="I-D.rosenberg-rtcweb-rtpmux"></xref> and <xref target="I-D.peterson-rosenberg-avt-rtp-ssrc-demux"></xref>. This document describes an alternative approach with advantages compared to the current preferred BUNDLE and SHIM approaches.</t>
</section>
<section title="Overview of RTP subsessions">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref target="RFC5761"></xref> 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.</t>
<t>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 <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref>) 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.</t>
</section>
<section title="Applicability of RTP subsessions">
<t>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.</t>
<t><xref target="RFC3550"></xref> 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 <xref target="I-D.westerlund-avtcore-multiplex-architecture"></xref>, but these differences are well understood and manageable. In addition, SRTP forwarding is more complex when SSRC is changed, as discussed in <xref target="I-D.westerlund-avtcore-multiplex-architecture"></xref>. 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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Example">
<t>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.</t>
<figure align="left">
<artwork align="left"><![CDATA[
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
...
]]></artwork>
</figure>
<t>The SDP answerer that agrees to use SDP subsessions as described in the SDP offer might respond with the following SDP answer.</t>
<figure align="left">
<artwork align="left"><![CDATA[
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
...
]]></artwork>
</figure>
<t>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.</t>
</section>
<section title="Evaluation">
<section title="Comparison to BUNDLE">
<t><xref target="I-D.ietf-mmusic-sdp-bundle-negotiation">BUNDLE</xref> 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.</t>
<t>The author proposes that RTP subsessions be considered as a long-term replacement for BUNDLE.</t>
</section>
<section title="Comparison to SHIM">
<t><xref target="I-D.westerlund-avtcore-transport-multiplexing">SHIM</xref> 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.</t>
<t>The author proposes that RTP subsessions be considered for standardization instead of SHIM.</t>
</section>
<section title="Comparison to other SSRC proposals">
<t>Two expired drafts (<xref target="I-D.rosenberg-rtcweb-rtpmux"></xref> and <xref target="I-D.peterson-rosenberg-avt-rtp-ssrc-demux"></xref>) propose other means of multiplexing based on the SSRC field. <xref target="I-D.rosenberg-rtcweb-rtpmux"></xref> 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. <xref target="I-D.peterson-rosenberg-avt-rtp-ssrc-demux"></xref> assumes a single SSRC value per m line so is not consistent with current RTP multiplexing requirements.</t>
<t>Neither earlier SSRC based scheme fully addresses the requirements for multiplexing agreed in the working groups.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>To be completed.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>To be completed.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&BUNDLE;
&SHIM;
&muxarchitecture;
&maxssrc;
&ssrcdemux;
&rtpmux;
&rtpusage;
&RFC3550;
&RFC5245;
&RFC6347;
&RFC5761;
&RFC4566;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:12:27 |