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.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/