draft-ietf-avtext-splicing-notification-04.txt   draft-ietf-avtext-splicing-notification-05.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: July 29, 2016 Huawei Expires: September 22, 2016 Huawei
L. Deng L. Deng
China Mobile China Mobile
January 26, 2016 March 21, 2016
RTP/RTCP extension for RTP Splicing Notification RTP/RTCP extension for RTP Splicing Notification
draft-ietf-avtext-splicing-notification-04 draft-ietf-avtext-splicing-notification-05
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 3, line 29 skipping to change at page 3, line 29
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 middle box is either a translator or a mixer as described in
[RFC6828]. The need for such processing increases the workload of the [RFC6828]. The need for such processing increases the workload of the
middle box and limits the number of RTP sessions the middle box can middle box and limits the number of RTP sessions the middle box can
support. 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.
Nevertheless, the Splicing Interval conveyed in the RTP header However, the Splicing Interval conveyed in the RTP header extension
extension might not reach the splicer successfully. Any splicing un- might not reach the splicer successfully. Any splicing un-aware
aware middlebox on the path between the RTP sender might strip this middlebox on the path between the RTP sender might strip this RTP
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 complementary RTCP packet type to carry the same Splicing Interval to
the splicer. the splicer.
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].
skipping to change at page 4, line 23 skipping to change at page 4, line 23
decodable frames. decodable frames.
Splicing-Out Point Splicing-Out Point
A virtual point in the RTP stream, suitable for substitutive A virtual point in the RTP stream, suitable for substitutive
content exit, typically in the boundary between two independently content exit, typically in the boundary between two independently
decodable frames. decodable frames.
Splicing Interval: Splicing Interval:
The NTP timestamps for the Splicing-In point and Splicing-Out The NTP-format timestamps, representing the main RTP sender
point per [RFC6828] allowing the splicer to know when to start and wallclock time, for the Splicing-In point and Splicing-Out point
end the RTP splicing. per [RFC6828] allowing the splicer to know when to start and end
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 of RTP Splicing Notification
A splicer is designed to handle splicing on the RTP layer at the A splicer is designed to handle splicing on the RTP layer at the
reserved time slots set by the main RTP sender. This implies that the reserved time slots set by the main RTP sender. This implies that the
skipping to change at page 5, line 27 skipping to change at page 5, line 29
In this document, the main RTP sender uses a pair of NTP-format In this document, the main RTP sender uses a pair of NTP-format
timestamps, to indicate when to start and end the splicing to the timestamps, to indicate when to start and end the splicing to the
splicer: the timestamp of the first substitutive RTP packet at the splicer: the timestamp of the first substitutive RTP packet at the
splicing in point, and the timestamp of the first main RTP packet at splicing in point, and the timestamp of the first main RTP packet at
the splicing out point. the splicing out point.
When the substitutive RTP sender gets the Splicing Interval, it must When the substitutive RTP sender gets the Splicing Interval, it must
prepare the substitutive stream. The main and the substitutive prepare the substitutive stream. The main and the substitutive
content providers MUST ensure that the RTP timestamp of the first content providers MUST ensure that the RTP timestamp of the first
substitutive RTP packet that would be presented to the receivers substitutive RTP packet that would be presented to the receivers
corresponds to the same time instant as the former NTP timestamp in corresponds to the same time instant as the former NTP-format
the Splicing Interval. To enable the splicer to know the first timestamp in the Splicing Interval. To enable the splicer to know the
substitutive RTP packet it needs to send, the substitutive RTP sender first substitutive RTP packet it needs to send, the substitutive RTP
MUST send the substitutive RTP packet ahead of the Splicing In point, sender MUST send the substitutive RTP packet ahead of the Splicing In
allowing the splicer to find out the timestamp of this first RTP point, allowing the splicer to find out the timestamp of this first
packet in the substitutive RTP stream, e.g., using a prior RTCP SR RTP packet in the substitutive RTP stream, e.g., using a prior RTCP
message. SR (Sender Report) message.
When the splicing will end, the main content provider and the When the splicing will end, the main content provider and the
substitutive content provider MUST ensure the RTP timestamp of the substitutive content provider MUST ensure the RTP timestamp of the
first main RTP packet that would be presented on the receivers first main RTP packet that would be presented on the receivers
corresponds to the same time instant as the latter NTP timestamp in corresponds to the same time instant as the latter NTP-format
the Splicing Interval. timestamp in the Splicing Interval.
3 Conveying Splicing Interval in RTP/RTCP extensions 3 Conveying Splicing Interval in RTP/RTCP extensions
This memo defines two backwards compatible RTP extensions to convey This memo defines two backwards compatible RTP extensions to convey
the Splicing Interval to the splicer: an RTP header extension and an the Splicing Interval to the splicer: an RTP header extension and an
RTCP splicing notification message. RTCP splicing notification message.
3.1 RTP Header Extension 3.1 RTP Header Extension
The RTP header extension mechanism defined in [RFC5285] can be The RTP header extension mechanism defined in [RFC5285] can be
adapted to carry the Splicing Interval consisting of a pair of NTP- adapted to carry the Splicing Interval consisting of a pair of NTP-
format timestamps. format timestamps. Two variants are defined for this header
extension: one-byte header variant and two-byte header variant.
One variant is defined for this header extension. It carries the 7 For one-byte header variant, it carries the 7 octets splicing-out
octets splicing-out NTP timestamp (lower 24-bit part of the Seconds NTP-format timestamp (lower 24-bit part of the Seconds of a NTP-
of a NTP-format timestamp and the 32 bits of the Fraction of a NTP- format timestamp and the 32 bits of the Fraction of a NTP-format
format timestamp as defined in [RFC5905]), followed by the 8 octets timestamp as defined in [RFC5905]), followed by the 8 octets
splicing-in NTP timestamp (64-bit NTP-format timestamp as defined in splicing-in NTP-format timestamp (64-bit NTP-format timestamp as
[RFC5905]). The top 8 bits of the splicing-out NTP timestamp are defined in [RFC5905]). The top 8 bits of the splicing-out NTP
inferred from the top 8 bits of the splicing-in NTP timestamp. This timestamp are inferred from the top 8 bits of the splicing-in NTP
is unambiguous, under the assumption that the splicing-out time is timestamp. This is unambiguous, under the assumption that the
after the splicing-in time, and the splicing interval is less than splicing-out time is after the splicing-in time, and the splicing
2^25 seconds. If the 7 octets splicing-out NTP timestamp is smaller interval is less than 2^25 seconds. Therefore, if the value of 7
than the lower 7 octets splicing-in NTP timestamp, it implies a wrap octets splicing-out NTP-format timestamp is smaller than the value of
of the 64-bit splicing-out NTP timestamp which will then be 7 lower octets splicing-in NTP-format, it implies a wrap of the 56-
calculated by the 7 octets splicing-out NTP timestamp plus bit splicing-out NTP-format timestamp which means the top 8-bit value
0x100000000. Otherwise, the top 8 octets of splicing-out NTP of the 64-bit splicing-out is equal to the top 8-bit value of
timestamp is equal to the top 8 octets of splicing-in NTP timestamp. splicing-in NTP Timestamp plus 0x01. Otherwise, the top 8 bits of
splicing-out NTP timestamp is equal to the top 8 bits of splicing-in
NTP Timestamp.
The format is shown in Figures 1. The format is shown in Figures 1.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xBE | 0xDE | length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID | L=15 | OUT NTP timestamp format - Seconds (bit 8-31) |x | ID | L=15 | OUT NTP timestamp format - Seconds (bit 8-31) |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
| OUT NTP timestamp format - Fraction (bit 0-31) |e | OUT NTP timestamp format - Fraction (bit 0-31) |e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
| IN NTP timestamp format - Seconds (bit 0-31) |s | IN NTP timestamp format - Seconds (bit 0-31) |s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i
| IN NTP timestamp format - Fraction (bit 0-31) |o | IN NTP timestamp format - Fraction (bit 0-31) |o
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
Figure 1: Sample hybrid NTP Encoding Using Figure 1: Splicing Interval
the One-Byte Header Format Using the One-Byte Header Format
For two-byte header variant, it carries the 6 octets splicing-out
NTP-format timestamp (lower 16-bit part of the Seconds of a NTP-
format timestamp and the 32 bits of the Fraction of a NTP-format
timestamp as defined in [RFC5905]), followed by the 8 octets
splicing-in NTP-format timestamp (64-bit NTP-format timestamp as
defined in [RFC5905]). Also, the top 16 bits of the splicing-out NTP
timestamp are inferred from the top 16 bits of the splicing-in NTP
timestamp, under the assumption that the splicing-out time is after
the splicing-in time, and the splicing interval is less than 2^16
seconds. Similar to the one-byte header, if the value of 6 octets
splicing-out NTP-format timestamp is smaller than the value of 6
lower octets splicing-in NTP-format, it implies a wrap of the 48-bit
splicing-out NTP-format timestamp which means the top 16-bit value of
the 64-bit splicing-out is equal to the top 16-bit value of splicing-
in NTP Timestamp plus 0x01. Otherwise, the top 16 bits of splicing-
out NTP timestamp is equal to the top 16 bits of splicing-in NTP
Timestamp.
The format is shown in Figures 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID | L=14 | OUT NTP timestamp - Seconds |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
| OUT NTP timestamp format - Fraction (bit 0-31) |e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
| IN NTP timestamp format - Seconds (bit 0-31) |s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i
| IN NTP timestamp format - Fraction (bit 0-31) |o
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
Figure 2: Splicing Interval
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 intercepts the RTP header extension and derives the
Splicing Interval, it will generate its own stream and SHOULD NOT Splicing Interval, it will generate its own stream and SHOULD NOT
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
middlebox strips RTP header extensions. middlebox strips RTP header extensions. The main RTP sender MUST make
sure the splicing information contained in the RTCP splicing
notification message consistent with the information included in the
RTP header extensions.
The RTCP splicing notification message is a new RTCP packet type. It The RTCP splicing notification message is a new RTCP packet type. It
has a fixed header followed by a pair of NTP-format timestamps: has a fixed header followed by a pair of NTP-format timestamps:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|reserved | PT=TBA | length | |V=2|P|reserved | PT=TBA | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC | | SSRC |
skipping to change at page 7, line 49 skipping to change at page 8, line 42
As defined in [RFC3550], the length of the RTCP packet in 32-bit As defined in [RFC3550], the length of the RTCP packet in 32-bit
words minus one, including the header and any padding. words minus one, including the header and any padding.
SSRC: 32 bits SSRC: 32 bits
The SSRC of the Main RTP Sender. The SSRC of the Main RTP Sender.
Timestamp: 64 bits Timestamp: 64 bits
Indicates the wallclock time when this splicing starts and ends. Indicates the wallclock time when this splicing starts and ends.
The full-resolution NTP timestamp is used, which is a 64-bit, The full-resolution NTP-format timestamp is used, which is a 64-
unsigned, fixed-point number with the integer part in the first 32 bit, unsigned, fixed-point number with the integer part in the
bits and the fractional part in the last 32 bits. This format is first 32 bits and the fractional part in the last 32 bits. This
similar to the RTCP Sender Report (Section 6.4.1 of [RFC3550]). format is same as the NTP timestamp field in the RTCP Sender
Report (Section 6.4.1 of [RFC3550]).
The RTCP splicing notification message can be appended to RTCP SR the The RTCP splicing notification message can be included in the RTCP
main RTP sender generates in compound RTCP packets, and hence follows compound packet together with RTCP SR generated at the main RTP
the compound RTCP rules defined in Section 6.1 in [RFC3550]. sender, and hence follows the compound RTCP rules defined in Section
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. 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
drift happening before the splicing event, it may be required to send
RTCP SR or even updated Splicing Interval information timely to
update the timestamp mapping for accurate splicing.
When the splicer intercepts the RTCP splicing notification message, When the splicer intercepts the RTCP splicing notification message,
it SHOULD NOT forward the message to the down-stream receivers in it SHOULD NOT forward the message to the down-stream receivers in
order to reduce RTCP bandwidth consumption. And if the splicer wishes order to reduce RTCP bandwidth consumption. And if the splicer wishes
to prevent the downstream receivers from detecting splicing, it MUST to prevent the downstream receivers from detecting splicing, it MUST
NOT forward the message. NOT forward the message.
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
skipping to change at page 12, line 5 skipping to change at page 13, line 5
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
a=recvonly a=recvonly
a=mid:1 a=mid:1
m=video 40000 RTP/AVP 100 m=video 40000 RTP/AVP 100
i=Substitutive RTP Stream i=Substitutive RTP Stream
c=IN IP4 splicer.example.com c=IN IP4 splicer.example.com
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=recvonly a=recvonly
a=mid:2 a=mid:2
Only codecs that are supported both by the main RTP stream and the
substitutive RTP stream could be negotiated with SDP O/A. And the
splicer MUST choose the same codec for both of these two streams.
6.3 Offer/Answer with BUNDLE: All Media are spliced 6.3 Offer/Answer with BUNDLE: All Media are spliced
In this example, the bundled audio and video media have their own In this example, the bundled audio and video media have their own
substitutive media for splicing: substitutive media for splicing:
1. An Offer, in which the offerer assigns a unique address and a 1. An Offer, in which the offerer assigns a unique address and a
substitutive media to each bundled "m="line for splicing within the substitutive media to each bundled "m="line for splicing within the
BUNDLE group. BUNDLE group.
2. An answer, in which the answerer selects its own BUNDLE address, 2. An answer, in which the answerer selects its own BUNDLE address,
skipping to change at page 15, line 27 skipping to change at page 16, line 23
i=Substitutive video RTP Stream i=Substitutive video RTP Stream
c=IN IP4 splicer.example.com c=IN IP4 splicer.example.com
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=mid:2 a=mid:2
a=recvonly a=recvonly
7 Security Considerations 7 Security Considerations
The security considerations of the RTP specification [RFC3550] and The security considerations of the RTP specification [RFC3550] and
the general mechanism for RTP header extensions [RFC5285] apply. The the general mechanism for RTP header extensions [RFC5285] apply. The
splicer MUST either be a mixer or a translator, and has all the splicer can either be a mixer or a translator, and has all the
security considerations on these two standard RTP intermediaries. security considerations on these two standard RTP intermediaries.
However, the splicer replaces some content with other content in RTP However, the splicer replaces some content with other content in RTP
packet, thus breaking any RTP-level end-to-end security, such as packet, thus breaking any RTP-level end-to-end security, such as
source authentication and integrity protection. source authentication and integrity protection.
End to end source authentication is not possible with any known End to end source authentication is not possible with any known
existing splicing solution. A new solution can theoretically be existing splicing solution. A new solution can theoretically be
developed that enables identifying the participating entities and developed that enables identifying the participating entities and
what each provides, i.e., the different media sources, man and what each provides, i.e., the different media sources, main and
substituting, and the splicer providing the RTP-level integration of substituting, and the splicer providing the RTP-level integration of
the media payloads in a common timeline and synchronization context. the media payloads in a common timeline and synchronization context.
Since the mechanism introduced in this document is not dependent on Since splicer works as a trusted entity, any RTP-level or outside
any RTP payload-level hints for finding the splicing in and out security mechanism, such IPsec[RFC4301] or Datagram Transport Layer
points, Secure Real-Time Transport Protocol (SRTP) [3711] can be used Security [RFC6347], will use a security association between the
to provide confidentiality of the RTP payload while leaving the RTP splicer and the receiver. When using the Secure Real-Time Transport
header in the clear so that the splicer can still carry out splicing Protocol (SRTP) [RFC3711], the splicer could be provisioned with the
without keying materials. However, for a malicious endpoint without same security association as the main RTP sender.
the key, it can observe the splicing time in the RTP header, and it
can intercept the substitutive content and even replace it with a
different one if the substitutive stream does not use any security
like SRTP and the splicer does not authenticate the main and
substitutive content sources.
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, header extension encryption [RFC6904] SHOULD be used.
However, the malicious endpoint may get the splicing time information However, the malicious endpoint may get the splicing time information
by other means, e.g., inferring from the communication between the by other means, e.g., inferring from the communication between the
main and substitutive content sources. To avoid the insertion of main and substitutive content sources. To avoid the insertion of
invalid substitutive content, the splicer MUST have some mechanisms invalid substitutive content, the splicer MUST have some mechanisms
to authenticate the substitutive stream source. 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
skipping to change at page 17, line 36 skipping to change at page 18, line 27
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.
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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
 End of changes. 22 change blocks. 
66 lines changed or deleted 108 lines changed or added

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