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