draft-ietf-avtext-splicing-notification-06.txt   draft-ietf-avtext-splicing-notification-07.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: October 8, 2016 Huawei Expires: November 18, 2016 Huawei
L. Deng L. Deng
China Mobile China Mobile
April 6, 2016 May 17, 2016
RTP/RTCP extension for RTP Splicing Notification RTP/RTCP extension for RTP Splicing Notification
draft-ietf-avtext-splicing-notification-06 draft-ietf-avtext-splicing-notification-07
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 11 skipping to change at page 3, line 11
10.1 Normative References . . . . . . . . . . . . . . . . . . . 15 10.1 Normative References . . . . . . . . . . . . . . . . . . . 15
10.2 Informative References . . . . . . . . . . . . . . . . . . 15 10.2 Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1 Introduction 1 Introduction
Splicing is a process that replaces some multimedia content with Splicing is a process that replaces some multimedia content with
other multimedia content and delivers the substitutive multimedia other multimedia content and delivers the substitutive multimedia
content to the receivers for a period of time. In some predictable content to the receivers for a period of time. In some predictable
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. needs to be inside of the specific, pre-designated time slot. Certain
Certain timing information about when to start and end the splicing timing information about when to start and end the splicing must be
must be first acquired by the splicer in order to start the splicing. first acquired by the splicer in order to start the splicing. This
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 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.
skipping to change at page 6, line 8 skipping to change at page 6, line 8
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.
This RTP header extension carries the 6 octets splicing-out NTP- This RTP header extension carries the 7 octets splicing-out NTP-
format timestamp (lower 16-bit part of the Seconds of a NTP-format format timestamp (lower 24-bit part of the Seconds of a NTP-format
timestamp and the 32 bits of the Fraction of a NTP-format timestamp 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- as defined in [RFC5905]), followed by the 8 octets splicing-in NTP-
format timestamp (64-bit NTP-format timestamp as defined in format timestamp (64-bit NTP-format timestamp as defined in
[RFC5905]). The top 16 bits of the splicing-out NTP timestamp are [RFC5905]). The top 8 bits of the splicing-out NTP timestamp are
inferred from the top 16 bits of the splicing-in NTP timestamp, under inferred from the top 8 bits of the splicing-in NTP timestamp, under
the assumption that the splicing-out time is after the splicing-in the assumption that the splicing-out time is after the splicing-in
time, and the splicing interval is less than 2^16 seconds. Therefore, time, and the splicing interval is less than 2^25 seconds. Therefore,
if the value of 6 octets splicing-out NTP-format timestamp is smaller if the value of 7 octets splicing-out NTP-format timestamp is smaller
than the value of 6 lower octets splicing-in NTP-format, it implies a than the value of 7 lower octets splicing-in NTP-format, it implies a
wrap of the 48-bit splicing-out NTP-format timestamp which means the wrap of the 56-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- top 8-bit value of the 64-bit splicing-out is equal to the top 8-bit
bit value of splicing-in NTP Timestamp plus 0x0001. Otherwise, the value of splicing-in NTP Timestamp plus 0x01. Otherwise, the top 8
top 16 bits of splicing-out NTP timestamp is equal to the top 16 bits bits of splicing-out NTP timestamp is equal to the top 8 bits of
of splicing-in NTP Timestamp. splicing-in NTP Timestamp.
This RTP header extension can be encoded using either the one-byte or This RTP header extension can be encoded using either the one-byte or
two-byte header defined in [RFC5285]. Figure 1 and 2 show the two-byte header defined in [RFC5285]. Figure 1 and 2 show the
splicing interval header extension with each of the two header splicing interval header extension with each of the two header
formats. formats.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID | L=13 |OUT NTP timestamp-Seconds(0-16)| Out |x | ID | L=14 | OUT NTP timestamp format - Seconds (bit 8-31) |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
| NTP timestamp format - Fraction (bit 0-31) | In |e | OUT NTP timestamp format - Fraction (bit 0-31) |e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
| NTP timestamp format - Seconds (bit 0-31) | In |s | IN NTP timestamp format - Seconds (bit 0-31) |s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i
| NTP timestamp format - Fraction (bit 0-31) | 0 (pad) |o | IN NTP timestamp format - Fraction (bit 0-31) |o
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
Figure 1: Splicing Interval Figure 1: Splicing Interval
Using the One-Byte Header Format Using the One-Byte Header Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E
| ID | L=14 | OUT NTP timestamp - Seconds |x | ID | L=15 | OUT NTP timestamp - Seconds |x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t
| OUT NTP timestamp format - Fraction (bit 0-31) |e |Out Secds(cont)| OUT NTP timestamp format - Fraction |e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
| IN NTP timestamp format - Seconds (bit 0-31) |s |Out Fract(cont)| IN NTP timestamp format - Seconds |s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i
| IN NTP timestamp format - Fraction (bit 0-31) |o | In Secds(cont)| IN NTP timestamp format - Fraction |o
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n
| In Fract(cont)| 0 (pad) | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 intercepts the RTP header extension and derives the
skipping to change at page 16, line 23 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 can either be a mixer or a translator, and has all the splicer can either be a mixer or a translator, and all the security
security considerations on these two standard RTP intermediaries. considerations of these two RTP intermediaries topologies described
However, the splicer replaces some content with other content in RTP in [RFC7667] and [RFC7201] are applicable for the splicer.
packet, thus breaking any RTP-level end-to-end security, such as
source authentication and integrity protection.
End to end source authentication is not possible with any known The splicer replaces some content with other content in RTP packet,
existing splicing solution. A new solution can theoretically be thus breaking any RTP-level end-to-end security, such as source
developed that enables identifying the participating entities and authentication and integrity protection. End to end source
what each provides, i.e., the different media sources, main and authentication is not possible with any known existing splicing
substituting, and the splicer providing the RTP-level integration of solution. A new solution can theoretically be developed that enables
the media payloads in a common timeline and synchronization context. identification of the participating entities and what each provides,
i.e., the different media sources, main and substituting, and the
splicer which provides the RTP-level integration of the media
payloads in a common timeline and synchronization context.
Since splicer works as a trusted entity, any RTP-level or outside Since splicer works as a trusted entity, any RTP-level or outside
security mechanism, such IPsec[RFC4301] or Datagram Transport Layer security mechanism, such as IPsec[RFC4301] or Datagram Transport
Security [RFC6347], will use a security association between the Layer Security [RFC6347], will use a security association between the
splicer and the receiver. When using the Secure Real-Time Transport splicer and the receiver. When using the Secure Real-Time Transport
Protocol (SRTP) [RFC3711], the splicer could be provisioned with the Protocol (SRTP) [RFC3711], the splicer could be provisioned with the
same security association as the main RTP sender. 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, 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
malicious endpoint, the splicing may fail since it will not be malicious endpoint, the splicing, for example, may fail since it will
available at the right time for the substitutive media to arrive, not be available at the right time for the substitutive media to
which may also break an undetectable splicing. To mitigate this arrive. Another case is that an attacker may prevent the receivers
effect, the splicer SHOULD NOT forward the splicing time information receiving the content from the main sender by inserting extra
RTP header extension defined in Section 4.1 to the receivers. And it splicing time information. To avoid the above cases happening, the
MUST NOT forward this header extension when considering an authentication of the RTP header extension for splicing time
undetectable splicing. information SHOULD be considered.
A malicious endpoint may also break an undetectable splicing. To
mitigate this effect, the splicer SHOULD NOT forward the splicing
time information RTP header extension defined in Section 4.1 to the
receivers. And it MUST NOT forward this header extension when
considering an undetectable splicing.
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 18, line 46 skipping to change at page 19, line 5
[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 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, April 2014.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
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)",
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. 21 change blocks. 
47 lines changed or deleted 62 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/