draft-ietf-avtext-splicing-notification-01.txt   draft-ietf-avtext-splicing-notification-02.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: June 13, 2015 Huawei Expires: October 31, 2015 Huawei
L. Deng L. Deng
China Mobile China Mobile
December 10, 2014 April 29, 2015
RTP/RTCP extension for RTP Splicing Notification RTP/RTCP extension for RTP Splicing Notification
draft-ietf-avtext-splicing-notification-01 draft-ietf-avtext-splicing-notification-02
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 2, line 7 skipping to change at page 2, line 7
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 7 skipping to change at page 4, line 7
[RFC6828] applies to this document and in addition, we define: [RFC6828] applies to this document and in addition, we define:
Splicing Interval: Splicing Interval:
The NTP timestamps for the Splicing-In point and Splicing-Out The NTP timestamps for the Splicing-In point and Splicing-Out
point per [RFC6828] allowing the mixer to know when to start and point per [RFC6828] allowing the mixer to know when to start and
end the RTP splicing. end the RTP splicing.
2 Overview of RTP Splicing Notification 2 Overview of RTP Splicing Notification
According to RTP Splicing draft [RFC6828], a mixer is designed to According to [RFC6828], a mixer is designed to handle splicing on the
handle splicing on the RTP layer at the reserved time slots set by RTP layer at the reserved time slots set by the main RTP sender. This
the main RTP sender. This implies that the mixer must first know the implies that the mixer must first know the Splicing Interval from the
Splicing Interval from the main RTP sender before it can start main RTP sender before it can start splicing.
splicing.
When a new splicing is forthcoming, the main RTP sender MUST send the When a new splicing is forthcoming, the main RTP sender MUST send the
Splicing Interval to the mixer. Usually, the Splicing Interval SHOULD Splicing Interval to the mixer. Usually, the Splicing Interval SHOULD
be sent more than once to mitigate the possible packet loss. To be sent more than once to mitigate the possible packet loss. To
enable the mixer to get the substitutive content before the splicing enable the mixer to get the substitutive content before the splicing
starts, the main RTP sender MUST send the Splicing Interval far starts, the main RTP sender MUST send the Splicing Interval far
ahead. For example, the main RTP sender can estimate when to send the ahead. For example, the main RTP sender can estimate when to send the
Splicing Interval based on the round-trip time (RTT) following the Splicing Interval based on the round-trip time (RTT) following the
mechanisms in section 6.4.1 of [RFC3550] when the mixer sends RTCP RR mechanisms in section 6.4.1 of [RFC3550] when the mixer sends RTCP RR
to the main sender. to the main sender.
skipping to change at page 4, line 33 skipping to change at page 4, line 32
The substitutive sender also needs to learn the Splicing Interval The substitutive sender also needs to learn the Splicing Interval
from the main RTP sender in advance, and thus estimates when to from the main RTP sender in advance, and thus estimates when to
transfer the substitutive content to the mixer. The Splicing Interval transfer the substitutive content to the mixer. The Splicing Interval
could be transmitted from the main RTP sender to the substitutive could be transmitted from the main RTP sender to the substitutive
content using some out-of-band mechanisms, the details how to achieve content using some out-of-band mechanisms, the details how to achieve
that are beyond the scope of this memo. To ensure the Splicing that are beyond the scope of this memo. To ensure the Splicing
Interval is valid for both the main RTP sender and the substitutive Interval is valid for both the main RTP sender and the substitutive
RTP sender, the two senders MUST share a common reference clock, so RTP sender, the two senders MUST share a common reference clock, so
the mixer can achieve accurate splicing. the mixer can achieve accurate splicing.
In this document, the main RTP sender uses a couple of NTP-format In this document, the main RTP sender uses a pair of NTP-format
timestamps, derived from the common reference clock, to indicate when timestamps, derived from the common reference clock, to indicate when
to start and end the splicing to the mixer: the timestamp of the to start and end the splicing to the mixer: the timestamp of the
first substitutive RTP packet at the splicing in point, and the first substitutive RTP packet at the splicing in point, and the
timestamp of the first main RTP packet at the splicing out point. timestamp of the first main RTP packet at 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 mixer MUST ensure that the RTP prepare the substitutive stream. The mixer MUST ensure that the RTP
timestamp of the first substitutive RTP packet that would be timestamp of the first substitutive RTP packet that would be
presented to the receivers corresponds to the same time instant as presented to the receivers corresponds to the same time instant as
the former NTP timestamp in the Splicing Interval. To enable the the former NTP timestamp in the Splicing Interval. To enable the
mixer to know the first substitutive RTP packet it needs to send, the mixer to know the first substitutive RTP packet it needs to send, the
substitutive RTP sender MUST send the substitutive RTP packet ahead substitutive RTP sender MUST send the substitutive RTP packet ahead
of the Splicing In point, sllowing the mixer to find out the of the Splicing In point, allowing the mixer to find out the
timestamp of this first RTP packet in the substitutive RTP stream, timestamp of this first RTP packet in the substitutive RTP stream,
e.g., using a prior RTCP SR message. e.g., using a prior RTCP SR message.
When the splicing will end, the mixer MUST ensure that the RTP When the splicing will end, the mixer MUST ensure that the RTP
timestamp of the first main RTP packet that would be presented on the timestamp of the first main RTP packet that would be presented on the
receivers corresponds to the same time instant as the latter NTP receivers corresponds to the same time instant as the latter NTP
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 mixer: an RTP header extension and an the Splicing Interval to the mixer: 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 couple of NTP- adapted to carry the Splicing Interval consisting of a pair of NTP-
format timestamps. format timestamps.
One variant is defined for this header extension. It carries the 7 One variant is defined for this header extension. It carries the 7
octets splicing-out NTP timestamp (lower 24-bit part of the Seconds octets splicing-out NTP timestamp (lower 24-bit part of the Seconds
of a NTP-format timestamp and the 32 bits of the Fraction of a NTP- 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 format 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 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
referred from the top 8 bits of the splicing-in NTP timestamp. This referred from the top 8 bits of the splicing-in NTP timestamp. This
is unambiguous, under the assumption that the splicing-out time is is unambiguous, under the assumption that the splicing-out time is
skipping to change at page 6, line 24 skipping to change at page 6, line 21
or not, RTCP splicing notification message, specified in the next or not, RTCP splicing notification message, specified in the next
section, MUST be sent to provide robustness in case of any splicing- section, MUST be sent to provide robustness in case of any splicing-
unaware middlebox that might strip RTP header extensions. unaware middlebox that might strip RTP header extensions.
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.
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 fix header followed by a couple of NTP-format timestamps: has a fix 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN NTP Timestamp (most significant word) | | IN NTP Timestamp (most significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 26 skipping to change at page 7, line 22
The RTCP splicing notification message can be appended to RTCP SR the The RTCP splicing notification message can be appended to RTCP SR the
main RTP sender generates in compound RTCP packets, and hence follows main RTP sender generates in compound RTCP packets, and hence follows
the compound RTCP rules defined in Section 6.1 in [RFC3550]. 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 mixer, the RTCP splicing notification between the sender and the mixer, the RTCP splicing notification
message may be sent as non-compound RTCP packets. message may be sent as non-compound RTCP packets.
When the mixer intercepts the RTCP splicing notification message, it When the mixer intercepts the RTCP splicing notification message, it
MAY NOT forward the message to the receivers in order to reduce RTCP SHOULD NOT forward the message to the receivers in order to reduce
bandwidth consumption or to avoid downstream receivers from detecting RTCP bandwidth consumption. And it MUST NOT forward the message to
splicing defined in Section 4.5 in [RFC6828]. the downstream receivers to avoid them from detecting splicing
defined in Section 4.5 in [RFC6828].
4 Reducing Splicing Latency 4 Reducing Splicing Latency
When splicing starts or ends, the mixer outputs the multimedia When splicing starts or ends, the mixer outputs the multimedia
content from another sender to the receivers. Given that the content from another sender to the receivers. Given that the
receivers must first acquire certain information ([RFC6285] refers to receivers must first acquire certain information ([RFC6285] refers to
this information as Reference Information) to start processing the this information as Reference Information) to start processing the
multimedia data, either the main RTP sender or the substitutive multimedia data, either the main RTP sender or the substitutive
sender SHOULD provide the Reference Information align with its sender SHOULD provide the Reference Information align with its
multimedia content to reduce the delay caused by acquiring the multimedia content to reduce the delay caused by acquiring the
skipping to change at page 8, line 37 skipping to change at page 8, line 37
substitutive sender SHOULD check the path to the failed mixer, or substitutive sender SHOULD check the path to the failed mixer, or
fallback to the payload specific mechanisms, e.g., MPEG-TS splicing fallback to the payload specific mechanisms, e.g., MPEG-TS splicing
solution defined in [SCTE35]. solution defined in [SCTE35].
6 SDP Signaling 6 SDP Signaling
This document defines the URI for declaring this header extension in This document defines the URI for declaring this header extension in
an extmap attribute to be "urn:ietf:params:rtp-hdrext:splicing- an extmap attribute to be "urn:ietf:params:rtp-hdrext:splicing-
interval". interval".
This document extended the standard semantics defined in SDP Grouping This document extends the standard semantics defined in SDP Grouping
Framework [RFC5888] with a new semantic: SPLICE to represent the Framework [RFC5888] with a new semantic: SPLICE to represent the
relationship between the main RTP stream and the substitutive RTP relationship between the main RTP stream and the substitutive RTP
stream. The main RTP sender provides the information about both main stream. Only 2 m-lines are allowed in the SPLICE group. The main RTP
and substitutive sources. stream is the one with the extended extmap attribute, and the other
one is substitutive stream. A single m-line MUST NOT be included in
different SPLICE groups at the same time. The main RTP sender
provides the information about both main and substitutive sources.
The extended SDP attribute specified in this document is applicable The extended SDP attribute specified in this document is applicable
for offer/answer content [RFC3264] and do not affect any rules when for offer/answer content [RFC3264] and do not affect any rules when
negotiating offer and answer. When used with multiple media, negotiating offer and answer. When used with multiple media,
substitutive RTP MUST be applied only to the RTP packets whose SDP m- substitutive RTP MUST be applied only to the RTP packets whose SDP m-
line is in the same group with the substitutive stream using FID and line is in the same group with the substitutive stream using SPLICE
has the extended splicing extmap attribute. This semantics is to have and has the extended splicing extmap attribute. This semantics is
splicing applicable for BUNDLE cases. also applicable for BUNDLE cases.
The following examples show how SDP signaling could be used for The following examples show how SDP signaling could be used for
splicing in different cases. splicing in different cases.
6.1 Declarative SDP 6.1 Declarative SDP
v=0 v=0
o=xia 1122334455 1122334466 IN IP4 splicing.example.com o=xia 1122334455 1122334466 IN IP4 splicing.example.com
s=RTP Splicing Example s=RTP Splicing Example
t=0 0 t=0 0
skipping to change at page 10, line 4 skipping to change at page 10, line 7
o=xia 1122334455 1122334466 IN IP4 splicing.example.com o=xia 1122334455 1122334466 IN IP4 splicing.example.com
s=RTP Splicing Example s=RTP Splicing Example
t=0 0 t=0 0
a=group:SPLICE 1 2 a=group:SPLICE 1 2
m=video 30000 RTP/AVP 31 100 m=video 30000 RTP/AVP 31 100
i=Main RTP Stream i=Main RTP Stream
c=IN IP4 splicing.example.com c=IN IP4 splicing.example.com
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
a=sendonly
a=mid:1 a=mid:1
m=video 40000 RTP/AVP 31 100 m=video 40000 RTP/AVP 31 100
i=Substitutive RTP Stream i=Substitutive RTP Stream
c=IN IP4 substitutive.example.com c=IN IP4 substitutive.example.com
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:100 MP2T/90000 a=rtpmap:100 MP2T/90000
a=sendonly a=sendonly
a=mid:2 a=mid:2
SDP Answer - from splicer SDP Answer - from splicer
skipping to change at page 10, line 25 skipping to change at page 10, line 29
v=0 v=0
o=xia 1122334455 1122334466 IN IP4 splicer.example.com o=xia 1122334455 1122334466 IN IP4 splicer.example.com
s=RTP Splicing Example s=RTP Splicing Example
t=0 0 t=0 0
a=group:SPLICE 1 2 a=group:SPLICE 1 2
m=video 30000 RTP/AVP 100 m=video 30000 RTP/AVP 100
i=Main RTP Stream i=Main 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=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
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 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 substitutive RTP stream could be negotiated with SDP O/A. And the
skipping to change at page 11, line 19 skipping to change at page 11, line 25
a=group:SPLICE foo 1 a=group:SPLICE foo 1
a=group:SPLICE bar 2 a=group:SPLICE bar 2
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
a=sendonly
m=video 10002 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
a=sendonly
m=audio 20000 RTP/AVP 0 8 97 m=audio 20000 RTP/AVP 0 8 97
i=Substitutive audio RTP Stream i=Substitutive audio RTP Stream
c=IN IP4 substitive.example.com c=IN IP4 substitive.example.com
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=sendonly a=sendonly
a=mid:1 a=mid:1
m=video 20002 RTP/AVP 31 32 m=video 20002 RTP/AVP 31 32
i=Substitutive video RTP Stream i=Substitutive video RTP Stream
c=IN IP4 substitive.example.com c=IN IP4 substitive.example.com
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=mid:2 a=mid:2
a=sendonly
SDP Answer - from the splicer SDP Answer - from the splicer
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 splicer.example.com o=bob 2808844564 2808844564 IN IP4 splicer.example.com
s=RTP Splicing Example s=RTP Splicing Example
c=IN IP4 splicer.example.com c=IN IP4 splicer.example.com
t=0 0 t=0 0
a=group:SPLICE foo 1 a=group:SPLICE foo 1
a=group:SPLICE bar 2 a=group:SPLICE bar 2
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval
a=recvonly
m=video 30000 RTP/AVP 32 m=video 30000 RTP/AVP 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
a=recvonly
m=audio 30002 RTP/AVP 0 m=audio 30002 RTP/AVP 0
i=Substitutive audio RTP Stream i=Substitutive audio RTP Stream
c=IN IP4 splicer.example.com c=IN IP4 splicer.example.com
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=sendonly a=recvonly
a=mid:1 a=mid:1
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
6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced 6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced
In this example, the substitutive media only applies for video when In this example, the substitutive media only applies for video when
splicing: splicing:
1. An Offer, in which the offerer assigns a unique address to each 1. An Offer, in which the offerer assigns a unique address to each
bundled "m="line within the BUNDLE group, and assigns a substitutive bundled "m="line within the BUNDLE group, and assigns a substitutive
media to the bundled video "m=" line for splicing. media to the bundled video "m=" line for splicing.
skipping to change at page 12, line 51 skipping to change at page 13, line 15
c=IN IP4 splicing.example.com c=IN IP4 splicing.example.com
t=0 0 t=0 0
a=group:SPLICE bar 2 a=group:SPLICE bar 2
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97 m=audio 10000 RTP/AVP 0 8 97
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000 a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000 a=rtpmap:97 iLBC/8000
a=sendonly
m=video 10002 RTP/AVP 31 32 m=video 10002 RTP/AVP 31 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
a=sendonly
m=video 20000 RTP/AVP 31 32 m=video 20000 RTP/AVP 31 32
i=Substitutive video RTP Stream i=Substitutive video RTP Stream
c=IN IP4 substitutive.example.com c=IN IP4 substitutive.example.com
a=rtpmap:31 H261/90000 a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=mid:2 a=mid:2
a=sendonly
SDP Answer - from the splicer: SDP Answer - from the splicer:
v=0 v=0
o=bob 2808844564 2808844564 IN IP4 splicer.example.com o=bob 2808844564 2808844564 IN IP4 splicer.example.com
s=RTP Splicing Example s=RTP Splicing Example
c=IN IP4 splicer.example.com c=IN IP4 splicer.example.com
t=0 0 t=0 0
a=group:SPLICE bar 2 a=group:SPLICE bar 2
a=group:BUNDLE foo bar a=group:BUNDLE foo bar
m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0
a=mid:foo a=mid:foo
b=AS:200 b=AS:200
a=rtpmap:0 PCMU/8000 a=rtpmap:0 PCMU/8000
a=recvonly
m=video 30000 RTP/AVP 32 m=video 30000 RTP/AVP 32
a=mid:bar a=mid:bar
b=AS:1000 b=AS:1000
a=rtpmap:32 MPV/90000 a=rtpmap:32 MPV/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval
a=recvonly
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
7 Security Considerations 7 Security Considerations
The security considerations of the RTP specification [RFC3550], the The security considerations of the RTP specification [RFC3550], the
general mechanism for RTP header extensions [RFC5285] and the general mechanism for RTP header extensions [RFC5285] and the
security considerations of the RTP splicing specification [RFC6828] security considerations of the RTP splicing specification [RFC6828]
apply. apply.
The RTP header extension defined in Section 4.1 include two NTP- The RTP header extension defined in Section 4.1 include two NTP-
format timestamps. In the Secure Real-time Transport Protocol format timestamps. In the Secure Real-time Transport Protocol
(SRTP)[RFC3711], RTP header extensions are authenticated but not (SRTP)[RFC3711], RTP header extensions are authenticated but not
encrypted. A malicious endpoint possessing the SRTP key could choose encrypted. For a malicious endpoint without the key, it can observe
to set the values in this header extension falsely, so as to falsely the splicing time in the RTP header, and it can intercept the
claim the splicing time. Also, such a malicious endpoint could cause substitutive content and even replace it with a different one if the
any arbitrary content it wishes spliced into the main RTP stream. splicer does not use any security like SRTP and authenticate the main
and substitutive content sources.
In scenarios where this is a concern, additional mechanisms MUST be If there is a concern about the confidentiality of the splicing time
used to protect the confidentiality of the header extension. This information, header extension encryption [RFC6904] SHOULD be used.
mechanism could be header extension encryption [SRTP-ENCR-HDR], or a However, the malicious endpoint can get the splicing time information
lower-level security and authentication mechanism such as IPsec by other means, e.g., observing the RTP timestamp of the substitutive
[RFC4301]. stream. To protect from different substitutive contents are inserted,
the splicer MUST have some mechanisms to authenticate the
substitutive stream source.
For cases that the splicing time information is changed by a
malicious endpoint, the splicing may fail since it will not be
available at the right time for the substitutive media to arrive,
which 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 15, line 20 skipping to change at page 16, line 4
TBD TBD
10 References 10 References
10.1 Normative References 10.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model
Description Protocol", RFC 4566, July 2006. with the Session Description Protocol (SDP)", RFC 3264,
June 2002.
[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.
[RFC6828] Xia, J., "Content Splicing for RTP Sessions", RFC 6828,
January 2013.
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.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[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.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009. and Consequences", RFC 5506, April 2009.
[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,
"Unicast-Based Rapid Acquisition of Multicast RTP "Unicast-Based Rapid Acquisition of Multicast RTP
Sessions", RFC 6285, June 2011. Sessions", RFC 6285, June 2011.
[RFC6904] Lennox, J.,"Encryption of Header Extensions in the Secure [RFC6904] Lennox, J.,"Encryption of Header Extensions in the Secure
Real-Time Transport Protocol (SRTP)", April 2013. Real-Time Transport Protocol (SRTP)", April 2013.
[SCTE35] Society of Cable Telecommunications Engineers (SCTE), [SCTE35] Society of Cable Telecommunications Engineers (SCTE),
"Digital Program Insertion Cueing Message for Cable", "Digital Program Insertion Cueing Message for Cable",
2011. 2011.
[RFC6828] Xia, J., "Content Splicing for RTP Sessions", RFC 6828,
January 2013.
Authors' Addresses Authors' Addresses
Jinwei Xia Jinwei Xia
Huawei Huawei
Email: xiajinwei@huawei.com Email: xiajinwei@huawei.com
Roni Even Roni Even
Huawei Huawei
 End of changes. 35 change blocks. 
40 lines changed or deleted 68 lines changed or added

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