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/ |