idnits 2.17.1 draft-ietf-avtext-splicing-for-rtp-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 (February 20, 2012) is 4441 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-avtcore-ecn-for-rtp-06 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 February 20, 2012 5 Expires: August 23, 2012 7 Content Splicing for RTP Sessions 8 draft-ietf-avtext-splicing-for-rtp-07 10 Abstract 12 This memo outlines RTP splicing. Splicing is a process that replaces 13 the content of the main multimedia stream with other multimedia 14 content, and delivers the substitutive multimedia content to receiver 15 for a period of time. This memo provides some RTP splicing use 16 cases, then we enumerate a set of requirements and analyze whether an 17 existing RTP level middlebox can meet these requirements, at last we 18 provide concrete guidelines for how the chosen middlebox works to 19 handle RTP splicing. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 23, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. RTP Splicing Discussion and Requirements . . . . . . . . . . . 4 58 4. Recommended Solution for RTP Splicing . . . . . . . . . . . . 7 59 4.1. RTP Processing in RTP Mixer . . . . . . . . . . . . . . . 7 60 4.2. RTCP Processing in RTP Mixer . . . . . . . . . . . . . . . 9 61 4.3. Media Clipping Considerations . . . . . . . . . . . . . . 10 62 4.4. Congestion Control Considerations . . . . . . . . . . . . 11 63 4.5. Processing Splicing in User Invisibility Case . . . . . . 13 64 5. Implementation Considerations . . . . . . . . . . . . . . . . 13 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 68 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 9.1. draft-xia-avtext-splicing-for-rtp-01 . . . . . . . . . . . 14 70 9.2. draft-xia-avtext-splicing-for-rtp-00 . . . . . . . . . . . 14 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 This document outlines how splicing can be used for RTP sessions. 79 Splicing is a process that replaces the content of the main RTP 80 stream with other multimedia content, and delivers the substitutive 81 content to receiver for a period of time. The substitutive content 82 can be provided for example via another RTP stream or local media 83 file storage. 85 One representative use case for splicing is advertisements insertion, 86 which allows operators to replace the national advertising content 87 with its own regional advertising content prior to delivering the 88 regional advertising content to receiver. 90 Besides the advertisement insertion use case, there are other use 91 cases to which RTP splicing technology can apply. For example, 92 splicing a recorded video into a video conferencing session, and 93 implementing a playlist server that stitches pieces of video together 94 and so forth. 96 So far [SCTE30] and [SCTE35] have standardized MPEG2-TS splicing 97 running over cable. The introduction of multimedia splicing into 98 internet requires changes to transport layer, but to date there is no 99 guideline for how to handle content splicing for RTP sessions 100 [RFC3550]. 102 In this document, we first describe a set of requirements of RTP 103 splicing. Then we provide a method about how an intermediary node 104 can be used to process RTP splicing to meet these requirements from 105 the aspects of feasibility, implementation complexity and backward 106 compatibility. 108 2. Terminology 110 This document uses the following terminologies. 112 Current RTP Stream 114 The RTP stream that the RTP receiver is currently receiving. The 115 content of current RTP stream can be either main content or 116 substitutive content. 118 Main Content 120 The multimedia content that are conveyed in main RTP stream. Main 121 content will be replaced by the substitutive content during 122 splicing. 124 Main RTP Stream 126 The RTP stream that the Splicer is receiving. The content of main 127 RTP stream can be replaced by substitutive content for a period of 128 time. 130 Substitutive Content 132 The multimedia content that replaces the main content during 133 splicing. The substitutive content can for example be contained 134 in an RTP stream from a media sender or fetched from local media 135 file storage. 137 Substitutive RTP Stream 139 A RTP stream that may provide substitutive content. Substitutive 140 RTP stream and main RTP stream are two separate streams. If the 141 substitutive content is provided via substitutive RTP stream, the 142 substitutive RTP Stream must pass through Splicer before the 143 substitutive content is delivered to receiver. 145 Splicing In Point 147 A virtual point in the RTP stream, suitable for substitutive 148 content entry, that exists in the boundary of two independently 149 decodable frames. 151 Splicing Out Point 153 A virtual point in the RTP stream, suitable for substitutive 154 content exit, that exists in the boundary of two independently 155 decodable frames. 157 Splicer 159 An intermediary node that inserts substitutive content into main 160 RTP stream. Splicer sends substitutive content to RTP receiver 161 instead of main content during splicing. It is also responsible 162 for processing RTCP traffic between media source and RTP receiver. 164 3. RTP Splicing Discussion and Requirements 166 In this document, we assume an intermediary network element, which is 167 referred to as Splicer, to play the key role to handle RTP splicing. 168 A simplified RTP splicing diagram is depicted in Figure 1, in which 169 only one main content flow and one substitutive content flow are 170 given. 172 +---------------+ 173 | | Main Content +-----------+ 174 |Main RTP Sender|------------->| | Current Content 175 | | | Splicer |----------> 176 +---------------+ ---------->| | 177 | +-----------+ 178 | 179 | Substitutive Content 180 | 181 | 182 +-----------------------+ 183 |Substitutive RTP Sender| 184 | or | 185 | Local File Storage | 186 +-----------------------+ 188 Figure 1: RTP Splicing Architecture 190 When RTP splicing begins, Splicer stops delivering the main content, 191 instead delivering the substitutive content to RTP receiver for a 192 period of time, and then resumes the main content when splicing ends. 193 The methods how Splicer learns when to start and end the splicing is 194 out of scope for this document. The RTP splicing may happen more 195 than once in case that substitutive content will be dispersedly 196 inserted in multiple time slots during the lifetime of the main RTP 197 stream. 199 When realizing splicing technology on RTP layer, there are a set of 200 requirements that must be satisfied to at least some degree on 201 Splicer: 203 REQ-1: 205 Splicer must operate in either unicast or multicast session 206 environment. 208 REQ-2: 210 Splicer should not cause perceptible media clipping at the 211 splicing point and adverse impact on the quality of user 212 experience. 214 REQ-3: 216 Splicer must be backward compatible with RTP/RTCP protocols, and 217 its associated profiles and extensions to those protocols. For 218 example, Splicer must be robust to packet loss, network congestion 219 etc. 221 REQ-4: 223 Splicer must be trusted by media source and receiver, and has the 224 valid security context with media source and RTP receiver 225 respectively. 227 REQ-5: 229 Splicer should allow the media source to learn the performance of 230 the downstream receiver when its content is being passed to RTP 231 receiver. 233 In a number of deployment scenarios, especially advertisement 234 insertion, there may be one specific requirement. Given that it is 235 unacceptable for advertisers that their advertising content is not 236 delivered to user, this may require RTP splicing to be operated 237 within the following constraint: 239 REQ-6: 241 If Splicer intends to prevent RTP receiver from identifying and 242 filtering the substitutive content, it should eliminate the 243 visibility of splicing process on RTP level from RTP receiver 244 point of view. 246 However, substitutive content and main content are encoded by 247 different encoders and have different parameter sets. In such 248 case, a full media transcoding must be done on Splicer to ensure 249 the completely invisible impact on RTP receiver, but this may be 250 prohibitively expensive and complex. As a trade-off, it is 251 recommended to minimize the splicing visibility on RTP receiver, 252 i.e., maintaining RTP header parameters consistent but leaving the 253 RTP payload untranscoded. If one wants to realize complete 254 invisibility, the cost of transcoding must be taken into account. 256 Henceforth, we refer to the minimum and complete invisibility 257 requirement as User Invisibility Requirement. 259 To improve the versatility of existing implementations and better 260 interoperability, it is recommended to use existing tools in RTP/RTCP 261 protocol family to realize RTP splicing without any protocol 262 extension unless the existing tools are incompetent for splicing. 264 4. Recommended Solution for RTP Splicing 266 Given that Splicer is an intermediary node exists between the main 267 media source and the RTP receiver and splicing is not a very 268 complicated processing, there are some chance that any existing RTP- 269 level middlebox may has the incidental capability to meet the 270 requirements described in previous section. 272 Since Splicer needs to select substitutive content or main content as 273 the input content at one point of time, an RTP mixer seems to have 274 such capability to do this under its own SSRC. Moreover, mixer may 275 include the CSRC list in outgoing packets to indicate the source(s) 276 of content in some use cases like conferencing, this facilitates the 277 system debugging and loop detection. From this point of view, an RTP 278 mixer may have some chance to be Splicer. In next four subsections 279 (from subsection 4.1 to subsection 4.4), we start analyzing how an 280 RTP mixer handles RTP splicing and how it satisfies the general 281 requirements listed in section 3. 283 In subsection 4.5, we specially consider the special requirement 6 284 (i.e., User Invisibility Requirement) since it needs to mask any RTP 285 splicing clue on receiver (e.g, CSRC list must not be included in 286 outgoing packets to prevent receiver from identifying the difference 287 between main RTP stream and substitutive RTP stream) when mixer is 288 used. 290 4.1. RTP Processing in RTP Mixer 292 Once mixer has learnt when to do splicing, it must get ready for the 293 coming splicing in advance, e.g., fetches the substitutive content 294 either from local media file storage or via substitutive RTP stream 295 earlier than splicing in point. If the substitutive content comes 296 from local media file storage, mixer should leave the CSRC list blank 297 in the output stream. 299 Even if splicing does not begin, mixer still needs to receive the 300 main RTP stream, and generate a media stream as defined in RFC3550. 301 Using main content, mixer generates the current media stream with its 302 own SSRC, sequence number space and timing model. Moreover, mixer 303 may insert the SSRC of main RTP stream into CSRC list in the current 304 media stream. 306 When splicing begins, mixer chooses the substitutive RTP stream as 307 input stream at splicing in point, and extracts the payload data 308 (i.e., substitutive content). After that, mixer encapsulates 309 substitutive content instead of main content as the payload of the 310 current media stream, and then outputs the current media stream to 311 receiver. Moreover, mixer may insert the SSRC of substitutive RTP 312 stream into CSRC list in the current media stream. 314 When splicing ends, mixer retrieves the main RTP stream as input 315 stream at splicing out point, and extracts the payload data (i.e., 316 main content). After that, mixer encapsulates main content instead 317 of substitutive content as the payload of the current media stream, 318 and then outputs the current media stream to receiver. Moreover, 319 mixer may insert the SSRC of main RTP stream into CSRC list in the 320 current media stream. 322 The whole RTP splicing procedure is perhaps best explained by a 323 pseudo code example: 325 if (splicing begins) { 326 the substitutive RTP stream is terminated on mixer and 327 substitutive content is encapsulated by mixer with its own SSRC 328 identifier; 330 the sequence numbers of the current RTP packets which contain 331 substitutive content are allocated by mixer and maintain 332 consistent with the sequence numbers of previous current RTP 333 packets, until the splicing end; 335 the timestamp of the current RTP packet increments linearly; 337 the CSRC list of the current RTP packet may include SSRC of 338 substitutive RTP stream; 339 } 341 else { 342 the main RTP stream is terminated on mixer and main content is 343 encapsulated by mixer with its own SSRC identifier; 345 the sequence numbers of the current RTP packets which contain main 346 content are allocated by mixer and maintain consistent with the 347 sequence numbers of previous current RTP packets, until the 348 splicing begins; 350 the timestamp of the current RTP packets increments linearly; 352 the CSRC list of the current RTP may include SSRC of main RTP 353 stream; 354 } 355 Splicing may occur more than one time during the lifetime of main RTP 356 stream, this means mixer needs to output main content and 357 substitutive content in turn with its own SSRC identifier. From 358 receiver point of view, the only source of the current stream is 359 mixer wherever the content comes from. 361 Note that, the substitutive content should be outputted in the range 362 of splicing duration. Any gap or overlap between main RTP stream and 363 substitutive RTP stream may induce media clipping at splicing point. 364 More details about preventing media clipping are introduced in 365 section 4.3. 367 4.2. RTCP Processing in RTP Mixer 369 By monitoring available bandwidth and buffer levels and by computing 370 network metrics such as packet loss, network jitter, and delay, RTP 371 receiver can learn the situation on it and can communicate this 372 information to media source via RTCP reception reports. 374 According to the description in section 7.3 of [RFC3550], mixer 375 divides RTCP flow between media source and receiver into two separate 376 RTCP loops, media source probably has no idea about the situation on 377 receiver. Hence, mixer can use some mechanisms, allowing media 378 source to at least some degree to have some knowledge of the 379 situation on receiver when its content is being passed to receiver. 381 Because splicing is a processing that mixer selects one media stream 382 from multiple streams but neither mixing nor transcoding them, upon 383 receiving an RTCP receiver report from downstream receiver, mixer can 384 forward it to original media source with its SSRC identifier intact 385 (i.e., the SSRC of downstream receiver). Given that the number of 386 output RTP packets containing substitutive content is equal to the 387 number of input substitutive RTP packets (from substitutive RTP 388 stream) during splicing. In the same manner, the number of output 389 RTP packets containing main content is equal to the number of input 390 main RTP packets (from main RTP stream) during non-splicing, so mixer 391 does not need to modify loss packet fields in Receiver Report Blocks 392 unless the reporting intervals spans the splicing point. But mixer 393 needs to change the SSRC field in report block to the SSRC identifier 394 of original media source and rewrite the extended highest sequence 395 number field to the corresponding original extended highest sequence 396 number before forwarding the RTCP receiver report to original media 397 source. 399 When a RTCP receiver report spans the splicing point, it reflects the 400 characteristics of the combination of main RTP packets and 401 substitutive RTP packets, in which case, mixer needs to divide the 402 receiver report into two separated receiver reports and send them to 403 their original media sources respectively. For each separated 404 receiver report, mixer also needs to make the corresponding changes 405 to the packet loss fields in report block besides the SSRC field and 406 the extended highest sequence number field. 408 The mixer can also inform the media source of quality with which the 409 content reaches the mixer. This is done by the mixer generating RTCP 410 reports for the RTP stream, which it sends upstream towards the media 411 source. These RTCP reports use the SSRC of the mixer. 413 Based on above RTCP operating mechanism, the media source whose 414 content is being passed to receiver, will see the reception quality 415 of its stream received on mixer, and the reception quality of spliced 416 stream received on receiver. The media source whose content is not 417 being passed to receiver, will only see the reception quality of its 418 stream received on mixer. 420 If the substitutive content comes from local media file storage ( 421 i.e., mixer can be regarded as the substitutive media source), the 422 reception reports received from downstream relate to the substitutive 423 content should be terminated on mixer without any further processing. 425 4.3. Media Clipping Considerations 427 This section provides informative guideline about how media clipping 428 may shape and how mixer deal with the media clipping. 430 If the time slot for substitutive RTP stream mismatches (shorter or 431 longer than) the duration of the reserved main RTP stream for 432 replacing, the media clipping may occur at the splicing point which 433 usually is the joint between two independently decodable frames. 435 At the splicing in point, mixer can fill up receiver's buffer with 436 substitutive content several seconds earlier than the presentation 437 time of substitutive content so that smooth playback can be achieved 438 without pauses or stuttering on RTP receiver. 440 Compared to buffering method used at splicing in point, things become 441 somewhat complex at splicing out point. The case that insertion 442 duration is shorter than the reserved gap time may cause a little 443 playback latency of main RTP stream on RTP receiver, but not 444 adversely impact the quality of user experience. One alternative 445 approach is that mixer may pad some blank content (e.g., all black 446 sequence) to fill up the gap. Another alternative approach is that 447 main media source may send filler content (e.g., static channel 448 identifier) during splicing, the mixer can switch back to early when 449 it runs out of substitutive content. 451 However, in case that insertion duration is longer than the reserved 452 gap duration, there exists an overlap of the substitutive RTP stream 453 and the main RTP stream at splicing out point. One straightforward 454 approach is that mixer takes a ungracefule action, terminating the 455 splicing and switching back to main RTP stream even if this may cause 456 media stuttering on receiver. There is an alternative approach which 457 may be mild but somewhat complex, mixer buffers main content for a 458 while until substitutive content is finished, and then transmits 459 buffered main content to receiver at an acceleated bitrate (as 460 compared to the nominal bitrate of main RTP stream) until its buffer 461 level returns to normal. At this point in time, mixer transmits main 462 content to receiver at an nominal bitrate of main RTP stream. Note 463 that mixer should take into account a variety of parameters, such as 464 available bandwidth between mixer and receiver, mixer buffer level 465 and receiver buffer level, to count the accelerated bitrate value. 467 Another reason to cause media clipping is synchronization delay at 468 splicing point if RTP receiver needs to synchronize multiple current 469 streams for playback. How to address this issue is discussed in 470 detail in [RFC6051], which provides three feasible approaches to 471 reduce synchronization delay. 473 4.4. Congestion Control Considerations 475 Provided that the substitutive content has somewhat different 476 characteristics to the main content it replaces (e.g., the more 477 dynamic content, the higher bandwidth occupation), or substitutive 478 content may be encoded with different codec and has different 479 encoding bitrate, some challenge raise to network capacity and 480 receiver buffer size. A more dynamic content or a higher encoding 481 bitrate stream might overload the network and possibly exceed the 482 receiver's media consumption rate, which might flood receiver's 483 buffer and eventually result in a buffer overflow. Either network 484 overload or buffer overflow would induce network congestion and 485 congestion-caused packet loss. 487 To be robust to network congestion and packet loss, mixer must 488 continuously monitor the network situation by means of a variety of 489 manners: 491 1. RTCP receiver reports indicate packet loss [RFC3550]. 493 2. RTCP NACKs for lost packet recovery [RFC4585]. 495 3. RTCP ECN Feedback information [I-D.ietf-avtcore-ecn-for-rtp]. 497 Upon detection of above three types of RTCP reports during splicing, 498 mixer will treat them with three different manners as following: 500 1. If mixer receives the RTCP receiver reports with packet loss 501 indication, it will process them as the description given in 502 section 7.3 of [RFC3550]. 504 2. If mixer receives the RTCP NACK packets defined in [RFC4585] from 505 RTP receiver for packet loss recovery, it first identifies the 506 content category of lost packets to which the NACK corresponds. 507 Then, mixer will generate new RTCP NACK for the lost packets with 508 its own SSRC, and make corresponding changes to their sequence 509 numbers to match original, pre-spliced, packets. If the lost 510 substitutive content comes from local media file storage, mixer 511 acting as substitutive media source will directly fetch the lost 512 substitutive content and retransmit it to RTP receiver. 514 It is somewhat complex that the lost packets requested in a 515 single RTCP NACK message not only contain the main content but 516 also the substitutive content. To address this, mixer must 517 divide the RTCP NACK packet into two separate RTCP NACK packets: 518 one requests for the lost main content, and another requests for 519 the lost substitutive content. 521 3. In [I-D.ietf-avtcore-ecn-for-rtp], two RTCP extensions are 522 defined for ECN feedback: RTP/AVPF transport layer ECN feedback 523 packet for urgent ECN information, and RTCP XR ECN summary report 524 block for regular reporting of the ECN marking information. 526 If an ECN-aware mixer receives any RTCP ECN feedback (i.e., RTCP 527 ECN feedback packets or RTCP XR summary reports) from RTP 528 receiver, it must operates as description given in section 8.4 of 529 [I-D.ietf-avtcore-ecn-for-rtp], terminating the RTCP ECN feedback 530 packets from downstream receivers, and driving congestion control 531 loop and bitrate adaptation between itself and downstream 532 receiver as if it were the media source. In addition, an ECN- 533 aware RTP mixer must generate RTCP ECN feedback relating to the 534 input RTP streams it terminates, and driving congestion control 535 loop and bitrate adaptation between itself and upstream sender as 536 if it were the RTP sender. 538 Once mixer learns that congestion is being experienced on its 539 downstream link by means of above three detection mechanisms, it 540 should adapt the bitrate of output stream in response to network 541 congestion. The bitrate adaptation may be determined by a TCP- 542 friendly bitrate adaptation algorithm specified in [RFC5348], or by a 543 DCCP congestion control algorithms defined in [RFC5762]. 545 In practice, during splicing, the real reason to cause congestion 546 usually is the different characteristic of substitutive RTP stream 547 (more dynamic content or higher encoding bitrate) with main RTP 548 stream, and that stream transcoding or thinning on mixer is very 549 inefficient and difficult operation. Therefore, a means that enables 550 substitutive media source to limit the media bitrate it is currently 551 generating even in the absence of congestion on the path between 552 itself and mixer is desirable. The TMMBR message defined in 553 [RFC5104] provides an effective method. When mixer detects 554 congestion on its downstream link during splicing, it uses TMMBR to 555 request substitutive media source to reduce the media bitrate to a 556 value that is in compliance with congestion control principles for 557 the slowest link. Upon reception of TMMBR, substitutive media source 558 applies its congestion control algorithm and responds Temporary 559 Maximum Media Stream Bit Rate Notification (TMMBN) to mixer. 561 If the substitutive content comes from local media file storage, 562 mixer must directly reduce the substitutive media bitrate as the 563 substitutive media source when it detects any congestion on its 564 downstream link during splicing. 566 From above analysis, to reduce the risk of congestion and remain the 567 bandwidth consumption stable over time, the substitutive RTP stream 568 is recommended to be encoded at an appropriate bitrate to match that 569 of main RTP stream. If the substitutive RTP stream comes from 570 substitutive media source, the source had better has some knowledge 571 about the media encoding bitrate of main content in advance. How it 572 knows that is out of scope in this draft. 574 4.5. Processing Splicing in User Invisibility Case 576 Mixer will not includes CRSC list in outgoing RTP packets to prevent 577 user from detecting the splicing occurred on RTP level. Due to the 578 absence of CRSC list in current RTP stream, RTP receiver only 579 initiates SDES, BYE and APP packets to mixer without any knowledge of 580 main media source and substitutive media source. This creates a 581 danger that loops involving those sources could not be detected. 583 5. Implementation Considerations 585 When mixer is used to handle RTP splicing, RTP receiver does not need 586 any RTP/RTCP extension for splicing. As a trade-off, additional 587 overhead could be induced on mixer which uses its own sequence number 588 space and timing model. So mixer will rewrite RTP sequence number 589 and timestamp whatever splicing is active or not, and generate RTCP 590 flows for both sides. In case mixer serves multiple main RTP streams 591 simultaneously, this may lead to more overhead on mixer. 593 In addition, there is a potential issue with loop detection, which 594 would be problematic if User Invisibility Requirement is required. 596 6. Security Considerations 598 If any payload internal security mechanisms (e.g., ISMACryp 599 [ISMACryp]) are used, only media source and RTP receiver can learn 600 the security keying material generated by such internal security 601 mechanism, any middlebox (e.g., mixer) between media source and RTP 602 receiver can't get such keying material. Only when regular transport 603 security mechanisms (e.g., SRTP, IPSec, etc) are used, mixer will 604 process the packets passing through it. 606 The security considerations of the RTP specification [RFC3550], the 607 Extended RTP profile for RTCP-Based Feedback [RFC4585], and the 608 Secure Real-time Transport Protocol [RFC3711] apply. Mixer must be 609 trusted by main media source and insertion media source, and must be 610 included in the security context. 612 7. IANA Considerations 614 No IANA actions are required. 616 8. Acknowledgments 618 The following individuals have reviewed the earlier versions of this 619 specification and provided very valuable comments: Colin Perkins, 620 Magnus Westerlund, Roni Even, Tom Van Caenegem, Joerg Ott, David R 621 Oran, Cullen Jennings, Ali C Begen, Charles Eckel and Ning Zong. 623 9. Change Log 625 9.1. draft-xia-avtext-splicing-for-rtp-01 627 The following are the major changes compared to previous version 00: 629 o Use mixer to handle both user visible and invisible splicing. 631 o Add one subsection to describe media clipping considerations. 633 o Add one subsection to describe congestion control considerations. 635 9.2. draft-xia-avtext-splicing-for-rtp-00 637 The following are the major changes compared to previous AVT I-D 638 version 00: 640 o Change primary RTP stream to main RTP stream, add current RTP 641 stream as the streaming received by RTP receiver. 643 o Eliminate the ambiguity of inserted content with substitutive 644 content which replaces the main content rather than pause it. 646 o Clarify the signaling requirements. 648 o Delete the description on Mixer and MCU in section 4, mainly focus 649 on the direction whether a Translator can act as a Splicer. 651 o Add section 5 to describe the exact guidance on how an RTP 652 Translator is used to handle splicing. 654 o Modify the security considerations section and add acknowledges 655 section. 657 10. References 659 10.1. Normative References 661 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 662 Jacobson, "RTP: A Transport Protocol for Real-Time 663 Applications", STD 64, RFC 3550, July 2003. 665 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 666 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 667 RFC 3711, March 2004. 669 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 670 "Extended RTP Profile for Real-time Transport Control 671 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 672 July 2006. 674 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 675 "Codec Control Messages in the RTP Audio-Visual Profile 676 with Feedback (AVPF)", RFC 5104, February 2008. 678 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 679 Flows", RFC 6051, November 2010. 681 [I-D.ietf-avtcore-ecn-for-rtp] 682 Westerlund, M., "Explicit Congestion Notification (ECN) 683 for RTP over UDP", draft-ietf-avtcore-ecn-for-rtp-06 (work 684 in progress), February 2012. 686 10.2. Informative References 688 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 689 Friendly Rate Control (TFRC): Protocol Specification", 690 RFC 5348, September 2008. 692 [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control 693 Protocol (DCCP)", RFC 5762, April 2010. 695 [SCTE30] Society of Cable Telecommunications Engineers (SCTE), 696 "Digital Program Insertion Splicing API", 2001. 698 [SCTE35] Society of Cable Telecommunications Engineers (SCTE), 699 "Digital Program Insertion Cueing Message for Cable", 700 2004. 702 [ISMACryp] 703 Internet Streaming Media Alliance (ISMA), "ISMA Encryption 704 and Authentication Specification 2.0", November 2007. 706 Author's Address 708 Jinwei Xia 709 Huawei 710 Software No.101 711 Nanjing, Yuhuatai District 210012 712 China 714 Phone: +86-025-86622310 715 Email: xiajinwei@huawei.com