idnits 2.17.1 draft-ietf-avtext-splicing-notification-07.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 (May 17, 2016) is 2900 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 normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 7201 ** Downref: Normative reference to an Informational RFC: RFC 7667 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 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: November 18, 2016 Huawei 6 L. Deng 7 China Mobile 8 May 17, 2016 10 RTP/RTCP extension for RTP Splicing Notification 11 draft-ietf-avtext-splicing-notification-07 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. 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 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 However, the Splicing Interval conveyed in the RTP header extension 113 might not reach the splicer successfully. Any splicing un-aware 114 middlebox on the path between the RTP sender might strip this RTP 115 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-format timestamps, representing the main RTP sender 156 wallclock time, for the Splicing-In point and Splicing-Out point 157 per [RFC6828] allowing the splicer to know when to start and end 158 the RTP splicing. 160 Substitutive RTP Sender: 162 The sender of RTP packets carrying the RTP stream that will 163 replace the content in the main RTP stream. 165 2 Overview of RTP Splicing Notification 167 A splicer is designed to handle splicing on the RTP layer at the 168 reserved time slots set by the main RTP sender. This implies that the 169 splicer must first know the Splicing Interval from the main RTP 170 sender before it can start splicing. The splicer can be a mixer as 171 described in [RFC6828]. 173 When a new splicing is forthcoming, the main RTP sender needs to send 174 the Splicing Interval to the splicer. The Splicing Interval SHOULD be 175 sent more than once to mitigate the possible packet loss. To enable 176 the splicer to get the substitutive content before the splicing 177 starts, the main RTP sender MUST send the Splicing Interval far 178 ahead. For example, the main RTP sender can estimate when to send the 179 Splicing Interval based on the round-trip time (RTT) following the 180 mechanisms in section 6.4.1 of [RFC3550] when the splicer sends RTCP 181 RR to the main sender. 183 The substitutive sender also needs to learn the Splicing Interval 184 from the main RTP sender in advance, and thus estimates when to 185 transfer the substitutive content to the splicer. The Splicing 186 Interval could be transmitted from the main RTP sender to the 187 substitutive content using some out-of-band mechanisms, for example, 188 a proprietary mechanism to exchange the Splicing Interval, or the 189 substitutive sender is implemented together with the main RTP sender 190 inside a single device. To ensure the Splicing Interval is valid for 191 both the main RTP sender and the substitutive RTP sender, the two 192 senders MUST share a common reference clock so that the splicer can 193 achieve accurate splicing. The requirements for the common reference 194 clock (e.g. resolution, skew) depend on the codec used by the media 195 content. 197 In this document, the main RTP sender uses a pair of NTP-format 198 timestamps, to indicate when to start and end the splicing to the 199 splicer: the timestamp of the first substitutive RTP packet at the 200 splicing in point, and the timestamp of the first main RTP packet at 201 the splicing out point. 203 When the substitutive RTP sender gets the Splicing Interval, it must 204 prepare the substitutive stream. The main and the substitutive 205 content providers MUST ensure that the RTP timestamp of the first 206 substitutive RTP packet that would be presented to the receivers 207 corresponds to the same time instant as the former NTP-format 208 timestamp in the Splicing Interval. To enable the splicer to know the 209 first substitutive RTP packet it needs to send, the substitutive RTP 210 sender MUST send the substitutive RTP packet ahead of the Splicing In 211 point, allowing the splicer to find out the timestamp of this first 212 RTP packet in the substitutive RTP stream, e.g., using a prior RTCP 213 SR (Sender Report) message. 215 When the splicing will end, the main content provider and the 216 substitutive content provider MUST ensure the RTP timestamp of the 217 first main RTP packet that would be presented on the receivers 218 corresponds to the same time instant as the latter NTP-format 219 timestamp in the Splicing Interval. 221 3 Conveying Splicing Interval in RTP/RTCP extensions 223 This memo defines two backwards compatible RTP extensions to convey 224 the Splicing Interval to the splicer: an RTP header extension and an 225 RTCP splicing notification message. 227 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 This RTP header extension carries the 7 octets splicing-out NTP- 233 format timestamp (lower 24-bit part of the Seconds of a NTP-format 234 timestamp and the 32 bits of the Fraction of a NTP-format timestamp 235 as defined in [RFC5905]), followed by the 8 octets splicing-in NTP- 236 format 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, under 239 the assumption that the splicing-out time is after the splicing-in 240 time, and the splicing interval is less than 2^25 seconds. Therefore, 241 if the value of 7 octets splicing-out NTP-format timestamp is smaller 242 than the value of 7 lower octets splicing-in NTP-format, it implies a 243 wrap of the 56-bit splicing-out NTP-format timestamp which means the 244 top 8-bit value of the 64-bit splicing-out is equal to the top 8-bit 245 value of splicing-in NTP Timestamp plus 0x01. Otherwise, the top 8 246 bits of splicing-out NTP timestamp is equal to the top 8 bits of 247 splicing-in NTP Timestamp. 249 This RTP header extension can be encoded using either the one-byte or 250 two-byte header defined in [RFC5285]. Figure 1 and 2 show the 251 splicing interval header extension with each of the two header 252 formats. 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E 257 | ID | L=14 | OUT NTP timestamp format - Seconds (bit 8-31) |x 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t 259 | OUT NTP timestamp format - Fraction (bit 0-31) |e 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 261 | IN NTP timestamp format - Seconds (bit 0-31) |s 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i 263 | IN NTP timestamp format - Fraction (bit 0-31) |o 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 266 Figure 1: Splicing Interval 267 Using the One-Byte Header Format 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E 272 | ID | L=15 | OUT NTP timestamp - Seconds |x 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t 274 |Out Secds(cont)| OUT NTP timestamp format - Fraction |e 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 276 |Out Fract(cont)| IN NTP timestamp format - Seconds |s 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i 278 | In Secds(cont)| IN NTP timestamp format - Fraction |o 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 280 | In Fract(cont)| 0 (pad) | ... 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 2: Splicing Interval 284 Using the Two-Byte Header Format 286 Since the inclusion of an RTP header extension will reduce the 287 efficiency of RTP header compression, it is RECOMMENDED that the main 288 sender inserts the RTP header extensions into only a number of RTP 289 packets, instead of all the RTP packets, prior to the splicing in. 291 After the splicer intercepts the RTP header extension and derives the 292 Splicing Interval, it will generate its own stream and SHOULD NOT 293 include the RTP header extension in outgoing packets to reduce header 294 overhead. 296 3.2 RTCP Splicing Notification Message 298 In addition to the RTP header extension, the main RTP sender includes 299 the Splicing Interval in an RTCP splicing notification message. 300 Whether or not the timestamps are included in the RTP header 301 extension, the main RTP sender MUST send the RTCP splicing 302 notification message. This provide robustness in the case where a 303 middlebox strips RTP header extensions. The main RTP sender MUST make 304 sure the splicing information contained in the RTCP splicing 305 notification message consistent with the information included in the 306 RTP header extensions. 308 The RTCP splicing notification message is a new RTCP packet type. It 309 has a fixed header followed by a pair of NTP-format timestamps: 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 |V=2|P|reserved | PT=TBA | length | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | SSRC | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | IN NTP Timestamp (most significant word) | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | IN NTP Timestamp (least significant word) | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | OUT NTP Timestamp (most significant word) | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | OUT NTP Timestamp (least significant word) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 2: RTCP Splicing Notification Message 329 The RSI packet includes the following fields: 331 Length: 16 bits 333 As defined in [RFC3550], the length of the RTCP packet in 32-bit 334 words minus one, including the header and any padding. 336 SSRC: 32 bits 338 The SSRC of the Main RTP Sender. 340 Timestamp: 64 bits 342 Indicates the wallclock time when this splicing starts and ends. 343 The full-resolution NTP-format timestamp is used, which is a 64- 344 bit, unsigned, fixed-point number with the integer part in the 345 first 32 bits and the fractional part in the last 32 bits. This 346 format is same as the NTP timestamp field in the RTCP Sender 347 Report (Section 6.4.1 of [RFC3550]). 349 The RTCP splicing notification message can be included in the RTCP 350 compound packet together with RTCP SR generated at the main RTP 351 sender, and hence follows the compound RTCP rules defined in Section 352 6.1 in [RFC3550]. 354 If the use of non-compound RTCP [RFC5506] was previously negotiated 355 between the sender and the splicer, the RTCP splicing notification 356 message may be sent as non-compound RTCP packets. In some cases that 357 the mapping from RTP timestamp to NTP timestamp changes, e.g., clock 358 drift happening before the splicing event, it may be required to send 359 RTCP SR or even updated Splicing Interval information timely to 360 update the timestamp mapping for accurate splicing. 362 When the splicer intercepts the RTCP splicing notification message, 363 it SHOULD NOT forward the message to the down-stream receivers in 364 order to reduce RTCP bandwidth consumption. And if the splicer wishes 365 to prevent the downstream receivers from detecting splicing, it MUST 366 NOT forward the message. 368 4 Reducing Splicing Latency 370 When splicing starts or ends, the splicer outputs the multimedia 371 content from another sender to the receivers. Given that the 372 receivers must first acquire certain information ([RFC6285] refers to 373 this information as Reference Information) to start processing the 374 multimedia data, either the main RTP sender or the substitutive 375 sender SHOULD provide the Reference Information together with its 376 multimedia content to reduce the delay caused by acquiring the 377 Reference Information. The methods by which the Reference Information 378 is distributed to the receivers is out of scope of this memo. 380 Another latency element is synchronization caused delay. The 381 receivers must receive enough synchronization metadata prior to 382 synchronizing the separate components of the multimedia streams when 383 splicing starts or ends. Either the main RTP sender or the 384 substitutive sender SHOULD send the synchronization metadata early 385 enough so that the receivers can play out the multimedia in a 386 synchronized fashion. The main RTP sender and the substitutive sender 387 can be coordinated by some proprietary out-of-band mechanisms to 388 decide when and whom to send the metadata. If both send the 389 information, the splicer SHOULD pick one based on the current 390 situation, e.g., choosing media sender when synchronizing the main 391 media content while choosing the information from the substitutive 392 sender when synchronizing the spliced content. The mechanisms defined 393 in [RFC6051] are RECOMMENDED to be adopted to reduce the possible 394 synchronization delay. 396 5 Failure Cases 398 This section examines the implications of losing RTCP splicing 399 notification message and the other failure case, e.g., the RTP header 400 extension is stripped on the path. 402 Given that there may be a splicing un-aware middlebox on the path 403 between the main RTP sender and the splicer, the main and the 404 substitutive RTP senders can use one heuristic to verify whether or 405 not the Splicing Interval reaches the splicer. 407 The splicer can be implemented to have its own SSRC, and send RTCP 408 reception reports to the senders of the main and substitutive RTP 409 streams. This allows the senders to detect problems on the path to 410 the splicer. Alternatively, it is possible to implement the splicer 411 such that it has no SSRC, and does not send RTCP reports; this 412 prevents the senders from being able to monitor the quality to the 413 path to the splicer. 415 If the splicer has an SSRC and sends its own RTCP reports, it can 416 choose not to pass RTCP reports it receives from the receivers to the 417 senders. This will stop the senders from being able to monitor the 418 quality of the paths from the splicer to the receivers. 420 A splicer that has an SSRC can choose to pass RTCP reception reports 421 from the receivers back to the senders, after modifications to 422 account for the splicing. This will allow the senders the monitor the 423 quality of the paths from the splicer to the receivers. A splicer 424 that does not have its own SSRC has to forward and translation RTCP 425 reports from the receiver, otherwise the senders will not see any 426 receivers in the RTP session. 428 If the splicer is implemented following [RFC6828], it will have its 429 own SSRC and will send its own RTCP reports, and will forward 430 translated RTCP reports from the receivers. 432 Upon the detection of a failure, the splicer can communicate with the 433 main sender and the substitutive sender in some out of band signaling 434 ways to fall back to the payload specific mechanisms it supports, 435 e.g., MPEG-TS splicing solution defined in [SCTE35], or just abandon 436 the splicing. 438 6 Session Description Protocol (SDP) Signaling 440 This document defines the URI for declaring this header extension in 441 an extmap attribute to be "urn:ietf:params:rtp-hdrext:splicing- 442 interval". 444 This document extends the standard semantics defined in SDP Grouping 445 Framework [RFC5888] with a new semantic: SPLICE to represent the 446 relationship between the main RTP stream and the substitutive RTP 447 stream. Only 2 m-lines are allowed in the SPLICE group. The main RTP 448 stream is the one with the extended extmap attribute, and the other 449 one is substitutive stream. A single m-line MUST NOT be included in 450 different SPLICE groups at the same time. The main RTP sender 451 provides the information about both main and substitutive sources. 453 The extended SDP attribute specified in this document is applicable 454 for offer/answer content [RFC3264] and do not affect any rules when 455 negotiating offer and answer. When used with multiple m-lines, 456 substitutive RTP MUST be applied only to the RTP packets whose SDP m- 457 line is in the same group with the substitutive stream using SPLICE 458 and has the extended splicing extmap attribute. This semantic is also 459 applicable for BUNDLE cases. 461 The following examples show how SDP signaling could be used for 462 splicing in different cases. 464 6.1 Declarative SDP 466 v=0 467 o=xia 1122334455 1122334466 IN IP4 splicing.example.com 468 s=RTP Splicing Example 469 t=0 0 470 a=group:SPLICE 1 2 471 m=video 30000 RTP/AVP 100 472 i=Main RTP Stream 473 c=IN IP4 233.252.0.1/127 474 a=rtpmap:100 MP2T/90000 475 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 476 a=mid:1 477 m=video 30002 RTP/AVP 100 478 i=Substitutive RTP Stream 479 c=IN IP4 233.252.0.2/127 480 a=sendonly 481 a=rtpmap:100 MP2T/90000 482 a=mid:2 484 Figure 3: Example SDP for a single-channel splicing scenario 486 The splicer receiving the SDP message above receives one MPEG2-TS 487 stream (payload 100) from the main RTP sender (with multicast 488 destination address of 233.252.0.1) on port 30000, and/or receives 489 another MPEG2-TS stream from the substitutive RTP sender (with 490 multicast destination address of 233.252.0.2) on port 30002. But at 491 a particular point in time, the splicer only selects one stream and 492 outputs the content from the chosen stream to the downstream 493 receivers. 495 6.2 Offer/Answer without BUNDLE 497 SDP Offer - from main RTP sender 499 v=0 500 o=xia 1122334455 1122334466 IN IP4 splicing.example.com 501 s=RTP Splicing Example 502 t=0 0 503 a=group:SPLICE 1 2 504 m=video 30000 RTP/AVP 31 100 505 i=Main RTP Stream 506 c=IN IP4 splicing.example.com 507 a=rtpmap:31 H261/90000 508 a=rtpmap:100 MP2T/90000 509 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 510 a=sendonly 511 a=mid:1 512 m=video 40000 RTP/AVP 31 100 513 i=Substitutive RTP Stream 514 c=IN IP4 substitutive.example.com 515 a=rtpmap:31 H261/90000 516 a=rtpmap:100 MP2T/90000 517 a=sendonly 518 a=mid:2 520 SDP Answer - from splicer 522 v=0 523 o=xia 1122334455 1122334466 IN IP4 splicer.example.com 524 s=RTP Splicing Example 525 t=0 0 526 a=group:SPLICE 1 2 527 m=video 30000 RTP/AVP 100 528 i=Main RTP Stream 529 c=IN IP4 splicer.example.com 530 a=rtpmap:100 MP2T/90000 531 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 532 a=recvonly 533 a=mid:1 534 m=video 40000 RTP/AVP 100 535 i=Substitutive RTP Stream 536 c=IN IP4 splicer.example.com 537 a=rtpmap:100 MP2T/90000 538 a=recvonly 539 a=mid:2 541 6.3 Offer/Answer with BUNDLE: All Media are spliced 543 In this example, the bundled audio and video media have their own 544 substitutive media for splicing: 546 1. An Offer, in which the offerer assigns a unique address and a 547 substitutive media to each bundled "m="line for splicing within the 548 BUNDLE group. 550 2. An answer, in which the answerer selects its own BUNDLE address, 551 and leave the substitutive media untouched. 553 SDP Offer - from main RTP sender 555 v=0 556 o=alice 1122334455 1122334466 IN IP4 splicing.example.com 557 s=RTP Splicing Example 558 c=IN IP4 splicing.example.com 559 t=0 0 560 a=group:SPLICE foo 1 561 a=group:SPLICE bar 2 562 a=group:BUNDLE foo bar 563 m=audio 10000 RTP/AVP 0 8 97 564 a=mid:foo 565 b=AS:200 566 a=rtpmap:0 PCMU/8000 567 a=rtpmap:8 PCMA/8000 568 a=rtpmap:97 iLBC/8000 569 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 570 a=sendonly 571 m=video 10002 RTP/AVP 31 32 572 a=mid:bar 573 b=AS:1000 574 a=rtpmap:31 H261/90000 575 a=rtpmap:32 MPV/90000 576 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 577 a=sendonly 578 m=audio 20000 RTP/AVP 0 8 97 579 i=Substitutive audio RTP Stream 580 c=IN IP4 substitive.example.com 581 a=rtpmap:0 PCMU/8000 582 a=rtpmap:8 PCMA/8000 583 a=rtpmap:97 iLBC/8000 584 a=sendonly 585 a=mid:1 586 m=video 20002 RTP/AVP 31 32 587 i=Substitutive video RTP Stream 588 c=IN IP4 substitive.example.com 589 a=rtpmap:31 H261/90000 590 a=rtpmap:32 MPV/90000 591 a=mid:2 592 a=sendonly 594 SDP Answer - from the splicer 596 v=0 597 o=bob 2808844564 2808844564 IN IP4 splicer.example.com 598 s=RTP Splicing Example 599 c=IN IP4 splicer.example.com 600 t=0 0 601 a=group:SPLICE foo 1 602 a=group:SPLICE bar 2 603 a=group:BUNDLE foo bar 604 m=audio 30000 RTP/AVP 0 605 a=mid:foo 606 b=AS:200 607 a=rtpmap:0 PCMU/8000 608 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 609 a=recvonly 610 m=video 30000 RTP/AVP 32 611 a=mid:bar 612 b=AS:1000 613 a=rtpmap:32 MPV/90000 614 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 615 a=recvonly 616 m=audio 30002 RTP/AVP 0 617 i=Substitutive audio RTP Stream 618 c=IN IP4 splicer.example.com 619 a=rtpmap:0 PCMU/8000 620 a=recvonly 621 a=mid:1 622 m=video 30004 RTP/AVP 32 623 i=Substitutive video RTP Stream 624 c=IN IP4 splicer.example.com 625 a=rtpmap:32 MPV/90000 626 a=mid:2 627 a=recvonly 629 6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced 631 In this example, the substitutive media only applies for video when 632 splicing: 634 1. An Offer, in which the offerer assigns a unique address to each 635 bundled "m="line within the BUNDLE group, and assigns a substitutive 636 media to the bundled video "m=" line for splicing. 638 2. An answer, in which the answerer selects its own BUNDLE address, 639 and leave the substitutive media untouched. 641 SDP Offer - from the main RTP sender: 643 v=0 644 o=alice 1122334455 1122334466 IN IP4 splicing.example.com 645 s=RTP Splicing Example 646 c=IN IP4 splicing.example.com 647 t=0 0 648 a=group:SPLICE bar 2 649 a=group:BUNDLE foo bar 650 m=audio 10000 RTP/AVP 0 8 97 651 a=mid:foo 652 b=AS:200 653 a=rtpmap:0 PCMU/8000 654 a=rtpmap:8 PCMA/8000 655 a=rtpmap:97 iLBC/8000 656 a=sendonly 657 m=video 10002 RTP/AVP 31 32 658 a=mid:bar 659 b=AS:1000 660 a=rtpmap:31 H261/90000 661 a=rtpmap:32 MPV/90000 662 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 663 a=sendonly 664 m=video 20000 RTP/AVP 31 32 665 i=Substitutive video RTP Stream 666 c=IN IP4 substitutive.example.com 667 a=rtpmap:31 H261/90000 668 a=rtpmap:32 MPV/90000 669 a=mid:2 670 a=sendonly 672 SDP Answer - from the splicer: 674 v=0 675 o=bob 2808844564 2808844564 IN IP4 splicer.example.com 676 s=RTP Splicing Example 677 c=IN IP4 splicer.example.com 678 t=0 0 679 a=group:SPLICE bar 2 680 a=group:BUNDLE foo bar 681 m=audio 30000 RTP/AVP 0 682 a=mid:foo 683 b=AS:200 684 a=rtpmap:0 PCMU/8000 685 a=recvonly 686 m=video 30000 RTP/AVP 32 687 a=mid:bar 688 b=AS:1000 689 a=rtpmap:32 MPV/90000 690 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 691 a=recvonly 692 m=video 30004 RTP/AVP 32 693 i=Substitutive video RTP Stream 694 c=IN IP4 splicer.example.com 695 a=rtpmap:32 MPV/90000 696 a=mid:2 697 a=recvonly 699 7 Security Considerations 701 The security considerations of the RTP specification [RFC3550] and 702 the general mechanism for RTP header extensions [RFC5285] apply. The 703 splicer can either be a mixer or a translator, and all the security 704 considerations of these two RTP intermediaries topologies described 705 in [RFC7667] and [RFC7201] are applicable for the splicer. 707 The splicer replaces some content with other content in RTP packet, 708 thus breaking any RTP-level end-to-end security, such as source 709 authentication and integrity protection. End to end source 710 authentication is not possible with any known existing splicing 711 solution. A new solution can theoretically be developed that enables 712 identification of the participating entities and what each provides, 713 i.e., the different media sources, main and substituting, and the 714 splicer which provides the RTP-level integration of the media 715 payloads in a common timeline and synchronization context. 717 Since splicer works as a trusted entity, any RTP-level or outside 718 security mechanism, such as IPsec[RFC4301] or Datagram Transport 719 Layer Security [RFC6347], will use a security association between the 720 splicer and the receiver. When using the Secure Real-Time Transport 721 Protocol (SRTP) [RFC3711], the splicer could be provisioned with the 722 same security association as the main RTP sender. 724 If there is a concern about the confidentiality of the splicing time 725 information, header extension encryption [RFC6904] SHOULD be used. 726 However, the malicious endpoint may get the splicing time information 727 by other means, e.g., inferring from the communication between the 728 main and substitutive content sources. To avoid the insertion of 729 invalid substitutive content, the splicer MUST have some mechanisms 730 to authenticate the substitutive stream source. 732 For cases that the splicing time information is changed by a 733 malicious endpoint, the splicing, for example, may fail since it will 734 not be available at the right time for the substitutive media to 735 arrive. Another case is that an attacker may prevent the receivers 736 receiving the content from the main sender by inserting extra 737 splicing time information. To avoid the above cases happening, the 738 authentication of the RTP header extension for splicing time 739 information SHOULD be considered. 741 A malicious endpoint may also break an undetectable splicing. To 742 mitigate this effect, the splicer SHOULD NOT forward the splicing 743 time information RTP header extension defined in Section 4.1 to the 744 receivers. And it MUST NOT forward this header extension when 745 considering an undetectable splicing. 747 8 IANA Considerations 749 8.1 RTCP Control Packet Types 751 Based on the guidelines suggested in [RFC5226], a new RTCP packet 752 format has been registered with the RTCP Control Packet Type (PT) 753 Registry: 755 Name: SNM 757 Long name: Splicing Notification Message 759 Value: TBA 761 Reference: This document 763 8.2 RTP Compact Header Extensions 765 The IANA has also registered a new RTP Compact Header Extension 766 [RFC5285], according to the following: 768 Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval 770 Description: Splicing Interval 772 Contact: Jinwei Xia 774 Reference: This document 776 8.3 SDP Grouping Semantic Extension 778 This document request IANA to register the new SDP grouping semantic 779 extension called "SPLICE". 781 Semantics: Splice 783 Token:SPLICE 785 Reference: This document 787 Contact: Jinwei Xia 789 9 Acknowledgement 791 The authors would like to thank the following individuals who help to 792 review this document and provide very valuable comments: Colin 793 Perkins, Bo Burman, Stephen Botzko, Ben Campbell. 795 10 References 797 10.1 Normative References 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, March 1997. 802 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 803 Jacobson, "RTP: A Transport Protocol for Real-Time 804 Applications", STD 64, RFC 3550, July 2003. 806 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 807 with the Session Description Protocol (SDP)", RFC 3264, 808 June 2002. 810 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 811 Internet Protocol", RFC 4301, December 2005. 813 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 814 Header Extensions", RFC 5285, July 2008. 816 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 817 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 819 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 820 "Network Time Protocol Version 4: Protocol and Algorithms 821 Specification", RFC 5905, June 2010. 823 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 824 Flows", RFC 6051, November 2010. 826 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 827 Security Version 1.2", RFC 6347, January 2012. 829 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 830 Sessions", RFC 7201, April 2014. 832 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 833 November 2015. 835 10.2 Informative References 837 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 838 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 839 RFC 3711, March 2004. 841 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 842 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 843 May 2008. 845 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 846 Real-Time Transport Control Protocol (RTCP): Opportunities 847 and Consequences", RFC 5506, April 2009. 849 [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, 850 "Unicast-Based Rapid Acquisition of Multicast RTP 851 Sessions", RFC 6285, June 2011. 853 [RFC6904] Lennox, J.,"Encryption of Header Extensions in the Secure 854 Real-Time Transport Protocol (SRTP)", April 2013. 856 [SCTE35] Society of Cable Telecommunications Engineers (SCTE), 857 "Digital Program Insertion Cueing Message for Cable", 858 2011. 860 [RFC6828] Xia, J., "Content Splicing for RTP Sessions", RFC 6828, 861 January 2013. 863 Authors' Addresses 865 Jinwei Xia 866 Huawei 868 Email: xiajinwei@huawei.com 870 Roni Even 871 Huawei 873 Email: ron.even.tlv@gmail.com 874 Rachel Huang 875 Huawei 877 Email: rachel.huang@huawei.com 879 Lingli Deng 880 China Mobile 882 Email: denglingli@chinamobile.com