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/ |