--- 1/draft-ietf-rtcweb-rtp-usage-23.txt 2015-05-29 02:15:02.954918107 -0700 +++ 2/draft-ietf-rtcweb-rtp-usage-24.txt 2015-05-29 02:15:03.054920534 -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: October 01, 2015 Ericsson +Expires: November 30, 2015 Ericsson J. Ott Aalto University - March 30, 2015 + May 29, 2015 Web Real-Time Communication (WebRTC): Media Transport and Use of RTP - draft-ietf-rtcweb-rtp-usage-23 + draft-ietf-rtcweb-rtp-usage-24 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 October 01, 2015. + This Internet-Draft will expire on November 30, 2015. Copyright Notice Copyright (c) 2015 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 . . . . . . . . . . . . . . . . 7 4.3. Choice of RTP Payload Formats . . . . . . . . . . . . . . 8 - 4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 10 + 4.4. Use of RTP Sessions . . . . . . . . . . . . . . . . . . . 9 4.5. RTP and RTCP Multiplexing . . . . . . . . . . . . . . . . 10 4.6. Reduced Size RTCP . . . . . . . . . . . . . . . . . . . . 11 4.7. Symmetric RTP/RTCP . . . . . . . . . . . . . . . . . . . 11 - 4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 12 + 4.8. Choice of RTP Synchronisation Source (SSRC) . . . . . . . 11 4.9. Generation of the RTCP Canonical Name (CNAME) . . . . . . 12 4.10. Handling of Leap Seconds . . . . . . . . . . . . . . . . 13 5. WebRTC Use of RTP: Extensions . . . . . . . . . . . . . . . . 13 5.1. Conferencing Extensions and Topologies . . . . . . . . . 13 5.1.1. Full Intra Request (FIR) . . . . . . . . . . . . . . 15 5.1.2. Picture Loss Indication (PLI) . . . . . . . . . . . . 15 - 5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 16 + 5.1.3. Slice Loss Indication (SLI) . . . . . . . . . . . . . 15 5.1.4. Reference Picture Selection Indication (RPSI) . . . . 16 5.1.5. Temporal-Spatial Trade-off Request (TSTR) . . . . . . 16 5.1.6. Temporary Maximum Media Stream Bit Rate Request (TMMBR) . . . . . . . . . . . . . . . . . . . . . . . 16 - 5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 17 + 5.2. Header Extensions . . . . . . . . . . . . . . . . . . . . 16 5.2.1. Rapid Synchronisation . . . . . . . . . . . . . . . . 17 5.2.2. Client-to-Mixer Audio Level . . . . . . . . . . . . . 17 5.2.3. Mixer-to-Client Audio Level . . . . . . . . . . . . . 18 5.2.4. Media Stream Identification . . . . . . . . . . . . . 18 5.2.5. Coordination of Video Orientation . . . . . . . . . . 18 - 6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 19 + 6. WebRTC Use of RTP: Improving Transport Robustness . . . . . . 18 6.1. Negative Acknowledgements and RTP Retransmission . . . . 19 6.2. Forward Error Correction (FEC) . . . . . . . . . . . . . 20 7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 20 7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 21 - 7.2. Congestion Control Interoperability and Legacy Systems . 22 - 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 23 - 9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 23 - 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 24 - 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 25 + 7.2. Congestion Control Interoperability and Legacy Systems . 21 + 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22 + 9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 22 + 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 23 + 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 24 12. RTP Implementation Considerations . . . . . . . . . . . . . . 27 - 12.1. Configuration and Use of RTP Sessions . . . . . . . . . 28 - 12.1.1. Use of Multiple Media Sources Within an RTP Session 28 - 12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 29 + 12.1. Configuration and Use of RTP Sessions . . . . . . . . . 27 + 12.1.1. Use of Multiple Media Sources Within an RTP Session 27 + 12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 28 12.1.3. Differentiated Treatment of RTP Packet Streams . . . 33 12.2. Media Source, RTP Packet Streams, and Participant Identification . . . . . . . . . . . . . . . . . . . . . 35 12.2.1. Media Source Identification . . . . . . . . . . . . 35 12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 36 12.2.3. Media Synchronisation Context . . . . . . . . . . . 37 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 38 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 37 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 16.1. Normative References . . . . . . . . . . . . . . . . . . 40 - 16.2. Informative References . . . . . . . . . . . . . . . . . 43 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 16.1. Normative References . . . . . . . . . . . . . . . . . . 39 + 16.2. Informative References . . . . . . . . . . . . . . . . . 42 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 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. @@ -160,22 +160,21 @@ development of the WebRTC framework provides an opportunity to review the available RTP features and extensions, and to define a common baseline RTP feature set for all WebRTC Endpoints. This builds on the past 20 years development of RTP to mandate the use of extensions that have shown widespread utility, while still remaining compatible with the wide installed base of RTP implementations where possible. RTP and RTCP extensions that are not discussed in this document can be implemented by WebRTC Endpoints if they are beneficial for new use cases. However, they are not necessary to address the WebRTC use - cases and requirements identified in - [I-D.ietf-rtcweb-use-cases-and-requirements]. + cases and requirements identified in [RFC7478]. While the baseline set of RTP features and extensions defined in this memo is targeted at the requirements of the WebRTC framework, it is expected to be broadly useful for other conferencing-related uses of RTP. In particular, it is likely that this set of RTP features and extensions will be appropriate for other desktop or mobile video conferencing systems, or for room-based high-quality telepresence applications. 3. Terminology @@ -279,26 +278,26 @@ support for RTCP timer reconsideration (Section 6.3.6 of [RFC3550]) and reverse reconsideration (Section 6.3.4 of [RFC3550]). 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 [RFC4566][RFC3556]. o Support for the reduced minimum RTCP reporting interval described - in Section 6.2 of [RFC3550] is REQUIRED. When using the reduced - minimum RTCP reporting interval, the fixed (non-reduced) minimum - interval MUST be used when calculating the participant timeout - interval (see Sections 6.2 and 6.3.5 of [RFC3550]). The delay - before sending the initial compound RTCP packet can be set to zero - (see Section 6.2 of [RFC3550] as updated by + in Section 6.2 of [RFC3550]. When using the reduced minimum RTCP + reporting interval, the fixed (non-reduced) minimum interval MUST + be used when calculating the participant timeout interval (see + Sections 6.2 and 6.3.5 of [RFC3550]). The delay before sending + the initial compound RTCP packet can be set to zero (see + Section 6.2 of [RFC3550] as updated by [I-D.ietf-avtcore-rtp-multi-stream]). o Support for discontinuous transmission. RTP allows endpoints to pause and resume transmission at any time. When resuming, the RTP sequence number will increase by one, as usual, while the increase in the RTP timestamp value will depend on the duration of the pause. Discontinuous transmission is most commonly used with some audio payload formats, but is not audio specific, and can be used with any RTP payload format. @@ -741,21 +741,21 @@ temporal and spatial resolution, for example to prefer high spatial image quality but low frame rate. Support for TSTR requests and notifications is OPTIONAL. 5.1.6. Temporary Maximum Media Stream Bit Rate Request (TMMBR) The TMMBR feedback message is defined in Sections 3.5.4 and 4.2.1 of the Codec Control Messages [RFC5104]. This request and its notification message are used by a media receiver to inform the sending party that there is a current limitation on the amount of - bandwidth available to this receiver. This can be various reasons + bandwidth available to this receiver. There can be various reasons for this: for example, an RTP mixer can use this message to limit the media rate of the sender being forwarded by the mixer (without doing media transcoding) to fit the bottlenecks existing towards the other session participants. WebRTC Endpoints that are sending media are REQUIRED to implement support for TMMBR messages, and MUST follow bandwidth limitations set by a TMMBR message received for their SSRC. The sending of TMMBR requests is OPTIONAL. 5.2. Header Extensions @@ -952,22 +952,23 @@ bandwidth, or it might be competition with other traffic on the link (this can be non-WebRTC traffic, traffic due to other WebRTC flows, or even competition with other WebRTC flows in the same session). An effective media congestion control algorithm is therefore an essential part of the WebRTC framework. However, at the time of this writing, there is no standard congestion control algorithm that can be used for interactive media applications such as WebRTC's flows. Some requirements for congestion control algorithms for RTCPeerConnections are discussed in [I-D.ietf-rmcat-cc-requirements]. - A future version of this memo will mandate the use of a congestion - control algorithm that satisfies these requirements. + If a standardized congestion control algorithm that satisfies these + requirements is developed in the future, this memo will need to be be + updated to mandate its use. 7.1. Boundary Conditions and Circuit Breakers WebRTC Endpoints MUST implement the RTP circuit breaker algorithm that is described in [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 @@ -979,21 +980,21 @@ 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 packetisation choices that exist. In addition, the signalling channel can establish maximum media bit-rate boundaries using, for example, 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). Signalled bandwidth limitations, such as SDP "b=AS:" or "b=CT:" lines received from the peer, MUST be followed when sending RTP packet streams. A WebRTC Endpoint receiving media SHOULD signal - its bandwidth limitations, these limitations have to be based on + its bandwidth limitations. These limitations have to be based on known bandwidth limitations, for example the capacity of the edge links. 7.2. Congestion Control Interoperability and Legacy Systems All endpoints that wish to interwork with WebRTC MUST implement RTCP and provide congestion feedback via the defined RTCP reporting mechanisms. When interworking with legacy implementations that support RTCP using @@ -1084,22 +1085,22 @@ signalled. Interworking functions might transform this into the RTP/SAVP profile for a legacy use case, by indicating to the WebRTC Endpoint that the RTP/SAVPF is used and configuring a trr- int value of 4 seconds. Transport Information: Source and destination IP address(s) and ports for RTP and RTCP MUST be signalled for each RTP session. In WebRTC these transport addresses will be provided by ICE [RFC5245] that signals candidates and arrives at nominated candidate address pairs. If RTP and RTCP multiplexing [RFC5761] is to be used, such - that a single port, i.e. transport-layer flow, is used for RTP - and RTCP flows, this MUST be signalled (see Section 4.5). + that a single port, i.e. transport-layer flow, is used for RTP and + RTCP flows, this MUST be signalled (see Section 4.5). RTP Payload Types, media formats, and format parameters: The mapping between media type names (and hence the RTP payload formats to be used), and the RTP payload type numbers MUST be signalled. Each media type MAY also have a number of media type parameters that MUST also be signalled to configure the codec and RTP payload format (the "a=fmtp:" line from SDP). Section 4.3 of this memo discusses requirements for uniqueness of payload types. RTP Extensions: The use of any additional RTP header extensions and @@ -1115,23 +1116,23 @@ RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the end-points will be necessary. This SHALL be done as described in "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or something semantically equivalent. This also ensures that the end-points have a common view of the RTCP bandwidth. A common RTCP bandwidth is important as a too different view of the bandwidths can lead to failure to interoperate. These parameters are often expressed in SDP messages conveyed within - 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 - agreed upon, and provided to the RTP implementation. Note that in + 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 agreed upon, and provided to the RTP implementation. Note that in WebRTC it will depend on the signalling model and API how these parameters need to be configured but they will be need to either be set in the API or explicitly signalled between the peers. 11. WebRTC API Considerations The WebRTC API [W3C.WD-webrtc-20130910] and the Media Capture and Streams API [W3C.WD-mediacapture-streams-20130903] defines and uses the concept of a MediaStream that consists of zero or more MediaStreamTracks. A MediaStreamTrack is an individual stream of @@ -1187,50 +1188,49 @@ RTCPeerConnection instances, as specified in Section 4.9. Having two communication sessions with the same CNAME could enable tracking of a user or device across different services (see Section 4.4.1 of [I-D.ietf-rtcweb-security] for details). A web application can request that the CNAMEs used in different RTCPeerConnections (within a same-orign context) be the same, this allows for synchronization of the endpoint's RTP packet streams across the different RTCPeerConnections. Note: this doesn't result in a tracking issue, since the creation - of matching CNAMEs depends on existing tracking. + of matching CNAMEs depends on existing tracking within a single + origin. The above will currently force a WebRTC Endpoint that receives a 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 to the one it - uses, which implies that the sender has to use a local 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 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. + Since the sending party needs to change the CNAME to the one it uses, + this implies it has to use a local 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 be 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 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 is to allow for forward compatibility with any future changes that - enables more efficient stream handling when end-points relay/ + enable more efficient stream handling when end-points relay/ forward streams. It also ensures that end-points can interoperate with certain types of multi-stream middleboxes or end-points 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. This later is relevant to handle some cases of legacy @@ -1543,55 +1544,67 @@ streams is dependent on the media type and codec used, in regards to how robust that codec is to packet loss. However, a default policy might to be to use the same priority for redundant RTP packet stream as for the source RTP packet stream. Secondly, the network can prioritize transport-layer flows and sub- flows, including RTP packet streams. Typically, differential treatment includes two steps, the first being identifying whether an IP packet belongs to a class that has to be treated differently, the second consisting of the actual mechanism to prioritize packets. - This is done according to three methods: + Three common methods for classifying IP packets are: DiffServ: The end-point marks a packet with a DiffServ code point to indicate to the network that the packet belongs to a particular class. Flow based: Packets that need to be given a particular treatment are identified using a combination of IP and port address. Deep Packet Inspection: A network classifier (DPI) inspects the packet and tries to determine if the packet represents a particular application and type that is to be prioritized. Flow-based differentiation will provide the same treatment to all packets within a transport-layer flow, i.e., relative prioritization is not possible. Moreover, if the resources are limited it might not be possible to provide differential treatment compared to best-effort - for all the RTP packet streams used in a WebRTC session. When flow- - based differentiation is available, the WebRTC Endpoint needs to know - about it so that it can provide the separation of the RTP packet - streams onto different UDP flows to enable a more granular usage of - flow based differentiation. That way at least providing different - prioritization of audio and video if desired by application. + for all the RTP packet streams used in a WebRTC session. The use of + flow-based differentiation needs to be coordinated between the WebRTC + system and the network(s). The WebRTC endpoint needs to know that + flow-based differentiation might be used to provide the separation of + the RTP packet streams onto different UDP flows to enable a more + granular usage of flow based differentiation. The used flows, their + 5-tuples and prioritization will need to be communicated to the + network so that it can identify the flows correctly to enable + prioritization. No specific protocol support for this is specified. 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 Endpoint has to know which DSCP to use and that it can use them on some set of RTP packet streams. 2) The information needs to be propagated to the operating system when transmitting the packet. Details of this process are outside the scope of this memo and are further discussed in "DSCP and other packet markings for RTCWeb QoS" [I-D.ietf-tsvwg-rtcweb-qos]. + Deep Packet Inspectors will, despite the SRTP media encryption, still + be fairly capable at classifying the RTP streams. The reason is that + SRTP leaves the first 12 bytes of the RTP header unencrypted. This + enables easy RTP stream identification using the SSRC and provides + the classifier with useful information that can be correlated to + determine for example the stream's media type. Using packet sizes, + reception times, packet inter-spacing, RTP timestamp increments and + sequence numbers, fairly reliable classifications are achieved. + For packet based marking schemes it might be possible to mark individual RTP packets differently based on the relative priority of the RTP payload. For example video codecs that have I, P, and B pictures could prioritise any payloads carrying only B frames less, as these are less damaging to loose. However, depending on the QoS mechanism and what markings that are applied, this can result in not only different packet drop probabilities but also packet reordering, see [I-D.ietf-tsvwg-rtcweb-qos] for further discussion. As a default policy all RTP packets related to a RTP packet stream ought to be provided with the same prioritization; per-packet prioritization is @@ -1789,94 +1802,96 @@ media data rate), or that configure the RTCP reporting interval small enough that the RTCP bandwidth would exceed the media bandwidth. The guidelines in [RFC6562] apply when using variable bit rate (VBR) audio codecs such as Opus (see Section 4.3 for discussion of mandated audio codecs). The guidelines in [RFC6562] also apply, but are of lesser importance, when using the client-to-mixer audio level header extensions (Section 5.2.2) or the mixer-to-client audio level header extensions (Section 5.2.3). The use of the encryption of the header extensions are RECOMMENDED, unless there are known reasons, like RTP - middleboxes or third party monitoring that will greatly benefit from - the information, and this has been expressed using API or signalling. - If further evidence are produced to show that information leakage is - significant from audio level indications, then use of encryption - needs to be mandated at that time. + middleboxes performing voice activity based source selection or third + party monitoring that will greatly benefit from the information, and + this has been expressed using API or signalling. If further evidence + are produced to show that information leakage is significant from + audio level indications, then use of encryption needs to be mandated + at that time. 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. Acknowledgements The authors would like to thank Bernard Aboba, Harald Alvestrand, - Cary Bran, Ben Campbell, Charles Eckel, Alex Eleftheriadis, Christian - Groves, Cullen Jennings, Olle Johansson, Suhas Nandakumar, Dan - Romascanu, Jim Spring, Martin Thomson, and the other members of the - IETF RTCWEB working group for their valuable feedback. + Cary Bran, Ben Campbell, Alissa Cooper, Charles Eckel, Alex + Eleftheriadis, Christian Groves, Cullen Jennings, Olle Johansson, + Suhas Nandakumar, Dan Romascanu, Jim Spring, Martin Thomson, and the + other members of the IETF RTCWEB working group for their valuable + feedback. 16. References 16.1. Normative References [I-D.ietf-avtcore-multi-media-rtp-session] Westerlund, M., Perkins, C., and J. Lennox, "Sending Multiple Types of Media in a Single RTP Session", draft- ietf-avtcore-multi-media-rtp-session-07 (work in progress), March 2015. [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-10 (work in progress), March 2015. - [I-D.ietf-avtcore-rtp-multi-stream-optimisation] - Lennox, J., Westerlund, M., Wu, Q., 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-07 (work in progress), March 2015. + [I-D.ietf-avtcore-rtp-multi-stream-optimisation] + 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-05 (work + in progress), February 2015. + [I-D.ietf-mmusic-sdp-bundle-negotiation] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- negotiation-19 (work in progress), March 2015. [I-D.ietf-rtcweb-audio] Valin, J. and C. Bran, "WebRTC Audio Codec and Processing - Requirements", draft-ietf-rtcweb-audio-07 (work in - progress), October 2014. + Requirements", draft-ietf-rtcweb-audio-08 (work in + progress), April 2015. [I-D.ietf-rtcweb-fec] Uberti, J., "WebRTC Forward Error Correction Requirements", draft-ietf-rtcweb-fec-01 (work in progress), March 2015. - [I-D.ietf-rtcweb-security-arch] - Rescorla, E., "WebRTC Security Architecture", draft-ietf- - rtcweb-security-arch-11 (work in progress), March 2015. - [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-08 (work in progress), February 2015. + [I-D.ietf-rtcweb-security-arch] + Rescorla, E., "WebRTC Security Architecture", draft-ietf- + rtcweb-security-arch-11 (work in progress), March 2015. + [I-D.ietf-rtcweb-video] Roach, A., "WebRTC Video Processing and Codec Requirements", draft-ietf-rtcweb-video-05 (work in progress), March 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, December @@ -1972,61 +1987,50 @@ 16.2. Informative References [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-03 (work in progress), October 2014. [I-D.ietf-avtcore-rtp-topologies-update] Westerlund, M. and S. Wenger, "RTP Topologies", draft- - ietf-avtcore-rtp-topologies-update-06 (work in progress), - March 2015. + ietf-avtcore-rtp-topologies-update-07 (work in progress), + April 2015. [I-D.ietf-avtext-rtp-grouping-taxonomy] - Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, - "A Taxonomy of Grouping Semantics and Mechanisms for Real- - Time Transport Protocol (RTP) Sources", draft-ietf-avtext- - rtp-grouping-taxonomy-06 (work in progress), March 2015. + Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and + B. Burman, "A Taxonomy of Grouping Semantics and + Mechanisms for Real-Time Transport Protocol (RTP) + Sources", draft-ietf-avtext-rtp-grouping-taxonomy-06 (work + in progress), March 2015. [I-D.ietf-mmusic-msid] Alvestrand, H., "WebRTC MediaStream Identification in the - Session Description Protocol", draft-ietf-mmusic-msid-08 - (work in progress), February 2015. - - [I-D.ietf-mmusic-sdp-bundle-negotiation] - Holmberg, C., Alvestrand, H., and C. Jennings, - "Negotiating Media Multiplexing Using the Session - Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- - negotiation-19 (work in progress), March 2015. + Session Description Protocol", draft-ietf-mmusic-msid-10 + (work in progress), April 2015. [I-D.ietf-payload-rtp-howto] Westerlund, M., "How to Write an RTP Payload Format", - draft-ietf-payload-rtp-howto-13 (work in progress), - January 2014. + draft-ietf-payload-rtp-howto-14 (work in progress), May + 2015. [I-D.ietf-rmcat-cc-requirements] Jesup, R. and Z. Sarker, "Congestion Control Requirements for Interactive Real-Time Media", draft-ietf-rmcat-cc- requirements-09 (work in progress), December 2014. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-13 (work in progress), November 2014. - [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-16 (work in - progress), January 2015. - [I-D.ietf-tsvwg-rtcweb-qos] Dhesikan, S., Jennings, C., Druta, D., Jones, P., and J. Polk, "DSCP and other packet markings for RTCWeb QoS", draft-ietf-tsvwg-rtcweb-qos-03 (work in progress), November 2014. [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003. @@ -2047,32 +2051,36 @@ [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP Control Protocol (RTCP)", RFC 5968, September 2010. [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP 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. + [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- + Time Communication Use Cases and Requirements", RFC 7478, + March 2015. + [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, . + 2013, . [W3C.WD-webrtc-20130910] Bergkvist, A., Burnett, D., Jennings, C., and A. Narayanan, "WebRTC 1.0: Real-time Communication Between - Browsers", World Wide Web Consortium WD WD- - webrtc-20130910, September 2013, + Browsers", World Wide Web Consortium WD WD-webrtc- + 20130910, September 2013, . Authors' Addresses Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom