draft-ietf-mmusic-rid-00.txt   draft-ietf-mmusic-rid-01.txt 
Network Working Group P. Thatcher Network Working Group P. Thatcher
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track M. Zanaty Intended status: Standards Track M. Zanaty
Expires: May 14, 2016 S. Nandakumar Expires: August 4, 2016 S. Nandakumar
Cisco Systems Cisco Systems
B. Burman B. Burman
Ericsson Ericsson
A. Roach A. Roach
B. Campen B. Campen
Mozilla Mozilla
November 11, 2015 February 01, 2016
RTP Payload Format Constraints RTP Payload Format Constraints
draft-ietf-mmusic-rid-00 draft-ietf-mmusic-rid-01
Abstract Abstract
In this specification, we define a framework for identifying Source In this specification, we define a framework for identifying RTP
RTP Streams with the constraints on its payload format in the Session Streams with the constraints on its payload format in the Session
Description Protocol. This framework uses "rid" SDP attribute to: a) Description Protocol. This framework defines a new "rid" SDP
effectively identify the Source RTP Streams within a RTP Session, b) attribute to: a) effectively identify the RID RTP Streams within a
constrain their payload format parameters in a codec-agnostic way RTP Session, b) constrain their payload format parameters in a codec-
beyond what is provided with the regular Payload Types and c) enable agnostic way beyond what is provided with the regular Payload Types
unambiguous mapping between the Source RTP Streams to their media and c) enable unambiguous mapping between the RID RTP Streams to
format specification in the SDP. their media format specification in the SDP.
Note-1: The name 'rid' is not yet finalized. Please refer to
Section 12 for more details on the naming.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 14, 2016. This Internet-Draft will expire on August 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Key Words for Requirements . . . . . . . . . . . . . . . . . 4 2. Key Words for Requirements . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. SDP "a=rid" Media Level Attribute . . . . . . . . . . . . . . 4
5. SDP 'rid' Media Level Attribute . . . . . . . . . . . . . . . 5 5. "a=rid" constraints . . . . . . . . . . . . . . . . . . . . . 5
6. 'rid-level' constraints . . . . . . . . . . . . . . . . . . . 6 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7
7. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 6.1. Generating the Initial SDP Offer . . . . . . . . . . . . 7
7.1. Generating the Initial SDP Offer . . . . . . . . . . . . 7 6.2. Answerer processing the SDP Offer . . . . . . . . . . . . 8
7.2. Answerer processing the SDP Offer . . . . . . . . . . . . 8 6.2.1. 'rid' unaware Answerer . . . . . . . . . . . . . . . 8
7.2.1. 'rid' unaware Answerer . . . . . . . . . . . . . . . 8 6.2.2. 'rid' aware Answerer . . . . . . . . . . . . . . . . 8
7.2.2. 'rid' aware Answerer . . . . . . . . . . . . . . . . 8 6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 9
7.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 9 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10
7.4. Offering Processing of the SDP Answer . . . . . . . . . . 10 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 11
7.5. Modifying the Session . . . . . . . . . . . . . . . . . . 10 7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 11
8. Usage of 'rid' in RTP and RTCP . . . . . . . . . . . . . . . 10 8. Interaction with Other Techniques . . . . . . . . . . . . . . 11
8.1. RTCP 'RID' SDES Extension . . . . . . . . . . . . . . . . 11 9. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. RTP 'rid' Header Extension . . . . . . . . . . . . . . . 11 10. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Interaction with Other Techniques . . . . . . . . . . . . . . 12 10.1. Many Bundled Streams using Many Codecs . . . . . . . . . 13
10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 12 10.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 15
11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 14 11.1. Declarative SDP . . . . . . . . . . . . . . . . . . . . 16
11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 16 11.2. Definition of bitrate . . . . . . . . . . . . . . . . . 16
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.3. Escaping new constraint values . . . . . . . . . . . . . 16
12.1. Name of the identifier . . . . . . . . . . . . . . . . . 16 11.4. Utility of max-width and max height . . . . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11.5. Definition of max-fps . . . . . . . . . . . . . . . . . 17
13.1. New RTP Header Extension URI . . . . . . . . . . . . . . 17 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13.2. New SDES item . . . . . . . . . . . . . . . . . . . . . 17 12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 18
13.3. New SDP Media-Level attribute . . . . . . . . . . . . . 18 12.2. Registry for RID-Level Parameters . . . . . . . . . . . 18
13.4. Registry for RID-Level Parameters . . . . . . . . . . . 18 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19
14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 15.1. Normative References . . . . . . . . . . . . . . . . . . 19
16.1. Normative References . . . . . . . . . . . . . . . . . . 20 15.2. Informative References . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Payload Type (PT) in RTP provides mapping between the format of the Payload Type (PT) in RTP provides a mapping between the format of the
RTP payload and the media format description specified in the RTP payload and the media format description specified in the
signaling. For applications that use SDP for signaling, the signaling. For applications that use SDP for signaling, the
constructs rtpmap and/or fmtp describe the characteristics of the constructs rtpmap and/or fmtp describe the characteristics of the
media that is carried in the RTP payload, mapped to a given PT. media that is carried in the RTP payload, mapped to a given PT.
Recent advances in standards such as RTCWEB and NETVC have given rise Recent advances in standards have given rise to rich multimedia
to rich multimedia applications requiring support for multiple RTP applications requiring support for multiple RTP Streams within a RTP
Streams with in a RTP session session [I-D.ietf-mmusic-sdp-bundle-negotiation],
[I-D.ietf-mmusic-sdp-bundle-negotiation], [I-D.ietf-mmusic-sdp-simulcast] or having to support a large number
[I-D.ietf-mmusic-sdp-simulcast] or having to support multiple codecs, of codecs. These demands have unearthed challenges inherent with:
for example. These demands have unearthed challenges inherent with:
o The restricted RTP PT space in specifying the various payload o The restricted RTP PT space in specifying the various payload
configurations, configurations,
o The codec-specific constructs for the payload formats in SDP, o The codec-specific constructs for the payload formats in SDP,
o Missing or underspecied payload format parameters, o Missing or underspecified payload format parameters,
o Ambiguity in mapping between the individual Source RTP Streams and o Overloading of PTs to indicate not just codec configurations, but
their equivalent format specification in the SDP. individual streams within an RTP session.
To expand on these points: [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
constraints on payload configurations and to effectively map a RID
RTP Stream to its corresponding constraints. This issue is
exacerbated by the increase in techniques such as simulcast and
layered codecs, which introduce additional streams into RTP Sessions.
This specification defines a new SDP framework for constraining This specification defines a new SDP framework for constraining
Source RTP Streams (Section 2.1.10 Source RTP Streams (Section 2.1.10
[I-D.ietf-avtext-rtp-grouping-taxonomy]), called "Restriction [I-D.ietf-avtext-rtp-grouping-taxonomy]), along with the SDP
Identifier (rid)", along with the SDP attributes to constrain their attributes to constrain payload formats in a codec-agnostic way.
payload formats in a codec-agnostic way. The "rid" framework can be This framework can be thought of as complementary extension to the
thought of as complementary extension to the way the media format way the media format parameters are specified in SDP today, via the
parameters are specified in SDP today, via the "a=fmtp" attribute. "a=fmtp" attribute.
This specification also proposes a new RTCP SDES item to carry the
"rid" value, to provide correlation between the RTP Packets and their
format specification in the SDP. This SDES item also uses the header
extension mechanism [I-D.ietf-avtext-sdes-hdr-ext] to provide
correlation at stream startup, or stream changes where RTCP isn't
sufficient.
Note that the "rid" parameters only serve to further constrain the This specification makes use of the RTP Stream Identifier SDES RTCP
parameters that are established on a PT format. They do not relax item defined in [I-D.roach-avtext-rid] to provide correlation
any existing constraints. between the RTP Packets and their format specification in the SDP.
As described in Section 7.2.1, this mechanism achieves backwards The additional constraints on individual streams are indicated with a
new "a=rid" SDP attribute. Note that the parameters communicated via
this attribute only serve to further constrain the parameters that
are established on a PT format. They do not relax any existing
constraints.
As described in Section 6.2.1, this mechanism achieves backwards
compatibility via the normal SDP processing rules, which require compatibility via the normal SDP processing rules, which require
unknown a= parameters to be ignored. This means that implementations unknown a= parameters to be ignored. This means that implementations
need to be prepared to handle successful offers and answers from need to be prepared to handle successful offers and answers from
other implementations that neither indicate nor honor the constraints other implementations that neither indicate nor honor the constraints
requested by this mechanism. requested by this mechanism.
Further, as described in Section 7 and its subsections, this Further, as described in Section 6 and its subsections, this
mechanism achieves extensibility by: (a) having offerers include all mechanism achieves extensibility by: (a) having offerers include all
supported constraints in their offer, abd (b) having answerers ignore supported constraints in their offer, abd (b) having answerers ignore
a=rid lines that specify unknown constraints. "a=rid" lines that specify unknown constraints.
2. Key Words for Requirements 2. Key Words for Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119]
3. Terminology 3. Terminology
The terms Source RTP Stream, Endpoint, RTP Session, and RTP Stream The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP
are used as defined in [I-D.ietf-avtext-rtp-grouping-taxonomy]. Stream" are used as defined in
[I-D.ietf-avtext-rtp-grouping-taxonomy].
[RFC4566] and [RFC3264] terminology is also used where appropriate.
4. Motivation
This section summarizes several motivations for proposing the "rid"
framework.
1. RTP PT Space Exhaustion: [RFC3550] defines payload type (PT) that The term "RID RTP Stream" is used as defined in
identifies the format of the RTP payload and determine its [I-D.roach-avtext-rid].
interpretation by the application. [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
constraints on payload configurations and to effectively map a
Source RTP Stream to its corresponding constraints.
1. Multi-source and Multi-stream Use Cases: Recently, there is a [RFC4566] and [RFC3264] terminology is also used where appropriate.
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.
5. SDP 'rid' Media Level Attribute 4. SDP "a=rid" Media Level Attribute
This section defines new SDP media-level attribute [RFC4566], This section defines new SDP media-level attribute [RFC4566],
"a=rid". Roughly speaking, this attribute takes the following form "a=rid". Roughly speaking, this attribute takes the following form
(see Section 10 for a formal definition). (see Section 9 for a formal definition).
a=rid:<rid-identifier> <direction> [pt=<fmt-list>;]<constraint>=<value>... a=rid:<rid-identifier> <direction> [pt=<fmt-list>;]<constraint>=<value>...
A given "a=rid" SDP media attribute specifies constraints defining an An "a=rid" SDP media attribute specifies constraints defining a
unique RTP payload configuration identified via the "rid-identifier". unique RTP payload configuration identified via the "rid-identifier".
A set of codec-agnostic "rid-level" constraints are defined This value binds the restriction to the RID RTP Stream identified by
(Section 6) that describe the media format specification applicable its RID SDES item [I-D.roach-avtext-rid].
to one or more Payload Types speicified by the "a=rid" line.
The 'rid' framework MAY be used in combination with the 'a=fmtp' SDP The "direction" parameter identifies the directionality of the RID
attribute for describing the media format parameters for a given RTP RTP Stream; it may be either "send" or "recv".
Payload Type. However in such scenarios, the 'rid-level' constraints
(Section 6) further constrains the equivalent 'fmtp' attributes.
The 'direction' identifies the either 'send', 'recv' directionality The optional "pt" parameter lists one or more PT values that can be
of the Source RTP Stream. used in the associated RID RTP Stream. If the parameter is absent,
then any of the PT values specified in the corresponding "m=" line
may be used.
The list of zero or more codec-agnostic "constraint" parameters
(Section 5) describe the restrictions that the corresponding RID RTP
Stream will conform to.
This framework MAY be used in combination with the "a=fmtp" SDP
attribute for describing the media format parameters for a given RTP
Payload Type. In such scenarios, the "a=rid" constraints (Section 5)
further constrain the equivalent "a=fmtp" attributes.
A given SDP media description MAY have zero or more "a=rid" lines A given SDP media description MAY have zero or more "a=rid" lines
describing various possible RTP payload configurations. A given describing various possible RTP payload configurations. A given
'rid-identifier' MUST NOT be repeated in a given media description. "rid-identifier" MUST NOT be repeated in a given media description
("m=" section).
The 'rid' media attribute MAY be used for any RTP-based media
transport. It is not defined for other transports.
Though the 'rid-level' attributes specified by the 'rid' property The "a=rid" media attribute MAY be used for any RTP-based media
follow the syntax similar to session-level and media-level transport. It is not defined for other transports, although other
attributes, they are defined independently. All 'rid-level' documents may extend its semantics for such transports.
attributes MUST be registered with IANA, using the registry defined
in Section 13
Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] Though the parameters specified by the "rid" constraints follow a
grammar for the "rid" attribute. syntax similar to session-level and media-level attributes, they are
defined independently. All "rid" parameters MUST be registered with
IANA, using the registry defined in Section 12
The "a=rid" media attribute is not dependent on charset. Section 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234]
grammar for the "rid" attribute. The "a=rid" media attribute is not
dependent on charset.
6. 'rid-level' constraints 5. "a=rid" constraints
This section defines the 'rid-level' constraints that can be used to This section defines the "a=rid" constraints that can be used to
constrain the RTP payload encoding format in a codec-agnostic way. restrict the RTP payload encoding format in a codec-agnostic way.
The following constraints are intended to apply to video codecs in a The following constraints are intended to apply to video codecs in a
codec-independent fashion. codec-independent fashion.
o max-width, for spatial resolution in pixels. In the case that o max-width, for spatial resolution in pixels. In the case that
stream orientation signaling is used to modify the intended stream orientation signaling is used to modify the intended
display orientation, this attribute refers to the width of the display orientation, this attribute refers to the width of the
stream when a rotation of zero degrees is encoded. stream when a rotation of zero degrees is encoded.
o max-height, for spatial resolution in pixels. In the case that o max-height, for spatial resolution in pixels. In the case that
skipping to change at page 6, line 49 skipping to change at page 6, line 41
the total number of bits in the payload portion of RTP SHOULD NOT the total number of bits in the payload portion of RTP SHOULD NOT
exceed the value specified in "max-br." exceed the value specified in "max-br."
o max-pps, for pixel rate in pixels per second. This value SHOULD o max-pps, for pixel rate in pixels per second. This value SHOULD
be handled identically to max-fps, after performing the following be handled identically to max-fps, after performing the following
conversion: max-fps = max-pps / (width * height). If the stream conversion: max-fps = max-pps / (width * height). If the stream
resolution changes, this value is recalculated. Due to this resolution changes, this value is recalculated. Due to this
recalculation, excursions outside the specified maximum are recalculation, excursions outside the specified maximum are
possible during near resolution change boundaries. possible during near resolution change boundaries.
All the constraints are optional and are subjected to negotiation o max-bpp, for maximum number of bits per pixel, calculated as an
based on the SDP Offer/Answer rules described in Section 7 average of all samples of any given coded picture. This is
This list is intended to be an initial set of constraints; future expressed as a floating point value, with an allowed range of
documents may define additional constraints; see Section 13.4. While 0.0001 to 48.0.
this document doesn't define constraints for audio codecs, there is
All the constraints are optional and are subject to negotiation based
on the SDP Offer/Answer rules described in Section 6.
This list is intended to be an initial set of constraints. Future
documents may define additional constraints; see Section 12.2. While
this document does not define constraints for audio codecs, there is
no reason such constraints should be precluded from definition and no reason such constraints should be precluded from definition and
registration by other documents. registration by other documents.
Section 10 provides formal Augmented Backus-Naur Form(ABNF) [RFC5234] Section 9 provides formal Augmented Backus-Naur Form(ABNF) [RFC5234]
grammar for each of the "rid-level" attributes defined in this grammar for each of the "a=rid" attributes defined in this section.
section.
7. SDP Offer/Answer Procedures 6. SDP Offer/Answer Procedures
This section describes the SDP Offer/Answer [RFC3264] procedures when This section describes the SDP Offer/Answer [RFC3264] procedures when
using the 'rid' framework. using this framework.
Note that 'rid's are only required to be unique within a media Note that "rid-identifier" values are only required to be unique
section ("m-line"); they do not necessarily need to be unique within within a media section ("m-line"); they do not necessarily need to be
an entire RTP session. In traditional usage, each media section is unique within an entire RTP session. In traditional usage, each
sent on its own unique 5-tuple, which provides an unambiguous scope. media section is sent on its own unique 5-tuple, which provides an
Similarly, when using BUNDLE unambiguous scope. Similarly, when using BUNDLE
[I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP
streams uniquely to a single media description. streams uniquely to a single media description.
7.1. Generating the Initial SDP Offer 6.1. Generating the Initial SDP Offer
For each media description in the offer, the offerer MAY choose to For each media description in the offer, the offerer MAY choose to
include one or more "a=rid" lines to specify a configuration profile include one or more "a=rid" lines to specify a configuration profile
for the given set of RTP Payload Types. for the given set of RTP Payload Types.
In order to construct a given "a=rid" line, the offerer must follow In order to construct a given "a=rid" line, the offerer must follow
the below steps: these steps:
1. It MUST generate a 'rid-identifier' that is unique within a media 1. It MUST generate a "rid-identifier" that is unique within a media
description description
2. It MUST set the direction for the 'rid-identifier' to one of 2. It MUST set the direction for the "rid-identifier" to one of
'send' or 'recv' "send" or "recv"
3. It MAY include a listing of SDP format tokens (usually 3. It MAY include a listing of SDP format tokens (usually
corresponding to RTP payload types) to which the constraints corresponding to RTP payload types) allowed to appear in the RID
expressed by the 'rid-level' attributes apply. Any Payload Types RTP Stream. Any Payload Types chosen MUST be a valid payload
chosen MUST be a valid payload type for the media section (that type for the media section (that is, it must be listed on the
is, it must be listed on the "m=" line). "m=" line). The order of the listed formats is significant; the
alternatives are listed from (left) most preferred to (right)
least preferred. When using RID, this preference overrides the
normal codec preference as expressed by format type ordering on
the "m="-line, using regular SDP rules.
4. The Offerer then chooses the 'rid-level' constraints (Section 6) 4. The Offerer then chooses zero or more "a=rid" constraints
to be applied for the rid, and adds them to the "a=rid" line. If (Section 5) to be applied to the rid, and adds them to the
it wishes the answer to have the ability to specify a constraint, "a=rid" line.
but does not wish to set a value itself, it MUST include the name
of the constraint in the "a=rid" line, but without any indicated
value.
Note: If an 'a=fmtp' attribute is also used to provide media-format- 5. If the offerer wishes the answerer to have the ability to specify
specific parameters, then the 'rid-level' attributes will further a constraint, but does not wish to set a value itself, it MUST
constrain the equivalent 'fmtp' parameters for the given Payload Type include the name of the constraint in the "a=rid" line, but
for those streams associated with the 'rid'. without any indicated value.
If a given codec would require "a=fmtp" line when used without Note: If an "a=fmtp" attribute is also used to provide media-format-
specific parameters, then the "a=rid" attributes will further
constrain the equivalent "a=fmtp" parameters for the given Payload
Type for the specified RID RTP Stream.
If a given codec would require an "a=fmtp" line when used without
"a=rid" then the offer MUST include a valid corresponding "a=fmtp" "a=rid" then the offer MUST include a valid corresponding "a=fmtp"
line even when using RID. line even when using "a=rid".
7.2. Answerer processing the SDP Offer 6.2. Answerer processing the SDP Offer
For each media description in the offer, and for each "a=rid" For each media description in the offer, and for each "a=rid"
attribute in the media description, the receiver of the offer will attribute in the media description, the receiver of the offer will
perform the following steps: perform the following steps:
7.2.1. 'rid' unaware Answerer 6.2.1. 'rid' unaware Answerer
If the receiver doesn't support the 'rid' framework proposed in this If the receiver doesn't support the framework proposed in this
specification, the entire "a=rid" line is ignored following the specification, the entire "a=rid" line is ignored following the
standard [RFC3264] Offer/Answer rules. standard [RFC3264] Offer/Answer rules.
Section 7.1 requires the offer to include a valid "a=fmtp" line for Section 6.1 requires the offer to include a valid "a=fmtp" line for
any codecs that otherwise require it (in other words, the "a=rid" any codecs that otherwise require it (in other words, the "a=rid"
line cannot be used to replace "a=fmtp" configuration). As a result, line cannot be used to replace "a=fmtp" configuration). As a result,
ignoring the "a=rid" line is always guaranteed to result in a valid ignoring the "a=rid" line is always guaranteed to result in a valid
session description. session description.
7.2.2. 'rid' aware Answerer 6.2.2. 'rid' aware Answerer
If the answerer supports 'rid' framework, the following steps are If the answerer supports the "a=rid" attribute, the following steps
executed, in order, for each "a=rid" line in a given media are executed, in order, for each "a=rid" line in a given media
description: description:
1. Extract the rid-identifier from the "a=rid" line and verify its 1. Extract the rid-identifier from the "a=rid" line and verify its
uniqueness. In the case of a duplicate, the entire "a=rid" line, uniqueness. In the case of a duplicate, the entire "a=rid" line,
and all "a=rid" lines with rid-identifiers that duplicate this and all "a=rid" lines with rid-identifiers that duplicate this
line, are rejected and MUST NOT be included in the SDP Answer. line, are rejected and MUST NOT be included in the SDP Answer.
2. If the "a=rid" line contains a "pt=" parameter, the list of 2. If the "a=rid" line contains a "pt=" parameter, the list of
payload types is verified against the list of valid payload types payload types is verified against the list of valid payload types
for the media section (that is, those listed on the "m=" line). for the media section (that is, those listed on the "m=" line).
If there is no match for the Payload Type listed in the "a=rid" Any PT missing from the "m=" line is removed from the "pt="
line, then remove the "a=rid" line. parameter.
3. The answerer ensures that "rid-level" parameters listed are 3. The answerer ensures that "a=rid" parameters listed are
supported and syntactically well formed. In the case of a syntax syntactically well formed. In the case of a syntax error, the
error or an unsupported parameter, the "a=rid" line is removed. "a=rid" line is removed.
4. If the 'depend' rid-level attribute is included, the answerer 4. If the "direction" parameter is "recv", The answerer ensures that
MUST make sure that the rid-identifiers listed unambiguously "a=rid" parameters are supported. In the case of an unsupported
match the rid-identifiers in the SDP offer. Any lines that do parameter, the "a=rid" line is removed.
not are removed.
5. if the "a=rid" line contains a "pt=" parameter, the answerer 5. If the "depend" parameter is included, the answerer MUST make
verifies that the attribute values provided in the "rid-level" sure that the listed rid-identifiers unambiguously match the rid-
attributes are consistent with the corrsponding codecs and their identifiers in the SDP offer. Any lines that do not are removed.
other parameters. See Section 9 for more detail. If the rid-
level parameters are incompatible with the other codec
properties, then the "a=rid" line is removed.
7.3. Generating the SDP Answer 6. The answerer verifies that the constraining parameters are
consistent with at least one of the codecs to be used with the
RID RTP Stream. If the "a=rid" line contains a "pt=" parameter,
it contains the list of such codecs; otherwise, the list of such
codecs is taken from the associated "m=" line. See Section 8 for
more detail. If the "a=rid" parameters are incompatible with the
other codec properties for all codecs, then the "a=rid" line is
removed.
Having performed the verification of the SDP offer as described, the Note that the answerer does not need to understand every constraint
present in a "send" line: if a stream sender constrains the stream in
a way that the receiver does not understand, this causes no issues
with interoperability.
6.3. Generating the SDP Answer
Having performed verification of the SDP offer as described, the
answerer shall perform the following steps to generate the SDP answerer shall perform the following steps to generate the SDP
answer. answer.
For each "a=rid" line: For each "a=rid" line:
1. The answerer MAY choose to modify specific 'rid-level' attribute 1. The sense of of the "direction" parameter is reversed: "send" is
changed to "recv", and "recv" is changed to "send".
2. The answerer MAY choose to modify specific "a=rid" constraint
value in the answer SDP. In such a case, the modified value MUST value in the answer SDP. In such a case, the modified value MUST
be more constrained than the ones specified in the offer. The be more constrained than the ones specified in the offer. The
answer MUST NOT include any constraints that were not present in answer MUST NOT include any constraints that were not present in
the offer. the offer.
2. The answerer MUST NOT modify the 'rid-identifier' present in the 3. The answerer MUST NOT modify the "rid-identifier" present in the
offer. offer.
3. The answerer is allowed to remove one or more media formats from 4. If the "a=rid" line contains a "pt=" parameter, the answerer is
a given 'a=rid' line. If the answerer chooses to remove all the allowed to remove one or more media formats from a given "a=rid"
media format tokens from an "a=rid" line, the answerer MUST line. If the answerer chooses to remove all the media format
remove the entire "a=rid" line. tokens from an "a=rid" line, the answerer MUST remove the entire
"a=rid" line. If the offer did not contain a "pt=" parameter for
a given "a=rid" line, then the answer MUST NOT contain a "pt="
parameter in the corresponding line.
4. In cases where the answerer is unable to support the payload 5. In cases where the answerer is unable to support the payload
configuration specified in a given "a=rid" line in the offer, the configuration specified in a given "a=rid" line in the offer, the
answerer MUST remove the corresponding "a=rid" line. This answerer MUST remove the corresponding "a=rid" line. This
includes situations in which the answerer does not understand one includes situations in which the answerer does not understand one
or more of the constraints in the "a=rid" line that has an or more of the constraints in an "a=rid" line with a direction of
associated value. "recv".
Note: in the case that the answerer uses different PT values to Note: in the case that the answerer uses different PT values to
represent a codec than the offerer did, the "a=rid" values in the represent a codec than the offerer did, the "a=rid" values in the
answer use the PT values that were sent in the offer. answer use the PT values that are present in its answer.
7.4. Offering Processing of the SDP Answer
The offerer shall follow the steps similar to answerer's offer
processing with the following exceptions
1. 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.
2. 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.
3. If the SDP answer contains any "rid-identifier" that doesn't
match with the offer, the offerer MUST ignore the corresponding
"a=rid" line.
4. If the "a=rid" line contains a "pt=" parameter, the offerer
verifies that the list of payload types is a subset of those sent
in the corresponding "a=rid" line in the offer.
5. If the "a=rid" line contains a "pt=" parameter, the offerer 6.4. Offerer Processing of the SDP Answer
verifies that the attribute values provided in the "rid-level"
attributes are consistent with the corrsponding codecs and their
other parameters. See Section 9 for more detail. If the rid-
level parameters are incompatible with the other codec
properties, then the "a=rid" line is removed.
7.5. Modifying the Session The offerer shall follow these steps when processing the answer:
Offers and answers inside an existing session follow the rules for 1. The offerer matches the "a=rid" line in the answer to the "a=rid"
initial session negotiation. Such an offer MAY propose a change the line in the offer using the "rid-identifier". If no matching
number of RIDs in use. To avoid race conditions with media, any RIDs line can be located in the offer, the "a=rid" line is ignored.
with proposed changes SHOULD use a new ID, rather than re-using one
from the previous offer/answer exchange. RIDs without proposed
changes SHOULD re-use the ID from the previous exchange.
8. Usage of 'rid' in RTP and RTCP 2. If the answer contains any constraints that were not present in
the offer, then the offerer SHALL consider the "a=rid" line as
rejected.
The RTP fixed header includes the payload type number and the SSRC 3. If the constraints have been changed between the offer and the
values of the RTP stream. RTP defines how you de-multiplex streams answer, the offerer MUST ensure that the modifications can be
within an RTP session, but in some use cases applications need supported; if they cannot, the SHALL consider the "a=rid" line as
further identifiers in order to effectively map the individual RTP rejected.
Streams to their equivalent payload configurations in the SDP.
This specification defines a new RTCP SDES item [RFC3550], 'RID', 4. If the "a=rid" line in the answer contains a "pt=" parameter but
which is used to carry rids within RTCP SDES packets. This makes it the offer did not, the offerer SHALL consider the "a=rid" line as
possible for a receiver to associate received RTP packets rejected.
(identifying the Source RTP Stream) with a media description having
the format constraint specified.
This specification also uses the RTP header extension for RTCP SDES 5. If the "a=rid" line in the answer contains a "pt=" parameter and
items [I-D.ietf-avtext-sdes-hdr-ext] to allow carrying RID the offer did as well, the offerer verifies that the list of
information in RTP packets to provide correlation at stream startup, payload types is a subset of those sent in the corresponding
or after stream changes where the use of RTCP may not be sufficiently "a=rid" line in the offer. If not, the offerer SHALL consider
responsive. the "a=rid" line as rejected.
8.1. RTCP 'RID' SDES Extension 6. If the "a=rid" line contains a "pt=" parameter, the offerer
verifies that the attribute values provided in the "a=rid"
attributes are consistent with the corresponding codecs and their
other parameters. See Section 8 for more detail. If the "a=rid"
parameters are incompatible with the other codec properties, then
the "a=rid" line is removed.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 7. The offerer verifies that the constraining parameters are
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ consistent with at least one of the codecs to be used with the
| RID=TBD | length | rid ... RID RTP Stream. If the "a=rid" line contains a "pt=" parameter,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ it contains the list of such codecs; otherwise, the list of such
codecs is taken from the associated "m=" line. See Section 8 for
more detail. If the "a=rid" parameters are incompatible with the
other codec properties for all codecs, then the "a=rid" line
SHALL be considered rejected
The rid payload is UTF-8 encoded and is not null-terminated. Any "a=rid" line present in the offer that was not matched by step 1
above SHALL be considered as rejected.
RFC EDITOR NOTE: Please replace TBD with the assigned SDES 6.5. Modifying the Session
identifier value.
8.2. RTP 'rid' Header Extension Offers and answers inside an existing session follow the rules for
initial session negotiation. Such an offer MAY propose a change in
the number of RIDs in use. To avoid race conditions with media, any
RIDs with proposed changes SHOULD use a new ID, rather than re-using
one from the previous offer/answer exchange. RIDs without proposed
changes SHOULD re-use the ID from the previous exchange.
Because recipients of RTP packets will typically need to know which 7. Use with Declarative SDP
"a=rid" constraints they correspond to immediately upon receipt, this
specification also defines a means of carrying RID identifiers in RTP
extension headers, using the technique described in
[I-D.ietf-avtext-sdes-hdr-ext].
As described in that document, the header extension element can be Although designed predominantly with session negotiation in mind, the
encoded using either the one-byte or two-byte header, and the "a=rid" attribute can also be used in declarative SDP situations.
identification-tag payload is UTF-8 encoded, as in SDP. When used with declarative SDP, any constraints applied to a RID
indicate how the sender intends to constrain the stream they are
sending.
As the identification-tag is included in an RTP header extension, In declarative use, the "direction" parameter MUST be set to "send"
there should be some consideration about the packet expansion caused in all "a=rid" lines.
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 [RFC5285]
It is RECOMMENDED that the identification-tag is kept short. Due to Recipients of declarative SDP may use the indicated constraints to
the properties of the RTP header extension mechanism, when using the select an RID RTP Stream to decode, based on their needs and
one-byte header, a tag that is 1-3 bytes will result in that a capabilities.
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 identifier that fits their purposes.
9. Interaction with Other Techniques 8. Interaction with Other Techniques
Historically, a number of other approaches have been defined that Historically, a number of other approaches have been defined that
allow constraining media streams via SDP parameters. These include: allow constraining media streams via SDP parameters. These include:
o Codec-specific configuration set via format parameters ("a=fmtp"); o Codec-specific configuration set via format parameters ("a=fmtp");
for example, the H.264 "max-fs" format parameter for example, the H.264 "max-fs" format parameter
o Size restrictions imposed by image attribute attributes o Size restrictions imposed by image attribute attributes
("a=imgattr") [RFC6236] ("a=imgattr") [RFC6236]
When the mechanism described in this document is used in conjunction When the mechanism described in this document is used in conjunction
with these other restricting mechanisms, it is intended to impose with these other restricting mechanisms, it is intended to impose
additional restrictions beyond those communicated in other additional restrictions beyond those communicated in other
techniques. techniques.
In an offer, this means that a=rid lines, when combined with other In an offer, this means that "a=rid" lines, when combined with other
restrictions on the media stream, are expected to result in a non- restrictions on the media stream, are expected to result in a non-
empty union. For example, if image attributes are used to indicate empty union. For example, if image attributes are used to indicate
that a PT has a minimum width of 640, then specification of "max- that a PT has a minimum width of 640, then specification of "max-
width=320" in an "a=rid" line that is then applied to that PT is width=320" in an "a=rid" line that is then applied to that PT is
nonsensical. According to the rules of Section 7.2.2, this will nonsensical. According to the rules of Section 6.2.2, this will
result in the corresponding "a=rid" line being ignored by the result in the corresponding "a=rid" line being ignored by the
recipient. recipient.
Similarly, an answer the a=rid lines, when combined with the other In an answer, the "a=rid" lines, when combined with the other
restrictions on the media stream, are also expected to result in a restrictions on the media stream, are also expected to result in a
non-empty union. If the implementation generating an answer wishes non-empty union. If the implementation generating an answer wishes
to restrict a property of the stream below that which would be to restrict a property of the stream below that which would be
allowed by other parameters (e.g., those specified in "a=fmtp" or allowed by other parameters (e.g., those specified in "a=fmtp" or
"a=imgattr"), its only recourse is to remove the "a=rid" line "a=imgattr"), its only recourse is to remove the "a=rid" line
altogether, as described in Section 7.3. If it instead attempts to altogether, as described in Section 6.3. If it instead attempts to
constrain the stream beyond what is allowed by other mechanisms, then constrain the stream beyond what is allowed by other mechanisms, then
the offerer will ignore the corresponding "a=rid" line, as described the offerer will ignore the corresponding "a=rid" line, as described
in Section 7.4. in Section 6.4.
10. Formal Grammar 9. Formal Grammar
This section gives a formal Augmented Backus-Naur Form (ABNF) This section gives a formal Augmented Backus-Naur Form (ABNF)
[RFC5234] grammar for each of the new media and rid-level attributes [RFC5234] grammar for each of the new media and "a=rid" attributes
defined in this document. defined in this document.
rid-syntax = "a=rid:" rid-identifier SP rid-dir rid-syntax = "a=rid:" rid-identifier SP rid-dir
[ rid-pt-param-list / rid-param-list ] [ rid-pt-param-list / rid-param-list ]
rid-identifier = 1*(alpha-numeric / "-" / "_") rid-identifier = 1*(alpha-numeric / "-" / "_")
rid-dir = "send" / "recv" rid-dir = "send" / "recv"
rid-pt-param-list = SP rid-fmt-list *(";" rid-param) rid-pt-param-list = SP rid-fmt-list *(";" rid-param)
skipping to change at page 13, line 25 skipping to change at page 13, line 11
rid-fmt-list = "pt=" fmt *( "," fmt ) rid-fmt-list = "pt=" fmt *( "," fmt )
; fmt defined in {{RFC4566}} ; fmt defined in {{RFC4566}}
rid-param = rid-width-param rid-param = rid-width-param
/ rid-height-param / rid-height-param
/ rid-fps-param / rid-fps-param
/ rid-fs-param / rid-fs-param
/ rid-br-param / rid-br-param
/ rid-pps-param / rid-pps-param
/ rid-bpp-param
/ rid-depend-param / rid-depend-param
/ rid-param-other / rid-param-other
rid-width-param = "max-width" [ "=" int-param-val ] rid-width-param = "max-width" [ "=" int-param-val ]
rid-height-param = "max-height" [ "=" int-param-val ] rid-height-param = "max-height" [ "=" int-param-val ]
rid-fps-param = "max-fps" [ "=" int-param-val ] rid-fps-param = "max-fps" [ "=" int-param-val ]
rid-fs-param = "max-fs" [ "=" int-param-val ] rid-fs-param = "max-fs" [ "=" int-param-val ]
rid-br-param = "max-br" [ "=" int-param-val ] rid-br-param = "max-br" [ "=" int-param-val ]
rid-pps-param = "max-pps" [ "=" int-param-val ] rid-pps-param = "max-pps" [ "=" int-param-val ]
rid-bpp-param = "max-bpp" [ "=" float-param-val ]
rid-depend-param = "depend=" rid-list rid-depend-param = "depend=" rid-list
rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ]
rid-list = rid-identifier *( "," rid-identifier ) rid-list = rid-identifier *( "," rid-identifier )
int-param-val = 1*DIGIT int-param-val = 1*DIGIT
float-param-val = 1*DIGIT "." 1*DIGIT
param-val = *( %x20-58 / %x60-7E ) param-val = *( %x20-58 / %x60-7E )
; Any printable character except semicolon ; Any printable character except semicolon
11. SDP Examples 10. SDP Examples
Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in
simulcast scenarios. simulcast scenarios.
11.1. Many Bundled Streams using Many Codecs 10.1. Many Bundled Streams using Many Codecs
In this scenario, the offerer supports the Opus, G.722, G.711 and 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 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 (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 mixer) is supported (send 1 and receive 7 video streams) by offering
7 video media sections (1 sendrecv at max resolution and 6 recvonly 7 video media sections (1 sendrecv at max resolution and 6 recvonly
at smaller resolutions), all bundled on the same port, using 3 at smaller resolutions), all bundled on the same port, using 3
different resolutions. The resolutions include: different resolutions. The resolutions include:
o 1 receive stream of 720p resolution is offered for the active o 1 receive stream of 720p resolution is offered for the active
skipping to change at page 14, line 38 skipping to change at page 14, line 27
Expressing all these codecs and resolutions using 32 dynamic PTs (2 Expressing all these codecs and resolutions using 32 dynamic PTs (2
audio + 10x3 video) would exhaust the primary dynamic space (96-127). audio + 10x3 video) would exhaust the primary dynamic space (96-127).
RIDs are used to avoid PT exhaustion and express the resolution RIDs are used to avoid PT exhaustion and express the resolution
constraints. constraints.
NOTE: The SDP given below skips few lines to keep the example short NOTE: The SDP given below skips few lines to keep the example short
and focused, as indicated by either the "..." or the comments and focused, as indicated by either the "..." or the comments
inserted. inserted.
Example 1 The offer for this scenario is shown below.
Offer:
... ...
m=audio 10000 RTP/SAVPF 96 9 8 0 123 m=audio 10000 RTP/SAVPF 96 9 8 0 123
a=rtpmap:96 OPUS/48000 a=rtpmap:96 OPUS/48000
a=rtpmap:9 G722/8000 a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:123 telephone-event/8000 a=rtpmap:123 telephone-event/8000
a=mid:a1 a=mid:a1
... ...
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
skipping to change at page 16, line 5 skipping to change at page 15, line 39
...same rtpmap/fmtp as above... ...same rtpmap/fmtp as above...
a=recvonly a=recvonly
a=mid:v4 (small resolution) a=mid:v4 (small resolution)
a=rid:4 recv max-width=320;max-height=180;max-fps=15 a=rid:4 recv max-width=320;max-height=180;max-fps=15
... ...
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
...same rtpmap/fmtp as above... ...same rtpmap/fmtp as above...
...same rid:4 as above for mid:v5,v6,v7 (small resolution)... ...same rid:4 as above for mid:v5,v6,v7 (small resolution)...
... ...
Answer: 10.2. Scalable Layers
...same as offer but swap send/recv...
11.2. Scalable Layers
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).
Example 3 Adding scalable layers to a session within a multiparty conference
gives a selective forwarding unit (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).
Offer: Offer:
... ...
m=audio ...same as Example 1 ... m=audio ...same as previous example ...
... ...
m=video ...same as Example 1 ... m=video ...same as previous example ...
...same rtpmap/fmtp as Example 1... ...same rtpmap/fmtp as previous example ...
a=sendrecv a=sendrecv
a=mid:v1 (max resolution) a=mid:v1 (max resolution)
a=rid:0 send max-width=1280;max-height=720;max-fps=15 a=rid:0 send max-width=1280;max-height=720;max-fps=15
a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0
a=rid:2 recv max-width=1280;max-height=720;max-fps=30 a=rid:2 recv max-width=1280;max-height=720;max-fps=30
a=rid:5 send max-width=640;max-height=360;max-fps=15 a=rid:5 send max-width=640;max-height=360;max-fps=15
a=rid:6 send max-width=320;max-height=180;max-fps=15 a=rid:6 send max-width=320;max-height=180;max-fps=15
a=simulcast: send rid=0;1;5;6 recv rid=2 a=simulcast: send rid=0;1;5;6 recv rid=2
... ...
...same m=video sections as Example1 for mid:v2-v7... ...same m=video sections as previous example for mid:v2-v7...
... ...
Answer: 11. Open Issues
...same as offer but swap send/recv...
12. Open Issues 11.1. Declarative SDP
12.1. Name of the identifier Section 7 describes the use of "a=rid" for declarative SDP. This is
a pretty small amount of work, and the use of this mechanism to
describe how a sender is going to constrain a stream does have some
amount of utility. Is the text sufficient? If not, do we want to
invest the work needed to make RID work with declarative use cases?
The name 'rid' is provisionally used and is open for further PROPOSAL: Keep the current text.
discussion.
Here are the few options that were considered while writing this 11.2. Definition of bitrate
draft
o CID: Constraint ID, which is a rather precise description of what
we are attempting to accomplish.
o ESID: Encoded Stream ID, does not align well with taxonomy which Some questions have been raised as to whether we need a more formal
defines Encoded Stream as before RTP packetization. description of bitrate than we currently use.
o RSID or RID: RTP Stream ID, aligns better with taxonomy but very If I read correctly, Magnus indicated that the definition in the
vague. document is consistent with TIAS, and believes it is sufficiently
well defined.
o LID: Layer ID, aligns well for SVC with each layer in a separate PROPOSAL: keep current definition that exists in description of "max-
stream, but not for other SVC layerings or independent simulcast br".
which is awkward to view as layers.
o EPT or XPT: EXtended Payload Type, conveys XPT.PT usage well, but 11.3. Escaping new constraint values
may be confused with PT, for example people may mistakenly think
they can use it in other places where PT would normally be used.
13. IANA Considerations The parameters on an "a=rid:" line are extensible. The syntax for
these is:
13.1. New RTP Header Extension URI rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ]
This document defines a new extension URI in the RTP Compact Header param-val = *( %x20-58 / %x60-7E )
Extensions subregistry of the Real-Time Transport Protocol (RTP) ; Any printable character except semicolon
Parameters registry, according to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:sdes:rid If an extension has values that can contain semicolons, they need an
Description: RTP Stream Restriction Identifier escaping mechanism. Note that this is not an issue for any currently
Contact: <mmusic@ietf.org> defined parameters, as they all take numeric values only.
Reference: RFCXXXX
13.2. New SDES item 1. Change extension syntax to only allow numeric values
RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of 2. Define a universal escaping mechanism for all extensions to use
this document.
RFC EDITOR NOTE: Please replace TBD with the assigned SDES 3. Leave this problem for the first extension parameter - if any -
identifier value. to define value in a way that might allow a semicolon. Note that
this approach would allow the use of percent-style escaping
(e.g., "%3B") but not backslash-style escaping (e.g., "\;"), as
parsers that do not support the new constraint would interpret
the embedded semicolon as a separator.
This document adds the MID SDES item to the IANA "RTCP SDES item PROPOSAL: Option #3
types" registry as follows:
Value: TBD 11.4. Utility of max-width and max height
Abbrev.: RID
Name: Restriction Identification
Reference: RFCXXXX
13.3. New SDP Media-Level attribute Comment from Stephan Wenger: Are max-width and max-height actually
useful controls? Shouldn't max-fs be sufficient for any plausible
uses?
PROPOSAL: Keep max-height and max-width. Implementation is well-
defined and easily implemented. At least one participant expressed
support for these parameters at IETF 94 face-to-face meeting.
11.5. Definition of max-fps
Comment from Stephan Wenger: Would it be better to define max-fps as
constraining the average over a second rather than the inverse of the
smallest allowed interval between frames?
PROPOSAL: Keep as currently defined. The difference is subtle. The
only kinds of cases allowed by an average that aren't allowed by a
minimum interframe interval are those such as sending no packets for
most of a second, followed by a burst of 30 frames 1 ms apart, as
part of a stream constrained to 30 fps. Such cases seem undesirable.
12. IANA Considerations
12.1. New SDP Media-Level attribute
This document defines "rid" as SDP media-level attribute. This This document defines "rid" as SDP media-level attribute. This
attribute must be registered by IANA under "Session Description attribute must be registered by IANA under "Session Description
Protocol (SDP) Parameters" under "att-field (media level only)". Protocol (SDP) Parameters" under "att-field (media level only)".
The "rid" attribute is used to identify characteristics of RTP stream The "rid" attribute is used to identify characteristics of RTP stream
with in a RTP Session. Its format is defined in Section 10. with in a RTP Session. Its format is defined in Section 9.
13.4. Registry for RID-Level Parameters 12.2. Registry for RID-Level Parameters
This specification creates a new IANA registry named "att-field (rid This specification creates a new IANA registry named "att-field (rid
level)" within the SDP parameters registry. The rid-level parameters level)" within the SDP parameters registry. The "a=rid" parameters
MUST be registered with IANA and documented under the same rules as MUST be registered with IANA and documented under the same rules as
for SDP session-level and media-level attributes as specified in for SDP session-level and media-level attributes as specified in
[RFC4566]. [RFC4566].
Parameters for "a=rid" lines that modify the nature of encoded media Parameters for "a=rid" lines that modify the nature of encoded media
MUST be of the form that the result of applying the modification to MUST be of the form that the result of applying the modification to
the stream results in a stream that still complies with the other the stream results in a stream that still complies with the other
parameters that affect the media. In other words, parameters always parameters that affect the media. In other words, parameters always
have to restrict the definition to be a subset of what is otherwise have to restrict the definition to be a subset of what is otherwise
allowable, and never expand it. allowable, and never expand it.
skipping to change at page 18, line 47 skipping to change at page 18, line 49
o long-form parameter name in English o long-form parameter name in English
o whether the parameter value is subject to the charset attribute o whether the parameter value is subject to the charset attribute
o an explanation of the purpose of the parameter o an explanation of the purpose of the parameter
o a specification of appropriate attribute values for this parameter o a specification of appropriate attribute values for this parameter
o an ABNF definition of the parameter o an ABNF definition of the parameter
The initial set of rid-level parameter names, with definitions in The initial set of "a=rid" parameter names, with definitions in
Section 6 of this document, is given below: Section 5 of this document, is given below:
Type SDP Name Reference Type SDP Name Reference
---- ------------------ --------- ---- ------------------ ---------
att-field (rid level) att-field (rid level)
max-width [RFCXXXX] max-width [RFCXXXX]
max-height [RFCXXXX] max-height [RFCXXXX]
max-fps [RFCXXXX] max-fps [RFCXXXX]
max-fs [RFCXXXX] max-fs [RFCXXXX]
max-br [RFCXXXX] max-br [RFCXXXX]
max-pps [RFCXXXX] max-pps [RFCXXXX]
max-bpp [RFCXXXX]
depend [RFCXXXX] depend [RFCXXXX]
It is conceivable that a future document wants to define a RID-level It is conceivable that a future document wants to define a RID-level
parameter that contains string values. These extensions need to take parameter that contains string values. These extensions need to take
care to conform to the ABNF defined for rid-param-other. In care to conform to the ABNF defined for rid-param-other. In
particular, this means that such extensions will need to define particular, this means that such extensions will need to define
escaping mechanisms if they want to allow semicolons, unprintable escaping mechanisms if they want to allow semicolons, unprintable
characters, or byte values greater than 127 in the string. characters, or byte values greater than 127 in the string.
OPEN ITEM: Do we need to do more than this regarding escaping? 13. Security Considerations
14. Security Considerations
As with most SDP parameters, a failure to provide integrity As with most SDP parameters, a failure to provide integrity
protection over the a=rid attributes provides attackers a way to protection over the "a=rid" attributes provides attackers a way to
modify the session in potentially unwanted ways. This could result modify the session in potentially unwanted ways. This could result
in an implementation sending greater amounts of data than a recipient in an implementation sending greater amounts of data than a recipient
wishes to receive. In general, however, since the "a=rid" attribute wishes to receive. In general, however, since the "a=rid" attribute
can only restrict a stream to be a subset of what is otherwise can only restrict a stream to be a subset of what is otherwise
allowable, modification of the value cannot result in a stream that allowable, modification of the value cannot result in a stream that
is of higher bandwidth than would be sent to an implementation that is of higher bandwidth than would be sent to an implementation that
does not support this mechanism. does not support this mechanism.
The actual identifiers used for RIDs are expected to be opaque. As The actual identifiers used for RIDs are expected to be opaque. As
such, they are not expected to contain information that would be such, they are not expected to contain information that would be
sensitive, were it observed by third-parties. sensitive, were it observed by third-parties.
15. Acknowledgements 14. Acknowledgements
Many thanks to review from Cullen Jennings, Magnus Westerlund, and Many thanks to review from Cullen Jennings, Magnus Westerlund, and
Paul Kyzivat. Paul Kyzivat.
16. References 15. References
16.1. Normative References
[I-D.ietf-avtext-sdes-hdr-ext] 15.1. Normative References
Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP
Header Extension for RTCP Source Description Items", [I-D.roach-avtext-rid]
draft-ietf-avtext-sdes-hdr-ext-02 (work in progress), July Roach, A., Nandakumar, S., and P. Thatcher, "RTP Payload
2015. Format Constraints", draft-roach-avtext-rid-01 (work in
progress), February 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, DOI with Session Description Protocol (SDP)", RFC 3264, DOI
10.17487/RFC3264, June 2002, 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>. <http://www.rfc-editor.org/info/rfc3264>.
skipping to change at page 20, line 40 skipping to change at page 20, line 38
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
RFC5234, January 2008, RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <http://www.rfc-editor.org/info/rfc5285>. 2008, <http://www.rfc-editor.org/info/rfc5285>.
16.2. Informative References 15.2. Informative References
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, "A Taxonomy of Semantics and Mechanisms for B. Burman, "A Taxonomy of Semantics and Mechanisms for
Real-Time Transport Protocol (RTP) Sources", draft-ietf- Real-Time Transport Protocol (RTP) Sources", draft-ietf-
avtext-rtp-grouping-taxonomy-08 (work in progress), July avtext-rtp-grouping-taxonomy-08 (work in progress), July
2015. 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-23 (work in progress), July 2015. negotiation-25 (work in progress), January 2016.
[I-D.ietf-mmusic-sdp-simulcast] [I-D.ietf-mmusic-sdp-simulcast]
Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
"Using Simulcast in SDP and RTP Sessions", draft-ietf- "Using Simulcast in SDP and RTP Sessions", draft-ietf-
mmusic-sdp-simulcast-03 (work in progress), October 2015. mmusic-sdp-simulcast-03 (work in progress), October 2015.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
 End of changes. 130 change blocks. 
371 lines changed or deleted 378 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/