draft-ietf-mmusic-rid-08.txt   draft-ietf-mmusic-rid-09.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: April 28, 2017 Cisco Systems Expires: August 12, 2017 Cisco Systems
B. Burman B. Burman
Ericsson Ericsson
A. Roach A. Roach
B. Campen B. Campen
Mozilla Mozilla
October 25, 2016 February 08, 2017
RTP Payload Format Restrictions RTP Payload Format Restrictions
draft-ietf-mmusic-rid-08 draft-ietf-mmusic-rid-09
Abstract Abstract
In this specification, we define a framework for specifying In this specification, we define a framework for specifying
restrictions on RTP streams in the Session Description Protocol. restrictions on RTP streams in the Session Description Protocol.
This framework defines a new "rid" SDP attribute to unambiguously This framework defines a new "rid" SDP attribute to unambiguously
identify the RTP Streams within a RTP Session and restrict the identify the RTP Streams within a RTP Session and restrict the
streams' payload format parameters in a codec-agnostic way beyond streams' payload format parameters in a codec-agnostic way beyond
what is provided with the regular Payload Types. what is 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 April 28, 2017. This Internet-Draft will expire on August 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 3, line 8 skipping to change at page 3, line 8
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 . . . . . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . 21 12.2. Registry for RID-Level Parameters . . . . . . . . . . . 21
13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
15.1. Normative References . . . . . . . . . . . . . . . . . . 23 15.1. Normative References . . . . . . . . . . . . . . . . . . 23
15.2. Informative References . . . . . . . . . . . . . . . . . 24 15.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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
The Payload Type (PT) field in RTP provides a mapping between the RTP The Payload Type (PT) field in RTP provides a mapping between the RTP
payload format and the associated SDP media description. The SDP payload format and the associated SDP media description. The SDP
rtpmap and/or fmtp attributes are used, for a given PT, to the rtpmap and/or fmtp attributes are used, for a given PT, to describe
describe the properties of the media that is carried in the RTP the properties of the media that is carried in the RTP payload.
payload.
Recent advances in standards have given rise to rich multimedia Recent advances in standards have given rise to rich multimedia
applications requiring support for multiple RTP Streams within a RTP applications requiring support for multiple RTP Streams within a RTP
session [I-D.ietf-mmusic-sdp-bundle-negotiation], session [I-D.ietf-mmusic-sdp-bundle-negotiation],
[I-D.ietf-mmusic-sdp-simulcast] or having to support a large number [I-D.ietf-mmusic-sdp-simulcast] or having to support a large number
of codecs. These demands have unearthed challenges inherent with: of codecs. These demands have unearthed challenges inherent with:
o The restricted RTP PT space in specifying the various payload o The restricted RTP PT space in specifying the various payload
configurations, configurations,
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 RTP payload RTP header. However, the assignment of static mapping of RTP payload
type numbers to payload formats and multiplexing of RTP with other type numbers to payload formats and multiplexing of RTP with other
protocols (such as RTCP) could result in limited number of payload protocols (such as RTCP) could result in a limited number of payload
type numbers available for application usage. In scenarios where the type numbers available for application usage. In scenarios where the
number of possible RTP payload configurations exceed the available PT number of possible RTP payload configurations exceed the available PT
space within a RTP Session, there is a need for a way to represent space within a RTP Session, there is a need for a way to represent
the additional restrictions on payload configurations and to the additional restrictions on payload configurations and to
effectively map an RTP Stream to its corresponding restrictions. effectively map an RTP Stream to its corresponding restrictions.
This issue is exacerbated by the increase in techniques - such as This issue is exacerbated by the increase in techniques - such as
simulcast and layered codecs - which introduce additional streams simulcast and layered codecs - which introduce additional streams
into RTP Sessions. into RTP Sessions.
This specification defines a new SDP framework for restricting Source This specification defines a new SDP framework for restricting Source
skipping to change at page 4, line 50 skipping to change at page 4, line 49
3. Key Words for Requirements 3. Key Words for Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119]
4. SDP "a=rid" Media Level Attribute 4. SDP "a=rid" Media Level Attribute
This section defines new SDP media-level attribute [RFC4566], This section defines new SDP media-level attribute [RFC4566],
"a=rid", ("restriction identifier") used to communicate a set of "a=rid", ("restriction identifier") used to communicate a set of
restrictions to be applied an identified RTP Stream. Roughly restrictions to be applied to 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>;]<restriction>=<value>... a=rid:<rid-id> <direction> [pt=<fmt-list>;]<restriction>=<value>...
An "a=rid" SDP media attribute specifies restrictions defining a An "a=rid" SDP media attribute specifies restrictions defining a
unique RTP payload configuration identified via the "rid-id" field. unique RTP payload configuration identified via the "rid-id" field.
This value binds the restriction to the RTP Stream identified by its This value binds the restriction to the RTP Stream identified by its
RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. To be clear, RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. To be clear,
implementations that use the "a=rid" parameter in SDP MUST support implementations that use the "a=rid" parameter in SDP MUST support
the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such
implementations MUST send it for all streams in an m-section that has implementations MUST send it for all streams in an SDP media
"a=rid" lines remaining after applying the rules in Section 6 and its description ("m=") that has "a=rid" lines remaining after applying
subsections. the rules in Section 6 and its subsections.
The "direction" field identifies the directionality of the RTP The "direction" field identifies the direction of the RTP Stream
Stream; it may be either "send" or "recv". packets to which the indicated restrictions are applied. It may be
either "send" or "recv". Note that these restriction direction are
expressed independently of any "inactive", "sendonly", "recvonly", or
"sendrecv" attributes associated with the media section. It is, for
example, valid to indicate "recv" restrictions on a "sendonly"
stream; those restrictions would apply if, at a future point in time,
the stream were changed to "sendrecv" or "recvonly".
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 restrictions (Section 5) The list of zero or more codec-agnostic restrictions (Section 5)
describe the restrictions that the corresponding RTP Stream will describe the restrictions that the corresponding RTP Stream will
conform to. conform to.
skipping to change at page 6, line 24 skipping to change at page 6, line 26
The following restrictions are intended to apply to video codecs in a The following restrictions are intended to apply to video codecs in a
codec-independent fashion. codec-independent fashion.
o max-width, for spatial resolution in pixels. In the case that o max-width, for spatial resolution in pixels. In the case that
stream orientation signaling is used to modify the intended stream orientation signaling is used to modify the intended
display orientation, this attribute refers to the width of the display orientation, this attribute refers to the width of the
stream when a rotation of zero degrees is encoded. stream when a rotation of zero degrees is encoded.
o max-height, for spatial resolution in pixels. In the case that o max-height, for spatial resolution in pixels. In the case that
stream orientation signaling is used to modify the intended stream orientation signaling is used to modify the intended
display orientation, this attribute refers to the width of the display orientation, this attribute refers to the height of the
stream when a rotation of zero degrees is encoded. stream when a rotation of zero degrees is encoded.
o max-fps, for frame rate in frames per second. For encoders that o max-fps, for frame rate in frames per second. For encoders that
do not use a fixed framerate for encoding, this value should do not use a fixed framerate for encoding, this value should
restrict the minimum amount of time between frames: the time restrict the minimum amount of time between frames: the time
between any two consecutive frames SHOULD NOT be less than 1/max- between any two consecutive frames SHOULD NOT be less than 1/max-
fps seconds. fps seconds.
o max-fs, for frame size in pixels per frame. This is the product o max-fs, for frame size in pixels per frame. This is the product
of frame width and frame height, in pixels, for rectangular of frame width and frame height, in pixels, for rectangular
skipping to change at page 7, line 14 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. These values MUST be encoded with at most four 0.0001 to 48.0. These values MUST be encoded with at most four
digits to the right of the decimal point. digits to the right of the decimal point.
o depend, to identify other streams that the stream depends on. The o depend, to identify other streams that the stream depends on. The
value is a comma-separated list of rid-ids. These rid-ids value is a comma-separated list of rid-ids. These rid-ids
identify RTP streams that this stream depends on in order to allow identify RTP streams that this stream depends on in order to allow
for proper interpretation. for proper interpretation. The mechanism defined in this this
document allows for such dependencies to be expressed only when
the streams are in the same media section.
All the restrictions are optional and are subject to negotiation All the restrictions are optional and are subject to negotiation
based on the SDP Offer/Answer rules described in Section 6. based on the SDP Offer/Answer rules described in Section 6.
This list is intended to be an initial set of restrictions. Future This list is intended to be an initial set of restrictions. Future
documents may define additional restrictions; see Section 12.2. documents may define additional restrictions; see Section 12.2.
While this document does not define restrictions for audio codecs or While this document does not define restrictions for audio codecs or
any media types other than video, there is no reason such any media types other than video, there is no reason such
restrictions should be precluded from definition and registration by restrictions should be precluded from definition and registration by
other documents. other documents.
skipping to change at page 8, line 11 skipping to change at page 8, line 14
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-id" that is unique within a media 1. It MUST generate a "rid-id" that is unique within a media
description description
2. It MUST set the direction for the "rid-id" to one of "send" or 2. It MUST set the direction for the "rid-id" to one of "send" or
"recv" "recv"
3. It MAY include a listing of SDP format tokens (usually 3. It MAY include a listing of SDP media formats (usually
corresponding to RTP payload types) allowed to appear in the RTP corresponding to RTP payload types) allowed to appear in the RTP
Stream. Any Payload Types chosen MUST be a valid payload type Stream. Any Payload Types chosen MUST be a valid payload type
for the media section (that is, it must be listed on the "m=" for the media section (that is, it must be listed on the "m="
line). The order of the listed formats is significant; the line). The order of the listed formats is significant; the
alternatives are listed from (left) most preferred to (right) alternatives are listed from (left) most preferred to (right)
least preferred. When using RID, this preference overrides the least preferred. When using RID, this preference overrides the
normal codec preference as expressed by format type ordering on normal codec preference as expressed by format type ordering on
the "m="-line, using regular SDP rules. the "m="-line, using regular SDP rules.
4. The Offerer then chooses zero or more "a=rid" restrictions 4. The Offerer then chooses zero or more "a=rid" restrictions
skipping to change at page 8, line 43 skipping to change at page 8, line 46
Type for the specified RTP Stream. Type for the specified RTP Stream.
If a given codec would require an "a=fmtp" line when used without If a given codec would require an "a=fmtp" line when used without
"a=rid" then the offer MUST include a valid corresponding "a=fmtp" "a=rid" then the offer MUST include a valid corresponding "a=fmtp"
line even when using "a=rid". line even when using "a=rid".
6.2. Answerer processing the SDP Offer 6.2. Answerer processing the SDP Offer
6.2.1. "a=rid"-unaware Answerer 6.2.1. "a=rid"-unaware Answerer
If the receiver doesn't support the framework proposed in this If the receiver doesn't support the framework defined 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 media formats that otherwise require it (in other words, the
line cannot be used to replace "a=fmtp" configuration). As a result, "a=rid" line cannot be used to replace "a=fmtp" configuration). As a
ignoring the "a=rid" line is always guaranteed to result in a valid result, ignoring the "a=rid" line is always guaranteed to result in a
session description. valid session description.
6.2.2. "a=rid"-aware Answerer 6.2.2. "a=rid"-aware Answerer
If the answerer supports the "a=rid" attribute, the following If the answerer supports the "a=rid" attribute, the following
verification steps are executed, in order, for each "a=rid" line in a verification steps are executed, in order, for each "a=rid" line in a
given media description: received offer:
1. The answerer ensures that the "a=rid" line is syntactically well 1. The answerer ensures that the "a=rid" line is syntactically well
formed. In the case of a syntax error, the "a=rid" line is formed. In the case of a syntax error, the "a=rid" line is
discarded. discarded.
2. Extract the rid-id from the "a=rid" line and verify its 2. Extract the rid-id from the "a=rid" line and verify its
uniqueness within a media section. In the case of a duplicate, uniqueness within a media section. In the case of a duplicate,
the entire "a=rid" line, and all "a=rid" lines with rid-ids that the entire "a=rid" line, and all "a=rid" lines with rid-ids that
duplicate this line, are discarded and MUST NOT be included in duplicate this line, are discarded and MUST NOT be included in
the SDP Answer. the SDP Answer.
skipping to change at page 9, line 34 skipping to change at page 9, line 36
from the "m=" line is discarded from the set of values in the from the "m=" line is discarded from the set of values in the
"pt=". If no values are left in the "pt=" parameter after this "pt=". If no values are left in the "pt=" parameter after this
processing, then the "a=rid" line is discarded. processing, then the "a=rid" line is discarded.
4. If the "direction" field is "recv", The answerer ensures that 4. If the "direction" field is "recv", The answerer ensures that
"a=rid" restrictions are supported. In the case of an "a=rid" restrictions are supported. In the case of an
unsupported restriction, the "a=rid" line is discarded. unsupported restriction, the "a=rid" line is discarded.
5. If the "depend" restriction is included, the answerer MUST make 5. If the "depend" restriction is included, the answerer MUST make
sure that the listed rid-ids unambiguously match the rid-ids in sure that the listed rid-ids unambiguously match the rid-ids in
the SDP offer. Any "a=rid" lines that do not are discarded. the media description. Any "depend" "a=rid" lines that do not
are discarded.
6. The answerer verifies that the restrictions are consistent with 6. The answerer verifies that the restrictions are consistent with
at least one of the codecs to be used with the RTP Stream. If at least one of the codecs to be used with the RTP Stream. If
the "a=rid" line contains a "pt=", it contains the list of such the "a=rid" line contains a "pt=", it contains the list of such
codecs; otherwise, the list of such codecs is taken from the codecs; otherwise, the list of such codecs is taken from the
associated "m=" line. See Section 8 for more detail. If the associated "m=" line. See Section 8 for more detail. If the
"a=rid" restrictions are incompatible with the other codec "a=rid" restrictions are incompatible with the other codec
properties for all codecs, then the "a=rid" line is discarded. properties for all codecs, then the "a=rid" line is discarded.
Note that the answerer does not need to understand every restriction Note that the answerer does not need to understand every restriction
skipping to change at page 10, line 13 skipping to change at page 10, line 13
with interoperability. with interoperability.
6.3. Generating the SDP Answer 6.3. Generating the SDP Answer
Having performed verification of the SDP offer as described in Having performed verification of the SDP offer as described in
Section 6.2.2, the answerer shall perform the following steps to Section 6.2.2, the answerer shall perform the following steps to
generate the SDP answer. generate the SDP answer.
For each "a=rid" line: For each "a=rid" line:
1. The sense of of the "direction" field is reversed: "send" is 1. The value of the "direction" field is reversed: "send" is changed
changed to "recv", and "recv" is changed to "send". to "recv", and "recv" is changed to "send".
2. The answerer MAY choose to modify specific "a=rid" restriction 2. The answerer MAY choose to modify specific "a=rid" restriction
value in the answer SDP. In such a case, the modified value MUST values in the answer SDP. In such a case, the modified value
be more restricted than the ones specified in the offer. The MUST be more restricted than the ones specified in the offer.
answer MUST NOT include any restrictions that were not present in The answer MUST NOT include any restrictions that were not
the offer. present in the offer.
3. The answerer MUST NOT modify the "rid-id" present in the offer. 3. The answerer MUST NOT modify the "rid-id" present in the offer.
4. If the "a=rid" line contains a "pt=", the answerer is allowed to 4. If the "a=rid" line contains a "pt=", the answerer is allowed to
discard one or more media formats from a given "a=rid" line. If discard one or more media formats from a given "a=rid" line. If
the answerer chooses to discard all the media format tokens from the answerer chooses to discard all the media formats from an
an "a=rid" line, the answerer MUST discard the entire "a=rid" "a=rid" line, the answerer MUST discard the entire "a=rid" line.
line. If the offer did not contain a "pt=" for a given "a=rid" If the offer did not contain a "pt=" for a given "a=rid" line,
line, then the answer MUST NOT contain a "pt=" in the then the answer MUST NOT contain a "pt=" in the corresponding
corresponding line. line.
5. In cases where the answerer is unable to support the payload 5. In cases where the answerer is unable to support the payload
configuration specified in a given "a=rid" line in the offer, the configuration specified in a given "a=rid" line with a direction
answerer MUST discard the corresponding "a=rid" line. This of "recv" in the offer, the answerer MUST discard the
includes situations in which the answerer does not understand one corresponding "a=rid" line. This includes situations in which
or more of the restrictions in an "a=rid" line with a direction the answerer does not understand one or more of the restrictions
of "recv". in an "a=rid" line with a direction of "recv".
Note: in the case that the answerer uses different PT values to Note: in the case that the answerer uses different PT values to
represent a codec than the offerer did, the "a=rid" values in the represent a codec than the offerer did, the "a=rid" values in the
answer use the PT values that are present in its answer. answer use the PT values that are present in its answer.
6.4. Offerer Processing of the SDP Answer 6.4. Offerer Processing of the SDP Answer
The offerer SHALL follow these steps when processing the answer: The offerer SHALL follow these steps when processing the answer:
1. The offerer matches the "a=rid" line in the answer to the "a=rid" 1. The offerer matches the "a=rid" line in the answer to the "a=rid"
skipping to change at page 13, line 32 skipping to change at page 13, line 32
[RFC7741] defines two format parameters for the VP8 codec. Both [RFC7741] defines two format parameters for the VP8 codec. Both
correspond to restrictions on receiver capabilities, and never correspond to restrictions on receiver capabilities, and never
indicate sending restrictions. indicate sending restrictions.
8.1.1. max-fr - Maximum Framerate 8.1.1. max-fr - Maximum Framerate
The VP8 "max-fr" format parameter corresponds to the "max-fps" The VP8 "max-fr" format parameter corresponds to the "max-fps"
restriction defined in this specification. If an RTP sender is restriction defined in this specification. If an RTP sender is
generating a stream using a format defined with this format generating a stream using a format defined with this format
parameter, and the sending restrictions defined via "a=rid" include a parameter, and the sending restrictions defined via "a=rid" include a
"max-fps" parameter, then the sent stream is will conform to the "max-fps" parameter, then the sent stream will conform to the smaller
smaller of the two values. of the two values.
8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks
The VP8 "max-fs" format parameter corresponds to the "max-fs" The VP8 "max-fs" format parameter corresponds to the "max-fs"
restriction defined in this document, by way of a conversion factor restriction defined in this document, by way of a conversion factor
of the number of pixels per macroblock (typically 256). If an RTP of the number of pixels per macroblock (typically 256). If an RTP
sender is generating a stream using a format defined with this format sender is generating a stream using a format defined with this format
parameter, and the sending restrictions defined via "a=rid" include a parameter, and the sending restrictions defined via "a=rid" include a
"max-fs" parameter, then the sent stream will conform to the smaller "max-fs" parameter, then the sent stream will conform to the smaller
of the two values; that is, the number of pixels per frame will not of the two values; that is, the number of pixels per frame will not
skipping to change at page 15, line 15 skipping to change at page 15, line 15
equivalents. equivalents.
The following codec format parameters correspond to restrictions on The following codec format parameters correspond to restrictions on
receiver capabilities, and never indicate sending restrictions. receiver capabilities, and never indicate sending restrictions.
8.2.1. profile-level-id and max-recv-level - Negotiated Sub-Profile 8.2.1. profile-level-id and max-recv-level - Negotiated Sub-Profile
These parameters include a "level" indicator, which acts as an index These parameters include a "level" indicator, which acts as an index
into Table A-1 of [H264]. This table contains a number of into Table A-1 of [H264]. This table contains a number of
parameters, several of which correspond to the restrictions defined parameters, several of which correspond to the restrictions defined
in this document. [RFC6184] also defines formate parameters for the in this document. [RFC6184] also defines format parameters for the
H.264 codec that may increase the maximum values indicated by the H.264 codec that may increase the maximum values indicated by the
negotiated level. The following sections describe the interaction negotiated level. The following sections describe the interaction
between these parameters and the restrictions defined by this between these parameters and the restrictions defined by this
document. In all cases, the H.264 parameters being discussed are the document. In all cases, the H.264 parameters being discussed are the
maximum of those indicated by [H264] Table A-1 and those indicated in maximum of those indicated by [H264] Table A-1 and those indicated in
the corresponding "a=fmtp" line. the corresponding "a=fmtp" line.
8.2.2. max-br / MaxBR - Maximum Video Bitrate 8.2.2. max-br / MaxBR - Maximum Video Bitrate
The H.264 "MaxBR" parameter (and its equivalent "max-br" format The H.264 "MaxBR" parameter (and its equivalent "max-br" format
parameter) corresponds to the "max-bps" restriction defined in this parameter) corresponds to the "max-bps" restriction defined in this
specification, by way of a conversion factor of 1000 or 1200; see specification, by way of a conversion factor of 1000 or 1200; see
[RFC6184] for details regarding which factor gets used under [RFC6184] for details regarding which factor gets used under
differing circumstances. differing circumstances.
If an RTP sender is generating a stream using a format defined with If an RTP sender is generating a stream using a format defined with
this format parameter, and the sending restrictions defined via this format parameter, and the sending restrictions defined via
"a=rid" include a "max-fps" parameter, then the sent stream is will "a=rid" include a "max-fps" parameter, then the sent stream 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 equivalent "max-fs" format
parameter) corresponds roughly to the "max-fs" restriction defined in parameter) corresponds roughly to the "max-fs" restriction defined in
this document, by way of a conversion factor of 256 (the number of this document, by way of a conversion factor of 256 (the number of
pixels per macroblock). pixels per macroblock).
If an RTP sender is generating a stream using a format defined with If an RTP sender is generating a stream using a format defined with
this format parameter, and the sending restrictions defined via this format parameter, and the sending restrictions defined via
"a=rid" include a "max-fs" parameter, then the sent stream is will "a=rid" include a "max-fs" parameter, then the sent stream will
conform to the smaller of the two values - that is: conform to the smaller of the two values - that is:
min(rid_max_fs, h264_MaxFs * 256) min(rid_max_fs, h264_MaxFs * 256)
8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing Rate
The H.264 "MaxMBPS" parameter (and its equiavelent "max-mbps" format The H.264 "MaxMBPS" parameter (and its equivalent "max-mbps" format
parameter) corresponds roughly to the "max-pps" restriction defined parameter) corresponds roughly to the "max-pps" restriction defined
in this document, by way of a conversion factor of 256 (the number of in this document, by way of a conversion factor of 256 (the number of
pixels per macroblock). pixels per macroblock).
If an RTP sender is generating a stream using a format defined with If an RTP sender is generating a stream using a format defined with
this format parameter, and the sending restrictions defined via this format parameter, and the sending restrictions defined via
"a=rid" include a "max-pps" parameter, then the sent stream is will "a=rid" include a "max-pps" parameter, then the sent stream will
conform to the smaller of the two values - that is: conform to the smaller of the two values - that is:
min(rid_max_pps, h264_MaxMBPS * 256) min(rid_max_pps, h264_MaxMBPS * 256)
8.2.5. max-smbps - Maximum Decoded Picture Buffer 8.2.5. max-smbps - Maximum Decoded Picture Buffer
The H.264 "max-smbps" format parameter operates the same way as the The H.264 "max-smbps" format parameter operates the same way as the
"max-mpbs" format parameter, under the hypothetical assumption that "max-mpbs" format parameter, under the hypothetical assumption that
all macroblocks are static macroblocks. It is handled by applying all macroblocks are static macroblocks. It is handled by applying
the conversion factor described in Section 8.1 of [RFC6184], and the the conversion factor described in Section 8.1 of [RFC6184], and the
skipping to change at page 21, line 38 skipping to change at page 21, line 38
The "rid" SDP attribute is used to to unambiguously identify The "rid" SDP attribute is used to to unambiguously identify
the RTP Streams within a RTP Session and restrict the the RTP Streams within a RTP Session and restrict the
streams' payload format parameters in a codec-agnostic way streams' payload format parameters in a codec-agnostic way
beyond what is provided with the regular Payload Types. beyond what is provided with the regular Payload Types.
A specification of appropriate attribute values for this attribute A specification of appropriate attribute values for this attribute
Valid values are defined by the ABNF in [RFCXXXXX] Valid values are defined by the ABNF in [RFCXXXXX]
Multiplexing (Mux) Category
NORMAL
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" restrictions level)" within the SDP parameters registry. The "a=rid" restrictions
MUST be registered with IANA and documented under the same rules as MUST be registered with IANA and documented under the same rules as
for SDP session-level and media-level attributes as specified in for SDP session-level and media-level attributes as specified in
[RFC4566]. [RFC4566].
Parameters for "a=rid" lines that modify the nature of encoded media Parameters for "a=rid" lines that modify the nature of encoded media
MUST be of the form that the result of applying the modification to MUST be of the form that the result of applying the modification to
skipping to change at page 24, line 20 skipping to change at page 24, line 28
15.2. Informative References 15.2. Informative References
[H264] ITU-T Recommendation H.264, "Advanced video coding for [H264] ITU-T Recommendation H.264, "Advanced video coding for
generic audiovisual services (V9)", February 2014, generic audiovisual services (V9)", February 2014,
<http://www.itu.int/rec/T-REC-H.264-201304-I>. <http://www.itu.int/rec/T-REC-H.264-201304-I>.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-35 (work in progress), October 2016. negotiation-36 (work in progress), October 2016.
[I-D.ietf-mmusic-sdp-simulcast] [I-D.ietf-mmusic-sdp-simulcast]
Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
"Using Simulcast in SDP and RTP Sessions", draft-ietf- "Using Simulcast in SDP and RTP Sessions", draft-ietf-
mmusic-sdp-simulcast-05 (work in progress), June 2016. mmusic-sdp-simulcast-07 (work in progress), January 2017.
[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>.
[RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP [RFC6184] Wang, Y., Even, R., Kristensen, T., and R. Jesup, "RTP
Payload Format for H.264 Video", RFC 6184, DOI 10.17487/ Payload Format for H.264 Video", RFC 6184, DOI 10.17487/
RFC6184, May 2011, RFC6184, May 2011,
<http://www.rfc-editor.org/info/rfc6184>. <http://www.rfc-editor.org/info/rfc6184>.
 End of changes. 32 change blocks. 
52 lines changed or deleted 64 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/