idnits 2.17.1 draft-ietf-avtext-splicing-for-rtp-10.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 (October 10, 2012) is 4215 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3711' is defined on line 675, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTEXT Working Group J. Xia 3 Internet-Draft Huawei 4 Intended status: Informational October 10, 2012 5 Expires: April 12, 2013 7 Content Splicing for RTP Sessions 8 draft-ietf-avtext-splicing-for-rtp-10 10 Abstract 12 Content splicing is a process that replaces the content of a main 13 multimedia stream with other multimedia content, and delivers the 14 substitutive multimedia content to the receivers for a period of 15 time. Splicing is commonly used for local advertisement insertion by 16 cable operators, replacing a national advertisement content with a 17 local advertisement. 19 This memo describes some use cases for content splicing and a set of 20 requirements for splicing content delivered by RTP. It provides 21 concrete guidelines for how an RTP mixer can be used to handle 22 content splicing. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 12, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. System Model and Terminology . . . . . . . . . . . . . . . . . 3 60 3. Requirements for RTP Splicing . . . . . . . . . . . . . . . . 6 61 4. Content Splicing for RTP sessions . . . . . . . . . . . . . . 7 62 4.1. RTP Processing in RTP Mixer . . . . . . . . . . . . . . . 7 63 4.2. RTCP Processing in RTP Mixer . . . . . . . . . . . . . . . 8 64 4.3. Considerations for Handling Media Clipping at the RTP 65 Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.4. Congestion Control Considerations . . . . . . . . . . . . 11 67 4.5. Considerations for Implementing Undetectable Splicing . . 12 68 5. Implementation Considerations . . . . . . . . . . . . . . . . 13 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 72 9. 10. Appendix- Why Mixer Is Chosen . . . . . . . . . . . . . . 14 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 1. Introduction 80 This document outlines how content splicing can be used in RTP 81 sessions. Splicing, in general, is a process where part of a 82 multimedia content is replaced with other multimedia content, and 83 delivered to the receivers for a period of time. The substitutive 84 content can be provided for example via another stream or via local 85 media file storage. One representative use case for splicing is 86 local advertisement insertion, allowing content providers to replace 87 the national advertising content with its own regional advertising 88 content prior to delivering the regional advertising content to the 89 receivers. Besides the advertisement insertion use case, there are 90 other use cases in which splicing technology can be applied. For 91 example, splicing a recorded video into a video conferencing session, 92 or implementing a playlist server that stitches pieces of video 93 together. 95 Content splicing is a well-defined operation in MPEG-based cable TV 96 systems. Indeed, the Society for Cable Telecommunications Engineers 97 (SCTE) has created two standards, [SCTE30] and [SCTE35], to 98 standardize MPEG2-TS splicing procedure. SCTE 30 creates a 99 standardized method for communication between advertisements server 100 and splicer, and SCTE 35 supports splicing of MPEG2 transport 101 streams. 103 When using multimedia splicing into the internet, the media may be 104 transported by RTP. In this case the original media content and 105 substitutive media content will use the same time period, but may 106 contain different numbers of RTP packets due to different media 107 codecs and entropy coding. This mismatch may require some 108 adjustments of the RTP header sequence number to maintain 109 consistency. [RFC3550] provides the tools to enabled seamless 110 content splicing in RTP session, but to date there has been no clear 111 guidelines on how to use these tools. 113 This memo outlines the requirements for content splicing in RTP 114 sessions and describes how an RTP mixer can be used to meet these 115 requirements. 117 2. System Model and Terminology 119 In this document, an intermediary network element, the Splicer 120 handles RTP splicing. The Splicer can receive main content and 121 substitutive content simultaneously, but will send one of them at one 122 point of time. 124 When RTP splicing begins, the splicer sends the substitutive content 125 to the RTP receiver instead of the main content for a period of time. 126 When RTP splicing ends, the splicer switches back sending the main 127 content to the RTP receiver. 129 A simplified RTP splicing diagram is depicted in Figure 1, in which 130 only one main content flow and one substitutive content flow are 131 given. Actually, the splicer can handle multiple splicing for 132 multiple RTP sessions simultaneously. RTP splicing may happen more 133 than once in multiple time slots during the lifetime of the main RTP 134 stream. The methods how splicer learns when to start and end the 135 splicing is out of scope for this document. 137 +---------------+ 138 | | Main Content +-----------+ 139 | Main RTP |------------->| | Output Content 140 | Content | | Splicer |---------------> 141 +---------------+ ---------->| | 142 | +-----------+ 143 | 144 | Substitutive Content 145 | 146 | 147 +-----------------------+ 148 | Substitutive RTP | 149 | Content | 150 | or | 151 | Local File Storage | 152 +-----------------------+ 154 Figure 1: RTP Splicing Architecture 156 This document uses the following terminologies. 158 Output RTP Stream 160 The RTP stream that the RTP receiver is currently receiving. The 161 content of output RTP stream can be either main content or 162 substitutive content. 164 Main Content 166 The multimedia content that are conveyed in main RTP stream. Main 167 content will be replaced by the substitutive content during 168 splicing. 170 Main RTP Stream 172 The RTP stream that the splicer is receiving. The content of main 173 RTP stream can be replaced by substitutive content for a period of 174 time. 176 Main RTP Sender 178 The sender of RTP packets carrying the main RTP stream. 180 Substitutive Content 182 The multimedia content that replaces the main content during 183 splicing. The substitutive content can for example be contained 184 in an RTP stream from a media sender or fetched from local media 185 file storage. 187 Substitutive RTP Stream 189 A RTP stream with new content that will replace the content in the 190 main RTP stream. Substitutive RTP stream and main RTP stream are 191 two separate streams. If the substitutive content is provided via 192 substitutive RTP stream, the substitutive RTP Stream must pass 193 through the splicer before the substitutive content is delivered 194 to receiver. 196 Substitutive RTP Sender 198 The sender of RTP packets carrying the substitutive RTP stream. 200 Splicing In Point 202 A virtual point in the RTP stream, suitable for substitutive 203 content entry, typically in the boundary between two independently 204 decodable frames. 206 Splicing Out Point 208 A virtual point in the RTP stream, suitable for substitutive 209 content exist, typically in the boundary between two independently 210 decodable frames. 212 Splicer 214 An intermediary node that inserts substitutive content into main 215 RTP stream. The splicer sends substitutive content to RTP 216 receiver instead of main content during splicing. It is also 217 responsible for processing RTCP traffic between the RTP sender and 218 the RTP receiver. 220 3. Requirements for RTP Splicing 222 In order to allow seamless content splicing at the RTP layer, the 223 following requirements must be met. Meeting these will also allow, 224 but not require, seamless content splicing at layers above RTP. 226 REQ-1: 228 The splicer should be agnostic about the network and transport 229 layer protocols used to deliver the RTP streams. 231 REQ-2: 233 The splicing operation at the RTP layer must allow splicing at any 234 point required by the media content, and must not constrain when 235 splicing in or splicing out operations can take place. 237 REQ-3: 239 Splicing of RTP content must be backward compatible with the RTP/ 240 RTCP protocol, associated profiles, payload formats, and 241 extensions. 243 REQ-4: 245 The splicer will modify the content of RTP packets, and break the 246 end-to-end security, e.g., breaking data integrity and source 247 authentication. If the Splicer is designated to insert 248 substitutive content, it must be trusted, i.e., be in the security 249 context(s) as the main RTP sender, the substitutive RTP sender, 250 and the receivers. If encryption is employed, the splicer must be 251 able to decrypt the inbound RTP packets and re-encrypt the 252 outbound RTP packets after splicing. 254 REQ-5: 256 The splicer should rewrite as necessary and forward RTCP messages 257 (e.g., including packet loss, jitter, etc.) sent from downstream 258 receiver to the main RTP sender or the substitutive RTP sender, 259 and thus allow the main RTP sender or substitutive RTP sender to 260 learn the performance of the downstream receiver when its content 261 is being passed to RTP receiver. In addition, the splicer should 262 rewrite RTCP messages from the main RTP sender or substitutive RTP 263 sender to the receiver. 265 REQ-6: 267 The splicer must not affect other RTP sessions running between the 268 RTP sender and the RTP receiver, and must be transparent for the 269 RTP sessions it does not splice. 271 REQ-7: 273 The splicer should be able to modify the RTP stream such that the 274 splicing point is not easy to be detected by the RTP receiver at 275 the RTP layer. For the advertisement insertion use case, it is 276 important to make it difficult for the RTP receiver to detect 277 where an advertisement insertion is starting or ending from the 278 RTP packets, and thus avoiding the RTP receiver from filtering out 279 the advertisement content. This memo only focuses on making the 280 splicing undetectable at the RTP layer. How (or if) the splicing 281 is made undetectable in the media stream is outside the scope of 282 this memo. The corresponding processing is depicted in section 283 4.5. 285 4. Content Splicing for RTP sessions 287 The RTP specification [RFC3550] defines two types of middlebox: RTP 288 translators and RTP mixers. Splicing is best viewed as a mixing 289 operation. The splicer generates a new RTP stream that is a mix of 290 the main RTP stream and the substitutive RTP stream. An RTP mixer is 291 therefore an appropriate model for a content splicer. In next four 292 subsections (from subsection 4.1 to subsection 4.4), the document 293 analyzes how the mixer handles RTP splicing and how it satisfies the 294 general requirements listed in section 3. In subsection 4.5, the 295 document looks at REQ-7 in order to hide the fact that splicing take 296 place. 298 4.1. RTP Processing in RTP Mixer 300 A splicer could be implemented as a mixer that receives the main RTP 301 stream and the substitutive content (possibly via a substitutive RTP 302 stream), and sends a single output RTP stream to the receiver(s). 303 That output RTP stream will contain either the main content or the 304 substitutive content. The output RTP stream will come from the 305 mixer, and will have the synchronization source (SSRC) of the mixer 306 rather than the main RTP sender or the substitutive RTP sender. 308 The mixer uses its own SSRC, sequence number space and timing model 309 when generating the output stream. Moreover, the mixer may insert 310 the SSRC of main RTP stream into contributing source (CSRC) list in 311 the output media stream. 313 At the splicing in point, when the substitutive content becomes 314 active, the mixer chooses the substitutive RTP stream as input stream 315 at splicing in point, and extracts the payload data (i.e., 316 substitutive content). If the substitutive content comes from local 317 media file storage, the mixer directly fetches the substitutive 318 content. After that, the mixer encapsulates substitutive content 319 instead of main content as the payload of the output media stream, 320 and then sends the output RTP media stream to receiver. The mixer 321 may insert the SSRC of substitutive RTP stream into CSRC list in the 322 output media stream. If the substitutive content comes from local 323 media file storage, the mixer should leave the CSRC list blank. 325 At the splicing out point, when the substitutive content ends, the 326 mixer retrieves the main RTP stream as input stream at splicing out 327 point, and extracts the payload data (i.e., main content). After 328 that, the mixer encapsulates main content instead of substitutive 329 content as the payload of the output media stream, and then sends the 330 output media stream to the receivers. Moreover, the mixer may insert 331 the SSRC of main RTP stream into CSRC list in the output media stream 332 as before. 334 Note that if the content is too large to fit into RTP packets sent to 335 RTP receiver, the mixer needs to transcode or perform application- 336 layer fragmentation. Usually the mixer is deployed as part of a 337 managed system and MTU will be carefully managed by this system. 338 This document does not raise any new MTU related issues compared to a 339 standard mixer described in [RFC3550]. 341 Splicing may occur more than once during the lifetime of main RTP 342 stream, this means the mixer needs to send main content and 343 substitutive content in turn with its own SSRC identifier. From 344 receiver point of view, the only source of the output stream is the 345 mixer regardless of where the content is coming from. 347 4.2. RTCP Processing in RTP Mixer 349 By monitoring available bandwidth and buffer levels and by computing 350 network metrics such as packet loss, network jitter, and delay, RTP 351 receiver can learn the network performance and communicate this to 352 the RTP sender via RTCP reception reports. 354 According to the description in section 7.3 of [RFC3550], the mixer 355 splits the RTCP flow between sender and receiver into two separate 356 RTCP loops, RTP sender has no idea about the situation on the 357 receiver. But splicing is a processing that the mixer selects one 358 media stream from multiple streams rather than mixing them, so the 359 mixer can leave the SSRC identifier in the RTCP report intact (i.e., 360 the SSRC of downstream receiver), this enables the main RTP sender or 361 the substitutive RTP sender to learn the situation on the receiver. 363 If the RTCP report corresponds to a time interval that is entirely 364 main content or entirely substitutive content, the number of output 365 RTP packets containing substitutive content is equal to the number of 366 input substitutive RTP packets (from substitutive RTP stream) during 367 splicing, in the same manner, the number of output RTP packets 368 containing main content is equal to the number of input main RTP 369 packets (from main RTP stream) during non-splicing unless the mixer 370 fragment the input RTP packets. This means that the mixer does not 371 need to modify the loss packet fields in reception report blocks in 372 RTCP reports. But if the mixer fragments the input RTP packets, it 373 may need to modify the loss packet fields to compensate for the 374 fragmentation. Whether the input RTP packets are fragmented or not, 375 the mixer still needs to change the SSRC field in report block to the 376 SSRC identifier of the main RTP sender or the substitutive RTP 377 sender, and rewrite the extended highest sequence number field to the 378 corresponding original extended highest sequence number before 379 forwarding the RTCP report to the main RTP sender or the substitutive 380 RTP sender. 382 If the RTCP report spans the splicing in point or the splicing out 383 point, it reflects the characteristics of the combination of main RTP 384 packets and substitutive RTP packets. In this case, the mixer needs 385 to divide the RTCP report into two separate RTCP reports and send 386 them to their original RTP senders respectively. For each RTCP 387 report, the mixer also needs to make the corresponding changes to the 388 packet loss fields in report block besides the SSRC field and the 389 extended highest sequence number field. 391 If the mixer receives an RTCP extended report (XR) block, it should 392 rewrite the XR report block in a similar way to the reception report 393 block in the RTCP report. 395 Besides forwarding the RTCP reports sent from RTP receiver, the mixer 396 can also generate its own RTCP reports to inform the main RTP sender 397 or the substitutive RTP sender of the reception quality of the 398 content reaches the mixer when the content is not sent to the RTP 399 receiver. These RTCP reports use the SSRC of the mixer. If the 400 substitutive content comes from local media file storage, the mixer 401 does not need to generate RTCP reports for the substitutive stream. 403 Based on above RTCP operating mechanism, the RTP sender whose content 404 is being passed to receiver will see the reception quality of its 405 stream as received by the mixer, and the reception quality of spliced 406 stream as received by the receiver. The RTP sender whose content is 407 not being passed to receiver will only see the reception quality of 408 its stream as received by the mixer. 410 The mixer must forward RTCP SDES and BYE packets from the receiver to 411 the sender, and may forward them in inverse direction as defined in 412 section 7.3 of [RFC3550]. 414 Once the mixer receives an RTP/AVPF [RFC4585] transport layer 415 feedback packet, it must handle it carefully as the feedback packet 416 may contain the information of the content that come from different 417 RTP senders. In this case the mixer needs to divide the feedback 418 packet into two separate feedback packets and process the information 419 in the feedback control information (FCI) in the two feedback 420 packets, just as the RTCP report process described above. 422 If the substitutive content comes from local media file storage 423 (i.e., the mixer can be regarded as the substitutive RTP sender), any 424 RTCP packets received from downstream relate to the substitutive 425 content must be terminated on the mixer without any further 426 processing. 428 4.3. Considerations for Handling Media Clipping at the RTP Layer 430 This section provides informative guideline about how media clipping 431 is shaped and how the mixer deal with the media clipping only at the 432 RTP layer. Dealing with the media clipping at the RTP layer just do 433 a good quality implementation, perfectly erasing the media clipping 434 needs more considerations in the higher layers, how to realize it is 435 outside of the scope of this memo. 437 If the time slot for substitutive content mismatches (is shorter or 438 longer than) the duration of the main content to be replaced, then 439 media clipping may occur at the splicing point and thus impact the 440 user's experience. 442 If the substitutive content has shorter duration from the main 443 content, then there will be a gap in the output RTP stream. The RTP 444 sequence number will be contiguous across this gap, but there will be 445 an unexpected jump in the RTP timestamp. This gap will cause the 446 receiver to have nothing to play. This is unavoidable, unless the 447 mixer adjusts the splice in or splice out point to compensate, 448 sending more of the main RTP stream in place of the shorter 449 substitutive stream, or unless the mixer can vary the length of the 450 substitutive content. It is the responsibility of the higher layer 451 protocols to ensure that the substitutive content is of the same 452 duration as the main content to be replaced. 454 If the insertion duration is longer than the reserved gap duration, 455 there will be an overlap between the substitutive RTP stream and the 456 main RTP stream at splicing out point. One straightforward approach 457 is that the mixer takes an ungraceful action, terminating the 458 splicing and switching back to main RTP stream even if this may cause 459 media stuttering on receiver. Alternatively, the mixer may transcode 460 the substitutive content to play at a faster rate than normal, to 461 adjust it to the length of the gap in the main content, and generate 462 a new RTP stream for the transcoded content. This is a complex 463 operation, and very specific to the content and media codec used. 465 4.4. Congestion Control Considerations 467 If the substitutive content has somewhat different characteristics 468 from the main content it replaces, or if the substitutive content is 469 encoded with a different codec or has different encoding bitrate, it 470 might overload the network and might cause network congestion on the 471 path between the mixer and the RTP receiver(s) that would not have 472 been caused by the main content. 474 To be robust to network congestion and packet loss, a mixer that is 475 performing splicing must continuously monitor the status of 476 downstream network by monitoring any of the following RTCP reports 477 that are used: 479 1. RTCP receiver reports indicate packet loss [RFC3550]. 481 2. RTCP NACKs for lost packet recovery [RFC4585]. 483 3. RTCP ECN Feedback information [I-D.ietf-avtcore-ecn-for-rtp]. 485 Once the mixer detects congestion on its downstream link, it will 486 treat these reports as follows: 488 1. If the mixer receives the RTCP receiver reports with packet loss 489 indication, it will forward the reports to the substitutive RTP 490 sender or the main RTP sender as described in section 4.2. 492 2. If mixer receives the RTCP NACK packets defined in [RFC4585] from 493 RTP receiver for packet loss recovery, it first identifies the 494 content category of lost packets to which the NACK corresponds. 495 Then, the mixer will generate new RTCP NACK for the lost packets 496 with its own SSRC, and make corresponding changes to their 497 sequence numbers to match original, pre-spliced, packets. If the 498 lost substitutive content comes from local media file storage, 499 the mixer acting as substitutive RTP sender will directly fetch 500 the lost substitutive content and retransmit it to RTP receiver. 501 The mixer may buffer the sent RTP packets and do the 502 retransmission. 504 It is somewhat complex that the lost packets requested in a 505 single RTCP NACK message not only contain the main content but 506 also the substitutive content. To address this, the mixer must 507 divide the RTCP NACK packet into two separate RTCP NACK packets: 508 one requests for the lost main content, and another requests for 509 the lost substitutive content. 511 3. If an ECN-aware mixer receives RTCP ECN feedbacks (RTCP ECN 512 feedback packets or RTCP XR summary reports) defined in 513 [I-D.ietf-avtcore-ecn-for-rtp] from the RTP receiver, it must 514 process them in a similar way to the RTP/AVPF feedback packet or 515 RTCP XR process described in section 4.2 of this memo. 517 These three methods require the mixer to run a congestion control 518 loop and bitrate adaptation between itself and RTP receiver. The 519 mixer can thin or transcode the main RTP stream or the substitutive 520 RTP stream, but such operations are very inefficient and difficult, 521 and bring undesirable delay. Fortunately in this memo, the mixer 522 acting as splicer can rewrite the RTCP packets sent from the RTP 523 receiver and forward them to the RTP sender, thus letting the RTP 524 sender knows that congestion is being experienced on the path between 525 the mixer and the RTP receiver. Then, the RTP sender applies its 526 congestion control algorithm and reduces the media bitrate to a value 527 that is in compliance with congestion control principles for the 528 slowest link. The congestion control algorithm may be a TCP-friendly 529 bitrate adaptation algorithm specified in [RFC5348], or a DCCP 530 congestion control algorithms defined in [RFC5762]. 532 If the substitutive content comes from local media file storage, the 533 mixer must directly reduce the bitrate as if it were the substitutive 534 RTP sender. 536 From above analysis, to reduce the risk of congestion and remain the 537 bandwidth consumption stable over time, the substitutive RTP stream 538 is recommended to be encoded at an appropriate bitrate to match that 539 of main RTP stream. If the substitutive RTP stream comes from the 540 substitutive RTP sender, this sender had better has some knowledge 541 about the media encoding bitrate of main content in advance. How it 542 knows that is out of scope in this draft. 544 4.5. Considerations for Implementing Undetectable Splicing 546 If it is desirable to prevent receivers from detecting that splicing 547 is occurring at the RTP layer, the mixer must not include a CSRC list 548 in outgoing RTP packets, and must not forward RTCP messages from the 549 main RTP sender or from the substitutive RTP sender. Due to the 550 absence of CSRC list in the output RTP stream, the RTP receiver only 551 initiates SDES, BYE and APP packets to the mixer without any 552 knowledge of the main RTP sender and the substitutive RTP sender. 554 CSRC list identifies the contributing sources, these SSRC identifiers 555 of contributing sources are kept globally unique for each RTP 556 session. The uniqueness of SSRC identifier is used to resolve 557 collisions and detecting RTP-level forwarding loops as defined in 558 section 8.2 of [RFC3550]. The absence of CSRC list in this case will 559 create a danger that loops involving those contributing sources could 560 not be detected. The loops could occur if either the mixer is 561 misconfigured to form a loop, or a second mixer/translator is added, 562 causing packets to loop back to upstream of the original mixer and 563 hence wasting the network bandwidth. So Non-RTP means must be used 564 to detect and resolve loops if the mixer does not add a CSRC list. 566 5. Implementation Considerations 568 When the mixer is used to handle RTP splicing, RTP receiver does not 569 need any RTP/RTCP extension for splicing. As a trade-off, additional 570 overhead could be induced on the mixer which uses its own sequence 571 number space and timing model. So the mixer will rewrite RTP 572 sequence number and timestamp whatever splicing is active or not, and 573 generate RTCP flows for both sides. In case the mixer serves 574 multiple main RTP streams simultaneously, this may lead to more 575 overhead on the mixer. 577 If undetectable splicing requirement is required, CSRC list is not 578 included in outgoing RTP packet, this brings a potential issue with 579 loop detection as briefly described in section 4.5. 581 6. Security Considerations 583 The splicing application is subject to the general security 584 considerations of the RTP specification [RFC3550]. 586 The mixer acting as splicer replaces some content with other content 587 in RTP packets, thus breaking any RTP level end-to-end security, such 588 as integrity protection and source authentication. Thus any RTP 589 level or outside security mechanism, such as IPsec or DTLS will use a 590 security association between the splicer and the receiver. When 591 using SRTP the splicer could be provisioned with the same security 592 association as the main RTP sender. Using a limitation in the SRTP 593 security services, the splicer can modify and re-protect the RTP 594 packets without enabling the receiver to detect if the data comes 595 from the original source or from the splicer. 597 Security goals to have source authentication all the way from the RTP 598 main sender to the receiver through the splicer is not possible with 599 splicing. The nature of this RTP service offered by a network 600 operator employing a content splicer is that the RTP layer security 601 relationship is between the receiver and the splicer, and between the 602 senders and the splicer, are not end-to-end. This appears to 603 invalidate the undetectability goal, but in the common case the 604 receiver will consider the splicer as the main media source. 606 Commonly no RTP level security mechanism is employed. Instead only 607 payload security mechanisms (e.g., ISMACryp [ISMACryp]) are used. If 608 any payload internal security mechanisms are used, only the RTP 609 sender and the RTP receiver can learn the security keying material 610 generated by such internal security mechanism, in which case, any 611 middlebox (e.g., splicer) between the RTP sender and the RTP receiver 612 can't get such keying material, and thus fail to perform splicing. 614 7. IANA Considerations 616 No IANA actions are required. 618 8. Acknowledgments 620 The following individuals have reviewed the earlier versions of this 621 specification and provided very valuable comments: Colin Perkins, 622 Magnus Westerlund, Roni Even, Tom Van Caenegem, Joerg Ott, David R 623 Oran, Cullen Jennings, Ali C Begen, Charles Eckel and Ning Zong. 625 9. 10. Appendix- Why Mixer Is Chosen 627 Translator and mixer both can realize splicing by changing a set of 628 RTP parameters. 630 Translator has no SSRC, hence it is transparent to RTP sender and 631 receiver. Therefore, RTP sender sees the full path to the receiver 632 when translator is passing its content. When translator insert the 633 substitutive content RTP sender could get a report on the path up to 634 translator itself. Additionally, if splicing does not occur yet, 635 translator does not need to rewrite RTP header, the overhead on 636 translator can be avoided. 638 If mixer is used to do splicing, it can also allow RTP sender to 639 learn the situation of its content on receiver or on mixer just like 640 translator does, which is specified in section 4.2. Compared to 641 translator, mixer's outstanding benefit is that it is pretty straight 642 forward to do with RTCP messages, for example, bit-rate adaptation to 643 handle varying network conditions. But translator needs more 644 considerations and its implementation is more complex. 646 From above analysis, both translator and mixer have their own 647 advantages: less overhead or less complexity on handling RTCP. 648 Through long and sophisticated discussion, the avtext WG members 649 prefer less complexity rather than less overhead and incline to mixer 650 to do splicing. 652 If one chooses mixer as splicer, the overhead on mixer must be taken 653 into account even if the splicing does not occur yet. 655 10. References 657 10.1. Normative References 659 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 660 Jacobson, "RTP: A Transport Protocol for Real-Time 661 Applications", STD 64, RFC 3550, July 2003. 663 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 664 "Extended RTP Profile for Real-time Transport Control 665 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 666 July 2006. 668 [I-D.ietf-avtcore-ecn-for-rtp] 669 Westerlund, M., "Explicit Congestion Notification (ECN) 670 for RTP over UDP", draft-ietf-avtcore-ecn-for-rtp-08 (work 671 in progress), May 2012. 673 10.2. Informative References 675 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 676 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 677 RFC 3711, March 2004. 679 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 680 Friendly Rate Control (TFRC): Protocol Specification", 681 RFC 5348, September 2008. 683 [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control 684 Protocol (DCCP)", RFC 5762, April 2010. 686 [SCTE30] Society of Cable Telecommunications Engineers (SCTE), 687 "Digital Program Insertion Splicing API", 2009. 689 [SCTE35] Society of Cable Telecommunications Engineers (SCTE), 690 "Digital Program Insertion Cueing Message for Cable", 691 2011. 693 [ISMACryp] 694 Internet Streaming Media Alliance (ISMA), "ISMA Encryption 695 and Authentication Specification 2.0", November 2007. 697 Author's Address 699 Jinwei Xia 700 Huawei 701 Software No.101 702 Nanjing, Yuhuatai District 210012 703 China 705 Phone: +86-025-86622310 706 Email: xiajinwei@huawei.com