draft-ietf-rtcweb-rtp-usage-10.txt   draft-ietf-rtcweb-rtp-usage-11.txt 
RTCWEB Working Group C. Perkins RTCWEB Working Group C. 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, 2014 Ericsson Expires: June 19, 2014 Ericsson
J. Ott J. Ott
Aalto University Aalto University
October 21, 2013 December 16, 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-10 draft-ietf-rtcweb-rtp-usage-11
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, 2014. This Internet-Draft will expire on June 19, 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 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. WebRTC Use of RTP: Core Protocols . . . . . . . . . . . . . . 5 4. WebRTC Use of RTP: Core Protocols . . . . . . . . . . . . . . 5
4.1. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . 5 4.1. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Choice of the RTP Profile . . . . . . . . . . . . . . . . 6 4.2. Choice of the RTP Profile . . . . . . . . . . . . . . . . 6
4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 7 4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 7
4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 9 4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 8
4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 9 4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 9
4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 10 4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 10
4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 10 4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 10
4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 11 4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 10
4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 11 4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 11
5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 12 5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 12
5.1. Conferencing Extensions . . . . . . . . . . . . . . . . . 12 5.1. Conferencing Extensions . . . . . . . . . . . . . . . . . 12
5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 13 5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 13
5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 13 5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 13
5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 14 5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 13
5.1.4. Reference Picture Selection Indication (RPSI) . . . . 14 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 . . . . . . . . . . . . . . . . 15 5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . 16 5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 15
5.2.4. Associating RTP Media Streams and Signalling Contexts 16 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 . . . . . . 16
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 . . . . 18 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 . 20 7.3. Congestion Control Interoperability and Legacy Systems . 19
8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . 22 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 21
11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 23 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 23
12. RTP Implementation Considerations . . . . . . . . . . . . . . 24 12. RTP Implementation Considerations . . . . . . . . . . . . . . 25
12.1. Configuration and Use of RTP Sessions . . . . . . . . . 24 12.1. Configuration and Use of RTP Sessions . . . . . . . . . 25
12.1.1. Use of Multiple Media Flows Within an RTP Session . 24 12.1.1. Use of Multiple Media Flows Within an RTP Session . 25
12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 26 12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 27
12.1.3. Differentiated Treatment of Flows . . . . . . . . . 31 12.1.3. Differentiated Treatment of Flows . . . . . . . . . 31
12.2. Source, Flow, and Participant Identification . . . . . . 32 12.2. Source, Flow, and Participant Identification . . . . . . 32
12.2.1. Media Streams . . . . . . . . . . . . . . . . . . . 32 12.2.1. Media Streams . . . . . . . . . . . . . . . . . . . 33
12.2.2. Media Streams: SSRC Collision Detection . . . . . . 33 12.2.2. Media Streams: SSRC Collision Detection . . . . . . 33
12.2.3. Media Synchronisation Context . . . . . . . . . . . 34 12.2.3. Media Synchronisation Context . . . . . . . . . . . 34
12.2.4. Correlation of Media Streams . . . . . . . . . . . . 34
13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35 15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
17.1. Normative References . . . . . . . . . . . . . . . . . . 36 17.1. Normative References . . . . . . . . . . . . . . . . . . 36
17.2. Informative References . . . . . . . . . . . . . . . . . 39 17.2. Informative References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
The Real-time Transport Protocol (RTP) [RFC3550] provides a framework The Real-time Transport Protocol (RTP) [RFC3550] provides a framework
for delivery of audio and video teleconferencing data and other real- for delivery of audio and video teleconferencing data and other real-
skipping to change at page 6, line 5 skipping to change at page 6, line 5
functionality implementations of RTP, but are REQUIRED in all WebRTC functionality implementations of RTP, but are REQUIRED in all WebRTC
implementations: implementations:
o Support for use of multiple simultaneous SSRC values in a single o Support for use of multiple simultaneous SSRC values in a single
RTP session, including support for RTP end-points that send many RTP session, including support for RTP end-points that send many
SSRC values simultaneously, following [RFC3550] and SSRC values simultaneously, following [RFC3550] and
[I-D.ietf-avtcore-rtp-multi-stream]. Support for the RTCP [I-D.ietf-avtcore-rtp-multi-stream]. Support for the RTCP
optimisations for multi-SSRC sessions defined in optimisations for multi-SSRC sessions defined in
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] is RECOMMENDED. [I-D.ietf-avtcore-rtp-multi-stream-optimisation] is RECOMMENDED.
* (tbd: do endpoints need to signal the maximum number of SSRCs
that they support (e.g., draft-westerlund-mmusic-max-ssrc-01)
and/or some constraint on the maximum number of simultaneous
streams of various kinds that can be decoded?)
o Random choice of SSRC on joining a session; collision detection o Random choice of SSRC on joining a session; collision detection
and resolution for SSRC values (see also Section 4.8). and resolution for SSRC values (see also Section 4.8).
o Support for reception of RTP data packets containing CSRC lists, o Support for reception of RTP data packets containing CSRC lists,
as generated by RTP mixers, and RTCP packets relating to CSRCs. as generated by RTP mixers, and RTCP packets relating to CSRCs.
o Support for sending correct synchronization information in the o Sending correct synchronisation information in the RTCP Sender
RTCP Sender Reports, to allow a receiver to implement lip-sync, Reports, to allow receivers to implement lip-sync, with support
with RECOMMENDED support for the rapid RTP synchronisation for the rapid RTP synchronisation extensions (see Section 5.2.1)
extensions (see Section 5.2.1). being RECOMMENDED.
o Support for multiple synchronisation contexts. Participants that
send multiple simultaneous RTP media streams MAY do so as part of
a single synchronisation context, using a single RTCP CNAME for
all streams and allowing receivers to play the streams out in a
synchronised manner, or they MAY use different synchronisation
contexts, and hence different RTCP CNAMEs, for some or all of the
streams. Receivers MUST support reception of multiple RTCP CNAMEs
from each participant in an RTP session. See also Section 4.9.
o Support for sending and receiving RTCP SR, RR, SDES, and BYE o Support for sending and receiving RTCP SR, RR, SDES, and BYE
packet types, with OPTIONAL support for other RTCP packet types; packet types, with OPTIONAL support for other RTCP packet types;
implementations MUST ignore unknown RTCP packet types. Note that implementations MUST ignore unknown RTCP packet types. Note that
additional RTCP Packet types are needed by the RTP/SAVPF Profile additional RTCP Packet types are needed by the RTP/SAVPF Profile
(Section 4.2) and the other RTCP extensions (Section 5). (Section 4.2) and the other RTCP extensions (Section 5).
o Support for multiple end-points in a single RTP session, and for o Support for multiple end-points in a single RTP session, and for
scaling the RTCP transmission interval according to the number of scaling the RTCP transmission interval according to the number of
participants in the session; support for randomised RTCP participants in the session; support for randomised RTCP
skipping to change at page 12, line 7 skipping to change at page 11, line 37
The RTCP Canonical Name (CNAME) provides a persistent transport-level The RTCP Canonical Name (CNAME) provides a persistent transport-level
identifier for an RTP endpoint. While the Synchronisation Source identifier for an RTP endpoint. While the Synchronisation Source
(SSRC) identifier for an RTP endpoint can change if a collision is (SSRC) identifier for an RTP endpoint can change if a collision is
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 at least one unique RTCP CNAME value. An endpoint MAY needs to have at least one unique RTCP CNAME value. An endpoint MAY
have multiple CNAMEs, as the CNAME also identifies a particular have multiple CNAMEs, as the CNAME also identifies a particular
synchronization context, i.e. all SSRC associated with a CNAME share synchronisation context, i.e. all SSRC associated with a CNAME share
a common reference clock, and if an endpoint have SSRCs associated a common reference clock, and if an endpoint have SSRCs associated
with different reference clocks it will need to use multiple CNAMEs. with different reference clocks it will need to use multiple CNAMEs.
This ought not be common, and if possible reference clocks ought to This ought not be common, and if possible reference clocks ought to
be mapped to each other and one chosen to be used with RTP and RTCP. be mapped to each other and one chosen to be used with RTP and RTCP.
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 [RFC7022] is generating a short-term persistent RTCP CNAMEs following [RFC7022] is
skipping to change at page 21, line 30 skipping to change at page 21, line 6
8. WebRTC Use of RTP: Performance Monitoring 8. WebRTC Use of RTP: Performance Monitoring
As described in Section 4.1, implementations are REQUIRED to generate As described in Section 4.1, implementations are REQUIRED to generate
RTCP Sender Report (SR) and Reception Report (RR) packets relating to RTCP Sender Report (SR) and Reception Report (RR) packets relating to
the RTP media streams they send and receive. These RTCP reports can the RTP media streams they send and receive. These RTCP reports can
be used for performance monitoring purposes, since they include basic be used for performance monitoring purposes, since they include basic
packet loss and jitter statistics. packet loss and jitter statistics.
A large number of additional performance metrics are supported by the A large number of additional performance metrics are supported by the
RTCP Extended Reports (XR) framework [RFC3611]. It is not yet clear RTCP Extended Reports (XR) framework [RFC3611][RFC6792]. It is not
what extended metrics are appropriate for use in the WebRTC context, yet clear what extended metrics are appropriate for use in the WebRTC
so implementations are not expected to generate any RTCP XR packets. context, so there is no requirement that implementations generate
However, implementations that can use detailed performance monitoring RTCP XR packets. However, implementations that can use detailed
data MAY generate RTCP XR packets as appropriate; the use of such performance monitoring data MAY generate RTCP XR packets as
packets SHOULD be signalled in advance. appropriate; the use of such packets SHOULD be signalled in advance.
All WebRTC implementations MUST be prepared to receive RTP XR report All WebRTC implementations MUST be prepared to receive RTP XR report
packets, whether or not they were signalled. There is no requirement packets, whether or not they were signalled. There is no requirement
that the data contained in such reports be used, or exposed to the that the data contained in such reports be used, or exposed to the
Javascript application, however. Javascript application, however.
9. WebRTC Use of RTP: Future Extensions 9. WebRTC Use of RTP: Future Extensions
It is possible that the core set of RTP protocols and RTP extensions It is possible that the core set of RTP protocols and RTP extensions
specified in this memo will prove insufficient for the future needs specified in this memo will prove insufficient for the future needs
skipping to change at page 23, line 31 skipping to change at page 23, line 7
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 offer an offer/answer exchange. RTP does not depend on SDP or on the offer
/answer model, but does require all the necessary parameters to be /answer model, but does require all the necessary parameters to be
agreed upon, and provided to the RTP implementation. We note that in agreed upon, and provided to the RTP implementation. We 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 set in the API or explicitly signalled between the peers. either set in the API or explicitly signalled between the peers.
11. WebRTC API Considerations 11. WebRTC API Considerations
The WebRTC API and its media function have the concept of a WebRTC The WebRTC API [W3C.WD-webrtc-20130910] and the Media Capture and
MediaStream that consists of zero or more tracks. A track is an Streams API [W3C.WD-mediacapture-streams-20130903] defines and uses
individual stream of media from any type of media source like a the concept of a MediaStream that consists of zero or more
microphone or a camera, but also conceptual sources, like a audio mix MediaStreamTracks. A MediaStreamTrack is an individual stream of
or a video composition, are possible. The tracks within a WebRTC media from any type of media source like a microphone or a camera,
MediaStream are expected to be synchronized. but also conceptual sources, like a audio mix or a video composition,
are possible. The MediaStreamTracks within a MediaStream need to be
possible to play out synchronised.
A track correspond to the media received with one particular SSRC. A MediaStreamTrack's realisation in RTP in the context of an
There might be additional SSRCs associated with that SSRC, like for RTCPeerConnection consists of a source packet stream identified with
RTP retransmission or Forward Error Correction. However, one SSRC an SSRC within an RTP session part of the RTCPeerConnection. The
will identify an RTP media stream and its timing. MediaStreamTrack can also result in additional packet streams, and
thus SSRCs, in the same RTP session. These can be dependent packet
streams from scalable encoding of the source stream associated with
the MediaStreamTrack, if such a media encoder is used. They can also
be redundancy packet streams, these are created when applying Forward
Error Correction (Section 6.2) or RTP retransmission (Section 6.1) to
the source packet stream.
As a result, a WebRTC MediaStream is a collection of SSRCs carrying Note: It is quite likely that a simulcast specification will
the different media included in the synchronised aggregate. result in multiple source packet streams, and thus SSRCs, based on
Therefore, also the synchronization state associated with the the same source stream associated with the MediaStreamTrack being
included SSRCs are part of concept. It is important to consider that simulcasted. Each such source packet stream can have dependent
there can be multiple different WebRTC MediaStreams containing a and redundant packet streams associated with them. However, the
given Track (SSRC). To avoid unnecessary duplication of media at the final conclusion on this awaits the specification of simulcast.
transport level in such cases, a need arises for a binding defining Simulcast will also require signalling to correctly separate and
which WebRTC MediaStreams a given SSRC is associated with at the associate the source packet streams with their sets of dependent
signalling level. and/or redundant streams.
The API also needs to be capable of handling when new SSRCs are It is important to note that the same media source can be feeding
received but not previously signalled by signalling in some fashion. multiple MediaStreamTracks. As different sets of constraints or
Note, that not all SSRCs carries media directly associated with a other parameters can be applied to the MediaStreamTrack, each
media source, instead they can be repair or redundancy information MediaStreamTrack instance added to a RTCPeerConnection SHALL result
for one or a set of SSRCs. in an independent source packet stream, with its own set of
associated packet streams, and thus different SSRC(s). It will
depend on applied constraints and parameters if the source stream and
the encoding configuration will be identical between different
MediaStreamTracks sharing the same media source. Thus it is possible
for multiple source packet streams to share encoded streams (but not
packet streams), but this is an implementation choice to try to
utilise such optimisations. Note that such optimizations would need
to take into account that the constraints for one of the
MediaStreamTracks can at any moment change, meaning that the encoding
configurations should no longer be identical.
A proposal for how the binding between WebRTC MediaStreams and SSRC The same MediaStreamTrack can also be included in multiple
can be done is specified in "Cross Session Stream Identification in MediaStreams, thus multiple sets of MediaStreams can implicitly need
the Session Description Protocol" [I-D.alvestrand-rtcweb-msid]. to use the same synchronisation base. To ensure that this works in
all cases, and don't forces a endpoint to change synchronisation base
and CNAME in the middle of a ongoing delivery of any packet streams,
which would cause media disruption; all MediaStreamTracks and their
associated SSRCs originating from the same endpoint MUST be sent
using the same CNAME within one RTCPeerConnection as well as across
all RTCPeerConnections part of the same communication session
context, which for a browser are a single origin.
(tbd: This text needs to be improved and achieved consensus on. Note: It is important that the same CNAME is not used in different
Interim meeting in June 2012 shows large differences in opinions.) communication session contexts or origins, as that could enable
tracking of a user and its device usage of different services.
See Section 4.4.1 of Security Considerations for WebRTC
[I-D.ietf-rtcweb-security] for further discussion.
(tbd: It is an open question whether these considerations are best The reasons to require the same CNAME across multiple
discussed in this draft, in the W3C WebRTC API spec, or elsewhere. RTCPeerConnections is to enable synchronisation of different
MediaStreamTracks originating from one endpoint despite them being
transported over different RTCPeerConnections.
The above will currently force a WebRTC endpoint that receives an
MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing
on any RTCPeerConnection to perform resynchronisation of the stream.
This, as the sending party needs to change the CNAME, which implies
that it has to use a locally available system clock as timebase for
the synchronisation. Thus, the relative relation between the
timebase of the incoming stream and the system sending out needs to
defined. This relation also needs monitoring for clock drift and
likely adjustments of the synchronisation. The sending entity is
also responsible for congestion control for its the sent streams. In
cases of packet loss the loss of incoming data also needs to be
handled. This leads to the observation that the method that is least
likely to cause issues or interruptions in the outgoing source packet
stream is a model of full decoding, including repair etc followed by
encoding of the media again into the outgoing packet stream.
Optimisations of this method is clearly possible and implementation
specific.
A WebRTC endpoint MUST support receiving multiple MediaStreamTracks,
where each of different MediaStreamTracks (and their sets of
associated packet streams) uses different CNAMEs. However,
MediaStreamTracks that are received with different CNAMEs have no
defined synchronisation.
Note: The motivation for supporting reception of multiple CNAMEs
are to allow for forward compatibility with any future changes
that enables more efficient stream handling when endpoints relay/
forward streams. It also ensures that endpoints can interoperate
with certain types of multi-stream middleboxes or endpoints that
are not WebRTC.
The binding between the WebRTC MediaStreams, MediaStreamTracks and
the SSRC is done as specified in "Cross Session Stream Identification
in the Session Description Protocol" [I-D.ietf-mmusic-msid]. This
document [I-D.ietf-mmusic-msid] also defines, in section 4.1, how to
map unknown source packet stream SSRCs to MediaStreamTracks and
MediaStreams. Commonly the RTP Payload Type of any incoming packets
will reveal if the packet stream is a source stream or a redundancy
or dependent packet stream. The association to the correct source
packet stream depends on the payload format in use for the packet
stream.
12. RTP Implementation Considerations 12. RTP Implementation Considerations
The following discussion provides some guidance on the implementation The following discussion provides some guidance on the implementation
of the RTP features described in this memo. The focus is on a WebRTC of the RTP features described in this memo. The focus is on a WebRTC
end-point implementation perspective, and while some mention is made end-point implementation perspective, and while some mention is made
of the behaviour of middleboxes, that is not the focus of this memo. of the behaviour of middleboxes, that is not the focus of this memo.
12.1. Configuration and Use of RTP Sessions 12.1. Configuration and Use of RTP Sessions
skipping to change at page 26, line 5 skipping to change at page 27, line 5
of media processing middlebox. In the latter cases, the middlebox of media processing middlebox. In the latter cases, the middlebox
might send mixed or relayed RTP streams from several participants, might send mixed or relayed RTP streams from several participants,
that the WebRTC end-point will need to render. Thus, even though that the WebRTC end-point will need to render. Thus, even though
a WebRTC end-point might only be a member of a single RTP session, a WebRTC end-point might only be a member of a single RTP session,
the peer device might be extending that RTP session to incorporate the peer device might be extending that RTP session to incorporate
other end-points. WebRTC is a group communication environment and other end-points. WebRTC is a group communication environment and
end-points need to be capable of receiving, decoding, and playing end-points need to be capable of receiving, decoding, and playing
out multiple RTP media streams at once, even in a single RTP out multiple RTP media streams at once, even in a single RTP
session. session.
(tbd: Are any mechanism needed to signal limitations in the number
of active SSRC that an end-point can handle?)
(tbd: need to discuss signalling for the above here, preferably by
referring to a separate document that describes SDP use for WebRTC)
12.1.2. Use of Multiple RTP Sessions 12.1.2. Use of Multiple RTP Sessions
In addition to sending and receiving multiple media streams within a In addition to sending and receiving multiple media streams within a
single RTP session, a WebRTC end-point might participate in multiple single RTP session, a WebRTC end-point might participate in multiple
RTP sessions. There are several reasons why a WebRTC end-point might RTP sessions. There are several reasons why a WebRTC end-point might
choose to do this: choose to do this:
To interoperate with legacy devices: The common practice in the non- To interoperate with legacy devices: The common practice in the non-
WebRTC world is to send different types of media in separate RTP WebRTC world is to send different types of media in separate RTP
sessions, for example using one RTP session for audio and another sessions, for example using one RTP session for audio and another
skipping to change at page 26, line 44 skipping to change at page 27, line 38
To separate media with different purposes: An end-point might want To separate media with different purposes: An end-point might want
to send media streams that have different purposes on different to send media streams that have different purposes on different
RTP sessions, to make it easy for the peer device to distinguish RTP sessions, to make it easy for the peer device to distinguish
them. For example, some centralised multiparty conferencing them. For example, some centralised multiparty conferencing
systems display the active speaker in high resolution, but show systems display the active speaker in high resolution, but show
low resolution "thumbnails" of other participants. Such systems low resolution "thumbnails" of other participants. Such systems
might configure the end-points to send simulcast high- and low- might configure the end-points to send simulcast high- and low-
resolution versions of their video using separate RTP sessions, to resolution versions of their video using separate RTP sessions, to
simplify the operation of the central mixer. In the WebRTC simplify the operation of the central mixer. In the WebRTC
context this appears to be most easily accomplished by context this appears to be most easily accomplished by
establishing multiple PeerConnection all being feed the same set establishing multiple RTCPeerConnection all being feed the same
of WebRTC MediaStreams. Each PeerConnection is then configured to set of WebRTC MediaStreams. Each RTCPeerConnection is then
deliver a particular media quality and thus media bit-rate, and configured to deliver a particular media quality and thus media
will produce an independently encoded version with the codec bit-rate, and will produce an independently encoded version with
parameters agreed specifically in the context of that the codec parameters agreed specifically in the context of that
PeerConnection. The central mixer can always distinguish packets RTCPeerConnection. The central mixer can always distinguish
corresponding to the low- and high-resolution streams by packets corresponding to the low- and high-resolution streams by
inspecting their SSRC, RTP payload type, or some other information inspecting their SSRC, RTP payload type, or some other information
contained in RTP header extensions or RTCP packets, but it can be contained in RTP header extensions or RTCP packets, but it can be
easier to distinguish the flows if they arrive on separate RTP easier to distinguish the flows if they arrive on separate RTP
sessions on separate UDP ports. sessions on separate UDP ports.
To directly connect with multiple peers: A multi-party conference To directly connect with multiple peers: A multi-party conference
does not need to use a central mixer. Rather, a multi-unicast does not need to use a central mixer. Rather, a multi-unicast
mesh can be created, comprising several distinct RTP sessions, mesh can be created, comprising several distinct RTP sessions,
with each participant sending RTP traffic over a separate RTP with each participant sending RTP traffic over a separate RTP
session (that is, using an independent PeerConnection object) to session (that is, using an independent RTCPeerConnection object)
every other participant, as shown in Figure 1. This topology has to every other participant, as shown in Figure 1. This topology
the benefit of not requiring a central mixer node that is trusted has the benefit of not requiring a central mixer node that is
to access and manipulate the media data. The downside is that it trusted to access and manipulate the media data. The downside is
increases the used bandwidth at each sender by requiring one copy that it increases the used bandwidth at each sender by requiring
of the RTP media streams for each participant that are part of the one copy of the RTP media streams for each participant that are
same session beyond the sender itself. part of the same session beyond the sender itself.
+---+ +---+ +---+ +---+
| A |<--->| B | | A |<--->| B |
+---+ +---+ +---+ +---+
^ ^ ^ ^
\ / \ /
\ / \ /
v v v v
+---+ +---+
| C | | C |
+---+ +---+
Figure 1: Multi-unicast using several RTP sessions Figure 1: Multi-unicast using several RTP sessions
The multi-unicast topology could also be implemented as a single The multi-unicast topology could also be implemented as a single
RTP session, spanning multiple peer-to-peer transport layer RTP session, spanning multiple peer-to-peer transport layer
connections, or as several pairwise RTP sessions, one between each connections, or as several pairwise RTP sessions, one between each
pair of peers. To maintain a coherent mapping between the pair of peers. To maintain a coherent mapping between the
relation between RTP sessions and PeerConnection objects we relation between RTP sessions and RTCPeerConnection objects we
recommend that this is implemented as several individual RTP recommend that this is implemented as several individual RTP
sessions. The only downside is that end-point A will not learn of sessions. The only downside is that end-point A will not learn of
the quality of any transmission happening between B and C, since the quality of any transmission happening between B and C, since
it will not see RTCP reports for the RTP session between B and C, it will not see RTCP reports for the RTP session between B and C,
whereas it would it all three participants were part of a single whereas it would it all three participants were part of a single
RTP session. Experience with the Mbone tools (experimental RTP- RTP session. Experience with the Mbone tools (experimental RTP-
based multicast conferencing tools from the late 1990s) has showed based multicast conferencing tools from the late 1990s) has showed
that RTCP reception quality reports for third parties can usefully that RTCP reception quality reports for third parties can usefully
be presented to the users in a way that helps them understand be presented to the users in a way that helps them understand
asymmetric network problems, and the approach of using separate asymmetric network problems, and the approach of using separate
skipping to change at page 28, line 19 skipping to change at page 29, line 15
To indirectly connect with multiple peers: A common scenario in To indirectly connect with multiple peers: A common scenario in
multi-party conferencing is to create indirect connections to multi-party conferencing is to create indirect connections to
multiple peers, using an RTP mixer, translator, or some other type multiple peers, using an RTP mixer, translator, or some other type
of RTP middlebox. Figure 2 outlines a simple topology that might of RTP middlebox. Figure 2 outlines a simple topology that might
be used in a four-person centralised conference. The middlebox be used in a four-person centralised conference. The middlebox
acts to optimise the transmission of RTP media streams from acts to optimise the transmission of RTP media streams from
certain perspectives, either by only sending some of the received certain perspectives, either by only sending some of the received
RTP media stream to any given receiver, or by providing a combined RTP media stream to any given receiver, or by providing a combined
RTP media stream out of a set of contributing streams. RTP media stream out of a set of contributing streams.
+---+ +-------------+ +---+ +---+ +-------------+ +---+
| A |<---->| |<---->| B | | A |<---->| |<---->| B |
+---+ | RTP mixer, | +---+ +---+ | RTP mixer, | +---+
| translator, | | translator, |
| or other | | or other |
+---+ | middlebox | +---+ +---+ | middlebox | +---+
| C |<---->| |<---->| D | | C |<---->| |<---->| D |
+---+ +-------------+ +---+ +---+ +-------------+ +---+
Figure 2: RTP mixer with only unicast paths Figure 2: RTP mixer with only unicast paths
There are various methods of implementation for the middlebox. If There are various methods of implementation for the middlebox. If
implemented as a standard RTP mixer or translator, a single RTP implemented as a standard RTP mixer or translator, a single RTP
session will extend across the middlebox and encompass all the session will extend across the middlebox and encompass all the
end-points in one multi-party session. Other types of middlebox end-points in one multi-party session. Other types of middlebox
might use separate RTP sessions between each end-point and the might use separate RTP sessions between each end-point and the
middlebox. A common aspect is that these central nodes can use a middlebox. A common aspect is that these central nodes can use a
number of tools to control the media encoding provided by a WebRTC number of tools to control the media encoding provided by a WebRTC
end-point. This includes functions like requesting breaking the end-point. This includes functions like requesting breaking the
encoding chain and have the encoder produce a so called Intra encoding chain and have the encoder produce a so called Intra
frame. Another is limiting the bit-rate of a given stream to frame. Another is limiting the bit-rate of a given stream to
better suit the mixer view of the multiple down-streams. Others better suit the mixer view of the multiple down-streams. Others
are controlling the most suitable frame-rate, picture resolution, are controlling the most suitable frame-rate, picture resolution,
the trade-off between frame-rate and spatial quality. The the trade-off between frame-rate and spatial quality. The
middlebox gets the significant responsibility to correctly perform middlebox gets the significant responsibility to correctly perform
congestion control, source identification, manage synchronization congestion control, source identification, manage synchronisation
while providing the application with suitable media optimizations. while providing the application with suitable media optimizations.
The middlebox is also has to be a trusted node when it comes to The middlebox is also has to be a trusted node when it comes to
security, since it manipulates either the RTP header or the media security, since it manipulates either the RTP header or the media
itself (or both) received from one end-point, before sending it on itself (or both) received from one end-point, before sending it on
towards the end-point(s), thus they need to be able to decrypt and towards the end-point(s), thus they need to be able to decrypt and
then encrypt it before sending it out. then encrypt it before sending it out.
RTP Mixers can create a situation where an end-point experiences a RTP Mixers can create a situation where an end-point experiences a
situation in-between a session with only two end-points and situation in-between a session with only two end-points and
multiple RTP sessions. Mixers are expected to not forward RTCP multiple RTP sessions. Mixers are expected to not forward RTCP
skipping to change at page 30, line 8 skipping to change at page 30, line 31
visible to an end-point, all end-points will have knowledge about visible to an end-point, all end-points will have knowledge about
each others' master keys, and can thus inject packets claimed to each others' master keys, and can thus inject packets claimed to
come from another end-point in the session. Any node performing come from another end-point in the session. Any node performing
relay can perform non-cryptographic mitigation by preventing relay can perform non-cryptographic mitigation by preventing
forwarding of packets that have SSRC fields that came from other forwarding of packets that have SSRC fields that came from other
end-points before. For cryptographic verification of the source end-points before. For cryptographic verification of the source
SRTP would require additional security mechanisms, for example SRTP would require additional security mechanisms, for example
TESLA for SRTP [RFC4383], that are not part of the base WebRTC TESLA for SRTP [RFC4383], that are not part of the base WebRTC
standards. standards.
To forward media between multiple peers: It might be desirable for To forward media between multiple peers: It is sometimes desirable
an end-point that receives an RTP media stream to be able to for an end-point that receives an RTP media stream to be able to
forward that media stream to a third party. The are obvious forward that media stream to a third party. The are some obvious
security and privacy implications in this, but also potential security and privacy implications in supporting this, but also
uses. If it is to be allowed, there are two implementation potential uses. This is supported in the W3C API by taking the
strategies: either the browser can relay the flow at the RTP received and decoded media and using it as media source that is
layer, or it transcode and forward the media at the application re-encoding and transmitted as a new stream.
layer.
A relay approach will result in the RTP session be extended beyond
the PeerConnection, making both the original end-point and the
destination to which the media is forwarded part of the RTP
session. These end-points can have different path
characteristics, and hence different reception quality. Thus
sender's congestion control needs to be capable of handling this.
The security solution can either support mechanism that the sender
informs both receivers of the key; alternatively the end-point
that is forwarding the media needs to decrypt and then re-encrypt
using a new key. The relay based approach has the advantage that
the forwarding end-point does not need to transcode the media,
thus maintaining the quality of the encoding and reducing the
computational complexity requirements. If the right security
solutions are supported then the end-point that receives the
forwarded media will be able to verify the authenticity of the
media coming from the original sender. A downside is that the
original sender is forced to take both receivers into
consideration when delivering content.
The media transcoder approach is similar to having the forwarding At the RTP layer, media forwarding acts as a back-to-back RTP
end-point act as Mixer, terminating the RTP session, combined with receiver and RTP sender. The receiving side terminates the RTP
a transcoder. The original sender will only see a single receiver session and decodes the media, while the sender side re-encodes
of its media. The receiving end-point will responsible to produce and transmits the media using an entirely separate RTP session.
a RTP media stream suitable for onwards transmission. This might The original sender will only see a single receiver of the media,
require media transcoding for congestion control purpose to and will not be able to tell that forwarding is happening based on
produce a suitable bit-rate. Thus loosing media quality in the RTP-layer information since the RTP session that is used to send
transcoding and forcing the forwarding end-point to spend the the forwarded media is not connected to the RTP session on which
resource on the transcoding. The media transcoding does result in the media was received by the node doing the forwarding.
a separation of the two different legs removing almost all
dependencies, and allowing the forwarding end-point to optimize
its media transcoding operation. It also allows forwarding
without the original sender being aware of the forwarding. The
cost is greatly increased computational complexity on the
forwarding node.
(tbd: ought media forwarding be allowed?) The end-point that is performing the forwarding is responsible for
producing an RTP media stream suitable for onwards transmission.
The outgoing RTP session that is used to send the forwarded media
is entirely separate to the RTP session on which the media was
received. This will require media transcoding for congestion
control purpose to produce a suitable bit-rate for the outgoing
RTP session, reducing media quality and forcing the forwarding
end-point to spend the resource on the transcoding. The media
transcoding does result in a separation of the two different legs
removing almost all dependencies, and allowing the forwarding end-
point to optimize its media transcoding operation. The cost is
greatly increased computational complexity on the forwarding node.
Receivers of the forwarded stream will see the forwarding device
as the sender of the stream, and will not be able to tell from the
RTP layer that they are receiving a forwarded stream rather than
an entirely new media stream generated by the forwarding device.
12.1.3. Differentiated Treatment of Flows 12.1.3. Differentiated Treatment of Flows
There are use cases for differentiated treatment of RTP media There are use cases for differentiated treatment of RTP media
streams. Such differentiation can happen at several places in the streams. Such differentiation can happen at several places in the
system. First of all is the prioritization within the end-point system. First of all is the prioritization within the end-point
sending the media, which controls, both which RTP media streams that sending the media, which controls, both which RTP media streams that
will be sent, and their allocation of bit-rate out of the current will be sent, and their allocation of bit-rate out of the current
available aggregate as determined by the congestion control. available aggregate as determined by the congestion control.
skipping to change at page 32, line 15 skipping to change at page 32, line 27
differentiation. That way at least providing different differentiation. That way at least providing different
prioritization of audio and video if desired by application. prioritization of audio and video if desired by application.
DiffServ assumes that either the end-point or a classifier can mark DiffServ assumes that either the end-point or a classifier can mark
the packets with an appropriate DSCP so that the packets are treated the packets with an appropriate DSCP so that the packets are treated
according to that marking. If the end-point is to mark the traffic according to that marking. If the end-point is to mark the traffic
two requirements arise in the WebRTC context: 1) The WebRTC two requirements arise in the WebRTC context: 1) The WebRTC
application or browser has to know which DSCP to use and that it can application or browser has to know which DSCP to use and that it can
use them on some set of RTP media streams. 2) The information needs use them on some set of RTP media streams. 2) The information needs
to be propagated to the operating system when transmitting the to be propagated to the operating system when transmitting the
packet. These issues are discussed in DSCP and other packet markings packet. Details of this process are outside the scope of this memo
for RTCWeb QoS [I-D.dhesikan-tsvwg-rtcweb-qos]. and are further discussed in "DSCP and other packet markings for
RTCWeb QoS" [I-D.dhesikan-tsvwg-rtcweb-qos].
For packet based marking schemes it would be possible in the context For packet based marking schemes it might be possible to mark
to mark individual RTP packets differently based on the relative individual RTP packets differently based on the relative priority of
priority of the RTP payload. For example video codecs that has I,P the RTP payload. For example video codecs that have I, P, and B
and B pictures could prioritise any payloads carrying only B frames pictures could prioritise any payloads carrying only B frames less,
less, as these are less damaging to loose. But as default policy all as these are less damaging to loose. As default policy all RTP
RTP packets related to a media stream ought to be provided with the packets related to a media stream ought to be provided with the same
same prioritization. prioritization; per-packet prioritization is outside the scope of
this memo, but might be specified elsewhere in future.
It is also important to consider how RTCP packets associated with a It is also important to consider how RTCP packets associated with a
particular RTP media flow need to be marked. RTCP compound packets particular RTP media flow need to be marked. RTCP compound packets
with Sender Reports (SR), ought to be marked with the same priority with Sender Reports (SR), ought to be marked with the same priority
as the RTP media flow itself, so the RTCP-based round-trip time (RTT) as the RTP media flow itself, so the RTCP-based round-trip time (RTT)
measurements are done using the same flow priority as the media flow measurements are done using the same flow priority as the media flow
experiences. RTCP compound packets containing RR packet ought to be experiences. RTCP compound packets containing RR packet ought to be
sent with the priority used by the majority of the RTP media flows sent with the priority used by the majority of the RTP media flows
reported on. RTCP packets containing time-critical feedback packets reported on. RTCP packets containing time-critical feedback packets
can use higher priority to improve the timeliness and likelihood of can use higher priority to improve the timeliness and likelihood of
skipping to change at page 33, line 49 skipping to change at page 34, line 14
signalling message, there can be collisions. The Source-Specific SDP signalling message, there can be collisions. The Source-Specific SDP
Attributes [RFC5576] contains no mechanism to resolve SSRC collisions Attributes [RFC5576] contains no mechanism to resolve SSRC collisions
or reject a end-points usage of an SSRC. or reject a end-points usage of an SSRC.
There could also appear SSRC values that are not signalled. This is There could also appear SSRC values that are not signalled. This is
more likely than it appears as certain RTP functions need extra SSRCs more likely than it appears as certain RTP functions need extra SSRCs
to provide functionality related to another (the "main") SSRC, for to provide functionality related to another (the "main") SSRC, for
example, SSRC multiplexed RTP retransmission [RFC4588]. In those example, SSRC multiplexed RTP retransmission [RFC4588]. In those
cases, an end-point can create a new SSRC that strictly doesn't need cases, an end-point can create a new SSRC that strictly doesn't need
to be announced over the signalling channel to function correctly on to be announced over the signalling channel to function correctly on
both RTP and PeerConnection level. both RTP and RTCPeerConnection level.
The more likely case for SSRC collision is that multiple end-points The more likely case for SSRC collision is that multiple end-points
in a multiparty conference create new sources and signals those in a multiparty conference create new sources and signals those
towards the central server. In cases where the SSRC/CSRC are towards the central server. In cases where the SSRC/CSRC are
propagated between the different end-points from the central node propagated between the different end-points from the central node
collisions can occur. collisions can occur.
Another scenario is when the central node manages to connect an end- Another scenario is when the central node manages to connect an end-
point's PeerConnection to another PeerConnection the end-point point's RTCPeerConnection to another RTCPeerConnection the end-point
already has, thus forming a loop where the end-point will receive its already has, thus forming a loop where the end-point will receive its
own traffic. While is is clearly considered a bug, it is important own traffic. While is is clearly considered a bug, it is important
that the end-point is able to recognise and handle the case when it that the end-point is able to recognise and handle the case when it
occurs. This case becomes even more problematic when media mixers, occurs. This case becomes even more problematic when media mixers,
and so on, are involved, where the stream received is a different and so on, are involved, where the stream received is a different
stream but still contains this client's input. stream but still contains this client's input.
These SSRC/CSRC collisions can only be handled on RTP level as long These SSRC/CSRC collisions can only be handled on RTP level as long
as the same RTP session is extended across multiple PeerConnections as the same RTP session is extended across multiple
by a RTP middlebox. To resolve the more generic case where multiple RTCPeerConnections by a RTP middlebox. To resolve the more generic
PeerConnections are interconnected, then identification of the media case where multiple RTCPeerConnections are interconnected, then
source(s) part of a MediaStreamTrack being propagated across multiple identification of the media source(s) part of a MediaStreamTrack
interconnected PeerConnection needs to be preserved across these being propagated across multiple interconnected RTCPeerConnection
interconnections. needs to be preserved across these interconnections.
12.2.3. Media Synchronisation Context 12.2.3. Media Synchronisation Context
When an end-point sends media from more than one media source, it When an end-point sends media from more than one media source, it
needs to consider if (and which of) these media sources are to be needs to consider if (and which of) these media sources are to be
synchronized. In RTP/RTCP, synchronisation is provided by having a synchronized. In RTP/RTCP, synchronisation is provided by having a
set of RTP media streams be indicated as coming from the same set of RTP media streams be indicated as coming from the same
synchronisation context and logical end-point by using the same RTCP synchronisation context and logical end-point by using the same RTCP
CNAME identifier. CNAME identifier.
The next provision is that the internal clocks of all media sources, The next provision is that the internal clocks of all media sources,
i.e., what drives the RTP timestamp, can be correlated to a system i.e., what drives the RTP timestamp, can be correlated to a system
clock that is provided in RTCP Sender Reports encoded in an NTP clock that is provided in RTCP Sender Reports encoded in an NTP
format. By correlating all RTP timestamps to a common system clock format. By correlating all RTP timestamps to a common system clock
for all sources, the timing relation of the different RTP media for all sources, the timing relation of the different RTP media
streams, also across multiple RTP sessions can be derived at the streams, also across multiple RTP sessions can be derived at the
receiver and, if desired, the streams can be synchronized. The receiver and, if desired, the streams can be synchronized. The
requirement is for the media sender to provide the correlation requirement is for the media sender to provide the correlation
information; it is up to the receiver to use it or not. information; it is up to the receiver to use it or not.
12.2.4. Correlation of Media Streams
(tbd: this need to outline the approach to mapping media streams to
the signalling context defined in the unified plan)
(tbd: need to discuss correlation between associated RTP streams, for
example between a media stream and its associated FEC stream)
13. Security Considerations 13. Security Considerations
The overall security architecture for WebRTC is described in The overall security architecture for WebRTC is described in
[I-D.ietf-rtcweb-security-arch], and security considerations for the [I-D.ietf-rtcweb-security-arch], and security considerations for the
WebRTC framework are described in [I-D.ietf-rtcweb-security]. These WebRTC framework are described in [I-D.ietf-rtcweb-security]. These
considerations apply to this memo also. considerations apply to this memo also.
The security considerations of the RTP specification, the RTP/SAVPF The security considerations of the RTP specification, the RTP/SAVPF
profile, and the various RTP/RTCP extensions and RTP payload formats profile, and the various RTP/RTCP extensions and RTP payload formats
that form the complete protocol suite described in this memo apply. that form the complete protocol suite described in this memo apply.
skipping to change at page 36, line 4 skipping to change at page 36, line 6
extensions (Section 5.2.3). extensions (Section 5.2.3).
14. IANA Considerations 14. IANA Considerations
This memo makes no request of IANA. This memo makes no request of IANA.
Note to RFC Editor: this section is to be removed on publication as Note to RFC Editor: this section is to be removed on publication as
an RFC. an RFC.
15. Open Issues 15. Open Issues
This section contains a summary of the open issues or to be done This section contains a summary of the open issues or to be done
things noted in the document: things noted in the document:
1. tbd: The API mapping to RTP level concepts has to be agreed and 1. tbd: The discussion at IETF 88 confirmed that there is broad
documented in Section 11. This include both SSRC to API agreement to support simulcast, however the method for achieving
constructs, but also how different SSRC are related in this simulcast of a media source has to be decided.
context.
2. tbd: An open question if any requirements are needed to agree and
limit the number of simultaneously used media sources (SSRCs)
within an RTP session. See Section 4.1.
3. tbd: The method for achieving simulcast of a media source has to
be decided.
4. tbd: Possible documentation of what support for differentiated
treatment that are needed on RTP level as the API and the network
level specification matures as discussed in Section 12.1.3.
5. tbd: There are various reasons for having multiple SSRCs of the
same media type in the PeerConnections RTP session(s)
(Section 12.1.1). The signalling separating these cases needs
clarifications, preferably just by pointing to relevant
signalling section taking care of it. Related to Open Issue 1.
6. tbd: The section on usage of multiple RTP sessions
(Section 12.1.2) raised the question: ought media forwarding be
allowed?
16. Acknowledgements 16. Acknowledgements
The authors would like to thank Harald Alvestrand, Cary Bran, Charles The authors would like to thank Bernard Aboba, Harald Alvestrand,
Eckel, Cullen Jennings, Bernard Aboba, and the other members of the Cary Bran, Charles Eckel, Cullen Jennings, Dan Romascanu, and the
IETF RTCWEB working group for their valuable feedback. other members of the IETF RTCWEB working group for their valuable
feedback.
17. References 17. References
17.1. Normative References 17.1. Normative References
[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.
skipping to change at page 37, line 23 skipping to change at page 37, line 4
[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-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-10 (work in progress), September multiple-clock-rates-11 (work in progress), November
2013. 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-05 (work in progress), October 2013. bundle-negotiation-05 (work in progress), October 2013.
[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-
skipping to change at page 39, line 30 skipping to change at page 39, line 9
[RFC7007] Terriberry, T., "Update to Remove DVI4 from the [RFC7007] Terriberry, T., "Update to Remove DVI4 from the
Recommended Codecs for the RTP Profile for Audio and Video Recommended Codecs for the RTP Profile for Audio and Video
Conferences with Minimal Control (RTP/AVP)", RFC 7007, Conferences with Minimal Control (RTP/AVP)", RFC 7007,
August 2013. August 2013.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla,
"Guidelines for Choosing RTP Control Protocol (RTCP) "Guidelines for Choosing RTP Control Protocol (RTCP)
Canonical Names (CNAMEs)", RFC 7022, September 2013. Canonical Names (CNAMEs)", RFC 7022, September 2013.
17.2. Informative References [W3C.WD-mediacapture-streams-20130903]
Burnett, D., Bergkvist, A., Jennings, C., and A.
Narayanan, "Media Capture and Streams", World Wide Web
Consortium WD WD-mediacapture-streams-20130903, September
2013, <http://www.w3.org/TR/2013/
WD-mediacapture-streams-20130903>.
[I-D.alvestrand-rtcweb-msid] [W3C.WD-webrtc-20130910]
Alvestrand, H., "Cross Session Stream Identification in Bergkvist, A., Burnett, D., Jennings, C., and A.
the Session Description Protocol", draft-alvestrand- Narayanan, "WebRTC 1.0: Real-time Communication Between
rtcweb-msid-02 (work in progress), May 2012. Browsers", World Wide Web Consortium WD WD-
webrtc-20130910, September 2013,
<http://www.w3.org/TR/2013/WD-webrtc-20130910>.
17.2. Informative References
[I-D.dhesikan-tsvwg-rtcweb-qos] [I-D.dhesikan-tsvwg-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-dhesikan- other packet markings for RTCWeb QoS", draft-dhesikan-
tsvwg-rtcweb-qos-02 (work in progress), July 2013. tsvwg-rtcweb-qos-03 (work in progress), December 2013.
[I-D.ietf-avtcore-multiplex-guidelines] [I-D.ietf-avtcore-multiplex-guidelines]
Westerlund, M., Perkins, C., and H. Alvestrand, Westerlund, M., Perkins, C., and H. Alvestrand,
"Guidelines for using the Multiplexing Features of RTP to "Guidelines for using the Multiplexing Features of RTP to
Support Multiple Media Streams", draft-ietf-avtcore- Support Multiple Media Streams", draft-ietf-avtcore-
multiplex-guidelines-01 (work in progress), July 2013. multiplex-guidelines-01 (work in progress), July 2013.
[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-01 (work in progress),
April 2013. October 2013.
[I-D.ietf-mmusic-msid]
Alvestrand, H., "Cross Session Stream Identification in
the Session Description Protocol", draft-ietf-mmusic-
msid-02 (work in progress), November 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-08 (work based Applications", draft-ietf-rtcweb-overview-08 (work
in progress), September 2013. in progress), September 2013.
[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-12 (work in ietf-rtcweb-use-cases-and-requirements-12 (work in
progress), October 2013. progress), October 2013.
[I-D.jesup-rtp-congestion-reqs] [I-D.jesup-rtp-congestion-reqs]
Jesup, R. and H. Alvestrand, "Congestion Control Jesup, R. and H. Alvestrand, "Congestion Control
Requirements For Real Time Media", draft-jesup-rtp- Requirements For Real Time Media", draft-jesup-rtp-
congestion-reqs-00 (work in progress), March 2012. congestion-reqs-00 (work in progress), March 2012.
[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, "Multiplexing Multiple RTP
Single Lower-Layer Transport", draft-westerlund-avtcore- Sessions onto a Single Lower-Layer Transport", draft-
transport-multiplexing-06 (work in progress), August 2013. westerlund-avtcore-transport-multiplexing-07 (work in
progress), October 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
skipping to change at page 41, line 19 skipping to change at page 41, line 12
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control", RFC 5681, September 2009.
[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP
Control Protocol (RTCP)", RFC 5968, September 2010. Control Protocol (RTCP)", RFC 5968, September 2010.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
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
RTP Monitoring Framework", RFC 6792, November 2012.
Authors' Addresses Authors' Addresses
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
URI: http://csperkins.org/ URI: http://csperkins.org/
 End of changes. 52 change blocks. 
215 lines changed or deleted 266 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/