One document matched: draft-ejzak-avtcore-rtp-subsessions-02.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 msid SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.alvestrand-mmusic-msid.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-02" 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 a means of representing this multiplexing option in SDP so that network nodes can easily identify groups of RTP streams and their associated RTCP packets for differential treatment as necessary. This mechanism can be used to complement the BUNDLE multiplexing scheme, which uses the grouping framework to identify all media lines associated with a single transport connection, but provides no means for network nodes to group RTP streams and their RTCP packets for differential treatment. RTP subsessions is an alternative to the SHIM multiplexing proposal; it clearly partitions packets associated with different media lines without changing the format of individual RTP and RTCP packets, but it does not maintain a completely independent SSRC space for each media line, as does SHIM. RTP subsessions avoid SSRC conflicts by construction and can be used in all RTP topologies in which all systems implement RTP subsessions, although SSRC mapping might be needed when forwarding RTP streams from an unpartitioned RTP session into an RTP subsession.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The subject of RTP 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 enable network nodes to provide differential treatment to multiplexed media types within the same transport connection, since means already exist to apply differential treatment to an entire transport connection and RTP is capable of multiplexing RTP streams of the same media type onto a single transport connection using the SSRC field. While an application may be able to request different DSCP markings for these flows, the treatment associated with a particular marking is network-specific and many networks routinely remap packet markings according to local policy unless they can independently verify the requested treatment.</t>
<t>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>, <xref target="I-D.westerlund-avtcore-max-ssrc"></xref> and <xref target="I-D.alvestrand-mmusic-msid"></xref>. Note in particular that the use of MSID, mandated in RTCWEB, uses SSRC reservation to assist in stream identification.</t>
<t>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>.</t>
<t>This document describes an optional enhancement to BUNDLE that allows network nodes to identify RTP streams associated with an SDP media line and their associated RTCP packets for differential treatment in the network. Also included is a description of a means of negotiating use of RTP subsessions in SDP, along with some alternatives. This document assumes the use of unicast RTP sessions only and there is no discussion of multicast sessions.</t>
</section>
<section title="Overview of RTP subsessions">
<section title="RTP procedures">
<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>As described in <xref target="RFC3550"></xref>, RTP topologies can include end systems, translators(relays) and mixers. RTP subsessions are particularly suited to supporting end systems and mixers, since these systems typically remap SSRC values when forwarding RTP streams and so can independently assign SSRC values on each transport connection. The remainder of this section describes use of RTP subsessions by end systems and mixers; a later section describes use of RTP subsessions by relays.</t>
<t>Each RTP subsession sharing a single transport connection is assigned a unique 24-bit SSRC prefix for each direction of transmission, i.e., the first (highest order) bit is reserved to indicate each direction of transmission and the next 23 bits of the 32-bit SSRC field have a fixed value for RTP streams associated with the RTP subsession. Each assigned SSRC prefix is also unique in the first 8 bits to allow for potential connection to relays that forward RTP streams from other sources. The network can use the first 8 bits of the SSRC prefix to filter IP packets on the transport connection to identify those associated with the RTP subsession.</t>
<t>In non-relay topologies, the SDP offerer selects the first 24 bits of the SSRC for RTP streams associated with a media line that it transmits to the SDP answerer, and the SDP answerer selects the other value of the 1st bit and the same values of the remaining 23 bits of the SSRC prefix selected by the SDP offerer for RTP streams associated with the same media line that it transmits in the other direction to the SDP offerer. The final 8 bits of the SSRC are available to specify separate RTP streams within the RTP subsession. The SDP offerer selects the 24 bits of the SSRC prefix randomly for each RTP subsession in such a way that the first 8 bits are also unique across known RTP subsessions in the transport connection, and each endpoint selects the last 8 bits of the SSRC randomly for each RTP stream within an RTP subsession. The SDP offerer is allowed to specify either value for the 1st 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>
</section>
<section title="Summary of SSRC bit assignments">
<t>RTP subsessions supports topologies including end systems, mixers and translators (relays), where relays are classified either as "master" or "slave". These end systems share responsibility for SSRC bit assignments as described in the following table, using the procedure described in the following section. There is a strict precedence order between these systems, where a master relay can override SSRC prefix assignments made by a slave relay, which can override SSRC prefix assignments made by a mixer or end system, but not the other way around.</t>
<texttable title="SSRC bit assignments">
<ttcol width="30%">SSRC bit range</ttcol>
<ttcol>Purpose</ttcol>
<c>1</c>
<c>identifies direction of flow</c>
<c>2-8</c>
<c>subsession id (for QoS)</c>
<c>9-16</c>
<c>allocated by primary relay to slave relays (except one value reserved for self)</c>
<c>17-24</c>
<c>allocated by slave relays to non-relay systems</c>
<c>25-32</c>
<c>allocated by non-relay systems to individual RTP streams (e.g., via MSID)</c>
</texttable>
</section>
<section title="SDP procedures">
<t>The use of RTP subsessions is negotiated during the SDP offer/answer exchange as follows. When signaled in combination with BUNDLE, BUNDLE defines each group of media lines to share a transport connection, and the SDP attribute for RTP subsessions defines the SSRC prefix for each media line. Use of RTP subsessions without BUNDLE is possible but not defined within this document. This draft assumes that only one port is assigned for transport of RTP streams on each m line, since use of multiple ports, though allowed in <xref target="RFC4566"></xref>, is rarely used. SDP subsessions can be readily enhanced to support multiple media ports per m line if necessary.</t>
<t>BUNDLE specifies how the connection and port information is to be set for each media line in a BUNDLE group. When RTP subsessions is used with BUNDLE, there is no requirement for the payload type numbers for each media line in the group to be non-overlapping, as required for BUNDLE without RTP subsessions. The payload type field is not needed to identify the media line associated with an RTP stream if the SSRC prefix is known.</t>
<t>A system supporting RTP subsessions will include an "ssrc-prefix" attribute for each media line in a sharing group, where each ssrc-prefix attribute includes a parameter that indicates whether the system is a relay (supporting RTP stream forwarding) and a parameter that is a hex representation of the 24-bit SSRC prefix proposed for use by the RTP subsession associated with the m line. If the endpoint expects to transmit or receive more than 256 RTP streams of the same media type, it should allocate more than one m line for that media type. The system will also include the rtcp-mux attribute <xref target="RFC5761"></xref> for each media line sharing the same transport connection. A system supporting RTP subsessions that receives SDP with ssrc-prefix attributes will assume the presence of the rtcp-mux attribute for each associated media line, even in its absence. While rtcp-mux could be made optional, there is no clear use case for supporting RTP subsessions without rtcp-mux.</t>
<t>In addition to including the requisite BUNDLE attributes, the SDP offer includes the ssrc-prefix attribute and the rtcp-mux attribute for each media line in the sharing group. If the SDP answerer is not a relay and agrees to use RTP subsessions (regardless of the role of the SDP offerer), or if the SDP offerer is not a relay and the SDP answerer is a relay that agrees to use RTP subsessions with the value(s) of the SSRC prefix in the SDP offer, then the SDP answerer also includes in the SDP answer the BUNDLE attributes, the ssrc-prefix attribute and the rtcp-mux attribute for each media line in the sharing group, with the same ssrc-prefix parameter values as the corresponding ones from the SDP offer, but with the 1st bit changed, i.e., '0' becomes '1' or '1' becomes '0'. The SDP answerer can disable the use of RTP subsessions by not including the ssrc-prefix attributes in the answer.</t>
<t>If the SDP offerer is not a relay and the SDP answerer is a relay that selects not to use the SSRC prefix in the SDP offer for one or more of the media lines, then it includes in the SDP answer the BUNDLE attributes, the ssrc-prefix attribute and the rtcp-mux attribute for each media line in the sharing group, with its own ssrc-prefix parameter values for those selected media lines and as described in the previous paragraph for the remaining media lines. The SDP offerer must then use the ssrc-prefix values from the selected media lines in the SDP answer with the 1st bit changed as above. Note that for these selected media lines, any SSRC values selected by other SDP attributes (such as ssrc for msid) in the SDP offer are assumed by the SDP answerer to be remapped to include the ssrc-prefix from the SDP answer with the 1st bit changed and the original final 8 bits from the attribute in the SDP offer. The SDP offerer will also assume the use of the remapped values and include the remapped values in any subsequent SDP messages.</t>
</section>
<section title="Additional procedures for relays">
<t>RTP subsessions will work without SSRC collisions for RTP system configurations consisting of a single master relay directly connected to up to 256 slave relays, where each relay may be directly connected to up to 256 end systems or mixers. Note that a master relay incorporates the function of at least one slave relay so that it can connect to non-relay systems. The only requirements are that the master relay initiate all connections to separate slave relays using SDP offer/answer procedures and that all participating systems in the RTP session comprising the RTP subsessions support SDP offer/answer procedures to negotiate RTP subsessions. The master relay picks the first 8 bits of the SSRC for every RTP subsession (used for filtering in the network), thus allowing up to 128 RTP subsessions within an RTP session. Each RTP subsession multiplexes traffic that is to receive the same QoS treatment throughout the RTP session. The master relay picks the first 16 bits of the SSRC that a slave relay can use with a particular RTP subsession and the slave relay picks the first 24 bits of the SSRC that an end system or mixer can use with a particular RTP subsession. The non-relay systems are free to allocate the last 8 bits of the SSRC to multiplex RTP streams on an RTP subsession.</t>
<t>The previous sections already describe how SDP offer/answer occurs between relay and non-relay systems to ensure that the relay determines the 24-bit SSRC prefix that the non-relay system uses for an RTP subsession, regardless of which system initiates the SDP offer/answer procedure.</t>
<t>Once a relay system chooses the role of a master relay by selecting an SSRC prefix for an RTP subsession, it refuses to accept an SDP offer from any other relay. When sending an SDP offer to another system, without knowing if it is another relay, it selects a 24-bit SSRC prefix for each media line as already discussed, ensuring that the first 16 bits of the SSRC have not been assigned to any other transport connection. If the SDP answerer is not a relay, then the 24-bit SSRC prefix is reserved for the non-relay system to use for the RTP subsession. If the SDP answerer is another relay (a slave relay), it can accept the RTP subsession in the same manner as a non-relay system by responding with the same ssrc-prefix with the first bit changed. A slave relay is not allowed to respond to a master relay with a different SSRC prefix except for the changed first bit. Since the SDP offerer and answerer both signal that they are relays, they both understand that the master relay will reserve the first 16 bits of the SSRC to the slave relay, thus allowing the master relay to delegate SSRC prefix assignment to up to 256 slave relays and allowing each slave relay to select the 24-bit SSRC prefix for the RTP subsessions for up to 256 non-relay systems.</t>
</section>
<section title="When a system doesn't support RTP subsessions">
<t>When a non-relay system fails to negotiate the use of RTP subsessions with a peer, it will be difficult for the network to identify flows for differential treatment in the presence of BUNDLE type multiplexing. Once a relay has committed to RTP subsessions with one or more other systems, it has only two choices if a new system being added to the RTP session does not support RTP subsessions: it can re-negotiate with all existing systems to disable RTP subsessions; or it can perform SSRC mapping with the non-conformant system.</t>
</section>
<section title="Alternative SDP procedures considered">
<t>Since <xref target="I-D.alvestrand-mmusic-msid"></xref> already describes an SSRC reservation procedure for SDP, it is appropriate to consider the relationship to RTP subsessions and whether MSID can be used to simplify the signaling of RTP subsessions in SDP.
</t>
<section title="Signaling only MSID">
<t>If we consider using MSID without change to signal the use of RTP subsessions, there are two limitations to consider. MSID provides for explicit identification of the SSSRC used for each stream, so a traffic filter could be constructed to search for RTP packets with particular SSRC values, but this is quite cumbersome once there is any significant amount of multiplexing per media line. Furthermore, MSID includes no SSRC collision resolution procedure, thus making the use of SDP offer/answer re-negotiation necessary for collision resolution. While SSRC collisions are fairly rare if SSRC assignment is completely random, collisions will occur and this form of resolution is expensive and preferably avoided.
</t>
</section>
<section title="MSID with implicit SSRC range reservation">
<t>RTP subsession negotiation could be easily added to MSID as a mandatory feature, as follows. If selection of an SSRC value for MSID implicitly reserves SSRC ranges according to the conventions described earlier in the document, then there would be no need to explicitly signal the SSRC prefix. The only aspect missing is to create a convention to negotiate precedence (master relay, slave relay, or other) to provide for a simple method of resolving any SSRC or SSRC range collisions. Details are left for further study if this proposal for enhancing MSID is agreed.
</t>
</section>
</section>
</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 associated with constraints on SSRC assignment. No changes are required to RTP or SRTP packet formats 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 8 bits of the SSRC field, in addition to the five-tuple for the transport connection. 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 (relays) 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 and thus are free to detect and resolve SSRC conflicts. For interworking with systems not supporting RTP subsessions in particular, a relay can act as a mixer to reassign the SSRC value associated with an RTP stream before forwarding. When performing SSRC mapping rather than SRC forwarding, RTCP is handled differently and SRTP forwarding is more complex, requiring the decrypting and re-encrypting of each packet, 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 in RTCWEB to require support for forwarding with SSRC preservation. Systems that provide additional media processing functions before forwarding RTP streams need to decrypt SRTP packets anyway.</t>
<t>The relay procedures for RTP subsessions allow support of most relay topologies as long as all systems in an RTP session support RTP subsessions. This is a limitation in the short term when interworking with existing systems, but if RTP subsession support is made available early in the deployment of RTCWEB systems, then new applications where relay systems, multiplexing of different media types, and differential treatment of media flows are desirable can require support for RTP subsessions.</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 24 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>
<t>Another short term limitation of RTP subsessions is that most networks capable of assigning differential treatment do so with the granularity of a five-tuple. The availability of a simple filter to identify flows for differential treatment allows deployment of DPI or custom gateways to enforce or verify DSCP markings in the short term. In the longer term, network policy control systems can be enhanced to perform SSRC prefix filtering.</t>
</section>
<section title="Examples">
<t>In the first example, a non-relay SDP offerer desiring to use a single transport connection for an audio m line and a video m line might construct the following SDP offer. BUNDLE attributes are present but not shown.</t>
<figure align="left">
<artwork align="left"><![CDATA[
c=...
m=audio 49170 RTP/AVP 96 97
a=rtcp-mux
a=ssrc-prefix: non-relay 0x111111
...
m=video 49170 RTP/AVP 98 99
a=rtcp-mux
a=ssrc-prefix: non-relay 0x222222
...
]]></artwork>
</figure>
<t>The non-relay SDP answerer agrees to use SDP subsessions as described in the SDP offer and accepts the SSRC prefixes for the two m lines as shown below. BUNDLE attributes are present but not shown.</t>
<figure align="left">
<artwork align="left"><![CDATA[
c=...
m=audio 36008 RTP/AVP 96 97
a=rtcp-mux
a=ssrc-prefix: non-relay 0x911111
...
m=video 36008 RTP/AVP 98 99
a=rtcp-mux
a=ssrc-prefix: non-relay 0xa22222
...
]]></artwork>
</figure>
<t>The endpoints will establish one audio RTP subsession and one video RTP subsession 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 8 bits of the SSRC field as necessary for differential handling, e.g., to assign separate QoS treatment. The SDP offerer will send RTP streams on the two RTP subsessions for the audio and video media m lines using 24-bit SSRC prefixes 0x111111 and 0x222222, respectively. The SDP answerer will send RTP streams using 24-bit SSRC prefixes 0x911111 and 0xa22222, respectively. The network can filter on 8-bit SSRC prefixes 0x11 and 0x22 for packets in the five-tuple from the SDP offerer and the network can filter on 8-bit SSRC prefixes 0x91 and 0xa2 for packets in the five-tuple sent to the SDP offerer.</t>
<t>In another example to highlight how a relay may override an SSRC prefix selected by a non-relay system, a non-relay SDP offerer desiring to use a single transport connection for an audio m line and a video m line might construct the following SDP offer. BUNDLE attributes are present but not shown.</t>
<figure align="left">
<artwork align="left"><![CDATA[
c=...
m=audio 49170 RTP/AVP 96 97
a=rtcp-mux
a=ssrc-prefix: non-relay 0x111111
...
m=video 49170 RTP/AVP 98 99
a=rtcp-mux
a=ssrc-prefix: non-relay 0x222222
...
]]></artwork>
</figure>
<t>The SDP answerer performing as an RTP relay agrees to use SDP subsessions as described in the SDP offer. It accepts the SSRC prefix for the audio m line but selects an alternate SSRC prefix for the video m line as shown below. BUNDLE attributes are present but not shown.</t>
<figure align="left">
<artwork align="left"><![CDATA[
c=...
m=audio 36008 RTP/AVP 96 97
a=rtcp-mux
a=ssrc-prefix: relay 0x911111
...
m=video 36008 RTP/AVP 98 99
a=rtcp-mux
a=ssrc-prefix: relay 0x333333
...
]]></artwork>
</figure>
<t>The endpoints will establish one audio RTP subsession and one video RTP subsession 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 8 bits of the SSRC field as necessary for differential handling, e.g., to assign separate QoS treatment. The non-relay SDP offerer will send RTP streams on the two RTP subsessions for the audio and video media m lines using 24-bit SSRC prefixes 0x111111 and 0xb33333, respectively. The SDP answerer performing as an RTP relay will send RTP streams (forwarded from other systems) using 8-bit SSRC prefixes 0x91 and 0x33, respectively. The network can filter on 8-bit SSRC prefixes 0x11 and 0xb3 for packets in the five-tuple from the SDP offerer and the network can filter on 8-bit SSRC prefixes 0x91 and 0x33 for packets in the five-tuple sent to the SDP offerer. Note that the 32-bit prefix for any ssrc values selected for RTP streams associated with the video m line are assumed to be changed from 0x222222 to 0xb33333 while ssrc values selected for the audio line can remain unchanged.</t>
</section>
<section title="Evaluation">
<section title="Comparison to BUNDLE">
<t><xref target="I-D.ietf-mmusic-sdp-bundle-negotiation">BUNDLE</xref> effectively merges RTP sessions together in relay topologies, thus slightly increasing the probability of SSRC collisions, although the impact is minor. In the context of RTCWEB, an SSRC collision, though rare, will require the use of an additional SDP offer/answer transaction to change msid/ssrc mappings, so is clearly undesirable. This can be avoided with RTP subsessions, since SDP offer/answer is used to pre-allocate SSRC ranges for each m line, thus completely avoiding SSRC collisions. It must also 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. It is difficult to define a filter to allow the network to identify the RTP streams associated with different media lines with BUNDLE since this requires filtering on sets of payload type values. RTP subsessions can enhance BUNDLE for this purpose, since it is only necessary to screen for a single value in the first 8 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 24 bits of the SSRC with RTP subsessions), due to the need to separate the RTCP messages for each RTP stream.</t>
<t>The author proposes that RTP subsessions be adopted to augment BUNDLE to eliminate the restrictions described above. </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 the SSRC space of each RTP session when multiplexing those RTP sessions onto a single transport connection. SHIM changes RTP so it 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.</t>
<t>The author recommends RTP subsessions over SHIM to better address two key requirements: to support flow identification for differential treatment; and to minimize impact on the RTP packet format. Given the increasing use of pre-selected SSRC values to identify individual RTP streams, which is inconsistent with the idea of random SSRC assignment and the use of SSRC collision detection and resolution schemes, the author also recommends the use of an effective SSRC collision avoidance scheme based on SSRC range reservation, such as the one defined for RTP subsessions.</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;
&msid;
&SHIM;
&muxarchitecture;
&maxssrc;
&ssrcdemux;
&rtpmux;
&rtpusage;
&RFC3550;
&RFC5245;
&RFC6347;
&RFC5761;
&RFC4566;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:11:59 |