draft-ietf-rtcweb-rtp-usage-15.txt   draft-ietf-rtcweb-rtp-usage-16.txt 
RTCWEB Working Group C. 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: November 29, 2014 Ericsson Expires: January 24, 2015 Ericsson
J. Ott J. Ott
Aalto University Aalto University
May 28, 2014 July 23, 2014
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-15 draft-ietf-rtcweb-rtp-usage-16
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 November 29, 2014. This Internet-Draft will expire on January 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 7, line 7 skipping to change at page 7, line 7
o Support for the reduced minimum RTCP reporting interval described o Support for the reduced minimum RTCP reporting interval described
in Section 6.2 of [RFC3550] is REQUIRED. When using the reduced in Section 6.2 of [RFC3550] is REQUIRED. When using the reduced
minimum RTCP reporting interval, the fixed (non-reduced) minimum minimum RTCP reporting interval, the fixed (non-reduced) minimum
interval MUST be used when calculating the participant timeout interval MUST be used when calculating the participant timeout
interval (see Sections 6.2 and 6.3.5 of [RFC3550]). The delay interval (see Sections 6.2 and 6.3.5 of [RFC3550]). The delay
before sending the initial compound RTCP packet can be set to zero before sending the initial compound RTCP packet can be set to zero
(see Section 6.2 of [RFC3550] as updated by (see Section 6.2 of [RFC3550] as updated by
[I-D.ietf-avtcore-rtp-multi-stream]). [I-D.ietf-avtcore-rtp-multi-stream]).
o Support for discontinuous transmission. RTP allows endpoints to
pause and resume transmission at any time. When resuming, the RTP
sequence number will increase by one, as usual, while the increase
in the RTP timestamp value will depend on the duration of the
pause. Discontinuous transmission is most commonly used with some
audio payload formats, but is not audio specific, and can be used
with any RTP payload format.
o Ignore unknown RTCP packet types and RTP header extensions. This o Ignore unknown RTCP packet types and RTP header extensions. This
to ensure robust handling of future extensions, middlebox to ensure robust handling of future extensions, middlebox
behaviours, etc., that can result in not signalled RTCP packet behaviours, etc., that can result in not signalled RTCP packet
types or RTP header extensions being received. If a compound RTCP types or RTP header extensions being received. If a compound RTCP
packet is received that contains a mixture of known and unknown packet is received that contains a mixture of known and unknown
RTCP packet types, the known packets types need to be processed as RTCP packet types, the known packets types need to be processed as
usual, with only the unknown packet types being discarded. usual, with only the unknown packet types being discarded.
It is known that a significant number of legacy RTP implementations, It is known that a significant number of legacy RTP implementations,
especially those targeted at VoIP-only systems, do not support all of especially those targeted at VoIP-only systems, do not support all of
skipping to change at page 23, line 18 skipping to change at page 23, line 23
signalled. Interworking functions might transform this into the signalled. Interworking functions might transform this into the
RTP/SAVP profile for a legacy use case, by indicating to the RTP/SAVP profile for a legacy use case, by indicating to the
WebRTC end-point that the RTP/SAVPF is used and configuring a trr- WebRTC end-point that the RTP/SAVPF is used and configuring a trr-
int value of 4 seconds. int value of 4 seconds.
Transport Information: Source and destination IP address(s) and Transport Information: Source and destination IP address(s) and
ports for RTP and RTCP MUST be signalled for each RTP session. In ports for RTP and RTCP MUST be signalled for each RTP session. In
WebRTC these transport addresses will be provided by ICE [RFC5245] WebRTC these transport addresses will be provided by ICE [RFC5245]
that signals candidates and arrives at nominated candidate address that signals candidates and arrives at nominated candidate address
pairs. If RTP and RTCP multiplexing [RFC5761] is to be used, such pairs. If RTP and RTCP multiplexing [RFC5761] is to be used, such
that a single port, i.e. transport-layer flow, is used for RTP and that a single port, i.e. transport-layer flow, is used for RTP
RTCP flows, this MUST be signalled (see Section 4.5). and RTCP flows, this MUST be signalled (see Section 4.5).
RTP Payload Types, media formats, and format parameters: The mapping RTP Payload Types, media formats, and format parameters: The mapping
between media type names (and hence the RTP payload formats to be between media type names (and hence the RTP payload formats to be
used), and the RTP payload type numbers MUST be signalled. Each used), and the RTP payload type numbers MUST be signalled. Each
media type MAY also have a number of media type parameters that media type MAY also have a number of media type parameters that
MUST also be signalled to configure the codec and RTP payload MUST also be signalled to configure the codec and RTP payload
format (the "a=fmtp:" line from SDP). Section 4.3 of this memo format (the "a=fmtp:" line from SDP). Section 4.3 of this memo
discusses requirements for uniqueness of payload types. discusses requirements for uniqueness of payload types.
RTP Extensions: The use of any additional RTP header extensions and RTP Extensions: The use of any additional RTP header extensions and
skipping to change at page 23, line 49 skipping to change at page 24, line 6
RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the
end-points will be necessary. This SHALL be done as described in end-points will be necessary. This SHALL be done as described in
"Session Description Protocol (SDP) Bandwidth Modifiers for RTP "Session Description Protocol (SDP) Bandwidth Modifiers for RTP
Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or
something semantically equivalent. This also ensures that the something semantically equivalent. This also ensures that the
end-points have a common view of the RTCP bandwidth. A common end-points have a common view of the RTCP bandwidth. A common
RTCP bandwidth is important as a too different view of the RTCP bandwidth is important as a too different view of the
bandwidths can lead to failure to interoperate. bandwidths can lead to failure to interoperate.
These parameters are often expressed in SDP messages conveyed within These parameters are often expressed in SDP messages conveyed within
an offer/answer exchange. RTP does not depend on SDP or on the an offer/answer exchange. RTP does not depend on SDP or on the offer
offer/answer model, but does require all the necessary parameters to /answer model, but does require all the necessary parameters to be
be agreed upon, and provided to the RTP implementation. Note that in agreed upon, and provided to the RTP implementation. Note that in
the WebRTC context it will depend on the signalling model and API how the WebRTC context it will depend on the signalling model and API how
these parameters need to be configured but they will be need to these parameters need to be configured but they will be need to
either be set in the API or explicitly signalled between the peers. either be set in the API or explicitly signalled between the peers.
11. WebRTC API Considerations 11. WebRTC API Considerations
The WebRTC API [W3C.WD-webrtc-20130910] and the Media Capture and The WebRTC API [W3C.WD-webrtc-20130910] and the Media Capture and
Streams API [W3C.WD-mediacapture-streams-20130903] defines and uses Streams API [W3C.WD-mediacapture-streams-20130903] defines and uses
the concept of a MediaStream that consists of zero or more the concept of a MediaStream that consists of zero or more
MediaStreamTracks. A MediaStreamTrack is an individual stream of MediaStreamTracks. A MediaStreamTrack is an individual stream of
skipping to change at page 25, line 7 skipping to change at page 25, line 13
needed. needed.
The same MediaStreamTrack can also be included in multiple The same MediaStreamTrack can also be included in multiple
MediaStreams, thus multiple sets of MediaStreams can implicitly need MediaStreams, thus multiple sets of MediaStreams can implicitly need
to use the same synchronisation base. To ensure that this works in to use the same synchronisation base. To ensure that this works in
all cases, and does not force an end-point to to disrupt the media by all cases, and does not force an end-point to to disrupt the media by
changing synchronisation base and CNAME during delivery of any changing synchronisation base and CNAME during delivery of any
ongoing packet streams, all MediaStreamTracks and their associated ongoing packet streams, all MediaStreamTracks and their associated
SSRCs originating from the same end-point need to be sent using the SSRCs originating from the same end-point need to be sent using the
same CNAME within one RTCPeerConnection. This is motivating the same CNAME within one RTCPeerConnection. This is motivating the
strong recommendation in Section 4.9 to only use a single CNAME. discussion in Section 4.9 to only use a single CNAME.
The requirement on using the same CNAME for all SSRCs that The requirement on using the same CNAME for all SSRCs that
originate from the same end-point, does not require a middlebox originate from the same end-point, does not require a middlebox
that forwards traffic from multiple end-points to only use a that forwards traffic from multiple end-points to only use a
single CNAME. single CNAME.
Different CNAMEs normally need to be used for different Different CNAMEs normally need to be used for different
RTCPeerConnection instances, as specified in Section 4.9. Having two RTCPeerConnection instances, as specified in Section 4.9. Having two
communication sessions with the same CNAME could enable tracking of a communication sessions with the same CNAME could enable tracking of a
user or device across different services (see Section 4.4.1 of user or device across different services (see Section 4.4.1 of
skipping to change at page 38, line 41 skipping to change at page 38, line 46
[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-05 (work in ietf-avtcore-multi-media-rtp-session-05 (work in
progress), February 2014. progress), February 2014.
[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-05 (work in progress), avtcore-rtp-circuit-breakers-06 (work in progress), July
February 2014. 2014.
[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-04 (work in progress),
May 2014.
[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 Media 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-02 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-00 (work
in progress), February 2014. in progress), July 2013.
[I-D.ietf-rtcweb-security] [I-D.ietf-avtcore-rtp-multi-stream]
Rescorla, E., "Security Considerations for WebRTC", draft- Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
ietf-rtcweb-security-06 (work in progress), January 2014. "Sending Multiple Media Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-05 (work in progress),
July 2014.
[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-09 (work in progress), February 2014. rtcweb-security-arch-10 (work in progress), July 2014.
[I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-07 (work in progress), July 2014.
[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, March 1997.
[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, December
1999. 1999.
[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
skipping to change at page 41, line 37 skipping to change at page 41, line 37
[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-02 (work in progress), ietf-avtcore-rtp-topologies-update-02 (work in progress),
May 2014. May 2014.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro,
"A Taxonomy of Grouping Semantics and Mechanisms for Real- "A Taxonomy of Grouping Semantics and Mechanisms for Real-
Time Transport Protocol (RTP) Sources", draft-ietf-avtext- Time Transport Protocol (RTP) Sources", draft-ietf-avtext-
rtp-grouping-taxonomy-01 (work in progress), February rtp-grouping-taxonomy-02 (work in progress), June 2014.
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-05 Session Description Protocol", draft-ietf-mmusic-msid-06
(work in progress), March 2014. (work in progress), June 2014.
[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-07 (work in progress), April 2014. negotiation-07 (work in progress), April 2014.
[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-13 (work in progress), draft-ietf-payload-rtp-howto-13 (work in progress),
January 2014. January 2014.
[I-D.ietf-rmcat-cc-requirements] [I-D.ietf-rmcat-cc-requirements]
Jesup, R., "Congestion Control Requirements For RMCAT", Jesup, R., "Congestion Control Requirements For RMCAT",
draft-ietf-rmcat-cc-requirements-04 (work in progress), draft-ietf-rmcat-cc-requirements-05 (work in progress),
April 2014. July 2014.
[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-05 (work in Requirements", draft-ietf-rtcweb-audio-05 (work in
progress), February 2014. progress), February 2014.
[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
based Applications", draft-ietf-rtcweb-overview-09 (work Browser-based Applications", draft-ietf-rtcweb-overview-10
in progress), February 2014. (work in progress), June 2014.
[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-14 (work in ietf-rtcweb-use-cases-and-requirements-14 (work in
progress), February 2014. progress), February 2014.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J.
other packet markings for RTCWeb QoS", draft-ietf-tsvwg- Polk, "DSCP and other packet markings for RTCWeb QoS",
rtcweb-qos-00 (work in progress), April 2014. draft-ietf-tsvwg-rtcweb-qos-02 (work in progress), June
2014.
[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.
[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, February
2006. 2006.
skipping to change at page 43, line 19 skipping to change at page 43, line 19
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, June 2011.
[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
RTP Monitoring Framework", RFC 6792, November 2012. RTP Monitoring Framework", RFC 6792, November 2012.
[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-
WD-mediacapture-streams-20130903>. 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.
Narayanan, "WebRTC 1.0: Real-time Communication Between Narayanan, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD WD- Browsers", World Wide Web Consortium WD WD-
webrtc-20130910, September 2013, webrtc-20130910, September 2013,
<http://www.w3.org/TR/2013/WD-webrtc-20130910>. <http://www.w3.org/TR/2013/WD-webrtc-20130910>.
Authors' Addresses Authors' Addresses
 End of changes. 20 change blocks. 
40 lines changed or deleted 48 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/