draft-ietf-rtcweb-rtp-usage-25.txt   draft-ietf-rtcweb-rtp-usage-26.txt 
RTCWEB Working Group C. Perkins RTCWEB Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Intended status: Standards Track M. Westerlund Intended status: Standards Track M. Westerlund
Expires: December 14, 2015 Ericsson Expires: September 18, 2016 Ericsson
J. Ott J. Ott
Aalto University Aalto University
June 12, 2015 March 17, 2016
Web Real-Time Communication (WebRTC): Media Transport and Use of RTP Web Real-Time Communication (WebRTC): Media Transport and Use of RTP
draft-ietf-rtcweb-rtp-usage-25 draft-ietf-rtcweb-rtp-usage-26
Abstract Abstract
The Web Real-Time Communication (WebRTC) framework provides support The Web Real-Time Communication (WebRTC) framework provides support
for direct interactive rich communication using audio, video, text, for direct interactive rich communication using audio, video, text,
collaboration, games, etc. between two peers' web-browsers. This collaboration, games, etc. between two peers' web-browsers. This
memo describes the media transport aspects of the WebRTC framework. memo describes the media transport aspects of the WebRTC framework.
It specifies how the Real-time Transport Protocol (RTP) is used in It specifies how the Real-time Transport Protocol (RTP) is used in
the WebRTC context, and gives requirements for which RTP features, the WebRTC context, and gives requirements for which RTP features,
profiles, and extensions need to be supported. profiles, and extensions need to be supported.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 December 14, 2015. This Internet-Draft will expire on September 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 3, line 7
7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 21 7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 21
7.2. Congestion Control Interoperability and Legacy Systems . 22 7.2. Congestion Control Interoperability and Legacy Systems . 22
8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22
9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 23 9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 23
10. Signalling Considerations . . . . . . . . . . . . . . . . . . 23 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 23
11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 25 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 25
12. RTP Implementation Considerations . . . . . . . . . . . . . . 27 12. RTP Implementation Considerations . . . . . . . . . . . . . . 27
12.1. Configuration and Use of RTP Sessions . . . . . . . . . 27 12.1. Configuration and Use of RTP Sessions . . . . . . . . . 27
12.1.1. Use of Multiple Media Sources Within an RTP Session 27 12.1.1. Use of Multiple Media Sources Within an RTP Session 27
12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 28 12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 28
12.1.3. Differentiated Treatment of RTP Packet Streams . . . 33 12.1.3. Differentiated Treatment of RTP Streams . . . . . . 33
12.2. Media Source, RTP Packet Streams, and Participant 12.2. Media Source, RTP Streams, and Participant
Identification . . . . . . . . . . . . . . . . . . . . . 35 Identification . . . . . . . . . . . . . . . . . . . . . 35
12.2.1. Media Source Identification . . . . . . . . . . . . 35 12.2.1. Media Source Identification . . . . . . . . . . . . 35
12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 36 12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 36
12.2.3. Media Synchronisation Context . . . . . . . . . . . 37 12.2.3. Media Synchronisation Context . . . . . . . . . . . 37
13. Security Considerations . . . . . . . . . . . . . . . . . . . 37 13. Security Considerations . . . . . . . . . . . . . . . . . . . 37
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
16.1. Normative References . . . . . . . . . . . . . . . . . . 39 16.1. Normative References . . . . . . . . . . . . . . . . . . 39
16.2. Informative References . . . . . . . . . . . . . . . . . 43 16.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
The Real-time Transport Protocol (RTP) [RFC3550] provides a framework The Real-time Transport Protocol (RTP) [RFC3550] provides a framework
for delivery of audio and video teleconferencing data and other real- for delivery of audio and video teleconferencing data and other real-
time media applications. Previous work has defined the RTP protocol, time media applications. Previous work has defined the RTP protocol,
along with numerous profiles, payload formats, and other extensions. along with numerous profiles, payload formats, and other extensions.
When combined with appropriate signalling, these form the basis for When combined with appropriate signalling, these form the basis for
many teleconferencing systems. many teleconferencing systems.
skipping to change at page 5, line 31 skipping to change at page 5, line 31
layer flow is a transport-layer flow that is symmetric. That is, layer flow is a transport-layer flow that is symmetric. That is,
the transport-layer flow in the reverse direction has a 5-tuple the transport-layer flow in the reverse direction has a 5-tuple
where the source and destination address and ports are swapped where the source and destination address and ports are swapped
compared to the forward path transport-layer flow, and the compared to the forward path transport-layer flow, and the
transport protocol is the same. transport protocol is the same.
This document uses the terminology from This document uses the terminology from
[I-D.ietf-avtext-rtp-grouping-taxonomy] and [I-D.ietf-avtext-rtp-grouping-taxonomy] and
[I-D.ietf-rtcweb-overview]. Other terms are used according to their [I-D.ietf-rtcweb-overview]. Other terms are used according to their
definitions from the RTP Specification [RFC3550]. Especially note definitions from the RTP Specification [RFC3550]. Especially note
the following frequently used terms: RTP Packet Stream, RTP Session, the following frequently used terms: RTP Stream, RTP Session, and
and Endpoint. Endpoint.
4. WebRTC Use of RTP: Core Protocols 4. WebRTC Use of RTP: Core Protocols
The following sections describe the core features of RTP and RTCP The following sections describe the core features of RTP and RTCP
that need to be implemented, along with the mandated RTP profiles. that need to be implemented, along with the mandated RTP profiles.
Also described are the core extensions providing essential features Also described are the core extensions providing essential features
that all WebRTC Endpoints need to implement to function effectively that all WebRTC Endpoints need to implement to function effectively
on today's networks. on today's networks.
4.1. RTP and RTCP 4.1. RTP and RTCP
skipping to change at page 6, line 33 skipping to change at page 6, line 33
o Support for multiple synchronisation contexts. Participants that o Support for multiple synchronisation contexts. Participants that
send multiple simultaneous RTP packet streams SHOULD do so as part send multiple simultaneous RTP packet streams SHOULD do so as part
of a single synchronisation context, using a single RTCP CNAME for of a single synchronisation context, using a single RTCP CNAME for
all streams and allowing receivers to play the streams out in a all streams and allowing receivers to play the streams out in a
synchronised manner. For compatibility with potential future synchronised manner. For compatibility with potential future
versions of this specification, or for interoperability with non- versions of this specification, or for interoperability with non-
WebRTC devices through a gateway, receivers MUST support multiple WebRTC devices through a gateway, receivers MUST support multiple
synchronisation contexts, indicated by the use of multiple RTCP synchronisation contexts, indicated by the use of multiple RTCP
CNAMEs in an RTP session. This specification mandates the usage CNAMEs in an RTP session. This specification mandates the usage
of a single CNAME when sending RTP Packet Streams in some of a single CNAME when sending RTP Streams in some circumstances,
circumstances, see Section 4.9. see Section 4.9.
o Support for sending and receiving RTCP SR, RR, SDES, and BYE o Support for sending and receiving RTCP SR, RR, SDES, and BYE
packet types. Note that support for other RTCP packet types is packet types. Note that support for other RTCP packet types is
OPTIONAL, unless mandated by other parts of this specification. OPTIONAL, unless mandated by other parts of this specification.
Note that additional RTCP Packet types are used by the RTP/SAVPF Note that additional RTCP Packet types are used by the RTP/SAVPF
Profile (Section 4.2) and the other RTCP extensions (Section 5). Profile (Section 4.2) and the other RTCP extensions (Section 5).
WebRTC endpoints that implement the SDP bundle negotiation WebRTC endpoints that implement the SDP bundle negotiation
extension will use the SDP grouping framework 'mid' attribute to extension will use the SDP grouping framework 'mid' attribute to
identify media streams. Such endpoints MUST implement the RTCP identify media streams. Such endpoints MUST implement the RTCP
SDES MID item described in SDES MID item described in
skipping to change at page 11, line 8 skipping to change at page 11, line 8
flows (e.g., two UDP ports for each RTP session, one port for RTP and flows (e.g., two UDP ports for each RTP session, one port for RTP and
one port for RTCP). With the increased use of Network Address/Port one port for RTCP). With the increased use of Network Address/Port
Translation (NAT/NAPT) this has become problematic, since maintaining Translation (NAT/NAPT) this has become problematic, since maintaining
multiple NAT bindings can be costly. It also complicates firewall multiple NAT bindings can be costly. It also complicates firewall
administration, since multiple ports need to be opened to allow RTP administration, since multiple ports need to be opened to allow RTP
traffic. To reduce these costs and session set-up times, traffic. To reduce these costs and session set-up times,
implementations are REQUIRED to support multiplexing RTP data packets implementations are REQUIRED to support multiplexing RTP data packets
and RTCP control packets on a single transport-layer flow [RFC5761]. and RTCP control packets on a single transport-layer flow [RFC5761].
Such RTP and RTCP multiplexing MUST be negotiated in the signalling Such RTP and RTCP multiplexing MUST be negotiated in the signalling
channel before it is used. If SDP is used for signalling, this channel before it is used. If SDP is used for signalling, this
negotiation MUST use the attributes defined in [RFC5761]. For negotiation MUST use the mechanism defined in [RFC5761].
backwards compatibility, implementations are also REQUIRED to support Implementations can also support sending RTP and RTCP on separate
RTP and RTCP sent on separate transport-layer flows. transport-layer flows, but this is OPTIONAL to implement. If an
implementation does not support RTP and RTCP sent on separate
transport-layer flows, it MUST indicate that using the mechanism
defined in [I-D.ietf-mmusic-mux-exclusive].
Note that the use of RTP and RTCP multiplexed onto a single Note that the use of RTP and RTCP multiplexed onto a single
transport-layer flow ensures that there is occasional traffic sent on transport-layer flow ensures that there is occasional traffic sent on
that port, even if there is no active media traffic. This can be that port, even if there is no active media traffic. This can be
useful to keep NAT bindings alive [RFC6263]. useful to keep NAT bindings alive [RFC6263].
4.6. Reduced Size RTCP 4.6. Reduced Size RTCP
RTCP packets are usually sent as compound RTCP packets, and [RFC3550] RTCP packets are usually sent as compound RTCP packets, and [RFC3550]
requires that those compound packets start with an Sender Report (SR) requires that those compound packets start with an Sender Report (SR)
skipping to change at page 33, line 15 skipping to change at page 33, line 15
transcoding does result in a separation of the two different legs transcoding does result in a separation of the two different legs
removing almost all dependencies, and allowing the forwarding removing almost all dependencies, and allowing the forwarding
endpoint to optimise its media transcoding operation. The cost is endpoint to optimise its media transcoding operation. The cost is
greatly increased computational complexity on the forwarding node. greatly increased computational complexity on the forwarding node.
Receivers of the forwarded stream will see the forwarding device Receivers of the forwarded stream will see the forwarding device
as the sender of the stream, and will not be able to tell from the as the sender of the stream, and will not be able to tell from the
RTP layer that they are receiving a forwarded stream rather than RTP layer that they are receiving a forwarded stream rather than
an entirely new RTP packet stream generated by the forwarding an entirely new RTP packet stream generated by the forwarding
device. device.
12.1.3. Differentiated Treatment of RTP Packet Streams 12.1.3. Differentiated Treatment of RTP Streams
There are use cases for differentiated treatment of RTP packet There are use cases for differentiated treatment of RTP packet
streams. Such differentiation can happen at several places in the streams. Such differentiation can happen at several places in the
system. First of all is the prioritization within the endpoint system. First of all is the prioritization within the endpoint
sending the media, which controls, both which RTP packet streams that sending the media, which controls, both which RTP packet streams that
will be sent, and their allocation of bit-rate out of the current will be sent, and their allocation of bit-rate out of the current
available aggregate as determined by the congestion control. available aggregate as determined by the congestion control.
It is expected that the WebRTC API [W3C.WD-webrtc-20130910] will It is expected that the WebRTC API [W3C.WD-webrtc-20130910] will
allow the application to indicate relative priorities for different allow the application to indicate relative priorities for different
skipping to change at page 35, line 18 skipping to change at page 35, line 18
particular RTP packet stream need to be marked. RTCP compound particular RTP packet stream need to be marked. RTCP compound
packets with Sender Reports (SR), ought to be marked with the same packets with Sender Reports (SR), ought to be marked with the same
priority as the RTP packet stream itself, so the RTCP-based round- priority as the RTP packet stream itself, so the RTCP-based round-
trip time (RTT) measurements are done using the same transport-layer trip time (RTT) measurements are done using the same transport-layer
flow priority as the RTP packet stream experiences. RTCP compound flow priority as the RTP packet stream experiences. RTCP compound
packets containing RR packet ought to be sent with the priority used packets containing RR packet ought to be sent with the priority used
by the majority of the RTP packet streams reported on. RTCP packets by the majority of the RTP packet streams reported on. RTCP packets
containing time-critical feedback packets can use higher priority to containing time-critical feedback packets can use higher priority to
improve the timeliness and likelihood of delivery of such feedback. improve the timeliness and likelihood of delivery of such feedback.
12.2. Media Source, RTP Packet Streams, and Participant Identification 12.2. Media Source, RTP Streams, and Participant Identification
12.2.1. Media Source Identification 12.2.1. Media Source Identification
Each RTP packet stream is identified by a unique synchronisation Each RTP packet stream is identified by a unique synchronisation
source (SSRC) identifier. The SSRC identifier is carried in each of source (SSRC) identifier. The SSRC identifier is carried in each of
the RTP packets comprising a RTP packet stream, and is also used to the RTP packets comprising a RTP packet stream, and is also used to
identify that stream in the corresponding RTCP reports. The SSRC is identify that stream in the corresponding RTCP reports. The SSRC is
chosen as discussed in Section 4.8. The first stage in chosen as discussed in Section 4.8. The first stage in
demultiplexing RTP and RTCP packets received on a single transport demultiplexing RTP and RTCP packets received on a single transport
layer flow at a WebRTC Endpoint is to separate the RTP packet streams layer flow at a WebRTC Endpoint is to separate the RTP packet streams
skipping to change at page 39, line 51 skipping to change at page 39, line 51
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.
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.ietf-avtcore-multi-media-rtp-session] [I-D.ietf-avtcore-multi-media-rtp-session]
Westerlund, M., Perkins, C., and J. Lennox, "Sending Westerlund, M., Perkins, C., and J. Lennox, "Sending
Multiple Types of Media in a Single RTP Session", draft- Multiple Types of Media in a Single RTP Session", draft-
ietf-avtcore-multi-media-rtp-session-07 (work in ietf-avtcore-multi-media-rtp-session-13 (work in
progress), March 2015. progress), December 2015.
[I-D.ietf-avtcore-rtp-circuit-breakers] [I-D.ietf-avtcore-rtp-circuit-breakers]
Perkins, C. and V. Singh, "Multimedia Congestion Control: Perkins, C. and V. Varun, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", draft-ietf- Circuit Breakers for Unicast RTP Sessions", draft-ietf-
avtcore-rtp-circuit-breakers-10 (work in progress), March avtcore-rtp-circuit-breakers-13 (work in progress),
2015. February 2016.
[I-D.ietf-avtcore-rtp-multi-stream] [I-D.ietf-avtcore-rtp-multi-stream]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session", "Sending Multiple RTP Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-07 (work in progress), draft-ietf-avtcore-rtp-multi-stream-11 (work in progress),
March 2015. December 2015.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] [I-D.ietf-avtcore-rtp-multi-stream-optimisation]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session: "Sending Multiple RTP Streams in a Single RTP Session:
Grouping RTCP Reception Statistics and Other Feedback", Grouping RTCP Reception Statistics and Other Feedback",
draft-ietf-avtcore-rtp-multi-stream-optimisation-05 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-12 (work
in progress), February 2015. in progress), March 2016.
[I-D.ietf-avtcore-rtp-topologies-update] [I-D.ietf-avtcore-rtp-topologies-update]
Westerlund, M. and S. Wenger, "RTP Topologies", draft- Westerlund, M. and S. Wenger, "RTP Topologies", draft-
ietf-avtcore-rtp-topologies-update-07 (work in progress), ietf-avtcore-rtp-topologies-update-10 (work in progress),
April 2015. July 2015.
[I-D.ietf-mmusic-mux-exclusive]
Holmberg, C., "Indicating Exclusive Support of RTP/RTCP
Multiplexing using SDP", draft-ietf-mmusic-mux-
exclusive-03 (work in progress), February 2016.
[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-19 (work in progress), March 2015. negotiation-27 (work in progress), February 2016.
[I-D.ietf-rtcweb-audio] [I-D.ietf-rtcweb-audio]
Valin, J. and C. Bran, "WebRTC Audio Codec and Processing Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
Requirements", draft-ietf-rtcweb-audio-08 (work in Requirements", draft-ietf-rtcweb-audio-10 (work in
progress), April 2015. progress), February 2016.
[I-D.ietf-rtcweb-fec] [I-D.ietf-rtcweb-fec]
Uberti, J., "WebRTC Forward Error Correction Uberti, J., "WebRTC Forward Error Correction
Requirements", draft-ietf-rtcweb-fec-01 (work in Requirements", draft-ietf-rtcweb-fec-02 (work in
progress), March 2015. progress), October 2015.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-13 Browser-based Applications", draft-ietf-rtcweb-overview-15
(work in progress), November 2014. (work in progress), January 2016.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-08 (work in progress), February 2015. ietf-rtcweb-security-08 (work in progress), February 2015.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-11 (work in progress), March 2015. rtcweb-security-arch-11 (work in progress), March 2015.
[I-D.ietf-rtcweb-video] [I-D.ietf-rtcweb-video]
Roach, A., "WebRTC Video Processing and Codec Roach, A., "WebRTC Video Processing and Codec
Requirements", draft-ietf-rtcweb-video-05 (work in Requirements", draft-ietf-rtcweb-video-06 (work in
progress), March 2015. progress), June 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP
Payload Format Specifications", BCP 36, RFC 2736, December Payload Format Specifications", BCP 36, RFC 2736,
1999. DOI 10.17487/RFC2736, December 1999,
<http://www.rfc-editor.org/info/rfc2736>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>.
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC Modifiers for RTP Control Protocol (RTCP) Bandwidth",
3556, July 2003. RFC 3556, DOI 10.17487/RFC3556, July 2003,
<http://www.rfc-editor.org/info/rfc3556>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
2006. DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>.
[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,
July 2006. DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007. BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
<http://www.rfc-editor.org/info/rfc4961>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008. (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009. and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <http://www.rfc-editor.org/info/rfc5506>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761,
DOI 10.17487/RFC5761, April 2010,
<http://www.rfc-editor.org/info/rfc5761>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764,
DOI 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010. Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010,
<http://www.rfc-editor.org/info/rfc6051>.
[RFC6464] Lennox, J., Ivov, E., and E. Marocco, "A Real-time [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to- Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464, December 2011. Mixer Audio Level Indication", RFC 6464,
DOI 10.17487/RFC6464, December 2011,
<http://www.rfc-editor.org/info/rfc6464>.
[RFC6465] Ivov, E., Marocco, E., and J. Lennox, "A Real-time [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-
Transport Protocol (RTP) Header Extension for Mixer-to- time Transport Protocol (RTP) Header Extension for Mixer-
Client Audio Level Indication", RFC 6465, December 2011. to-Client Audio Level Indication", RFC 6465,
DOI 10.17487/RFC6465, December 2011,
<http://www.rfc-editor.org/info/rfc6465>.
[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of
Variable Bit Rate Audio with Secure RTP", RFC 6562, March Variable Bit Rate Audio with Secure RTP", RFC 6562,
2012. DOI 10.17487/RFC6562, March 2012,
<http://www.rfc-editor.org/info/rfc6562>.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904, April Real-time Transport Protocol (SRTP)", RFC 6904,
2013. DOI 10.17487/RFC6904, April 2013,
<http://www.rfc-editor.org/info/rfc6904>.
[RFC7007] Terriberry, T., "Update to Remove DVI4 from the [RFC7007] Terriberry, T., "Update to Remove DVI4 from the
Recommended Codecs for the RTP Profile for Audio and Video Recommended Codecs for the RTP Profile for Audio and Video
Conferences with Minimal Control (RTP/AVP)", RFC 7007, Conferences with Minimal Control (RTP/AVP)", RFC 7007,
August 2013. DOI 10.17487/RFC7007, August 2013,
<http://www.rfc-editor.org/info/rfc7007>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013. Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[RFC7160] Petit-Huguenin, M. and G. Zorn, "Support for Multiple [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
Clock Rates in an RTP Session", RFC 7160, April 2014. Clock Rates in an RTP Session", RFC 7160,
DOI 10.17487/RFC7160, April 2014,
<http://www.rfc-editor.org/info/rfc7160>.
[RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC [RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds",
7164, March 2014. RFC 7164, DOI 10.17487/RFC7164, March 2014,
<http://www.rfc-editor.org/info/rfc7164>.
[W3C.WD-mediacapture-streams-20130903] [W3C.WD-mediacapture-streams-20130903]
Burnett, D., Bergkvist, A., Jennings, C., and A. Burnett, D., Bergkvist, A., Jennings, C., and A.
Narayanan, "Media Capture and Streams", World Wide Web Narayanan, "Media Capture and Streams", World Wide Web
Consortium WD WD-mediacapture-streams-20130903, September Consortium WD WD-mediacapture-streams-20130903, September
2013, <http://www.w3.org/TR/2013/ 2013, <http://www.w3.org/TR/2013/
WD-mediacapture-streams-20130903>. WD-mediacapture-streams-20130903>.
[W3C.WD-webrtc-20130910] [W3C.WD-webrtc-20130910]
Bergkvist, A., Burnett, D., Jennings, C., and A. Bergkvist, A., Burnett, D., Jennings, C., and A.
skipping to change at page 43, line 39 skipping to change at page 44, line 29
16.2. Informative References 16.2. Informative References
[I-D.ietf-avtcore-multiplex-guidelines] [I-D.ietf-avtcore-multiplex-guidelines]
Westerlund, M., Perkins, C., and H. Alvestrand, Westerlund, M., Perkins, C., and H. Alvestrand,
"Guidelines for using the Multiplexing Features of RTP to "Guidelines for using the Multiplexing Features of RTP to
Support Multiple Media Streams", draft-ietf-avtcore- Support Multiple Media Streams", draft-ietf-avtcore-
multiplex-guidelines-03 (work in progress), October 2014. multiplex-guidelines-03 (work in progress), October 2014.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, "A Taxonomy of Grouping Semantics and B. Burman, "A Taxonomy of Semantics and Mechanisms for
Mechanisms for Real-Time Transport Protocol (RTP) Real-Time Transport Protocol (RTP) Sources", draft-ietf-
Sources", draft-ietf-avtext-rtp-grouping-taxonomy-06 (work avtext-rtp-grouping-taxonomy-08 (work in progress), July
in progress), March 2015. 2015.
[I-D.ietf-dart-dscp-rtp] [I-D.ietf-dart-dscp-rtp]
Black, D. and P. Jones, "Differentiated Services Black, D. and P. Jones, "Differentiated Services
(DiffServ) and Real-time Communication", draft-ietf-dart- (DiffServ) and Real-time Communication", draft-ietf-dart-
dscp-rtp-10 (work in progress), November 2014. dscp-rtp-10 (work in progress), November 2014.
[I-D.ietf-mmusic-msid] [I-D.ietf-mmusic-msid]
Alvestrand, H., "WebRTC MediaStream Identification in the Alvestrand, H., "WebRTC MediaStream Identification in the
Session Description Protocol", draft-ietf-mmusic-msid-10 Session Description Protocol", draft-ietf-mmusic-msid-11
(work in progress), April 2015. (work in progress), October 2015.
[I-D.ietf-payload-rtp-howto] [I-D.ietf-payload-rtp-howto]
Westerlund, M., "How to Write an RTP Payload Format", Westerlund, M., "How to Write an RTP Payload Format",
draft-ietf-payload-rtp-howto-14 (work in progress), May draft-ietf-payload-rtp-howto-14 (work in progress), May
2015. 2015.
[I-D.ietf-rmcat-cc-requirements] [I-D.ietf-rmcat-cc-requirements]
Jesup, R. and Z. Sarker, "Congestion Control Requirements Jesup, R. and Z. Sarker, "Congestion Control Requirements
for Interactive Real-Time Media", draft-ietf-rmcat-cc- for Interactive Real-Time Media", draft-ietf-rmcat-cc-
requirements-09 (work in progress), December 2014. requirements-09 (work in progress), December 2014.
[I-D.ietf-rtcweb-jsep] [I-D.ietf-rtcweb-jsep]
Uberti, J., Jennings, C., and E. Rescorla, "Javascript Uberti, J., Jennings, C., and E. Rescorla, "Javascript
Session Establishment Protocol", draft-ietf-rtcweb-jsep-09 Session Establishment Protocol", draft-ietf-rtcweb-jsep-13
(work in progress), March 2015. (work in progress), March 2016.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
Polk, "DSCP and other packet markings for RTCWeb QoS", and other packet markings for WebRTC QoS", draft-ietf-
draft-ietf-tsvwg-rtcweb-qos-03 (work in progress), tsvwg-rtcweb-qos-14 (work in progress), March 2016.
November 2014.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
Protocol Extended Reports (RTCP XR)", RFC 3611, November "RTP Control Protocol Extended Reports (RTCP XR)",
2003. RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://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, February Real-time Transport Protocol (SRTP)", RFC 4383,
2006. DOI 10.17487/RFC4383, February 2006,
<http://www.rfc-editor.org/info/rfc4383>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>.
[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP
Control Protocol (RTCP)", RFC 5968, September 2010. Control Protocol (RTCP)", RFC 5968, DOI 10.17487/RFC5968,
September 2010, <http://www.rfc-editor.org/info/rfc5968>.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
Keeping Alive the NAT Mappings Associated with RTP / RTP Keeping Alive the NAT Mappings Associated with RTP / RTP
Control Protocol (RTCP) Flows", RFC 6263, June 2011. Control Protocol (RTCP) Flows", RFC 6263,
DOI 10.17487/RFC6263, June 2011,
<http://www.rfc-editor.org/info/rfc6263>.
[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use
RTP Monitoring Framework", RFC 6792, November 2012. of the RTP Monitoring Framework", RFC 6792,
DOI 10.17487/RFC6792, November 2012,
<http://www.rfc-editor.org/info/rfc6792>.
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use Cases and Requirements", RFC 7478, Time Communication Use Cases and Requirements", RFC 7478,
March 2015. DOI 10.17487/RFC7478, March 2015,
<http://www.rfc-editor.org/info/rfc7478>.
Authors' Addresses Authors' Addresses
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
 End of changes. 62 change blocks. 
102 lines changed or deleted 150 lines changed or added

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