draft-ietf-rtcweb-rtp-usage-14.txt | draft-ietf-rtcweb-rtp-usage-15.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: November 17, 2014 Ericsson | Expires: November 29, 2014 Ericsson | |||
J. Ott | J. Ott | |||
Aalto University | Aalto University | |||
May 16, 2014 | May 28, 2014 | |||
Web Real-Time Communication (WebRTC): Media Transport and Use of RTP | Web Real-Time Communication (WebRTC): Media Transport and Use of RTP | |||
draft-ietf-rtcweb-rtp-usage-14 | draft-ietf-rtcweb-rtp-usage-15 | |||
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 November 17, 2014. | This Internet-Draft will expire on November 29, 2014. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2014 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 3, line 4 ¶ | skipping to change at page 3, line 4 ¶ | |||
7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 19 | 7. WebRTC Use of RTP: Rate Control and Media Adaptation . . . . 19 | |||
7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 20 | 7.1. Boundary Conditions and Circuit Breakers . . . . . . . . 20 | |||
7.2. Congestion Control Interoperability and Legacy Systems . 21 | 7.2. Congestion Control Interoperability and Legacy Systems . 21 | |||
8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22 | 8. WebRTC Use of RTP: Performance Monitoring . . . . . . . . . . 22 | |||
9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 22 | 9. WebRTC Use of RTP: Future Extensions . . . . . . . . . . . . 22 | |||
10. Signalling Considerations . . . . . . . . . . . . . . . . . . 22 | 10. Signalling Considerations . . . . . . . . . . . . . . . . . . 22 | |||
11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 24 | 11. WebRTC API Considerations . . . . . . . . . . . . . . . . . . 24 | |||
12. RTP Implementation Considerations . . . . . . . . . . . . . . 26 | 12. RTP Implementation Considerations . . . . . . . . . . . . . . 26 | |||
12.1. Configuration and Use of RTP Sessions . . . . . . . . . 26 | 12.1. Configuration and Use of RTP Sessions . . . . . . . . . 26 | |||
12.1.1. Use of Multiple Media Sources Within an RTP Session 26 | 12.1.1. Use of Multiple Media Sources Within an RTP Session 26 | |||
12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 27 | 12.1.2. Use of Multiple RTP Sessions . . . . . . . . . . . . 28 | |||
12.1.3. Differentiated Treatment of RTP Packet Streams . . . 32 | 12.1.3. Differentiated Treatment of RTP Packet Streams . . . 32 | |||
12.2. Media Source, RTP Packet Streams, and Participant | 12.2. Media Source, RTP Packet Streams, and Participant | |||
Identification . . . . . . . . . . . . . . . . . . . . . 34 | Identification . . . . . . . . . . . . . . . . . . . . . 34 | |||
12.2.1. Media Source Identification . . . . . . . . . . . . 34 | 12.2.1. Media Source Identification . . . . . . . . . . . . 34 | |||
12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 34 | 12.2.2. SSRC Collision Detection . . . . . . . . . . . . . . 35 | |||
12.2.3. Media Synchronisation Context . . . . . . . . . . . 36 | 12.2.3. Media Synchronisation Context . . . . . . . . . . . 36 | |||
13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 | |||
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 | |||
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 | 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 | |||
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 | 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
16.1. Normative References . . . . . . . . . . . . . . . . . . 37 | 16.1. Normative References . . . . . . . . . . . . . . . . . . 38 | |||
16.2. Informative References . . . . . . . . . . . . . . . . . 40 | 16.2. Informative References . . . . . . . . . . . . . . . . . 41 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
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- | |||
time media applications. Previous work has defined the RTP protocol, | time media applications. Previous work has defined the RTP protocol, | |||
along with numerous profiles, payload formats, and other extensions. | along with numerous profiles, payload formats, and other extensions. | |||
When combined with appropriate signalling, these form the basis for | When combined with appropriate signalling, these form the basis for | |||
many teleconferencing systems. | many teleconferencing systems. | |||
skipping to change at page 5, line 49 ¶ | skipping to change at page 5, line 49 ¶ | |||
control protocol (RTCP). RTCP is a fundamental and integral part of | control protocol (RTCP). RTCP is a fundamental and integral part of | |||
RTP, and MUST be implemented in all WebRTC applications. | RTP, and MUST be implemented in all WebRTC applications. | |||
The following RTP and RTCP features are sometimes omitted in limited | The following RTP and RTCP features are sometimes omitted in limited | |||
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]. The RTCP optimisations for | |||
optimisations for multi-SSRC sessions defined in | multi-SSRC sessions defined in | |||
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] is RECOMMENDED. | [I-D.ietf-avtcore-rtp-multi-stream-optimisation] MAY be supported; | |||
if supported the usage MUST be signalled. | ||||
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 Sending correct synchronisation information in the RTCP Sender | o Sending correct synchronisation information in the RTCP Sender | |||
Reports, to allow receivers to implement lip-synchronisation; see | Reports, to allow receivers to implement lip-synchronisation; see | |||
Section 5.2.1 regarding support for the rapid RTP synchronisation | Section 5.2.1 regarding support for the rapid RTP synchronisation | |||
skipping to change at page 7, line 49 ¶ | skipping to change at page 7, line 49 ¶ | |||
bandwidth allocation if there are many events that require feedback. | bandwidth allocation if there are many events that require feedback. | |||
The timer rules are also needed to make use of the RTP conferencing | The timer rules are also needed to make use of the RTP conferencing | |||
extensions discussed in Section 5.1. | extensions discussed in Section 5.1. | |||
Note: The enhanced RTCP timer model defined in the RTP/AVPF | Note: The enhanced RTCP timer model defined in the RTP/AVPF | |||
profile is backwards compatible with legacy systems that implement | profile is backwards compatible with legacy systems that implement | |||
only the RTP/AVP or RTP/SAVP profile, given some constraints on | only the RTP/AVP or RTP/SAVP profile, given some constraints on | |||
parameter configuration such as the RTCP bandwidth value and "trr- | parameter configuration such as the RTCP bandwidth value and "trr- | |||
int" (the most important factor for interworking with RTP/(S)AVP | int" (the most important factor for interworking with RTP/(S)AVP | |||
end-points via a gateway is to set the trr-int parameter to a | end-points via a gateway is to set the trr-int parameter to a | |||
value representing 4 seconds). | value representing 4 seconds, see Section 6.1 in | |||
[I-D.ietf-avtcore-rtp-multi-stream]). | ||||
The secure RTP (SRTP) profile extensions [RFC3711] are needed to | The secure RTP (SRTP) profile extensions [RFC3711] are needed to | |||
provide media encryption, integrity protection, replay protection and | provide media encryption, integrity protection, replay protection and | |||
a limited form of source authentication. WebRTC implementations MUST | a limited form of source authentication. WebRTC implementations MUST | |||
NOT send packets using the basic RTP/AVP profile or the RTP/AVPF | 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 | profile; they MUST employ the full RTP/SAVPF profile to protect all | |||
RTP and RTCP packets that are generated (i.e., implementations MUST | RTP and RTCP packets that are generated (i.e., implementations MUST | |||
use SRTP and SRTCP). The RTP/SAVPF profile MUST be configured using | use SRTP and SRTCP). The RTP/SAVPF profile MUST be configured using | |||
the cipher suites, DTLS-SRTP protection profiles, keying mechanisms, | the cipher suites, DTLS-SRTP protection profiles, keying mechanisms, | |||
and other parameters described in [I-D.ietf-rtcweb-security-arch]. | and other parameters described in [I-D.ietf-rtcweb-security-arch]. | |||
skipping to change at page 18, line 9 ¶ | skipping to change at page 18, line 9 ¶ | |||
is REQUIRED that implementations are capable of encrypting the header | is REQUIRED that implementations are capable of encrypting the header | |||
extension according to [RFC6904] since the information contained in | extension according to [RFC6904] since the information contained in | |||
these header extensions can be considered sensitive. It is further | these header extensions can be considered sensitive. It is further | |||
RECOMMENDED that this encryption is used, unless the encryption has | RECOMMENDED that this encryption is used, unless the encryption has | |||
been explicitly disabled through API or signalling. | been explicitly disabled through API or signalling. | |||
6. WebRTC Use of RTP: Improving Transport Robustness | 6. WebRTC Use of RTP: Improving Transport Robustness | |||
There are tools that can make RTP packet streams robust against | There are tools that can make RTP packet streams robust against | |||
packet loss and reduce the impact of loss on media quality. However, | packet loss and reduce the impact of loss on media quality. However, | |||
they generally some add overhead compared to a non-robust stream. | they generally add some overhead compared to a non-robust stream. | |||
The overhead needs to be considered, and the aggregate bit-rate MUST | The overhead needs to be considered, and the aggregate bit-rate MUST | |||
be rate controlled to avoid causing network congestion (see | be rate controlled to avoid causing network congestion (see | |||
Section 7). As a result, improving robustness might require a lower | Section 7). As a result, improving robustness might require a lower | |||
base encoding quality, but has the potential to deliver that quality | base encoding quality, but has the potential to deliver that quality | |||
with fewer errors. The mechanisms described in the following sub- | with fewer errors. The mechanisms described in the following sub- | |||
sections can be used to improve tolerance to packet loss. | sections can be used to improve tolerance to packet loss. | |||
6.1. Negative Acknowledgements and RTP Retransmission | 6.1. Negative Acknowledgements and RTP Retransmission | |||
As a consequence of supporting the RTP/SAVPF profile, implementations | As a consequence of supporting the RTP/SAVPF profile, implementations | |||
skipping to change at page 23, line 30 ¶ | skipping to change at page 23, line 30 ¶ | |||
RTP Payload Types, media formats, and format parameters: The mapping | RTP Payload Types, media formats, and format parameters: The mapping | |||
between media type names (and hence the RTP payload formats to be | between media type names (and hence the RTP payload formats to be | |||
used), and the RTP payload type numbers MUST be signalled. Each | used), and the RTP payload type numbers MUST be signalled. Each | |||
media type MAY also have a number of media type parameters that | media type MAY also have a number of media type parameters that | |||
MUST also be signalled to configure the codec and RTP payload | MUST also be signalled to configure the codec and RTP payload | |||
format (the "a=fmtp:" line from SDP). Section 4.3 of this memo | format (the "a=fmtp:" line from SDP). Section 4.3 of this memo | |||
discusses requirements for uniqueness of payload types. | discusses requirements for uniqueness of payload types. | |||
RTP Extensions: The use of any additional RTP header extensions and | RTP Extensions: The use of any additional RTP header extensions and | |||
RTCP packet types, including any necessary parameters, SHOULD be | RTCP packet types, including any necessary parameters, MUST be | |||
signalled. For robustness, and for compatibility with non-WebRTC | signalled. This signalling is to ensure that a WebRTC endpoint's | |||
systems that might be connected to a WebRTC session via a gateway, | behaviour, especially when sending, of any extensions is | |||
implementations are required to ignore unknown RTCP packets and | predictable and consistent. For robustness, and for compatibility | |||
RTP header extensions (See Section 4.1). | with non-WebRTC systems that might be connected to a WebRTC | |||
session via a gateway, implementations are REQUIRED to ignore | ||||
unknown RTCP packets and RTP header extensions (see also | ||||
Section 4.1). | ||||
RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the | RTCP Bandwidth: Support for exchanging RTCP Bandwidth values to the | |||
end-points will be necessary. This SHALL be done as described in | end-points will be necessary. This SHALL be done as described in | |||
"Session Description Protocol (SDP) Bandwidth Modifiers for RTP | "Session Description Protocol (SDP) Bandwidth Modifiers for RTP | |||
Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or | Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or | |||
something semantically equivalent. This also ensures that the | something semantically equivalent. This also ensures that the | |||
end-points have a common view of the RTCP bandwidth. A common | end-points have a common view of the RTCP bandwidth. A common | |||
RTCP bandwidth is important as a too different view of the | RTCP bandwidth is important as a too different view of the | |||
bandwidths can lead to failure to interoperate. | bandwidths can lead to failure to interoperate. | |||
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 | |||
/answer model, but does require all the necessary parameters to be | offer/answer model, but does require all the necessary parameters to | |||
agreed upon, and provided to the RTP implementation. Note that in | be agreed upon, and provided to the RTP implementation. 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 be set in the API or explicitly signalled between the peers. | either be set in the API or explicitly signalled between the peers. | |||
11. WebRTC API Considerations | 11. WebRTC API Considerations | |||
The WebRTC API [W3C.WD-webrtc-20130910] and the Media Capture and | The WebRTC API [W3C.WD-webrtc-20130910] and the Media Capture and | |||
Streams API [W3C.WD-mediacapture-streams-20130903] defines and uses | Streams API [W3C.WD-mediacapture-streams-20130903] defines and uses | |||
the concept of a MediaStream that consists of zero or more | the concept of a MediaStream that consists of zero or more | |||
MediaStreamTracks. A MediaStreamTrack is an individual stream of | MediaStreamTracks. A MediaStreamTrack is an individual stream of | |||
skipping to change at page 37, line 5 ¶ | skipping to change at page 37, line 8 ¶ | |||
[I-D.ietf-rtcweb-security-arch]. | [I-D.ietf-rtcweb-security-arch]. | |||
RTCP packets convey a Canonical Name (CNAME) identifier that is used | RTCP packets convey a Canonical Name (CNAME) identifier that is used | |||
to associate RTP packet streams that need to be synchronised across | to associate RTP packet streams that need to be synchronised across | |||
related RTP sessions. Inappropriate choice of CNAME values can be a | related RTP sessions. Inappropriate choice of CNAME values can be a | |||
privacy concern, since long-term persistent CNAME identifiers can be | privacy concern, since long-term persistent CNAME identifiers can be | |||
used to track users across multiple WebRTC calls. Section 4.9 of | used to track users across multiple WebRTC calls. Section 4.9 of | |||
this memo provides guidelines for generation of untraceable CNAME | this memo provides guidelines for generation of untraceable CNAME | |||
values that alleviate this risk. | values that alleviate this risk. | |||
Some potential denial of service attacks exist if the RTCP reporting | ||||
interval is configured to an inappropriate value. This could be done | ||||
by configuring the RTCP bandwidth fraction to an excessively large or | ||||
small value using the SDP "b=RR:" or "b=RS:" lines [RFC3556], or some | ||||
similar mechanism, or by choosing an excessively large or small value | ||||
for the RTP/AVPF minimal receiver report interval (if using SDP, this | ||||
is the "a=rtcp-fb:... trr-int" parameter) [RFC4585]. The risks are | ||||
as follows: | ||||
1. the RTCP bandwidth could be configured to make the regular | ||||
reporting interval so large that effective congestion control | ||||
cannot be maintained, potentially leading to denial of service | ||||
due to congestion caused by the media traffic; | ||||
2. the RTCP interval could be configured to a very small value, | ||||
causing endpoints to generate high rate RTCP traffic, potentially | ||||
leading to denial of service due to the non-congestion controlled | ||||
RTCP traffic; and | ||||
3. RTCP parameters could be configured differently for each | ||||
endpoint, with some of the endpoints using a large reporting | ||||
interval and some using a smaller interval, leading to denial of | ||||
service due to premature participant timeouts due to mismatched | ||||
timeout periods which are based on the reporting interval (this | ||||
is a particular concern if endpoints use a small but non-zero | ||||
value for the RTP/AVPF minimal receiver report interval (trr-int) | ||||
[RFC4585], as discussed in Section 6.1 of | ||||
[I-D.ietf-avtcore-rtp-multi-stream]). | ||||
Premature participant timeout can be avoided by using the fixed (non- | ||||
reduced) minimum interval when calculating the participant timeout | ||||
(see Section 4.1 of this memo and Section 6.1 of | ||||
[I-D.ietf-avtcore-rtp-multi-stream]). To address the other concerns, | ||||
endpoints SHOULD ignore parameters that configure the RTCP reporting | ||||
interval to be significantly longer than the default five second | ||||
interval specified in [RFC3550] (unless the media data rate is so low | ||||
that the longer reporting interval roughly corresponds to 5% of the | ||||
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) | 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 such as Opus (see Section 4.3 for discussion of mandated | |||
audio codecs). The guidelines in [RFC6562] also apply, but are of | audio codecs). The guidelines in [RFC6562] also apply, but are of | |||
lesser importance, when using the client-to-mixer audio level header | 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.2) or the mixer-to-client audio level header | |||
extensions (Section 5.2.3). The use of the encryption of the header | extensions (Section 5.2.3). The use of the encryption of the header | |||
extensions are RECOMMENDED, unless there are known reasons, like RTP | extensions are RECOMMENDED, unless there are known reasons, like RTP | |||
middleboxes or third party monitoring that will greatly benefit from | middleboxes or third party monitoring that will greatly benefit from | |||
the information, and this has been expressed using API or signalling. | the information, and this has been expressed using API or signalling. | |||
If further evidence are produced to show that information leakage is | If further evidence are produced to show that information leakage is | |||
skipping to change at page 38, line 5 ¶ | skipping to change at page 38, line 44 ¶ | |||
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-05 (work in | ietf-avtcore-multi-media-rtp-session-05 (work in | |||
progress), February 2014. | progress), February 2014. | |||
[I-D.ietf-avtcore-rtp-circuit-breakers] | [I-D.ietf-avtcore-rtp-circuit-breakers] | |||
Perkins, C. and V. Singh, "Multimedia Congestion Control: | Perkins, C. and V. Singh, "Multimedia Congestion Control: | |||
Circuit Breakers for Unicast RTP Sessions", draft-ietf- | Circuit Breakers for Unicast RTP Sessions", draft-ietf- | |||
avtcore-rtp-circuit-breakers-05 (work in progress), | avtcore-rtp-circuit-breakers-05 (work in progress), | |||
February 2014. | February 2014. | |||
[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-04 (work in progress), | ||||
May 2014. | ||||
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] | [I-D.ietf-avtcore-rtp-multi-stream-optimisation] | |||
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: | |||
Grouping RTCP Reception Statistics and Other Feedback", | Grouping RTCP Reception Statistics and Other Feedback", | |||
draft-ietf-avtcore-rtp-multi-stream-optimisation-02 (work | draft-ietf-avtcore-rtp-multi-stream-optimisation-02 (work | |||
in progress), February 2014. | in progress), February 2014. | |||
[I-D.ietf-avtcore-rtp-multi-stream] | [I-D.ietf-rtcweb-security] | |||
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, | Rescorla, E., "Security Considerations for WebRTC", draft- | |||
"Sending Multiple Media Streams in a Single RTP Session", | ietf-rtcweb-security-06 (work in progress), January 2014. | |||
draft-ietf-avtcore-rtp-multi-stream-03 (work in progress), | ||||
February 2014. | ||||
[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- | |||
rtcweb-security-arch-09 (work in progress), February 2014. | rtcweb-security-arch-09 (work in progress), February 2014. | |||
[I-D.ietf-rtcweb-security] | ||||
Rescorla, E., "Security Considerations for WebRTC", draft- | ||||
ietf-rtcweb-security-06 (work in progress), January 2014. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP | [RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP | |||
Payload Format Specifications", BCP 36, RFC 2736, December | Payload Format Specifications", BCP 36, RFC 2736, December | |||
1999. | 1999. | |||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", STD 64, RFC 3550, July 2003. | Applications", STD 64, RFC 3550, July 2003. | |||
skipping to change at page 40, line 34 ¶ | skipping to change at page 41, line 30 ¶ | |||
16.2. Informative References | 16.2. Informative References | |||
[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-02 (work in progress), January 2014. | multiplex-guidelines-02 (work in progress), January 2014. | |||
[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-01 (work in progress), | ietf-avtcore-rtp-topologies-update-02 (work in progress), | |||
October 2013. | May 2014. | |||
[I-D.ietf-avtext-rtp-grouping-taxonomy] | [I-D.ietf-avtext-rtp-grouping-taxonomy] | |||
Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, | Lennox, J., Gross, K., Nandakumar, S., and G. Salgueiro, | |||
"A Taxonomy of Grouping Semantics and Mechanisms for Real- | "A Taxonomy of Grouping Semantics and Mechanisms for Real- | |||
Time Transport Protocol (RTP) Sources", draft-ietf-avtext- | Time Transport Protocol (RTP) Sources", draft-ietf-avtext- | |||
rtp-grouping-taxonomy-01 (work in progress), February | rtp-grouping-taxonomy-01 (work in progress), February | |||
2014. | 2014. | |||
[I-D.ietf-mmusic-msid] | [I-D.ietf-mmusic-msid] | |||
Alvestrand, H., "WebRTC MediaStream Identification in the | Alvestrand, H., "WebRTC MediaStream Identification in the | |||
End of changes. 17 change blocks. | ||||
36 lines changed or deleted | 81 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/ |