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/