draft-ietf-mmusic-rid-07.txt   draft-ietf-mmusic-rid-08.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: January 19, 2017 Cisco Systems Expires: April 28, 2017 Cisco Systems
B. Burman B. Burman
Ericsson Ericsson
A. Roach A. Roach
B. Campen B. Campen
Mozilla Mozilla
July 18, 2016 October 25, 2016
RTP Payload Format Constraints RTP Payload Format Restrictions
draft-ietf-mmusic-rid-07 draft-ietf-mmusic-rid-08
Abstract Abstract
In this specification, we define a framework for specifying In this specification, we define a framework for specifying
constraints on RTP streams in the Session Description Protocol. This restrictions on RTP streams in the Session Description Protocol.
framework defines a new "rid" SDP attribute to unambiguously identify This framework defines a new "rid" SDP attribute to unambiguously
the RTP Streams within a RTP Session and constrain the streams' identify the RTP Streams within a RTP Session and restrict the
payload format parameters in a codec-agnostic way beyond what is streams' payload format parameters in a codec-agnostic way beyond
provided with the regular Payload Types. what is provided with the regular Payload Types.
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. restrictions 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 January 19, 2017. This Internet-Draft will expire on April 28, 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 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . 4 4. SDP "a=rid" Media Level Attribute . . . . . . . . . . . . . . 4
5. "a=rid" constraints . . . . . . . . . . . . . . . . . . . . . 6 5. "a=rid" restrictions . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 9 6.2.2. "a=rid"-aware Answerer . . . . . . . . . . . . . . . 9
6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 10 6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 10
6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10
6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 12 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 12
7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 12 7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 12
8. Interaction with Other Techniques . . . . . . . . . . . . . . 12 8. Interaction with Other Techniques . . . . . . . . . . . . . . 12
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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].
[RFC4566] and [RFC3264] terminology is also used where appropriate. [RFC4566] and [RFC3264] terminology is also used where appropriate.
2. Introduction 2. Introduction
The Payload Type (PT) field in RTP provides a mapping between the RTP The Payload Type (PT) field in RTP provides a mapping between the RTP
payload format and the associated SDP media description. The SDP payload format and the associated SDP media description. The SDP
rtpmap and/or fmtp attributes are used, for a given PT, to the rtpmap and/or fmtp attributes are used, for a given PT, to the
describe the characteristics of the media that is carried in the RTP describe the properties of the media that is carried in the RTP
payload. 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 5 skipping to change at page 4, line 5
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 application usage. In scenarios where the type numbers available for application usage. In scenarios where the
number of possible RTP payload configurations exceed the available PT number of possible RTP payload configurations exceed the available PT
space within a RTP Session, there is a need for a way to represent space within a RTP Session, there is a need for a way to represent
the additional constraints on payload configurations and to the additional restrictions on payload configurations and to
effectively map an RTP Stream to its corresponding constraints. This effectively map an RTP Stream to its corresponding restrictions.
issue is exacerbated by the increase in techniques - such as This issue is exacerbated by the increase in techniques - such as
simulcast and layered codecs - which introduce additional streams simulcast and layered codecs - which introduce additional streams
into RTP Sessions. into RTP Sessions.
This specification defines a new SDP framework for constraining This specification defines a new SDP framework for restricting Source
Source RTP Streams (Section 2.1.10 [RFC7656]), along with the SDP RTP Streams (Section 2.1.10 [RFC7656]), along with the SDP attributes
attributes to constrain payload formats in a codec-agnostic way. to restrict payload formats in a codec-agnostic way. This framework
This framework can be thought of as a complementary extension to the can be thought of as a complementary extension to the way the media
way the media format parameters are specified in SDP today, via the format parameters are specified in SDP today, via the "a=fmtp"
"a=fmtp" attribute. attribute.
The additional constraints on individual streams are indicated with a The additional restrictions on individual streams are indicated with
new "a=rid" SDP attribute. Note that the constraints communicated a new "a=rid" SDP attribute. Note that the restrictions communicated
via this attribute only serve to further constrain the parameters via this attribute only serve to further restrict the parameters that
that are established on a PT format. They do not relax any existing 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.ietf-avtext-rid] to provide correlation between item defined in [I-D.ietf-avtext-rid] to provide correlation 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 restrictions
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
supported constraints in their offer, and (b) having answerers ignore supported restrictions in their offer, and (b) having answerers
"a=rid" lines that specify unknown constraints. ignore "a=rid" lines that specify unknown restrictions.
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", ("restriction identifier") used to communicate a set of "a=rid", ("restriction identifier") used to communicate a set of
restrictions to be applied an identified RTP Stream. Roughly restrictions to be applied an identified RTP Stream. Roughly
speaking, this attribute takes the following form (see Section 10 for speaking, this attribute takes the following form (see Section 10 for
a formal definition). a formal definition).
a=rid:<rid-id> <direction> [pt=<fmt-list>;]<constraint>=<value>... a=rid:<rid-id> <direction> [pt=<fmt-list>;]<restriction>=<value>...
An "a=rid" SDP media attribute specifies constraints defining a An "a=rid" SDP media attribute specifies restrictions defining a
unique RTP payload configuration identified via the "rid-id" field. unique RTP payload configuration identified via the "rid-id" field.
This value binds the restriction to the RTP Stream identified by its This value binds the restriction to the RTP Stream identified by its
RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. To be clear, RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. To be clear,
implementations that use the "a=rid" parameter in SDP MUST support implementations that use the "a=rid" parameter in SDP MUST support
the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such
implementations MUST send it for all streams in an m-section that has implementations MUST send it for all streams in an m-section that has
"a=rid" lines remaining after applying the rules in Section 6 and its "a=rid" lines remaining after applying the rules in Section 6 and its
subsections. subsections.
The "direction" field identifies the directionality of the 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 RTP Stream. If the "a=rid" attribute contains used in the associated RTP Stream. If the "a=rid" attribute contains
no "pt", then any of the PT values specified in the corresponding no "pt", then any of the PT values specified in the 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 restrictions (Section 5)
describe the restrictions that the corresponding 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" restrictions
further constrain the equivalent "a=fmtp" attributes. (Section 5) further restrict 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-id" MUST NOT be repeated in a given media description ("m=" "rid-id" MUST NOT be repeated in a given media description ("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 restrictions specified by the "rid" restrictions 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" restrictions MUST be registered
IANA, using the registry defined in Section 12. with IANA, using the registry defined in Section 12.
Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234]
grammar for the "rid" attribute. The "a=rid" media attribute is not grammar for the "rid" attribute. The "a=rid" media attribute is not
dependent on charset. dependent on charset.
5. "a=rid" constraints 5. "a=rid" restrictions
This section defines the "a=rid" constraints that can be used to This section defines the "a=rid" restrictions that can be used to
restrict 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 restrictions 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
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-fps, for frame rate in frames per second. For encoders that o max-fps, for frame rate in frames per second. For encoders that
do not use a fixed framerate for encoding, this value should do not use a fixed framerate for encoding, this value should
constrain the minimum amount of time between frames: the time restrict the minimum amount of time between frames: the time
between any two consecutive frames SHOULD NOT be less than 1/max- between any two consecutive frames SHOULD NOT be less than 1/max-
fps seconds. fps seconds.
o max-fs, for frame size in pixels per frame. This is the product o max-fs, for frame size in pixels per frame. This is the product
of frame width and frame height, in pixels, for rectangular of frame width and frame height, in pixels, for rectangular
frames. frames.
o max-br, for bit rate in bits per second. The restriction applies o max-br, for bit rate in bits per second. The restriction applies
to the media payload only, and does not include overhead to the media payload only, and does not include overhead
introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The introduced by other layers (e.g., RTP, UDP, IP, or Ethernet). The
skipping to change at page 7, line 16 skipping to change at page 7, line 16
average of all samples of any given coded picture. This is average of all samples of any given coded picture. This is
expressed as a floating point value, with an allowed range of expressed as a floating point value, with an allowed range of
0.0001 to 48.0. These values MUST be encoded with at most four 0.0001 to 48.0. These values MUST be encoded with at most four
digits to the right of the decimal point. digits to the right of the decimal point.
o depend, to identify other streams that the stream depends on. The o depend, to identify other streams that the stream depends on. The
value is a comma-separated list of rid-ids. These rid-ids value is a comma-separated list of rid-ids. These rid-ids
identify RTP streams that this stream depends on in order to allow identify RTP streams that this stream depends on in order to allow
for proper interpretation. for proper interpretation.
All the constraints are optional and are subject to negotiation based All the restrictions are optional and are subject to negotiation
on the SDP Offer/Answer rules described in Section 6. based on the SDP Offer/Answer rules described in Section 6.
This list is intended to be an initial set of constraints. Future This list is intended to be an initial set of restrictions. Future
documents may define additional constraints; see Section 12.2. While documents may define additional restrictions; see Section 12.2.
this document does not define constraints for audio codecs or any While this document does not define restrictions for audio codecs or
media types other than video, there is no reason such constraints any media types other than video, there is no reason such
should be precluded from definition and registration by other restrictions should be precluded from definition and registration by
documents. other documents.
Section 10 provides formal Augmented Backus-Naur Form (ABNF) Section 10 provides formal Augmented Backus-Naur Form (ABNF)
[RFC5234] grammar for each of the "a=rid" constraints defined in this [RFC5234] grammar for each of the "a=rid" restrictions defined in
section. 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-id" values are only required to be unique within a Note that "rid-id" values are only required to be unique within a
media section ("m-line"); they do not necessarily need to be unique media section ("m-line"); they do not necessarily need to be unique
within an entire RTP session. In traditional usage, each media within an entire RTP session. In traditional usage, each 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
skipping to change at page 8, line 21 skipping to change at page 8, line 21
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 RTP corresponding to RTP payload types) allowed to appear in the RTP
Stream. Any Payload Types chosen MUST be a valid payload type Stream. Any Payload Types chosen MUST be a valid payload type
for the media section (that is, it must be listed on the "m=" for the media section (that is, it must be listed on the "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" restrictions
(Section 5) to be applied to the RTP Stream, and adds them to the (Section 5) to be applied to the RTP Stream, and adds them to 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 restriction, but does not wish to set a value itself, it
include the name of the constraint in the "a=rid" line, but includes the name of the restriction 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" restrictions 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 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
6.2.1. "a=rid"-unaware Answerer 6.2.1. "a=rid"-unaware Answerer
skipping to change at page 9, line 13 skipping to change at page 9, line 13
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. The answerer ensures that the "a=rid" line is syntactically well 1. The answerer ensures that the "a=rid" line is syntactically well
formed. In the case of a syntax error, the "a=rid" line is formed. In the case of a syntax error, the "a=rid" line is
removed. discarded.
2. Extract the rid-id from the "a=rid" line and verify its 2. Extract the rid-id from the "a=rid" line and verify its
uniqueness within a media section. In the case of a duplicate, 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 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 duplicate this line, are discarded and MUST NOT be included in
the SDP Answer. the SDP Answer.
3. If the "a=rid" line contains a "pt=", the list of payload types 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 set of values in the from the "m=" line is discarded from the set of values in the
"pt=". If no values are left in the "pt=" parameter after this "pt=". If no values are left in the "pt=" parameter after this
processing, then the "a=rid" line is removed. processing, then the "a=rid" line is discarded.
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" restrictions are supported. In the case of an
constraint, the "a=rid" line is removed. unsupported restriction, the "a=rid" line is discarded.
5. If the "depend" constraint is included, the answerer MUST make 5. If the "depend" restriction is included, the answerer MUST make
sure that the listed rid-ids unambiguously match the rid-ids in sure that the listed rid-ids unambiguously match the rid-ids in
the SDP offer. Any "a=rid" lines that do not are removed. the SDP offer. Any "a=rid" lines that do not are discarded.
6. The answerer verifies that the constraints are consistent with at 6. The answerer verifies that the restrictions are consistent with
least one of the codecs to be used with the RTP Stream. If the at least one of the codecs to be used with the RTP Stream. If
"a=rid" line contains a "pt=", it contains the list of such the "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" restrictions 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 discarded.
Note that the answerer does not need to understand every constraint Note that the answerer does not need to understand every restriction
present in a "send" line: if a stream sender constrains the stream in present in a "send" line: if a stream sender restricts 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.
6.3. Generating the SDP Answer 6.3. Generating the SDP Answer
Having performed verification of the SDP offer as described in Having performed verification of the SDP offer as described in
Section 6.2.2, the answerer shall perform the following steps to Section 6.2.2, the answerer shall perform the following steps to
generate the SDP answer. generate the SDP answer.
For each "a=rid" line: For each "a=rid" line:
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" restriction
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 restricted than the ones specified in the offer. The
answer MUST NOT include any constraints that were not present in answer MUST NOT include any restrictions that were not present in
the offer. the offer.
3. The answerer MUST NOT modify the "rid-id" present in the offer. 3. The answerer MUST NOT modify the "rid-id" present in the 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 discard 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 discard 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 discard 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
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 discard 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 an "a=rid" line with a direction of or more of the restrictions in an "a=rid" line with a direction
"recv". of "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 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-id". If no matching line can be line in the offer using the "rid-id". If no matching 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 restrictions 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 restrictions 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
did not, the offerer SHALL discard the "a=rid" line. did not, the offerer SHALL discard the "a=rid" line.
5. If the "a=rid" line in the answer contains a "pt=" and the offer 5. If the "a=rid" line in the answer contains a "pt=" and the offer
did as well, the offerer verifies that the list of payload types did as well, the offerer verifies that the list of payload types
is a subset of those sent in the corresponding "a=rid" line in is a subset of those sent in the corresponding "a=rid" line in
skipping to change at page 11, line 35 skipping to change at page 11, line 35
validation; otherwise, it fails. If this validation fails, the validation; otherwise, it fails. If this validation fails, the
offerer SHALL discard the "a=rid" line. Note that this semantic offerer SHALL discard the "a=rid" line. Note that this semantic
comparison necessarily requires an understanding of the meaning comparison necessarily requires an understanding of the meaning
of codec parameters, rather than a rote byte-wise comparison of of codec parameters, rather than a rote byte-wise comparison of
their values. their values.
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, restrictions 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 restrictions are consistent with at
least one of the codecs to be used with the RTP Stream. If the least one of the codecs to be used with the RTP Stream. If 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" restrictions 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 an RTP Stream. The offerer MAY still the negotiated restrictions on an RTP Stream. The offerer MAY still
apply any constraints it indicated in an "a=rid" line with a apply any restrictions 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 restrictions. 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. restrictions have been applied.
6.5. Modifying the Session 6.5. Modifying the Session
Offers and answers inside an existing session follow the rules for Offers and answers inside an existing session follow the rules for
initial session negotiation. Such an offer MAY propose a change in initial session negotiation. Such an offer MAY propose a change in
the number of RIDs in use. To avoid race conditions with media, any 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 RIDs with proposed changes SHOULD use a new ID, rather than re-using
one from the previous offer/answer exchange. RIDs without proposed one from the previous offer/answer exchange. RIDs without proposed
changes SHOULD re-use the ID from the previous exchange. changes SHOULD re-use the ID from the previous exchange.
7. Use with Declarative SDP 7. Use with Declarative SDP
This document does not define the use of RID in declarative SDP. If This document does not define the use of RID in declarative SDP. If
concrete use cases for RID in declarative SDP use are identified in concrete use cases for RID in declarative SDP use are identified in
the future, we expect that additional specifications will address the future, we expect that additional specifications will address
such use. such use.
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 restricting 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]
o Size restrictions imposed by image attribute attributes o Size restrictions imposed by image attribute attributes
("a=imageattr") [RFC6236] ("a=imageattr") [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
skipping to change at page 13, line 10 skipping to change at page 13, line 10
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 6.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.
In 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=imageattr"), its only recourse is to remove the "a=rid" line "a=imageattr"), its only recourse is to discard the "a=rid" line
altogether, as described in Section 6.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 restrict 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 6.4. in Section 6.4.
The following subsections demonstrate these interactions using The following subsections demonstrate these interactions using
commonly-used video codecs. These descriptions are illustrative of commonly-used video codecs. These descriptions are illustrative of
the interaction principles outlined above, and are not normative. the interaction principles outlined above, and are not normative.
8.1. Interaction with VP8 Format Parameters 8.1. Interaction with VP8 Format Parameters
[RFC7741] defines two format parameters for the VP8 codec. Both [RFC7741] defines two format parameters for the VP8 codec. Both
correspond to constraints on receiver capabilities, and never correspond to restrictions on receiver capabilities, and never
indicate sending constraints. indicate sending restrictions.
8.1.1. max-fr - Maximum Framerate 8.1.1. max-fr - Maximum Framerate
The VP8 "max-fr" format parameter corresponds to the "max-fps" The VP8 "max-fr" format parameter corresponds to the "max-fps"
constraint defined in this specification. If an RTP sender is restriction defined in this specification. If an RTP sender is
generating a stream using a format defined with this format generating a stream using a format defined with this format
parameter, and the sending constraints defined via "a=rid" include a parameter, and the sending restrictions defined via "a=rid" include a
"max-fps" parameter, then the sent stream is will conform to the "max-fps" parameter, then the sent stream is will conform to the
smaller of the two values. smaller of the two values.
8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks
The VP8 "max-fs" format parameter corresponds to the "max-fs" The VP8 "max-fs" format parameter corresponds to the "max-fs"
constraint defined in this document, by way of a conversion factor of restriction defined in this document, by way of a conversion factor
the number of pixels per macroblock (typically 256). If an RTP of the number of pixels per macroblock (typically 256). If an RTP
sender is generating a stream using a format defined with this format sender is generating a stream using a format defined with this format
parameter, and the sending constraints defined via "a=rid" include a parameter, and the sending restrictions defined via "a=rid" include a
"max-fs" parameter, then the sent stream will conform to the smaller "max-fs" parameter, then the sent stream will conform to the smaller
of the two values; that is, the number of pixels per frame will not of the two values; that is, the number of pixels per frame will not
exceed: exceed:
min(rid_max_fs, fmtp_max_fs * macroblock_size) min(rid_max_fs, fmtp_max_fs * macroblock_size)
This fmtp parameter also has bearing on the max-height and max-width This fmtp parameter also has bearing on the max-height and max-width
parameters. Section 6.1 of [RFC7741] requires that the width and parameters. Section 6.1 of [RFC7741] requires that the width and
height of the frame in macroblocks are also required to be less than height of the frame in macroblocks are also required to be less than
int(sqrt(fmtp_max_fs * 8)). Accordingly, the maximum width of a int(sqrt(fmtp_max_fs * 8)). Accordingly, the maximum width of a
skipping to change at page 14, line 15 skipping to change at page 14, line 15
min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width) min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width)
Similarly, the stream's height will be limited to: Similarly, the stream's height will be limited to:
min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height) min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height)
8.2. Interaction with H.264 Format Parameters 8.2. Interaction with H.264 Format Parameters
[RFC6184] defines format parameters for the H.264 video codec. The [RFC6184] defines format parameters for the H.264 video codec. The
majority of these parameters do not correspond to codec-independent majority of these parameters do not correspond to codec-independent
constraints: restrictions:
o deint-buf-cap o deint-buf-cap
o in-band-parameter-sets o in-band-parameter-sets
o level-asymmetry-allowed o level-asymmetry-allowed
o max-rcmd-nalu-size o max-rcmd-nalu-size
o max-cpb o max-cpb
skipping to change at page 14, line 52 skipping to change at page 14, line 52
o sprop-level-parameter-sets o sprop-level-parameter-sets
o sprop-max-don-diff o sprop-max-don-diff
o sprop-parameter-sets o sprop-parameter-sets
o use-level-src-parameter-sets o use-level-src-parameter-sets
Note that the max-cpb and max-dpb format parameters for H.264 Note that the max-cpb and max-dpb format parameters for H.264
correspond to constraints on the stream, but they are specific to the correspond to restrictions on the stream, but they are specific to
way the H.264 codec operates, and do not have codec-independent the way the H.264 codec operates, and do not have codec-independent
equivalents. equivalents.
The following codec format parameters correspond to constraints on The following codec format parameters correspond to restrictions on
receiver capabilities, and never indicate sending constraints. receiver capabilities, and never indicate sending restrictions.
8.2.1. profile-level-id and max-recv-level - Negotiated Sub-Profile 8.2.1. profile-level-id and max-recv-level - Negotiated Sub-Profile
These parameters include a "level" indicator, which acts as an index These parameters include a "level" indicator, which acts as an index
into Table A-1 of [H264]. This table contains a number of into Table A-1 of [H264]. This table contains a number of
parameters, several of which correspond to the constraints defined in parameters, several of which correspond to the restrictions defined
this document. [RFC6184] also defines formate parameters for the in this document. [RFC6184] also defines formate parameters for the
H.264 codec that may increase the maximum values indicated by the H.264 codec that may increase the maximum values indicated by the
negotiated level. The following sections describe the interaction negotiated level. The following sections describe the interaction
between these parameters and the constraints defined by this between these parameters and the restrictions defined by this
document. In all cases, the H.264 parameters being discussed are the document. In all cases, the H.264 parameters being discussed are the
maximum of those indicated by [H264] Table A-1 and those indicated in maximum of those indicated by [H264] Table A-1 and those indicated in
the corresponding "a=fmtp" line. the corresponding "a=fmtp" line.
8.2.2. max-br / MaxBR - Maximum Video Bitrate 8.2.2. max-br / MaxBR - Maximum Video Bitrate
The H.264 "MaxBR" parameter (and its equivalent "max-br" format The H.264 "MaxBR" parameter (and its equivalent "max-br" format
parameter) corresponds to the "max-bps" constraint defined in this parameter) corresponds to the "max-bps" restriction defined in this
specification, by way of a conversion factor of 1000 or 1200; see specification, by way of a conversion factor of 1000 or 1200; see
[RFC6184] for details regarding which factor gets used under [RFC6184] for details regarding which factor gets used under
differing circumstances. differing circumstances.
If an RTP sender is generating a stream using a format defined with If an RTP sender is generating a stream using a format defined with
this format parameter, and the sending constraints defined via this format parameter, and the sending restrictions defined via
"a=rid" include a "max-fps" parameter, then the sent stream is will "a=rid" include a "max-fps" parameter, then the sent stream is will
conform to the smaller of the two values - that is: conform to the smaller of the two values - that is:
min(rid_max_br, h264_MaxBR * conversion_factor) min(rid_max_br, h264_MaxBR * conversion_factor)
8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks
The H.264 "MaxFs" parameter (and its equiavelent "max-fs" format The H.264 "MaxFs" parameter (and its equiavelent "max-fs" format
parameter) corresponds roughly to the "max-fs" constraint defined in parameter) corresponds roughly to the "max-fs" restriction defined in
this document, by way of a conversion factor of 256 (the number of this document, by way of a conversion factor of 256 (the number of
pixels per macroblock). pixels per macroblock).
If an RTP sender is generating a stream using a format defined with If an RTP sender is generating a stream using a format defined with
this format parameter, and the sending constraints defined via this format parameter, and the sending restrictions defined via
"a=rid" include a "max-fs" parameter, then the sent stream is will "a=rid" include a "max-fs" parameter, then the sent stream is will
conform to the smaller of the two values - that is: conform to the smaller of the two values - that is:
min(rid_max_fs, h264_MaxFs * 256) min(rid_max_fs, h264_MaxFs * 256)
8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate
The H.264 "MaxMBPS" parameter (and its equiavelent "max-mbps" format The H.264 "MaxMBPS" parameter (and its equiavelent "max-mbps" format
parameter) corresponds roughly to the "max-pps" constraint defined in parameter) corresponds roughly to the "max-pps" restriction defined
this document, by way of a conversion factor of 256 (the number of in this document, by way of a conversion factor of 256 (the number of
pixels per macroblock). pixels per macroblock).
If an RTP sender is generating a stream using a format defined with If an RTP sender is generating a stream using a format defined with
this format parameter, and the sending constraints defined via this format parameter, and the sending restrictions defined via
"a=rid" include a "max-pps" parameter, then the sent stream is will "a=rid" include a "max-pps" parameter, then the sent stream is will
conform to the smaller of the two values - that is: conform to the smaller of the two values - that is:
min(rid_max_pps, h264_MaxMBPS * 256) min(rid_max_pps, h264_MaxMBPS * 256)
8.2.5. max-smbps - Maximum Decoded Picture Buffer 8.2.5. max-smbps - Maximum Decoded Picture Buffer
The H.264 "max-smbps" format parameter operates the same way as the The H.264 "max-smbps" format parameter operates the same way as the
"max-mpbs" format parameter, under the hypothetical assumption that "max-mpbs" format parameter, under the hypothetical assumption that
all macroblocks are static macroblocks. It is handled by applying all macroblocks are static macroblocks. It is handled by applying
the conversion factor described in Section 8.1 of [RFC6184], and the the conversion factor described in Section 8.1 of [RFC6184], and the
result of this conversion is applied as described in Section 8.2.4. result of this conversion is applied as described in Section 8.2.4.
9. Format Parameters for Future Payloads 9. Format Parameters for Future Payloads
Registrations of future RTP payload format specifications that define Registrations of future RTP payload format specifications that define
media types that have parameters matching the RID constraints media types that have parameters matching the RID restrictions
specified in this memo SHOULD name those parameters in a manner that specified in this memo SHOULD name those parameters in a manner that
matches the names of those RID constraints, and SHOULD explicitly matches the names of those RID restrictions, and SHOULD explicitly
state what media type parameters are constrained by what RID state what media type parameters are restricted by what RID
constraints. restrictions.
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-id 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 ]
skipping to change at page 20, line 13 skipping to change at page 20, line 13
... ...
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
have dependencies between layers, unlike independent simulcast have dependencies between layers, unlike independent simulcast
streams. RIDs can be used to express these dependencies using the streams. RIDs can be used to express these dependencies using the
"depend" constraint. In the example below, the highest resolution is "depend" restriction. In the example below, the highest resolution
offered to be sent as 2 scalable temporal layers (using MRST). See is offered to be sent as 2 scalable temporal layers (using MRST).
[I-D.ietf-mmusic-sdp-simulcast] for additional detail about simulcast See [I-D.ietf-mmusic-sdp-simulcast] for additional detail about
usage. simulcast usage.
Offer: Offer:
... ...
m=audio ...same as previous example ... m=audio ...same as previous example ...
... ...
m=video ...same as previous example ... m=video ...same as previous example ...
...same rtpmap/fmtp as previous example ... ...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
skipping to change at page 20, line 40 skipping to change at page 20, line 40
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 previous example for mid:v2-v7... ...same m=video sections as previous example for mid:v2-v7...
... ...
12. IANA Considerations 12. IANA Considerations
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 RID choice of Format Parameter (fmtp) names, and on their relation to RID
constraints. restrictions.
12.1. New SDP Media-Level attribute 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 properties of RTP stream with
with in a RTP Session. Its format is defined in Section 10. in a RTP Session. Its format is defined in Section 10.
The formal registration information for this attribute follows. The formal registration information for this attribute follows.
Contact name, email address, and telephone number Contact name, email address, and telephone number
IETF MMUSIC Working Group IETF MMUSIC Working Group
mmusic@ietf.org mmusic@ietf.org
+1 510 492 4080 +1 510 492 4080
Attribute name (as it will appear in SDP) Attribute name (as it will appear in SDP)
skipping to change at page 21, line 30 skipping to change at page 21, line 30
Media Level Media Level
Whether the attribute value is subject to the charset attribute Whether the attribute value is subject to the charset attribute
The attribute is not dependent on charset. The attribute is not dependent on charset.
A one-paragraph explanation of the purpose of the attribute A one-paragraph explanation of the purpose of the attribute
The "rid" SDP attribute is used to to unambiguously identify The "rid" SDP attribute is used to to unambiguously identify
the RTP Streams within a RTP Session and constrain the the RTP Streams within a RTP Session and restrict the
streams' payload format parameters in a codec-agnostic way streams' payload format parameters in a codec-agnostic way
beyond what is provided with the regular Payload Types. beyond what is provided with the regular Payload Types.
A specification of appropriate attribute values for this attribute A specification of appropriate attribute values for this attribute
Valid values are defined by the ABNF in [RFCXXXXX] Valid values are defined by the ABNF in [RFCXXXXX]
12.2. 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 "a=rid" constraints level)" within the SDP parameters registry. The "a=rid" restrictions
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, constraints always parameters that affect the media. In other words, restrictions
have to restrict the definition to be a subset of what is otherwise always have to restrict the definition to be a subset of what is
allowable, and never expand it. otherwise allowable, and never expand it.
New constraint registrations are accepted according to the New restriction registrations are accepted according to the
"Specification Required" policy of [RFC5226], provided that the "Specification Required" policy of [RFC5226], provided that the
specification includes the following information: specification includes the following information:
o contact name, email address, and telephone number o contact name, email address, and telephone number
o constraint name (as it will appear in SDP) o restriction name (as it will appear in SDP)
o long-form constraint name in English o long-form restriction name in English
o whether the constraint value is subject to the charset attribute o whether the restriction value is subject to the charset attribute
o an explanation of the purpose of the constraint o an explanation of the purpose of the restriction
o a specification of appropriate attribute values for this o a specification of appropriate attribute values for this
constraint restriction
o an ABNF definition of the constraint o an ABNF definition of the restriction
The initial set of "a=rid" constraint names, with definitions in The initial set of "a=rid" restriction names, with definitions in
Section 5 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] 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
constraints that contain string values. These extensions need to restrictions that contain string values. These extensions need to
take care to conform to the ABNF defined for rid-param-other. In take 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.
13. Security Considerations 13. 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
skipping to change at page 23, line 27 skipping to change at page 23, line 27
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.ietf-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 Source Description (SDES)", draft-ietf-avtext- Identifier Source Description (SDES)", draft-ietf-avtext-
rid-05 (work in progress), July 2016. rid-09 (work in progress), October 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 24, line 20 skipping to change at page 24, line 20
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-31 (work in progress), June 2016. negotiation-35 (work in progress), October 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-05 (work in progress), June 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>.
 End of changes. 89 change blocks. 
139 lines changed or deleted 139 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/