idnits 2.17.1 draft-ietf-avtext-splicing-notification-04.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 (January 26, 2016) is 3012 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) -- Looks like a reference, but probably isn't: '3711' on line 694 == Unused Reference: 'RFC3711' is defined on line 798, but no explicit reference was found in the text ** 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 (~~), 2 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: July 29, 2016 Huawei 6 L. Deng 7 China Mobile 8 January 26, 2016 10 RTP/RTCP extension for RTP Splicing Notification 11 draft-ietf-avtext-splicing-notification-04 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) 2016 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 needs to be inside of the specific, pre-designated time slot. 95 Certain timing information about when to start and end the splicing 96 must be first acquired by the splicer in order to start the splicing. 97 This document refers to this information as the Splicing Interval. 99 [SCTE35] provides a method that encapsulates the Splicing Interval 100 inside the MPEG2-TS layer in cable TV systems. When transported in 101 RTP, an middle box designed as the splicer to decode the RTP packets 102 and search for the Splicing Interval inside the payloads is required. 103 The middle box is either a translator or a mixer as described in 104 [RFC6828]. The need for such processing increases the workload of the 105 middle box and limits the number of RTP sessions the middle box can 106 support. 108 The document defines an RTP header extension [RFC5285] used by the 109 main RTP sender to provide the Splicing Interval by including it in 110 the RTP packets. 112 Nevertheless, the Splicing Interval conveyed in the RTP header 113 extension might not reach the splicer successfully. Any splicing un- 114 aware middlebox on the path between the RTP sender might strip this 115 RTP header extension. 117 To increase robustness against such case, the document also defines a 118 complementary RTCP packet type to carry the same Splicing Interval to 119 the splicer. 121 1.1 Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 In addition, we define following terminologies: 129 Main RTP sender: 131 The sender of RTP packets carrying the main RTP stream. 133 Splicer: 135 An intermediary node that inserts substitutive content into a main 136 RTP stream. The splicer sends substitutive content to the RTP 137 receiver instead of the main content during splicing. It is also 138 responsible for processing RTCP traffic between the RTP sender and 139 the RTP receiver. 141 Splicing-In Point 143 A virtual point in the RTP stream, suitable for substitutive 144 content entry, typically in the boundary between two independently 145 decodable frames. 147 Splicing-Out Point 149 A virtual point in the RTP stream, suitable for substitutive 150 content exit, typically in the boundary between two independently 151 decodable frames. 153 Splicing Interval: 155 The NTP timestamps for the Splicing-In point and Splicing-Out 156 point per [RFC6828] allowing the splicer to know when to start and 157 end the RTP splicing. 159 Substitutive RTP Sender: 161 The sender of RTP packets carrying the RTP stream that will 162 replace the content in the main RTP stream. 164 2 Overview of RTP Splicing Notification 166 A splicer is designed to handle splicing on the RTP layer at the 167 reserved time slots set by the main RTP sender. This implies that the 168 splicer must first know the Splicing Interval from the main RTP 169 sender before it can start splicing. The splicer can be a mixer as 170 described in [RFC6828]. 172 When a new splicing is forthcoming, the main RTP sender needs to send 173 the Splicing Interval to the splicer. The Splicing Interval SHOULD be 174 sent more than once to mitigate the possible packet loss. To enable 175 the splicer to get the substitutive content before the splicing 176 starts, the main RTP sender MUST send the Splicing Interval far 177 ahead. For example, the main RTP sender can estimate when to send the 178 Splicing Interval based on the round-trip time (RTT) following the 179 mechanisms in section 6.4.1 of [RFC3550] when the splicer sends RTCP 180 RR to the main sender. 182 The substitutive sender also needs to learn the Splicing Interval 183 from the main RTP sender in advance, and thus estimates when to 184 transfer the substitutive content to the splicer. The Splicing 185 Interval could be transmitted from the main RTP sender to the 186 substitutive content using some out-of-band mechanisms, for example, 187 a proprietary mechanism to exchange the Splicing Interval, or the 188 substitutive sender is implemented together with the main RTP sender 189 inside a single device. To ensure the Splicing Interval is valid for 190 both the main RTP sender and the substitutive RTP sender, the two 191 senders MUST share a common reference clock so that the splicer can 192 achieve accurate splicing. The requirements for the common reference 193 clock (e.g. resolution, skew) depend on the codec used by the media 194 content. 196 In this document, the main RTP sender uses a pair of NTP-format 197 timestamps, to indicate when to start and end the splicing to the 198 splicer: the timestamp of the first substitutive RTP packet at the 199 splicing in point, and the timestamp of the first main RTP packet at 200 the splicing out point. 202 When the substitutive RTP sender gets the Splicing Interval, it must 203 prepare the substitutive stream. The main and the substitutive 204 content providers MUST ensure that the RTP timestamp of the first 205 substitutive RTP packet that would be presented to the receivers 206 corresponds to the same time instant as the former NTP timestamp in 207 the Splicing Interval. To enable the splicer to know the first 208 substitutive RTP packet it needs to send, the substitutive RTP sender 209 MUST send the substitutive RTP packet ahead of the Splicing In point, 210 allowing the splicer to find out the timestamp of this first RTP 211 packet in the substitutive RTP stream, e.g., using a prior RTCP SR 212 message. 214 When the splicing will end, the main content provider and the 215 substitutive content provider MUST ensure the RTP timestamp of the 216 first main RTP packet that would be presented on the receivers 217 corresponds to the same time instant as the latter NTP timestamp in 218 the Splicing Interval. 220 3 Conveying Splicing Interval in RTP/RTCP extensions 222 This memo defines two backwards compatible RTP extensions to convey 223 the Splicing Interval to the splicer: an RTP header extension and an 224 RTCP splicing notification message. 226 3.1 RTP Header Extension 228 The RTP header extension mechanism defined in [RFC5285] can be 229 adapted to carry the Splicing Interval consisting of a pair of NTP- 230 format timestamps. 232 One variant is defined for this header extension. It carries the 7 233 octets splicing-out NTP timestamp (lower 24-bit part of the Seconds 234 of a NTP-format timestamp and the 32 bits of the Fraction of a NTP- 235 format timestamp as defined in [RFC5905]), followed by the 8 octets 236 splicing-in NTP timestamp (64-bit NTP-format timestamp as defined in 237 [RFC5905]). The top 8 bits of the splicing-out NTP timestamp are 238 inferred from the top 8 bits of the splicing-in NTP timestamp. This 239 is unambiguous, under the assumption that the splicing-out time is 240 after the splicing-in time, and the splicing interval is less than 241 2^25 seconds. If the 7 octets splicing-out NTP timestamp is smaller 242 than the lower 7 octets splicing-in NTP timestamp, it implies a wrap 243 of the 64-bit splicing-out NTP timestamp which will then be 244 calculated by the 7 octets splicing-out NTP timestamp plus 245 0x100000000. Otherwise, the top 8 octets of splicing-out NTP 246 timestamp is equal to the top 8 octets of splicing-in NTP timestamp. 248 The format is shown in Figures 1. 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 | 0xBE | 0xDE | length=4 | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E 255 | ID | L=15 | OUT NTP timestamp format - Seconds (bit 8-31) |x 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t 257 | OUT NTP timestamp format - Fraction (bit 0-31) |e 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 259 | IN NTP timestamp format - Seconds (bit 0-31) |s 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i 261 | IN NTP timestamp format - Fraction (bit 0-31) |o 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 264 Figure 1: Sample hybrid NTP Encoding Using 265 the One-Byte Header Format 267 Since the inclusion of an RTP header extension will reduce the 268 efficiency of RTP header compression, it is RECOMMENDED that the main 269 sender inserts the RTP header extensions into only a number of RTP 270 packets, instead of all the RTP packets, prior to the splicing in. 272 After the splicer intercepts the RTP header extension and derives the 273 Splicing Interval, it will generate its own stream and SHOULD NOT 274 include the RTP header extension in outgoing packets to reduce header 275 overhead. 277 3.2 RTCP Splicing Notification Message 279 In addition to the RTP header extension, the main RTP sender includes 280 the Splicing Interval in an RTCP splicing notification message. 281 Whether or not the timestamps are included in the RTP header 282 extension, the main RTP sender MUST send the RTCP splicing 283 notification message. This provide robustness in the case where a 284 middlebox strips RTP header extensions. 286 The RTCP splicing notification message is a new RTCP packet type. It 287 has a fixed header followed by a pair of NTP-format timestamps: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |V=2|P|reserved | PT=TBA | length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | SSRC | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | IN NTP Timestamp (most significant word) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | IN NTP Timestamp (least significant word) | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | OUT NTP Timestamp (most significant word) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | OUT NTP Timestamp (least significant word) | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 2: RTCP Splicing Notification Message 307 The RSI packet includes the following fields: 309 Length: 16 bits 311 As defined in [RFC3550], the length of the RTCP packet in 32-bit 312 words minus one, including the header and any padding. 314 SSRC: 32 bits 316 The SSRC of the Main RTP Sender. 318 Timestamp: 64 bits 320 Indicates the wallclock time when this splicing starts and ends. 321 The full-resolution NTP timestamp is used, which is a 64-bit, 322 unsigned, fixed-point number with the integer part in the first 32 323 bits and the fractional part in the last 32 bits. This format is 324 similar to the RTCP Sender Report (Section 6.4.1 of [RFC3550]). 326 The RTCP splicing notification message can be appended to RTCP SR the 327 main RTP sender generates in compound RTCP packets, and hence follows 328 the compound RTCP rules defined in Section 6.1 in [RFC3550]. 330 If the use of non-compound RTCP [RFC5506] was previously negotiated 331 between the sender and the splicer, the RTCP splicing notification 332 message may be sent as non-compound RTCP packets. 334 When the splicer intercepts the RTCP splicing notification message, 335 it SHOULD NOT forward the message to the down-stream receivers in 336 order to reduce RTCP bandwidth consumption. And if the splicer wishes 337 to prevent the downstream receivers from detecting splicing, it MUST 338 NOT forward the message. 340 4 Reducing Splicing Latency 342 When splicing starts or ends, the splicer outputs the multimedia 343 content from another sender to the receivers. Given that the 344 receivers must first acquire certain information ([RFC6285] refers to 345 this information as Reference Information) to start processing the 346 multimedia data, either the main RTP sender or the substitutive 347 sender SHOULD provide the Reference Information together with its 348 multimedia content to reduce the delay caused by acquiring the 349 Reference Information. The methods by which the Reference Information 350 is distributed to the receivers is out of scope of this memo. 352 Another latency element is synchronization caused delay. The 353 receivers must receive enough synchronization metadata prior to 354 synchronizing the separate components of the multimedia streams when 355 splicing starts or ends. Either the main RTP sender or the 356 substitutive sender SHOULD send the synchronization metadata early 357 enough so that the receivers can play out the multimedia in a 358 synchronized fashion. The main RTP sender and the substitutive sender 359 can be coordinated by some proprietary out-of-band mechanisms to 360 decide when and whom to send the metadata. If both send the 361 information, the splicer SHOULD pick one based on the current 362 situation, e.g., choosing media sender when synchronizing the main 363 media content while choosing the information from the substitutive 364 sender when synchronizing the spliced content. The mechanisms defined 365 in [RFC6051] are RECOMMENDED to be adopted to reduce the possible 366 synchronization delay. 368 5 Failure Cases 370 This section examines the implications of losing RTCP splicing 371 notification message and the other failure case, e.g., the RTP header 372 extension is stripped on the path. 374 Given that there may be a splicing un-aware middlebox on the path 375 between the main RTP sender and the splicer, the main and the 376 substitutive RTP senders can use one heuristic to verify whether or 377 not the Splicing Interval reaches the splicer. 379 The splicer can be implemented to have its own SSRC, and send RTCP 380 reception reports to the senders of the main and substitutive RTP 381 streams. This allows the senders to detect problems on the path to 382 the splicer. Alternatively, it is possible to implement the splicer 383 such that it has no SSRC, and does not send RTCP reports; this 384 prevents the senders from being able to monitor the quality to the 385 path to the splicer. 387 If the splicer has an SSRC and sends its own RTCP reports, it can 388 choose not to pass RTCP reports it receives from the receivers to the 389 senders. This will stop the senders from being able to monitor the 390 quality of the paths from the splicer to the receivers. 392 A splicer that has an SSRC can choose to pass RTCP reception reports 393 from the receivers back to the senders, after modifications to 394 account for the splicing. This will allow the senders the monitor the 395 quality of the paths from the splicer to the receivers. A splicer 396 that does not have its own SSRC has to forward and translation RTCP 397 reports from the receiver, otherwise the senders will not see any 398 receivers in the RTP session. 400 If the splicer is implemented following [RFC6828], it will have its 401 own SSRC and will send its own RTCP reports, and will forward 402 translated RTCP reports from the receivers. 404 Upon the detection of a failure, the splicer can communicate with the 405 main sender and the substitutive sender in some out of band signaling 406 ways to fall back to the payload specific mechanisms it supports, 407 e.g., MPEG-TS splicing solution defined in [SCTE35], or just abandon 408 the splicing. 410 6 Session Description Protocol (SDP) Signaling 412 This document defines the URI for declaring this header extension in 413 an extmap attribute to be "urn:ietf:params:rtp-hdrext:splicing- 414 interval". 416 This document extends the standard semantics defined in SDP Grouping 417 Framework [RFC5888] with a new semantic: SPLICE to represent the 418 relationship between the main RTP stream and the substitutive RTP 419 stream. Only 2 m-lines are allowed in the SPLICE group. The main RTP 420 stream is the one with the extended extmap attribute, and the other 421 one is substitutive stream. A single m-line MUST NOT be included in 422 different SPLICE groups at the same time. The main RTP sender 423 provides the information about both main and substitutive sources. 425 The extended SDP attribute specified in this document is applicable 426 for offer/answer content [RFC3264] and do not affect any rules when 427 negotiating offer and answer. When used with multiple m-lines, 428 substitutive RTP MUST be applied only to the RTP packets whose SDP m- 429 line is in the same group with the substitutive stream using SPLICE 430 and has the extended splicing extmap attribute. This semantic is also 431 applicable for BUNDLE cases. 433 The following examples show how SDP signaling could be used for 434 splicing in different cases. 436 6.1 Declarative SDP 438 v=0 439 o=xia 1122334455 1122334466 IN IP4 splicing.example.com 440 s=RTP Splicing Example 441 t=0 0 442 a=group:SPLICE 1 2 443 m=video 30000 RTP/AVP 100 444 i=Main RTP Stream 445 c=IN IP4 233.252.0.1/127 446 a=rtpmap:100 MP2T/90000 447 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 448 a=mid:1 449 m=video 30002 RTP/AVP 100 450 i=Substitutive RTP Stream 451 c=IN IP4 233.252.0.2/127 452 a=sendonly 453 a=rtpmap:100 MP2T/90000 454 a=mid:2 456 Figure 3: Example SDP for a single-channel splicing scenario 458 The splicer receiving the SDP message above receives one MPEG2-TS 459 stream (payload 100) from the main RTP sender (with multicast 460 destination address of 233.252.0.1) on port 30000, and/or receives 461 another MPEG2-TS stream from the substitutive RTP sender (with 462 multicast destination address of 233.252.0.2) on port 30002. But at 463 a particular point in time, the splicer only selects one stream and 464 outputs the content from the chosen stream to the downstream 465 receivers. 467 6.2 Offer/Answer without BUNDLE 469 SDP Offer - from main RTP sender 471 v=0 472 o=xia 1122334455 1122334466 IN IP4 splicing.example.com 473 s=RTP Splicing Example 474 t=0 0 475 a=group:SPLICE 1 2 476 m=video 30000 RTP/AVP 31 100 477 i=Main RTP Stream 478 c=IN IP4 splicing.example.com 479 a=rtpmap:31 H261/90000 480 a=rtpmap:100 MP2T/90000 481 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 482 a=sendonly 483 a=mid:1 484 m=video 40000 RTP/AVP 31 100 485 i=Substitutive RTP Stream 486 c=IN IP4 substitutive.example.com 487 a=rtpmap:31 H261/90000 488 a=rtpmap:100 MP2T/90000 489 a=sendonly 490 a=mid:2 492 SDP Answer - from splicer 494 v=0 495 o=xia 1122334455 1122334466 IN IP4 splicer.example.com 496 s=RTP Splicing Example 497 t=0 0 498 a=group:SPLICE 1 2 499 m=video 30000 RTP/AVP 100 500 i=Main RTP Stream 501 c=IN IP4 splicer.example.com 502 a=rtpmap:100 MP2T/90000 503 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 504 a=recvonly 505 a=mid:1 506 m=video 40000 RTP/AVP 100 507 i=Substitutive RTP Stream 508 c=IN IP4 splicer.example.com 509 a=rtpmap:100 MP2T/90000 510 a=recvonly 511 a=mid:2 513 Only codecs that are supported both by the main RTP stream and the 514 substitutive RTP stream could be negotiated with SDP O/A. And the 515 splicer MUST choose the same codec for both of these two streams. 517 6.3 Offer/Answer with BUNDLE: All Media are spliced 519 In this example, the bundled audio and video media have their own 520 substitutive media for splicing: 522 1. An Offer, in which the offerer assigns a unique address and a 523 substitutive media to each bundled "m="line for splicing within the 524 BUNDLE group. 526 2. An answer, in which the answerer selects its own BUNDLE address, 527 and leave the substitutive media untouched. 529 SDP Offer - from main RTP sender 531 v=0 532 o=alice 1122334455 1122334466 IN IP4 splicing.example.com 533 s=RTP Splicing Example 534 c=IN IP4 splicing.example.com 535 t=0 0 536 a=group:SPLICE foo 1 537 a=group:SPLICE bar 2 538 a=group:BUNDLE foo bar 539 m=audio 10000 RTP/AVP 0 8 97 540 a=mid:foo 541 b=AS:200 542 a=rtpmap:0 PCMU/8000 543 a=rtpmap:8 PCMA/8000 544 a=rtpmap:97 iLBC/8000 545 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 546 a=sendonly 547 m=video 10002 RTP/AVP 31 32 548 a=mid:bar 549 b=AS:1000 550 a=rtpmap:31 H261/90000 551 a=rtpmap:32 MPV/90000 552 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 553 a=sendonly 554 m=audio 20000 RTP/AVP 0 8 97 555 i=Substitutive audio RTP Stream 556 c=IN IP4 substitive.example.com 557 a=rtpmap:0 PCMU/8000 558 a=rtpmap:8 PCMA/8000 559 a=rtpmap:97 iLBC/8000 560 a=sendonly 561 a=mid:1 562 m=video 20002 RTP/AVP 31 32 563 i=Substitutive video RTP Stream 564 c=IN IP4 substitive.example.com 565 a=rtpmap:31 H261/90000 566 a=rtpmap:32 MPV/90000 567 a=mid:2 568 a=sendonly 570 SDP Answer - from the splicer 572 v=0 573 o=bob 2808844564 2808844564 IN IP4 splicer.example.com 574 s=RTP Splicing Example 575 c=IN IP4 splicer.example.com 576 t=0 0 577 a=group:SPLICE foo 1 578 a=group:SPLICE bar 2 579 a=group:BUNDLE foo bar 580 m=audio 30000 RTP/AVP 0 581 a=mid:foo 582 b=AS:200 583 a=rtpmap:0 PCMU/8000 584 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 585 a=recvonly 586 m=video 30000 RTP/AVP 32 587 a=mid:bar 588 b=AS:1000 589 a=rtpmap:32 MPV/90000 590 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 591 a=recvonly 592 m=audio 30002 RTP/AVP 0 593 i=Substitutive audio RTP Stream 594 c=IN IP4 splicer.example.com 595 a=rtpmap:0 PCMU/8000 596 a=recvonly 597 a=mid:1 598 m=video 30004 RTP/AVP 32 599 i=Substitutive video RTP Stream 600 c=IN IP4 splicer.example.com 601 a=rtpmap:32 MPV/90000 602 a=mid:2 603 a=recvonly 605 6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced 607 In this example, the substitutive media only applies for video when 608 splicing: 610 1. An Offer, in which the offerer assigns a unique address to each 611 bundled "m="line within the BUNDLE group, and assigns a substitutive 612 media to the bundled video "m=" line for splicing. 614 2. An answer, in which the answerer selects its own BUNDLE address, 615 and leave the substitutive media untouched. 617 SDP Offer - from the main RTP sender: 619 v=0 620 o=alice 1122334455 1122334466 IN IP4 splicing.example.com 621 s=RTP Splicing Example 622 c=IN IP4 splicing.example.com 623 t=0 0 624 a=group:SPLICE bar 2 625 a=group:BUNDLE foo bar 626 m=audio 10000 RTP/AVP 0 8 97 627 a=mid:foo 628 b=AS:200 629 a=rtpmap:0 PCMU/8000 630 a=rtpmap:8 PCMA/8000 631 a=rtpmap:97 iLBC/8000 632 a=sendonly 633 m=video 10002 RTP/AVP 31 32 634 a=mid:bar 635 b=AS:1000 636 a=rtpmap:31 H261/90000 637 a=rtpmap:32 MPV/90000 638 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 639 a=sendonly 640 m=video 20000 RTP/AVP 31 32 641 i=Substitutive video RTP Stream 642 c=IN IP4 substitutive.example.com 643 a=rtpmap:31 H261/90000 644 a=rtpmap:32 MPV/90000 645 a=mid:2 646 a=sendonly 648 SDP Answer - from the splicer: 650 v=0 651 o=bob 2808844564 2808844564 IN IP4 splicer.example.com 652 s=RTP Splicing Example 653 c=IN IP4 splicer.example.com 654 t=0 0 655 a=group:SPLICE bar 2 656 a=group:BUNDLE foo bar 657 m=audio 30000 RTP/AVP 0 658 a=mid:foo 659 b=AS:200 660 a=rtpmap:0 PCMU/8000 661 a=recvonly 662 m=video 30000 RTP/AVP 32 663 a=mid:bar 664 b=AS:1000 665 a=rtpmap:32 MPV/90000 666 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 667 a=recvonly 668 m=video 30004 RTP/AVP 32 669 i=Substitutive video RTP Stream 670 c=IN IP4 splicer.example.com 671 a=rtpmap:32 MPV/90000 672 a=mid:2 673 a=recvonly 675 7 Security Considerations 677 The security considerations of the RTP specification [RFC3550] and 678 the general mechanism for RTP header extensions [RFC5285] apply. The 679 splicer MUST either be a mixer or a translator, and has all the 680 security considerations on these two standard RTP intermediaries. 681 However, the splicer replaces some content with other content in RTP 682 packet, thus breaking any RTP-level end-to-end security, such as 683 source authentication and integrity protection. 685 End to end source authentication is not possible with any known 686 existing splicing solution. A new solution can theoretically be 687 developed that enables identifying the participating entities and 688 what each provides, i.e., the different media sources, man and 689 substituting, and the splicer providing the RTP-level integration of 690 the media payloads in a common timeline and synchronization context. 692 Since the mechanism introduced in this document is not dependent on 693 any RTP payload-level hints for finding the splicing in and out 694 points, Secure Real-Time Transport Protocol (SRTP) [3711] can be used 695 to provide confidentiality of the RTP payload while leaving the RTP 696 header in the clear so that the splicer can still carry out splicing 697 without keying materials. However, for a malicious endpoint without 698 the key, it can observe the splicing time in the RTP header, and it 699 can intercept the substitutive content and even replace it with a 700 different one if the substitutive stream does not use any security 701 like SRTP and the splicer does not authenticate the main and 702 substitutive content sources. 704 If there is a concern about the confidentiality of the splicing time 705 information, header extension encryption [RFC6904] SHOULD be used. 706 However, the malicious endpoint may get the splicing time information 707 by other means, e.g., inferring from the communication between the 708 main and substitutive content sources. To avoid the insertion of 709 invalid substitutive content, the splicer MUST have some mechanisms 710 to authenticate the substitutive stream source. 712 For cases that the splicing time information is changed by a 713 malicious endpoint, the splicing may fail since it will not be 714 available at the right time for the substitutive media to arrive, 715 which may also break an undetectable splicing. To mitigate this 716 effect, the splicer SHOULD NOT forward the splicing time information 717 RTP header extension defined in Section 4.1 to the receivers. And it 718 MUST NOT forward this header extension when considering an 719 undetectable splicing. 721 8 IANA Considerations 723 8.1 RTCP Control Packet Types 725 Based on the guidelines suggested in [RFC5226], a new RTCP packet 726 format has been registered with the RTCP Control Packet Type (PT) 727 Registry: 729 Name: SNM 731 Long name: Splicing Notification Message 733 Value: TBA 735 Reference: This document 737 8.2 RTP Compact Header Extensions 739 The IANA has also registered a new RTP Compact Header Extension 740 [RFC5285], according to the following: 742 Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval 744 Description: Splicing Interval 746 Contact: Jinwei Xia 748 Reference: This document 750 8.3 SDP Grouping Semantic Extension 751 This document request IANA to register the new SDP grouping semantic 752 extension called "SPLICE". 754 Semantics: Splice 756 Token:SPLICE 758 Reference: This document 760 Contact: Jinwei Xia 762 9 Acknowledgement 764 The authors would like to thank the following individuals who help to 765 review this document and provide very valuable comments: Colin 766 Perkins, Bo Burman, Stephen Botzko, Ben Campbell. 768 10 References 770 10.1 Normative References 772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 773 Requirement Levels", BCP 14, RFC 2119, March 1997. 775 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 776 Jacobson, "RTP: A Transport Protocol for Real-Time 777 Applications", STD 64, RFC 3550, July 2003. 779 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 780 with the Session Description Protocol (SDP)", RFC 3264, 781 June 2002. 783 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 784 Header Extensions", RFC 5285, July 2008. 786 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 787 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 789 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 790 "Network Time Protocol Version 4: Protocol and Algorithms 791 Specification", RFC 5905, June 2010. 793 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 794 Flows", RFC 6051, November 2010. 796 10.2 Informative References 798 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 799 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 800 RFC 3711, March 2004. 802 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 803 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 804 May 2008. 806 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 807 Real-Time Transport Control Protocol (RTCP): Opportunities 808 and Consequences", RFC 5506, April 2009. 810 [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, 811 "Unicast-Based Rapid Acquisition of Multicast RTP 812 Sessions", RFC 6285, June 2011. 814 [RFC6904] Lennox, J.,"Encryption of Header Extensions in the Secure 815 Real-Time Transport Protocol (SRTP)", April 2013. 817 [SCTE35] Society of Cable Telecommunications Engineers (SCTE), 818 "Digital Program Insertion Cueing Message for Cable", 819 2011. 821 [RFC6828] Xia, J., "Content Splicing for RTP Sessions", RFC 6828, 822 January 2013. 824 Authors' Addresses 826 Jinwei Xia 827 Huawei 829 Email: xiajinwei@huawei.com 831 Roni Even 832 Huawei 834 Email: ron.even.tlv@gmail.com 836 Rachel Huang 837 Huawei 839 Email: rachel.huang@huawei.com 841 Lingli Deng 842 China Mobile 844 Email: denglingli@chinamobile.com