idnits 2.17.1 draft-ietf-avtext-splicing-notification-02.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 document date (April 29, 2015) is 3278 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) ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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: October 31, 2015 Huawei 6 L. Deng 7 China Mobile 8 April 29, 2015 10 RTP/RTCP extension for RTP Splicing Notification 11 draft-ietf-avtext-splicing-notification-02 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) 2015 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 [RFC6828], a mixer is designed to handle splicing on the 138 RTP layer at the reserved time slots set by the main RTP sender. This 139 implies that the mixer must first know the Splicing Interval from the 140 main RTP sender before it can start splicing. 142 When a new splicing is forthcoming, the main RTP sender MUST send the 143 Splicing Interval to the mixer. Usually, the Splicing Interval SHOULD 144 be sent more than once to mitigate the possible packet loss. To 145 enable the mixer to get the substitutive content before the splicing 146 starts, the main RTP sender MUST send the Splicing Interval far 147 ahead. For example, the main RTP sender can estimate when to send the 148 Splicing Interval based on the round-trip time (RTT) following the 149 mechanisms in section 6.4.1 of [RFC3550] when the mixer sends RTCP RR 150 to the main sender. 152 The substitutive sender also needs to learn the Splicing Interval 153 from the main RTP sender in advance, and thus estimates when to 154 transfer the substitutive content to the mixer. The Splicing Interval 155 could be transmitted from the main RTP sender to the substitutive 156 content using some out-of-band mechanisms, the details how to achieve 157 that are beyond the scope of this memo. To ensure the Splicing 158 Interval is valid for both the main RTP sender and the substitutive 159 RTP sender, the two senders MUST share a common reference clock, so 160 the mixer can achieve accurate splicing. 162 In this document, the main RTP sender uses a pair of NTP-format 163 timestamps, derived from the common reference clock, to indicate when 164 to start and end the splicing to the mixer: the timestamp of the 165 first substitutive RTP packet at the splicing in point, and the 166 timestamp of the first main RTP packet at the splicing out point. 168 When the substitutive RTP sender gets the Splicing Interval, it must 169 prepare the substitutive stream. The mixer MUST ensure that the RTP 170 timestamp of the first substitutive RTP packet that would be 171 presented to the receivers corresponds to the same time instant as 172 the former NTP timestamp in the Splicing Interval. To enable the 173 mixer to know the first substitutive RTP packet it needs to send, the 174 substitutive RTP sender MUST send the substitutive RTP packet ahead 175 of the Splicing In point, allowing the mixer to find out the 176 timestamp of this first RTP packet in the substitutive RTP stream, 177 e.g., using a prior RTCP SR message. 179 When the splicing will end, the mixer MUST ensure that the RTP 180 timestamp of the first main RTP packet that would be presented on the 181 receivers corresponds to the same time instant as the latter NTP 182 timestamp in the Splicing Interval. 184 3 Conveying Splicing Interval in RTP/RTCP extensions 186 This memo defines two backwards compatible RTP extensions to convey 187 the Splicing Interval to the mixer: an RTP header extension and an 188 RTCP splicing notification message. 190 3.1 RTP Header Extension 192 The RTP header extension mechanism defined in [RFC5285] can be 193 adapted to carry the Splicing Interval consisting of a pair of NTP- 194 format timestamps. 196 One variant is defined for this header extension. It carries the 7 197 octets splicing-out NTP timestamp (lower 24-bit part of the Seconds 198 of a NTP-format timestamp and the 32 bits of the Fraction of a NTP- 199 format timestamp as defined in [RFC5905]), followed by the 8 octets 200 splicing-in NTP timestamp (64-bit NTP-format timestamp as defined in 201 [RFC5905]). The top 8 bits of the splicing-out NTP timestamp are 202 referred from the top 8 bits of the splicing-in NTP timestamp. This 203 is unambiguous, under the assumption that the splicing-out time is 204 after the splicing-in time, and the splicing interval is less than 205 2^25 seconds. 207 The format is shown in Figures 1. 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | 0xBE | 0xDE | length=4 | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E 214 | ID | L=15 | OUT NTP timestamp format - Seconds (bit 8-31) |x 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t 216 | OUT NTP timestamp format - Fraction (bit 0-31) |e 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 218 | IN NTP timestamp format - Seconds (bit 0-31) |s 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i 220 | IN NTP timestamp format - Fraction (bit 0-31) |o 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 223 Figure 1: Sample hybrid NTP Encoding Using 224 the One-Byte Header Format 226 Note that the inclusion of an RTP header extension will reduce the 227 efficiency of RTP header compression. It is RECOMMENDED that the main 228 sender begins to insert the RTP header extensions into a number of 229 RTP packets prior to the splicing in, while leaving the remaining RTP 230 packets unmarked. 232 After the mixer intercepts the RTP header extension and derives the 233 Splicing Interval, it will generate its own stream and SHOULD NOT 234 include the RTP header extension in outgoing packets to reduce header 235 overhead. 237 Furthermore, whether the in-band NTP-format timestamps are included 238 or not, RTCP splicing notification message, specified in the next 239 section, MUST be sent to provide robustness in case of any splicing- 240 unaware middlebox that might strip RTP header extensions. 242 3.2 RTCP Splicing Notification Message 244 In addition to the RTP header extension, the main RTP sender includes 245 the Splicing Interval in an RTCP splicing notification message. 247 The RTCP splicing notification message is a new RTCP packet type. It 248 has a fix header followed by a pair of NTP-format timestamps: 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 |V=2|P|reserved | PT=TBA | length | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | SSRC | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | IN NTP Timestamp (most significant word) | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | IN NTP Timestamp (least significant word) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | OUT NTP Timestamp (most significant word) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | OUT NTP Timestamp (least significant word) | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 2: RTCP Splicing Notification Message 268 The RSI packet includes the following fields: 270 Length: 16 bits 272 As defined in [RFC3550], the length of the RTCP packet in 32-bit 273 words minus one, including the header and any padding. 275 SSRC: 32 bits 277 The SSRC of the Main RTP Sender. 279 Timestamp: 64 bits 281 Indicates the wallclock time when this splicing starts and ends. 282 The full-resolution NTP timestamp is used, which is a 64-bit, 283 unsigned, fixed-point number with the integer part in the first 32 284 bits and the fractional part in the last 32 bits. This format is 285 similar to RTCP Sender Report (Section 6.4.1 of [RFC3550]). 287 The RTCP splicing notification message can be appended to RTCP SR the 288 main RTP sender generates in compound RTCP packets, and hence follows 289 the compound RTCP rules defined in Section 6.1 in [RFC3550]. 291 If the use of non-compound RTCP [RFC5506] was previously negotiated 292 between the sender and the mixer, the RTCP splicing notification 293 message may be sent as non-compound RTCP packets. 295 When the mixer intercepts the RTCP splicing notification message, it 296 SHOULD NOT forward the message to the receivers in order to reduce 297 RTCP bandwidth consumption. And it MUST NOT forward the message to 298 the downstream receivers to avoid them from detecting splicing 299 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 extends 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. Only 2 m-lines are allowed in the SPLICE group. The main RTP 359 stream is the one with the extended extmap attribute, and the other 360 one is substitutive stream. A single m-line MUST NOT be included in 361 different SPLICE groups at the same time. The main RTP sender 362 provides the information about both main and substitutive sources. 364 The extended SDP attribute specified in this document is applicable 365 for offer/answer content [RFC3264] and do not affect any rules when 366 negotiating offer and answer. When used with multiple media, 367 substitutive RTP MUST be applied only to the RTP packets whose SDP m- 368 line is in the same group with the substitutive stream using SPLICE 369 and has the extended splicing extmap attribute. This semantics is 370 also applicable for BUNDLE cases. 372 The following examples show how SDP signaling could be used for 373 splicing in different cases. 375 6.1 Declarative SDP 377 v=0 378 o=xia 1122334455 1122334466 IN IP4 splicing.example.com 379 s=RTP Splicing Example 380 t=0 0 381 a=group:SPLICE 1 2 382 m=video 30000 RTP/AVP 100 383 i=Main RTP Stream 384 c=IN IP4 233.252.0.1/127 385 a=rtpmap:100 MP2T/90000 386 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 387 a=mid:1 388 m=video 30002 RTP/AVP 100 389 i=Substitutive RTP Stream 390 c=IN IP4 233.252.0.2/127 391 a=sendonly 392 a=rtpmap:100 MP2T/90000 393 a=mid:2 395 Figure 3: Example SDP for a single-channel splicing scenario 397 The mixer receiving the SDP message above receives one MPEG2-TS 398 stream (payload 100) from the main RTP sender (with multicast 399 destination address of 233.252.0.1) on port 30000, and/or receives 400 another MPEG2-TS stream from the substitutive RTP sender (with 401 multicast destination address of 233.252.0.2) on port 30002. But at 402 a particular point in time, the mixer only selects one stream and 403 outputs the content from the chosen stream to the downstream 404 receivers. 406 6.2 Offer/Answer without BUNDLE 408 SDP Offer - from main RTP sender 410 v=0 411 o=xia 1122334455 1122334466 IN IP4 splicing.example.com 412 s=RTP Splicing Example 413 t=0 0 414 a=group:SPLICE 1 2 415 m=video 30000 RTP/AVP 31 100 416 i=Main RTP Stream 417 c=IN IP4 splicing.example.com 418 a=rtpmap:31 H261/90000 419 a=rtpmap:100 MP2T/90000 420 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 421 a=sendonly 422 a=mid:1 423 m=video 40000 RTP/AVP 31 100 424 i=Substitutive RTP Stream 425 c=IN IP4 substitutive.example.com 426 a=rtpmap:31 H261/90000 427 a=rtpmap:100 MP2T/90000 428 a=sendonly 429 a=mid:2 431 SDP Answer - from splicer 433 v=0 434 o=xia 1122334455 1122334466 IN IP4 splicer.example.com 435 s=RTP Splicing Example 436 t=0 0 437 a=group:SPLICE 1 2 438 m=video 30000 RTP/AVP 100 439 i=Main RTP Stream 440 c=IN IP4 splicer.example.com 441 a=rtpmap:100 MP2T/90000 442 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 443 a=recvonly 444 a=mid:1 445 m=video 40000 RTP/AVP 100 446 i=Substitutive RTP Stream 447 c=IN IP4 splicer.example.com 448 a=rtpmap:100 MP2T/90000 449 a=recvonly 450 a=mid:2 452 Only codecs that are supported both by the main RTP stream and the 453 substitutive RTP stream could be negotiated with SDP O/A. And the 454 mixer MUST choose the same codec for both of these two streams. 456 6.3 Offer/Answer with BUNDLE: All Media are spliced 458 In this example, the bundled audio and video media have their own 459 substitutive media for splicing: 461 1. An Offer, in which the offerer assigns a unique address and a 462 substitutive media to each bundled "m="line for splicing within the 463 BUNDLE group. 465 2. An answer, in which the answerer selects its own BUNDLE address, 466 and leave the substitutive media untouched. 468 SDP Offer - from main RTP sender 470 v=0 471 o=alice 1122334455 1122334466 IN IP4 splicing.example.com 472 s=RTP Splicing Example 473 c=IN IP4 splicing.example.com 474 t=0 0 475 a=group:SPLICE foo 1 476 a=group:SPLICE bar 2 477 a=group:BUNDLE foo bar 478 m=audio 10000 RTP/AVP 0 8 97 479 a=mid:foo 480 b=AS:200 481 a=rtpmap:0 PCMU/8000 482 a=rtpmap:8 PCMA/8000 483 a=rtpmap:97 iLBC/8000 484 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 485 a=sendonly 486 m=video 10002 RTP/AVP 31 32 487 a=mid:bar 488 b=AS:1000 489 a=rtpmap:31 H261/90000 490 a=rtpmap:32 MPV/90000 491 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 492 a=sendonly 493 m=audio 20000 RTP/AVP 0 8 97 494 i=Substitutive audio RTP Stream 495 c=IN IP4 substitive.example.com 496 a=rtpmap:0 PCMU/8000 497 a=rtpmap:8 PCMA/8000 498 a=rtpmap:97 iLBC/8000 499 a=sendonly 500 a=mid:1 501 m=video 20002 RTP/AVP 31 32 502 i=Substitutive video RTP Stream 503 c=IN IP4 substitive.example.com 504 a=rtpmap:31 H261/90000 505 a=rtpmap:32 MPV/90000 506 a=mid:2 507 a=sendonly 509 SDP Answer - from the splicer 511 v=0 512 o=bob 2808844564 2808844564 IN IP4 splicer.example.com 513 s=RTP Splicing Example 514 c=IN IP4 splicer.example.com 515 t=0 0 516 a=group:SPLICE foo 1 517 a=group:SPLICE bar 2 518 a=group:BUNDLE foo bar 519 m=audio 30000 RTP/AVP 0 520 a=mid:foo 521 b=AS:200 522 a=rtpmap:0 PCMU/8000 523 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 524 a=recvonly 525 m=video 30000 RTP/AVP 32 526 a=mid:bar 527 b=AS:1000 528 a=rtpmap:32 MPV/90000 529 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 530 a=recvonly 531 m=audio 30002 RTP/AVP 0 532 i=Substitutive audio RTP Stream 533 c=IN IP4 splicer.example.com 534 a=rtpmap:0 PCMU/8000 535 a=recvonly 536 a=mid:1 537 m=video 30004 RTP/AVP 32 538 i=Substitutive video RTP Stream 539 c=IN IP4 splicer.example.com 540 a=rtpmap:32 MPV/90000 541 a=mid:2 542 a=recvonly 544 6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced 546 In this example, the substitutive media only applies for video when 547 splicing: 549 1. An Offer, in which the offerer assigns a unique address to each 550 bundled "m="line within the BUNDLE group, and assigns a substitutive 551 media to the bundled video "m=" line for splicing. 553 2. An answer, in which the answerer selects its own BUNDLE address, 554 and leave the substitutive media untouched. 556 SDP Offer - from the main RTP sender: 558 v=0 559 o=alice 1122334455 1122334466 IN IP4 splicing.example.com 560 s=RTP Splicing Example 561 c=IN IP4 splicing.example.com 562 t=0 0 563 a=group:SPLICE bar 2 564 a=group:BUNDLE foo bar 565 m=audio 10000 RTP/AVP 0 8 97 566 a=mid:foo 567 b=AS:200 568 a=rtpmap:0 PCMU/8000 569 a=rtpmap:8 PCMA/8000 570 a=rtpmap:97 iLBC/8000 571 a=sendonly 572 m=video 10002 RTP/AVP 31 32 573 a=mid:bar 574 b=AS:1000 575 a=rtpmap:31 H261/90000 576 a=rtpmap:32 MPV/90000 577 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 578 a=sendonly 579 m=video 20000 RTP/AVP 31 32 580 i=Substitutive video RTP Stream 581 c=IN IP4 substitutive.example.com 582 a=rtpmap:31 H261/90000 583 a=rtpmap:32 MPV/90000 584 a=mid:2 585 a=sendonly 587 SDP Answer - from the splicer: 589 v=0 590 o=bob 2808844564 2808844564 IN IP4 splicer.example.com 591 s=RTP Splicing Example 592 c=IN IP4 splicer.example.com 593 t=0 0 594 a=group:SPLICE bar 2 595 a=group:BUNDLE foo bar 596 m=audio 30000 RTP/AVP 0 597 a=mid:foo 598 b=AS:200 599 a=rtpmap:0 PCMU/8000 600 a=recvonly 601 m=video 30000 RTP/AVP 32 602 a=mid:bar 603 b=AS:1000 604 a=rtpmap:32 MPV/90000 605 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 606 a=recvonly 607 m=video 30004 RTP/AVP 32 608 i=Substitutive video RTP Stream 609 c=IN IP4 splicer.example.com 610 a=rtpmap:32 MPV/90000 611 a=mid:2 612 a=recvonly 614 7 Security Considerations 616 The security considerations of the RTP specification [RFC3550], the 617 general mechanism for RTP header extensions [RFC5285] and the 618 security considerations of the RTP splicing specification [RFC6828] 619 apply. 621 The RTP header extension defined in Section 4.1 include two NTP- 622 format timestamps. In the Secure Real-time Transport Protocol 623 (SRTP)[RFC3711], RTP header extensions are authenticated but not 624 encrypted. For a malicious endpoint without the key, it can observe 625 the splicing time in the RTP header, and it can intercept the 626 substitutive content and even replace it with a different one if the 627 splicer does not use any security like SRTP and authenticate the main 628 and substitutive content sources. 630 If there is a concern about the confidentiality of the splicing time 631 information, header extension encryption [RFC6904] SHOULD be used. 632 However, the malicious endpoint can get the splicing time information 633 by other means, e.g., observing the RTP timestamp of the substitutive 634 stream. To protect from different substitutive contents are inserted, 635 the splicer MUST have some mechanisms to authenticate the 636 substitutive stream source. 638 For cases that the splicing time information is changed by a 639 malicious endpoint, the splicing may fail since it will not be 640 available at the right time for the substitutive media to arrive, 641 which may also break an undetectable splicing. To mitigate this 642 effect, the splicer SHOULD NOT forward the splicing time information 643 RTP header extension defined in Section 4.1 to the receivers. And it 644 MUST NOT forward this header extension when considering an 645 undetectable splicing. 647 8 IANA Considerations 649 8.1 RTCP Control Packet Types 651 Based on the guidelines suggested in [RFC5226], a new RTCP packet 652 format has been registered with the RTCP Control Packet Type (PT) 653 Registry: 655 Name: SNM 657 Long name: Splicing Notification Message 659 Value: TBA 661 Reference: This document 663 8.2 RTP Compact Header Extensions 665 The IANA has also registered a new RTP Compact Header Extension 666 [RFC5285], according to the following: 668 Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval 670 Description: Splicing Interval 672 Contact: Jinwei Xia 674 Reference: This document 676 8.3 SDP Grouping Semantic Extension 678 This document request IANA to register the new SDP grouping semantic 679 extension called "SPLICE". 681 Semantics: Splice 683 Token:SPLICE 685 Reference: This document 687 Contact: Jinwei Xia 689 9 Acknowledges 691 TBD 693 10 References 695 10.1 Normative References 697 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 698 Requirement Levels", BCP 14, RFC 2119, March 1997. 700 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 702 Jacobson, "RTP: A Transport Protocol for Real-Time 703 Applications", STD 64, RFC 3550, July 2003. 705 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 706 with the Session Description Protocol (SDP)", RFC 3264, 707 June 2002. 709 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 710 Header Extensions", RFC 5285, July 2008. 712 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 713 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 715 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 716 "Network Time Protocol Version 4: Protocol and Algorithms 717 Specification", RFC 5905, June 2010. 719 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 720 Flows", RFC 6051, November 2010. 722 10.2 Informative References 724 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 725 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 726 RFC 3711, March 2004. 728 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 729 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 730 May 2008. 732 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 733 Real-Time Transport Control Protocol (RTCP): Opportunities 734 and Consequences", RFC 5506, April 2009. 736 [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, 737 "Unicast-Based Rapid Acquisition of Multicast RTP 738 Sessions", RFC 6285, June 2011. 740 [RFC6904] Lennox, J.,"Encryption of Header Extensions in the Secure 741 Real-Time Transport Protocol (SRTP)", April 2013. 743 [SCTE35] Society of Cable Telecommunications Engineers (SCTE), 744 "Digital Program Insertion Cueing Message for Cable", 745 2011. 747 [RFC6828] Xia, J., "Content Splicing for RTP Sessions", RFC 6828, 748 January 2013. 750 Authors' Addresses 752 Jinwei Xia 753 Huawei 755 Email: xiajinwei@huawei.com 757 Roni Even 758 Huawei 760 Email: ron.even.tlv@gmail.com 762 Rachel Huang 763 Huawei 765 Email: rachel.huang@huawei.com 767 Lingli Deng 768 China Mobile 770 Email: denglingli@chinamobile.com