draft-ietf-mmusic-rid-12.txt   draft-ietf-mmusic-rid-13.txt 
Network Working Group A. Roach (Editor) Network Working Group A. Roach (Editor)
Internet-Draft Mozilla Internet-Draft Mozilla
Updates: 4855 (if approved) November 13, 2017 Updates: 4855 (if approved) January 17, 2018
Intended status: Standards Track Intended status: Standards Track
Expires: May 17, 2018 Expires: July 21, 2018
RTP Payload Format Restrictions RTP Payload Format Restrictions
draft-ietf-mmusic-rid-12 draft-ietf-mmusic-rid-13
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 40 skipping to change at page 1, line 40
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 May 17, 2018. This Internet-Draft will expire on July 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
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 . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 12
7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 12 7. Use with Declarative SDP . . . . . . . . . . . . . . . . . . 13
8. Interaction with Other Techniques . . . . . . . . . . . . . . 12 8. Interaction with Other Techniques . . . . . . . . . . . . . . 13
8.1. Interaction with VP8 Format Parameters . . . . . . . . . 13 8.1. Interaction with VP8 Format Parameters . . . . . . . . . 14
8.1.1. max-fr - Maximum Framerate . . . . . . . . . . . . . 13 8.1.1. max-fr - Maximum Framerate . . . . . . . . . . . . . 14
8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks . . . 13 8.1.2. max-fs - Maximum Framesize, in VP8 Macroblocks . . . 14
8.2. Interaction with H.264 Format Parameters . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . 15 Profile . . . . . . . . . . . . . . . . . . . . . . . 16
8.2.2. max-br / MaxBR - Maximum Video Bitrate . . . . . . . 15 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
Macroblocks . . . . . . . . . . . . . . . . . . . . . 16 Macroblocks . . . . . . . . . . . . . . . . . . . . . 16
8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing 8.2.4. max-mbps / MaxMBPS - Maximum Macroblock Processing
Rate . . . . . . . . . . . . . . . . . . . . . . . . 16 Rate . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2.5. max-smbps - Maximum Decoded Picture Buffer . . . . . 16 8.2.5. max-smbps - Maximum Decoded Picture Buffer . . . . . 17
9. Format Parameters for Future Payloads . . . . . . . . . . . . 16 8.3. Redundancy Formats and Payload Type Restrictions . . . . 17
10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 17 9. Format Parameters for Future Payloads . . . . . . . . . . . . 18
11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Formal Grammar . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 18 11. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . 20
11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 20 11.1. Many Bundled Streams using Many Codecs . . . . . . . . . 20
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11.2. Scalable Layers . . . . . . . . . . . . . . . . . . . . 22
12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 21 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12.2. Registry for RID-Level Parameters . . . . . . . . . . . 22 12.1. New SDP Media-Level attribute . . . . . . . . . . . . . 22
13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 12.2. Registry for RID-Level Parameters . . . . . . . . . . . 23
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
15.1. Normative References . . . . . . . . . . . . . . . . . . 24 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
15.2. Informative References . . . . . . . . . . . . . . . . . 24 15.1. Normative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 26 15.2. Informative References . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 27
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
Stream" are used as defined in [RFC7656]. Stream" are used as defined in [RFC7656].
[RFC4566] and [RFC3264] terminology is also used where appropriate. [RFC4566] and [RFC3264] terminology is also used where appropriate.
2. Introduction 2. Introduction
skipping to change at page 4, line 37 skipping to change at page 4, line 37
requested by this mechanism. requested by this mechanism.
Further, as described in Section 6 and its subsections, this Further, as described in Section 6 and its subsections, this
mechanism achieves extensibility by: (a) having offerers include all mechanism achieves extensibility by: (a) having offerers include all
supported restrictions in their offer, and (b) having answerers supported restrictions in their offer, and (b) having answerers
ignore "a=rid" lines that specify unknown restrictions. ignore "a=rid" lines that specify unknown restrictions.
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119] "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
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", ("restriction identifier") used to communicate a set of
restrictions to be applied to 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>...
skipping to change at page 5, line 15 skipping to change at page 5, line 17
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 SDP media implementations MUST send it for all streams in an SDP media
description ("m=") that have "a=rid" lines remaining after applying description ("m=") that have "a=rid" lines remaining after applying
the rules in Section 6 and its subsections. 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] [I-D.ietf-payload-flexible-fec-scheme], for any of the FEC [RFC5109], for any of the source RTP streams that have "a=rid"
source RTP streams that have "a=rid" lines remaining after applying lines remaining after applying the rules in Section 6 and its
the rules in Section 6 and its subsections, MUST support and use subsections, MUST support the RepairedRtpStreamId SDES item described
RepairedRtpStreamId SDES item described in [I-D.ietf-avtext-rid] for in [I-D.ietf-avtext-rid] for those redundancy RTP streams.
those redundancy RTP streams. This provides the binding between the RepairedRtpStreamId MUST be used for redundancy RTP streams to which
source RTP stream and the corresponding redundancy RTP stream, by it can be applied. Use of RepairedRtpStreamId is not applicable for
setting RepairedRtpStreamId value for the redundancy RTP stream to redundancy formats that directly associate RTP streams through shared
the RtpStreamId value of the source RTP stream. The redundancy RTP SSRCs (for example [I-D.ietf-payload-flexible-fec-scheme]) or other
cases that RepairedRtpStreamId cannot support, such as referencing
multiple source streams.
RepairedRtpStreamId is used to provide the binding between the
redundancy RTP stream and its source RTP stream, by setting the
RepairedRtpStreamId value for the redundancy RTP stream to the
RtpStreamId value of the source RTP stream. The redundancy RTP
stream MAY (but need not) have an "a=rid" line of its own, in which stream MAY (but need not) have an "a=rid" line of its own, in which
case the RtpStreamId SDES item value will be different from the case the RtpStreamId SDES item value will be different from the
corresponding source RTP stream. corresponding source RTP stream.
It is important to note that this indirection may result in the
temporary inability to correctly associate source and redundancy data
when the SSRC associated with the RtpStreamId or RepairedRtpStreamId
is dynamically changed during the RTP session. This can be avoided
if all RTP packets, source and repair, after the change include their
RtpStreamId or RepairedRtpStreamId, respectively. To maximize the
probability of reception and utility of redundancy information after
such a change, all the source packets referenced by the first several
repair packets SHOULD include such information. It is RECOMMENDED
that the number of such packets is large enough to give a high
probability of actual updated association. Section 4.1.1 of
[RFC8285] provides relevant guidance for RTP header extension
transmission considerations. Alternatively, to avoid this issue,
redundancy mechanisms that directly reference its source data may be
used, such as [I-D.ietf-payload-flexible-fec-scheme].
The "direction" field identifies the direction of the RTP Stream The "direction" field identifies the direction of the RTP Stream
packets to which the indicated restrictions are applied. It may be packets to which the indicated restrictions are applied. It may be
either "send" or "recv". Note that these restriction directions are either "send" or "recv". Note that these restriction directions are
expressed independently of any "inactive", "sendonly", "recvonly", or expressed independently of any "inactive", "sendonly", "recvonly", or
"sendrecv" attributes associated with the media section. It is, for "sendrecv" attributes associated with the media section. It is, for
example, valid to indicate "recv" restrictions on a "sendonly" example, valid to indicate "recv" restrictions on a "sendonly"
stream; those restrictions would apply if, at a future point in time, stream; those restrictions would apply if, at a future point in time,
the stream were changed to "sendrecv" or "recvonly". 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
skipping to change at page 16, line 41 skipping to change at page 17, line 20
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
result of this conversion is applied as described in Section 8.2.4. result of this conversion is applied as described in Section 8.2.4.
8.3. Redundancy Formats and Payload Type Restrictions
Section 4 specifies that redundancy formats using redundancy RTP
streams bind the redundancy RTP stream to the source RTP stream with
either the RepairedRtpStreamId SDES item, or other mechanisms.
However, there exist redundancy RTP payload formats that result in
the redundancy being included in the source RTP stream. An example
of this is "RTP Payload for Redundant Audio Data" [RFC2198], which
encapsulates one source stream with one or more redundancy streams in
the same RTP payload. Formats defining the source and redundancy
encodings as regular RTP payload types require some consideration for
how the "a=rid" restrictions are defined. The "a=rid" line "pt="
parameter can be used to indicate whether the redundancy RTP payload
type and/or the individual source RTP payload type(s) are part of the
restriction.
Example (SDP Excerpt):
m=audio 49200 RTP/AVP 97 98 99 100 101 102
a=mid:foo
a=rtpmap:97 G711/8000
a=rtpmap:98 LPC/8000
a=rtpmap:99 OPUS/48000/1
a=rtpmap:100 RED/8000/1
a=rtpmap:101 CN/8000
a=rtpmap:102 telephone-event/8000
a=fmtp:99 useinbandfec=1; usedtx=0
a=fmtp:100 97/98
a=fmtp:102 0-15
a=ptime:20
a=maxptime:40
a=rid:5 send pt=99,102;max-br=64000
a=rid:6 send pt=100,97,101,102
The RID with ID=6 restricts the payload types for this RID to 100
(the redundancy format), 97 (G.711), 101 (Comfort Noise) and 102
(DTMF tones). This means that RID 6 can either contain the RED
format, encapsulating encodings of the source media stream using
payload type 97 and 98, 97 without RED encapsulation, Comfort noise,
or DTMF tones. Payload type 98 is not included in the RID, and can
thus not be sent except as redundancy information in RED
encapsulation. If 97 were to be excluded from the pt parameter, it
would instead mean that payload types 97 and 98 are only allowed via
RED encapsulation.
9. Format Parameters for Future Payloads 9. Format Parameters for Future Payloads
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
skipping to change at page 24, line 39 skipping to change at page 26, line 18
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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-39 (work in progress), August 2017. negotiation-47 (work in progress), December 2017.
[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-10 (work in progress), July 2017. mmusic-sdp-simulcast-11 (work in progress), December 2017.
[I-D.ietf-payload-flexible-fec-scheme] [I-D.ietf-payload-flexible-fec-scheme]
Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP Singh, V., Begen, A., Zanaty, M., 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-05 (work in
progress), July 2017. progress), July 2017.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
DOI 10.17487/RFC2198, September 1997, <https://www.rfc-
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-
editor.org/info/rfc4588>. editor.org/info/rfc4588>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, DOI 10.17487/RFC5109, December Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <https://www.rfc-editor.org/info/rfc5109>. 2007, <https://www.rfc-editor.org/info/rfc5109>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
skipping to change at page 26, line 5 skipping to change at page 27, line 40
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, <https://www.rfc- DOI 10.17487/RFC7656, November 2015, <https://www.rfc-
editor.org/info/rfc7656>. editor.org/info/rfc7656>.
[RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F. [RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
Galligan, "RTP Payload Format for VP8 Video", RFC 7741, Galligan, "RTP Payload Format for VP8 Video", RFC 7741,
DOI 10.17487/RFC7741, March 2016, <https://www.rfc- DOI 10.17487/RFC7741, March 2016, <https://www.rfc-
editor.org/info/rfc7741>. editor.org/info/rfc7741>.
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
Mechanism for RTP Header Extensions", RFC 8285, DOI
10.17487/RFC8285, October 2017, <https://www.rfc-
editor.org/info/rfc8285>.
Appendix A. Contributors Appendix A. Contributors
The following individuals have contributed significant text to this The following individuals have contributed significant text to this
document. document.
Peter Thatcher Peter Thatcher
Google Google
Email: pthatcher@google.com Email: pthatcher@google.com
Mo Zanaty Mo Zanaty
 End of changes. 18 change blocks. 
42 lines changed or deleted 128 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/