draft-ietf-avtext-splicing-notification-08.txt | draft-ietf-avtext-splicing-notification-09.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: December 30, 2016 Huawei | Expires: February 4, 2017 Huawei | |||
L. Deng | L. Deng | |||
China Mobile | China Mobile | |||
June 28, 2016 | August 3, 2016 | |||
RTP/RTCP extension for RTP Splicing Notification | RTP/RTCP extension for RTP Splicing Notification | |||
draft-ietf-avtext-splicing-notification-08 | draft-ietf-avtext-splicing-notification-09 | |||
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 23 ¶ | skipping to change at page 3, line 23 ¶ | |||
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 need for such processing increases the workload of the middle box | The need for such processing increases the workload of the middle box | |||
and limits the number of RTP sessions the middle box can support. | 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 [RFC5285bis] 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 | |||
new RTCP packet type to carry the same Splicing Interval to the | new RTCP packet type to carry the same Splicing Interval to the | |||
skipping to change at page 5, line 11 ¶ | skipping to change at page 5, line 11 ¶ | |||
splicing begins, the splicer sends the substitutive content to the | splicing begins, the splicer sends the substitutive content to the | |||
receivers instead of the main content. When RTP splicing ends, the | receivers instead of the main content. When RTP splicing ends, the | |||
splicer switches back to sending the main content to the receivers. | splicer switches back to sending the main content to the receivers. | |||
This implies that the receiver is explicitly configured to receive | This implies that the receiver is explicitly configured to receive | |||
the traffic via the splicer, and will return any RTCP feedback to it | the traffic via the splicer, and will return any RTCP feedback to it | |||
in the presence of the splicer. | in the presence of the splicer. | |||
The middlebox working as the splicer can be implemented as either an | 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, | RTP mixer or as an RTP translator. If implemented as an RTP mixer, | |||
[RFC6828] specifies how the splicer can use its own SSRC, sequence | the splicer will use its own SSRC, sequence number space, and timing | |||
number space, and timing model when generating the output stream to | model when generating the output stream to receivers, using the CSRC | |||
receivers, using the CSRC list to indicate whether the original or | list to indicate whether the original or substitutive content is | |||
substitutive content is being delivered. The splicer, on behalf of | being delivered. The splicer, on behalf of the content provider, can | |||
the content provider, can omit the CSRC list from the RTP packets it | omit the CSRC list from the RTP packets it generates. This simplifies | |||
generates. This simplifies the design of the receivers, since they | the design of the receivers, since they don't need to parse the CSRC | |||
don't need to parse the CSRC list, but makes it harder to determine | list, but makes it harder to determine when the splicing is taking | |||
when the splicing is taking place (it requires inspection of the RTP | place (it requires inspection of the RTP payload data, rather than | |||
payload data, rather than just the RTP headers). A splicer working as | just the RTP headers). A splicer working as an RTP mixer splits the | |||
an RTP mixer splits the flow between the sender and receiver into | flow between the sender and receiver into two, and requires separate | |||
two, and requires separate control loops, for RTCP and congestion | control loops, for RTCP and congestion control. [RFC6828] offers an | |||
control, see Section 4.4 of [RFC6828]. | example of an RTP mixer approach. | |||
A splicer implemented as an RTP translator [RFC3550] will forward the | A splicer implemented as an RTP translator [RFC3550] will forward the | |||
RTP packets from the original and substitutive senders with their | RTP packets from the original and substitutive senders with their | |||
SSRCs intact, but will need to rewrite RTCP sender report packets to | SSRCs intact, but will need to rewrite RTCP sender report packets to | |||
account for the splicing. In this case, the congestion control loops | account for the splicing. In this case, the congestion control loops | |||
run between original sender and receiver, and between the | run between original sender and receiver, and between the | |||
substitutive sender and receiver. The splicer needs to ensure that | substitutive sender and receiver. The splicer needs to ensure that | |||
the RTCP feedback message from the receiver are passed to the right | the RTCP feedback message from the receiver are passed to the right | |||
sender to let the congestion control work. | sender to let the congestion control work. | |||
2.2 Overview of Splicing Interval | 2.2 Overview of Splicing Interval | |||
To handle splicing on the RTP layer at the reserved time slots set by | 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 | the main RTP sender, the splicer must first know the Splicing | |||
Interval from the main RTP sender before it can start splicing. The | Interval from the main RTP sender before it can start splicing. | |||
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 by RTP header extension or RTCP extension message more than once | sent by RTP header extension or RTCP extension message more than once | |||
to mitigate the possible packet loss. To enable the splicer to get | to mitigate the possible packet loss. To enable the splicer to get | |||
the substitutive content before the splicing starts, the main RTP | the substitutive content before the splicing starts, the main RTP | |||
sender MUST send the Splicing Interval far ahead. For example, the | sender MUST send the Splicing Interval far ahead. For example, the | |||
main RTP sender can estimate when to send the Splicing Interval based | main RTP sender can estimate when to send the Splicing Interval based | |||
on the round-trip time (RTT) following the mechanisms in section | on the round-trip time (RTT) following the mechanisms in section | |||
6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main sender. | 6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main sender. | |||
skipping to change at page 6, line 47 ¶ | skipping to change at page 6, line 46 ¶ | |||
timestamp in 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 [RFC5285bis] 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 7 octets splicing-out NTP- | This RTP header extension carries the 7 octets splicing-out NTP- | |||
format timestamp (lower 24-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 8 bits of the splicing-out NTP timestamp are | [RFC5905]). The top 8 bits of the splicing-out NTP timestamp are | |||
inferred from the top 8 bits of the splicing-in NTP timestamp, under | inferred from the top 8 bits of the splicing-in NTP timestamp, under | |||
skipping to change at page 7, line 24 ¶ | skipping to change at page 7, line 23 ¶ | |||
time, and the splicing interval is less than 2^25 seconds. Therefore, | time, and the splicing interval is less than 2^25 seconds. Therefore, | |||
if the value of 7 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 7 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 56-bit splicing-out NTP-format timestamp which means the | wrap of the 56-bit splicing-out NTP-format timestamp which means the | |||
top 8-bit value of the 64-bit splicing-out is equal to the top 8-bit | top 8-bit value of the 64-bit splicing-out is equal to the top 8-bit | |||
value of splicing-in NTP Timestamp plus 0x01. Otherwise, the top 8 | value of splicing-in NTP Timestamp plus 0x01. Otherwise, the top 8 | |||
bits of splicing-out NTP timestamp is equal to the top 8 bits of | bits of splicing-out NTP timestamp is equal to the top 8 bits 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 [RFC5285bis]. 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=14 | OUT NTP timestamp format - Seconds (bit 8-31) |x | | ID | L=14 | 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 | |||
skipping to change at page 11, line 37 ¶ | skipping to change at page 11, line 37 ¶ | |||
quality of the paths from the splicer to the receivers. | quality of the paths from the splicer to the receivers. | |||
A splicer that has an SSRC can choose to pass RTCP reception reports | A splicer that has an SSRC can choose to pass RTCP reception reports | |||
from the receivers back to the senders, after modifications to | from the receivers back to the senders, after modifications to | |||
account for the splicing. This will allow the senders the monitor the | account for the splicing. This will allow the senders the monitor the | |||
quality of the paths from the splicer to the receivers. A splicer | quality of the paths from the splicer to the receivers. A splicer | |||
that does not have its own SSRC has to forward and translation RTCP | that does not have its own SSRC has to forward and translation RTCP | |||
reports from the receiver, otherwise the senders will not see any | reports from the receiver, otherwise the senders will not see any | |||
receivers in the RTP session. | receivers in the RTP session. | |||
If the splicer is implemented following [RFC6828], it will have its | If the splicer is implemented as a mixer, it will have its own SSRC | |||
own SSRC and will send its own RTCP reports, and will forward | and will send its own RTCP reports, and will forward translated RTCP | |||
translated RTCP reports from the receivers. | reports from the receivers. | |||
Upon the detection of a failure, the splicer can communicate with the | Upon the detection of a failure, the splicer can communicate with the | |||
main sender and the substitutive sender in some out of band signaling | main sender and the substitutive sender in some out of band signaling | |||
ways to fall back to the payload specific mechanisms it supports, | ways to fall back to the payload specific mechanisms it supports, | |||
e.g., MPEG-TS splicing solution defined in [SCTE35], or just abandon | e.g., MPEG-TS splicing solution defined in [SCTE35], or just abandon | |||
the splicing. | the splicing. | |||
6 Session Description Protocol (SDP) Signaling | 6 Session Description Protocol (SDP) Signaling | |||
This document defines the URI for declaring this header extension in | This document defines the URI for declaring this header extension in | |||
skipping to change at page 17, line 22 ¶ | skipping to change at page 17, line 22 ¶ | |||
m=video 30004 RTP/AVP 32 | m=video 30004 RTP/AVP 32 | |||
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 [RFC5285bis] apply. | |||
splicer can either be a mixer or a translator, and all the security | The splicer can either be a mixer or a translator, and all the | |||
considerations of these two RTP intermediaries topologies described | security considerations of these two RTP intermediaries topologies | |||
in [RFC7667] and [RFC7201] are applicable for the splicer. | described in [RFC7667] and [RFC7201] are applicable for the splicer. | |||
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. | |||
skipping to change at page 18, line 42 ¶ | skipping to change at page 18, line 42 ¶ | |||
Long name: Splicing Notification Message | Long name: Splicing Notification Message | |||
Value: TBA | Value: TBA | |||
Reference: This document | Reference: This document | |||
8.2 RTP Compact Header Extensions | 8.2 RTP Compact Header Extensions | |||
The IANA has also registered a new RTP Compact Header Extension | The IANA has also registered a new RTP Compact Header Extension | |||
[RFC5285], according to the following: | [RFC5285bis], according to the following: | |||
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 | |||
skipping to change at page 19, 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. | |||
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP | [RFC5285bis] Even, R., Singer, D. and H. Desineni, "A General | |||
Header Extensions", RFC 5285, July 2008. | Mechanism for RTP Header Extensions", draft-ietf-avtcore- | |||
rfc5285-bis-02, May 2016. | ||||
[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. | |||
End of changes. 12 change blocks. | ||||
30 lines changed or deleted | 30 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/ |