idnits 2.17.1 draft-ietf-avtext-splicing-notification-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: When the mixer intercepts the RTCP splicing notification message, it MAY NOT forward the message to the receivers in order to reduce RTCP bandwidth consumption or to avoid downstream receivers from detecting splicing defined in Section 4.5 in [RFC6828]. -- The document date (December 10, 2014) is 3417 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3264' is mentioned on line 362, but not defined == Missing Reference: 'SRTP-ENCR-HDR' is mentioned on line 613, but not defined == Unused Reference: 'RFC4566' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'RFC6904' is defined on line 713, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) ** Downref: Normative reference to an Informational RFC: RFC 6828 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTEXT Working Group J. Xia 3 INTERNET-DRAFT R. Even 4 Intended Status: Standards Track R. Huang 5 Expires: June 13, 2015 Huawei 6 L. Deng 7 China Mobile 8 December 10, 2014 10 RTP/RTCP extension for RTP Splicing Notification 11 draft-ietf-avtext-splicing-notification-01 13 Abstract 15 Content splicing is a process that replaces the content of a main 16 multimedia stream with other multimedia content, and delivers the 17 substitutive multimedia content to the receivers for a period of 18 time. The splicer is designed to handle RTP splicing and needs to 19 know when to start and end the splicing. 21 This memo defines two RTP/RTCP extensions to indicate the splicing 22 related information to the splicer: an RTP header extension that 23 conveys the information in-band and an RTCP packet that conveys the 24 information out-of-band. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as 34 Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright and License Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2 Overview of RTP Splicing Notification . . . . . . . . . . . . . 4 67 3 Conveying Splicing Interval in RTP/RTCP extensions . . . . . . 5 68 3.1 RTP Header Extension . . . . . . . . . . . . . . . . . . . . 5 69 3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6 70 4 Reducing Splicing Latency . . . . . . . . . . . . . . . . . . . 7 71 5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 6.1 Declarative SDP . . . . . . . . . . . . . . . . . . . . . . 9 74 6.2 Offer/Answer without BUNDLE . . . . . . . . . . . . . . . . 9 75 6.3 Offer/Answer with BUNDLE: All Media are spliced . . . . . . 10 76 6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced . . 12 77 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 78 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 79 8.1 RTCP Control Packet Types . . . . . . . . . . . . . . . . . 14 80 8.2 RTP Compact Header Extensions . . . . . . . . . . . . . . . 14 81 8.3 SDP Grouping Semantic Extension . . . . . . . . . . . . . . 14 82 9 Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 10.1 Normative References . . . . . . . . . . . . . . . . . . . 15 85 10.2 Informative References . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 88 1 Introduction 90 Splicing is a process that replaces some multimedia content with 91 other multimedia content and delivers the substitutive multimedia 92 content to the receivers for a period of time. In some predictable 93 splicing cases, e.g., advertisement insertion, the splicing duration 94 MUST be inside of the specific, pre-designated time slot. Certain 95 timing information about when to start and end the splicing must be 96 first acquired by the splicer in order to start the splicing. This 97 document refers to this information as Splicing Interval. 99 [SCTE35] provides a method that encapsulates the Splicing Interval 100 inside the MPEG2-TS layer in cable TV systems. But in the RTP 101 splicing scenario described in [RFC6828], the RTP mixer designed as 102 the splicer has to decode the RTP packets and search for the Splicing 103 Interval inside the payloads. The need for such processing increases 104 the workload of the mixer and limits the number of RTP sessions the 105 mixer can support. 107 The document defines an RTP header extension [RFC5285] used by the 108 main RTP sender to provide the Splicing Interval by including it in 109 the RTP packets. 111 Nevertheless, the Splicing Interval conveyed in the RTP header 112 extension might not reach the mixer successfully, any splicing un- 113 aware middlebox on the path between the RTP sender and the mixer 114 might strip this RTP header extension. 116 To increase robustness against such case, the document also defines a 117 new RTCP packet type in a complementary fashion to carry the same 118 Splicing Interval to the mixer. 120 1.1 Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 The terminology defined in "Content Splicing for RTP Sessions" 127 [RFC6828] applies to this document and in addition, we define: 129 Splicing Interval: 131 The NTP timestamps for the Splicing-In point and Splicing-Out 132 point per [RFC6828] allowing the mixer to know when to start and 133 end the RTP splicing. 135 2 Overview of RTP Splicing Notification 137 According to RTP Splicing draft [RFC6828], a mixer is designed to 138 handle splicing on the RTP layer at the reserved time slots set by 139 the main RTP sender. This implies that the mixer must first know the 140 Splicing Interval from the main RTP sender before it can start 141 splicing. 143 When a new splicing is forthcoming, the main RTP sender MUST send the 144 Splicing Interval to the mixer. Usually, the Splicing Interval SHOULD 145 be sent more than once to mitigate the possible packet loss. To 146 enable the mixer to get the substitutive content before the splicing 147 starts, the main RTP sender MUST send the Splicing Interval far 148 ahead. For example, the main RTP sender can estimate when to send the 149 Splicing Interval based on the round-trip time (RTT) following the 150 mechanisms in section 6.4.1 of [RFC3550] when the mixer sends RTCP RR 151 to the main sender. 153 The substitutive sender also needs to learn the Splicing Interval 154 from the main RTP sender in advance, and thus estimates when to 155 transfer the substitutive content to the mixer. The Splicing Interval 156 could be transmitted from the main RTP sender to the substitutive 157 content using some out-of-band mechanisms, the details how to achieve 158 that are beyond the scope of this memo. To ensure the Splicing 159 Interval is valid for both the main RTP sender and the substitutive 160 RTP sender, the two senders MUST share a common reference clock, so 161 the mixer can achieve accurate splicing. 163 In this document, the main RTP sender uses a couple of NTP-format 164 timestamps, derived from the common reference clock, to indicate when 165 to start and end the splicing to the mixer: the timestamp of the 166 first substitutive RTP packet at the splicing in point, and the 167 timestamp of the first main RTP packet at the splicing out point. 169 When the substitutive RTP sender gets the Splicing Interval, it must 170 prepare the substitutive stream. The mixer MUST ensure that the RTP 171 timestamp of the first substitutive RTP packet that would be 172 presented to the receivers corresponds to the same time instant as 173 the former NTP timestamp in the Splicing Interval. To enable the 174 mixer to know the first substitutive RTP packet it needs to send, the 175 substitutive RTP sender MUST send the substitutive RTP packet ahead 176 of the Splicing In point, sllowing the mixer to find out the 177 timestamp of this first RTP packet in the substitutive RTP stream, 178 e.g., using a prior RTCP SR message. 180 When the splicing will end, the mixer MUST ensure that the RTP 181 timestamp of the first main RTP packet that would be presented on the 182 receivers corresponds to the same time instant as the latter NTP 183 timestamp in the Splicing Interval. 185 3 Conveying Splicing Interval in RTP/RTCP extensions 187 This memo defines two backwards compatible RTP extensions to convey 188 the Splicing Interval to the mixer: an RTP header extension and an 189 RTCP splicing notification message. 191 3.1 RTP Header Extension 193 The RTP header extension mechanism defined in [RFC5285] can be 194 adapted to carry the Splicing Interval consisting of a couple of NTP- 195 format timestamps. 197 One variant is defined for this header extension. It carries the 7 198 octets splicing-out NTP timestamp (lower 24-bit part of the Seconds 199 of a NTP-format timestamp and the 32 bits of the Fraction of a NTP- 200 format timestamp as defined in [RFC5905]), followed by the 8 octets 201 splicing-in NTP timestamp (64-bit NTP-format timestamp as defined in 202 [RFC5905]). The top 8 bits of the splicing-out NTP timestamp are 203 referred from the top 8 bits of the splicing-in NTP timestamp. This 204 is unambiguous, under the assumption that the splicing-out time is 205 after the splicing-in time, and the splicing interval is less than 206 2^25 seconds. 208 The format is shown in Figures 1. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | 0xBE | 0xDE | length=4 | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E 215 | ID | L=15 | OUT NTP timestamp format - Seconds (bit 8-31) |x 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t 217 | OUT NTP timestamp format - Fraction (bit 0-31) |e 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 219 | IN NTP timestamp format - Seconds (bit 0-31) |s 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i 221 | IN NTP timestamp format - Fraction (bit 0-31) |o 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 224 Figure 1: Sample hybrid NTP Encoding Using 225 the One-Byte Header Format 227 Note that the inclusion of an RTP header extension will reduce the 228 efficiency of RTP header compression. It is RECOMMENDED that the main 229 sender begins to insert the RTP header extensions into a number of 230 RTP packets prior to the splicing in, while leaving the remaining RTP 231 packets unmarked. 233 After the mixer intercepts the RTP header extension and derives the 234 Splicing Interval, it will generate its own stream and SHOULD NOT 235 include the RTP header extension in outgoing packets to reduce header 236 overhead. 238 Furthermore, whether the in-band NTP-format timestamps are included 239 or not, RTCP splicing notification message, specified in the next 240 section, MUST be sent to provide robustness in case of any splicing- 241 unaware middlebox that might strip RTP header extensions. 243 3.2 RTCP Splicing Notification Message 245 In addition to the RTP header extension, the main RTP sender includes 246 the Splicing Interval in an RTCP splicing notification message. 248 The RTCP splicing notification message is a new RTCP packet type. It 249 has a fix header followed by a couple of NTP-format timestamps: 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 |V=2|P|reserved | PT=TBA | length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | SSRC | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | IN NTP Timestamp (most significant word) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | IN NTP Timestamp (least significant word) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | OUT NTP Timestamp (most significant word) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | OUT NTP Timestamp (least significant word) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 2: RTCP Splicing Notification Message 269 The RSI packet includes the following fields: 271 Length: 16 bits 273 As defined in [RFC3550], the length of the RTCP packet in 32-bit 274 words minus one, including the header and any padding. 276 SSRC: 32 bits 278 The SSRC of the Main RTP Sender. 280 Timestamp: 64 bits 282 Indicates the wallclock time when this splicing starts and ends. 283 The full-resolution NTP timestamp is used, which is a 64-bit, 284 unsigned, fixed-point number with the integer part in the first 32 285 bits and the fractional part in the last 32 bits. This format is 286 similar to RTCP Sender Report (Section 6.4.1 of [RFC3550]). 288 The RTCP splicing notification message can be appended to RTCP SR the 289 main RTP sender generates in compound RTCP packets, and hence follows 290 the compound RTCP rules defined in Section 6.1 in [RFC3550]. 292 If the use of non-compound RTCP [RFC5506] was previously negotiated 293 between the sender and the mixer, the RTCP splicing notification 294 message may be sent as non-compound RTCP packets. 296 When the mixer intercepts the RTCP splicing notification message, it 297 MAY NOT forward the message to the receivers in order to reduce RTCP 298 bandwidth consumption or to avoid downstream receivers from detecting 299 splicing defined in Section 4.5 in [RFC6828]. 301 4 Reducing Splicing Latency 303 When splicing starts or ends, the mixer outputs the multimedia 304 content from another sender to the receivers. Given that the 305 receivers must first acquire certain information ([RFC6285] refers to 306 this information as Reference Information) to start processing the 307 multimedia data, either the main RTP sender or the substitutive 308 sender SHOULD provide the Reference Information align with its 309 multimedia content to reduce the delay caused by acquiring the 310 Reference Information. The methods by which the Reference Information 311 is distributed to the receivers is out of scope of this memo. 313 Another latency element is synchronization caused delay. The 314 receivers must receive enough synchronization metadata prior to 315 synchronizing the separate components of the multimedia streams when 316 splicing starts or ends. Either the main RTP sender or the 317 substitutive sender SHOULD send the synchronization metadata early 318 enough so that the receivers can play out the multimedia in a 319 synchronized fashion. The mechanisms defined in [RFC6051] are 320 RECOMMENDED to be adopted to reduce the possible synchronization 321 delay. 323 5 Failure Cases 325 This section examines the implications of losing RTCP splicing 326 notification message and other failure case, e.g., the RTP header 327 extension is stripped on the path. 329 Given that there may be splicing un-aware middlebox on the path 330 between the main RTP sender and the mixer, one heuristics will be 331 used to verify whether or not the Splicing Interval reaches the 332 mixers. 334 If the mixer does not get the Splicing Interval when the splicing 335 starts, it will still output the main content to the downstream 336 receivers and forward the RTCP RR packets sent from downstream 337 receivers to the main RTP sender (see section 4.2 of [RFC6828]). In 338 such case, the main RTP sender can learn that splicing failed. 340 In a similar manner, the substitutive sender can learn that splicing 341 failed if it does not receive any RTCP RR packets from downstream 342 receivers when the splicing starts. 344 Upon the detection of a failure, the main RTP sender or the 345 substitutive sender SHOULD check the path to the failed mixer, or 346 fallback to the payload specific mechanisms, e.g., MPEG-TS splicing 347 solution defined in [SCTE35]. 349 6 SDP Signaling 351 This document defines the URI for declaring this header extension in 352 an extmap attribute to be "urn:ietf:params:rtp-hdrext:splicing- 353 interval". 355 This document extended the standard semantics defined in SDP Grouping 356 Framework [RFC5888] with a new semantic: SPLICE to represent the 357 relationship between the main RTP stream and the substitutive RTP 358 stream. The main RTP sender provides the information about both main 359 and substitutive sources. 361 The extended SDP attribute specified in this document is applicable 362 for offer/answer content [RFC3264] and do not affect any rules when 363 negotiating offer and answer. When used with multiple media, 364 substitutive RTP MUST be applied only to the RTP packets whose SDP m- 365 line is in the same group with the substitutive stream using FID and 366 has the extended splicing extmap attribute. This semantics is to have 367 splicing applicable for BUNDLE cases. 369 The following examples show how SDP signaling could be used for 370 splicing in different cases. 372 6.1 Declarative SDP 374 v=0 375 o=xia 1122334455 1122334466 IN IP4 splicing.example.com 376 s=RTP Splicing Example 377 t=0 0 378 a=group:SPLICE 1 2 379 m=video 30000 RTP/AVP 100 380 i=Main RTP Stream 381 c=IN IP4 233.252.0.1/127 382 a=rtpmap:100 MP2T/90000 383 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 384 a=mid:1 385 m=video 30002 RTP/AVP 100 386 i=Substitutive RTP Stream 387 c=IN IP4 233.252.0.2/127 388 a=sendonly 389 a=rtpmap:100 MP2T/90000 390 a=mid:2 392 Figure 3: Example SDP for a single-channel splicing scenario 394 The mixer receiving the SDP message above receives one MPEG2-TS 395 stream (payload 100) from the main RTP sender (with multicast 396 destination address of 233.252.0.1) on port 30000, and/or receives 397 another MPEG2-TS stream from the substitutive RTP sender (with 398 multicast destination address of 233.252.0.2) on port 30002. But at 399 a particular point in time, the mixer only selects one stream and 400 outputs the content from the chosen stream to the downstream 401 receivers. 403 6.2 Offer/Answer without BUNDLE 405 SDP Offer - from main RTP sender 407 v=0 408 o=xia 1122334455 1122334466 IN IP4 splicing.example.com 409 s=RTP Splicing Example 410 t=0 0 411 a=group:SPLICE 1 2 412 m=video 30000 RTP/AVP 31 100 413 i=Main RTP Stream 414 c=IN IP4 splicing.example.com 415 a=rtpmap:31 H261/90000 416 a=rtpmap:100 MP2T/90000 417 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 418 a=mid:1 419 m=video 40000 RTP/AVP 31 100 420 i=Substitutive RTP Stream 421 c=IN IP4 substitutive.example.com 422 a=rtpmap:31 H261/90000 423 a=rtpmap:100 MP2T/90000 424 a=sendonly 425 a=mid:2 427 SDP Answer - from splicer 429 v=0 430 o=xia 1122334455 1122334466 IN IP4 splicer.example.com 431 s=RTP Splicing Example 432 t=0 0 433 a=group:SPLICE 1 2 434 m=video 30000 RTP/AVP 100 435 i=Main RTP Stream 436 c=IN IP4 splicer.example.com 437 a=rtpmap:100 MP2T/90000 438 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 439 a=mid:1 440 m=video 40000 RTP/AVP 100 441 i=Substitutive RTP Stream 442 c=IN IP4 splicer.example.com 443 a=rtpmap:100 MP2T/90000 444 a=recvonly 445 a=mid:2 447 Only codecs that are supported both by the main RTP stream and the 448 substitutive RTP stream could be negotiated with SDP O/A. And the 449 mixer MUST choose the same codec for both of these two streams. 451 6.3 Offer/Answer with BUNDLE: All Media are spliced 453 In this example, the bundled audio and video media have their own 454 substitutive media for splicing: 456 1. An Offer, in which the offerer assigns a unique address and a 457 substitutive media to each bundled "m="line for splicing within the 458 BUNDLE group. 460 2. An answer, in which the answerer selects its own BUNDLE address, 461 and leave the substitutive media untouched. 463 SDP Offer - from main RTP sender 464 v=0 465 o=alice 1122334455 1122334466 IN IP4 splicing.example.com 466 s=RTP Splicing Example 467 c=IN IP4 splicing.example.com 468 t=0 0 469 a=group:SPLICE foo 1 470 a=group:SPLICE bar 2 471 a=group:BUNDLE foo bar 472 m=audio 10000 RTP/AVP 0 8 97 473 a=mid:foo 474 b=AS:200 475 a=rtpmap:0 PCMU/8000 476 a=rtpmap:8 PCMA/8000 477 a=rtpmap:97 iLBC/8000 478 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 479 m=video 10002 RTP/AVP 31 32 480 a=mid:bar 481 b=AS:1000 482 a=rtpmap:31 H261/90000 483 a=rtpmap:32 MPV/90000 484 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 485 m=audio 20000 RTP/AVP 0 8 97 486 i=Substitutive audio RTP Stream 487 c=IN IP4 substitive.example.com 488 a=rtpmap:0 PCMU/8000 489 a=rtpmap:8 PCMA/8000 490 a=rtpmap:97 iLBC/8000 491 a=sendonly 492 a=mid:1 493 m=video 20002 RTP/AVP 31 32 494 i=Substitutive video RTP Stream 495 c=IN IP4 substitive.example.com 496 a=rtpmap:31 H261/90000 497 a=rtpmap:32 MPV/90000 498 a=mid:2 500 SDP Answer - from the splicer 502 v=0 503 o=bob 2808844564 2808844564 IN IP4 splicer.example.com 504 s=RTP Splicing Example 505 c=IN IP4 splicer.example.com 506 t=0 0 507 a=group:SPLICE foo 1 508 a=group:SPLICE bar 2 509 a=group:BUNDLE foo bar 510 m=audio 30000 RTP/AVP 0 511 a=mid:foo 512 b=AS:200 513 a=rtpmap:0 PCMU/8000 514 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 515 m=video 30000 RTP/AVP 32 516 a=mid:bar 517 b=AS:1000 518 a=rtpmap:32 MPV/90000 519 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 520 m=audio 30002 RTP/AVP 0 521 i=Substitutive audio RTP Stream 522 c=IN IP4 splicer.example.com 523 a=rtpmap:0 PCMU/8000 524 a=sendonly 525 a=mid:1 526 m=video 30004 RTP/AVP 32 527 i=Substitutive video RTP Stream 528 c=IN IP4 splicer.example.com 529 a=rtpmap:32 MPV/90000 530 a=mid:2 532 6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced 534 In this example, the substitutive media only applies for video when 535 splicing: 537 1. An Offer, in which the offerer assigns a unique address to each 538 bundled "m="line within the BUNDLE group, and assigns a substitutive 539 media to the bundled video "m=" line for splicing. 541 2. An answer, in which the answerer selects its own BUNDLE address, 542 and leave the substitutive media untouched. 544 SDP Offer - from the main RTP sender: 546 v=0 547 o=alice 1122334455 1122334466 IN IP4 splicing.example.com 548 s=RTP Splicing Example 549 c=IN IP4 splicing.example.com 550 t=0 0 551 a=group:SPLICE bar 2 552 a=group:BUNDLE foo bar 553 m=audio 10000 RTP/AVP 0 8 97 554 a=mid:foo 555 b=AS:200 556 a=rtpmap:0 PCMU/8000 557 a=rtpmap:8 PCMA/8000 558 a=rtpmap:97 iLBC/8000 559 m=video 10002 RTP/AVP 31 32 560 a=mid:bar 561 b=AS:1000 562 a=rtpmap:31 H261/90000 563 a=rtpmap:32 MPV/90000 564 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 565 m=video 20000 RTP/AVP 31 32 566 i=Substitutive video RTP Stream 567 c=IN IP4 substitutive.example.com 568 a=rtpmap:31 H261/90000 569 a=rtpmap:32 MPV/90000 570 a=mid:2 572 SDP Answer - from the splicer: 574 v=0 575 o=bob 2808844564 2808844564 IN IP4 splicer.example.com 576 s=RTP Splicing Example 577 c=IN IP4 splicer.example.com 578 t=0 0 579 a=group:SPLICE bar 2 580 a=group:BUNDLE foo bar 581 m=audio 30000 RTP/AVP 0 582 a=mid:foo 583 b=AS:200 584 a=rtpmap:0 PCMU/8000 585 m=video 30000 RTP/AVP 32 586 a=mid:bar 587 b=AS:1000 588 a=rtpmap:32 MPV/90000 589 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 590 m=video 30004 RTP/AVP 32 591 i=Substitutive video RTP Stream 592 c=IN IP4 splicer.example.com 593 a=rtpmap:32 MPV/90000 594 a=mid:2 596 7 Security Considerations 598 The security considerations of the RTP specification [RFC3550], the 599 general mechanism for RTP header extensions [RFC5285] and the 600 security considerations of the RTP splicing specification [RFC6828] 601 apply. 603 The RTP header extension defined in Section 4.1 include two NTP- 604 format timestamps. In the Secure Real-time Transport Protocol 605 (SRTP)[RFC3711], RTP header extensions are authenticated but not 606 encrypted. A malicious endpoint possessing the SRTP key could choose 607 to set the values in this header extension falsely, so as to falsely 608 claim the splicing time. Also, such a malicious endpoint could cause 609 any arbitrary content it wishes spliced into the main RTP stream. 611 In scenarios where this is a concern, additional mechanisms MUST be 612 used to protect the confidentiality of the header extension. This 613 mechanism could be header extension encryption [SRTP-ENCR-HDR], or a 614 lower-level security and authentication mechanism such as IPsec 615 [RFC4301]. 617 8 IANA Considerations 619 8.1 RTCP Control Packet Types 621 Based on the guidelines suggested in [RFC5226], a new RTCP packet 622 format has been registered with the RTCP Control Packet Type (PT) 623 Registry: 625 Name: SNM 627 Long name: Splicing Notification Message 629 Value: TBA 631 Reference: This document 633 8.2 RTP Compact Header Extensions 635 The IANA has also registered a new RTP Compact Header Extension 636 [RFC5285], according to the following: 638 Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval 640 Description: Splicing Interval 642 Contact: Jinwei Xia 644 Reference: This document 646 8.3 SDP Grouping Semantic Extension 648 This document request IANA to register the new SDP grouping semantic 649 extension called "SPLICE". 651 Semantics: Splice 653 Token:SPLICE 654 Reference: This document 656 Contact: Jinwei Xia 658 9 Acknowledges 660 TBD 662 10 References 664 10.1 Normative References 666 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 667 Requirement Levels", BCP 14, RFC 2119, March 1997. 669 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 670 Jacobson, "RTP: A Transport Protocol for Real-Time 671 Applications", STD 64, RFC 3550, July 2003. 673 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 674 Description Protocol", RFC 4566, July 2006. 676 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 677 Header Extensions", RFC 5285, July 2008. 679 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 680 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 682 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 683 "Network Time Protocol Version 4: Protocol and Algorithms 684 Specification", RFC 5905, June 2010. 686 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 687 Flows", RFC 6051, November 2010. 689 [RFC6828] Xia, J., "Content Splicing for RTP Sessions", RFC 6828, 690 January 2013. 692 10.2 Informative References 694 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 695 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 696 RFC 3711, March 2004. 698 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 699 Internet Protocol", RFC 4301, December 2005. 701 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 702 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 703 May 2008. 705 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 706 Real-Time Transport Control Protocol (RTCP): Opportunities 707 and Consequences", RFC 5506, April 2009. 709 [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, 710 "Unicast-Based Rapid Acquisition of Multicast RTP 711 Sessions", RFC 6285, June 2011. 713 [RFC6904] Lennox, J.,"Encryption of Header Extensions in the Secure 714 Real-Time Transport Protocol (SRTP)", April 2013. 716 [SCTE35] Society of Cable Telecommunications Engineers (SCTE), 717 "Digital Program Insertion Cueing Message for Cable", 718 2011. 720 Authors' Addresses 722 Jinwei Xia 723 Huawei 725 Email: xiajinwei@huawei.com 727 Roni Even 728 Huawei 730 Email: ron.even.tlv@gmail.com 732 Rachel Huang 733 Huawei 735 Email: rachel.huang@huawei.com 737 Lingli Deng 738 China Mobile 740 Email: denglingli@chinamobile.com