idnits 2.17.1 draft-ietf-avtext-splicing-notification-08.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 (June 28, 2016) is 2859 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) ** 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: 3 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: December 30, 2016 Huawei 6 L. Deng 7 China Mobile 8 June 28, 2016 10 RTP/RTCP extension for RTP Splicing Notification 11 draft-ietf-avtext-splicing-notification-08 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1 Overview of RTP Splicing . . . . . . . . . . . . . . . . . . 4 68 2.2 Overview of Splicing Interval . . . . . . . . . . . . . . . 5 69 3 Conveying Splicing Interval in RTP/RTCP extensions . . . . . . 5 70 3.1 RTP Header Extension . . . . . . . . . . . . . . . . . . . . 5 71 3.2 RTCP Splicing Notification Message . . . . . . . . . . . . . 6 72 4 Reducing Splicing Latency . . . . . . . . . . . . . . . . . . . 7 73 5 Failure Cases . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6.1 Declarative SDP . . . . . . . . . . . . . . . . . . . . . . 9 76 6.2 Offer/Answer without BUNDLE . . . . . . . . . . . . . . . . 9 77 6.3 Offer/Answer with BUNDLE: All Media are spliced . . . . . . 10 78 6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced . . 12 79 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 13 80 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 81 8.1 RTCP Control Packet Types . . . . . . . . . . . . . . . . . 14 82 8.2 RTP Compact Header Extensions . . . . . . . . . . . . . . . 14 83 8.3 SDP Grouping Semantic Extension . . . . . . . . . . . . . . 14 84 9 Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 10.1 Normative References . . . . . . . . . . . . . . . . . . . 15 87 10.2 Informative References . . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 90 1 Introduction 92 Splicing is a process that replaces some multimedia content with 93 other multimedia content and delivers the substitutive multimedia 94 content to the receivers for a period of time. In some predictable 95 splicing cases, e.g., advertisement insertion, the splicing duration 96 needs to be inside of the specific, pre-designated time slot. Certain 97 timing information about when to start and end the splicing must be 98 first acquired by the splicer in order to start the splicing. This 99 document refers to this information as the Splicing Interval. 101 [SCTE35] provides a method that encapsulates the Splicing Interval 102 inside the MPEG2-TS layer in cable TV systems. When transported in 103 RTP, an middle box designed as the splicer to decode the RTP packets 104 and search for the Splicing Interval inside the payloads is required. 105 The need for such processing increases the workload of the middle box 106 and limits the number of RTP sessions the middle box can 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 new RTCP packet type to carry the same Splicing Interval to the 119 splicer. Since RTCP is also unreliable and may not be so immediate as 120 the in-band way, it's only considered as a complement to the RTP 121 header extension. 123 1.1 Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 In addition, we define following terminologies: 131 Main RTP sender: 133 The sender of RTP packets carrying the main RTP stream. 135 Splicer: 137 An intermediary node that inserts substitutive content into a main 138 RTP stream. The splicer sends substitutive content to the RTP 139 receiver instead of the main content during splicing. It is also 140 responsible for processing RTCP traffic between the RTP sender and 141 the RTP receiver. 143 Splicing-In Point 145 A virtual point in the RTP stream, suitable for substitutive 146 content entry, typically in the boundary between two independently 147 decodable frames. 149 Splicing-Out Point 151 A virtual point in the RTP stream, suitable for substitutive 152 content exit, typically in the boundary between two independently 153 decodable frames. 155 Splicing Interval: 157 The NTP-format timestamps, representing the main RTP sender 158 wallclock time, for the Splicing-In point and Splicing-Out point 159 per [RFC6828] allowing the splicer to know when to start and end 160 the RTP splicing. 162 Substitutive RTP Sender: 164 The sender of RTP packets carrying the RTP stream that will 165 replace the content in the main RTP stream. 167 2 Overview 169 2.1 Overview of RTP Splicing 171 RTP Splicing is intended to replace some multimedia content with 172 certain substitutive multimedia content, and then forward it to the 173 receivers for a period of time. This process is authorized by the 174 main RTP sender that offers a specific time window for inserting the 175 substitutive multimedia content in the main content. A typical usage 176 is that IPTV service provider uses its own regional advertising 177 content to replace national advertising content, the time window of 178 which is explicitly indicated by the IPTV service provider. 180 The splicer is a middlebox handling RTP splicing. It receives main 181 content and substitutive content simultaneously but only chooses to 182 send one of them to the receiver at any point of time. When RTP 183 splicing begins, the splicer sends the substitutive content to the 184 receivers instead of the main content. When RTP splicing ends, the 185 splicer switches back to sending the main content to the receivers. 187 This implies that the receiver is explicitly configured to receive 188 the traffic via the splicer, and will return any RTCP feedback to it 189 in the presence of the splicer. 191 The middlebox working as the splicer can be implemented as either an 192 RTP mixer or as an RTP translator. If implemented as an RTP mixer, 193 [RFC6828] specifies how the splicer can use its own SSRC, sequence 194 number space, and timing model when generating the output stream to 195 receivers, using the CSRC list to indicate whether the original or 196 substitutive content is being delivered. The splicer, on behalf of 197 the content provider, can omit the CSRC list from the RTP packets it 198 generates. This simplifies the design of the receivers, since they 199 don't need to parse the CSRC list, but makes it harder to determine 200 when the splicing is taking place (it requires inspection of the RTP 201 payload data, rather than just the RTP headers). A splicer working as 202 an RTP mixer splits the flow between the sender and receiver into 203 two, and requires separate control loops, for RTCP and congestion 204 control, see Section 4.4 of [RFC6828]. 206 A splicer implemented as an RTP translator [RFC3550] will forward the 207 RTP packets from the original and substitutive senders with their 208 SSRCs intact, but will need to rewrite RTCP sender report packets to 209 account for the splicing. In this case, the congestion control loops 210 run between original sender and receiver, and between the 211 substitutive sender and receiver. The splicer needs to ensure that 212 the RTCP feedback message from the receiver are passed to the right 213 sender to let the congestion control work. 215 2.2 Overview of Splicing Interval 217 To handle splicing on the RTP layer at the reserved time slots set by 218 the main RTP sender, the splicer must first know the Splicing 219 Interval from the main RTP sender before it can start splicing. The 220 splicer can be a mixer as described in [RFC6828]. 222 When a new splicing is forthcoming, the main RTP sender needs to send 223 the Splicing Interval to the splicer. The Splicing Interval SHOULD be 224 sent by RTP header extension or RTCP extension message more than once 225 to mitigate the possible packet loss. To enable the splicer to get 226 the substitutive content before the splicing starts, the main RTP 227 sender MUST send the Splicing Interval far ahead. For example, the 228 main RTP sender can estimate when to send the Splicing Interval based 229 on the round-trip time (RTT) following the mechanisms in section 230 6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main sender. 232 The substitutive sender also needs to learn the Splicing Interval 233 from the main RTP sender in advance, and thus estimates when to 234 transfer the substitutive content to the splicer. The Splicing 235 Interval could be transmitted from the main RTP sender to the 236 substitutive content using some out-of-band mechanisms, for example, 237 a proprietary mechanism to exchange the Splicing Interval, or the 238 substitutive sender is implemented together with the main RTP sender 239 inside a single device. To ensure the Splicing Interval is valid for 240 both the main RTP sender and the substitutive RTP sender, the two 241 senders MUST share a common reference clock so that the splicer can 242 achieve accurate splicing. The requirements for the common reference 243 clock (e.g. resolution, skew) depend on the codec used by the media 244 content. 246 In this document, the main RTP sender uses a pair of NTP-format 247 timestamps, to indicate when to start and end the splicing to the 248 splicer: the timestamp of the first substitutive RTP packet at the 249 splicing in point, and the timestamp of the first main RTP packet at 250 the splicing out point. 252 When the substitutive RTP sender gets the Splicing Interval, it must 253 prepare the substitutive stream. The main and the substitutive 254 content providers MUST ensure that the RTP timestamp of the first 255 substitutive RTP packet that would be presented to the receivers 256 corresponds to the same time instant as the former NTP-format 257 timestamp in the Splicing Interval. To enable the splicer to know the 258 first substitutive RTP packet it needs to send, the substitutive RTP 259 sender MUST send the substitutive RTP packet ahead of the Splicing In 260 point, allowing the splicer to find out the timestamp of this first 261 RTP packet in the substitutive RTP stream, e.g., using a prior RTCP 262 SR (Sender Report) message. 264 When the splicing will end, the main content provider and the 265 substitutive content provider MUST ensure the RTP timestamp of the 266 first main RTP packet that would be presented on the receivers 267 corresponds to the same time instant as the latter NTP-format 268 timestamp in the Splicing Interval. 270 3 Conveying Splicing Interval in RTP/RTCP extensions 272 This memo defines two backwards compatible RTP extensions to convey 273 the Splicing Interval to the splicer: an RTP header extension and an 274 RTCP splicing notification message. 276 3.1 RTP Header Extension 278 The RTP header extension mechanism defined in [RFC5285] can be 279 adapted to carry the Splicing Interval consisting of a pair of NTP- 280 format timestamps. 282 This RTP header extension carries the 7 octets splicing-out NTP- 283 format timestamp (lower 24-bit part of the Seconds of a NTP-format 284 timestamp and the 32 bits of the Fraction of a NTP-format timestamp 285 as defined in [RFC5905]), followed by the 8 octets splicing-in NTP- 286 format timestamp (64-bit NTP-format timestamp as defined in 287 [RFC5905]). The top 8 bits of the splicing-out NTP timestamp are 288 inferred from the top 8 bits of the splicing-in NTP timestamp, under 289 the assumption that the splicing-out time is after the splicing-in 290 time, and the splicing interval is less than 2^25 seconds. Therefore, 291 if the value of 7 octets splicing-out NTP-format timestamp is smaller 292 than the value of 7 lower octets splicing-in NTP-format, it implies a 293 wrap of the 56-bit splicing-out NTP-format timestamp which means the 294 top 8-bit value of the 64-bit splicing-out is equal to the top 8-bit 295 value of splicing-in NTP Timestamp plus 0x01. Otherwise, the top 8 296 bits of splicing-out NTP timestamp is equal to the top 8 bits of 297 splicing-in NTP Timestamp. 299 This RTP header extension can be encoded using either the one-byte or 300 two-byte header defined in [RFC5285]. Figure 1 and 2 show the 301 splicing interval header extension with each of the two header 302 formats. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E 307 | ID | L=14 | OUT NTP timestamp format - Seconds (bit 8-31) |x 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t 309 | OUT NTP timestamp format - Fraction (bit 0-31) |e 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 311 | IN NTP timestamp format - Seconds (bit 0-31) |s 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i 313 | IN NTP timestamp format - Fraction (bit 0-31) |o 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 316 Figure 1: Splicing Interval 317 Using the One-Byte Header Format 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+E 322 | ID | L=15 | OUT NTP timestamp - Seconds |x 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+t 324 |Out Secds(cont)| OUT NTP timestamp format - Fraction |e 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 326 |Out Fract(cont)| IN NTP timestamp format - Seconds |s 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+i 328 | In Secds(cont)| IN NTP timestamp format - Fraction |o 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+n 330 | In Fract(cont)| 0 (pad) | ... 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 2: Splicing Interval 334 Using the Two-Byte Header Format 336 Since the inclusion of an RTP header extension will reduce the 337 efficiency of RTP header compression, it is RECOMMENDED that the main 338 sender inserts the RTP header extensions into only a number of RTP 339 packets, instead of all the RTP packets, prior to the splicing in. 341 After the splicer obtains the RTP header extension and derives the 342 Splicing Interval, it generates its own stream and is not allowed to 343 include the RTP header extension in outgoing packets to reduce header 344 overhead. 346 3.2 RTCP Splicing Notification Message 348 In addition to the RTP header extension, the main RTP sender includes 349 the Splicing Interval in an RTCP splicing notification message. 350 Whether or not the timestamps are included in the RTP header 351 extension, the main RTP sender MUST send the RTCP splicing 352 notification message. This provide robustness in the case where a 353 middlebox strips RTP header extensions. The main RTP sender MUST make 354 sure the splicing information contained in the RTCP splicing 355 notification message consistent with the information included in the 356 RTP header extensions. 358 The RTCP splicing notification message is a new RTCP packet type. It 359 has a fixed header followed by a pair of NTP-format timestamps: 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 |V=2|P|reserved | PT=TBA | length | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | SSRC | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | IN NTP Timestamp (most significant word) | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | IN NTP Timestamp (least significant word) | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | OUT NTP Timestamp (most significant word) | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | OUT NTP Timestamp (least significant word) | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Figure 2: RTCP Splicing Notification Message 379 The RSI packet includes the following fields: 381 Length: 16 bits 383 As defined in [RFC3550], the length of the RTCP packet in 32-bit 384 words minus one, including the header and any padding. 386 SSRC: 32 bits 388 The SSRC of the Main RTP Sender. 390 Timestamp: 64 bits 392 Indicates the wallclock time when this splicing starts and ends. 393 The full-resolution NTP-format timestamp is used, which is a 64- 394 bit, unsigned, fixed-point number with the integer part in the 395 first 32 bits and the fractional part in the last 32 bits. This 396 format is same as the NTP timestamp field in the RTCP Sender 397 Report (Section 6.4.1 of [RFC3550]). 399 The RTCP splicing notification message can be included in the RTCP 400 compound packet together with RTCP SR generated at the main RTP 401 sender, and hence follows the compound RTCP rules defined in Section 402 6.1 in [RFC3550]. 404 If the use of non-compound RTCP [RFC5506] was previously negotiated 405 between the sender and the splicer, the RTCP splicing notification 406 message may be sent as non-compound RTCP packets. In some cases that 407 the mapping from RTP timestamp to NTP timestamp changes, e.g., clock 408 drift happening before the splicing event, it may be required to send 409 RTCP SR or even updated Splicing Interval information timely to 410 update the timestamp mapping for accurate splicing. 412 Since the RTCP splicing notification message is intentionally sent by 413 the main RTP sender to the splicer, the splicer is not allowed to 414 forward this message to the receivers so as to avoid their useless 415 processing and additional RTCP bandwidth consumption in the 416 downstream. 418 4 Reducing Splicing Latency 420 When splicing starts or ends, the splicer outputs the multimedia 421 content from another sender to the receivers. Given that the 422 receivers must first acquire certain information ([RFC6285] refers to 423 this information as Reference Information) to start processing the 424 multimedia data, either the main RTP sender or the substitutive 425 sender SHOULD provide the Reference Information together with its 426 multimedia content to reduce the delay caused by acquiring the 427 Reference Information. The methods by which the Reference Information 428 is distributed to the receivers is out of scope of this memo. 430 Another latency element is synchronization caused delay. The 431 receivers must receive enough synchronization metadata prior to 432 synchronizing the separate components of the multimedia streams when 433 splicing starts or ends. Either the main RTP sender or the 434 substitutive sender SHOULD send the synchronization metadata early 435 enough so that the receivers can play out the multimedia in a 436 synchronized fashion. The main RTP sender or the substitutive sender 437 can estimate when to send the synchronization metadata based on, for 438 example, the round-trip time (RTT) following the mechanisms in 439 section 6.4.1 of [RFC3550] when the splicer sends RTCP RR to the main 440 sender or the substitutive sender. The main RTP sender and the 441 substitutive sender can also be coordinated by some proprietary out- 442 of-band mechanisms to decide when and whom to send the metadata. If 443 both send the information, the splicer SHOULD pick one based on the 444 current situation, e.g., choosing main RTP sender when synchronizing 445 the main media content while choosing the information from the 446 substitutive sender when synchronizing the spliced content. The 447 mechanisms defined in [RFC6051] are RECOMMENDED to be adopted to 448 reduce the possible synchronization delay. 450 5 Failure Cases 452 This section examines the implications of losing RTCP splicing 453 notification message and the other failure case, e.g., the RTP header 454 extension is stripped on the path. 456 Given that there may be a splicing un-aware middlebox on the path 457 between the main RTP sender and the splicer, the main and the 458 substitutive RTP senders can use one heuristic to verify whether or 459 not the Splicing Interval reaches the splicer. 461 The splicer can be implemented to have its own SSRC, and send RTCP 462 reception reports to the senders of the main and substitutive RTP 463 streams. This allows the senders to detect problems on the path to 464 the splicer. Alternatively, it is possible to implement the splicer 465 such that it has no SSRC, and does not send RTCP reports; this 466 prevents the senders from being able to monitor the quality to the 467 path to the splicer. 469 If the splicer has an SSRC and sends its own RTCP reports, it can 470 choose not to pass RTCP reports it receives from the receivers to the 471 senders. This will stop the senders from being able to monitor the 472 quality of the paths from the splicer to the receivers. 474 A splicer that has an SSRC can choose to pass RTCP reception reports 475 from the receivers back to the senders, after modifications to 476 account for the splicing. This will allow the senders the monitor the 477 quality of the paths from the splicer to the receivers. A splicer 478 that does not have its own SSRC has to forward and translation RTCP 479 reports from the receiver, otherwise the senders will not see any 480 receivers in the RTP session. 482 If the splicer is implemented following [RFC6828], it will have its 483 own SSRC and will send its own RTCP reports, and will forward 484 translated RTCP reports from the receivers. 486 Upon the detection of a failure, the splicer can communicate with the 487 main sender and the substitutive sender in some out of band signaling 488 ways to fall back to the payload specific mechanisms it supports, 489 e.g., MPEG-TS splicing solution defined in [SCTE35], or just abandon 490 the splicing. 492 6 Session Description Protocol (SDP) Signaling 494 This document defines the URI for declaring this header extension in 495 an extmap attribute to be "urn:ietf:params:rtp-hdrext:splicing- 496 interval". 498 This document extends the standard semantics defined in SDP Grouping 499 Framework [RFC5888] with a new semantic: SPLICE to represent the 500 relationship between the main RTP stream and the substitutive RTP 501 stream. Only 2 m-lines are allowed in the SPLICE group. The main RTP 502 stream is the one with the extended extmap attribute, and the other 503 one is substitutive stream. A single m-line MUST NOT be included in 504 different SPLICE groups at the same time. The main RTP sender 505 provides the information about both main and substitutive sources. 507 The extended SDP attribute specified in this document is applicable 508 for offer/answer content [RFC3264] and do not affect any rules when 509 negotiating offer and answer. When used with multiple m-lines, 510 substitutive RTP MUST be applied only to the RTP packets whose SDP m- 511 line is in the same group with the substitutive stream using SPLICE 512 and has the extended splicing extmap attribute. This semantic is also 513 applicable for BUNDLE cases. 515 The following examples show how SDP signaling could be used for 516 splicing in different cases. 518 6.1 Declarative SDP 520 v=0 521 o=xia 1122334455 1122334466 IN IP4 splicing.example.com 522 s=RTP Splicing Example 523 t=0 0 524 a=group:SPLICE 1 2 525 m=video 30000 RTP/AVP 100 526 i=Main RTP Stream 527 c=IN IP4 233.252.0.1/127 528 a=rtpmap:100 MP2T/90000 529 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 530 a=mid:1 531 m=video 30002 RTP/AVP 100 532 i=Substitutive RTP Stream 533 c=IN IP4 233.252.0.2/127 534 a=sendonly 535 a=rtpmap:100 MP2T/90000 536 a=mid:2 538 Figure 3: Example SDP for a single-channel splicing scenario 540 The splicer receiving the SDP message above receives one MPEG2-TS 541 stream (payload 100) from the main RTP sender (with multicast 542 destination address of 233.252.0.1) on port 30000, and/or receives 543 another MPEG2-TS stream from the substitutive RTP sender (with 544 multicast destination address of 233.252.0.2) on port 30002. But at 545 a particular point in time, the splicer only selects one stream and 546 outputs the content from the chosen stream to the downstream 547 receivers. 549 6.2 Offer/Answer without BUNDLE 551 SDP Offer - from main RTP sender 553 v=0 554 o=xia 1122334455 1122334466 IN IP4 splicing.example.com 555 s=RTP Splicing Example 556 t=0 0 557 a=group:SPLICE 1 2 558 m=video 30000 RTP/AVP 31 100 559 i=Main RTP Stream 560 c=IN IP4 splicing.example.com 561 a=rtpmap:31 H261/90000 562 a=rtpmap:100 MP2T/90000 563 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 564 a=sendonly 565 a=mid:1 566 m=video 40000 RTP/AVP 31 100 567 i=Substitutive RTP Stream 568 c=IN IP4 substitutive.example.com 569 a=rtpmap:31 H261/90000 570 a=rtpmap:100 MP2T/90000 571 a=sendonly 572 a=mid:2 574 SDP Answer - from splicer 576 v=0 577 o=xia 1122334455 1122334466 IN IP4 splicer.example.com 578 s=RTP Splicing Example 579 t=0 0 580 a=group:SPLICE 1 2 581 m=video 30000 RTP/AVP 100 582 i=Main RTP Stream 583 c=IN IP4 splicer.example.com 584 a=rtpmap:100 MP2T/90000 585 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 586 a=recvonly 587 a=mid:1 588 m=video 40000 RTP/AVP 100 589 i=Substitutive RTP Stream 590 c=IN IP4 splicer.example.com 591 a=rtpmap:100 MP2T/90000 592 a=recvonly 593 a=mid:2 595 6.3 Offer/Answer with BUNDLE: All Media are spliced 597 In this example, the bundled audio and video media have their own 598 substitutive media for splicing: 600 1. An Offer, in which the offerer assigns a unique address and a 601 substitutive media to each bundled "m="line for splicing within the 602 BUNDLE group. 604 2. An answer, in which the answerer selects its own BUNDLE address, 605 and leave the substitutive media untouched. 607 SDP Offer - from main RTP sender 609 v=0 610 o=alice 1122334455 1122334466 IN IP4 splicing.example.com 611 s=RTP Splicing Example 612 c=IN IP4 splicing.example.com 613 t=0 0 614 a=group:SPLICE foo 1 615 a=group:SPLICE bar 2 616 a=group:BUNDLE foo bar 617 m=audio 10000 RTP/AVP 0 8 97 618 a=mid:foo 619 b=AS:200 620 a=rtpmap:0 PCMU/8000 621 a=rtpmap:8 PCMA/8000 622 a=rtpmap:97 iLBC/8000 623 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 624 a=sendonly 625 m=video 10002 RTP/AVP 31 32 626 a=mid:bar 627 b=AS:1000 628 a=rtpmap:31 H261/90000 629 a=rtpmap:32 MPV/90000 630 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 631 a=sendonly 632 m=audio 20000 RTP/AVP 0 8 97 633 i=Substitutive audio RTP Stream 634 c=IN IP4 substitive.example.com 635 a=rtpmap:0 PCMU/8000 636 a=rtpmap:8 PCMA/8000 637 a=rtpmap:97 iLBC/8000 638 a=sendonly 639 a=mid:1 640 m=video 20002 RTP/AVP 31 32 641 i=Substitutive video RTP Stream 642 c=IN IP4 substitive.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 foo 1 656 a=group:SPLICE bar 2 657 a=group:BUNDLE foo bar 658 m=audio 30000 RTP/AVP 0 659 a=mid:foo 660 b=AS:200 661 a=rtpmap:0 PCMU/8000 662 a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval 663 a=recvonly 664 m=video 30000 RTP/AVP 32 665 a=mid:bar 666 b=AS:1000 667 a=rtpmap:32 MPV/90000 668 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 669 a=recvonly 670 m=audio 30002 RTP/AVP 0 671 i=Substitutive audio RTP Stream 672 c=IN IP4 splicer.example.com 673 a=rtpmap:0 PCMU/8000 674 a=recvonly 675 a=mid:1 676 m=video 30004 RTP/AVP 32 677 i=Substitutive video RTP Stream 678 c=IN IP4 splicer.example.com 679 a=rtpmap:32 MPV/90000 680 a=mid:2 681 a=recvonly 683 6.4 Offer/Answer with BUNDLE: a Subset of Media are Spliced 685 In this example, the substitutive media only applies for video when 686 splicing: 688 1. An Offer, in which the offerer assigns a unique address to each 689 bundled "m="line within the BUNDLE group, and assigns a substitutive 690 media to the bundled video "m=" line for splicing. 692 2. An answer, in which the answerer selects its own BUNDLE address, 693 and leave the substitutive media untouched. 695 SDP Offer - from the main RTP sender: 697 v=0 698 o=alice 1122334455 1122334466 IN IP4 splicing.example.com 699 s=RTP Splicing Example 700 c=IN IP4 splicing.example.com 701 t=0 0 702 a=group:SPLICE bar 2 703 a=group:BUNDLE foo bar 704 m=audio 10000 RTP/AVP 0 8 97 705 a=mid:foo 706 b=AS:200 707 a=rtpmap:0 PCMU/8000 708 a=rtpmap:8 PCMA/8000 709 a=rtpmap:97 iLBC/8000 710 a=sendonly 711 m=video 10002 RTP/AVP 31 32 712 a=mid:bar 713 b=AS:1000 714 a=rtpmap:31 H261/90000 715 a=rtpmap:32 MPV/90000 716 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 717 a=sendonly 718 m=video 20000 RTP/AVP 31 32 719 i=Substitutive video RTP Stream 720 c=IN IP4 substitutive.example.com 721 a=rtpmap:31 H261/90000 722 a=rtpmap:32 MPV/90000 723 a=mid:2 724 a=sendonly 726 SDP Answer - from the splicer: 728 v=0 729 o=bob 2808844564 2808844564 IN IP4 splicer.example.com 730 s=RTP Splicing Example 731 c=IN IP4 splicer.example.com 732 t=0 0 733 a=group:SPLICE bar 2 734 a=group:BUNDLE foo bar 735 m=audio 30000 RTP/AVP 0 736 a=mid:foo 737 b=AS:200 738 a=rtpmap:0 PCMU/8000 739 a=recvonly 740 m=video 30000 RTP/AVP 32 741 a=mid:bar 742 b=AS:1000 743 a=rtpmap:32 MPV/90000 744 a=extmap:2 urn:ietf:params:rtp-hdrext:splicing-interval 745 a=recvonly 746 m=video 30004 RTP/AVP 32 747 i=Substitutive video RTP Stream 748 c=IN IP4 splicer.example.com 749 a=rtpmap:32 MPV/90000 750 a=mid:2 751 a=recvonly 753 7 Security Considerations 755 The security considerations of the RTP specification [RFC3550] and 756 the general mechanism for RTP header extensions [RFC5285] apply. The 757 splicer can either be a mixer or a translator, and all the security 758 considerations of these two RTP intermediaries topologies described 759 in [RFC7667] and [RFC7201] are applicable for the splicer. 761 The splicer replaces some content with other content in RTP packet, 762 thus breaking any RTP-level end-to-end security, such as source 763 authentication and integrity protection. End to end source 764 authentication is not possible with any known existing splicing 765 solution. A new solution can theoretically be developed that enables 766 identification of the participating entities and what each provides, 767 i.e., the different media sources, main and substituting, and the 768 splicer which provides the RTP-level integration of the media 769 payloads in a common timeline and synchronization context. 771 Since the splicer breaks RTP-level end-to-end security, it needs to 772 be part of the signaling context and the necessary security 773 associations (e.g., SRTP crypto contexts) established for the RTP 774 session participants. When using the Secure Real-Time Transport 775 Protocol (SRTP) [RFC3711], the splicer would have to be provisioned 776 with the same security association as the main RTP sender. 778 If there is a concern about the confidentiality of the splicing time 779 information, the header extension defined in this document MUST be 780 also protected, for example, header extension encryption [RFC6904] 781 can be used in this case. However, the malicious endpoint may get the 782 splicing time information by other means, e.g., inferring from the 783 communication between the main and substitutive content sources. To 784 avoid the insertion of invalid substitutive content, the splicer MUST 785 have some mechanisms to authenticate the substitutive stream source. 787 For cases that the splicing time information is changed by a 788 malicious endpoint, the splicing, for example, may fail since it will 789 not be available at the right time for the substitutive media to 790 arrive. Another case is that an attacker may prevent the receivers 791 receiving the content from the main sender by inserting extra 792 splicing time information. To avoid the above cases happening, the 793 authentication of the RTP header extension for splicing time 794 information SHOULD be considered. 796 When a splicer implemented as a mixer sends the stream to the 797 receivers, CSRC list, which can be used to detect RTP-level 798 forwarding loops as defined in Section 8.2 of [RFC3550], may be 799 removed for simplifying the receivers that can not handle multiple 800 sources in the RTP stream. Hence, loops may occur to cause packets to 801 loop back to upstream of the splicer and may form a serious denial- 802 of-service threat. In such a case, non-RTP means, e.g., signaling 803 among all the participants, MUST be used to detect and resolve loops. 805 8 IANA Considerations 807 8.1 RTCP Control Packet Types 809 Based on the guidelines suggested in [RFC5226], a new RTCP packet 810 format has been registered with the RTCP Control Packet Type (PT) 811 Registry: 813 Name: SNM 815 Long name: Splicing Notification Message 817 Value: TBA 819 Reference: This document 821 8.2 RTP Compact Header Extensions 823 The IANA has also registered a new RTP Compact Header Extension 824 [RFC5285], according to the following: 826 Extension URI: urn:ietf:params:rtp-hdrext:splicing-interval 828 Description: Splicing Interval 830 Contact: Jinwei Xia 832 Reference: This document 834 8.3 SDP Grouping Semantic Extension 835 This document request IANA to register the new SDP grouping semantic 836 extension called "SPLICE". 838 Semantics: Splice 840 Token:SPLICE 842 Reference: This document 844 9 Acknowledgement 846 The authors would like to thank the following individuals who help to 847 review this document and provide very valuable comments: Colin 848 Perkins, Bo Burman, Stephen Botzko, Ben Campbell. 850 10 References 852 10.1 Normative References 854 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 855 Requirement Levels", BCP 14, RFC 2119, March 1997. 857 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 858 Jacobson, "RTP: A Transport Protocol for Real-Time 859 Applications", STD 64, RFC 3550, July 2003. 861 [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 862 with the Session Description Protocol (SDP)", RFC 3264, 863 June 2002. 865 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 866 Header Extensions", RFC 5285, July 2008. 868 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 869 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 871 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 872 "Network Time Protocol Version 4: Protocol and Algorithms 873 Specification", RFC 5905, June 2010. 875 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 876 Flows", RFC 6051, November 2010. 878 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 879 Sessions", RFC 7201, April 2014. 881 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 882 November 2015. 884 10.2 Informative References 886 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 887 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 888 RFC 3711, March 2004. 890 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 891 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 892 May 2008. 894 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 895 Real-Time Transport Control Protocol (RTCP): Opportunities 896 and Consequences", RFC 5506, April 2009. 898 [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, 899 "Unicast-Based Rapid Acquisition of Multicast RTP 900 Sessions", RFC 6285, June 2011. 902 [RFC6904] Lennox, J.,"Encryption of Header Extensions in the Secure 903 Real-Time Transport Protocol (SRTP)", April 2013. 905 [SCTE35] Society of Cable Telecommunications Engineers (SCTE), 906 "Digital Program Insertion Cueing Message for Cable", 907 2011. 909 [RFC6828] Xia, J., "Content Splicing for RTP Sessions", RFC 6828, 910 January 2013. 912 Authors' Addresses 914 Jinwei Xia 915 Huawei 917 Email: xiajinwei@huawei.com 919 Roni Even 920 Huawei 922 Email: ron.even.tlv@gmail.com 924 Rachel Huang 925 Huawei 926 Email: rachel.huang@huawei.com 928 Lingli Deng 929 China Mobile 931 Email: denglingli@chinamobile.com