draft-ietf-rtcweb-rtp-usage-18.txt | draft-ietf-rtcweb-rtp-usage-19.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: April 24, 2015 Ericsson | Expires: April 30, 2015 Ericsson | |||
J. Ott | J. Ott | |||
Aalto University | Aalto University | |||
October 21, 2014 | October 27, 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-18 | draft-ietf-rtcweb-rtp-usage-19 | |||
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 April 24, 2015. | This Internet-Draft will expire on April 30, 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 3, line 9 ¶ | skipping to change at page 3, line 9 ¶ | |||
10. Signalling Considerations . . . . . . . . . . . . . . . . . . 22 | 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 22 | |||
11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 24 | 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 24 | |||
12. RTP Implementation Considerations . . . . . . . . . . . . . . 26 | 12. RTP Implementation Considerations . . . . . . . . . . . . . . 26 | |||
12.1. Configuration and Use of RTP Sessions . . . . . . . . . 26 | 12.1. Configuration and Use of RTP Sessions . . . . . . . . . 26 | |||
12.1.1. Use of Multiple Media Sources Within an RTP Session 26 | 12.1.1. Use of Multiple Media Sources Within an RTP Session 26 | |||
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 . . . 32 | 12.1.3. Differentiated Treatment of RTP Packet Streams . . . 32 | |||
12.2. Media Source, RTP Packet Streams, and Participant | 12.2. Media Source, RTP Packet Streams, and Participant | |||
Identification . . . . . . . . . . . . . . . . . . . . . 34 | Identification . . . . . . . . . . . . . . . . . . . . . 34 | |||
12.2.1. Media Source Identification . . . . . . . . . . . . 34 | 12.2.1. Media Source Identification . . . . . . . . . . . . 34 | |||
12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 34 | 12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 35 | |||
12.2.3. Media Synchronisation Context . . . . . . . . . . . 36 | 12.2.3. Media Synchronisation Context . . . . . . . . . . . 36 | |||
13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 | |||
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 | 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 | |||
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 | 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 | |||
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 | 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
16.1. Normative References . . . . . . . . . . . . . . . . . . 38 | 16.1. Normative References . . . . . . . . . . . . . . . . . . 38 | |||
16.2. Informative References . . . . . . . . . . . . . . . . . 41 | 16.2. Informative References . . . . . . . . . . . . . . . . . 41 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
1. Introduction | 1. Introduction | |||
skipping to change at page 10, line 5 ¶ | skipping to change at page 10, line 5 ¶ | |||
4.4. Use of RTP Sessions | 4.4. Use of RTP Sessions | |||
An association amongst a set of end-points communicating using RTP is | An association amongst a set of end-points communicating using RTP is | |||
known as an RTP session [RFC3550]. An end-point can be involved in | known as an RTP session [RFC3550]. An end-point can be involved in | |||
several RTP sessions at the same time. In a multimedia session, each | several RTP sessions at the same time. In a multimedia session, each | |||
type of media has typically been carried in a separate RTP session | type of media has typically been carried in a separate RTP session | |||
(e.g., using one RTP session for the audio, and a separate RTP | (e.g., using one RTP session for the audio, and a separate RTP | |||
session using a different transport-layer flow for the video). | session using a different transport-layer flow for the video). | |||
WebRTC Endpoints are REQUIRED to implement support for multimedia | WebRTC Endpoints are REQUIRED to implement support for multimedia | |||
sessions in this way, separating each RTP session using different | sessions in this way, separating each RTP session using different | |||
transport-layer flows for compatibility with legacy systems. | transport-layer flows for compatibility with legacy systems (this is | |||
sometimes called session multiplexing). | ||||
In modern day networks, however, with the widespread use of network | In modern day networks, however, with the widespread use of network | |||
address/port translators (NAT/NAPT) and firewalls, it is desirable to | address/port translators (NAT/NAPT) and firewalls, it is desirable to | |||
reduce the number of transport-layer flows used by RTP applications. | reduce the number of transport-layer flows used by RTP applications. | |||
This can be done by sending all the RTP packet streams in a single | This can be done by sending all the RTP packet streams in a single | |||
RTP session, which will comprise a single transport-layer flow (this | RTP session, which will comprise a single transport-layer flow (this | |||
will prevent the use of some quality-of-service mechanisms, as | will prevent the use of some quality-of-service mechanisms, as | |||
discussed in Section 12.1.3). Implementations are therefore also | discussed in Section 12.1.3). Implementations are therefore also | |||
REQUIRED to support transport of all RTP packet streams, independent | REQUIRED to support transport of all RTP packet streams, independent | |||
of media type, in a single RTP session using a single transport layer | of media type, in a single RTP session using a single transport layer | |||
flow, according to [I-D.ietf-avtcore-multi-media-rtp-session]. If | flow, according to [I-D.ietf-avtcore-multi-media-rtp-session] (this | |||
multiple types of media are to be used in a single RTP session, all | is sometimes called SSRC multiplexing). If multiple types of media | |||
participants in that RTP session MUST agree to this usage. In an SDP | are to be used in a single RTP session, all participants in that RTP | |||
context, [I-D.ietf-mmusic-sdp-bundle-negotiation] can be used to | session MUST agree to this usage. In an SDP context, | |||
signal such a bundle of RTP packet streams forming a single RTP | [I-D.ietf-mmusic-sdp-bundle-negotiation] can be used to signal such a | |||
session. | bundle of RTP packet streams forming a single RTP session. | |||
Further discussion about the suitability of different RTP session | Further discussion about the suitability of different RTP session | |||
structures and multiplexing methods to different scenarios can be | structures and multiplexing methods to different scenarios can be | |||
found in [I-D.ietf-avtcore-multiplex-guidelines]. | found in [I-D.ietf-avtcore-multiplex-guidelines]. | |||
4.5. RTP and RTCP Multiplexing | 4.5. RTP and RTCP Multiplexing | |||
Historically, RTP and RTCP have been run on separate transport layer | Historically, RTP and RTCP have been run on separate transport layer | |||
flows (e.g., two UDP ports for each RTP session, one 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 | |||
skipping to change at page 19, line 13 ¶ | skipping to change at page 19, line 13 ¶ | |||
RTP bandwidth, and can potentially caused increased packet loss if | RTP bandwidth, and can potentially caused increased packet loss if | |||
the original packet loss was caused by network congestion. Note, | the original packet loss was caused by network congestion. Note, | |||
however, that retransmission of an important lost packet to repair | however, that retransmission of an important lost packet to repair | |||
decoder state can have lower cost than sending a full intra frame. | decoder state can have lower cost than sending a full intra frame. | |||
It is not appropriate to blindly retransmit RTP packets in response | It is not appropriate to blindly retransmit RTP packets in response | |||
to a NACK. The importance of lost packets and the likelihood of them | to a NACK. The importance of lost packets and the likelihood of them | |||
arriving in time to be useful needs to be considered before RTP | arriving in time to be useful needs to be considered before RTP | |||
retransmission is used. | retransmission is used. | |||
Receivers are REQUIRED to implement support for RTP retransmission | Receivers are REQUIRED to implement support for RTP retransmission | |||
packets [RFC4588]. Senders MAY send RTP retransmission packets in | packets [RFC4588] (both session multiplexing and SSRC multiplexing | |||
response to NACKs if the RTP retransmission payload format has been | need to be supported; see Section 4.4). Senders MAY send RTP | |||
negotiated for the session, and if the sender believes it is useful | retransmission packets in response to NACKs if the RTP retransmission | |||
to send a retransmission of the packet(s) referenced in the NACK. An | payload format has been negotiated for the session, and if the sender | |||
RTP sender does not need to retransmit every NACKed packet. | believes it is useful to send a retransmission of the packet(s) | |||
referenced in the NACK. An RTP sender does not need to retransmit | ||||
every NACKed packet. | ||||
6.2. Forward Error Correction (FEC) | 6.2. Forward Error Correction (FEC) | |||
The use of Forward Error Correction (FEC) can provide an effective | The use of Forward Error Correction (FEC) can provide an effective | |||
protection against some degree of packet loss, at the cost of steady | protection against some degree of packet loss, at the cost of steady | |||
bandwidth overhead. There are several FEC schemes that are defined | bandwidth overhead. There are several FEC schemes that are defined | |||
for use with RTP. Some of these schemes are specific to a particular | for use with RTP. Some of these schemes are specific to a particular | |||
RTP payload format, others operate across RTP packets and can be used | RTP payload format, others operate across RTP packets and can be used | |||
with any payload format. It needs to be noted that using redundant | with any payload format. It needs to be noted that using redundant | |||
encoding or FEC will lead to increased play out delay, which needs to | encoding or FEC will lead to increased play out delay, which needs to | |||
skipping to change at page 42, line 10 ¶ | skipping to change at page 42, line 21 ¶ | |||
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-06 (work in progress), | draft-ietf-rmcat-cc-requirements-06 (work in progress), | |||
October 2014. | October 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-06 (work in | Requirements", draft-ietf-rtcweb-audio-07 (work in | |||
progress), September 2014. | progress), October 2014. | |||
[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-12 | Browser-based Applications", draft-ietf-rtcweb-overview-12 | |||
(work in progress), October 2014. | (work in progress), October 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 | |||
End of changes. 9 change blocks. | ||||
19 lines changed or deleted | 22 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |