draft-ietf-mmusic-rid-05.txt   draft-ietf-mmusic-rid-06.txt 
Network Working Group P. Thatcher Network Working Group P. Thatcher
Internet-Draft Google Internet-Draft Google
Updates: 4855 (if approved) M. Zanaty Updates: 4855 (if approved) M. Zanaty
Intended status: Standards Track S. Nandakumar Intended status: Standards Track S. Nandakumar
Expires: September 26, 2016 Cisco Systems Expires: January 8, 2017 Cisco Systems
B. Burman B. Burman
Ericsson Ericsson
A. Roach A. Roach
B. Campen B. Campen
Mozilla Mozilla
March 25, 2016 July 07, 2016
RTP Payload Format Constraints RTP Payload Format Constraints
draft-ietf-mmusic-rid-05 draft-ietf-mmusic-rid-06
Abstract Abstract
In this specification, we define a framework for identifying RTP In this specification, we define a framework for specifying
Streams with the constraints on its payload format in the Session constraints on RTP streams in the Session Description Protocol. This
Description Protocol. This framework defines a new "rid" SDP framework defines a new "rid" SDP attribute to unambiguously identify
attribute to: a) effectively identify the RID RTP Streams within a the RTP Streams within a RTP Session and constrain the streams'
RTP Session, b) constrain their payload format parameters in a codec- payload format parameters in a codec-agnostic way beyond what is
agnostic way beyond what is provided with the regular Payload Types provided with the regular Payload Types.
and c) enable unambiguous mapping between the RID RTP Streams to
their media format specification in the SDP.
This specification updates RFC4855 to give additional guidance on This specification updates RFC4855 to give additional guidance on
choice of Format Parameter (fmtp) names, and on their relation to the choice of Format Parameter (fmtp) names, and on their relation to the
constraints defined by this document. constraints defined by this document.
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 September 26, 2016. This Internet-Draft will expire on January 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Key Words for Requirements . . . . . . . . . . . . . . . . . 4 3. Key Words for Requirements . . . . . . . . . . . . . . . . . 4
4. SDP "a=rid" Media Level Attribute . . . . . . . . . . . . . . 5 4. SDP "a=rid" Media Level Attribute . . . . . . . . . . . . . . 4
5. "a=rid" constraints . . . . . . . . . . . . . . . . . . . . . 6 5. "a=rid" constraints . . . . . . . . . . . . . . . . . . . . . 6
6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7
6.1. Generating the Initial SDP Offer . . . . . . . . . . . . 7 6.1. Generating the Initial SDP Offer . . . . . . . . . . . . 7
6.2. Answerer processing the SDP Offer . . . . . . . . . . . . 8 6.2. Answerer processing the SDP Offer . . . . . . . . . . . . 8
6.2.1. "a=rid"-unaware Answerer . . . . . . . . . . . . . . 8 6.2.1. "a=rid"-unaware Answerer . . . . . . . . . . . . . . 8
6.2.2. "a=rid"-aware Answerer . . . . . . . . . . . . . . . 8 6.2.2. "a=rid"-aware Answerer . . . . . . . . . . . . . . . 8
6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 9 6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 9
6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10
6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 11 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 11
7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 12 7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 12
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Rate . . . . . . . . . . . . . . . . . . . . . . . . 16 Rate . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2.5. max-smbps - Maximum Decoded Picture Buffer . . . . . 16 8.2.5. max-smbps - Maximum Decoded Picture Buffer . . . . . 16
9. Format Parameters for Future Payloads . . . . . . . . . . . . 16 9. Format Parameters for Future Payloads . . . . . . . . . . . . 16
10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 16 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 16
11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 18 11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 18
11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 19 11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 20 12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 20
12.2. Registry for RID-Level Parameters . . . . . . . . . . . 20 12.2. Registry for RID-Level Parameters . . . . . . . . . . . 20
13. Security Considerations . . . . . . . . . . . . . . . . . . . 21 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
15.1. Normative References . . . . . . . . . . . . . . . . . . 22 15.1. Normative References . . . . . . . . . . . . . . . . . . 22
15.2. Informative References . . . . . . . . . . . . . . . . . 23 15.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Terminology 1. Terminology
The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP
Stream" are used as defined in [RFC7656]. Stream" are used as defined in [RFC7656].
The term "RID RTP Stream" is used as defined in
[I-D.roach-avtext-rid].
[RFC4566] and [RFC3264] terminology is also used where appropriate. [RFC4566] and [RFC3264] terminology is also used where appropriate.
2. Introduction 2. Introduction
Payload Type (PT) in RTP provides a mapping between the RTP payload The Payload Type (PT) field in RTP provides a mapping between the RTP
format and the associated SDP media description. The SDP rtpmap and/ payload format and the associated SDP media description. The SDP
or fmtp attributes are used, for a given PT, to the describe the rtpmap and/or fmtp attributes are used, for a given PT, to the
characteristics of the media that is carried in the RTP payload. describe the characteristics of the media that is carried in the RTP
payload.
Recent advances in standards have given rise to rich multimedia Recent advances in standards have given rise to rich multimedia
applications requiring support for multiple RTP Streams within a RTP applications requiring support for multiple RTP Streams within a RTP
session [I-D.ietf-mmusic-sdp-bundle-negotiation], session [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 a large number
of codecs. These demands have unearthed challenges inherent with: of codecs. 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,
skipping to change at page 4, line 4 skipping to change at page 3, line 50
o Missing or underspecified payload format parameters, o Missing or underspecified payload format parameters,
o Overloading of PTs to indicate not just codec configurations, but o Overloading of PTs to indicate not just codec configurations, but
individual streams within an RTP session. individual streams within an RTP session.
To expand on these points: [RFC3550] assigns 7 bits for the PT in the To expand on these points: [RFC3550] assigns 7 bits for the PT in the
RTP header. However, the assignment of static mapping of RTP payload RTP header. However, the assignment of static mapping of RTP payload
type numbers to payload formats and multiplexing of RTP with other type numbers to payload formats and multiplexing of RTP with other
protocols (such as RTCP) could result in limited number of payload protocols (such as RTCP) could result in limited number of payload
type numbers available for the application usage. In scenarios where type numbers available for application usage. In scenarios where the
the number of possible RTP payload configurations exceed the number of possible RTP payload configurations exceed the available PT
available PT space within a RTP Session, there is a need for a way to space within a RTP Session, there is a need for a way to represent
represent the additional constraints on payload configurations and to the additional constraints on payload configurations and to
effectively map a RID RTP Stream to its corresponding constraints. effectively map an RTP Stream to its corresponding constraints. This
This issue is exacerbated by the increase in techniques such as issue is exacerbated by the increase in techniques - such as
simulcast and layered codecs, which introduce additional streams into simulcast and layered codecs - which introduce additional streams
RTP Sessions. 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 [RFC7656]), along with the SDP Source RTP Streams (Section 2.1.10 [RFC7656]), along with the SDP
attributes to constrain payload formats in a codec-agnostic way. attributes to constrain payload formats in a codec-agnostic way.
This framework can be thought of as a complementary extension to the This framework can be thought of as a complementary extension to the
way the media format parameters are specified in SDP today, via the way the media format parameters are specified in SDP today, via the
"a=fmtp" attribute. "a=fmtp" attribute.
The additional constraints on individual streams are indicated with a The additional constraints on individual streams are indicated with a
new "a=rid" SDP attribute. Note that the constraints communicated new "a=rid" SDP attribute. Note that the constraints communicated
via this attribute only serve to further constrain the parameters via this attribute only serve to further constrain the parameters
that are established on a PT format. They do not relax any existing that are established on a PT format. They do not relax any existing
restrictions. restrictions.
This specification makes use of the RTP Stream Identifier SDES RTCP This specification makes use of the RTP Stream Identifier SDES RTCP
item defined in [I-D.roach-avtext-rid] to provide correlation item defined in [I-D.ietf-avtext-rid] to provide correlation between
between the RTP Packets and their format specification in the SDP. the RTP Packets and their format specification in the SDP.
As described in Section 6.2.1, this mechanism achieves backwards 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= lines to be ignored. This means that implementations need unknown a= lines to be ignored. This means that implementations need
to be prepared to handle successful offers and answers from other to be prepared to handle successful offers and answers from other
implementations that neither indicate nor honor the constraints implementations that neither indicate nor honor the constraints
requested by this mechanism. requested by this mechanism.
Further, as described in Section 6 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
skipping to change at page 5, line 8 skipping to change at page 4, line 49
3. Key Words for Requirements 3. 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]
4. SDP "a=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", ("restriction identifier") used to communicate a set of
(see Section 10 for a formal definition). restrictions to be applied an identified RTP Stream. Roughly
speaking, this attribute takes the following form (see Section 10 for
a formal definition).
a=rid:<rid-id> <direction> [pt=<fmt-list>;]<constraint>=<value>... a=rid:<rid-id> <direction> [pt=<fmt-list>;]<constraint>=<value>...
An "a=rid" SDP media attribute specifies constraints defining a 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-id" field.
field. This value binds the restriction to the RID RTP Stream This value binds the restriction to the RTP Stream identified by its
identified by its RID SDES item [I-D.roach-avtext-rid]. RTP Stream Identifier SDES item [I-D.ietf-avtext-rid].
The "direction" field identifies the directionality of the RID RTP The "direction" field identifies the directionality of the RTP
Stream; it may be either "send" or "recv". Stream; it may be either "send" or "recv".
The optional "pt=<fmt-list>" lists one or more PT values that can be The optional "pt=<fmt-list>" lists one or more PT values that can be
used in the associated RID RTP Stream. If the "a=rid" attribute used in the associated RTP Stream. If the "a=rid" attribute contains
contains no "pt", then any of the PT values specified in the no "pt", then any of the PT values specified in the corresponding
corresponding "m=" line may be used. "m=" line may be used.
The list of zero or more codec-agnostic constraints (Section 5) The list of zero or more codec-agnostic constraints (Section 5)
describe the restrictions that the corresponding RID RTP Stream will describe the restrictions that the corresponding RTP Stream will
conform to. conform to.
This framework MAY be used in combination with the "a=fmtp" SDP This framework MAY be used in combination with the "a=fmtp" SDP
attribute for describing the media format parameters for a given RTP attribute for describing the media format parameters for a given RTP
Payload Type. In such scenarios, the "a=rid" constraints (Section 5) Payload Type. In such scenarios, the "a=rid" constraints (Section 5)
further constrain the equivalent "a=fmtp" attributes. 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-id" MUST NOT be repeated in a given media description ("m="
("m=" section). section).
The "a=rid" media attribute MAY be used for any RTP-based media The "a=rid" media attribute MAY be used for any RTP-based media
transport. It is not defined for other transports, although other transport. It is not defined for other transports, although other
documents may extend its semantics for such transports. documents may extend its semantics for such transports.
Though the constraints specified by the "rid" constraints follow a Though the constraints specified by the "rid" constraints follow a
syntax similar to session-level and media-level parameters, they are syntax similar to session-level and media-level parameters, they are
defined independently. All "rid" constraints MUST be registered with defined independently. All "rid" constraints MUST be registered with
IANA, using the registry defined in Section 12. IANA, using the registry defined in Section 12.
skipping to change at page 7, line 22 skipping to change at page 7, line 22
registration by other documents. registration by other documents.
Section 10 provides formal Augmented Backus-Naur Form(ABNF) [RFC5234] Section 10 provides formal Augmented Backus-Naur Form(ABNF) [RFC5234]
grammar for each of the "a=rid" constraints defined in this section. grammar for each of the "a=rid" constraints defined in this section.
6. 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 this framework. using this framework.
Note that "rid-identifier" values are only required to be unique Note that "rid-id" values are only required to be unique within a
within a media section ("m-line"); they do not necessarily need to be media section ("m-line"); they do not necessarily need to be unique
unique within an entire RTP session. In traditional usage, each within an entire RTP session. In traditional usage, each media
media section is sent on its own unique 5-tuple, which provides an section is sent on its own unique 5-tuple, which provides an
unambiguous scope. 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.
6.1. Generating the Initial SDP Offer 6.1. Generating the Initial SDP Offer
For each RTP media description in the offer, the offerer MAY choose For each RTP media description in the offer, the offerer MAY choose
to include one or more "a=rid" lines to specify a configuration to include one or more "a=rid" lines to specify a configuration
profile for the given set of RTP Payload Types. profile 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
these steps: these steps:
1. It MUST generate a "rid-identifier" that is unique within a media 1. It MUST generate a "rid-id" 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-id" to one of "send" or
"send" or "recv" "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) allowed to appear in the RID corresponding to RTP payload types) allowed to appear in the RTP
RTP Stream. Any Payload Types chosen MUST be a valid payload Stream. Any Payload Types chosen MUST be a valid payload type
type for the media section (that is, it must be listed on the for the media section (that is, it must be listed on the "m="
"m=" line). The order of the listed formats is significant; the line). The order of the listed formats is significant; the
alternatives are listed from (left) most preferred to (right) alternatives are listed from (left) most preferred to (right)
least preferred. When using RID, this preference overrides the least preferred. When using RID, this preference overrides the
normal codec preference as expressed by format type ordering on normal codec preference as expressed by format type ordering on
the "m="-line, using regular SDP rules. the "m="-line, using regular SDP rules.
4. The Offerer then chooses zero or more "a=rid" constraints 4. The Offerer then chooses zero or more "a=rid" constraints
(Section 5) to be applied to the RID RTP Stream, and adds them to (Section 5) to be applied to the RTP Stream, and adds them to the
the "a=rid" line. "a=rid" line.
5. If the offerer wishes the answerer to have the ability to specify 5. If the offerer wishes the answerer to have the ability to specify
a constraint, but does not wish to set a value itself, it MUST a constraint, but does not wish to set a value itself, it MUST
include the name of the constraint in the "a=rid" line, but include the name of the constraint in the "a=rid" line, but
without any indicated value. without any indicated value.
Note: If an "a=fmtp" attribute is also used to provide media-format- Note: If an "a=fmtp" attribute is also used to provide media-format-
specific parameters, then the "a=rid" constraints will further specific parameters, then the "a=rid" constraints will further
restrict the equivalent "a=fmtp" parameters for the given Payload restrict the equivalent "a=fmtp" parameters for the given Payload
Type for the specified RID RTP Stream. Type for the specified RTP Stream.
If a given codec would require an "a=fmtp" line when used without 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 "a=rid". line even when using "a=rid".
6.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"
attribute in the media description, the receiver of the offer will
perform the following steps:
6.2.1. "a=rid"-unaware Answerer 6.2.1. "a=rid"-unaware Answerer
If the receiver doesn't support the 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 6.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.
6.2.2. "a=rid"-aware Answerer 6.2.2. "a=rid"-aware Answerer
If the answerer supports the "a=rid" attribute, the following If the answerer supports the "a=rid" attribute, the following
verification steps are executed, in order, for each "a=rid" line in a verification steps are executed, in order, for each "a=rid" line in a
given media description: given media description:
1. Extract the rid-identifier from the "a=rid" line and verify its 1. The answerer ensures that the "a=rid" line is syntactically well
uniqueness. In the case of a duplicate, the entire "a=rid" line, formed. In the case of a syntax error, the "a=rid" line is
and all "a=rid" lines with rid-identifiers that duplicate this removed.
line, are discarded and MUST NOT be included in the SDP Answer.
2. If the "a=rid" line contains a "pt=", the list of payload types 2. Extract the rid-id from the "a=rid" line and verify its
uniqueness within a media section. In the case of a duplicate,
the entire "a=rid" line, and all "a=rid" lines with rid-ids that
duplicate this line, are discarded and MUST NOT be included in
the SDP Answer.
3. If the "a=rid" line contains a "pt=", the list of payload types
is verified against the list of valid payload types for the media is verified against the list of valid payload types for the media
section (that is, those listed on the "m=" line). Any PT missing section (that is, those listed on the "m=" line). Any PT missing
from the "m=" line is removed from the "pt=". from the "m=" line is removed from the set of valued in the
"pt=".
3. The answerer ensures that the "a=rid" line is syntactically well
formed. In the case of a syntax error, the "a=rid" line is
removed.
4. If the "direction" field is "recv", The answerer ensures that 4. If the "direction" field is "recv", The answerer ensures that
"a=rid" constraints are supported. In the case of an unsupported "a=rid" constraints are supported. In the case of an unsupported
constraint, the "a=rid" line is removed. constraint, the "a=rid" line is removed.
5. If the "depend" constraint is included, the answerer MUST make 5. If the "depend" constraint is included, the answerer MUST make
sure that the listed rid-identifiers unambiguously match the rid- sure that the listed rid-ids unambiguously match the rid-ids in
identifiers in the SDP offer. Any "a=rid" lines that do not are the SDP offer. Any "a=rid" lines that do not are removed.
removed.
6. The answerer verifies that the constraints are consistent with at 6. The answerer verifies that the constraints are consistent with at
least one of the codecs to be used with the RID RTP Stream. If least one of the codecs to be used with the RTP Stream. If the
the "a=rid" line contains a "pt=", it contains the list of such "a=rid" line contains a "pt=", it contains the list of such
codecs; otherwise, the list of such codecs is taken from the codecs; otherwise, the list of such codecs is taken from the
associated "m=" line. See Section 8 for more detail. If the associated "m=" line. See Section 8 for more detail. If the
"a=rid" constraints are incompatible with the other codec "a=rid" constraints are incompatible with the other codec
properties for all codecs, then the "a=rid" line is removed. properties for all codecs, then the "a=rid" line is removed.
Note that the answerer does not need to understand every constraint Note that the answerer does not need to understand every constraint
present in a "send" line: if a stream sender constrains the stream in 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 a way that the receiver does not understand, this causes no issues
with interoperability. with interoperability.
skipping to change at page 10, line 7 skipping to change at page 9, line 51
1. The sense of of the "direction" field is reversed: "send" is 1. The sense of of the "direction" field is reversed: "send" is
changed to "recv", and "recv" is changed to "send". changed to "recv", and "recv" is changed to "send".
2. The answerer MAY choose to modify specific "a=rid" constraint 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.
3. The answerer MUST NOT modify the "rid-identifier" present in the 3. The answerer MUST NOT modify the "rid-id" present in the offer.
offer.
4. If the "a=rid" line contains a "pt=", the answerer is allowed to 4. If the "a=rid" line contains a "pt=", the answerer is allowed to
remove one or more media formats from a given "a=rid" line. If remove one or more media formats from a given "a=rid" line. If
the answerer chooses to remove all the media format tokens from the answerer chooses to remove all the media format tokens from
an "a=rid" line, the answerer MUST remove the entire "a=rid" an "a=rid" line, the answerer MUST remove the entire "a=rid"
line. If the offer did not contain a "pt=" for a given "a=rid" line. If the offer did not contain a "pt=" for a given "a=rid"
line, then the answer MUST NOT contain a "pt=" in the line, then the answer MUST NOT contain a "pt=" in the
corresponding line. corresponding line.
5. In cases where the answerer is unable to support the payload 5. In cases where the answerer is unable to support the payload
skipping to change at page 10, line 34 skipping to change at page 10, line 29
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 are present in its answer. answer use the PT values that are present in its answer.
6.4. Offerer Processing of the SDP Answer 6.4. Offerer Processing of the SDP Answer
The offerer SHALL follow these steps when processing the answer: The offerer SHALL follow these steps when processing the answer:
1. The offerer matches the "a=rid" line in the answer to the "a=rid" 1. The offerer matches the "a=rid" line in the answer to the "a=rid"
line in the offer using the "rid-identifier". If no matching line in the offer using the "rid-id". If no matching line can be
line can be located in the offer, the "a=rid" line is ignored. located in the offer, the "a=rid" line is ignored.
2. If the answer contains any constraints that were not present in 2. If the answer contains any constraints that were not present in
the offer, then the offerer SHALL discard the "a=rid" line. the offer, then the offerer SHALL discard the "a=rid" line.
3. If the constraints have been changed between the offer and the 3. If the constraints have been changed between the offer and the
answer, the offerer MUST ensure that the modifications can be answer, the offerer MUST ensure that the modifications can be
supported; if they cannot, the offerer SHALL discard the "a=rid" supported; if they cannot, the offerer SHALL discard the "a=rid"
line. line.
4. If the "a=rid" line in the answer contains a "pt=" but the offer 4. If the "a=rid" line in the answer contains a "pt=" but the offer
skipping to change at page 11, line 23 skipping to change at page 11, line 17
offerer SHALL discard the "a=rid" line. offerer SHALL discard the "a=rid" line.
6. If the "a=rid" line contains a "pt=", the offerer verifies that 6. If the "a=rid" line contains a "pt=", the offerer verifies that
the attribute values provided in the "a=rid" attributes are the attribute values provided in the "a=rid" attributes are
consistent with the corresponding codecs and their other consistent with the corresponding codecs and their other
parameters. See Section 8 for more detail. If the "a=rid" parameters. See Section 8 for more detail. If the "a=rid"
constraints are incompatible with the other codec properties, constraints are incompatible with the other codec properties,
then the offerer SHALL discard the "a=rid" line. then the offerer SHALL discard the "a=rid" line.
7. The offerer verifies that the constraints are consistent with at 7. The offerer verifies that the constraints are consistent with at
least one of the codecs to be used with the RID RTP Stream. If least one of the codecs to be used with the RTP Stream. If the
the "a=rid" line contains a "pt=", it contains the list of such "a=rid" line contains a "pt=", it contains the list of such
codecs; otherwise, the list of such codecs is taken from the codecs; otherwise, the list of such codecs is taken from the
associated "m=" line. See Section 8 for more detail. If the associated "m=" line. See Section 8 for more detail. If the
"a=rid" constraints are incompatible with the other codec "a=rid" constraints are incompatible with the other codec
properties for all codecs, then the offerer SHALL discard the properties for all codecs, then the offerer SHALL discard the
"a=rid" line. "a=rid" line.
Any "a=rid" line present in the offer that was not matched by step 1 Any "a=rid" line present in the offer that was not matched by step 1
above has been discarded by the answerer, and does not form part of above has been discarded by the answerer, and does not form part of
the negotiated constraints on a RID RTP Stream. The offerer MAY the negotiated constraints on an RTP Stream. The offerer MAY still
still apply any constraints it indicated in an "a=rid" line with a apply any constraints it indicated in an "a=rid" line with a
direction field of "send", but it is not required to do so. direction field of "send", but it is not required to do so.
It is important to note that there are several ways in which an offer It is important to note that there are several ways in which an offer
can contain a media section with "a=rid" lines, but the corresponding can contain a media section with "a=rid" lines, but the corresponding
media section in the response does not. This includes situations in media section in the response does not. This includes situations in
which the answerer does not support "a=rid" at all, or does not which the answerer does not support "a=rid" at all, or does not
support the indicated constraints. Under such circumstances, the support the indicated constraints. Under such circumstances, the
offerer MUST be prepared to receive a media stream to which no offerer MUST be prepared to receive a media stream to which no
constraints have been applied. constraints have been applied.
skipping to change at page 12, line 19 skipping to change at page 12, line 17
Although designed predominantly with session negotiation in mind, the Although designed predominantly with session negotiation in mind, the
"a=rid" attribute can also be used in declarative SDP situations. "a=rid" attribute can also be used in declarative SDP situations.
When used with declarative SDP, any constraints applied to a RID When used with declarative SDP, any constraints applied to a RID
indicate how the sender intends to constrain the stream they are indicate how the sender intends to constrain the stream they are
sending. sending.
In declarative use, the "direction" field MUST be set to "send" in In declarative use, the "direction" field MUST be set to "send" in
all "a=rid" lines. all "a=rid" lines.
Recipients of declarative SDP may use the indicated constraints to Recipients of declarative SDP may use the indicated constraints to
select an RID RTP Stream to decode, based on their needs and select an RTP Stream to decode, based on their needs and
capabilities. capabilities.
8. 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. These include: allow constraining media streams via SDP. 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 [RFC6184] for example, the H.264 "max-fs" format parameter [RFC6184]
skipping to change at page 16, line 44 skipping to change at page 16, line 44
matches the names of those RID constraints, and SHOULD explicitly matches the names of those RID constraints, and SHOULD explicitly
state what media type parameters are constrained by what RID state what media type parameters are constrained by what RID
constraints. constraints.
10. Formal Grammar 10. 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 "a=rid" 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-id SP rid-dir
[ rid-pt-param-list / rid-param-list ] [ rid-pt-param-list / rid-param-list ]
rid-identifier = 1*(alpha-numeric / "-" / "_") rid-id = 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)
rid-param-list = SP rid-param *(";" rid-param) rid-param-list = SP rid-param *(";" rid-param)
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
skipping to change at page 17, line 37 skipping to change at page 17, line 37
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-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-id *( "," rid-id )
int-param-val = 1*DIGIT int-param-val = 1*DIGIT
float-param-val = 1*DIGIT "." 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 11. SDP Examples
skipping to change at page 18, line 40 skipping to change at page 18, line 40
... ...
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
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rtpmap:98 VP8/90000 a=rtpmap:98 VP8/90000
a=fmtp:98 max-fs=3600; max-fr=30 a=fmtp:98 max-fs=3600; max-fr=30
a=rtpmap:99 VP9/90000 a=rtpmap:99 VP9/90000
a=fmtp:99 max-fs=3600; max-fr=30 a=fmtp:99 max-fs=3600; max-fr=30
a=rtpmap:100 H264/90000 a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42401f; packetization-mode=0 a=fmtp:100 profile-level-id=42401f; packetization-mode=0
a=rtpmap:101 H264/90000 a=rtpmap:101 H264/90000
a=fmtp:101 profile-level-id=42401f; packetization-mode=1 a=fmtp:101 profile-level-id=42401f; packetization-mode=1
a=rtpmap:102 H264/90000 a=rtpmap:102 H264/90000
a=fmtp:102 profile-level-id=640c1f; packetization-mode=0 a=fmtp:102 profile-level-id=640c1f; packetization-mode=0
skipping to change at page 19, line 17 skipping to change at page 19, line 18
a=rtpmap:106 H265/90000 a=rtpmap:106 H265/90000
a=fmtp:106 profile-id=1; level-id=93 a=fmtp:106 profile-id=1; level-id=93
a=rtpmap:107 H265/90000 a=rtpmap:107 H265/90000
a=fmtp:107 profile-id=2; level-id=93 a=fmtp:107 profile-id=2; level-id=93
a=sendrecv a=sendrecv
a=mid:v1 (max resolution) a=mid:v1 (max resolution)
a=rid:1 send max-width=1280;max-height=720;max-fps=30 a=rid:1 send max-width=1280;max-height=720;max-fps=30
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
... ...
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
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
...same rtpmap/fmtp as above... ...same rtpmap/fmtp as above...
a=recvonly a=recvonly
a=mid:v2 (medium resolution) a=mid:v2 (medium resolution)
a=rid:3 recv max-width=640;max-height=360;max-fps=15 a=rid:3 recv max-width=640;max-height=360;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
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
...same rtpmap/fmtp as above... ...same rtpmap/fmtp as above...
a=recvonly a=recvonly
a=mid:v3 (medium resolution) a=mid:v3 (medium resolution)
a=rid:3 recv max-width=640;max-height=360;max-fps=15 a=rid:3 recv max-width=640;max-height=360;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
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
...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
a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
...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)...
... ...
11.2. Scalable Layers 11.2. Scalable Layers
Adding scalable layers to a session within a multiparty conference Adding scalable layers to a session within a multiparty conference
gives a selective forwarding unit (SFU) further flexibility to gives a selective forwarding unit (SFU) further flexibility to
selectively forward packets from a source that best match the selectively forward packets from a source that best match the
bandwidth and capabilities of diverse receivers. Scalable encodings bandwidth and capabilities of diverse receivers. Scalable encodings
skipping to change at page 22, line 18 skipping to change at page 22, line 25
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.
14. 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. Thanks to Colin Perkins for input on future payload Paul Kyzivat. Thanks to Colin Perkins for input on future payload
type handing.. type handing.
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.roach-avtext-rid] [I-D.ietf-avtext-rid]
Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream
Identifier (RID) Source Description (SDES)", draft-roach- Identifier Source Description (SDES)", draft-ietf-avtext-
avtext-rid-02 (work in progress), February 2016. rid-05 (work in progress), July 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 23, line 20 skipping to change at page 23, line 28
15.2. Informative References 15.2. Informative References
[H264] ITU-T Recommendation H.264, "Advanced video coding for [H264] ITU-T Recommendation H.264, "Advanced video coding for
generic audiovisual services (V9)", February 2014, generic audiovisual services (V9)", February 2014,
<http://www.itu.int/rec/T-REC-H.264-201304-I>. <http://www.itu.int/rec/T-REC-H.264-201304-I>.
[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-27 (work in progress), February 2016. negotiation-31 (work in progress), June 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-04 (work in progress), February 2016. mmusic-sdp-simulcast-05 (work in progress), June 2016.
[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>.
[RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP
Payload Format for H.264 Video", RFC 6184, DOI 10.17487/ Payload Format for H.264 Video", RFC 6184, DOI 10.17487/
RFC6184, May 2011, RFC6184, May 2011,
<http://www.rfc-editor.org/info/rfc6184>. <http://www.rfc-editor.org/info/rfc6184>.
 End of changes. 47 change blocks. 
94 lines changed or deleted 93 lines changed or added

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