draft-ietf-avtext-splicing-notification-07.txt   draft-ietf-avtext-splicing-notification-08.txt 
AVTEXT Working Group J. Xia AVTEXT Working Group J. Xia
INTERNET-DRAFT R. Even INTERNET-DRAFT R. Even
Intended Status: Standards Track R. Huang Intended Status: Standards Track R. Huang
Expires: November 18, 2016 Huawei Expires: December 30, 2016 Huawei
L. Deng L. Deng
China Mobile China Mobile
May 17, 2016 June 28, 2016
RTP/RTCP extension for RTP Splicing Notification RTP/RTCP extension for RTP Splicing Notification
draft-ietf-avtext-splicing-notification-07 draft-ietf-avtext-splicing-notification-08
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. The splicer is designed to handle RTP splicing and needs to time. The splicer is designed to handle RTP splicing and needs to
know when to start and end the splicing. know when to start and end the splicing.
This memo defines two RTP/RTCP extensions to indicate the splicing This memo defines two RTP/RTCP extensions to indicate the splicing
skipping to change at page 2, line 24 skipping to change at page 2, line 24
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Overview of RTP Splicing Notification . . . . . . . . . . . . . 4 2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Overview of RTP Splicing . . . . . . . . . . . . . . . . . . 4
2.2 Overview of Splicing Interval . . . . . . . . . . . . . . . 5
3 Conveying Splicing Interval in RTP/RTCP extensions . . . . . . 5 3 Conveying Splicing Interval in RTP/RTCP extensions . . . . . . 5
3.1 RTP Header Extension . . . . . . . . . . . . . . . . . . . . 5 3.1 RTP Header Extension . . . . . . . . . . . . . . . . . . . . 5
3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6 3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6
4 Reducing Splicing Latency . . . . . . . . . . . . . . . . . . . 7 4 Reducing Splicing Latency . . . . . . . . . . . . . . . . . . . 7
5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 8 5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 8
6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8 6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 Declarative SDP . . . . . . . . . . . . . . . . . . . . . . 9 6.1 Declarative SDP . . . . . . . . . . . . . . . . . . . . . . 9
6.2 Offer/Answer without BUNDLE . . . . . . . . . . . . . . . . 9 6.2 Offer/Answer without BUNDLE . . . . . . . . . . . . . . . . 9
6.3 Offer/Answer with BUNDLE: All Media are spliced . . . . . . 10 6.3 Offer/Answer with BUNDLE: All Media are spliced . . . . . . 10
6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced . . 12 6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced . . 12
skipping to change at page 3, line 20 skipping to change at page 3, line 20
splicing cases, e.g., advertisement insertion, the splicing duration splicing cases, e.g., advertisement insertion, the splicing duration
needs to be inside of the specific, pre-designated time slot. Certain needs to be inside of the specific, pre-designated time slot. Certain
timing information about when to start and end the splicing must be timing information about when to start and end the splicing must be
first acquired by the splicer in order to start the splicing. This first acquired by the splicer in order to start the splicing. This
document refers to this information as the Splicing Interval. document refers to this information as the Splicing Interval.
[SCTE35] provides a method that encapsulates the Splicing Interval [SCTE35] provides a method that encapsulates the Splicing Interval
inside the MPEG2-TS layer in cable TV systems. When transported in inside the MPEG2-TS layer in cable TV systems. When transported in
RTP, an middle box designed as the splicer to decode the RTP packets RTP, an middle box designed as the splicer to decode the RTP packets
and search for the Splicing Interval inside the payloads is required. and search for the Splicing Interval inside the payloads is required.
The middle box is either a translator or a mixer as described in The need for such processing increases the workload of the middle box
[RFC6828]. The need for such processing increases the workload of the and limits the number of RTP sessions the middle box can support.
middle box and limits the number of RTP sessions the middle box can
support.
The document defines an RTP header extension [RFC5285] used by the The document defines an RTP header extension [RFC5285] used by the
main RTP sender to provide the Splicing Interval by including it in main RTP sender to provide the Splicing Interval by including it in
the RTP packets. the RTP packets.
However, the Splicing Interval conveyed in the RTP header extension However, the Splicing Interval conveyed in the RTP header extension
might not reach the splicer successfully. Any splicing un-aware might not reach the splicer successfully. Any splicing un-aware
middlebox on the path between the RTP sender might strip this RTP middlebox on the path between the RTP sender might strip this RTP
header extension. header extension.
To increase robustness against such case, the document also defines a To increase robustness against such case, the document also defines a
complementary RTCP packet type to carry the same Splicing Interval to new RTCP packet type to carry the same Splicing Interval to the
the splicer. splicer. Since RTCP is also unreliable and may not be so immediate as
the in-band way, it's only considered as a complement to the RTP
header extension.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
In addition, we define following terminologies: In addition, we define following terminologies:
Main RTP sender: Main RTP sender:
skipping to change at page 4, line 33 skipping to change at page 4, line 33
The NTP-format timestamps, representing the main RTP sender The NTP-format timestamps, representing the main RTP sender
wallclock time, for the Splicing-In point and Splicing-Out point wallclock time, for the Splicing-In point and Splicing-Out point
per [RFC6828] allowing the splicer to know when to start and end per [RFC6828] allowing the splicer to know when to start and end
the RTP splicing. the RTP splicing.
Substitutive RTP Sender: Substitutive RTP Sender:
The sender of RTP packets carrying the RTP stream that will The sender of RTP packets carrying the RTP stream that will
replace the content in the main RTP stream. replace the content in the main RTP stream.
2 Overview of RTP Splicing Notification 2 Overview
A splicer is designed to handle splicing on the RTP layer at the 2.1 Overview of RTP Splicing
reserved time slots set by the main RTP sender. This implies that the
splicer must first know the Splicing Interval from the main RTP RTP Splicing is intended to replace some multimedia content with
sender before it can start splicing. The splicer can be a mixer as certain substitutive multimedia content, and then forward it to the
described in [RFC6828]. receivers for a period of time. This process is authorized by the
main RTP sender that offers a specific time window for inserting the
substitutive multimedia content in the main content. A typical usage
is that IPTV service provider uses its own regional advertising
content to replace national advertising content, the time window of
which is explicitly indicated by the IPTV service provider.
The splicer is a middlebox handling RTP splicing. It receives main
content and substitutive content simultaneously but only chooses to
send one of them to the receiver at any point of time. When RTP
splicing begins, the splicer sends the substitutive content to the
receivers instead of the main content. When RTP splicing ends, the
splicer switches back to sending the main content to the receivers.
This implies that the receiver is explicitly configured to receive
the traffic via the splicer, and will return any RTCP feedback to it
in the presence of the splicer.
The middlebox working as the splicer can be implemented as either an
RTP mixer or as an RTP translator. If implemented as an RTP mixer,
[RFC6828] specifies how the splicer can use its own SSRC, sequence
number space, and timing model when generating the output stream to
receivers, using the CSRC list to indicate whether the original or
substitutive content is being delivered. The splicer, on behalf of
the content provider, can omit the CSRC list from the RTP packets it
generates. This simplifies the design of the receivers, since they
don't need to parse the CSRC list, but makes it harder to determine
when the splicing is taking place (it requires inspection of the RTP
payload data, rather than just the RTP headers). A splicer working as
an RTP mixer splits the flow between the sender and receiver into
two, and requires separate control loops, for RTCP and congestion
control, see Section 4.4 of [RFC6828].
A splicer implemented as an RTP translator [RFC3550] will forward the
RTP packets from the original and substitutive senders with their
SSRCs intact, but will need to rewrite RTCP sender report packets to
account for the splicing. In this case, the congestion control loops
run between original sender and receiver, and between the
substitutive sender and receiver. The splicer needs to ensure that
the RTCP feedback message from the receiver are passed to the right
sender to let the congestion control work.
2.2 Overview of Splicing Interval
To handle splicing on the RTP layer at the reserved time slots set by
the main RTP sender, the splicer must first know the Splicing
Interval from the main RTP sender before it can start splicing. The
splicer can be a mixer as described in [RFC6828].
When a new splicing is forthcoming, the main RTP sender needs to send When a new splicing is forthcoming, the main RTP sender needs to send
the Splicing Interval to the splicer. The Splicing Interval SHOULD be the Splicing Interval to the splicer. The Splicing Interval SHOULD be
sent more than once to mitigate the possible packet loss. To enable sent by RTP header extension or RTCP extension message more than once
the splicer to get the substitutive content before the splicing to mitigate the possible packet loss. To enable the splicer to get
starts, the main RTP sender MUST send the Splicing Interval far the substitutive content before the splicing starts, the main RTP
ahead. For example, the main RTP sender can estimate when to send the sender MUST send the Splicing Interval far ahead. For example, the
Splicing Interval based on the round-trip time (RTT) following the main RTP sender can estimate when to send the Splicing Interval based
mechanisms in section 6.4.1 of [RFC3550] when the splicer sends RTCP on the round-trip time (RTT) following the mechanisms in section
RR to the main sender. 6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main sender.
The substitutive sender also needs to learn the Splicing Interval The substitutive sender also needs to learn the Splicing Interval
from the main RTP sender in advance, and thus estimates when to from the main RTP sender in advance, and thus estimates when to
transfer the substitutive content to the splicer. The Splicing transfer the substitutive content to the splicer. The Splicing
Interval could be transmitted from the main RTP sender to the Interval could be transmitted from the main RTP sender to the
substitutive content using some out-of-band mechanisms, for example, substitutive content using some out-of-band mechanisms, for example,
a proprietary mechanism to exchange the Splicing Interval, or the a proprietary mechanism to exchange the Splicing Interval, or the
substitutive sender is implemented together with the main RTP sender substitutive sender is implemented together with the main RTP sender
inside a single device. To ensure the Splicing Interval is valid for inside a single device. To ensure the Splicing Interval is valid for
both the main RTP sender and the substitutive RTP sender, the two both the main RTP sender and the substitutive RTP sender, the two
skipping to change at page 7, line 27 skipping to change at page 8, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Splicing Interval Figure 2: Splicing Interval
Using the Two-Byte Header Format Using the Two-Byte Header Format
Since the inclusion of an RTP header extension will reduce the Since the inclusion of an RTP header extension will reduce the
efficiency of RTP header compression, it is RECOMMENDED that the main efficiency of RTP header compression, it is RECOMMENDED that the main
sender inserts the RTP header extensions into only a number of RTP sender inserts the RTP header extensions into only a number of RTP
packets, instead of all the RTP packets, prior to the splicing in. packets, instead of all the RTP packets, prior to the splicing in.
After the splicer intercepts the RTP header extension and derives the After the splicer obtains the RTP header extension and derives the
Splicing Interval, it will generate its own stream and SHOULD NOT Splicing Interval, it generates its own stream and is not allowed to
include the RTP header extension in outgoing packets to reduce header include the RTP header extension in outgoing packets to reduce header
overhead. overhead.
3.2 RTCP Splicing Notification Message 3.2 RTCP Splicing Notification Message
In addition to the RTP header extension, the main RTP sender includes In addition to the RTP header extension, the main RTP sender includes
the Splicing Interval in an RTCP splicing notification message. the Splicing Interval in an RTCP splicing notification message.
Whether or not the timestamps are included in the RTP header Whether or not the timestamps are included in the RTP header
extension, the main RTP sender MUST send the RTCP splicing extension, the main RTP sender MUST send the RTCP splicing
notification message. This provide robustness in the case where a notification message. This provide robustness in the case where a
skipping to change at page 9, line 5 skipping to change at page 10, line 5
6.1 in [RFC3550]. 6.1 in [RFC3550].
If the use of non-compound RTCP [RFC5506] was previously negotiated If the use of non-compound RTCP [RFC5506] was previously negotiated
between the sender and the splicer, the RTCP splicing notification between the sender and the splicer, the RTCP splicing notification
message may be sent as non-compound RTCP packets. In some cases that message may be sent as non-compound RTCP packets. In some cases that
the mapping from RTP timestamp to NTP timestamp changes, e.g., clock the mapping from RTP timestamp to NTP timestamp changes, e.g., clock
drift happening before the splicing event, it may be required to send drift happening before the splicing event, it may be required to send
RTCP SR or even updated Splicing Interval information timely to RTCP SR or even updated Splicing Interval information timely to
update the timestamp mapping for accurate splicing. update the timestamp mapping for accurate splicing.
When the splicer intercepts the RTCP splicing notification message, Since the RTCP splicing notification message is intentionally sent by
it SHOULD NOT forward the message to the down-stream receivers in the main RTP sender to the splicer, the splicer is not allowed to
order to reduce RTCP bandwidth consumption. And if the splicer wishes forward this message to the receivers so as to avoid their useless
to prevent the downstream receivers from detecting splicing, it MUST processing and additional RTCP bandwidth consumption in the
NOT forward the message. downstream.
4 Reducing Splicing Latency 4 Reducing Splicing Latency
When splicing starts or ends, the splicer outputs the multimedia When splicing starts or ends, the splicer outputs the multimedia
content from another sender to the receivers. Given that the content from another sender to the receivers. Given that the
receivers must first acquire certain information ([RFC6285] refers to receivers must first acquire certain information ([RFC6285] refers to
this information as Reference Information) to start processing the this information as Reference Information) to start processing the
multimedia data, either the main RTP sender or the substitutive multimedia data, either the main RTP sender or the substitutive
sender SHOULD provide the Reference Information together with its sender SHOULD provide the Reference Information together with its
multimedia content to reduce the delay caused by acquiring the multimedia content to reduce the delay caused by acquiring the
Reference Information. The methods by which the Reference Information Reference Information. The methods by which the Reference Information
is distributed to the receivers is out of scope of this memo. is distributed to the receivers is out of scope of this memo.
Another latency element is synchronization caused delay. The Another latency element is synchronization caused delay. The
receivers must receive enough synchronization metadata prior to receivers must receive enough synchronization metadata prior to
synchronizing the separate components of the multimedia streams when synchronizing the separate components of the multimedia streams when
splicing starts or ends. Either the main RTP sender or the splicing starts or ends. Either the main RTP sender or the
substitutive sender SHOULD send the synchronization metadata early substitutive sender SHOULD send the synchronization metadata early
enough so that the receivers can play out the multimedia in a enough so that the receivers can play out the multimedia in a
synchronized fashion. The main RTP sender and the substitutive sender synchronized fashion. The main RTP sender or the substitutive sender
can be coordinated by some proprietary out-of-band mechanisms to can estimate when to send the synchronization metadata based on, for
decide when and whom to send the metadata. If both send the example, the round-trip time (RTT) following the mechanisms in
information, the splicer SHOULD pick one based on the current section 6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main
situation, e.g., choosing media sender when synchronizing the main sender or the substitutive sender. The main RTP sender and the
media content while choosing the information from the substitutive substitutive sender can also be coordinated by some proprietary out-
sender when synchronizing the spliced content. The mechanisms defined of-band mechanisms to decide when and whom to send the metadata. If
in [RFC6051] are RECOMMENDED to be adopted to reduce the possible both send the information, the splicer SHOULD pick one based on the
synchronization delay. current situation, e.g., choosing main RTP sender when synchronizing
the main media content while choosing the information from the
substitutive sender when synchronizing the spliced content. The
mechanisms defined in [RFC6051] are RECOMMENDED to be adopted to
reduce the possible synchronization delay.
5 Failure Cases 5 Failure Cases
This section examines the implications of losing RTCP splicing This section examines the implications of losing RTCP splicing
notification message and the other failure case, e.g., the RTP header notification message and the other failure case, e.g., the RTP header
extension is stripped on the path. extension is stripped on the path.
Given that there may be a splicing un-aware middlebox on the path Given that there may be a splicing un-aware middlebox on the path
between the main RTP sender and the splicer, the main and the between the main RTP sender and the splicer, the main and the
substitutive RTP senders can use one heuristic to verify whether or substitutive RTP senders can use one heuristic to verify whether or
skipping to change at page 16, line 37 skipping to change at page 17, line 37
The splicer replaces some content with other content in RTP packet, The splicer replaces some content with other content in RTP packet,
thus breaking any RTP-level end-to-end security, such as source thus breaking any RTP-level end-to-end security, such as source
authentication and integrity protection. End to end source authentication and integrity protection. End to end source
authentication is not possible with any known existing splicing authentication is not possible with any known existing splicing
solution. A new solution can theoretically be developed that enables solution. A new solution can theoretically be developed that enables
identification of the participating entities and what each provides, identification of the participating entities and what each provides,
i.e., the different media sources, main and substituting, and the i.e., the different media sources, main and substituting, and the
splicer which provides the RTP-level integration of the media splicer which provides the RTP-level integration of the media
payloads in a common timeline and synchronization context. payloads in a common timeline and synchronization context.
Since splicer works as a trusted entity, any RTP-level or outside Since the splicer breaks RTP-level end-to-end security, it needs to
security mechanism, such as IPsec[RFC4301] or Datagram Transport be part of the signaling context and the necessary security
Layer Security [RFC6347], will use a security association between the associations (e.g., SRTP crypto contexts) established for the RTP
splicer and the receiver. When using the Secure Real-Time Transport session participants. When using the Secure Real-Time Transport
Protocol (SRTP) [RFC3711], the splicer could be provisioned with the Protocol (SRTP) [RFC3711], the splicer would have to be provisioned
same security association as the main RTP sender. with the same security association as the main RTP sender.
If there is a concern about the confidentiality of the splicing time If there is a concern about the confidentiality of the splicing time
information, header extension encryption [RFC6904] SHOULD be used. information, the header extension defined in this document MUST be
However, the malicious endpoint may get the splicing time information also protected, for example, header extension encryption [RFC6904]
by other means, e.g., inferring from the communication between the can be used in this case. However, the malicious endpoint may get the
main and substitutive content sources. To avoid the insertion of splicing time information by other means, e.g., inferring from the
invalid substitutive content, the splicer MUST have some mechanisms communication between the main and substitutive content sources. To
to authenticate the substitutive stream source. avoid the insertion of invalid substitutive content, the splicer MUST
have some mechanisms to authenticate the substitutive stream source.
For cases that the splicing time information is changed by a For cases that the splicing time information is changed by a
malicious endpoint, the splicing, for example, may fail since it will malicious endpoint, the splicing, for example, may fail since it will
not be available at the right time for the substitutive media to not be available at the right time for the substitutive media to
arrive. Another case is that an attacker may prevent the receivers arrive. Another case is that an attacker may prevent the receivers
receiving the content from the main sender by inserting extra receiving the content from the main sender by inserting extra
splicing time information. To avoid the above cases happening, the splicing time information. To avoid the above cases happening, the
authentication of the RTP header extension for splicing time authentication of the RTP header extension for splicing time
information SHOULD be considered. information SHOULD be considered.
A malicious endpoint may also break an undetectable splicing. To When a splicer implemented as a mixer sends the stream to the
mitigate this effect, the splicer SHOULD NOT forward the splicing receivers, CSRC list, which can be used to detect RTP-level
time information RTP header extension defined in Section 4.1 to the forwarding loops as defined in Section 8.2 of [RFC3550], may be
receivers. And it MUST NOT forward this header extension when removed for simplifying the receivers that can not handle multiple
considering an undetectable splicing. sources in the RTP stream. Hence, loops may occur to cause packets to
loop back to upstream of the splicer and may form a serious denial-
of-service threat. In such a case, non-RTP means, e.g., signaling
among all the participants, MUST be used to detect and resolve loops.
8 IANA Considerations 8 IANA Considerations
8.1 RTCP Control Packet Types 8.1 RTCP Control Packet Types
Based on the guidelines suggested in [RFC5226], a new RTCP packet Based on the guidelines suggested in [RFC5226], a new RTCP packet
format has been registered with the RTCP Control Packet Type (PT) format has been registered with the RTCP Control Packet Type (PT)
Registry: Registry:
Name: SNM Name: SNM
skipping to change at page 17, line 50 skipping to change at page 19, line 4
Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval
Description: Splicing Interval Description: Splicing Interval
Contact: Jinwei Xia <xiajinwei@huawei.com> Contact: Jinwei Xia <xiajinwei@huawei.com>
Reference: This document Reference: This document
8.3 SDP Grouping Semantic Extension 8.3 SDP Grouping Semantic Extension
This document request IANA to register the new SDP grouping semantic This document request IANA to register the new SDP grouping semantic
extension called "SPLICE". extension called "SPLICE".
Semantics: Splice Semantics: Splice
Token:SPLICE Token:SPLICE
Reference: This document Reference: This document
Contact: Jinwei Xia <xiajinwei@huawei.com>
9 Acknowledgement 9 Acknowledgement
The authors would like to thank the following individuals who help to The authors would like to thank the following individuals who help to
review this document and provide very valuable comments: Colin review this document and provide very valuable comments: Colin
Perkins, Bo Burman, Stephen Botzko, Ben Campbell. Perkins, Bo Burman, Stephen Botzko, Ben Campbell.
10 References 10 References
10.1 Normative References 10.1 Normative References
skipping to change at page 18, line 34 skipping to change at page 19, line 34
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model
with the Session Description Protocol (SDP)", RFC 3264, with the Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010. Flows", RFC 6051, November 2010.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, April 2014. Sessions", RFC 7201, April 2014.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
November 2015. November 2015.
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)",
 End of changes. 19 change blocks. 
65 lines changed or deleted 113 lines changed or added

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