draft-ietf-mmusic-rid-14.txt   draft-ietf-mmusic-rid-15.txt 
Network Working Group A. Roach (Editor) Network Working Group A. Roach (Editor)
Internet-Draft Mozilla Internet-Draft Mozilla
Updates: 4855 (if approved) February 26, 2018 Updates: 4855 (if approved) May 15, 2018
Intended status: Standards Track Intended status: Standards Track
Expires: August 30, 2018 Expires: November 16, 2018
RTP Payload Format Restrictions RTP Payload Format Restrictions
draft-ietf-mmusic-rid-14 draft-ietf-mmusic-rid-15
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" ("restriction identifier") SDP
identify the RTP Streams within a RTP Session and restrict the attribute to unambiguously identify the RTP Streams within an RTP
streams' payload format parameters in a codec-agnostic way beyond Session and restrict the streams' payload format parameters in a
what is provided with the regular Payload Types. codec-agnostic way beyond what is provided with the regular Payload
Types.
This specification updates RFC4855 to give additional guidance on This specification updates RFC4855 to give additional guidance on
choice of Format Parameter (fmtp) names, and on their relation to the choice of Format Parameter (fmtp) names, and on their relation to the
restrictions defined by this document. restrictions 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 30, 2018. This Internet-Draft will expire on November 16, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 25 skipping to change at page 2, line 26
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" restrictions . . . . . . . . . . . . . . . . . . . . 6 5. "a=rid" restrictions . . . . . . . . . . . . . . . . . . . . 6
6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 8 6. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 8
6.1. Generating the Initial SDP Offer . . . . . . . . . . . . 8 6.1. Generating the Initial SDP Offer . . . . . . . . . . . . 8
6.2. Answerer processing the SDP Offer . . . . . . . . . . . . 9 6.2. Answerer processing the SDP Offer . . . . . . . . . . . . 9
6.2.1. "a=rid"-unaware Answerer . . . . . . . . . . . . . . 9 6.2.1. "a=rid"-unaware Answerer . . . . . . . . . . . . . . 9
6.2.2. "a=rid"-aware Answerer . . . . . . . . . . . . . . . 9 6.2.2. "a=rid"-aware Answerer . . . . . . . . . . . . . . . 9
6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 10 6.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 10
6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 11 6.4. Offerer Processing of the SDP Answer . . . . . . . . . . 11
6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 12 6.5. Modifying the Session . . . . . . . . . . . . . . . . . . 13
7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 13 7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 13
8. Interaction with Other Techniques . . . . . . . . . . . . . . 13 8. Interaction with Other Techniques . . . . . . . . . . . . . . 13
8.1. Interaction with VP8 Format Parameters . . . . . . . . . 14 8.1. Interaction with VP8 Format Parameters . . . . . . . . . 14
8.1.1. max-fr - Maximum Framerate . . . . . . . . . . . . . 14 8.1.1. max-fr - Maximum Framerate . . . . . . . . . . . . . 14
8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks . . . 14 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks . . . 14
8.2. Interaction with H.264 Format Parameters . . . . . . . . 15 8.2. Interaction with H.264 Format Parameters . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . . . 16 Profile . . . . . . . . . . . . . . . . . . . . . . . 16
8.2.2. max-br / MaxBR - Maximum Video Bitrate . . . . . . . 16 8.2.2. max-br / MaxBR - Maximum Video Bitrate . . . . . . . 16
8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264 8.2.3. max-fs / MaxFS - Maximum Framesize, in H.264
skipping to change at page 2, line 49 skipping to change at page 2, line 50
8.2.5. max-smbps - Maximum Decoded Picture Buffer . . . . . 17 8.2.5. max-smbps - Maximum Decoded Picture Buffer . . . . . 17
8.3. Redundancy Formats and Payload Type Restrictions . . . . 17 8.3. Redundancy Formats and Payload Type Restrictions . . . . 17
9. Format Parameters for Future Payloads . . . . . . . . . . . . 18 9. Format Parameters for Future Payloads . . . . . . . . . . . . 18
10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 18 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 18
11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 20 11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 20 11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 20
11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 22 11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 22 12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 22
12.2. Registry for RID-Level Parameters . . . . . . . . . . . 23 12.2. Registry for RID-Level Parameters . . . . . . . . . . . 23
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 13. Security Considerations . . . . . . . . . . . . . . . . . . . 24
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
15.1. Normative References . . . . . . . . . . . . . . . . . . 25 15.1. Normative References . . . . . . . . . . . . . . . . . . 25
15.2. Informative References . . . . . . . . . . . . . . . . . 26 15.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Terminology 1. Terminology
The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP The terms "Source RTP Stream", "Endpoint", "RTP Session", and "RTP
skipping to change at page 3, line 24 skipping to change at page 3, line 25
[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 describe rtpmap and/or fmtp attributes are used, for a given PT, to describe
the properties of the media that is carried in the RTP payload. the properties of the media that is carried in the RTP payload.
Recent advances in standards have given rise to rich multimedia Recent advances in standards have given rise to rich multimedia
applications requiring support for multiple RTP Streams within a RTP applications requiring support for multiple RTP Streams within an 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 a 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 exceeds the available
space within a RTP Session, there is a need for a way to represent PT space within an RTP Session, there is a need for a way to
the additional restrictions on payload configurations and to represent the additional restrictions on payload configurations and
effectively map an RTP Stream to its corresponding restrictions. to 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
RTP Streams (Section 2.1.10 [RFC7656]), along with the SDP attributes RTP Streams (Section 2.1.10 [RFC7656]), along with the SDP attributes
to restrict payload formats in a codec-agnostic way. This framework to restrict payload formats in a codec-agnostic way. This framework
can be thought of as a complementary extension to the way the media can be thought of as a complementary extension to the way the media
format parameters are specified in SDP today, via the "a=fmtp" format parameters are specified in SDP today, via the "a=fmtp"
attribute. attribute.
The additional restrictions on individual streams are indicated with The additional restrictions on individual streams are indicated with
a new "a=rid" SDP attribute. Note that the restrictions communicated a new "a=rid" ("restriction identifier") SDP attribute. Note that
via this attribute only serve to further restrict the parameters that the restrictions communicated via this attribute only serve to
are established on a PT format. They do not relax any existing further restrict the parameters that are established on a PT format.
restrictions. They do not relax any restrictions imposed by other mechanisms.
This specification makes use of the RTP Stream Identifier SDES RTCP This specification makes use of the RTP Stream Identifier Source
item defined in [I-D.ietf-avtext-rid] to provide correlation between Description (SDES) RTCP item defined in [I-D.ietf-avtext-rid] to
the RTP Packets and their format specification in the SDP. provide correlation between the RTP Packets and their format
specification in the SDP.
As described in Section 6.2.1, this mechanism achieves backwards As described in Section 6.2.1, this mechanism achieves backwards
compatibility via the normal SDP processing rules, which require compatibility via the normal SDP processing rules, which require
unknown a= lines to be ignored. This means that implementations need unknown a= lines to be ignored. This means that implementations need
to be prepared to handle successful offers and answers from other to be prepared to handle successful offers and answers from other
implementations that neither indicate nor honor the restrictions implementations that neither indicate nor honor the restrictions
requested by this mechanism. requested by this mechanism.
Further, as described in Section 6 and its subsections, this Further, as described in Section 6 and its subsections, this
mechanism achieves extensibility by: (a) having offerers include all mechanism achieves extensibility by: (a) having offerers include all
skipping to change at page 4, line 45 skipping to change at page 4, line 46
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
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", used to communicate a set of restrictions to be applied to
restrictions to be applied to an identified RTP Stream. Roughly an identified RTP Stream. Roughly speaking, this attribute takes the
speaking, this attribute takes the following form (see Section 10 for 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 Source Description (SDES) item
implementations that use the "a=rid" parameter in SDP MUST support [I-D.ietf-avtext-rid]. Implementations that use the "a=rid"
the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such parameter in SDP MUST support the RtpStreamId SDES item described in
implementations MUST send it for all streams in an SDP media [I-D.ietf-avtext-rid]. Such implementations MUST send that SDES item
description ("m=") that have "a=rid" lines remaining after applying for all streams in an SDP media description ("m=") that have "a=rid"
the rules in Section 6 and its subsections. lines remaining after applying the rules in Section 6 and its
subsections.
Implementations that use the "a=rid" parameter in SDP and that make Implementations that use the "a=rid" parameter in SDP and that make
use of redundancy RTP streams [RFC7656], e.g. RTP RTX [RFC4588] or use of redundancy RTP streams [RFC7656], e.g. RTP RTX [RFC4588] or
FEC [RFC5109], for any of the source RTP streams that have "a=rid" FEC [RFC5109], for any of the source RTP streams that have "a=rid"
lines remaining after applying the rules in Section 6 and its lines remaining after applying the rules in Section 6 and its
subsections, MUST support the RepairedRtpStreamId SDES item described subsections, MUST support the RepairedRtpStreamId SDES item described
in [I-D.ietf-avtext-rid] for those redundancy RTP streams. in [I-D.ietf-avtext-rid] for those redundancy RTP streams.
RepairedRtpStreamId MUST be used for redundancy RTP streams to which RepairedRtpStreamId MUST be used for redundancy RTP streams to which
it can be applied. Use of RepairedRtpStreamId is not applicable for it can be applied. Use of RepairedRtpStreamId is not applicable for
redundancy formats that directly associate RTP streams through shared redundancy formats that directly associate RTP streams through shared
skipping to change at page 7, line 16 skipping to change at page 7, line 16
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 height 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 is used to
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
frames. frames.
o max-br, for bit rate in bits per second. The restriction applies o max-br, for bit rate in bits per second. The restriction applies
to the media payload only, and does not include overhead to the media payload only, and does not include overhead
skipping to change at page 7, line 44 skipping to change at page 7, line 44
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. These values MUST be encoded with at most four 0.0001 to 48.0. These values MUST NOT be encoded with more than
digits to the right of the decimal point. four 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. The mechanism defined in this document for proper interpretation. The mechanism defined in this document
allows for such dependencies to be expressed only when the streams allows for such dependencies to be expressed only when the streams
are in the same media section. 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.
skipping to change at page 8, line 27 skipping to change at page 8, line 27
this section. 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 (that is: combination of
unambiguous scope. Similarly, when using BUNDLE sending address, sending port, receiving address, receiving port, and
[I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP transport protocol), which provides an unambiguous scope. Similarly,
streams uniquely to a single media description. when using BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], MID
values associate RTP streams uniquely to a single media description.
When RID is used with the BUNDLE mechanism, streams will be
associated with both MID and RID SDES items.
6.1. Generating the Initial SDP Offer 6.1. Generating the Initial SDP Offer
For each RTP media description in the offer, the offerer MAY choose For each RTP media description in the offer, the offerer MAY choose
to include one or more "a=rid" lines to specify a configuration to include one or more "a=rid" lines to specify a configuration
profile for the given set of RTP Payload Types. profile for the given set of RTP Payload Types.
In order to construct a given "a=rid" line, the offerer must follow In order to construct a given "a=rid" line, the offerer must follow
these steps: these steps:
skipping to change at page 9, line 50 skipping to change at page 10, line 5
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
received offer: 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. The answerer extracts the rid-id from the "a=rid" line and
uniqueness within a media section. In the case of a duplicate, verifies its uniqueness within a media section. In the case of a
the entire "a=rid" line, and all "a=rid" lines with rid-ids that duplicate, the entire "a=rid" line, and all "a=rid" lines with
duplicate this line, are discarded and MUST NOT be included in rid-ids that duplicate this line, are discarded and MUST NOT be
the SDP Answer. included in 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 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 the
"a=rid" restrictions are supported. In the case of an specified "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 media description. Any "depend" "a=rid" lines that do not the media description. Any "depend" "a=rid" lines that do not
are discarded. 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
skipping to change at page 10, line 43 skipping to change at page 10, line 46
present in a "send" line: if a stream sender restricts the stream in present in a "send" line: if a stream sender restricts the stream in
a way that the receiver does not understand, this causes no issues a way that the receiver does not understand, this causes no issues
with interoperability. with interoperability.
6.3. Generating the SDP Answer 6.3. Generating the SDP Answer
Having performed verification of the SDP offer as described in Having performed verification of the SDP offer as described in
Section 6.2.2, the answerer shall perform the following steps to Section 6.2.2, the answerer shall perform the following steps to
generate the SDP answer. generate the SDP answer.
For each "a=rid" line: For each "a=rid" line that has not been discarded by previous
processing:
1. The value of the "direction" field is reversed: "send" is changed 1. The value of the "direction" field is reversed: "send" is 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
values in the answer SDP. In such a case, the modified value values in the answer SDP. In such a case, the modified value
MUST be more restricted than the ones specified in the offer. MUST be more restrictive than the ones specified in the offer.
The answer MUST NOT include any restrictions that were not The answer MUST NOT include any restrictions that were not
present in 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 formats from an the answerer chooses to discard all the media formats from an
"a=rid" line, the answerer MUST discard the entire "a=rid" line. "a=rid" line, the answerer MUST discard the entire "a=rid" line.
If the offer did not contain a "pt=" for a given "a=rid" line, If the offer did not contain a "pt=" for a given "a=rid" line,
skipping to change at page 11, line 41 skipping to change at page 11, line 44
The offerer SHALL follow these steps when processing the answer: The offerer SHALL follow these steps when processing the answer:
1. The offerer matches the "a=rid" line in the answer to the "a=rid" 1. The offerer matches the "a=rid" line in the answer to the "a=rid"
line in the offer using the "rid-id". If no matching line can be line in the offer using the "rid-id". If no matching line can be
located in the offer, the "a=rid" line is ignored. located in the offer, the "a=rid" line is ignored.
2. If the answer contains any restrictions that were not present in 2. If the answer contains any restrictions that were not present in
the offer, then the offerer SHALL discard the "a=rid" line. the offer, then the offerer SHALL discard the "a=rid" line.
3. If the restrictions have been changed between the offer and the 3. If the restrictions have been changed between the offer and the
answer, the offerer MUST ensure that the modifications can be answer, the offerer MUST ensure that the modifications are more
supported; if they cannot, the offerer SHALL discard the "a=rid" restrictive than they were in the original offer, and that they
can be supported; if not, the offerer SHALL discard the "a=rid"
line. line.
4. If the "a=rid" line in the answer contains a "pt=" but the offer 4. If the "a=rid" line in the answer contains a "pt=" but the offer
did not, the offerer SHALL discard the "a=rid" line. did not, the offerer SHALL discard the "a=rid" line.
5. If the "a=rid" line in the answer contains a "pt=" and the offer 5. If the "a=rid" line in the answer contains a "pt=" and the offer
did as well, the offerer verifies that the list of payload types did as well, the offerer verifies that the list of payload types
is a subset of those sent in the corresponding "a=rid" line in is a subset of those sent in the corresponding "a=rid" line in
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
skipping to change at page 13, line 33 skipping to change at page 13, line 39
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
restrictions on the media stream, are expected to result in a non- restrictions on the media stream, are expected to result in a non-
empty union. For example, if image attributes are used to indicate empty intersection. For example, if image attributes are used to
that a PT has a minimum width of 640, then specification of "max- indicate that a PT has a minimum width of 640, then specification of
width=320" in an "a=rid" line that is then applied to that PT is "max-width=320" in an "a=rid" line that is then applied to that PT is
nonsensical. According to the rules of Section 6.2.2, this will nonsensical. According to the rules of Section 6.2.2, this will
result in the corresponding "a=rid" line being ignored by the result in the corresponding "a=rid" line being ignored by the
recipient. recipient.
In an answer, the "a=rid" lines, when combined with the other In an answer, the "a=rid" lines, when combined with the other
restrictions on the media stream, are also expected to result in a restrictions on the media stream, are also expected to result in a
non-empty union. If the implementation generating an answer wishes non-empty intersection. If the implementation generating an answer
to restrict a property of the stream below that which would be wishes 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 discard the "a=rid" line "a=imageattr"), its only recourse is to discard 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
restrict the stream beyond what is allowed by other mechanisms, then restrict 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.
The following subsections demonstrate these interactions using The following subsections demonstrate these interactions using
commonly-used video codecs. These descriptions are illustrative of commonly-used video codecs. These descriptions are illustrative of
the interaction principles outlined above, and are not normative. the interaction principles outlined above, and are not normative.
skipping to change at page 15, line 50 skipping to change at page 15, line 50
o sprop-parameter-sets o sprop-parameter-sets
o use-level-src-parameter-sets o use-level-src-parameter-sets
Note that the max-cpb and max-dpb format parameters for H.264 Note that the max-cpb and max-dpb format parameters for H.264
correspond to restrictions on the stream, but they are specific to correspond to restrictions on the stream, but they are specific to
the way the H.264 codec operates, and do not have codec-independent the way the H.264 codec operates, and do not have codec-independent
equivalents. equivalents.
The following codec format parameters correspond to restrictions on The [RFC6184] codec format parameters covered in the following
receiver capabilities, and never indicate sending restrictions. sections correspond to restrictions on 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 format 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
skipping to change at page 18, line 44 skipping to change at page 18, line 44
Registrations of future RTP payload format specifications that define Registrations of future RTP payload format specifications that define
media types that have parameters matching the RID restrictions media types that have parameters matching the RID restrictions
specified in this memo SHOULD name those parameters in a manner that specified in this memo SHOULD name those parameters in a manner that
matches the names of those RID restrictions, and SHOULD explicitly matches the names of those RID restrictions, and SHOULD explicitly
state what media type parameters are restricted by what RID state what media type parameters are restricted by what RID
restrictions. restrictions.
10. Formal Grammar 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, with the case-sensitive extensions described in
defined in this document. [RFC7405], for each of the new media and "a=rid" attributes defined
in this document.
rid-syntax = "a=rid:" rid-id SP rid-dir rid-syntax = %s"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}} > alpha-numeric = < as defined in {{RFC4566}} >
rid-dir = "send" / "recv" rid-dir = %s"send" / %s"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 = %s"pt=" fmt *( "," fmt )
fmt = < as 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
rid-width-param = "max-width" [ "=" int-param-val ] rid-width-param = %s"max-width" [ "=" int-param-val ]
rid-height-param = "max-height" [ "=" int-param-val ] rid-height-param = %s"max-height" [ "=" int-param-val ]
rid-fps-param = "max-fps" [ "=" int-param-val ] rid-fps-param = %s"max-fps" [ "=" int-param-val ]
rid-fs-param = "max-fs" [ "=" int-param-val ] rid-fs-param = %s"max-fs" [ "=" int-param-val ]
rid-br-param = "max-br" [ "=" int-param-val ] rid-br-param = %s"max-br" [ "=" int-param-val ]
rid-pps-param = "max-pps" [ "=" int-param-val ] rid-pps-param = %s"max-pps" [ "=" int-param-val ]
rid-bpp-param = "max-bpp" [ "=" float-param-val ] rid-bpp-param = %s"max-bpp" [ "=" float-param-val ]
rid-depend-param = "depend=" rid-list rid-depend-param = %s"depend=" rid-list
rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ] rid-param-other = 1*(alpha-numeric / "-") [ "=" param-val ]
rid-list = rid-id *( "," rid-id ) rid-list = rid-id *( "," rid-id )
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 )
skipping to change at page 22, line 49 skipping to change at page 22, line 49
choice of Format Parameter (fmtp) names, and on their relation to RID choice of Format Parameter (fmtp) names, and on their relation to RID
restrictions. restrictions.
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 properties of RTP stream with The "rid" attribute is used to identify properties of RTP stream with
in a RTP Session. Its format is defined in Section 10. in an RTP Session. Its format is defined in Section 10.
The formal registration information for this attribute follows. The formal registration information for this attribute follows.
Contact name, email address, and telephone number Contact name, email address, and telephone number
IETF MMUSIC Working Group IETF MMUSIC Working Group
mmusic@ietf.org mmusic@ietf.org
+1 510 492 4080 +1 510 492 4080
Attribute name (as it will appear in SDP) Attribute name (as it will appear in SDP)
skipping to change at page 23, line 30 skipping to change at page 23, line 30
Media Level Media Level
Whether the attribute value is subject to the charset attribute Whether the attribute value is subject to the charset attribute
The attribute is not dependent on charset. The attribute is not dependent on charset.
A one-paragraph explanation of the purpose of the attribute A one-paragraph explanation of the purpose of the attribute
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 an 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 Multiplexing (Mux) Category
SPECIAL SPECIAL
skipping to change at page 24, line 9 skipping to change at page 24, line 9
specified in [RFC4566]. specified in [RFC4566].
Parameters for "a=rid" lines that modify the nature of encoded media Parameters for "a=rid" lines that modify the nature of encoded media
MUST be of the form that the result of applying the modification to MUST be of the form that the result of applying the modification to
the stream results in a stream that still complies with the other the stream results in a stream that still complies with the other
parameters that affect the media. In other words, restrictions parameters that affect the media. In other words, restrictions
always have to restrict the definition to be a subset of what is always have to restrict the definition to be a subset of what is
otherwise allowable, and never expand it. otherwise allowable, and never expand it.
New restriction registrations are accepted according to the New restriction registrations are accepted according to the
"Specification Required" policy of [RFC5226], provided that the "Specification Required" policy of [RFC5226]. The registration MUST
specification includes the following information: contain the RID parameter name and a reference to the corresponding
specification. The specification itself must contain the following
o contact name, email address, and telephone number information (not all of which appears in the registry):
o restriction name (as it will appear in SDP) o restriction name (as it will appear in SDP)
o long-form restriction name in English
o whether the restriction value is subject to the charset attribute
o an explanation of the purpose of the restriction o an explanation of the purpose of the restriction
o a specification of appropriate attribute values for this o a specification of appropriate attribute values for this
restriction restriction
o an ABNF definition of the restriction o an ABNF definition of the restriction
The initial set of "a=rid" restriction names, with definitions in The initial set of "a=rid" restriction names, with definitions in
Section 5 of this document, is given below: Section 5 of this document, is given below:
skipping to change at page 26, line 18 skipping to change at page 26, line 10
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
<https://www.rfc-editor.org/info/rfc4855>. <https://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, <https://www.rfc-editor.org/info/ RFC5234, January 2008, <https://www.rfc-editor.org/info/
rfc5234>. rfc5234>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC
7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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-48 (work in progress), January 2018. negotiation-51 (work in progress), May 2018.
[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-11 (work in progress), December 2017. mmusic-sdp-simulcast-12 (work in progress), April 2018.
[I-D.ietf-payload-flexible-fec-scheme] [I-D.ietf-payload-flexible-fec-scheme]
Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP Zanaty, M., Singh, V., Begen, A., and G. Mandyam, "RTP
Payload Format for Flexible Forward Error Correction Payload Format for Flexible Forward Error Correction
(FEC)", draft-ietf-payload-flexible-fec-scheme-05 (work in (FEC)", draft-ietf-payload-flexible-fec-scheme-07 (work in
progress), July 2017. progress), March 2018.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
DOI 10.17487/RFC2198, September 1997, <https://www.rfc- DOI 10.17487/RFC2198, September 1997, <https://www.rfc-
editor.org/info/rfc2198>. editor.org/info/rfc2198>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
DOI 10.17487/RFC4588, July 2006, <https://www.rfc- DOI 10.17487/RFC4588, July 2006, <https://www.rfc-
 End of changes. 45 change blocks. 
86 lines changed or deleted 94 lines changed or added

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