draft-ietf-mmusic-rid-02.txt   draft-ietf-mmusic-rid-03.txt 
Network Working Group P. Thatcher Network Working Group P. Thatcher
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track M. Zanaty Intended status: Standards Track M. Zanaty
Expires: August 6, 2016 S. Nandakumar Expires: August 8, 2016 S. Nandakumar
Cisco Systems Cisco Systems
B. Burman B. Burman
Ericsson Ericsson
A. Roach A. Roach
B. Campen B. Campen
Mozilla Mozilla
February 03, 2016 February 05, 2016
RTP Payload Format Constraints RTP Payload Format Constraints
draft-ietf-mmusic-rid-02 draft-ietf-mmusic-rid-03
Abstract Abstract
In this specification, we define a framework for identifying RTP In this specification, we define a framework for identifying RTP
Streams with the constraints on its payload format in the Session Streams with the constraints on its payload format in the Session
Description Protocol. This framework defines a new "rid" SDP Description Protocol. This framework defines a new "rid" SDP
attribute to: a) effectively identify the RID RTP Streams within a attribute to: a) effectively identify the RID RTP Streams within a
RTP Session, b) constrain their payload format parameters in a codec- RTP Session, b) constrain their payload format parameters in a codec-
agnostic way beyond what is provided with the regular Payload Types agnostic way beyond what is provided with the regular Payload Types
and c) enable unambiguous mapping between the RID RTP Streams to and c) enable unambiguous mapping between the RID RTP Streams to
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 August 6, 2016. This Internet-Draft will expire on August 8, 2016.
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 37 skipping to change at page 2, line 37
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 . . . . . . . . . . . . . . . . . . 11 7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 11
8. Interaction with Other Techniques . . . . . . . . . . . . . . 12 8. Interaction with Other Techniques . . . . . . . . . . . . . . 12
9. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 12 9. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 13
10. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 14 10. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Many Bundled Streams using Many Codecs . . . . . . . . . 14 10.1. Many Bundled Streams using Many Codecs . . . . . . . . . 14
10.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 16 10.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 16
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Declarative SDP . . . . . . . . . . . . . . . . . . . . 16 11.1. Declarative SDP . . . . . . . . . . . . . . . . . . . . 16
11.2. Definition of bitrate . . . . . . . . . . . . . . . . . 16 11.2. Definition of bitrate . . . . . . . . . . . . . . . . . 17
11.3. Escaping new constraint values . . . . . . . . . . . . . 17 11.3. Escaping new constraint values . . . . . . . . . . . . . 17
11.4. Utility of max-width and max height . . . . . . . . . . 17 11.4. Utility of max-width and max height . . . . . . . . . . 17
11.5. Definition of max-fps . . . . . . . . . . . . . . . . . 18 11.5. Definition of max-fps . . . . . . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 18 12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 18
12.2. Registry for RID-Level Parameters . . . . . . . . . . . 18 12.2. Registry for RID-Level Parameters . . . . . . . . . . . 18
13. Security Considerations . . . . . . . . . . . . . . . . . . . 19 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
15.1. Normative References . . . . . . . . . . . . . . . . . . 20 15.1. Normative References . . . . . . . . . . . . . . . . . . 20
15.2. Informative References . . . . . . . . . . . . . . . . . 20 15.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 Stream" are used as defined in [RFC7656].
[I-D.ietf-avtext-rtp-grouping-taxonomy].
The term "RID RTP Stream" is used as defined in The term "RID RTP Stream" is used as defined in
[I-D.roach-avtext-rid]. [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 Payload Type (PT) in RTP provides a mapping between the RTP payload
format and the associated SDP media description. The SDP rtpmap and/ format and the associated SDP media description. The SDP rtpmap and/
skipping to change at page 3, line 48 skipping to change at page 3, line 47
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 the application usage. In scenarios where
the number of possible RTP payload configurations exceed the the number of possible RTP payload configurations exceed the
available PT space within a RTP Session, there is need a way to available PT space within a RTP Session, there is a need for a way to
represent the additional constraints on payload configurations and to represent the additional constraints on payload configurations and to
effectively map a RID RTP Stream to its corresponding constraints. effectively map a RID RTP Stream to its corresponding constraints.
This 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 into simulcast and layered codecs, which introduce additional streams into
RTP Sessions. RTP Sessions.
This specification defines a new SDP framework for constraining This specification defines a new SDP framework for constraining
Source RTP Streams (Section 2.1.10 Source RTP Streams (Section 2.1.10 [RFC7656]), along with the SDP
[I-D.ietf-avtext-rtp-grouping-taxonomy]), 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 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
new "a=rid" SDP attribute. Note that the constraints communicated
via this attribute only serve to further constrain the parameters
that are established on a PT format. They do not relax any existing
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.roach-avtext-rid] to provide correlation
between the RTP Packets and their format specification in the SDP. between the RTP Packets and their format specification in the SDP.
The additional constraints on individual streams are indicated with a
new "a=rid" SDP attribute. Note that the parameters communicated via
this attribute only serve to further constrain the parameters that
are established on a PT format. They do not relax any existing
constraints.
As described in Section 6.2.1, this mechanism achieves backwards As described in Section 6.2.1, this mechanism achieves backwards
compatibility via the normal SDP processing rules, which require compatibility via the normal SDP processing rules, which require
unknown a= parameters to be ignored. This means that implementations unknown a= lines to be ignored. This means that implementations need
need to be prepared to handle successful offers and answers from to be prepared to handle successful offers and answers from other
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
supported constraints in their offer, abd (b) having answerers ignore supported constraints in their offer, and (b) having answerers ignore
"a=rid" lines that specify unknown constraints. "a=rid" lines that specify unknown constraints.
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". Roughly speaking, this attribute takes the following form
(see Section 9 for a formal definition). (see Section 9 for a formal definition).
a=rid:<rid-identifier> <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-identifier"
This value binds the restriction to the RID RTP Stream identified by field. This value binds the restriction to the RID RTP Stream
its RID SDES item [I-D.roach-avtext-rid]. identified by its RID SDES item [I-D.roach-avtext-rid].
The "direction" parameter identifies the directionality of the RID The "direction" field identifies the directionality of the RID RTP
RTP Stream; it may be either "send" or "recv". Stream; it may be either "send" or "recv".
The optional "pt" parameter 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 parameter is absent, used in the associated RID RTP Stream. If the "a=rid" attribute
then any of the PT values specified in the corresponding "m=" line contains no "pt", then any of the PT values specified in the
may be used. corresponding "m=" line may be used.
The list of zero or more codec-agnostic "constraint" parameters The list of zero or more codec-agnostic constraints (Section 5)
(Section 5) describe the restrictions that the corresponding RID RTP describe the restrictions that the corresponding RID RTP Stream will
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-identifier" MUST NOT be repeated in a given media description
("m=" section). ("m=" 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 parameters 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 attributes, they are syntax similar to session-level and media-level parameters, they are
defined independently. All "rid" parameters 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.
Section 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] Section 9 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" constraints
This section defines the "a=rid" constraints that can be used to This section defines the "a=rid" constraints 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.
skipping to change at page 6, line 39 skipping to change at page 6, line 39
implementation, and instantaneous excursions outside the limit are implementation, and instantaneous excursions outside the limit are
permissible. For any given one-second sliding window, however, permissible. For any given one-second sliding window, however,
the total number of bits in the payload portion of RTP SHOULD NOT the total number of bits in the payload portion of RTP SHOULD NOT
exceed the value specified in "max-br." exceed the value specified in "max-br."
o max-pps, for pixel rate in pixels per second. This value SHOULD o max-pps, for pixel rate in pixels per second. This value SHOULD
be handled identically to max-fps, after performing the following be handled identically to max-fps, after performing the following
conversion: max-fps = max-pps / (width * height). If the stream conversion: max-fps = max-pps / (width * height). If the stream
resolution changes, this value is recalculated. Due to this resolution changes, this value is recalculated. Due to this
recalculation, excursions outside the specified maximum are recalculation, excursions outside the specified maximum are
possible during near resolution change boundaries. possible near resolution change boundaries.
o max-bpp, for maximum number of bits per pixel, calculated as an o max-bpp, for maximum number of bits per pixel, calculated as an
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. 0.0001 to 48.0.
All the constraints are optional and are subject to negotiation based All the constraints are optional and are subject to negotiation based
on the SDP Offer/Answer rules described in Section 6. 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 constraints. Future
documents may define additional constraints; see Section 12.2. While documents may define additional constraints; see Section 12.2. While
this document does not define constraints for audio codecs, there is this document does not define constraints for audio codecs, there is
no reason such constraints should be precluded from definition and no reason such constraints should be precluded from definition and
registration by other documents. registration by other documents.
Section 9 provides formal Augmented Backus-Naur Form(ABNF) [RFC5234] Section 9 provides formal Augmented Backus-Naur Form(ABNF) [RFC5234]
grammar for each of the "a=rid" parameters 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-identifier" values are only required to be unique
within a media section ("m-line"); they do not necessarily need to be within a media section ("m-line"); they do not necessarily need to be
unique within an entire RTP session. In traditional usage, each unique within an entire RTP session. In traditional usage, each
media section is sent on its own unique 5-tuple, which provides an media section is sent on its own unique 5-tuple, which provides an
skipping to change at page 8, line 11 skipping to change at page 8, line 11
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 RID RTP Stream, and adds them to
the "a=rid" line. the "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" attributes will further specific parameters, then the "a=rid" constraints will further
constrain 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 RID 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" For each media description in the offer, and for each "a=rid"
attribute in the media description, the receiver of the offer will attribute in the media description, the receiver of the offer will
skipping to change at page 8, line 48 skipping to change at page 8, line 48
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. Extract the rid-identifier from the "a=rid" line and verify its
uniqueness. In the case of a duplicate, the entire "a=rid" line, uniqueness. In the case of a duplicate, the entire "a=rid" line,
and all "a=rid" lines with rid-identifiers that duplicate this and all "a=rid" lines with rid-identifiers that duplicate this
line, are discarded and MUST NOT be included in the SDP Answer. line, are discarded and MUST NOT be included in the SDP Answer.
2. If the "a=rid" line contains a "pt=" parameter, the list of 2. If the "a=rid" line contains a "pt=", the list of payload types
payload types is verified against the list of valid payload types is verified against the list of valid payload types for the media
for the media section (that is, those listed on the "m=" line). section (that is, those listed on the "m=" line). Any PT missing
Any PT missing from the "m=" line is removed from the "pt=" from the "m=" line is removed from the "pt=".
parameter.
3. The answerer ensures that "a=rid" parameters listed are 3. The answerer ensures that the "a=rid" line is syntactically well
syntactically well formed. In the case of a syntax error, the formed. In the case of a syntax error, the "a=rid" line is
"a=rid" line is removed. removed.
4. If the "direction" parameter is "recv", The answerer ensures that 4. If the "direction" field is "recv", The answerer ensures that
"a=rid" parameters are supported. In the case of an unsupported "a=rid" constraints are supported. In the case of an unsupported
parameter, the "a=rid" line is removed. constraint, the "a=rid" line is removed.
5. If the "depend" parameter 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-identifiers unambiguously match the rid-
identifiers in the SDP offer. Any "a=rid" lines that do not are identifiers in the SDP offer. Any "a=rid" lines that do not are
removed. removed.
6. The answerer verifies that the constraining parameters are 6. The answerer verifies that the constraints are consistent with at
consistent with at least one of the codecs to be used with the least one of the codecs to be used with the RID RTP Stream. If
RID RTP Stream. If the "a=rid" line contains a "pt=" parameter, the "a=rid" line contains a "pt=", it contains the list of such
it contains the list of such codecs; otherwise, the list of such codecs; otherwise, the list of such codecs is taken from the
codecs is taken from the associated "m=" line. See Section 8 for associated "m=" line. See Section 8 for more detail. If the
more detail. If the "a=rid" parameters are incompatible with the "a=rid" constraints are incompatible with the other codec
other codec properties for all codecs, then the "a=rid" line is properties for all codecs, then the "a=rid" line is removed.
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.
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" parameter 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-identifier" present in the
offer. offer.
4. If the "a=rid" line contains a "pt=" parameter, the answerer is 4. If the "a=rid" line contains a "pt=", the answerer is allowed to
allowed to remove one or more media formats from a given "a=rid" remove one or more media formats from a given "a=rid" line. If
line. If the answerer chooses to remove all the media format the answerer chooses to remove all the media format tokens from
tokens from an "a=rid" line, the answerer MUST remove the entire an "a=rid" line, the answerer MUST remove the entire "a=rid"
"a=rid" line. If the offer did not contain a "pt=" parameter for line. If the offer did not contain a "pt=" for a given "a=rid"
a given "a=rid" line, then the answer MUST NOT contain a "pt=" line, then the answer MUST NOT contain a "pt=" in the
parameter 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 remove the corresponding "a=rid" line. This
includes situations in which the answerer does not understand one includes situations in which the answerer does not understand one
or more of the constraints in an "a=rid" line with a direction of or more of the constraints in an "a=rid" line with a direction of
"recv". "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
skipping to change at page 10, line 40 skipping to change at page 10, line 37
line can be located in the offer, the "a=rid" line is ignored. line can be 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=" parameter but 4. If the "a=rid" line in the answer contains a "pt=" but the offer
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=" parameter and 5. If the "a=rid" line in the answer contains a "pt=" and the offer
the offer did as well, the offerer verifies that the list of did as well, the offerer verifies that the list of payload types
payload types is a subset of those sent in the corresponding is a subset of those sent in the corresponding "a=rid" line in
"a=rid" line in the offer. If not, the offerer SHALL discard the the offer. Note that this matching must be performed
"a=rid" line. semantically rather than on literal PT values, as the remote end
may not be using symmetric PTs. For the purpose of this
comparison: for each PT listed on the "a=rid" line in the answer,
the offerer looks up the corresponding "a=rtpmap" and "a=fmtp"
lines in the answer. It then searches the list of "pt=" values
indicated in the offer, and attempts to find one with an
equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If
all PTs in the answer can be matched, then the "pt=" values pass
validation; otherwise, it fails. If this validation fails, the
offerer SHALL discard the "a=rid" line.
6. If the "a=rid" line contains a "pt=" parameter, the offerer 6. If the "a=rid" line contains a "pt=", the offerer verifies that
verifies that the attribute values provided in the "a=rid" the attribute values provided in the "a=rid" attributes are
attributes are consistent with the corresponding codecs and their consistent with the corresponding codecs and their other
other parameters. See Section 8 for more detail. If the "a=rid" parameters. See Section 8 for more detail. If the "a=rid"
parameters are incompatible with the other codec properties, then constraints are incompatible with the other codec properties,
the offerer SHALL discard the "a=rid" line. then the offerer SHALL discard the "a=rid" line.
7. The offerer verifies that the constraining parameters are 7. The offerer verifies that the constraints are consistent with at
consistent with at least one of the codecs to be used with the least one of the codecs to be used with the RID RTP Stream. If
RID RTP Stream. If the "a=rid" line contains a "pt=" parameter, the "a=rid" line contains a "pt=", it contains the list of such
it contains the list of such codecs; otherwise, the list of such codecs; otherwise, the list of such codecs is taken from the
codecs is taken from the associated "m=" line. See Section 8 for associated "m=" line. See Section 8 for more detail. If the
more detail. If the "a=rid" parameters are incompatible with the "a=rid" constraints are incompatible with the other codec
other codec properties for all codecs, then the offerer SHALL properties for all codecs, then the offerer SHALL discard the
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 a RID RTP Stream. The offerer MAY
still apply any constraints it indicated in an "a=rid" line with a still apply any constraints it indicated in an "a=rid" line with a
direction parameter 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.
6.5. Modifying the Session 6.5. Modifying the Session
skipping to change at page 11, line 47 skipping to change at page 12, line 7
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
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" parameter MUST be set to "send" In declarative use, the "direction" field MUST be set to "send" in
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 RID 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 parameters. 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 for example, the H.264 "max-fs" format parameter [RFC6185]
o Size restrictions imposed by image attribute attributes o Size restrictions imposed by image attribute attributes
("a=imgattr") [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
techniques. techniques.
In an offer, this means that "a=rid" lines, when combined with other In an offer, this means that "a=rid" lines, when combined with other
restrictions on the media stream, are expected to result in a non- restrictions on the media stream, are expected to result in a non-
empty union. For example, if image attributes are used to indicate empty union. For example, if image attributes are used to indicate
that a PT has a minimum width of 640, then specification of "max- that a PT has a minimum width of 640, then specification of "max-
width=320" in an "a=rid" line that is then applied to that PT is width=320" in an "a=rid" line that is then applied to that PT is
nonsensical. According to the rules of Section 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=imgattr"), its only recourse is to remove the "a=rid" line "a=imageattr"), its only recourse is to remove 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 constrain the stream beyond what is allowed by other mechanisms, then
the offerer will ignore the corresponding "a=rid" line, as described the offerer will ignore the corresponding "a=rid" line, as described
in Section 6.4. in Section 6.4.
9. Formal Grammar 9. Formal Grammar
This section gives a formal Augmented Backus-Naur Form (ABNF) This section gives a formal Augmented Backus-Naur Form (ABNF)
[RFC5234] grammar for each of the new media and "a=rid" attributes [RFC5234] grammar for each of the new media and "a=rid" attributes
defined in this document. defined in this document.
skipping to change at page 14, line 29 skipping to change at page 14, line 37
o 1 receive stream of 720p resolution is offered for the active o 1 receive stream of 720p resolution is offered for the active
speaker. speaker.
o 2 receive streams of 360p resolution are offered for the prior 2 o 2 receive streams of 360p resolution are offered for the prior 2
active speakers. active speakers.
o 4 receive streams of 180p resolution are offered for others in the o 4 receive streams of 180p resolution are offered for others in the
call. call.
Expressing all these codecs and resolutions using 32 dynamic PTs (2 NOTE: The SDP given below skips a few lines to keep the example short
audio + 10x3 video) would exhaust the primary dynamic space (96-127).
RIDs are used to avoid PT exhaustion and express the resolution
constraints.
NOTE: The SDP given below skips few lines to keep the example short
and focused, as indicated by either the "..." or the comments and focused, as indicated by either the "..." or the comments
inserted. inserted.
The offer for this scenario is shown below. The offer for this scenario is shown below.
... ...
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
skipping to change at page 16, line 13 skipping to change at page 16, line 15
... ...
10.2. Scalable Layers 10.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" parameter. In the example below, the highest resolution is "depend" constraint. In the example below, the highest resolution is
offered to be sent as 2 scalable temporal layers (using MRST). offered to be sent as 2 scalable temporal layers (using MRST).
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)
skipping to change at page 17, line 14 skipping to change at page 17, line 19
If I read correctly, Magnus indicated that the definition in the If I read correctly, Magnus indicated that the definition in the
document is consistent with TIAS, and believes it is sufficiently document is consistent with TIAS, and believes it is sufficiently
well defined. well defined.
PROPOSAL: keep current definition that exists in description of "max- PROPOSAL: keep current definition that exists in description of "max-
br". br".
11.3. Escaping new constraint values 11.3. Escaping new constraint values
The parameters on an "a=rid:" line are extensible. The syntax for The constraints on an "a=rid:" line are extensible. The syntax for
these is: these is:
rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ]
param-val = *( %x20-58 / %x60-7E ) param-val = *( %x20-58 / %x60-7E )
; Any printable character except semicolon ; Any printable character except semicolon
If an extension has values that can contain semicolons, they need an If an extension has values that can contain semicolons, they need an
escaping mechanism. Note that this is not an issue for any currently escaping mechanism. Note that this is not an issue for any currently
defined parameters, as they all take numeric values only. defined constraints, as they all take numeric values only.
1. Change extension syntax to only allow numeric values 1. Change extension syntax to only allow numeric values
2. Define a universal escaping mechanism for all extensions to use 2. Define a universal escaping mechanism for all extensions to use
3. Leave this problem for the first extension parameter - if any - 3. Leave this problem for the first extension constraints - if any -
to define value in a way that might allow a semicolon. Note that to define value in a way that might allow a semicolon. Note that
this approach would allow the use of percent-style escaping this approach would allow the use of percent-style escaping
(e.g., "%3B") but not backslash-style escaping (e.g., "\;"), as (e.g., "%3B") but not backslash-style escaping (e.g., "\;"), as
parsers that do not support the new constraint would interpret parsers that do not support the new constraint would interpret
the embedded semicolon as a separator. the embedded semicolon as a separator.
PROPOSAL: Option #3 PROPOSAL: Option #3
11.4. Utility of max-width and max height 11.4. Utility of max-width and max height
Comment from Stephan Wenger: Are max-width and max-height actually Comment from Stephan Wenger: Are max-width and max-height actually
useful controls? Shouldn't max-fs be sufficient for any plausible useful controls? Shouldn't max-fs be sufficient for any plausible
uses? uses?
PROPOSAL: Keep max-height and max-width. Implementation is well- PROPOSAL: Keep max-height and max-width. Implementation is well-
defined and easily implemented. At least one participant expressed defined and easily implemented. At least one participant expressed
support for these parameters at IETF 94 face-to-face meeting. support for these constraints at IETF 94 face-to-face meeting.
11.5. Definition of max-fps 11.5. Definition of max-fps
Comment from Stephan Wenger: Would it be better to define max-fps as Comment from Stephan Wenger: Would it be better to define max-fps as
constraining the average over a second rather than the inverse of the constraining the average over a second rather than the inverse of the
smallest allowed interval between frames? smallest allowed interval between frames?
PROPOSAL: Keep as currently defined. The difference is subtle. The PROPOSAL: Keep as currently defined. The difference is subtle. The
only kinds of cases allowed by an average that aren't allowed by a only kinds of cases allowed by an average that aren't allowed by a
minimum interframe interval are those such as sending no packets for minimum interframe interval are those such as sending no packets for
skipping to change at page 18, line 31 skipping to change at page 18, line 31
This document defines "rid" as SDP media-level attribute. This This document defines "rid" as SDP media-level attribute. This
attribute must be registered by IANA under "Session Description attribute must be registered by IANA under "Session Description
Protocol (SDP) Parameters" under "att-field (media level only)". Protocol (SDP) Parameters" under "att-field (media level only)".
The "rid" attribute is used to identify characteristics of RTP stream The "rid" attribute is used to identify characteristics of RTP stream
with in a RTP Session. Its format is defined in Section 9. with in a RTP Session. Its format is defined in Section 9.
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" parameters level)" within the SDP parameters registry. The "a=rid" constraints
MUST be registered with IANA and documented under the same rules as MUST be registered with IANA and documented under the same rules as
for SDP session-level and media-level attributes as specified in for SDP session-level and media-level attributes as specified in
[RFC4566]. [RFC4566].
Parameters for "a=rid" lines that modify the nature of encoded media Parameters for "a=rid" lines that modify the nature of encoded media
MUST be of the form that the result of applying the modification to MUST be of the form that the result of applying the modification to
the stream results in a stream that still complies with the other the stream results in a stream that still complies with the other
parameters that affect the media. In other words, parameters always parameters that affect the media. In other words, constraints always
have to restrict the definition to be a subset of what is otherwise have to restrict the definition to be a subset of what is otherwise
allowable, and never expand it. allowable, and never expand it.
New parameter registrations are accepted according to the New constraint 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 parameter name (as it will appear in SDP) o constraint name (as it will appear in SDP)
o long-form parameter name in English o long-form constraint name in English
o whether the parameter value is subject to the charset attribute o whether the constraint value is subject to the charset attribute
o an explanation of the purpose of the parameter o an explanation of the purpose of the constraint
o a specification of appropriate attribute values for this parameter o a specification of appropriate attribute values for this
constraint
o an ABNF definition of the parameter o an ABNF definition of the constraint
The initial set of "a=rid" parameter names, with definitions in The initial set of "a=rid" constraint 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
parameter that contains string values. These extensions need to take constraints that contain string values. These extensions need to
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
in an implementation sending greater amounts of data than a recipient in an implementation sending greater amounts of data than a recipient
skipping to change at page 20, line 15 skipping to change at page 20, line 15
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. Paul Kyzivat.
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.roach-avtext-rid] [I-D.roach-avtext-rid]
Roach, A., Nandakumar, S., and P. Thatcher, "RTP Payload Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream
Format Constraints", draft-roach-avtext-rid-01 (work in Identifier (RID) Source Description (SDES)", draft-roach-
progress), February 2016. avtext-rid-02 (work in progress), February 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, DOI with Session Description Protocol (SDP)", RFC 3264, DOI
10.17487/RFC3264, June 2002, 10.17487/RFC3264, June 2002,
<http://www.rfc-editor.org/info/rfc3264>. <http://www.rfc-editor.org/info/rfc3264>.
skipping to change at page 20, line 45 skipping to change at page 20, line 45
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
RFC5234, January 2008, RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
15.2. Informative References 15.2. Informative References
[I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, "A Taxonomy of Semantics and Mechanisms for
Real-Time Transport Protocol (RTP) Sources", draft-ietf-
avtext-rtp-grouping-taxonomy-08 (work in progress), July
2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-25 (work in progress), January 2016. negotiation-25 (work in progress), January 2016.
[I-D.ietf-mmusic-sdp-simulcast] [I-D.ietf-mmusic-sdp-simulcast]
Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
"Using Simulcast in SDP and RTP Sessions", draft-ietf- "Using Simulcast in SDP and RTP Sessions", draft-ietf-
mmusic-sdp-simulcast-04 (work in progress), February 2016. mmusic-sdp-simulcast-04 (work in progress), February 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>.
[RFC6185] Kristensen, T. and P. Luthi, "RTP Payload Format for H.264
Reduced-Complexity Decoding Operation (RCDO) Video", RFC
6185, DOI 10.17487/RFC6185, May 2011,
<http://www.rfc-editor.org/info/rfc6185>.
[RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image
Attributes in the Session Description Protocol (SDP)", RFC Attributes in the Session Description Protocol (SDP)", RFC
6236, DOI 10.17487/RFC6236, May 2011, 6236, DOI 10.17487/RFC6236, May 2011,
<http://www.rfc-editor.org/info/rfc6236>. <http://www.rfc-editor.org/info/rfc6236>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>.
Authors' Addresses Authors' Addresses
Peter Thatcher Peter Thatcher
Google Google
Email: pthatcher@google.com Email: pthatcher@google.com
Mo Zanaty Mo Zanaty
Cisco Systems Cisco Systems
 End of changes. 60 change blocks. 
132 lines changed or deleted 137 lines changed or added

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