draft-ietf-mmusic-rid-01.txt   draft-ietf-mmusic-rid-02.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 4, 2016 S. Nandakumar Expires: August 6, 2016 S. Nandakumar
Cisco Systems Cisco Systems
B. Burman B. Burman
Ericsson Ericsson
A. Roach A. Roach
B. Campen B. Campen
Mozilla Mozilla
February 01, 2016 February 03, 2016
RTP Payload Format Constraints RTP Payload Format Constraints
draft-ietf-mmusic-rid-01 draft-ietf-mmusic-rid-02
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 4, 2016. This Internet-Draft will expire on August 6, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Key Words for Requirements . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 5 5. "a=rid" constraints . . . . . . . . . . . . . . . . . . . . . 5
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. 'rid' unaware Answerer . . . . . . . . . . . . . . . 8 6.2.1. "a=rid"-unaware Answerer . . . . . . . . . . . . . . 8
6.2.2. '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 . . . . . . . . . . . . . . 11 8. Interaction with Other Techniques . . . . . . . . . . . . . . 12
9. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 12 9. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 12
10. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 13 10. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Many Bundled Streams using Many Codecs . . . . . . . . . 13 10.1. Many Bundled Streams using Many Codecs . . . . . . . . . 14
10.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . 16
11.3. Escaping new constraint values . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . 19 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
15.1. Normative References . . . . . . . . . . . . . . . . . . 19 15.1. Normative References . . . . . . . . . . . . . . . . . . 20
15.2. Informative References . . . . . . . . . . . . . . . . . 20 15.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Terminology
Payload Type (PT) in RTP provides a mapping between the format of the The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP
RTP payload and the media format description specified in the Stream" are used as defined in
signaling. For applications that use SDP for signaling, the [I-D.ietf-avtext-rtp-grouping-taxonomy].
constructs rtpmap and/or fmtp describe the characteristics of the
media that is carried in the RTP payload, mapped to a given PT. The term "RID RTP Stream" is used as defined in
[I-D.roach-avtext-rid].
[RFC4566] and [RFC3264] terminology is also used where appropriate.
2. Introduction
Payload Type (PT) in RTP provides a mapping between the RTP payload
format and the associated SDP media description. The SDP 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 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,
o The codec-specific constructs for the payload formats in SDP, o The codec-specific constructs for the payload formats in SDP,
o Missing or underspecified payload format parameters, o Missing or underspecified payload format parameters,
o Overloading of PTs to indicate not just codec configurations, but o Overloading of PTs to indicate not just codec configurations, but
individual streams within an RTP session. individual streams within an RTP session.
To expand on these points: [RFC3550] assigns 7 bits for the PT in the To expand on these points: [RFC3550] assigns 7 bits for the PT in the
RTP header. However, the assignment of static mapping of payload RTP header. However, the assignment of static mapping of RTP payload
codes to payload formats and multiplexing of RTP with other protocols type numbers to payload formats and multiplexing of RTP with other
(such as RTCP) could result in limited number of payload type numbers protocols (such as RTCP) could result in limited number of payload
available for the application usage. In scenarios where the number type numbers available for the application usage. In scenarios where
of possible RTP payload configurations exceed the available PT space the number of possible RTP payload configurations exceed the
within a RTP Session, there is need a way to represent the additional available PT space within a RTP Session, there is need a way to
constraints on payload configurations and to effectively map a RID represent the additional constraints on payload configurations and to
RTP Stream to its corresponding constraints. This issue is effectively map a RID RTP Stream to its corresponding constraints.
exacerbated by the increase in techniques such as simulcast and This issue is exacerbated by the increase in techniques such as
layered codecs, which introduce additional streams into RTP Sessions. simulcast and layered codecs, which introduce additional streams into
RTP Sessions.
This specification defines a new SDP framework for constraining This specification defines a new SDP framework for constraining
Source RTP Streams (Section 2.1.10 Source RTP Streams (Section 2.1.10
[I-D.ietf-avtext-rtp-grouping-taxonomy]), 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 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.
This specification makes use of the RTP Stream Identifier SDES RTCP This specification makes use of the RTP Stream Identifier SDES RTCP
skipping to change at page 4, line 27 skipping to change at page 4, line 37
unknown a= parameters to be ignored. This means that implementations unknown a= parameters to be ignored. This means that implementations
need to be prepared to handle successful offers and answers from need to be prepared to handle successful offers and answers from
other implementations that neither indicate nor honor the constraints other implementations that neither indicate nor honor the constraints
requested by this mechanism. requested by this mechanism.
Further, as described in Section 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, abd (b) having answerers ignore
"a=rid" lines that specify unknown constraints. "a=rid" lines that specify unknown constraints.
2. 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]
3. Terminology
The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP
Stream" are used as defined in
[I-D.ietf-avtext-rtp-grouping-taxonomy].
The term "RID RTP Stream" is used as defined in
[I-D.roach-avtext-rid].
[RFC4566] and [RFC3264] terminology is also used where appropriate.
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-identifier> <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".
skipping to change at page 7, line 8 skipping to change at page 7, line 8
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" attributes defined in this section. grammar for each of the "a=rid" parameters 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
unambiguous scope. Similarly, when using BUNDLE unambiguous scope. Similarly, when using BUNDLE
[I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP
streams uniquely to a single media description. streams uniquely to a single media description.
6.1. Generating the Initial SDP Offer 6.1. Generating the Initial SDP Offer
For each media description in the offer, the offerer MAY choose to For each RTP media description in the offer, the offerer MAY choose
include one or more "a=rid" lines to specify a configuration profile to include one or more "a=rid" lines to specify a configuration
for the given set of RTP Payload Types. profile for the given set of RTP Payload Types.
In order to construct a given "a=rid" line, the offerer must follow In order to construct a given "a=rid" line, the offerer must follow
these steps: these steps:
1. It MUST generate a "rid-identifier" that is unique within a media 1. It MUST generate a "rid-identifier" that is unique within a media
description description
2. It MUST set the direction for the "rid-identifier" to one of 2. It MUST set the direction for the "rid-identifier" to one of
"send" or "recv" "send" or "recv"
skipping to change at page 7, line 49 skipping to change at page 7, line 49
corresponding to RTP payload types) allowed to appear in the RID corresponding to RTP payload types) allowed to appear in the RID
RTP Stream. Any Payload Types chosen MUST be a valid payload RTP Stream. Any Payload Types chosen MUST be a valid payload
type for the media section (that is, it must be listed on the type for the media section (that is, it must be listed on the
"m=" line). The order of the listed formats is significant; the "m=" line). The order of the listed formats is significant; the
alternatives are listed from (left) most preferred to (right) alternatives are listed from (left) most preferred to (right)
least preferred. When using RID, this preference overrides the least preferred. When using RID, this preference overrides the
normal codec preference as expressed by format type ordering on normal codec preference as expressed by format type ordering on
the "m="-line, using regular SDP rules. the "m="-line, using regular SDP rules.
4. The Offerer then chooses zero or more "a=rid" constraints 4. The Offerer then chooses zero or more "a=rid" constraints
(Section 5) to be applied to the rid, and adds them to the (Section 5) to be applied to the RID RTP Stream, and adds them to
"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" attributes will further
constrain the equivalent "a=fmtp" parameters for the given Payload constrain the equivalent "a=fmtp" parameters for the given Payload
Type for the specified RID RTP Stream. Type for the specified RID RTP Stream.
skipping to change at page 8, line 25 skipping to change at page 8, line 25
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
perform the following steps: perform the following steps:
6.2.1. 'rid' unaware Answerer 6.2.1. "a=rid"-unaware Answerer
If the receiver doesn't support the framework proposed in this If the receiver doesn't support the framework proposed in this
specification, the entire "a=rid" line is ignored following the specification, the entire "a=rid" line is ignored following the
standard [RFC3264] Offer/Answer rules. standard [RFC3264] Offer/Answer rules.
Section 6.1 requires the offer to include a valid "a=fmtp" line for Section 6.1 requires the offer to include a valid "a=fmtp" line for
any codecs that otherwise require it (in other words, the "a=rid" any codecs that otherwise require it (in other words, the "a=rid"
line cannot be used to replace "a=fmtp" configuration). As a result, line cannot be used to replace "a=fmtp" configuration). As a result,
ignoring the "a=rid" line is always guaranteed to result in a valid ignoring the "a=rid" line is always guaranteed to result in a valid
session description. session description.
6.2.2. 'rid' aware Answerer 6.2.2. "a=rid"-aware Answerer
If the answerer supports the "a=rid" attribute, the following steps If the answerer supports the "a=rid" attribute, the following
are executed, in order, for each "a=rid" line in a given media verification steps are executed, in order, for each "a=rid" line in a
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 rejected 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=" parameter, the list of
payload types is verified against the list of valid payload types payload types is verified against the list of valid payload types
for the media section (that is, those listed on the "m=" line). for the media section (that is, those listed on the "m=" line).
Any PT missing from the "m=" line is removed from the "pt=" Any PT missing from the "m=" line is removed from the "pt="
parameter. parameter.
3. The answerer ensures that "a=rid" parameters listed are 3. The answerer ensures that "a=rid" parameters listed are
syntactically well formed. In the case of a syntax error, the syntactically well formed. In the case of a syntax error, the
"a=rid" line is removed. "a=rid" line is removed.
4. If the "direction" parameter is "recv", The answerer ensures that 4. If the "direction" parameter is "recv", The answerer ensures that
"a=rid" parameters are supported. In the case of an unsupported "a=rid" parameters are supported. In the case of an unsupported
parameter, the "a=rid" line is removed. parameter, the "a=rid" line is removed.
5. If the "depend" parameter is included, the answerer MUST make 5. If the "depend" parameter 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 lines that do not are removed. identifiers in the SDP offer. Any "a=rid" lines that do not are
removed.
6. The answerer verifies that the constraining parameters are 6. The answerer verifies that the constraining parameters are
consistent with at least one of the codecs to be used with the consistent with at least one of the codecs to be used with the
RID RTP Stream. If the "a=rid" line contains a "pt=" parameter, RID RTP Stream. If the "a=rid" line contains a "pt=" parameter,
it contains the list of such codecs; otherwise, the list of such it contains the list of such codecs; otherwise, the list of such
codecs is taken from the associated "m=" line. See Section 8 for codecs is taken from the associated "m=" line. See Section 8 for
more detail. If the "a=rid" parameters are incompatible with the more detail. If the "a=rid" parameters are incompatible with the
other codec properties for all codecs, then the "a=rid" line is other codec 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, the Having performed verification of the SDP offer as described in
answerer shall perform the following steps to generate the SDP Section 6.2.2, the answerer shall perform the following steps to
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" parameter 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
skipping to change at page 10, line 23 skipping to change at page 10, line 26
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
answer use the PT values that are present in its answer. answer use the PT values that are present in its answer.
6.4. Offerer Processing of the SDP Answer 6.4. Offerer Processing of the SDP Answer
The offerer shall follow these steps when processing the answer: The offerer SHALL follow these steps when processing the answer:
1. The offerer matches the "a=rid" line in the answer to the "a=rid" 1. The offerer matches the "a=rid" line in the answer to the "a=rid"
line in the offer using the "rid-identifier". If no matching line in the offer using the "rid-identifier". If no matching
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 consider the "a=rid" line as the offer, then the offerer SHALL discard the "a=rid" line.
rejected.
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 SHALL consider the "a=rid" line as supported; if they cannot, the offerer SHALL discard the "a=rid"
rejected. 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=" parameter but
the offer did not, the offerer SHALL consider the "a=rid" line as the offer did not, the offerer SHALL discard the "a=rid" line.
rejected.
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=" parameter and
the offer did as well, the offerer verifies that the list of the offer did as well, the offerer verifies that the list of
payload types is a subset of those sent in the corresponding payload types is a subset of those sent in the corresponding
"a=rid" line in the offer. If not, the offerer SHALL consider "a=rid" line in the offer. If not, the offerer SHALL discard the
the "a=rid" line as rejected. "a=rid" line.
6. If the "a=rid" line contains a "pt=" parameter, the offerer 6. If the "a=rid" line contains a "pt=" parameter, the offerer
verifies that the attribute values provided in the "a=rid" verifies that the attribute values provided in the "a=rid"
attributes are consistent with the corresponding codecs and their attributes are consistent with the corresponding codecs and their
other parameters. See Section 8 for more detail. If the "a=rid" other parameters. See Section 8 for more detail. If the "a=rid"
parameters are incompatible with the other codec properties, then parameters are incompatible with the other codec properties, then
the "a=rid" line is removed. the offerer SHALL discard the "a=rid" line.
7. The offerer verifies that the constraining parameters are 7. The offerer verifies that the constraining parameters are
consistent with at least one of the codecs to be used with the consistent with at least one of the codecs to be used with the
RID RTP Stream. If the "a=rid" line contains a "pt=" parameter, RID RTP Stream. If the "a=rid" line contains a "pt=" parameter,
it contains the list of such codecs; otherwise, the list of such it contains the list of such codecs; otherwise, the list of such
codecs is taken from the associated "m=" line. See Section 8 for codecs is taken from the associated "m=" line. See Section 8 for
more detail. If the "a=rid" parameters are incompatible with the more detail. If the "a=rid" parameters are incompatible with the
other codec properties for all codecs, then the "a=rid" line other codec properties for all codecs, then the offerer SHALL
SHALL be considered rejected discard the "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 SHALL be considered as rejected. above has been discarded by the answerer, and does not form part of
the negotiated constraints on a RID RTP Stream. The offerer MAY
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.
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
media section in the response does not. This includes situations in
which the answerer does not support "a=rid" at all, or does not
support the indicated constraints. Under such circumstances, the
offerer MUST be prepared to receive a media stream to which no
constraints 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.
skipping to change at page 20, line 34 skipping to change at page 20, line 43
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
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>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <http://www.rfc-editor.org/info/rfc5285>.
15.2. Informative References 15.2. Informative References
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, "A Taxonomy of Semantics and Mechanisms for B. Burman, "A Taxonomy of Semantics and Mechanisms for
Real-Time Transport Protocol (RTP) Sources", draft-ietf- Real-Time Transport Protocol (RTP) Sources", draft-ietf-
avtext-rtp-grouping-taxonomy-08 (work in progress), July avtext-rtp-grouping-taxonomy-08 (work in progress), July
2015. 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-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-03 (work in progress), October 2015. 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>.
[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>.
 End of changes. 35 change blocks. 
80 lines changed or deleted 86 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/