rfc8834v3.txt   rfc8834.txt 
Internet Engineering Task Force (IETF) C. Perkins Internet Engineering Task Force (IETF) C. Perkins
Request for Comments: 8834 University of Glasgow Request for Comments: 8834 University of Glasgow
Category: Standards Track M. Westerlund Category: Standards Track M. Westerlund
ISSN: 2070-1721 Ericsson ISSN: 2070-1721 Ericsson
J. Ott J. Ott
Aalto University Aalto University
June 2020 December 2020
Media Transport and Use of RTP in WebRTC Media Transport and Use of RTP in WebRTC
Abstract Abstract
The framework for Web Real-Time Communication (WebRTC) provides The framework for Web Real-Time Communication (WebRTC) provides
support for direct interactive rich communication using audio, video, support for direct interactive rich communication using audio, video,
text, collaboration, games, etc. between two peers' web browsers. text, collaboration, games, etc. between two peers' web browsers.
This memo describes the media transport aspects of the WebRTC This memo describes the media transport aspects of the WebRTC
framework. It specifies how the Real-time Transport Protocol (RTP) framework. It specifies how the Real-time Transport Protocol (RTP)
skipping to change at line 460 skipping to change at line 460
of media type, in a single RTP session using a single transport-layer of media type, in a single RTP session using a single transport-layer
flow, according to [RFC8860] (this is sometimes called SSRC flow, according to [RFC8860] (this is sometimes called SSRC
multiplexing). If multiple types of media are to be used in a single multiplexing). If multiple types of media are to be used in a single
RTP session, all participants in that RTP session MUST agree to this RTP session, all participants in that RTP session MUST agree to this
usage. In an SDP context, the mechanisms described in [RFC8843] can usage. In an SDP context, the mechanisms described in [RFC8843] can
be used to signal such a bundle of RTP packet streams forming a be used to signal such a bundle of RTP packet streams forming a
single RTP session. single RTP session.
Further discussion about the suitability of different RTP session Further discussion about the suitability of different RTP session
structures and multiplexing methods to different scenarios can be structures and multiplexing methods to different scenarios can be
found in [MULTIPLEX]. found in [RFC8872].
4.5. RTP and RTCP Multiplexing 4.5. RTP and RTCP Multiplexing
Historically, RTP and RTCP have been run on separate transport-layer Historically, RTP and RTCP have been run on separate transport-layer
flows (e.g., two UDP ports for each RTP session, one for RTP and one flows (e.g., two UDP ports for each RTP session, one for RTP and one
for RTCP). With the increased use of Network Address/Port for RTCP). With the increased use of Network Address/Port
Translation (NAT/NAPT), this has become problematic, since Translation (NAT/NAPT), this has become problematic, since
maintaining multiple NAT bindings can be costly. It also complicates maintaining multiple NAT bindings can be costly. It also complicates
firewall administration, since multiple ports need to be opened to firewall administration, since multiple ports need to be opened to
allow RTP traffic. To reduce these costs and session setup times, allow RTP traffic. To reduce these costs and session setup times,
skipping to change at line 679 skipping to change at line 679
streams and distributes them to the other participants. These streams and distributes them to the other participants. These
extensions are not necessary for interoperability; an RTP endpoint extensions are not necessary for interoperability; an RTP endpoint
that does not implement these extensions will work correctly but that does not implement these extensions will work correctly but
might offer poor performance. Support for the listed extensions will might offer poor performance. Support for the listed extensions will
greatly improve the quality of experience; to provide a reasonable greatly improve the quality of experience; to provide a reasonable
baseline quality, some of these extensions are mandatory to be baseline quality, some of these extensions are mandatory to be
supported by WebRTC endpoints. supported by WebRTC endpoints.
The RTCP conferencing extensions are defined in "Extended RTP Profile The RTCP conferencing extensions are defined in "Extended RTP Profile
for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/
AVPF)" [RFC4585] and the memo on "Codec Control Messages in the RTP AVPF)" [RFC4585] and "Codec Control Messages in the RTP Audio-Visual
Audio-Visual Profile with Feedback (AVPF)" [RFC5104]; they are fully Profile with Feedback (AVPF)" [RFC5104]; they are fully usable by the
usable by the secure variant of this profile (RTP/SAVPF) [RFC5124]. secure variant of this profile (RTP/SAVPF) [RFC5124].
5.1.1. Full Intra Request (FIR) 5.1.1. Full Intra Request (FIR)
The Full Intra Request message is defined in Sections 3.5.1 and 4.3.1 The Full Intra Request message is defined in Sections 3.5.1 and 4.3.1
of Codec Control Messages [RFC5104]. It is used to make the mixer of Codec Control Messages [RFC5104]. It is used to make the mixer
request a new Intra picture from a participant in the session. This request a new Intra picture from a participant in the session. This
is used when switching between sources to ensure that the receivers is used when switching between sources to ensure that the receivers
can decode the video or other predictive media encoding with long can decode the video or other predictive media encoding with long
prediction chains. WebRTC endpoints that are sending media MUST prediction chains. WebRTC endpoints that are sending media MUST
understand and react to FIR feedback messages they receive, since understand and react to FIR feedback messages they receive, since
skipping to change at line 1064 skipping to change at line 1064
signaled; implementations MUST ignore RTCP XR packets that are signaled; implementations MUST ignore RTCP XR packets that are
unexpected or not understood. unexpected or not understood.
9. WebRTC Use of RTP: Future Extensions 9. WebRTC Use of RTP: Future Extensions
It is possible that the core set of RTP protocols and RTP extensions It is possible that the core set of RTP protocols and RTP extensions
specified in this memo will prove insufficient for the future needs specified in this memo will prove insufficient for the future needs
of WebRTC. In this case, future updates to this memo have to be made of WebRTC. In this case, future updates to this memo have to be made
following "Guidelines for Writers of RTP Payload Format following "Guidelines for Writers of RTP Payload Format
Specifications" [RFC2736], "How to Write an RTP Payload Format" Specifications" [RFC2736], "How to Write an RTP Payload Format"
[RFC8088], and "Guidelines for Extending the RTP Control Protocol" [RFC8088], and "Guidelines for Extending the RTP Control Protocol
[RFC5968]. They also SHOULD take into account any future guidelines (RTCP)" [RFC5968]. They also SHOULD take into account any future
for extending RTP and related protocols that have been developed. guidelines for extending RTP and related protocols that have been
developed.
Authors of future extensions are urged to consider the wide range of Authors of future extensions are urged to consider the wide range of
environments in which RTP is used when recommending extensions, since environments in which RTP is used when recommending extensions, since
extensions that are applicable in some scenarios can be problematic extensions that are applicable in some scenarios can be problematic
in others. Where possible, the WebRTC framework will adopt RTP in others. Where possible, the WebRTC framework will adopt RTP
extensions that are of general utility, to enable easy implementation extensions that are of general utility, to enable easy implementation
of a gateway to other applications using RTP, rather than adopt of a gateway to other applications using RTP, rather than adopt
mechanisms that are narrowly targeted at specific WebRTC use cases. mechanisms that are narrowly targeted at specific WebRTC use cases.
10. Signaling Considerations 10. Signaling Considerations
skipping to change at line 1237 skipping to change at line 1238
MediaStreamTracks that are received with different CNAMEs have no MediaStreamTracks that are received with different CNAMEs have no
defined synchronization. defined synchronization.
| Note: The motivation for supporting reception of multiple | Note: The motivation for supporting reception of multiple
| CNAMEs is to allow for forward compatibility with any future | CNAMEs is to allow for forward compatibility with any future
| changes that enable more efficient stream handling when | changes that enable more efficient stream handling when
| endpoints relay/forward streams. It also ensures that | endpoints relay/forward streams. It also ensures that
| endpoints can interoperate with certain types of multistream | endpoints can interoperate with certain types of multistream
| middleboxes or endpoints that are not WebRTC. | middleboxes or endpoints that are not WebRTC.
The "JavaScript Session Establishment Protocol" [RFC8829] specifies "JavaScript Session Establishment Protocol (JSEP)" [RFC8829]
that the binding between the WebRTC MediaStreams, MediaStreamTracks, specifies that the binding between the WebRTC MediaStreams,
and the SSRC is done as specified in the "WebRTC MediaStream MediaStreamTracks, and the SSRC is done as specified in "WebRTC
Identification in the Session Description Protocol" [MSID]. MediaStream Identification in the Session Description Protocol"
Section 4.1 of the MediaStream Identification (MSID) document [MSID] [RFC8830]. Section 4.1 of the MediaStream Identification (MSID)
also defines how to map source packet streams with unknown SSRCs to document [RFC8830] also defines how to map source packet streams with
MediaStreamTracks and MediaStreams. This later is relevant to handle unknown SSRCs to MediaStreamTracks and MediaStreams. This later is
some cases of legacy interoperability. Commonly, the RTP payload relevant to handle some cases of legacy interoperability. Commonly,
type of any incoming packets will reveal if the packet stream is a the RTP payload type of any incoming packets will reveal if the
source stream or a redundancy or dependent packet stream. The packet stream is a source stream or a redundancy or dependent packet
association to the correct source packet stream depends on the stream. The association to the correct source packet stream depends
payload format in use for the packet stream. on the payload format in use for the packet stream.
Finally, this specification puts a requirement on the WebRTC API to Finally, this specification puts a requirement on the WebRTC API to
realize a method for determining the CSRC list (Section 4.1) as well realize a method for determining the CSRC list (Section 4.1) as well
as the mixer-to-client audio levels (Section 5.2.3) (when supported); as the mixer-to-client audio levels (Section 5.2.3) (when supported);
the basic requirements for this is further discussed in the basic requirements for this is further discussed in
Section 12.2.1. Section 12.2.1.
12. RTP Implementation Considerations 12. RTP Implementation Considerations
The following discussion provides some guidance on the implementation The following discussion provides some guidance on the implementation
skipping to change at line 1418 skipping to change at line 1419
| C | | C |
+---+ +---+
Figure 1: Multi-unicast Using Several RTP Sessions Figure 1: Multi-unicast Using Several RTP Sessions
The multi-unicast topology could also be implemented as a single The multi-unicast topology could also be implemented as a single
RTP session, spanning multiple peer-to-peer transport-layer RTP session, spanning multiple peer-to-peer transport-layer
connections, or as several pairwise RTP sessions, one between each connections, or as several pairwise RTP sessions, one between each
pair of peers. To maintain a coherent mapping of the relationship pair of peers. To maintain a coherent mapping of the relationship
between RTP sessions and RTCPeerConnection objects, it is between RTP sessions and RTCPeerConnection objects, it is
recommended that this be implemented as several individual RTP RECOMMENDED that this be implemented as several individual RTP
sessions. The only downside is that endpoint A will not learn of sessions. The only downside is that endpoint A will not learn of
the quality of any transmission happening between B and C, since the quality of any transmission happening between B and C, since
it will not see RTCP reports for the RTP session between B and C, it will not see RTCP reports for the RTP session between B and C,
whereas it would if all three participants were part of a single whereas it would if all three participants were part of a single
RTP session. Experience with the Mbone tools (experimental RTP- RTP session. Experience with the Mbone tools (experimental RTP-
based multicast conferencing tools from the late 1990s) has shown based multicast conferencing tools from the late 1990s) has shown
that RTCP reception quality reports for third parties can be that RTCP reception quality reports for third parties can be
presented to users in a way that helps them understand asymmetric presented to users in a way that helps them understand asymmetric
network problems, and the approach of using separate RTP sessions network problems, and the approach of using separate RTP sessions
prevents this. However, an advantage of using separate RTP prevents this. However, an advantage of using separate RTP
skipping to change at line 1612 skipping to change at line 1613
this is specified. this is specified.
DiffServ assumes that either the endpoint or a classifier can mark DiffServ assumes that either the endpoint or a classifier can mark
the packets with an appropriate Differentiated Services Code Point the packets with an appropriate Differentiated Services Code Point
(DSCP) so that the packets are treated according to that marking. If (DSCP) so that the packets are treated according to that marking. If
the endpoint is to mark the traffic, two requirements arise in the the endpoint is to mark the traffic, two requirements arise in the
WebRTC context: 1) The WebRTC endpoint has to know which DSCPs to use WebRTC context: 1) The WebRTC endpoint has to know which DSCPs to use
and know that it can use them on some set of RTP packet streams. 2) and know that it can use them on some set of RTP packet streams. 2)
The information needs to be propagated to the operating system when The information needs to be propagated to the operating system when
transmitting the packet. Details of this process are outside the transmitting the packet. Details of this process are outside the
scope of this memo and are further discussed in "DSCP Packet Markings scope of this memo and are further discussed in "Differentiated
for WebRTC QoS" [RFC8837]. Services Code Point (DSCP) Packet Markings for WebRTC QoS" [RFC8837].
Despite the SRTP media encryption, deep packet inspectors will still Despite the SRTP media encryption, deep packet inspectors will still
be fairly capable of classifying the RTP streams. The reason is that be fairly capable of classifying the RTP streams. The reason is that
SRTP leaves the first 12 bytes of the RTP header unencrypted. This SRTP leaves the first 12 bytes of the RTP header unencrypted. This
enables easy RTP stream identification using the SSRC and provides enables easy RTP stream identification using the SSRC and provides
the classifier with useful information that can be correlated to the classifier with useful information that can be correlated to
determine, for example, the stream's media type. Using packet sizes, determine, for example, the stream's media type. Using packet sizes,
reception times, packet inter-spacing, RTP timestamp increments, and reception times, packet inter-spacing, RTP timestamp increments, and
sequence numbers, fairly reliable classifications are achieved. sequence numbers, fairly reliable classifications are achieved.
skipping to change at line 1773 skipping to change at line 1774
[RFC8827], and security considerations for the WebRTC framework are [RFC8827], and security considerations for the WebRTC framework are
described in [RFC8826]. These considerations also apply to this described in [RFC8826]. These considerations also apply to this
memo. memo.
The security considerations of the RTP specification, the RTP/SAVPF The security considerations of the RTP specification, the RTP/SAVPF
profile, and the various RTP/RTCP extensions and RTP payload formats profile, and the various RTP/RTCP extensions and RTP payload formats
that form the complete protocol suite described in this memo apply. that form the complete protocol suite described in this memo apply.
It is believed that there are no new security considerations It is believed that there are no new security considerations
resulting from the combination of these various protocol extensions. resulting from the combination of these various protocol extensions.
The "Extended Secure RTP Profile for Real-time Transport Control "Extended Secure RTP Profile for Real-time Transport Control Protocol
Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] provides (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] provides handling of
handling of fundamental issues by offering confidentiality, fundamental issues by offering confidentiality, integrity, and
integrity, and partial source authentication. A media-security partial source authentication. A media-security solution that is
solution that is mandatory to implement and use is created by mandatory to implement and use is created by combining this secured
combining this secured RTP profile and DTLS-SRTP keying [RFC5764], as RTP profile and DTLS-SRTP keying [RFC5764], as defined by Section 5.5
defined by Section 5.5 of [RFC8827]. of [RFC8827].
RTCP packets convey a Canonical Name (CNAME) identifier that is used RTCP packets convey a Canonical Name (CNAME) identifier that is used
to associate RTP packet streams that need to be synchronized across to associate RTP packet streams that need to be synchronized across
related RTP sessions. Inappropriate choice of CNAME values can be a related RTP sessions. Inappropriate choice of CNAME values can be a
privacy concern, since long-term persistent CNAME identifiers can be privacy concern, since long-term persistent CNAME identifiers can be
used to track users across multiple WebRTC calls. Section 4.9 of used to track users across multiple WebRTC calls. Section 4.9 of
this memo mandates generation of short-term persistent RTCP CNAMES, this memo mandates generation of short-term persistent RTCP CNAMES,
as specified in RFC 7022, resulting in untraceable CNAME values that as specified in RFC 7022, resulting in untraceable CNAME values that
alleviate this risk. alleviate this risk.
skipping to change at line 2010 skipping to change at line 2011
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>.
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
Mechanism for RTP Header Extensions", RFC 8285, Mechanism for RTP Header Extensions", RFC 8285,
DOI 10.17487/RFC8285, October 2017, DOI 10.17487/RFC8285, October 2017,
<https://www.rfc-editor.org/info/rfc8285>. <https://www.rfc-editor.org/info/rfc8285>.
[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for
Browser-Based Applications", RFC 8825, Browser-Based Applications", RFC 8825,
DOI 10.17487/RFC8825, June 2020, DOI 10.17487/RFC8825, December 2020,
<https://www.rfc-editor.org/info/rfc8825>. <https://www.rfc-editor.org/info/rfc8825>.
[RFC8826] Rescorla, E., "Security Considerations for WebRTC", [RFC8826] Rescorla, E., "Security Considerations for WebRTC",
RFC 8826, DOI 10.17487/RFC8826, June 2020, RFC 8826, DOI 10.17487/RFC8826, December 2020,
<https://www.rfc-editor.org/info/rfc8826>. <https://www.rfc-editor.org/info/rfc8826>.
[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, [RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,
DOI 10.17487/RFC8827, June 2020, DOI 10.17487/RFC8827, December 2020,
<https://www.rfc-editor.org/info/rfc8827>. <https://www.rfc-editor.org/info/rfc8827>.
[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, [RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", RFC 8843, Description Protocol (SDP)", RFC 8843,
DOI 10.17487/RFC8843, June 2020, DOI 10.17487/RFC8843, December 2020,
<https://www.rfc-editor.org/info/rfc8843>. <https://www.rfc-editor.org/info/rfc8843>.
[RFC8854] Uberti, J., "WebRTC Forward Error Correction [RFC8854] Uberti, J., "WebRTC Forward Error Correction
Requirements", RFC 8854, DOI 10.17487/RFC8854, June 2020, Requirements", RFC 8854, DOI 10.17487/RFC8854, December
<https://www.rfc-editor.org/info/rfc8854>. 2020, <https://www.rfc-editor.org/info/rfc8854>.
[RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP [RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP
Control Protocol (RTCP) Multiplexing Using the Session Control Protocol (RTCP) Multiplexing Using the Session
Description Protocol (SDP)", RFC 8858, Description Protocol (SDP)", RFC 8858,
DOI 10.17487/RFC8858, June 2020, DOI 10.17487/RFC8858, December 2020,
<https://www.rfc-editor.org/info/rfc8858>. <https://www.rfc-editor.org/info/rfc8858>.
[RFC8860] Westerlund, M., Perkins, C., and J. Lennox, "Sending [RFC8860] Westerlund, M., Perkins, C., and J. Lennox, "Sending
Multiple Types of Media in a Single RTP Session", Multiple Types of Media in a Single RTP Session",
RFC 8860, DOI 10.17487/RFC8860, June 2020, RFC 8860, DOI 10.17487/RFC8860, December 2020,
<https://www.rfc-editor.org/info/rfc8860>. <https://www.rfc-editor.org/info/rfc8860>.
[RFC8861] Lennox, J., Westerlund, M., W, Q., and C. Perkins, [RFC8861] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple RTP Streams in a Single RTP Session: "Sending Multiple RTP Streams in a Single RTP Session:
Grouping RTP Control Protocol (RTCP) Reception Statistics Grouping RTP Control Protocol (RTCP) Reception Statistics
and Other Feedback", RFC 8861, DOI 10.17487/RFC8861, June and Other Feedback", RFC 8861, DOI 10.17487/RFC8861,
2020, <https://www.rfc-editor.org/info/rfc8861>. December 2020, <https://www.rfc-editor.org/info/rfc8861>.
[W3C-MEDIA-CAPTURE] [W3C-MEDIA-CAPTURE]
Burnett, D., Bergkvist, A., Jennings, C., Narayanan, A., Burnett, D., Bergkvist, A., Jennings, C., Narayanan, A.,
Aboba, B., Bruaroey, J., and H. Boström, "Media Capture Aboba, B., Bruaroey, J-I., and H. Boström, "Media Capture
and Streams", W3C Candidate Recommendation, 2 July 2019, and Streams", W3C Candidate Recommendation, 2 July 2019,
<https://www.w3.org/TR/2019/CR-mediacapture-streams- <https://www.w3.org/TR/2019/CR-mediacapture-streams-
20190702/>. 20190702/>.
[W3C.WebRTC] [W3C.WebRTC]
Bergkvist, A., Burnett, D., Jennings, C., Narayanan, A., Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0:
Aboba, B., Brandstetter, T., and J. Bruaroey, "WebRTC 1.0:
Real-time Communication Between Browsers", W3C Candidate Real-time Communication Between Browsers", W3C Candidate
Recommendation, 27 September 2018, Recommendation, <https://www.w3.org/TR/webrtc/>.
<https://www.w3.org/TR/2018/CR-webrtc-20180927/>.
15.2. Informative References 15.2. Informative References
[MSID] Alvestrand, H., "WebRTC MediaStream Identification in the
Session Description Protocol", Work in Progress, draft-
ietf-mmusic-msid-17, 13 December 2018.
[MULTIPLEX]
Westerlund, M., Burman, B., Perkins, C., Alvestrand, H.,
and R. Even, "Guidelines for using the Multiplexing
Features of RTP to Support Multiple Media Streams", Work
in Progress, draft-ietf-avtcore-multiplex-guidelines-09,
22 July 2019.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<https://www.rfc-editor.org/info/rfc3611>. <https://www.rfc-editor.org/info/rfc3611>.
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient
Stream Loss-Tolerant Authentication (TESLA) in the Secure Stream Loss-Tolerant Authentication (TESLA) in the Secure
Real-time Transport Protocol (SRTP)", RFC 4383, Real-time Transport Protocol (SRTP)", RFC 4383,
DOI 10.17487/RFC4383, February 2006, DOI 10.17487/RFC4383, February 2006,
<https://www.rfc-editor.org/info/rfc4383>. <https://www.rfc-editor.org/info/rfc4383>.
skipping to change at line 2138 skipping to change at line 2126
<https://www.rfc-editor.org/info/rfc8088>. <https://www.rfc-editor.org/info/rfc8088>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445, Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018, DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>. <https://www.rfc-editor.org/info/rfc8445>.
[RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed.,
"JavaScript Session Establishment Protocol (JSEP)", "JavaScript Session Establishment Protocol (JSEP)",
RFC 8829, DOI 10.17487/RFC8829, June 2020, RFC 8829, DOI 10.17487/RFC8829, December 2020,
<https://www.rfc-editor.org/info/rfc8829>. <https://www.rfc-editor.org/info/rfc8829>.
[RFC8830] Alvestrand, H., "WebRTC MediaStream Identification in the
Session Description Protocol", RFC 8830,
DOI 10.17487/RFC8830, December 2020,
<https://www.rfc-editor.org/info/rfc8830>.
[RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control [RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control
Requirements for Interactive Real-Time Media", RFC 8836, Requirements for Interactive Real-Time Media", RFC 8836,
DOI 10.17487/RFC8836, June 2020, DOI 10.17487/RFC8836, December 2020,
<https://www.rfc-editor.org/info/rfc8836>. <https://www.rfc-editor.org/info/rfc8836>.
[RFC8837] Jones, P., Dhesikan, S., Jennings, C., and D. Druta, [RFC8837] Jones, P., Dhesikan, S., Jennings, C., and D. Druta,
"Differentiated Services Code Point (DSCP) Packet Markings "Differentiated Services Code Point (DSCP) Packet Markings
for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, June for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, December
2020, <https://www.rfc-editor.org/info/rfc8837>. 2020, <https://www.rfc-editor.org/info/rfc8837>.
[RFC8872] Westerlund, M., Burman, B., Perkins, C., Alvestrand, H.,
and R. Even, "Guidelines for Using the Multiplexing
Features of RTP to Support Multiple Media Streams",
RFC 8872, DOI 10.17487/RFC8872, December 2020,
<https://www.rfc-editor.org/info/rfc8872>.
Acknowledgements Acknowledgements
The authors would like to thank Bernard Aboba, Harald Alvestrand, The authors would like to thank Bernard Aboba, Harald Alvestrand,
Cary Bran, Ben Campbell, Alissa Cooper, Spencer Dawkins, Charles Cary Bran, Ben Campbell, Alissa Cooper, Spencer Dawkins, Charles
Eckel, Alex Eleftheriadis, Christian Groves, Chris Inacio, Cullen Eckel, Alex Eleftheriadis, Christian Groves, Chris Inacio, Cullen
Jennings, Olle Johansson, Suhas Nandakumar, Dan Romascanu, Jim Jennings, Olle Johansson, Suhas Nandakumar, Dan Romascanu, Jim
Spring, Martin Thomson, and the other members of the IETF RTCWEB Spring, Martin Thomson, and the other members of the IETF RTCWEB
working group for their valuable feedback. working group for their valuable feedback.
Authors' Addresses Authors' Addresses
skipping to change at line 2174 skipping to change at line 2173
School of Computing Science School of Computing Science
Glasgow Glasgow
G12 8QQ G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
URI: https://csperkins.org/ URI: https://csperkins.org/
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Torshamsgatan 23
SE-164 80 Kista SE-164 80 Kista
Sweden Sweden
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
Jörg Ott Jörg Ott
Aalto University Aalto University
School of Electrical Engineering School of Electrical Engineering
FI-02150 Espoo FI-02150 Espoo
Finland Finland
Email: jorg.ott@aalto.fi Email: jorg.ott@aalto.fi
 End of changes. 28 change blocks. 
62 lines changed or deleted 60 lines changed or added

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