draft-ietf-mmusic-rid-03.txt   draft-ietf-mmusic-rid-04.txt 
Network Working Group P. Thatcher Network Working Group P. Thatcher
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track M. Zanaty Updates: RFC4855 (if approved) M. Zanaty
Expires: August 8, 2016 S. Nandakumar Intended status: Standards Track S. Nandakumar
Cisco Systems Expires: August 11, 2016 Cisco Systems
B. Burman B. Burman
Ericsson Ericsson
A. Roach A. Roach
B. Campen B. Campen
Mozilla Mozilla
February 05, 2016 February 08, 2016
RTP Payload Format Constraints RTP Payload Format Constraints
draft-ietf-mmusic-rid-03 draft-ietf-mmusic-rid-04
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
their media format specification in the SDP. their media format specification in the SDP.
This specification updates RFC4855 to give additional guidance on
choice of Format Parameter (fmtp) names, and on their relation to the
constraints defined by this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 8, 2016. This Internet-Draft will expire on August 11, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Key Words for Requirements . . . . . . . . . . . . . . . . . 4 3. Key Words for Requirements . . . . . . . . . . . . . . . . . 5
4. SDP "a=rid" Media Level Attribute . . . . . . . . . . . . . . 4 4. SDP "a=rid" Media Level Attribute . . . . . . . . . . . . . . 5
5. "a=rid" constraints . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 12
7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 11 7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 12
8. Interaction with Other Techniques . . . . . . . . . . . . . . 12 8. Interaction with Other Techniques . . . . . . . . . . . . . . 12
9. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Interaction with VP8 Format Parameters . . . . . . . . . 13
10. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1.1. max-fr - Maximum Framerate . . . . . . . . . . . . . 13
10.1. Many Bundled Streams using Many Codecs . . . . . . . . . 14 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks . . . 13
10.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 16 8.2. Interaction with H.264 Format Parameters . . . . . . . . 14
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.2.1. profile-level-id and max-recv-level - Negotiated Sub-
11.1. Declarative SDP . . . . . . . . . . . . . . . . . . . . 16 Profile . . . . . . . . . . . . . . . . . . . . . . . 15
11.2. Definition of bitrate . . . . . . . . . . . . . . . . . 17 8.2.2. max-br / MaxBR - Maximum Video Bitrate . . . . . . . 15
11.3. Escaping new constraint values . . . . . . . . . . . . . 17 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264
11.4. Utility of max-width and max height . . . . . . . . . . 17 Macroblocks . . . . . . . . . . . . . . . . . . . . . 15
11.5. Definition of max-fps . . . . . . . . . . . . . . . . . 18 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 Rate . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 18 8.2.5. max-smbps - Maximum Decoded Picture Buffer . . . . . 16
12.2. Registry for RID-Level Parameters . . . . . . . . . . . 18 9. Format Parameters for Future Payloads . . . . . . . . . . . . 16
13. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 16
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 18
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 18
15.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 19
15.2. Informative References . . . . . . . . . . . . . . . . . 20 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Declarative SDP . . . . . . . . . . . . . . . . . . . . 20
12.2. Definition of bitrate . . . . . . . . . . . . . . . . . 20
12.3. Escaping new constraint values . . . . . . . . . . . . . 21
12.4. Utility of max-width and max height . . . . . . . . . . 21
12.5. Definition of max-fps . . . . . . . . . . . . . . . . . 21
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
13.1. New SDP Media-Level attribute . . . . . . . . . . . . . 22
13.2. Registry for RID-Level Parameters . . . . . . . . . . . 22
14. Security Considerations . . . . . . . . . . . . . . . . . . . 23
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
16.1. Normative References . . . . . . . . . . . . . . . . . . 24
16.2. Informative References . . . . . . . . . . . . . . . . . 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].
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.
skipping to change at page 4, line 46 skipping to change at page 5, line 15
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 10 for a formal definition).
a=rid:<rid-id> <direction> [pt=<fmt-list>;]<constraint>=<value>... a=rid:<rid-id> <direction> [pt=<fmt-list>;]<constraint>=<value>...
An "a=rid" SDP media attribute specifies constraints defining a An "a=rid" SDP media attribute specifies constraints defining a
unique RTP payload configuration identified via the "rid-identifier" unique RTP payload configuration identified via the "rid-identifier"
field. This value binds the restriction to the RID RTP Stream field. This value binds the restriction to the RID RTP Stream
identified by its RID SDES item [I-D.roach-avtext-rid]. identified by its RID SDES item [I-D.roach-avtext-rid].
The "direction" field identifies the directionality of the RID RTP The "direction" field identifies the directionality of the RID RTP
Stream; it may be either "send" or "recv". Stream; it may be either "send" or "recv".
skipping to change at page 5, line 39 skipping to change at page 6, line 5
"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 constraints specified by the "rid" constraints follow a Though the constraints specified by the "rid" constraints follow a
syntax similar to session-level and media-level parameters, they are syntax similar to session-level and media-level parameters, they are
defined independently. All "rid" constraints MUST be registered with defined independently. All "rid" constraints MUST be registered with
IANA, using the registry defined in Section 12. IANA, using the registry defined in Section 13.
Section 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] Section 10 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234]
grammar for the "rid" attribute. The "a=rid" media attribute is not grammar for the "rid" attribute. The "a=rid" media attribute is not
dependent on charset. dependent on charset.
5. "a=rid" constraints 5. "a=rid" 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.
The following constraints are intended to apply to video codecs in a The following constraints are intended to apply to video codecs in a
codec-independent fashion. codec-independent fashion.
skipping to change at page 6, line 50 skipping to change at page 7, line 16
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 13.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 10 provides formal Augmented Backus-Naur Form(ABNF) [RFC5234]
grammar for each of the "a=rid" constraints defined in this section. grammar for each of the "a=rid" constraints defined in this section.
6. SDP Offer/Answer Procedures 6. SDP Offer/Answer Procedures
This section describes the SDP Offer/Answer [RFC3264] procedures when This section describes the SDP Offer/Answer [RFC3264] procedures when
using this framework. using this framework.
Note that "rid-identifier" values are only required to be unique Note that "rid-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
skipping to change at page 12, line 20 skipping to change at page 12, line 35
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. 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 [RFC6185] for example, the H.264 "max-fs" format parameter [RFC6184]
o Size restrictions imposed by image attribute attributes o Size restrictions imposed by image attribute attributes
("a=imageattr") [RFC6236] ("a=imageattr") [RFC6236]
When the mechanism described in this document is used in conjunction When the mechanism described in this document is used in conjunction
with these other restricting mechanisms, it is intended to impose with these other restricting mechanisms, it is intended to impose
additional restrictions beyond those communicated in other additional restrictions beyond those communicated in other
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
skipping to change at page 13, line 5 skipping to change at page 13, line 16
restrictions on the media stream, are also expected to result in a restrictions on the media stream, are also expected to result in a
non-empty union. If the implementation generating an answer wishes non-empty union. If the implementation generating an answer wishes
to restrict a property of the stream below that which would be to restrict a property of the stream below that which would be
allowed by other parameters (e.g., those specified in "a=fmtp" or allowed by other parameters (e.g., those specified in "a=fmtp" or
"a=imageattr"), its only recourse is to remove the "a=rid" line "a=imageattr"), its only recourse is to 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 The following subsections demonstrate these interactions using
commonly-used video codecs. These descriptions are illustrative of
the interaction principles outlined above, and are not normative.
8.1. Interaction with VP8 Format Parameters
[I-D.ietf-payload-vp8] defines two format parameters for the VP8
codec. Both correspond to constraints on receiver capabilities, and
never indicate sending constraints.
8.1.1. max-fr - Maximum Framerate
The VP8 "max-fr" format parameter corresponds to the "max-fps"
constraint defined in this specification. If an RTP sender is
generating a stream using a format defined with this format
parameter, and the sending constraints defined via "a=rid" include a
"max-fps" parameter, then the sent stream is will conform to the
smaller of the two values.
8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks
The VP8 "max-fs" format parameter corresponds to the "max-fs"
constraint defined in this document, by way of a conversion factor of
the number of pixels per macroblock (typically 256). If an RTP
sender is generating a stream using a format defined with this format
parameter, and the sending constraints defined via "a=rid" include a
"max-fs" parameter, then the sent stream will conform to the smaller
of the two values; that is, the number of pixels per frame will not
exceed:
min(rid_max_fs, fmtp_max_fs * macroblock_size)
This fmtp parameter also has bearing on the max-height and max-width
parameters. Section 6.1 of [I-D.ietf-payload-vp8] requires that the
width and height of the frame in macroblocks are also required to be
less than int(sqrt(fmtp_max_fs * 8)). Accordingly, the maximum width
of a transmitted stream will be limited to:
min(rid_max_width, int(sqrt(fmtp_max_fs * 8)) * macroblock_width)
Similarly, the stream's height will be limited to:
min(rid_max_height, int(sqrt(fmtp_max_fs * 8)) * macroblock_height)
8.2. Interaction with H.264 Format Parameters
[RFC6184] defines format parameters for the H.264 video codec. The
majority of these parameters do not correspond to codec-independent
constraints:
o deint-buf-cap
o in-band-parameter-sets
o level-asymmetry-allowed
o max-rcmd-nalu-size
o max-cpb
o max-dpb
o packetization-mode
o redundant-pic-cap
o sar-supported
o sar-understood
o sprop-deint-buf-req
o sprop-init-buf-time
o sprop-interleaving-depth
o sprop-level-parameter-sets
o sprop-max-don-diff
o sprop-parameter-sets
o use-level-src-parameter-sets
Note that the max-cpb and max-dpb format parameters for H.264
correspond to constraints on the stream, but they are specific to the
way the H.264 codec operates, and do not have codec-independent
equivalents.
The following codec format parameters correspond to constraints on
receiver capabilities, and never indicate sending constraints.
8.2.1. profile-level-id and max-recv-level - Negotiated Sub-Profile
These parameters include a "level" indicator, which acts as an index
into Table A-1 of [H264]. This table contains a number of
parameters, several of which correspond to the constraints defined in
this document. [RFC6184] also defines formate parameters for the
H.264 codec that may increase the maximum values indicated by the
negotiated level. The following sections describe the interaction
between these parameters and the constraints defined by this
document. In all cases, the H.264 parameters being discussed are the
maximum of those indicated by [H264] Table A-1 and those indicated in
the corresponding "a=fmtp" line.
8.2.2. max-br / MaxBR - Maximum Video Bitrate
The H.264 "MaxBR" parameter (and its equivalent "max-br" format
parameter) corresponds to the "max-bps" constraint defined in this
specification, by way of a conversion factor of 1000 or 1200; see
[RFC6184] for details regarding which factor gets used under
differing circumstances.
If an RTP sender is generating a stream using a format defined with
this format parameter, and the sending constraints defined via
"a=rid" include a "max-fps" parameter, then the sent stream is will
conform to the smaller of the two values - that is:
min(rid_max_br, h264_MaxBR * conversion_factor)
8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 Macroblocks
The H.264 "MaxFs" parameter (and its equiavelent "max-fs" format
parameter) corresponds roughly to the "max-fs" constraint defined in
this document, by way of a conversion factor of the number of pixels
per macroblock (typically 16 or 64).
As the size of H.264 macroblocks can change on a per-macroblock basis
for certain H.264 profiles, a direct mathematical conversion between
H.264's "max-fs" format parameter and the "a=rid" "max-fs" constraint
cannot be expressed. If an RTP sender is generating a stream using a
format defined with this format parameter, and the sending
constraints defined via "a=rid" include a "max-fs" parameter, then
the sent stream will conform to both signaled capabilities
simultaneously.
8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate
The H.264 "MaxMBPS" parameter (and its equiavelent "max-mbps" format
parameter) corresponds roughly to the "max-pps" constraint defined in
this document, by way of a conversion factor of the number of pixels
per macroblock (typically 16 or 64).
As the size of H.264 macroblocks can change on a per-macroblock basis
for certain H.264 profiles, a direct mathematical conversion between
H.264's "max-mbps" format parameter and the "a=rid" "max-pps"
constraint cannot be expressed. If an RTP sender is generating a
stream using a format defined with this format parameter, and the
sending constraints defined via "a=rid" include a "max-pps"
parameter, then the sent stream will conform to both signaled
capabilities simultaneously.
8.2.5. max-smbps - Maximum Decoded Picture Buffer
The H.264 "max-smbps" format parameter operates the same way as the
"max-mpbs" format parameter, under the hypothetical assumption that
all macroblocks are static macroblocks. It is handled by applying
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.
9. Format Parameters for Future Payloads
Registrations of future RTP payload format specifications that define
media types that have parameters matching the RID constraints
specified in this memo SHOULD name those parameters in a manner that
matches the names of those RID constraints, and SHOULD explicitly
state what media type parameters are constrained by what RID
constraints.
10. Formal Grammar
This section gives a formal Augmented Backus-Naur Form (ABNF) This section gives a formal Augmented Backus-Naur Form (ABNF)
[RFC5234] grammar for each of the new media and "a=rid" attributes [RFC5234] grammar for each of the new media and "a=rid" attributes
defined in this document. defined in this document.
rid-syntax = "a=rid:" rid-identifier SP rid-dir rid-syntax = "a=rid:" rid-identifier SP rid-dir
[ rid-pt-param-list / rid-param-list ] [ rid-pt-param-list / rid-param-list ]
rid-identifier = 1*(alpha-numeric / "-" / "_") rid-identifier = 1*(alpha-numeric / "-" / "_")
skipping to change at page 14, line 4 skipping to change at page 17, line 38
rid-br-param = "max-br" [ "=" int-param-val ] rid-br-param = "max-br" [ "=" int-param-val ]
rid-pps-param = "max-pps" [ "=" int-param-val ] rid-pps-param = "max-pps" [ "=" int-param-val ]
rid-bpp-param = "max-bpp" [ "=" float-param-val ] rid-bpp-param = "max-bpp" [ "=" float-param-val ]
rid-depend-param = "depend=" rid-list rid-depend-param = "depend=" rid-list
rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ]
rid-list = rid-identifier *( "," rid-identifier ) rid-list = rid-identifier *( "," rid-identifier )
int-param-val = 1*DIGIT int-param-val = 1*DIGIT
float-param-val = 1*DIGIT "." 1*DIGIT float-param-val = 1*DIGIT "." 1*DIGIT
param-val = *( %x20-58 / %x60-7E ) param-val = *( %x20-58 / %x60-7E )
; Any printable character except semicolon ; Any printable character except semicolon
10. SDP Examples 11. SDP Examples
Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in Note: see [I-D.ietf-mmusic-sdp-simulcast] for examples of RID used in
simulcast scenarios. simulcast scenarios.
10.1. Many Bundled Streams using Many Codecs 11.1. Many Bundled Streams using Many Codecs
In this scenario, the offerer supports the Opus, G.722, G.711 and In this scenario, the offerer supports the Opus, G.722, G.711 and
DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC DTMF audio codecs, and VP8, VP9, H.264 (CBP/CHP, mode 0/1), H.264-SVC
(SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a (SCBP/SCHP) and H.265 (MP/M10P) for video. An 8-way video call (to a
mixer) is supported (send 1 and receive 7 video streams) by offering mixer) is supported (send 1 and receive 7 video streams) by offering
7 video media sections (1 sendrecv at max resolution and 6 recvonly 7 video media sections (1 sendrecv at max resolution and 6 recvonly
at smaller resolutions), all bundled on the same port, using 3 at smaller resolutions), all bundled on the same port, using 3
different resolutions. The resolutions include: different resolutions. The resolutions include:
o 1 receive stream of 720p resolution is offered for the active o 1 receive stream of 720p resolution is offered for the active
skipping to change at page 16, line 4 skipping to change at page 19, line 42
... ...
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
...same rtpmap/fmtp as above... ...same rtpmap/fmtp as above...
a=recvonly a=recvonly
a=mid:v4 (small resolution) a=mid:v4 (small resolution)
a=rid:4 recv max-width=320;max-height=180;max-fps=15 a=rid:4 recv max-width=320;max-height=180;max-fps=15
... ...
m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107 m=video 10000 RTP/SAVPF 98 99 100 101 102 103 104 105 106 107
...same rtpmap/fmtp as above... ...same rtpmap/fmtp as above...
...same rid:4 as above for mid:v5,v6,v7 (small resolution)... ...same rid:4 as above for mid:v5,v6,v7 (small resolution)...
... ...
10.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).
skipping to change at page 16, line 36 skipping to change at page 20, line 27
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
a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0 a=rid:1 send max-width=1280;max-height=720;max-fps=30;depend=0
a=rid:2 recv max-width=1280;max-height=720;max-fps=30 a=rid:2 recv max-width=1280;max-height=720;max-fps=30
a=rid:5 send max-width=640;max-height=360;max-fps=15 a=rid:5 send max-width=640;max-height=360;max-fps=15
a=rid:6 send max-width=320;max-height=180;max-fps=15 a=rid:6 send max-width=320;max-height=180;max-fps=15
a=simulcast: send rid=0;1;5;6 recv rid=2 a=simulcast: send rid=0;1;5;6 recv rid=2
... ...
...same m=video sections as previous example for mid:v2-v7... ...same m=video sections as previous example for mid:v2-v7...
... ...
11. Open Issues 12. Open Issues
11.1. Declarative SDP 12.1. Declarative SDP
Section 7 describes the use of "a=rid" for declarative SDP. This is Section 7 describes the use of "a=rid" for declarative SDP. This is
a pretty small amount of work, and the use of this mechanism to a pretty small amount of work, and the use of this mechanism to
describe how a sender is going to constrain a stream does have some describe how a sender is going to constrain a stream does have some
amount of utility. Is the text sufficient? If not, do we want to amount of utility. Is the text sufficient? If not, do we want to
invest the work needed to make RID work with declarative use cases? invest the work needed to make RID work with declarative use cases?
PROPOSAL: Keep the current text. PROPOSAL: Keep the current text.
11.2. Definition of bitrate 12.2. Definition of bitrate
Some questions have been raised as to whether we need a more formal Some questions have been raised as to whether we need a more formal
description of bitrate than we currently use. description of bitrate than we currently use.
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 12.3. Escaping new constraint values
The constraints 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
skipping to change at page 17, line 44 skipping to change at page 21, line 32
3. Leave this problem for the first extension constraints - 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 12.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 constraints at IETF 94 face-to-face meeting. support for these constraints at IETF 94 face-to-face meeting.
11.5. Definition of max-fps 12.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
most of a second, followed by a burst of 30 frames 1 ms apart, as most of a second, followed by a burst of 30 frames 1 ms apart, as
part of a stream constrained to 30 fps. Such cases seem undesirable. part of a stream constrained to 30 fps. Such cases seem undesirable.
12. IANA Considerations 13. IANA Considerations
12.1. New SDP Media-Level attribute This specification updates [RFC4855] to give additional guidance on
choice of Format Parameter (fmtp) names, and on their relation to RID
constraints.
13.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 9. with in a RTP Session. Its format is defined in Section 10.
12.2. Registry for RID-Level Parameters 13.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
the stream results in a stream that still complies with the other the stream results in a stream that still complies with the other
skipping to change at page 19, line 35 skipping to change at page 23, line 26
max-bpp [RFCXXXX] max-bpp [RFCXXXX]
depend [RFCXXXX] depend [RFCXXXX]
It is conceivable that a future document wants to define a RID-level It is conceivable that a future document wants to define a RID-level
constraints that contain string values. These extensions need to constraints that contain string values. These extensions need to
take care to conform to the ABNF defined for rid-param-other. In take care to conform to the ABNF defined for rid-param-other. In
particular, this means that such extensions will need to define particular, this means that such extensions will need to define
escaping mechanisms if they want to allow semicolons, unprintable escaping mechanisms if they want to allow semicolons, unprintable
characters, or byte values greater than 127 in the string. characters, or byte values greater than 127 in the string.
13. Security Considerations 14. 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
wishes to receive. In general, however, since the "a=rid" attribute wishes to receive. In general, however, since the "a=rid" attribute
can only restrict a stream to be a subset of what is otherwise can only restrict a stream to be a subset of what is otherwise
allowable, modification of the value cannot result in a stream that allowable, modification of the value cannot result in a stream that
is of higher bandwidth than would be sent to an implementation that is of higher bandwidth than would be sent to an implementation that
does not support this mechanism. does not support this mechanism.
The actual identifiers used for RIDs are expected to be opaque. As The actual identifiers used for RIDs are expected to be opaque. As
such, they are not expected to contain information that would be such, they are not expected to contain information that would be
sensitive, were it observed by third-parties. sensitive, were it observed by third-parties.
14. Acknowledgements 15. 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. Thanks to Colin Perkins for input on future payload
type handing..
15. References 16. References
15.1. Normative References 16.1. Normative References
[I-D.roach-avtext-rid] [I-D.roach-avtext-rid]
Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream
Identifier (RID) Source Description (SDES)", draft-roach- Identifier (RID) Source Description (SDES)", draft-roach-
avtext-rid-02 (work in 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>.
skipping to change at page 20, line 38 skipping to change at page 24, line 33
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[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>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
<http://www.rfc-editor.org/info/rfc4855>.
[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 16.2. Informative References
[H264] ITU-T Recommendation H.264, "Advanced video coding for
generic audiovisual services (V9)", February 2014,
<http://www.itu.int/rec/T-REC-H.264-201304-I>.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-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.
[I-D.ietf-payload-vp8]
Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
Galligan, "RTP Payload Format for VP8 Video", draft-ietf-
payload-vp8-17 (work in progress), September 2015.
[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 [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP
Reduced-Complexity Decoding Operation (RCDO) Video", RFC Payload Format for H.264 Video", RFC 6184, DOI 10.17487/
6185, DOI 10.17487/RFC6185, May 2011, RFC6184, May 2011,
<http://www.rfc-editor.org/info/rfc6185>. <http://www.rfc-editor.org/info/rfc6184>.
[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 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015,
 End of changes. 40 change blocks. 
62 lines changed or deleted 266 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/