--- 1/draft-ietf-rtcweb-rtp-usage-09.txt 2013-10-21 09:16:28.837319327 -0700 +++ 2/draft-ietf-rtcweb-rtp-usage-10.txt 2013-10-21 09:16:28.925321630 -0700 @@ -1,21 +1,21 @@ -RTCWEB Working Group C. S. Perkins +RTCWEB Working Group C. Perkins Internet-Draft University of Glasgow Intended status: Standards Track M. Westerlund -Expires: March 09, 2014 Ericsson +Expires: April 24, 2014 Ericsson J. Ott Aalto University - September 05, 2013 + October 21, 2013 Web Real-Time Communication (WebRTC): Media Transport and Use of RTP - draft-ietf-rtcweb-rtp-usage-09 + draft-ietf-rtcweb-rtp-usage-10 Abstract The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 09, 2014. + This Internet-Draft will expire on April 24, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -54,69 +54,69 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. WebRTC Use of RTP: Core Protocols . . . . . . . . . . . . . . 5 4.1. RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Choice of the RTP Profile . . . . . . . . . . . . . . . . 6 4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 7 - 4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 8 + 4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 9 4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 9 4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 10 4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 10 - 4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 10 + 4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 11 4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 11 - 5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 11 + 5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 12 5.1. Conferencing Extensions . . . . . . . . . . . . . . . . . 12 5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 13 5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 13 - 5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 13 - 5.1.4. Reference Picture Selection Indication (RPSI) . . . . 13 + 5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 14 + 5.1.4. Reference Picture Selection Indication (RPSI) . . . . 14 5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 14 5.1.6. Temporary Maximum Media Stream Bit Rate Request (TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 14 - 5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 14 + 5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 15 5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 15 - 5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 15 - 5.2.4. Associating RTP Media Streams and Signalling Contexts 15 - 6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 15 + 5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 16 + 5.2.4. Associating RTP Media Streams and Signalling Contexts 16 + 6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 16 6.1. Negative Acknowledgements and RTP Retransmission . . . . 16 6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 17 - 7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 17 + 7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 18 7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 18 7.2. RTCP Limitations for Congestion Control . . . . . . . . . 19 - 7.3. Congestion Control Interoperability and Legacy Systems . 19 - 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 20 + 7.3. Congestion Control Interoperability and Legacy Systems . 20 + 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 21 9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 21 - 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 21 + 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 22 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 23 - 12. RTP Implementation Considerations . . . . . . . . . . . . . . 23 + 12. RTP Implementation Considerations . . . . . . . . . . . . . . 24 12.1. Configuration and Use of RTP Sessions . . . . . . . . . 24 12.1.1. Use of Multiple Media Flows Within an RTP Session . 24 - 12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 25 - 12.1.3. Differentiated Treatment of Flows . . . . . . . . . 30 - 12.2. Source, Flow, and Participant Identification . . . . . . 31 - 12.2.1. Media Streams . . . . . . . . . . . . . . . . . . . 31 - 12.2.2. Media Streams: SSRC Collision Detection . . . . . . 32 - 12.2.3. Media Synchronisation Context . . . . . . . . . . . 33 + 12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 26 + 12.1.3. Differentiated Treatment of Flows . . . . . . . . . 31 + 12.2. Source, Flow, and Participant Identification . . . . . . 32 + 12.2.1. Media Streams . . . . . . . . . . . . . . . . . . . 32 + 12.2.2. Media Streams: SSRC Collision Detection . . . . . . 33 + 12.2.3. Media Synchronisation Context . . . . . . . . . . . 34 12.2.4. Correlation of Media Streams . . . . . . . . . . . . 34 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 - 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 35 + 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 - 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 17.1. Normative References . . . . . . . . . . . . . . . . . . 35 - 17.2. Informative References . . . . . . . . . . . . . . . . . 38 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 + 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 + 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 17.1. Normative References . . . . . . . . . . . . . . . . . . 36 + 17.2. Informative References . . . . . . . . . . . . . . . . . 39 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction The Real-time Transport Protocol (RTP) [RFC3550] provides a framework for delivery of audio and video teleconferencing data and other real- time media applications. Previous work has defined the RTP protocol, along with numerous profiles, payload formats, and other extensions. When combined with appropriate signalling, these form the basis for many teleconferencing systems. @@ -140,24 +140,22 @@ robustness to network problems, while Section 7 describes congestion control and rate adaptation mechanisms. The discussion of mandated RTP mechanisms concludes in Section 8 with a review of performance monitoring and network management tools that can be used in the WebRTC context. Section 9 gives some guidelines for future incorporation of other RTP and RTP Control Protocol (RTCP) extensions into this framework. Section 10 describes requirements placed on the signalling channel. Section 11 discusses the relationship between features of the RTP framework and the WebRTC application programming interface (API), and Section 12 discusses RTP implementation - considerations. This memo concludes with an appendix discussing - several different RTP Topologies, and how they affect the RTP - session(s) and various implementation details of possible realization - of central nodes. + considerations. The memo concludes with security considerations + (Section 13) and IANA considerations (Section 14). 2. Rationale The RTP framework comprises the RTP data transfer protocol, the RTP control protocol, and numerous RTP payload formats, profiles, and extensions. This range of add-ons has allowed RTP to meet various needs that were not envisaged by the original protocol designers, and to support many new media encodings, but raises the question of what extensions are to be supported by new implementations. The development of the WebRTC framework provides an opportunity for us to @@ -252,21 +250,23 @@ o Support for reception of RTP data packets containing CSRC lists, as generated by RTP mixers, and RTCP packets relating to CSRCs. o Support for sending correct synchronization information in the RTCP Sender Reports, to allow a receiver to implement lip-sync, with RECOMMENDED support for the rapid RTP synchronisation extensions (see Section 5.2.1). o Support for sending and receiving RTCP SR, RR, SDES, and BYE packet types, with OPTIONAL support for other RTCP packet types; - implementations MUST ignore unknown RTCP packet types. + implementations MUST ignore unknown RTCP packet types. Note that + additional RTCP Packet types are needed by the RTP/SAVPF Profile + (Section 4.2) and the other RTCP extensions (Section 5). o Support for multiple end-points in a single RTP session, and for scaling the RTCP transmission interval according to the number of participants in the session; support for randomised RTCP transmission intervals to avoid synchronisation of RTCP reports; support for RTCP timer reconsideration. o Support for configuring the RTCP bandwidth as a fraction of the media bandwidth, and for configuring the fraction of the RTCP bandwidth allocated to senders, e.g., using the SDP "b=" line. @@ -306,25 +306,25 @@ 4 seconds). The secure RTP profile [RFC3711] is needed to provide media encryption, integrity protection, replay protection and a limited form of source authentication. WebRTC implementations MUST NOT send packets using the basic RTP/AVP profile or the RTP/AVPF profile; they MUST employ the full RTP/SAVPF profile to protect all RTP and RTCP packets that are generated. The default and mandatory to implement transforms listed in Section 5 of [RFC3711] SHALL apply. - Implementations MUST support DTLS-SRTP [RFC5764] for key-management. - Other key management schemes MAY be supported. + The keying mechanism(s) to be used with the RTP/SAVPF profile are + defined in Section 5.5 of [I-D.ietf-rtcweb-security-arch] or its + replacement. 4.3. Choice of RTP Payload Formats - The set of mandatory to implement codecs and RTP payload formats for WebRTC is not specified in this memo. Implementations can support any codec for which an RTP payload format and associated signalling is defined. Implementation cannot assume that the other participants in an RTP session understand any RTP payload format, no matter how common; the mapping between RTP payload type numbers and specific configurations of particular RTP payload formats MUST be agreed before those payload types/formats can be used. In an SDP context, this can be done using the "a=rtpmap:" and "a=fmtp:" attributes associated with an "m=" line. @@ -401,21 +401,21 @@ sessions on a single transport-layer flow. This gives advantages in some gateway scenarios, and makes it easy to distinguish groups of RTP media streams that might need distinct processing. One way of doing this is described in [I-D.westerlund-avtcore-transport-multiplexing]. At the time of this writing, there is no consensus to use a shim-based approach in WebRTC implementations. Further discussion about when different RTP session structures and multiplexing methods are suitable can be found in - [I-D.westerlund-avtcore-multiplex-architecture]. + [I-D.ietf-avtcore-multiplex-guidelines]. 4.5. RTP and RTCP Multiplexing Historically, RTP and RTCP have been run on separate transport layer addresses (e.g., two UDP ports for each RTP session, one port for RTP and one port for RTCP). With the increased use of Network Address/ Port Translation (NAPT) this has become problematic, since maintaining multiple NAT bindings can be costly. It also complicates firewall administration, since multiple ports need to be opened to allow RTP traffic. To reduce these costs and session set-up times, @@ -496,21 +495,27 @@ 4.9. Generation of the RTCP Canonical Name (CNAME) The RTCP Canonical Name (CNAME) provides a persistent transport-level identifier for an RTP endpoint. While the Synchronisation Source (SSRC) identifier for an RTP endpoint can change if a collision is detected, or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams within a set of related RTP sessions. For proper functionality, each RTP endpoint - needs to have a unique RTCP CNAME value. + needs to have at least one unique RTCP CNAME value. An endpoint MAY + have multiple CNAMEs, as the CNAME also identifies a particular + synchronization context, i.e. all SSRC associated with a CNAME share + a common reference clock, and if an endpoint have SSRCs associated + with different reference clocks it will need to use multiple CNAMEs. + 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. The RTP specification [RFC3550] includes guidelines for choosing a unique RTP CNAME, but these are not sufficient in the presence of NAT devices. In addition, long-term persistent identifiers can be problematic from a privacy viewpoint. Accordingly, support for generating a short-term persistent RTCP CNAMEs following [RFC7022] is RECOMMENDED. An WebRTC end-point MUST support reception of any CNAME that matches the syntax limitations specified by the RTP specification [RFC3550] @@ -717,21 +722,21 @@ these extra bits needs to be considered, and the aggregate bit-rate MUST be rate controlled to avoid causing network congestion (see Section 7). As a result, improving robustness might require a lower base encoding quality, but has the potential to deliver that quality with fewer errors. The mechanisms described in the following sub- sections can be used to improve tolerance to packet loss. 6.1. Negative Acknowledgements and RTP Retransmission As a consequence of supporting the RTP/SAVPF profile, implementations - will support negative acknowledgements (NACKs) for RTP data packets + can support negative acknowledgements (NACKs) for RTP data packets [RFC4585]. This feedback can be used to inform a sender of the loss of particular RTP packets, subject to the capacity limitations of the RTCP feedback channel. A sender can use this information to optimise the user experience by adapting the media encoding to compensate for known lost packets, for example. Senders are REQUIRED to understand the Generic NACK message defined in Section 6.2.1 of [RFC4585], but MAY choose to ignore this feedback (following Section 4.2 of [RFC4585]). Receivers MAY send NACKs for missing RTP packets; [RFC4585] provides some guidelines on when to @@ -756,21 +761,21 @@ appropriate to blindly retransmit RTP packets in response to a NACK. The importance of lost packets and the likelihood of them arriving in time to be useful needs to be considered before RTP retransmission is used. Receivers are REQUIRED to implement support for RTP retransmission packets [RFC4588]. Senders MAY send RTP retransmission packets in response to NACKs if the RTP retransmission payload format has been negotiated for the session, and if the sender believes it is useful to send a retransmission of the packet(s) referenced in the NACK. An - RTP sender is not expected to retransmit every NACKed packet. + RTP sender does not need to retransmit every NACKed packet. 6.2. Forward Error Correction (FEC) The use of Forward Error Correction (FEC) can provide an effective protection against some degree of packet loss, at the cost of steady bandwidth overhead. There are several FEC schemes that are defined for use with RTP. Some of these schemes are specific to a particular RTP payload format, others operate across RTP packets and can be used with any payload format. It needs to be noted that using redundant encoding or FEC will lead to increased play out delay, which needs to @@ -794,21 +799,21 @@ WebRTC will be used in heterogeneous network environments using a variety set of link technologies, including both wired and wireless links, to interconnect potentially large groups of users around the world. As a result, the network paths between users can have widely varying one-way delays, available bit-rates, load levels, and traffic mixtures. Individual end-points can send one or more RTP media streams to each participant in a WebRTC conference, and there can be several participants. Each of these RTP media streams can contain different types of media, and the type of media, bit rate, and number of flows can be highly asymmetric. Non-RTP traffic can share the - network paths RTP flows. Since the network environment is not + network paths with RTP flows. Since the network environment is not predictable or stable, WebRTC endpoints MUST ensure that the RTP traffic they generate can adapt to match changes in the available network capacity. The quality of experience for users of WebRTC implementation is very dependent on effective adaptation of the media to the limitations of the network. End-points have to be designed so they do not transmit significantly more data than the network path can support, except for very short time periods, otherwise high levels of network packet loss or delay spikes will occur, causing media quality degradation. The @@ -823,25 +828,28 @@ be used for interactive media applications such as WebRTC flows. Some requirements for congestion control algorithms for WebRTC sessions are discussed in [I-D.jesup-rtp-congestion-reqs], and it is expected that a future version of this memo will mandate the use of a congestion control algorithm that satisfies these requirements. 7.1. Boundary Conditions and Circuit Breakers In the absence of a concrete congestion control algorithm, all WebRTC implementations MUST implement the RTP circuit breaker algorithm that - is in described [I-D.ietf-avtcore-rtp-circuit-breakers]. The circuit - breaker defines a conservative boundary condition for safe operation, - chosen such that applications that trigger the circuit breaker will - almost certainly be causing severe network congestion. Any future - RTP congestion control algorithms are expected to operate within the + is in described [I-D.ietf-avtcore-rtp-circuit-breakers]. The RTP + circuit breaker is designed to enable applications to recognise and + react to situations of extreme network congestion. However, since + the RTP circuit breaker might not be triggered until congestion + becomes extreme, it cannot be considered a substitute for congestion + control, and applications MUST also implement congestion control to + allow them to adapt to changes in network capacity. Any future RTP + congestion control algorithms are expected to operate within the envelope allowed by the circuit breaker. The session establishment signalling will also necessarily establish boundaries to which the media bit-rate will conform. The choice of media codecs provides upper- and lower-bounds on the supported bit- rates that the application can utilise to provide useful quality, and the packetization choices that exist. In addition, the signalling channel can establish maximum media bit-rate boundaries using the SDP "b=AS:" or "b=CT:" lines, and the RTP/AVPF Temporary Maximum Media Stream Bit Rate (TMMBR) Requests (see Section 5.1.6 of this memo). @@ -1173,44 +1181,58 @@ discussed further in Section 12.1.3. To separate media with different purposes: An end-point might want to send media streams that have different purposes on different RTP sessions, to make it easy for the peer device to distinguish them. For example, some centralised multiparty conferencing systems display the active speaker in high resolution, but show low resolution "thumbnails" of other participants. Such systems might configure the end-points to send simulcast high- and low- resolution versions of their video using separate RTP sessions, to - simplify the operation of the central mixer In the WebRTC context - this appears to be most easily accomplished by establishing - multiple PeerConnection all being feed the same set of WebRTC - MediaStreams. Each PeerConnection is then configured to deliver a - particular media quality and thus media bit-rate, and will produce - an independently encoded version with the codec parameters agreed - specifically in the context of that PeerConnection. The central - mixer can always distinguish packets corresponding to the low- and - high-resolution streams by inspecting their SSRC, RTP payload - type, or some other information contained in RTP header extensions - or RTCP packets, but it can be easier to distinguish the flows if - they arrive on separate RTP sessions on separate UDP ports. + simplify the operation of the central mixer. In the WebRTC + context this appears to be most easily accomplished by + establishing multiple PeerConnection all being feed the same set + of WebRTC MediaStreams. Each PeerConnection is then configured to + deliver a particular media quality and thus media bit-rate, and + will produce an independently encoded version with the codec + parameters agreed specifically in the context of that + PeerConnection. The central mixer can always distinguish packets + corresponding to the low- and high-resolution streams by + inspecting their SSRC, RTP payload type, or some other information + contained in RTP header extensions or RTCP packets, but it can be + easier to distinguish the flows if they arrive on separate RTP + sessions on separate UDP ports. To directly connect with multiple peers: A multi-party conference does not need to use a central mixer. Rather, a multi-unicast mesh can be created, comprising several distinct RTP sessions, with each participant sending RTP traffic over a separate RTP - session (that is, using an independent an PeerConnection object) - to every other participant, as shown in Figure 1. This topology - has the benefit of not requiring a central mixer node that is - trusted to access and manipulate the media data. The downside is - that it increases the used bandwidth at each sender by requiring - one copy of the RTP media streams for each participant that are - part of the same session beyond the sender itself. + session (that is, using an independent PeerConnection object) to + every other participant, as shown in Figure 1. This topology has + the benefit of not requiring a central mixer node that is trusted + to access and manipulate the media data. The downside is that it + increases the used bandwidth at each sender by requiring one copy + of the RTP media streams for each participant that are part of the + same session beyond the sender itself. + + +---+ +---+ + | A |<--->| B | + +---+ +---+ + ^ ^ + \ / + \ / + v v + +---+ + | C | + +---+ + + Figure 1: Multi-unicast using several RTP sessions The multi-unicast topology could also be implemented as a single RTP session, spanning multiple peer-to-peer transport layer connections, or as several pairwise RTP sessions, one between each pair of peers. To maintain a coherent mapping between the relation between RTP sessions and PeerConnection objects we recommend that this is implemented as several individual RTP sessions. The only downside is that end-point A will not learn of 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, @@ -1231,20 +1253,31 @@ To indirectly connect with multiple peers: A common scenario in multi-party conferencing is to create indirect connections to multiple peers, using an RTP mixer, translator, or some other type of RTP middlebox. Figure 2 outlines a simple topology that might be used in a four-person centralised conference. The middlebox acts to optimise the transmission of RTP media streams from 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 out of a set of contributing streams. + +---+ +-------------+ +---+ + | A |<---->| |<---->| B | + +---+ | RTP mixer, | +---+ + | translator, | + | or other | + +---+ | middlebox | +---+ + | C |<---->| |<---->| D | + +---+ +-------------+ +---+ + + Figure 2: RTP mixer with only unicast paths + There are various methods of implementation for the middlebox. If implemented as a standard RTP mixer or translator, a single RTP session will extend across the middlebox and encompass all the end-points in one multi-party session. Other types of middlebox might use separate RTP sessions between each end-point and the middlebox. A common aspect is that these central nodes can use a number of tools to control the media encoding provided by a WebRTC end-point. This includes functions like requesting breaking the encoding chain and have the encoder produce a so called Intra frame. Another is limiting the bit-rate of a given stream to @@ -1329,44 +1362,20 @@ 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. 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?) - +---+ +---+ - | A |<--->| B | - +---+ +---+ - ^ ^ - \ / - \ / - v v - +---+ - | C | - +---+ - - Figure 1: Multi-unicast using several RTP sessions - - +---+ +-------------+ +---+ - | A |<---->| |<---->| B | - +---+ | RTP mixer, | +---+ - | translator, | - | or other | - +---+ | middlebox | +---+ - | C |<---->| |<---->| D | - +---+ +-------------+ +---+ - - Figure 2: RTP mixer with only unicast paths - 12.1.3. Differentiated Treatment of Flows There are use cases for differentiated treatment of RTP media streams. Such differentiation can happen at several places in the system. First of all is the prioritization within the end-point sending the media, which controls, both which RTP media streams that will be sent, and their allocation of bit-rate out of the current available aggregate as determined by the congestion control. It is expected that the WebRTC API will allow the application to @@ -1411,21 +1420,21 @@ prioritization of audio and video if desired by application. DiffServ assumes that either the end-point or a classifier can mark 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 two requirements arise in the WebRTC context: 1) The WebRTC 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 to be propagated to the operating system when transmitting the packet. These issues are discussed in DSCP and other packet markings - for RTCWeb QoS [I-D.ietf-rtcweb-qos]. + for RTCWeb QoS [I-D.dhesikan-tsvwg-rtcweb-qos]. For packet based marking schemes it would be possible in the context to mark individual RTP packets differently based on the relative priority of the RTP payload. For example video codecs that has I,P and B pictures could prioritise any payloads carrying only B frames less, as these are less damaging to loose. But as default policy all RTP packets related to a media stream ought to be provided with the same prioritization. It is also important to consider how RTCP packets associated with a @@ -1561,21 +1569,23 @@ The security considerations of the RTP specification, the RTP/SAVPF profile, and the various RTP/RTCP extensions and RTP payload formats that form the complete protocol suite described in this memo apply. We do not believe there are any new security considerations resulting from the combination of these various protocol extensions. The Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback [RFC5124] (RTP/SAVPF) provides handling of fundamental issues by offering confidentiality, integrity and partial source authentication. A mandatory to implement media - security solution is (tbd). + security solution is created by combing this secured RTP profile and + DTLS-SRTP keying [RFC5764] as defined by Section 5.5 of + [I-D.ietf-rtcweb-security-arch]. RTCP packets convey a Canonical Name (CNAME) identifier that is used to associate media flows that need to be synchronised across related RTP sessions. Inappropriate choice of CNAME values can be a privacy concern, since long-term persistent CNAME identifiers can be used to track users across multiple WebRTC calls. Section 4.9 of this memo provides guidelines for generation of untraceable CNAME values that alleviate this risk. The guidelines in [RFC6562] apply when using variable bit rate (VBR) @@ -1586,38 +1596,49 @@ extensions (Section 5.2.3). 14. IANA Considerations This memo makes no request of IANA. Note to RFC Editor: this section is to be removed on publication as an RFC. 15. Open Issues - This section contains a summary of the open issues or to be done things noted in the document: 1. tbd: The API mapping to RTP level concepts has to be agreed and - documented in Section 11. + documented in Section 11. This include both SSRC to API + constructs, but also how different SSRC are related in this + 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 The authors would like to thank Harald Alvestrand, Cary Bran, Charles Eckel, Cullen Jennings, Bernard Aboba, and the other members of the IETF RTCWEB working group for their valuable feedback. 17. References 17.1. Normative References @@ -1627,42 +1648,43 @@ ietf-avtcore-multi-media-rtp-session-03 (work in progress), July 2013. [I-D.ietf-avtcore-rtp-circuit-breakers] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", draft-ietf- avtcore-rtp-circuit-breakers-03 (work in progress), July 2013. [I-D.ietf-avtcore-rtp-multi-stream-optimisation] - Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, + Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback ", draft-ietf-avtcore-rtp-multi-stream-optimisation-00 (work in progress), July 2013. [I-D.ietf-avtcore-rtp-multi-stream] Lennox, J., Westerlund, M., Wu, W., and C. Perkins, "Sending Multiple Media Streams in a Single RTP Session", draft-ietf-avtcore-rtp-multi-stream-01 (work in progress), July 2013. [I-D.ietf-avtext-multiple-clock-rates] Petit-Huguenin, M. and G. Zorn, "Support for Multiple Clock Rates in an RTP Session", draft-ietf-avtext- - multiple-clock-rates-09 (work in progress), April 2013. + multiple-clock-rates-10 (work in progress), September + 2013. [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- - bundle-negotiation-04 (work in progress), June 2013. + bundle-negotiation-05 (work in progress), October 2013. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-07 (work in progress), July 2013. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-05 (work in progress), July 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate @@ -1750,57 +1772,52 @@ "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, September 2013. 17.2. Informative References [I-D.alvestrand-rtcweb-msid] Alvestrand, H., "Cross Session Stream Identification in the Session Description Protocol", draft-alvestrand- rtcweb-msid-02 (work in progress), May 2012. - [I-D.ietf-avt-srtp-ekt] - Wing, D., McGrew, D., and K. Fischer, "Encrypted Key - Transport for Secure RTP", draft-ietf-avt-srtp-ekt-03 - (work in progress), October 2011. + [I-D.dhesikan-tsvwg-rtcweb-qos] + Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and + other packet markings for RTCWeb QoS", draft-dhesikan- + tsvwg-rtcweb-qos-02 (work in progress), July 2013. + + [I-D.ietf-avtcore-multiplex-guidelines] + Westerlund, M., Perkins, C., and H. Alvestrand, + "Guidelines for using the Multiplexing Features of RTP to + Support Multiple Media Streams", draft-ietf-avtcore- + multiplex-guidelines-01 (work in progress), July 2013. [I-D.ietf-avtcore-rtp-topologies-update] Westerlund, M. and S. Wenger, "RTP Topologies", draft- ietf-avtcore-rtp-topologies-update-00 (work in progress), April 2013. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Brower- based Applications", draft-ietf-rtcweb-overview-08 (work in progress), September 2013. - [I-D.ietf-rtcweb-qos] - Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and - other packet markings for RTCWeb QoS", draft-ietf-rtcweb- - qos-00 (work in progress), October 2012. - [I-D.ietf-rtcweb-use-cases-and-requirements] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use-cases and Requirements", draft- - ietf-rtcweb-use-cases-and-requirements-11 (work in - progress), June 2013. + ietf-rtcweb-use-cases-and-requirements-12 (work in + progress), October 2013. [I-D.jesup-rtp-congestion-reqs] Jesup, R. and H. Alvestrand, "Congestion Control Requirements For Real Time Media", draft-jesup-rtp- congestion-reqs-00 (work in progress), March 2012. - [I-D.westerlund-avtcore-multiplex-architecture] - Westerlund, M., Perkins, C., and H. Alvestrand, - "Guidelines for using the Multiplexing Features of RTP", - draft-westerlund-avtcore-multiplex-architecture-03 (work - in progress), February 2013. - [I-D.westerlund-avtcore-transport-multiplexing] Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a Single Lower-Layer Transport", draft-westerlund-avtcore- transport-multiplexing-06 (work in progress), August 2013. [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion @@ -1841,20 +1858,21 @@ Authors' Addresses Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom Email: csp@csperkins.org + URI: http://csperkins.org/ Magnus Westerlund Ericsson Farogatan 6 SE-164 80 Kista Sweden Phone: +46 10 714 82 87 Email: magnus.westerlund@ericsson.com