--- 1/draft-ietf-rtcweb-rtp-usage-08.txt 2013-09-05 04:14:32.291468497 -0700 +++ 2/draft-ietf-rtcweb-rtp-usage-09.txt 2013-09-05 04:14:32.379470696 -0700 @@ -1,21 +1,21 @@ RTCWEB Working Group C. S. Perkins Internet-Draft University of Glasgow Intended status: Standards Track M. Westerlund -Expires: March 05, 2014 Ericsson +Expires: March 09, 2014 Ericsson J. Ott Aalto University - September 01, 2013 + September 05, 2013 Web Real-Time Communication (WebRTC): Media Transport and Use of RTP - draft-ietf-rtcweb-rtp-usage-08 + draft-ietf-rtcweb-rtp-usage-09 Abstract The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 05, 2014. + This Internet-Draft will expire on March 09, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -74,21 +74,21 @@ 5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 13 5.1.4. Reference Picture Selection Indication (RPSI) . . . . 13 5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 14 5.1.6. Temporary Maximum Media Stream Bit Rate Request (TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 14 5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 14 5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 15 5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 15 5.2.4. Associating RTP Media Streams and Signalling Contexts 15 - 6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 16 + 6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 15 6.1. Negative Acknowledgements and RTP Retransmission . . . . 16 6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 17 7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 17 7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 18 7.2. RTCP Limitations for Congestion Control . . . . . . . . . 19 7.3. Congestion Control Interoperability and Legacy Systems . 19 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 20 9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 21 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 21 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 23 @@ -276,24 +276,24 @@ the above features, and in some cases do not support RTCP at all. Implementers are advised to consider the requirements for graceful degradation when interoperating with legacy implementations. Other implementation considerations are discussed in Section 12. 4.2. Choice of the RTP Profile The complete specification of RTP for a particular application domain requires the choice of an RTP Profile. For WebRTC use, the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF) [RFC5124], as - extended by [I-D.ietf-avtcore-avp-codecs], MUST be implemented. This - builds on the basic RTP/AVP profile [RFC3551], the RTP profile for - RTCP-based feedback (RTP/AVPF) [RFC4585], and the secure RTP profile - (RTP/SAVP) [RFC3711]. + extended by [RFC7007], MUST be implemented. This builds on the basic + RTP/AVP profile [RFC3551], the RTP profile for RTCP-based feedback + (RTP/AVPF) [RFC4585], and the secure RTP profile (RTP/SAVP) + [RFC3711]. The RTCP-based feedback extensions [RFC4585] are needed for the improved RTCP timer model, that allows more flexible transmission of RTCP packets in response to events, rather than strictly according to bandwidth. This is vital for being able to report congestion events. These extensions also save RTCP bandwidth, and will commonly only use the full RTCP bandwidth allocation if there are many events that require feedback. They are also needed to make use of the RTP conferencing extensions discussed in Section 5.1. @@ -502,22 +502,22 @@ detected, or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams within a set of related RTP sessions. For proper functionality, each RTP endpoint needs to have a unique RTCP CNAME value. The RTP specification [RFC3550] includes guidelines for choosing a unique RTP CNAME, but these are not sufficient in the presence of NAT devices. In addition, long-term persistent identifiers can be problematic from a privacy viewpoint. Accordingly, support for - generating a short-term persistent RTCP CNAMEs following - [I-D.ietf-avtcore-6222bis] is RECOMMENDED. + generating a short-term persistent RTCP CNAMEs following [RFC7022] is + RECOMMENDED. An WebRTC end-point MUST support reception of any CNAME that matches the syntax limitations specified by the RTP specification [RFC3550] and cannot assume that any CNAME will be chosen according to the form suggested above. 5. WebRTC Use of RTP: Extensions There are a number of RTP extensions that are either needed to obtain full functionality, or extremely useful to improve on the baseline @@ -678,35 +678,33 @@ extension used by a client to inform a mixer about the level of audio activity in the packet to which the header is attached. This enables a central node to make mixing or selection decisions without decoding or detailed inspection of the payload, reducing the complexity in some types of central RTP nodes. It can also save decoding resources in receivers, which can choose to decode only the most relevant RTP media streams based on audio activity levels. The Client-to-Mixer Audio Level [RFC6464] extension is RECOMMENDED to be implemented. If it is implemented, it is REQUIRED that the header - extensions are encrypted according to - [I-D.ietf-avtcore-srtp-encrypted-header-ext] since the information + extensions are encrypted according to [RFC6904] since the information contained in these header extensions can be considered sensitive. 5.2.3. Mixer-to-Client Audio Level The Mixer to Client Audio Level header extension [RFC6465] provides the client with the audio level of the different sources mixed into a common mix by a RTP mixer. This enables a user interface to indicate the relative activity level of each session participant, rather than just being included or not based on the CSRC field. This is a pure optimisations of non critical functions, and is hence OPTIONAL to implement. If it is implemented, it is REQUIRED that the header - extensions are encrypted according to - [I-D.ietf-avtcore-srtp-encrypted-header-ext] since the information + extensions are encrypted according to [RFC6904] since the information contained in these header extensions can be considered sensitive. 5.2.4. Associating RTP Media Streams and Signalling Contexts (tbd: it seems likely that we need a mechanism to associate RTP media streams with signalling contexts. The mechanism by which this is done will likely be some combination of an RTP header extension, periodic transmission of a new RTCP SDES item, and some signalling extension. The semantics of those items are not yet settled; see draft-westerlund-avtext-rtcp-sdes-srcname, draft-ietf-mmusic-msid, @@ -1617,32 +1614,20 @@ 16. Acknowledgements The authors would like to thank Harald Alvestrand, Cary Bran, Charles Eckel, Cullen Jennings, Bernard Aboba, and the other members of the IETF RTCWEB working group for their valuable feedback. 17. References 17.1. Normative References - [I-D.ietf-avtcore-6222bis] - Begen, A., Perkins, C., Wing, D., and E. Rescorla, - "Guidelines for Choosing RTP Control Protocol (RTCP) - Canonical Names (CNAMEs)", draft-ietf-avtcore-6222bis-06 - (work in progress), July 2013. - - [I-D.ietf-avtcore-avp-codecs] - Terriberry, T., "Update to Remove DVI4 from the - Recommended Codecs for the RTP Profile for Audio and Video - Conferences with Minimal Control (RTP/AVP)", draft-ietf- - avtcore-avp-codecs-03 (work in progress), July 2013. - [I-D.ietf-avtcore-multi-media-rtp-session] Westerlund, M., Perkins, C., and J. Lennox, "Sending Multiple Types of Media in a Single RTP Session", draft- ietf-avtcore-multi-media-rtp-session-03 (work in progress), July 2013. [I-D.ietf-avtcore-rtp-circuit-breakers] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", draft-ietf- avtcore-rtp-circuit-breakers-03 (work in progress), July @@ -1654,26 +1639,20 @@ Grouping RTCP Reception Statistics and Other Feedback ", draft-ietf-avtcore-rtp-multi-stream-optimisation-00 (work in progress), July 2013. [I-D.ietf-avtcore-rtp-multi-stream] Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session", draft-ietf-avtcore-rtp-multi-stream-01 (work in progress), July 2013. - [I-D.ietf-avtcore-srtp-encrypted-header-ext] - Lennox, J., "Encryption of Header Extensions in the Secure - Real-Time Transport Protocol (SRTP)", draft-ietf-avtcore- - srtp-encrypted-header-ext-05 (work in progress), February - 2013. - [I-D.ietf-avtext-multiple-clock-rates] Petit-Huguenin, M. and G. Zorn, "Support for Multiple Clock Rates in an RTP Session", draft-ietf-avtext- multiple-clock-rates-09 (work in progress), April 2013. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- bundle-negotiation-04 (work in progress), June 2013. @@ -1751,41 +1730,54 @@ Mixer Audio Level Indication", RFC 6464, December 2011. [RFC6465] Ivov, E., Marocco, E., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to- Client Audio Level Indication", RFC 6465, December 2011. [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012. + [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure + Real-time Transport Protocol (SRTP)", RFC 6904, April + 2013. + + [RFC7007] Terriberry, T., "Update to Remove DVI4 from the + Recommended Codecs for the RTP Profile for Audio and Video + Conferences with Minimal Control (RTP/AVP)", RFC 7007, + August 2013. + + [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, + "Guidelines for Choosing RTP Control Protocol (RTCP) + Canonical Names (CNAMEs)", RFC 7022, September 2013. + 17.2. Informative References [I-D.alvestrand-rtcweb-msid] Alvestrand, H., "Cross Session Stream Identification in the Session Description Protocol", draft-alvestrand- rtcweb-msid-02 (work in progress), May 2012. [I-D.ietf-avt-srtp-ekt] Wing, D., McGrew, D., and K. Fischer, "Encrypted Key Transport for Secure RTP", draft-ietf-avt-srtp-ekt-03 (work in progress), October 2011. [I-D.ietf-avtcore-rtp-topologies-update] Westerlund, M. and S. Wenger, "RTP Topologies", draft- ietf-avtcore-rtp-topologies-update-00 (work in progress), April 2013. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Brower- - based Applications", draft-ietf-rtcweb-overview-07 (work - in progress), August 2013. + based Applications", draft-ietf-rtcweb-overview-08 (work + in progress), September 2013. [I-D.ietf-rtcweb-qos] Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and other packet markings for RTCWeb QoS", draft-ietf-rtcweb- qos-00 (work in progress), October 2012. [I-D.ietf-rtcweb-use-cases-and-requirements] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use-cases and Requirements", draft- ietf-rtcweb-use-cases-and-requirements-11 (work in @@ -1798,22 +1790,21 @@ [I-D.westerlund-avtcore-multiplex-architecture] Westerlund, M., Perkins, C., and H. Alvestrand, "Guidelines for using the Multiplexing Features of RTP", draft-westerlund-avtcore-multiplex-architecture-03 (work in progress), February 2013. [I-D.westerlund-avtcore-transport-multiplexing] Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a Single Lower-Layer Transport", draft-westerlund-avtcore- - transport-multiplexing-05 (work in progress), February - 2013. + transport-multiplexing-06 (work in progress), August 2013. [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control", RFC 4341, March 2006. [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for