draft-ietf-avtext-splicing-for-rtp-11.txt   draft-ietf-avtext-splicing-for-rtp-12.txt 
AVTEXT Working Group J. Xia AVTEXT Working Group J. Xia
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational October 22, 2012 Intended status: Informational November 12, 2012
Expires: April 25, 2013 Expires: May 16, 2013
Content Splicing for RTP Sessions Content Splicing for RTP Sessions
draft-ietf-avtext-splicing-for-rtp-11 draft-ietf-avtext-splicing-for-rtp-12
Abstract Abstract
Content splicing is a process that replaces the content of a main Content splicing is a process that replaces the content of a main
multimedia stream with other multimedia content, and delivers the multimedia stream with other multimedia content, and delivers the
substitutive multimedia content to the receivers for a period of substitutive multimedia content to the receivers for a period of
time. Splicing is commonly used for local advertisement insertion by time. Splicing is commonly used for local advertisement insertion by
cable operators, replacing a national advertisement content with a cable operators, replacing a national advertisement content with a
local advertisement. local advertisement.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2013. This Internet-Draft will expire on May 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
4.1. RTP Processing in RTP Mixer . . . . . . . . . . . . . . . 7 4.1. RTP Processing in RTP Mixer . . . . . . . . . . . . . . . 7
4.2. RTCP Processing in RTP Mixer . . . . . . . . . . . . . . . 8 4.2. RTCP Processing in RTP Mixer . . . . . . . . . . . . . . . 8
4.3. Considerations for Handling Media Clipping at the RTP 4.3. Considerations for Handling Media Clipping at the RTP
Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Congestion Control Considerations . . . . . . . . . . . . 11 4.4. Congestion Control Considerations . . . . . . . . . . . . 11
4.5. Considerations for Implementing Undetectable Splicing . . 12 4.5. Considerations for Implementing Undetectable Splicing . . 12
5. Implementation Considerations . . . . . . . . . . . . . . . . 13 5. Implementation Considerations . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. 10. Appendix- Why Mixer Is Chosen . . . . . . . . . . . . . . 14 9. 10. Appendix- Why Mixer Is Chosen . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document outlines how content splicing can be used in RTP This document outlines how content splicing can be used in RTP
sessions. Splicing, in general, is a process where part of a sessions. Splicing, in general, is a process where part of a
multimedia content is replaced with other multimedia content, and multimedia content is replaced with other multimedia content, and
delivered to the receivers for a period of time. The substitutive delivered to the receivers for a period of time. The substitutive
content can be provided for example via another stream or via local content can be provided for example via another stream or via local
media file storage. One representative use case for splicing is media file storage. One representative use case for splicing is
skipping to change at page 6, line 31 skipping to change at page 6, line 31
splicing in or splicing out operations can take place. splicing in or splicing out operations can take place.
REQ-3: REQ-3:
Splicing of RTP content must be backward compatible with the RTP/ Splicing of RTP content must be backward compatible with the RTP/
RTCP protocol, associated profiles, payload formats, and RTCP protocol, associated profiles, payload formats, and
extensions. extensions.
REQ-4: REQ-4:
The splicer will modify the content of RTP packets, and break the The splicer will modify the content of RTP packets, and thus break
end-to-end security, e.g., breaking data integrity and source the end-to-end security, at a minimum breaking the data integrity
authentication. If the Splicer is designated to insert and source authentication. If the Splicer is designated to insert
substitutive content, it must be trusted, i.e., be in the security substitutive content, it must be trusted, i.e., be in the security
context(s) as the main RTP sender, the substitutive RTP sender, context(s) with the main RTP sender, the substitutive RTP sender,
and the receivers. If encryption is employed, the splicer must be and the receivers. If encryption is employed, the splicer
able to decrypt the inbound RTP packets and re-encrypt the commonly must decrypt the inbound RTP packets and re-encrypt the
outbound RTP packets after splicing. outbound RTP packets after splicing.
REQ-5: REQ-5:
The splicer should rewrite as necessary and forward RTCP messages The splicer should rewrite as necessary and forward RTCP messages
(e.g., including packet loss, jitter, etc.) sent from downstream (e.g., including packet loss, jitter, etc.) sent from downstream
receiver to the main RTP sender or the substitutive RTP sender, receiver to the main RTP sender or the substitutive RTP sender,
and thus allow the main RTP sender or substitutive RTP sender to and thus allow the main RTP sender or substitutive RTP sender to
learn the performance of the downstream receiver when its content learn the performance of the downstream receiver when its content
is being passed to RTP receiver. In addition, the splicer should is being passed to RTP receiver. In addition, the splicer should
skipping to change at page 7, line 13 skipping to change at page 7, line 13
sender to the receiver. sender to the receiver.
REQ-6: REQ-6:
The splicer must not affect other RTP sessions running between the The splicer must not affect other RTP sessions running between the
RTP sender and the RTP receiver, and must be transparent for the RTP sender and the RTP receiver, and must be transparent for the
RTP sessions it does not splice. RTP sessions it does not splice.
REQ-7: REQ-7:
The splicer should be able to modify the RTP stream such that the The RTP receiver should not be able to detect any splicing points
splicing point is not easy to be detected by the RTP receiver at in the RTP stream produced by the splicer on RTP protocol level.
the RTP layer. For the advertisement insertion use case, it is For the advertisement insertion use case, it is important to make
important to make it difficult for the RTP receiver to detect it difficult for the RTP receiver to detect where an advertisement
where an advertisement insertion is starting or ending from the insertion is starting or ending from the RTP packets, and thus
RTP packets, and thus avoiding the RTP receiver from filtering out avoiding the RTP receiver from filtering out the advertisement
the advertisement content. This memo only focuses on making the content. This memo only focuses on making the splicing
splicing undetectable at the RTP layer. How (or if) the splicing undetectable at the RTP layer. The corresponding processing is
is made undetectable in the media stream is outside the scope of depicted in section 4.5.
this memo. The corresponding processing is depicted in section
4.5.
4. Content Splicing for RTP sessions 4. Content Splicing for RTP sessions
The RTP specification [RFC3550] defines two types of middlebox: RTP The RTP specification [RFC3550] defines two types of middlebox: RTP
translators and RTP mixers. Splicing is best viewed as a mixing translators and RTP mixers. Splicing is best viewed as a mixing
operation. The splicer generates a new RTP stream that is a mix of operation. The splicer generates a new RTP stream that is a mix of
the main RTP stream and the substitutive RTP stream. An RTP mixer is the main RTP stream and the substitutive RTP stream. An RTP mixer is
therefore an appropriate model for a content splicer. In next four therefore an appropriate model for a content splicer. In next four
subsections (from subsection 4.1 to subsection 4.4), the document subsections (from subsection 4.1 to subsection 4.4), the document
analyzes how the mixer handles RTP splicing and how it satisfies the analyzes how the mixer handles RTP splicing and how it satisfies the
skipping to change at page 10, line 27 skipping to change at page 10, line 25
packets, just as the RTCP report process described above. packets, just as the RTCP report process described above.
If the substitutive content comes from local media file storage If the substitutive content comes from local media file storage
(i.e., the mixer can be regarded as the substitutive RTP sender), any (i.e., the mixer can be regarded as the substitutive RTP sender), any
RTCP packets received from downstream relate to the substitutive RTCP packets received from downstream relate to the substitutive
content must be terminated on the mixer without any further content must be terminated on the mixer without any further
processing. processing.
4.3. Considerations for Handling Media Clipping at the RTP Layer 4.3. Considerations for Handling Media Clipping at the RTP Layer
This section provides informative guideline about how media clipping This section provides informative guidelines on how to handle media
is shaped and how the mixer deal with the media clipping only at the substitution at both the RTP layer to minimize media impact. Dealing
RTP layer. Dealing with the media clipping at the RTP layer just do with the media substitution well at the RTP layer is necessary for
a good quality implementation, perfectly erasing the media clipping quality implementations. To perfectly erase any media impact needs
needs more considerations at the higher layers, how the media more considerations at the higher layers, how the media substitution
clipping is erased at the higher layers is outside of the scope of is erased at the higher layers are outside of the scope of this memo.
this memo.
If the time slot for substitutive content mismatches (is shorter or If the time duration for any substitutive content mismatches, i.e.,
longer than) the duration of the main content to be replaced, then shorter or longer, than the duration of the main content to be
media clipping may occur at the splicing point and thus impact the replaced, then media degradations may occur at the splicing point and
user's experience. thus impact the user's experience.
If the substitutive content has shorter duration from the main If the substitutive content has shorter duration from the main
content, then there will be a gap in the output RTP stream. The RTP content, then there could be a gap in the output RTP stream. The RTP
sequence number will be contiguous across this gap, but there will be sequence number will be contiguous across this gap, but there will be
an unexpected jump in the RTP timestamp. This gap will cause the an unexpected jump in the RTP timestamp. Such a gap would cause the
receiver to have nothing to play. This is unavoidable, unless the receiver to have nothing to play. This may be unavoidable, unless
mixer adjusts the splice in or splice out point to compensate, the mixer can adjusts the splice in or splice out point to
sending more of the main RTP stream in place of the shorter compensate. This assumes the splicing mixer can send more of the
substitutive stream, or unless the mixer can vary the length of the main RTP stream in place of the shorter substitutive stream, or vary
substitutive content. It is the responsibility of the higher layer the length of the substitutive content. It is the responsibility of
protocols to ensure that the substitutive content is of the same the higher layer protocols and the media providers to ensure that the
duration as the main content to be replaced. substitutive content is of very similar duration as the main content
to be replaced.
If the insertion duration is longer than the reserved gap duration, If the substitute content has longer duration than the reserved gap
there will be an overlap between the substitutive RTP stream and the duration, there will be an overlap between the substitutive RTP
main RTP stream at splicing out point. One straightforward approach stream and the main RTP stream at the splicing out point. A
is that the mixer takes an ungraceful action, terminating the straightforward approach is that the mixer performs an ungraceful
splicing and switching back to main RTP stream even if this may cause action, terminating the splicing and switching back to main RTP
media stuttering on receiver. Alternatively, the mixer may transcode stream even if this may cause media stuttering on receiver.
the substitutive content to play at a faster rate than normal, to Alternatively, the mixer may transcode the substitutive content to
adjust it to the length of the gap in the main content, and generate play at a faster rate than normal, to adjust it to the length of the
a new RTP stream for the transcoded content. This is a complex gap in the main content, and generate a new RTP stream for the
operation, and very specific to the content and media codec used. transcoded content. This is a complex operation, and very specific
to the content and media codec used. Additional approaches exists,
these types of issues should be taken into account in both mixer
implementors and media generators to enable smooth substitutions.
4.4. Congestion Control Considerations 4.4. Congestion Control Considerations
If the substitutive content has somewhat different characteristics If the substitutive content has somewhat different characteristics
from the main content it replaces, or if the substitutive content is from the main content it replaces, or if the substitutive content is
encoded with a different codec or has different encoding bitrate, it encoded with a different codec or has different encoding bitrate, it
might overload the network and might cause network congestion on the might overload the network and might cause network congestion on the
path between the mixer and the RTP receiver(s) that would not have path between the mixer and the RTP receiver(s) that would not have
been caused by the main content. been caused by the main content.
To be robust to network congestion and packet loss, a mixer that is To be robust to network congestion and packet loss, a mixer that is
performing splicing must continuously monitor the status of performing splicing must continuously monitor the status of
downstream network by monitoring any of the following RTCP reports downstream network by monitoring any of the following RTCP reports
that are used: that are used:
1. RTCP receiver reports indicate packet loss [RFC3550]. 1. RTCP receiver reports indicate packet loss [RFC3550].
2. RTCP NACKs for lost packet recovery [RFC4585]. 2. RTCP NACKs for lost packet recovery [RFC4585].
3. RTCP ECN Feedback information [I-D.ietf-avtcore-ecn-for-rtp]. 3. RTCP ECN Feedback information [RFC6679].
Once the mixer detects congestion on its downstream link, it will Once the mixer detects congestion on its downstream link, it will
treat these reports as follows: treat these reports as follows:
1. If the mixer receives the RTCP receiver reports with packet loss 1. If the mixer receives the RTCP receiver reports with packet loss
indication, it will forward the reports to the substitutive RTP indication, it will forward the reports to the substitutive RTP
sender or the main RTP sender as described in section 4.2. sender or the main RTP sender as described in section 4.2.
2. If mixer receives the RTCP NACK packets defined in [RFC4585] from 2. If mixer receives the RTCP NACK packets defined in [RFC4585] from
RTP receiver for packet loss recovery, it first identifies the RTP receiver for packet loss recovery, it first identifies the
skipping to change at page 12, line 14 skipping to change at page 12, line 14
retransmission. retransmission.
It is somewhat complex that the lost packets requested in a It is somewhat complex that the lost packets requested in a
single RTCP NACK message not only contain the main content but single RTCP NACK message not only contain the main content but
also the substitutive content. To address this, the mixer must also the substitutive content. To address this, the mixer must
divide the RTCP NACK packet into two separate RTCP NACK packets: divide the RTCP NACK packet into two separate RTCP NACK packets:
one requests for the lost main content, and another requests for one requests for the lost main content, and another requests for
the lost substitutive content. the lost substitutive content.
3. If an ECN-aware mixer receives RTCP ECN feedbacks (RTCP ECN 3. If an ECN-aware mixer receives RTCP ECN feedbacks (RTCP ECN
feedback packets or RTCP XR summary reports) defined in feedback packets or RTCP XR summary reports) defined in [RFC6679]
[I-D.ietf-avtcore-ecn-for-rtp] from the RTP receiver, it must from the RTP receiver, it must process them in a similar way to
process them in a similar way to the RTP/AVPF feedback packet or the RTP/AVPF feedback packet or RTCP XR process described in
RTCP XR process described in section 4.2 of this memo. section 4.2 of this memo.
These three methods require the mixer to run a congestion control These three methods require the mixer to run a congestion control
loop and bitrate adaptation between itself and RTP receiver. The loop and bitrate adaptation between itself and RTP receiver. The
mixer can thin or transcode the main RTP stream or the substitutive mixer can thin or transcode the main RTP stream or the substitutive
RTP stream, but such operations are very inefficient and difficult, RTP stream, but such operations are very inefficient and difficult,
and bring undesirable delay. Fortunately in this memo, the mixer and bring undesirable delay. Fortunately in this memo, the mixer
acting as splicer can rewrite the RTCP packets sent from the RTP acting as splicer can rewrite the RTCP packets sent from the RTP
receiver and forward them to the RTP sender, thus letting the RTP receiver and forward them to the RTP sender, thus letting the RTP
sender knows that congestion is being experienced on the path between sender knows that congestion is being experienced on the path between
the mixer and the RTP receiver. Then, the RTP sender applies its the mixer and the RTP receiver. Then, the RTP sender applies its
skipping to change at page 13, line 16 skipping to change at page 13, line 16
knowledge of the main RTP sender and the substitutive RTP sender. knowledge of the main RTP sender and the substitutive RTP sender.
CSRC list identifies the contributing sources, these SSRC identifiers CSRC list identifies the contributing sources, these SSRC identifiers
of contributing sources are kept globally unique for each RTP of contributing sources are kept globally unique for each RTP
session. The uniqueness of SSRC identifier is used to resolve session. The uniqueness of SSRC identifier is used to resolve
collisions and detecting RTP-level forwarding loops as defined in collisions and detecting RTP-level forwarding loops as defined in
section 8.2 of [RFC3550]. The absence of CSRC list in this case will section 8.2 of [RFC3550]. The absence of CSRC list in this case will
create a danger that loops involving those contributing sources could create a danger that loops involving those contributing sources could
not be detected. The loops could occur if either the mixer is not be detected. The loops could occur if either the mixer is
misconfigured to form a loop, or a second mixer/translator is added, misconfigured to form a loop, or a second mixer/translator is added,
causing packets to loop back to upstream of the original mixer and causing packets to loop back to upstream of the original mixer. An
hence wasting the network bandwidth. So Non-RTP means must be used undetected RTP packet loop is a serious denial of service threat,
to detect and resolve loops if the mixer does not add a CSRC list. which can consume all available bandwidth or mixer processing
resources until the looped packets are dropped as result of
congestion. So Non-RTP means must be used to detect and resolve
loops if the mixer does not add a CSRC list.
5. Implementation Considerations 5. Implementation Considerations
When the mixer is used to handle RTP splicing, RTP receiver does not When the mixer is used to handle RTP splicing, RTP receiver does not
need any RTP/RTCP extension for splicing. As a trade-off, additional need any RTP/RTCP extension for splicing. As a trade-off, additional
overhead could be induced on the mixer which uses its own sequence overhead could be induced on the mixer which uses its own sequence
number space and timing model. So the mixer will rewrite RTP number space and timing model. So the mixer will rewrite RTP
sequence number and timestamp whatever splicing is active or not, and sequence number and timestamp whatever splicing is active or not, and
generate RTCP flows for both sides. In case the mixer serves generate RTCP flows for both sides. In case the mixer serves
multiple main RTP streams simultaneously, this may lead to more multiple main RTP streams simultaneously, this may lead to more
skipping to change at page 13, line 43 skipping to change at page 13, line 46
loop detection as briefly described in section 4.5. loop detection as briefly described in section 4.5.
6. Security Considerations 6. Security Considerations
The splicing application is subject to the general security The splicing application is subject to the general security
considerations of the RTP specification [RFC3550]. considerations of the RTP specification [RFC3550].
The mixer acting as splicer replaces some content with other content The mixer acting as splicer replaces some content with other content
in RTP packets, thus breaking any RTP level end-to-end security, such in RTP packets, thus breaking any RTP level end-to-end security, such
as integrity protection and source authentication. Thus any RTP as integrity protection and source authentication. Thus any RTP
level or outside security mechanism, such as IPsec or DTLS will use a level or outside security mechanism, such as IPSec or DTLS will use a
security association between the splicer and the receiver. When security association between the splicer and the receiver. When
using SRTP the splicer could be provisioned with the same security using SRTP the splicer could be provisioned with the same security
association as the main RTP sender. Using a limitation in the SRTP association as the main RTP sender. Using a limitation in the SRTP
security services, the splicer can modify and re-protect the RTP security services regarding source authentication, the splicer can
packets without enabling the receiver to detect if the data comes modify and re-protect the RTP packets without enabling the receiver
from the original source or from the splicer. to detect if the data comes from the original source or from the
splicer.
Security goals to have source authentication all the way from the RTP Security goals to have source authentication all the way from the RTP
main sender to the receiver through the splicer is not possible with main sender to the receiver through the splicer is not possible with
splicing. The nature of this RTP service offered by a network splicing and any existing solutions. A new solution can
operator employing a content splicer is that the RTP layer security theoretically be developed that enables identifying the participating
entities and what each provides, i.e. the different media sources,
main and substituting, and the splicer providing the RTP level
integration of the media payloads in a common timeline and
synchronization context. Such a solution would obviously not meet
Req-7 and will be detectable on RTP level.
The nature of this RTP service offered by a network operator
employing a content splicer is that the RTP layer security
relationship is between the receiver and the splicer, and between the relationship is between the receiver and the splicer, and between the
senders and the splicer, are not end-to-end. This appears to senders and the splicer, are not end-to-end. This appears to
invalidate the undetectability goal, but in the common case the invalidate the undetectability goal, but in the common case the
receiver will consider the splicer as the main media source. receiver will consider the splicer as the main media source.
Commonly no RTP level security mechanism is employed. Instead only Some RTP deployments use RTP payload security mechanisms (e.g.,
payload security mechanisms (e.g., ISMACryp [ISMACryp]) are used. If ISMACryp [ISMACryp]). If any payload internal security mechanisms
any payload internal security mechanisms are used, only the RTP are used, only the RTP sender and the RTP receiver establish that
sender and the RTP receiver can learn the security keying material security context, in which case, any middlebox (e.g., splicer)
generated by such internal security mechanism, in which case, any between the RTP sender and the RTP receiver will not get such keying
middlebox (e.g., splicer) between the RTP sender and the RTP receiver material. This may impact the splicer's possibility to perform
can't get such keying material, and thus fail to perform splicing. splicing if it is dependent on RTP payload level hints for finding
This would require a new method to be defined to make the splicer the splice in and out points. However, other potential solutions
learn the security keying material, but which is out of scope of this exist to specify or mark where the splicing points exist in the media
memo. streams. When using RTP payload security mechanisms SRTP or other
security mechanism at RTP or lower layers can be used to provide
integrity and source authentication between the splicer and the RTP
receiver.
7. IANA Considerations 7. IANA Considerations
No IANA actions are required. No IANA actions are required.
8. Acknowledgments 8. Acknowledgments
The following individuals have reviewed the earlier versions of this The following individuals have reviewed the earlier versions of this
specification and provided very valuable comments: Colin Perkins, specification and provided very valuable comments: Colin Perkins,
Magnus Westerlund, Roni Even, Tom Van Caenegem, Joerg Ott, David R Magnus Westerlund, Roni Even, Tom Van Caenegem, Joerg Ott, David R
skipping to change at page 15, line 33 skipping to change at page 15, line 48
[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.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[I-D.ietf-avtcore-ecn-for-rtp] [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
Westerlund, M., "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", draft-ietf-avtcore-ecn-for-rtp-08 (work for RTP over UDP", RFC 6679, August 2012.
in progress), May 2012.
10.2. Informative References 10.2. Informative References
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, September 2008. RFC 5348, September 2008.
 End of changes. 21 change blocks. 
81 lines changed or deleted 96 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/