One document matched: draft-pthatcher-mmusic-rid-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.28 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-pthatcher-mmusic-rid-00" category="std">
<front>
<title abbrev="rid">RTP Payload Format Constraints</title>
<author initials="P." surname="Thatcher" fullname="Peter Thatcher">
<organization>Google</organization>
<address>
<email>pthatcher@google.com</email>
</address>
</author>
<author initials="M." surname="Zanaty" fullname="Mo Zanaty">
<organization>Cisco Systems</organization>
<address>
<email>mzanaty@cisco.com</email>
</address>
</author>
<author initials="S." surname="Nandakumar" fullname="Suhas Nandakumar">
<organization>Cisco Systems</organization>
<address>
<email>snandaku@cisco.com</email>
</address>
</author>
<author initials="A.B." surname="Roach" fullname="Adam Roach">
<organization>Mozilla</organization>
<address>
<email>adam@nostrum.com</email>
</address>
</author>
<author initials="B." surname="Burman" fullname="Bo Burman">
<organization>Ericsson</organization>
<address>
<email>bo.burman@ericsson.com</email>
</address>
</author>
<author initials="B." surname="Campen" fullname="Byron Campen">
<organization>Mozilla</organization>
<address>
<email>bcampen@mozilla.com</email>
</address>
</author>
<date year="2015" month="October" day="02"/>
<abstract>
<t>In this specification, we define a framework for identifying Source RTP Streams with the constraints on its payload format in the Session Description Protocol. This framework uses “rid” SDP attribute to: a) effectively identify the Source RTP Streams within a RTP Session, b) constrain their payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types and c) enable unambiguous mapping between the Source RTP Streams to their media format specification in the SDP.</t>
<t>Note-1: The name ‘rid’ is not yet finalized. Please refer to Section “Open Issues” for more details on the naming.</t>
</abstract>
</front>
<middle>
<section anchor="sec-intro" title="Introduction">
<t>Payload Type (PT) in RTP provides mapping between the format of the RTP payload and the media format description specified in the signaling. For applications that use SDP for signaling, the constructs rtpmap and/or fmtp describe the characteristics of the media that is carried in the RTP payload, mapped to a given PT.</t>
<t>Recent advances in standards such as RTCWEB and NETVC have given rise to
rich multimedia applications requiring support for multiple RTP Streams with in a RTP session <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>, <xref target="I-D.ietf-mmusic-sdp-simulcast"/> or having to support multiple codecs, for
example. These demands have unearthed challenges inherent with:</t>
<t><list style="symbols">
<t>The restricted RTP PT space in specifying the various payload configurations,</t>
<t>The codec-specific constructs for the payload formats in SDP,</t>
<t>Missing or underspecied payload format parameters,</t>
<t>Ambiguity in mapping between the individual Source RTP Streams and their equivalent format specification in the SDP.</t>
</list></t>
<t>This specification defines a new SDP framework for configuring and identifying
Source RTP Streams (Section 2.1.10 <xref target="I-D.ietf-avtext-rtp-grouping-taxonomy"/>) called “RTP Source Stream Identifier (rid)” along with the SDP attributes to constrain their payload formats in a codec-agnostic way. The “rid” framework can be thought of as complementary extension to the way the media format parameters are specified in SDP today, via the “a=fmtp” attribute.
This specification also proposes a new RTP header extension to carry the
“rid” value, to provide correlation between the RTP Packets and their
format specification in the SDP.</t>
<t>Note that the “rid” parameters only serve to further constrain the parameters
that are established on a PT format. They do not relax any existing constraints.</t>
</section>
<section anchor="key-words-for-requirements" title="Key Words for Requirements">
<t>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 <xref target="RFC2119"/></t>
</section>
<section anchor="terminology" title="Terminology">
<t>The terms Source RTP Stream, Endpoint, RTP Session, and
RTP Stream are used as defined in <xref target="I-D.ietf-avtext-rtp-grouping-taxonomy"/>.</t>
<t><xref target="RFC4566"/> and <xref target="RFC3264"/> terminology is also used where appropriate.</t>
</section>
<section anchor="sec-motivation" title="Motivation">
<t>This section summarizes several motivations for proposing the “rid”
framework.</t>
<t><list style="numbers">
<t>RTP PT Space Exhaustion:
<xref target="RFC3550"/> defines payload type (PT) that identifies the format of the RTP payload and determine its interpretation by the application. <xref target="RFC3550"/> assigns 7 bits for the PT in the RTP header. However, the assignment of static mapping of payload codes to payload formats and multiplexing of RTP with other protocols (such as RTCP) could result in limited number of payload type numbers available for the application usage. In scenarios where the number of possible RTP payload configurations exceed the available PT space within a RTP Session, there is need a way to represent the additional payload configurations
and also to effectively map a Source RTP Stream to its configuration in the signaling.</t>
<t>Codec-Specific Media Format Specification in SDP: RTP Payload configuration is typically specified using rtpmap and fmtp SDP attributes. The rtpmap attribute provides the media format to RTP PT mapping and the ftmp attribute describes the media format specific parameters. The syntax for the fmtp attribute is tightly coupled to a specific media format (such as H.264, H.265, VP8). This has resulted in a myriad ways for defining the attributes that are common across different media formats. Additionally, with the advent of new standards efforts such as NETVC, one can expect more media formats to be standardized in the
future. Thus, there is a need to define common media characteristics
in a codec-agnostic way in order to reduce the duplicated efforts and to simplify the syntactic representation across the different codec standards.</t>
<t>Multi-source and Multi-stream Use Cases: Recently, there is a rising trend with real-time multimedia applications supporting multiple sources per endpoint with various temporal resolutions (Scalable Video Codec) and spatial resolutions (Simulcast) per source. These applications are being challenged
by the limited RTP PT space and/or by the underspecified SDP constructs for
exercising granular control on configuring the individual Source RTP Streams.</t>
</list></t>
</section>
<section anchor="sec-rid_attribute" title="SDP ‘rid’ Media Level Attribute">
<t>This section defines new SDP media-level attribute <xref target="RFC4566"/>, “a=rid”.</t>
<figure><artwork><![CDATA[
a=rid:<rid-identifier> <direction> pt=<fmt-list> <rid-attribute>:<value> ...
]]></artwork></figure>
<t>A given “a=rid” SDP media attribute specifies constraints defining
an unique RTP payload configuration identified via the “rid-identifier”.
A set of codec-agnostic “rid-level” attributes are defined (<xref target="sec-rid_level_attributes"/>) that describe the media format specification
applicable to one or more Payload Types speicified by the “a=rid” line.</t>
<t>The ‘rid’ framework MAY be used in combination with the ‘a=fmtp’ SDP
attribute for describing the media format parameters for a given
RTP Payload Type. However in such scenarios, the ‘rid-level’ attributes
(<xref target="sec-rid_level_attributes"/>) further constrains the equivalent ‘fmtp’ attributes.</t>
<t>The ‘direction’ identifies the either ‘send’, ‘recv’ directionality
of the Source RTP Stream.</t>
<t>A given SDP media description MAY have zero or more “a=rid” lines
describing various possible RTP payload configurations. A given
‘rid-identifier’ MUST not be repeated in a given media description.</t>
<t>The ‘rid’ media attribute MAY be used for any RTP-based media transport.
It is not defined for other transports.</t>
<t>Though the ‘rid-level’ attributes specified by the ‘rid’ property
follow the syntax similar to session-level and media-level attributes,
they are defined independently. All ‘rid-level’ attributes MUST be
registered with IANA, using the registry defined in <xref target="sec-iana"/></t>
<t><xref target="sec-abnf"/> gives a formal Augmented Backus-Naur Form(ABNF)
<xref target="RFC5234"/> grammar for the “rid” attribute.</t>
<t>The “a=rid” media attribute is not dependent on charset.</t>
</section>
<section anchor="sec-rid_level_attributes" title="“rid-level’ attributes">
<t>This section defines the ‘rid-level’ attributes that can be used
to constrain the RTP payload encoding format in a codec-agnostic way.</t>
<t>The following new SDP parameters shall be defined that represent things common across video codecs.</t>
<t><list style="symbols">
<t>max-width, for spatial resolution in pixels. In the case that stream orientation signaling is used to modify the intended display orientation, this attribute refers to the width of
the stream when a rotation of zero degrees is encoded.</t>
<t>max-height, for spatial resolution in pixels. In the case that stream orientation signaling is used to modify the intended display orientation, this attribute refers to the width of the stream when a rotation of zero degrees is encoded.</t>
<t>max-fps, for frame rate in frames per second. For encoders that do not use a fixed framerate for encoding, this value should constrain the minimum amount of time between frames: the time between any two consecutive frames SHOULD not be less than 1/max-fps seconds.</t>
<t>max-fs, for frame size in pixels per frame.</t>
<t>max-br, for bit rate in bits per second. The exact means of keeping withing this limit are left up to the implementation, and instantaneous excursions outside the limit are permissible. For any given one-second sliding window, however, the total number of bits in the payload portion of RTP SHOULD NOT exceed the value specific in “max-br.”</t>
<t>max-pps, for pixel rate in pixels per second. This value SHOULD be handled identically to max-fps, after performing the following conversion: max-fps = max-pps / (width * height). If the stream resolution changes, this value is recalculated. Due to this recalculation, excursions outside the specified maximum are possible during near resolution change boundaries.</t>
</list></t>
<t>All the attributes are optional and are subjected to negotiation
based on the SDP Offer/Answer rules described in <xref target="sec-sdp_o_a"/></t>
<t><xref target="sec-abnf"/> provides formal Augmented Backus-Naur Form(ABNF) <xref target="RFC5234"/> grammar for each of the “rid-level” attributes defined in this section.</t>
</section>
<section anchor="sec-sdp_o_a" title="SDP Offer/Answer Procedures">
<t>This section describes the SDP Offer/Answer <xref target="RFC3264"/> procedures when
using the ‘rid’ framework.</t>
<section anchor="generating-the-initial-sdp-offer" title="Generating the Initial SDP Offer">
<t>For each media description in the offer, the offerer MAY choose to
include one or more “a=rid” lines to specify a configuration profile for
the given set of RTP Payload Types.</t>
<t>In order to construct a given “a=rid” line, the offerer must follow
the below steps:</t>
<t><list style="numbers">
<t>It MUST generate rid-identifier’ unique with in a media description</t>
<t>It MUST set the direction for the ‘rid-identifier’ to one of
‘send’ or ‘recv’</t>
<t>A listing of SDP format tokens (usually corresponding to RTP payload
types) MUST be included to which the constraints expressed by the
‘rid-level’ attributes apply. The Payload Types chosen MUST either be defined as part of “a=rtpmap” or “a=fmtp” attributes.</t>
<t>The Offerer then chooses the ‘rid-level’ attributes
(<xref target="sec-rid_level_attributes"/>) to be applied for the SDP format tokens listed.</t>
<t>If an ‘a=fmtp’ attribute is also used to provide media-format-specific
parameters, then the ‘rid-level’ attributes will further constrain the equivalent ‘fmtp’ parameters for the given Payload Type for those streams associated with the ‘rid’.</t>
</list></t>
</section>
<section anchor="answerer-processing-the-sdp-offer" title="Answerer processing the SDP Offer">
<t>For each media description in the offer, and for each “a=rid” attribute
in the media description, the receiver of the offer will perform the
following steps:</t>
<section anchor="rid-unaware-answerer" title="‘rid’ unaware Answerer">
<t>If the receiver doesn’t support the ‘rid’ framework proposed in this specification, the entire “a=rid” line is ignored following the standard
<xref target="RFC3264"/> Offer/Answer rules. If a given codec would require ‘a=fmtp’ line
when used without “a-rid” then the offer still needs to include that even when
using RID.</t>
</section>
<section anchor="rid-aware-answerer" title="‘rid’ aware Answerer">
<t>If the answerer supports ‘rid’ framework, the following steps are executed, in
order, for each “a=rid” line in a given media description:</t>
<t><list style="numbers">
<t>Extract the rid-identifier from the “a=rid” line and verify its uniqueness.
In the case of a duplicate, the entire “a=rid” line is rejected and MUST not be included in the SDP Answer.</t>
<t>As a next step, the list of payload types are verified against the list
obtained from “a=rtpmap” and/or “a=fmtp” attributes. If there is no match
for the Payload Type listed in the “a=rid” line, then remove the “a=rid” line. The exception being when ‘*’ is used for identifying the media format,
where in the “a=rid” line applies to all the formats in a given media description.</t>
<t>On verifying the Payload Type(s) matches, the answerer shall ensure that
“rid-level” attributes listed are supported and syntactically well formed.
In the case of a syntax error or an unsupported parameter, the “a=rid” line is removed.</t>
<t>If the ‘depend’ rid-level attribute is included, the answerer MUST make
sure that the rid-identifiers listed unambiguously match the rid-identifiers in the SDP offer.</t>
<t>If the media description contains an “a=fmtp” attribute, the answerer
verifies that the attribute values provided in the “rid-level” attributes are within the scope of their fmtp equivalents for a given media format.</t>
</list></t>
</section>
</section>
<section anchor="generating-the-sdp-answer" title="Generating the SDP Answer">
<t>Having performed the verification of the SDP offer as described, the answerer shall perform the following steps to generate the SDP answer.</t>
<t>For each “a=rid” line:</t>
<t><list style="numbers">
<t>The answerer MAY choose to modify specific ‘rid-level’ attribute value in
the answer SDP. In such a case, the modified value MUST be lower (more constrained) than the ones specified in the offer.</t>
<t>The answerer MUST NOT modify the ‘rid-identifier’ present in the offer.</t>
<t>The answerer is allowed to remove one or more media formats from a
given ‘a=rid’ line. If the answerer chooses to remove all the
media format tokens from an “a=rid” line, the answerer MUST remove the entire “a=rid” line.</t>
<t>In cases where the answerer is unable to support the payload configuration
specified in a given “a=rid” line in the offer, the answerer MUST remove the corresponding “a=rid” line.</t>
</list></t>
</section>
<section anchor="offering-processing-of-the-sdp-answer" title="Offering Processing of the SDP Answer">
<t>The offerer shall follow the steps similar to answerer’s offer processing with the following exceptions</t>
<t><list style="numbers">
<t>The offerer MUST ensure that the ‘rid-identifiers’ aren’t changed between
the offer and the answer. If so, the offerer MUST consider the corresponding
‘a=rid’ line as rejected.</t>
<t>If there exist changes in the ‘rid-level’ attribute values, the offerer
MUST ensure that the modifications can be supported or else consider the “a=rid” line as rejected.</t>
<t>If the SDP answer contains any “rid-identifier” that doesn’t match with
the offer, the offerer MUST ignore the corresponding “a=rid” line.</t>
</list></t>
</section>
<section anchor="modifying-the-session" title="Modifying the Session">
<t>TODO</t>
</section>
</section>
<section anchor="usage-of-rid-in-rtp" title="Usage of ‘rid’ in RTP">
<t>The RTP fixed header includes the payload type number and the SSRC
values of the RTP stream. RTP defines how you de-multiplex streams
within an RTP session, but in some use cases applications need
further identifiers in order to effectively map the individual
RTP Streams to their equivalent payload configurations in the SDP.</t>
<t>This specification defines a new RTP header extension to include the ‘rid-identifier’. This makes it possible for a receiver to associate received RTP packets (identifying the Source RTP Stream) with a media description having the format constraint specificied.</t>
<section anchor="rtp-rid-header-extension" title="RTP ‘rid’ Header Extension">
<t>The payload, containing the identification-tag, of the RTP ‘rid-identifier’ header extension element can be encoded using either the one-byte or two-byte header <xref target="RFC5285"/>. The identification-tag payload is UTF-8 encoded, as in SDP.</t>
<t>As the identification-tag is included in an RTP header extension, there should be some consideration about the packet expansion caused by the identification-tag. To avoid Maximum Transmission Unit (MTU) issues for the RTP packets, the
header extension’s size needs to be taken into account when the encoding media.
Note that set of header extensions included in the packet needs to be padded to the next 32-bit boundary using zero bytes <xref target="RFC5285"/></t>
<t>It is recommended that the identification-tag is kept short. Due to the properties of the RTP header extension mechanism, when using the one-byte header, a tag that is 1-3 bytes will result in that a minimal number of 32-bit words are used for the RTP
header extension, in case no other header extensions are included at the same time. In many cases, a one-byte tag will be sufficient; it is RECOMMENDED that implementations use the shortest tag that fits their purposes.</t>
</section>
</section>
<section anchor="sec-abnf" title="Formal Grammar">
<t>This section gives a formal Augmented Backus-Naur Form (ABNF)
<xref target="RFC5234"/> grammar for each of the new media and rid-level attributes
defined in this document.</t>
<figure><artwork><![CDATA[
rid-syntax = "a=rid:" rid-identifier SP rid-dir SP rid-fmt-list SP rid-attr-list
rid-identifier = 1*(alpha-numeric / "-" / "_")
rid-dir = "send" / "recv"
rid-fmt-list = "pt=" rid-fmt *( ";" rid-fmt )
rid-fmt = "*" ; wildcard: applies to all formats
/ fmt
rid-attr-list = rid-width-param
/ rid-height-param
/ rid-fps-param
/ rid-fs-param
/ rid-br-param
/ rid-pps-param
/ rid-depend-param
rid-width-param = "max-width=" param-val
rid-height-param = "max-height=" param-val
rid-fps-param = "max-fps=" param-val
rid-fs-param = "max-fs=" param-val
rid-br-param = "max-br=" param-val
rid-pps-param = "max-pps=" param-val
rid-depend-param = "depend=" rid-list
rid-list = rid-identifier *( ";" rid-identifier )
param-val = byte-string
; WSP defined in {{RFC5234}}
; fmt defined in {{RFC4566}}
; byte-string in {{RFC4566}}
]]></artwork></figure>
</section>
<section anchor="sdp-examples" title="SDP Examples">
<section anchor="many-bundled-streams-using-many-codecs" title="Many Bundled Streams using Many Codecs">
<t>In this scenario, the offerer supports the Opus, G.722, G.711 and DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC (SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a mixer) is supported (send 1 and receive 7 video streams) by offering 7 video media sections (1 sendrecv at max resolution and 6 recvonly at smaller resolutions), all bundled on the same port, using 3 different resolutions.
The resolutions include:</t>
<t><list style="symbols">
<t>1 receive stream of 720p resolution is offered for the active speaker.</t>
<t>2 receive streams of 360p resolution are offered for the prior 2 active speakers.</t>
<t>4 receive streams of 180p resolution are offered for others in the call.</t>
</list></t>
<t>Expressing all these codecs and resolutions using 32 dynamic PTs (2 audio + 10x3 video) would exhaust the primary dynamic space (96-127). RIDs are used to avoid PT exhaustion and express the resolution constraints.</t>
<t><list style='empty'>
<t>Note: The SDP given below skips few lines to keep the example short and
focussed, as indicated by either the “…” or the comments inserted.</t>
</list></t>
<figure><artwork><![CDATA[
Example 1
Offer:
...
m=audio 10000 RTP/SAVPF 96 9 8 0 123
a=rtpmap:96 OPUS/48000
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:123 telephone-event/8000
a=mid:a1
...
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
a=rtpmap:98 VP8/90000
a=fmtp:98 max-fs=3600; max-fr=30
a=rtpmap:99 VP9/90000
a=fmtp:99 max-fs=3600; max-fr=30
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42401f; packetization-mode=0
a=rtpmap:101 H264/90000
a=fmtp:101 profile-level-id=42401f; packetization-mode=1
a=rtpmap:102 H264/90000
a=fmtp:102 profile-level-id=640c1f; packetization-mode=0
a=rtpmap:103 H264/90000
a=fmtp:103 profile-level-id=640c1f; packetization-mode=1
a=rtpmap:104 H264-SVC/90000
a=fmtp:104 profile-level-id=530c1f
a=rtpmap:105 H264-SVC/90000
a=fmtp:105 profile-level-id=560c1f
a=rtpmap:106 H265/90000
a=fmtp:106 profile-id=1; level-id=93
a=rtpmap:107 H265/90000
a=fmtp:107 profile-id=2; level-id=93
a=sendrecv
a=mid:v1 (max resolution)
a=rid:1 send pt=*; max-width=1280; max-height=720; max-fps=30
a=rid:2 recv pt=*; max-width=1280; max-height=720; max-fps=30
...
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
...same rtpmap/fmtp as above...
a=recvonly
a=mid:v2 (medium resolution)
a=rid:3 recv pt=*; max-width=640; max-height=360; max-fps=15
...
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
...same rtpmap/fmtp as above...
a=recvonly
a=mid:v3 (medium resolution)
a=rid:3 recv pt=*; max-width=640; max-height=360; max-fps=15
...
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
...same rtpmap/fmtp as above...
a=recvonly
a=mid:v4 (small resolution)
a=rid:4 recv pt=*; max-width=320; max-height=180; max-fps=15
...
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
...same rtpmap/fmtp as above...
...same rid:4 as above for mid:v5,v6,v7 (small resolution)...
...
Answer:
...same as offer but swap send/recv...
]]></artwork></figure>
</section>
<section anchor="simulcast" title="Simulcast">
<t>Adding simulcast to the above example allows the mixer to selectively forward streams like an SFU rather than transcode high resolutions to lower ones. Simulcast encodings can be expressed using PTs or RIDs. Using PTs can exhaust the primary dynamic space even faster in simulcast scenarios. So RIDs are used to avoid PT exhaustion and express the encoding constraints. In the example below, 3 resolutions are offered to be sent as simulcast to a mixer/SFU.</t>
<figure><artwork><![CDATA[
Example 2
Offer:
...
m=audio ... same as from Example 1 ..
...
m=video ...same as from Example 1 ...
...same rtpmap/fmtp as above...
a=sendrecv
a=mid:v1 (max resolution)
a=rid:1 send pt=*; max-width=1280; max-height=720; max-fps=30
a=rid:2 recv pt=*; max-width=1280; max-height=720; max-fps=30
a=rid:5 send pt=*; max-width=640; max-height=360; max-fps=15
a=rid:6 send pt=*; max-width=320; max-height=180; max-fps=15
a=simulcast: send rid=1;5;6 recv rid=2
...
...same m=video sections as Example 1 for mid:v2-v7...
...
Answer:
...same as offer but swap send/recv...
]]></artwork></figure>
</section>
<section anchor="scalable-layers" title="Scalable Layers">
<t>Adding scalable layers to the above simulcast example gives the SFU further flexibility to selectively forward packets from a source that best match the bandwidth and capabilities of diverse receivers. Scalable encodings have dependencies between layers, unlike independent simulcast streams. RIDs can be used to express these dependencies using the “depend” parameter. In the example below, the highest resolution is offered to be sent as 2 scalable temporal layers (using MRST).</t>
<figure><artwork><![CDATA[
Example 3
Offer:
...
m=audio ...same as Example 1 ...
...
m=video ...same as Example 1 ...
...same rtpmap/fmtp as Example 1...
a=sendrecv
a=mid:v1 (max resolution)
a=rid:0 send pt=*; max-width=1280; max-height=720; max-fps=15
a=rid:1 send pt=*; max-width=1280; max-height=720; max-fps=30; depend=0
a=rid:2 recv pt=*; max-width=1280; max-height=720; max-fps=30
a=rid:5 send pt=*; max-width=640; max-height=360; max-fps=15
a=rid:6 send pt=*; max-width=320; max-height=180; max-fps=15
a=simulcast: send rid=0;1;5;6 recv rid=2
...
...same m=video sections as Example1 for mid:v2-v7...
...
Answer:
...same as offer but swap send/recv...
]]></artwork></figure>
</section>
<section anchor="simulcast-with-payload-types" title="Simulcast with Payload Types">
<t>This example shows a simulcast Offer SDP that uses rid framework to
identify:</t>
<t><list style="symbols">
<t>1 send stream at max resolution,</t>
<t>1 recv stream at max resolution,</t>
<t>1 recv stream at low resolution</t>
</list></t>
<t>and includes 2 “a=simulcast” lines to identify the simulcast streams
with the Payload Types and rid-identifier respectively.</t>
<t><list style='empty'>
<t>Note: The exact rules for the usage of rid framework with simulcast
is still a work in progress.</t>
</list></t>
<figure><artwork><![CDATA[
Example 4
Offer:
m=video 10000 RTP/AVP 97 98
a=rtpmap:97 VP8/90000
a=rtpmap:98 VP8/90000
a=fmtp:97 max-fs=3600
a=fmtp:98 max-fs=3600
a=rid:1 send pt=97; max-br=; max-height=720;
a=rid:2 recv pt=97; max-width=1280; max-height=720
a=rid:3 recv pt=98; max-width=320; max-height=180
a=simulcast send pt=97 recv pt=*
a=simulcast: send rid=1 recv rid=2;3
]]></artwork></figure>
</section>
</section>
<section anchor="open-issues" title="Open Issues">
<section anchor="name-of-the-identifier" title="Name of the identifier">
<t>The name ‘rid’ is provisionally used and is open for further discussion.</t>
<t>Here are the few options that were considered while writing this draft</t>
<t><list style="symbols">
<t>ESID: Encoded Stream ID, does not align well with taxonomy which defines Encoded Stream as before RTP packetization.</t>
<t>RSID or RID: RTP Stream ID, aligns better with taxonomy but very vague.</t>
<t>LID: Layer ID, aligns well for SVC with each layer in a separate stream, but not for other SVC layerings or independent simulcast which is awkward to view as layers.</t>
<t>EPT or XPT: EXtended Payload Type, conveys XPT.PT usage well, but may be confused with PT, for example people may mistakenly think they can use it in other places where PT would normally be used.</t>
</list></t>
</section>
</section>
<section anchor="sec-iana" title="IANA Considerations">
<section anchor="new-rtp-header-extension-uri" title="New RTP Header Extension URI">
<t>This document defines a new extension URI in the RTP Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data:</t>
<figure><artwork><![CDATA[
Extension URI: urn:ietf:params:rtp-hdrext:rid
Description: RTP Stream Identifier
Contact: <name@email.com>
Reference: RFCXXXX
]]></artwork></figure>
</section>
<section anchor="new-sdp-media-level-attribute" title="New SDP Media-Level attribute">
<t>This document defines “rid” as SDP media-level attribute. This attribute must be registered by IANA under “Session Description Protocol (SDP) Parameters” under “att-field (media level only)”.</t>
<t>The “rid” attribute is used to identify characteristics of RTP stream
with in a RTP Session. Its format is defined in Section XXXX.</t>
</section>
<section anchor="registry-for-rid-level-attributes" title="Registry for RID-Level Attributes">
<t>This specification creates a new IANA registry named “att-field (rid level)” within the SDP parameters registry. The rid-level attributes MUST be registered with IANA and documented under the same rules as for SDP session-level and media-level attributes as specified in <xref target="RFC4566"></xref>.</t>
<t>New attribute registrations are accepted according to the “Specification Required” policy of [RFC5226], provided that the specification includes the following information:</t>
<t><list style="symbols">
<t>contact name, email address, and telephone number</t>
<t>attribute name (as it will appear in SDP)</t>
<t>long-form attribute name in English</t>
<t>whether the attribute value is subject to the charset attribute</t>
<t>a one-paragraph explanation of the purpose of the attribute</t>
<t>a specification of appropriate attribute values for this attribute</t>
</list></t>
<t>The initial set of rid-level attribute names, with definitions in Section XXXX of this document, is given below</t>
<figure><artwork><![CDATA[
Type SDP Name Reference
---- ------------------ ---------
att-field (rid level)
max-width [RFCXXXX]
max-height [RFCXXXX]
max-fps [RFCXXXX]
max-fs [RFCXXXX]
max-br [RFCXXXX]
max-pps [RFCXXXX]
depend [RFCXXXX]
]]></artwork></figure>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>TODO</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>Many thanks to review from Cullen Jennings, Magnus Westerlund.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC3264' target='http://www.rfc-editor.org/info/rfc3264'>
<front>
<title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<date year='2002' month='June' />
<abstract><t>This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3264'/>
<seriesInfo name='DOI' value='10.17487/RFC3264'/>
</reference>
<reference anchor='RFC3550' target='http://www.rfc-editor.org/info/rfc3550'>
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<author initials='S.' surname='Casner' fullname='S. Casner'><organization /></author>
<author initials='R.' surname='Frederick' fullname='R. Frederick'><organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /></author>
<date year='2003' month='July' />
<abstract><t>This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='64'/>
<seriesInfo name='RFC' value='3550'/>
<seriesInfo name='DOI' value='10.17487/RFC3550'/>
</reference>
<reference anchor='RFC4566' target='http://www.rfc-editor.org/info/rfc4566'>
<front>
<title>SDP: Session Description Protocol</title>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'><organization /></author>
<date year='2006' month='July' />
<abstract><t>This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4566'/>
<seriesInfo name='DOI' value='10.17487/RFC4566'/>
</reference>
<reference anchor='RFC5234' target='http://www.rfc-editor.org/info/rfc5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker' role='editor'><organization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'><organization /></author>
<date year='2008' month='January' />
<abstract><t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='68'/>
<seriesInfo name='RFC' value='5234'/>
<seriesInfo name='DOI' value='10.17487/RFC5234'/>
</reference>
<reference anchor='RFC5285' target='http://www.rfc-editor.org/info/rfc5285'>
<front>
<title>A General Mechanism for RTP Header Extensions</title>
<author initials='D.' surname='Singer' fullname='D. Singer'><organization /></author>
<author initials='H.' surname='Desineni' fullname='H. Desineni'><organization /></author>
<date year='2008' month='July' />
<abstract><t>This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5285'/>
<seriesInfo name='DOI' value='10.17487/RFC5285'/>
</reference>
<reference anchor='I-D.ietf-avtext-rtp-grouping-taxonomy'>
<front>
<title>A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources</title>
<author initials='J' surname='Lennox' fullname='Jonathan Lennox'>
<organization />
</author>
<author initials='K' surname='Gross' fullname='Kevin Gross'>
<organization />
</author>
<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
<organization />
</author>
<author initials='G' surname='Salgueiro' fullname='Gonzalo Salgueiro'>
<organization />
</author>
<author initials='B' surname='Burman' fullname='Bo Burman'>
<organization />
</author>
<date month='July' day='20' year='2015' />
<abstract><t>The terminology about, and associations among, Real-Time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed properties and relationships among RTP sources, and defines common terminology for discussing protocol entities and their relationships.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-avtext-rtp-grouping-taxonomy-08' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-avtext-rtp-grouping-taxonomy-08.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor='RFC5888' target='http://www.rfc-editor.org/info/rfc5888'>
<front>
<title>The Session Description Protocol (SDP) Grouping Framework</title>
<author initials='G.' surname='Camarillo' fullname='G. Camarillo'><organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author>
<date year='2010' month='June' />
<abstract><t>In this specification, we define a framework to group "m" lines in the Session Description Protocol (SDP) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. This document obsoletes RFC 3388. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5888'/>
<seriesInfo name='DOI' value='10.17487/RFC5888'/>
</reference>
<reference anchor='I-D.ietf-mmusic-sdp-bundle-negotiation'>
<front>
<title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title>
<author initials='C' surname='Holmberg' fullname='Christer Holmberg'>
<organization />
</author>
<author initials='H' surname='Alvestrand' fullname='Harald Alvestrand'>
<organization />
</author>
<author initials='C' surname='Jennings' fullname='Cullen Jennings'>
<organization />
</author>
<date month='July' day='20' year='2015' />
<abstract><t>This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media, referred to as bundled media, associated with multiple SDP media descriptions ("m=" lines). To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific media description.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-sdp-bundle-negotiation-23' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bundle-negotiation-23.txt' />
</reference>
<reference anchor='I-D.ietf-mmusic-sdp-simulcast'>
<front>
<title>Using Simulcast in SDP and RTP Sessions</title>
<author initials='B' surname='Burman' fullname='Bo Burman'>
<organization />
</author>
<author initials='M' surname='Westerlund' fullname='Magnus Westerlund'>
<organization />
</author>
<author initials='S' surname='Nandakumar' fullname='Suhas Nandakumar'>
<organization />
</author>
<author initials='M' surname='Zanaty' fullname='Mo Zanaty'>
<organization />
</author>
<date month='July' day='21' year='2015' />
<abstract><t>In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in independent RTP streams. This is called simulcast. This document discusses the best way of accomplishing simulcast in RTP and how to signal it in SDP. A solution is defined by making an extension to SDP, and using RTP/RTCP identification methods to relate RTP streams belonging to the same media source. The SDP extension consists a new media level SDP attribute that express capability to send and/or receive simulcast RTP streams. One part of the RTP/RTCP identification method is included as a reference to a separate document, since it is useful also for other purposes.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-mmusic-sdp-simulcast-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-simulcast-01.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:33:43 |