draft-ietf-mmusic-rid-06.txt   draft-ietf-mmusic-rid-07.txt 
Network Working Group P. Thatcher Network Working Group P. Thatcher
Internet-Draft Google Internet-Draft Google
Updates: 4855 (if approved) M. Zanaty Updates: 4855 (if approved) M. Zanaty
Intended status: Standards Track S. Nandakumar Intended status: Standards Track S. Nandakumar
Expires: January 8, 2017 Cisco Systems Expires: January 19, 2017 Cisco Systems
B. Burman B. Burman
Ericsson Ericsson
A. Roach A. Roach
B. Campen B. Campen
Mozilla Mozilla
July 07, 2016 July 18, 2016
RTP Payload Format Constraints RTP Payload Format Constraints
draft-ietf-mmusic-rid-06 draft-ietf-mmusic-rid-07
Abstract Abstract
In this specification, we define a framework for specifying In this specification, we define a framework for specifying
constraints on RTP streams in the Session Description Protocol. This constraints on RTP streams in the Session Description Protocol. This
framework defines a new "rid" SDP attribute to unambiguously identify framework defines a new "rid" SDP attribute to unambiguously identify
the RTP Streams within a RTP Session and constrain the streams' the RTP Streams within a RTP Session and constrain the streams'
payload format parameters in a codec-agnostic way beyond what is payload format parameters in a codec-agnostic way beyond what is
provided with the regular Payload Types. provided with the regular Payload Types.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 8, 2017. This Internet-Draft will expire on January 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Key Words for Requirements . . . . . . . . . . . . . . . . . 4 3. Key Words for Requirements . . . . . . . . . . . . . . . . . 4
4. SDP "a=rid" Media Level Attribute . . . . . . . . . . . . . . 4 4. SDP "a=rid" Media Level Attribute . . . . . . . . . . . . . . 4
5. "a=rid" constraints . . . . . . . . . . . . . . . . . . . . . 6 5. "a=rid" constraints . . . . . . . . . . . . . . . . . . . . . 6
6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 7
6.1. Generating the Initial SDP Offer . . . . . . . . . . . . 7 6.1. Generating the Initial SDP Offer . . . . . . . . . . . . 7
6.2. Answerer processing the SDP Offer . . . . . . . . . . . . 8 6.2. Answerer processing the SDP Offer . . . . . . . . . . . . 8
6.2.1. "a=rid"-unaware Answerer . . . . . . . . . . . . . . 8 6.2.1. "a=rid"-unaware Answerer . . . . . . . . . . . . . . 8
6.2.2. "a=rid"-aware Answerer . . . . . . . . . . . . . . . 8 6.2.2. "a=rid"-aware Answerer . . . . . . . . . . . . . . . 9
6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 9 6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 10
6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10
6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 11 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 12
7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 12 7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 12
8. Interaction with Other Techniques . . . . . . . . . . . . . . 12 8. Interaction with Other Techniques . . . . . . . . . . . . . . 12
8.1. Interaction with VP8 Format Parameters . . . . . . . . . 13 8.1. Interaction with VP8 Format Parameters . . . . . . . . . 13
8.1.1. max-fr - Maximum Framerate . . . . . . . . . . . . . 13 8.1.1. max-fr - Maximum Framerate . . . . . . . . . . . . . 13
8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks . . . 13 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks . . . 13
8.2. Interaction with H.264 Format Parameters . . . . . . . . 14 8.2. Interaction with H.264 Format Parameters . . . . . . . . 14
8.2.1. profile-level-id and max-recv-level - Negotiated Sub- 8.2.1. profile-level-id and max-recv-level - Negotiated Sub-
Profile . . . . . . . . . . . . . . . . . . . . . . . 15 Profile . . . . . . . . . . . . . . . . . . . . . . . 15
8.2.2. max-br / MaxBR - Maximum Video Bitrate . . . . . . . 15 8.2.2. max-br / MaxBR - Maximum Video Bitrate . . . . . . . 15
8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264
Macroblocks . . . . . . . . . . . . . . . . . . . . . 15 Macroblocks . . . . . . . . . . . . . . . . . . . . . 15
8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing
Rate . . . . . . . . . . . . . . . . . . . . . . . . 16 Rate . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2.5. max-smbps - Maximum Decoded Picture Buffer . . . . . 16 8.2.5. max-smbps - Maximum Decoded Picture Buffer . . . . . 16
9. Format Parameters for Future Payloads . . . . . . . . . . . . 16 9. Format Parameters for Future Payloads . . . . . . . . . . . . 16
10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 16 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 16
11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 18 11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 18
11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 19 11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 20
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 20 12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 20
12.2. Registry for RID-Level Parameters . . . . . . . . . . . 20 12.2. Registry for RID-Level Parameters . . . . . . . . . . . 21
13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
15.1. Normative References . . . . . . . . . . . . . . . . . . 22 15.1. Normative References . . . . . . . . . . . . . . . . . . 23
15.2. Informative References . . . . . . . . . . . . . . . . . 23 15.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Terminology 1. Terminology
The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP
Stream" are used as defined in [RFC7656]. Stream" are used as defined in [RFC7656].
[RFC4566] and [RFC3264] terminology is also used where appropriate. [RFC4566] and [RFC3264] terminology is also used where appropriate.
2. Introduction 2. Introduction
skipping to change at page 5, line 12 skipping to change at page 5, line 12
"a=rid", ("restriction identifier") used to communicate a set of "a=rid", ("restriction identifier") used to communicate a set of
restrictions to be applied an identified RTP Stream. Roughly restrictions to be applied an identified RTP Stream. Roughly
speaking, this attribute takes the following form (see Section 10 for speaking, this attribute takes the following form (see Section 10 for
a formal definition). a formal definition).
a=rid:<rid-id> <direction> [pt=<fmt-list>;]<constraint>=<value>... a=rid:<rid-id> <direction> [pt=<fmt-list>;]<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-id" field. unique RTP payload configuration identified via the "rid-id" field.
This value binds the restriction to the RTP Stream identified by its This value binds the restriction to the RTP Stream identified by its
RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. To be clear,
implementations that use the "a=rid" parameter in SDP MUST support
the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such
implementations MUST send it for all streams in an m-section that has
"a=rid" lines remaining after applying the rules in Section 6 and its
subsections.
The "direction" field identifies the directionality of the RTP The "direction" field identifies the directionality of the RTP
Stream; it may be either "send" or "recv". Stream; it may be either "send" or "recv".
The optional "pt=<fmt-list>" lists one or more PT values that can be The optional "pt=<fmt-list>" lists one or more PT values that can be
used in the associated RTP Stream. If the "a=rid" attribute contains used in the associated RTP Stream. If the "a=rid" attribute contains
no "pt", then any of the PT values specified in the corresponding no "pt", then any of the PT values specified in the corresponding
"m=" line may be used. "m=" line may be used.
The list of zero or more codec-agnostic constraints (Section 5) The list of zero or more codec-agnostic constraints (Section 5)
skipping to change at page 6, line 52 skipping to change at page 7, line 8
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 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. These values MUST be encoded with at most four
digits to the right of the decimal point.
o depend, to identify other streams that the stream depends on. The
value is a comma-separated list of rid-ids. These rid-ids
identify RTP streams that this stream depends on in order to allow
for proper interpretation.
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 or any
no reason such constraints should be precluded from definition and media types other than video, there is no reason such constraints
registration by other documents. should be precluded from definition and registration by other
documents.
Section 10 provides formal Augmented Backus-Naur Form(ABNF) [RFC5234] Section 10 provides formal Augmented Backus-Naur Form (ABNF)
grammar for each of the "a=rid" constraints defined in this section. [RFC5234] 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-id" values are only required to be unique within a Note that "rid-id" values are only required to be unique within a
media section ("m-line"); they do not necessarily need to be unique media section ("m-line"); they do not necessarily need to be unique
within an entire RTP session. In traditional usage, each media within an entire RTP session. In traditional usage, each media
section is sent on its own unique 5-tuple, which provides an section is sent on its own unique 5-tuple, which provides an
skipping to change at page 9, line 10 skipping to change at page 9, line 24
2. Extract the rid-id from the "a=rid" line and verify its 2. Extract the rid-id from the "a=rid" line and verify its
uniqueness within a media section. In the case of a duplicate, uniqueness within a media section. In the case of a duplicate,
the entire "a=rid" line, and all "a=rid" lines with rid-ids that the entire "a=rid" line, and all "a=rid" lines with rid-ids that
duplicate this line, are discarded and MUST NOT be included in duplicate this line, are discarded and MUST NOT be included in
the SDP Answer. the SDP Answer.
3. If the "a=rid" line contains a "pt=", the list of payload types 3. If the "a=rid" line contains a "pt=", the list of payload types
is verified against the list of valid payload types for the media is verified against the list of valid payload types for the media
section (that is, those listed on the "m=" line). Any PT missing section (that is, those listed on the "m=" line). Any PT missing
from the "m=" line is removed from the set of valued in the from the "m=" line is removed from the set of values in the
"pt=". "pt=". If no values are left in the "pt=" parameter after this
processing, then the "a=rid" line is removed.
4. If the "direction" field is "recv", The answerer ensures that 4. If the "direction" field is "recv", The answerer ensures that
"a=rid" constraints are supported. In the case of an unsupported "a=rid" constraints are supported. In the case of an unsupported
constraint, the "a=rid" line is removed. constraint, the "a=rid" line is removed.
5. If the "depend" constraint is included, the answerer MUST make 5. If the "depend" constraint is included, the answerer MUST make
sure that the listed rid-ids unambiguously match the rid-ids in sure that the listed rid-ids unambiguously match the rid-ids in
the SDP offer. Any "a=rid" lines that do not are removed. the SDP offer. Any "a=rid" lines that do not are removed.
6. The answerer verifies that the constraints are consistent with at 6. The answerer verifies that the constraints are consistent with at
skipping to change at page 11, line 7 skipping to change at page 11, line 26
the offer. Note that this matching must be performed the offer. Note that this matching must be performed
semantically rather than on literal PT values, as the remote end semantically rather than on literal PT values, as the remote end
may not be using symmetric PTs. For the purpose of this may not be using symmetric PTs. For the purpose of this
comparison: for each PT listed on the "a=rid" line in the answer, comparison: for each PT listed on the "a=rid" line in the answer,
the offerer looks up the corresponding "a=rtpmap" and "a=fmtp" the offerer looks up the corresponding "a=rtpmap" and "a=fmtp"
lines in the answer. It then searches the list of "pt=" values lines in the answer. It then searches the list of "pt=" values
indicated in the offer, and attempts to find one with an indicated in the offer, and attempts to find one with an
equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If 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 all PTs in the answer can be matched, then the "pt=" values pass
validation; otherwise, it fails. If this validation fails, the validation; otherwise, it fails. If this validation fails, the
offerer SHALL discard the "a=rid" line. offerer SHALL discard the "a=rid" line. Note that this semantic
comparison necessarily requires an understanding of the meaning
of codec parameters, rather than a rote byte-wise comparison of
their values.
6. If the "a=rid" line contains a "pt=", the offerer verifies that 6. If the "a=rid" line contains a "pt=", the offerer verifies that
the attribute values provided in the "a=rid" attributes are the attribute values provided in the "a=rid" attributes are
consistent with the corresponding codecs and their other consistent with the corresponding codecs and their other
parameters. See Section 8 for more detail. If the "a=rid" parameters. See Section 8 for more detail. If the "a=rid"
constraints are incompatible with the other codec properties, constraints are incompatible with the other codec properties,
then the offerer SHALL discard the "a=rid" line. then the offerer SHALL discard the "a=rid" line.
7. The offerer verifies that the constraints are consistent with at 7. The offerer verifies that the constraints are consistent with at
least one of the codecs to be used with the RTP Stream. If the least one of the codecs to be used with the RTP Stream. If the
skipping to change at page 12, line 7 skipping to change at page 12, line 24
Offers and answers inside an existing session follow the rules for Offers and answers inside an existing session follow the rules for
initial session negotiation. Such an offer MAY propose a change in initial session negotiation. Such an offer MAY propose a change in
the number of RIDs in use. To avoid race conditions with media, any the number of RIDs in use. To avoid race conditions with media, any
RIDs with proposed changes SHOULD use a new ID, rather than re-using RIDs with proposed changes SHOULD use a new ID, rather than re-using
one from the previous offer/answer exchange. RIDs without proposed one from the previous offer/answer exchange. RIDs without proposed
changes SHOULD re-use the ID from the previous exchange. changes SHOULD re-use the ID from the previous exchange.
7. Use with Declarative SDP 7. Use with Declarative SDP
Although designed predominantly with session negotiation in mind, the This document does not define the use of RID in declarative SDP. If
"a=rid" attribute can also be used in declarative SDP situations. concrete use cases for RID in declarative SDP use are identified in
When used with declarative SDP, any constraints applied to a RID the future, we expect that additional specifications will address
indicate how the sender intends to constrain the stream they are such use.
sending.
In declarative use, the "direction" field MUST be set to "send" in
all "a=rid" lines.
Recipients of declarative SDP may use the indicated constraints to
select an RTP Stream to decode, based on their needs and
capabilities.
8. Interaction with Other Techniques 8. Interaction with Other Techniques
Historically, a number of other approaches have been defined that Historically, a number of other approaches have been defined that
allow constraining media streams via SDP. These include: allow constraining media streams via SDP. These include:
o Codec-specific configuration set via format parameters ("a=fmtp"); o Codec-specific configuration set via format parameters ("a=fmtp");
for example, the H.264 "max-fs" format parameter [RFC6184] for example, the H.264 "max-fs" format parameter [RFC6184]
o Size restrictions imposed by image attribute attributes o Size restrictions imposed by image attribute attributes
skipping to change at page 15, line 37 skipping to change at page 15, line 42
this format parameter, and the sending constraints defined via this format parameter, and the sending constraints defined via
"a=rid" include a "max-fps" parameter, then the sent stream is will "a=rid" include a "max-fps" parameter, then the sent stream is will
conform to the smaller of the two values - that is: conform to the smaller of the two values - that is:
min(rid_max_br, h264_MaxBR * conversion_factor) min(rid_max_br, h264_MaxBR * conversion_factor)
8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks
The H.264 "MaxFs" parameter (and its equiavelent "max-fs" format The H.264 "MaxFs" parameter (and its equiavelent "max-fs" format
parameter) corresponds roughly to the "max-fs" constraint defined in parameter) corresponds roughly to the "max-fs" constraint defined in
this document, by way of a conversion factor of the number of pixels this document, by way of a conversion factor of 256 (the number of
per macroblock (typically 16 or 64). pixels per macroblock).
As the size of H.264 macroblocks can change on a per-macroblock basis If an RTP sender is generating a stream using a format defined with
for certain H.264 profiles, a direct mathematical conversion between this format parameter, and the sending constraints defined via
H.264's "max-fs" format parameter and the "a=rid" "max-fs" constraint "a=rid" include a "max-fs" parameter, then the sent stream is will
cannot be expressed. If an RTP sender is generating a stream using a conform to the smaller of the two values - that is:
format defined with this format parameter, and the sending
constraints defined via "a=rid" include a "max-fs" parameter, then min(rid_max_fs, h264_MaxFs * 256)
the sent stream will conform to both signaled capabilities
simultaneously.
8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate
The H.264 "MaxMBPS" parameter (and its equiavelent "max-mbps" format The H.264 "MaxMBPS" parameter (and its equiavelent "max-mbps" format
parameter) corresponds roughly to the "max-pps" constraint defined in parameter) corresponds roughly to the "max-pps" constraint defined in
this document, by way of a conversion factor of the number of pixels this document, by way of a conversion factor of 256 (the number of
per macroblock (typically 16 or 64). pixels per macroblock).
As the size of H.264 macroblocks can change on a per-macroblock basis If an RTP sender is generating a stream using a format defined with
for certain H.264 profiles, a direct mathematical conversion between this format parameter, and the sending constraints defined via
H.264's "max-mbps" format parameter and the "a=rid" "max-pps" "a=rid" include a "max-pps" parameter, then the sent stream is will
constraint cannot be expressed. If an RTP sender is generating a conform to the smaller of the two values - that is:
stream using a format defined with this format parameter, and the
sending constraints defined via "a=rid" include a "max-pps" min(rid_max_pps, h264_MaxMBPS * 256)
parameter, then the sent stream will conform to both signaled
capabilities simultaneously.
8.2.5. max-smbps - Maximum Decoded Picture Buffer 8.2.5. max-smbps - Maximum Decoded Picture Buffer
The H.264 "max-smbps" format parameter operates the same way as the The H.264 "max-smbps" format parameter operates the same way as the
"max-mpbs" format parameter, under the hypothetical assumption that "max-mpbs" format parameter, under the hypothetical assumption that
all macroblocks are static macroblocks. It is handled by applying all macroblocks are static macroblocks. It is handled by applying
the conversion factor described in Section 8.1 of [RFC6184], and the the conversion factor described in Section 8.1 of [RFC6184], and the
result of this conversion is applied as described in Section 8.2.4. result of this conversion is applied as described in Section 8.2.4.
9. Format Parameters for Future Payloads 9. Format Parameters for Future Payloads
skipping to change at page 16, line 49 skipping to change at page 16, line 47
This section gives a formal Augmented Backus-Naur Form (ABNF) This section gives a formal Augmented Backus-Naur Form (ABNF)
[RFC5234] grammar for each of the new media and "a=rid" attributes [RFC5234] grammar for each of the new media and "a=rid" attributes
defined in this document. defined in this document.
rid-syntax = "a=rid:" rid-id SP rid-dir rid-syntax = "a=rid:" rid-id SP rid-dir
[ rid-pt-param-list / rid-param-list ] [ rid-pt-param-list / rid-param-list ]
rid-id = 1*(alpha-numeric / "-" / "_") rid-id = 1*(alpha-numeric / "-" / "_")
alpha-numeric = < as defined in {{RFC4566}} >
rid-dir = "send" / "recv" rid-dir = "send" / "recv"
rid-pt-param-list = SP rid-fmt-list *(";" rid-param) rid-pt-param-list = SP rid-fmt-list *(";" rid-param)
rid-param-list = SP rid-param *(";" rid-param) rid-param-list = SP rid-param *(";" rid-param)
rid-fmt-list = "pt=" fmt *( "," fmt ) rid-fmt-list = "pt=" fmt *( "," fmt )
; fmt defined in {{RFC4566}}
fmt = < as defined in {{RFC4566}} >
rid-param = rid-width-param rid-param = rid-width-param
/ rid-height-param / rid-height-param
/ rid-fps-param / rid-fps-param
/ rid-fs-param / rid-fs-param
/ rid-br-param / rid-br-param
/ rid-pps-param / rid-pps-param
/ rid-bpp-param / rid-bpp-param
/ rid-depend-param / rid-depend-param
/ rid-param-other / rid-param-other
skipping to change at page 20, line 7 skipping to change at page 20, line 14
11.2. Scalable Layers 11.2. Scalable Layers
Adding scalable layers to a session within a multiparty conference Adding scalable layers to a session within a multiparty conference
gives a selective forwarding unit (SFU) further flexibility to gives a selective forwarding unit (SFU) further flexibility to
selectively forward packets from a source that best match the selectively forward packets from a source that best match the
bandwidth and capabilities of diverse receivers. Scalable encodings bandwidth and capabilities of diverse receivers. Scalable encodings
have dependencies between layers, unlike independent simulcast have dependencies between layers, unlike independent simulcast
streams. RIDs can be used to express these dependencies using the streams. RIDs can be used to express these dependencies using the
"depend" constraint. In the example below, the highest resolution is "depend" 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). See
[I-D.ietf-mmusic-sdp-simulcast] for additional detail about simulcast
usage.
Offer: Offer:
... ...
m=audio ...same as previous example ... m=audio ...same as previous example ...
... ...
m=video ...same as previous example ... m=video ...same as previous example ...
...same rtpmap/fmtp as previous example ... ...same rtpmap/fmtp as previous example ...
a=sendrecv a=sendrecv
a=mid:v1 (max resolution) a=mid:v1 (max resolution)
a=rid:0 send max-width=1280;max-height=720;max-fps=15 a=rid:0 send max-width=1280;max-height=720;max-fps=15
skipping to change at page 20, line 42 skipping to change at page 20, line 51
12.1. New SDP Media-Level attribute 12.1. New SDP Media-Level attribute
This document defines "rid" as SDP media-level attribute. This This document defines "rid" as SDP media-level attribute. This
attribute must be registered by IANA under "Session Description attribute must be registered by IANA under "Session Description
Protocol (SDP) Parameters" under "att-field (media level only)". Protocol (SDP) Parameters" under "att-field (media level only)".
The "rid" attribute is used to identify characteristics of RTP stream The "rid" attribute is used to identify characteristics of RTP stream
with in a RTP Session. Its format is defined in Section 10. with in a RTP Session. Its format is defined in Section 10.
The formal registration information for this attribute follows.
Contact name, email address, and telephone number
IETF MMUSIC Working Group
mmusic@ietf.org
+1 510 492 4080
Attribute name (as it will appear in SDP)
rid
Long-form attribute name in English
Restriction Identifier
Type of attribute (session level, media level, or both)
Media Level
Whether the attribute value is subject to the charset attribute
The attribute is not dependent on charset.
A one-paragraph explanation of the purpose of the attribute
The "rid" SDP attribute is used to to unambiguously identify
the RTP Streams within a RTP Session and constrain the
streams' payload format parameters in a codec-agnostic way
beyond what is provided with the regular Payload Types.
A specification of appropriate attribute values for this attribute
Valid values are defined by the ABNF in [RFCXXXXX]
12.2. Registry for RID-Level Parameters 12.2. Registry for RID-Level Parameters
This specification creates a new IANA registry named "att-field (rid This specification creates a new IANA registry named "att-field (rid
level)" within the SDP parameters registry. The "a=rid" constraints level)" within the SDP parameters registry. The "a=rid" 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
 End of changes. 25 change blocks. 
59 lines changed or deleted 104 lines changed or added

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