idnits 2.17.1 draft-ietf-avtext-splicing-for-rtp-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 20, 2011) is 4572 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2250' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'RFC3551' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'RFC5117' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'RFC5760' is defined on line 690, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5117 (Obsoleted by RFC 7667) == Outdated reference: A later version (-08) exists of draft-ietf-avtcore-ecn-for-rtp-02 Summary: 1 error (**), 0 flaws (~~), 7 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 20, 2011 5 Expires: April 22, 2012 7 Content Splicing for RTP Sessions 8 draft-ietf-avtext-splicing-for-rtp-01 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 to IETF 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 April 22, 2012. 38 Copyright Notice 40 Copyright (c) 2011 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 . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 13 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 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 Current RTP Stream 116 The RTP stream that the RTP receiver is currently receiving. The 117 content of current RTP stream can be either main content or 118 substitutive content. 120 Main Content 122 The multimedia content that are conveyed in main RTP stream. Main 123 content will be replaced by the substitutive content during 124 splicing. 126 Main RTP Stream 128 The RTP stream that the Splicer is receiving. The content of main 129 RTP stream can be replaced by substitutive content for a period of 130 time. 132 Substitutive Content 134 The multimedia content that replaces the main content during 135 splicing. The substitutive content can for example be contained 136 in an RTP stream from a media sender or fetched from local media 137 file storage. 139 Substitutive RTP Stream 141 A RTP stream that may provide substitutive content. Substitutive 142 RTP stream and main RTP stream are two separate streams. If the 143 substitutive content is provided via substitutive RTP stream, the 144 substitutive RTP Stream must pass through Splicer before the 145 substitutive content is delivered to receiver. 147 Splicing In Point 149 A virtual point in the RTP stream, suitable for substitutive 150 content entry, that exists in the boundary of two independently 151 decodable frames. 153 Splicing Out Point 155 A virtual point in the RTP stream, suitable for substitutive 156 content exist, that exists in the boundary of two independently 157 decodable frames. 159 Splicer 161 An intermediary node that inserts substitutive content into main 162 RTP stream. Splicer sends substitutive content to RTP receiver 163 instead of main content during splicing. It is also responsible 164 for processing RTCP traffic between media source and RTP receiver. 166 3. RTP Splicing Discussion and Requirements 168 In this document, we assume an intermediary network element, which is 169 referred to as Splicer, to play the key role to handle RTP splicing. 170 A simplified RTP splicing diagram is depicted in Figure 1, in which 171 only one main content flow and one substitutive content flow are 172 given. 174 +---------------+ 175 | | Main Content +-----------+ 176 |Main RTP Sender|------------->| | Current Content 177 | | | Splicer |----------> 178 +---------------+ ---------->| | 179 | +-----------+ 180 | 181 | Substitutive Content 182 | 183 | 184 +-----------------------+ 185 |Substitutive RTP Sender| 186 | or | 187 | Local File Storage | 188 +-----------------------+ 190 Figure 1: RTP Splicing Architecture 192 When RTP splicing begins, Splicer stops delivering the main content, 193 instead delivering the substitutive content to RTP receiver for a 194 period of time, and then resumes the main content when splicing ends. 195 The methods how Splicer learns when to start and end the splicing is 196 out of scope for this document. The RTP splicing may happen more 197 than once in case that substitutive content will be dispersedly 198 inserted in multiple time slots during the lifetime of the main RTP 199 stream. 201 When realizing splicing technology on RTP layer, there are a set of 202 requirements that must be satisfied to at least some degree on 203 Splicer: 205 REQ-1: 207 Splicer MUST operate in either unicast or multicast session 208 environment. 210 REQ-2: 212 Splicer SHOULD NOT cause perceptible media clipping at the 213 splicing point and adverse impact on the quality of user 214 experience. 216 REQ-3: 218 Splicer MUST be backward compatible with RTP/RTCP protocols, and 219 its associated profiles and extensions to those protocols. For 220 example, Splicer MUST be robust to packet loss, network congestion 221 etc. 223 REQ-4: 225 Splicer MUST be trusted by media source and receiver, and has the 226 valid security context with media source and RTP receiver 227 respectively. 229 REQ-5: 231 Splicer SHOULD allow the media source to learn the performance of 232 the downstream receiver when its content is being passed to RTP 233 receiver. 235 In a number of deployment scenarios, especially advertisement 236 insertion, there may be one specific requirement. Given that it is 237 unacceptable for advertisers that their advertising content is not 238 delivered to user, this may require RTP splicing to be operated 239 within the following constraint: 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 275 includes the CSRC list in outgoing packets to indicate the source(s) 276 of content, this facilitates the system debugging. From this point 277 of view, an RTP mixer may have some chance to be Splicer. In next 278 four subsections (from subsection 4.1 to subsection 4.4), we start 279 analyzing how an RTP mixer handles RTP splicing and how it satisfies 280 the general requirements listed in section 3. 282 In subsection 4.5, we specially consider the special requirement 6 283 (i.e., User Invisibility Requirement) since it needs to mask any RTP 284 splicing clue on user (e.g, CSRC list must not be included in 285 outgoing packets to prevent user from identifying the difference 286 between main RTP stream and substitutive RTP stream) when mixer is 287 used. 289 4.1. RTP Processing in RTP Mixer 291 Once mixer has learnt when to do splicing, it must get ready for the 292 coming splicing in advance, e.g., fetches the substitutive content 293 either from local media file storage or via substitutive RTP stream 294 earlier than splicing in point. If the substitutive content comes 295 from local media file storage, mixer can construct the substitutive 296 RTP stream using its own SSRC and leave the CSRC list blank in the 297 output stream. 299 When the main RTP stream begins, mixer terminates the main RTP 300 stream. Using the main RTP packets, mixer generates the current 301 media stream with its own SSRC, sequence number space and timing 302 model. Moreover, mixer inserts the SSRC of main RTP stream into CSRC 303 list in the current media stream. 305 When splicing begins, mixer chooses the substitutive RTP stream as 306 input stream at splicing in point, extracts the payload data (i.e., 307 substitutive content), encodes substitutive content and outputs it 308 instead of main content in the current media stream. Moreover, mixer 309 inserts the SSRC of substitutive RTP stream into CSRC list in the 310 current media stream. 312 When splicing ends, mixer retrieves the main RTP stream as input 313 stream at splicing out point, extracts the payload data (i.e., main 314 content), encodes main content and outputs it instead of substitutive 315 content in the current media stream. Moreover, mixer inserts the 316 SSRC of main RTP stream into CSRC list in the current media stream. 318 The whole RTP splicing procedure is perhaps best explained by a 319 pseudo code example: 321 if (main RTP stream begins) { 322 the main RTP stream is terminated on mixer and main content is 323 encoded by mixer with its own SSRC identifier; 325 the sequence numbers of the current RTP packets which contain main 326 content are allocated by mixer, until the splicing begins; 328 the timestamp of the current RTP packet increments linearly; 330 the CSRC list of the current RTP packet indicates SSRC of main RTP 331 stream; 332 } 334 else if (splicing begins) { 335 the substitutive RTP stream is terminated on mixer and 336 substitutive content is encoded by mixer with its own SSRC 337 identifier; 339 the sequence numbers of the current RTP packets which contain 340 substitutive content are allocated by mixer and maintain 341 consistent with the sequence numbers of previous current RTP 342 packets, until the splicing end; 344 the timestamp of the current RTP packet increments linearly; 346 the CSRC list of the current RTP packet indicates SSRC of 347 substitutive RTP stream; 348 } 349 else if (splicing ends) { 350 the main RTP stream is terminated on mixer and main content is 351 encoded by mixer with its own SSRC identifier; 353 the sequence numbers of the current RTP packets which contain main 354 content are allocated by mixer and maintain consistent with the 355 sequence numbers of previous current RTP packets, until the next 356 splicing begins; 358 the timestamp of the current RTP packets increments linearly; 360 the CSRC list the current RTP indicates SSRC of main RTP stream; 361 } 363 Splicing may occur more than one time during the lifetime of main RTP 364 stream, this means mixer needs to output main content and 365 substitutive content in turn with its own SSRC identifier. From user 366 point of view, the only source of the current stream is mixer 367 wherever the content comes from. 369 Note that, the substitutive content should be outputted in the range 370 of splicing duration. Any gap or overlap between main RTP stream and 371 substitutive RTP stream may induce media clipping at splicing point. 372 More details about preventing media clipping are introduced in 373 section 4.3. 375 4.2. RTCP Processing in RTP Mixer 377 By monitoring available bandwidth and buffer levels and by computing 378 network metrics such as packet loss, network jitter, and delay, RTP 379 receiver can learn the situation on it and can communicate this 380 information to media source via RTCP reception reports. 382 According to the description in section 7.3 of [RFC3550], mixer 383 divides RTCP flow between media source and receiver into two separate 384 RTCP loops, media source probably has no idea about the situation on 385 receiver. Hence, mixer may use some mechanisms, allowing media 386 source to at least some degree to have some knowledge of the 387 situation on receiver when its content is being passed to receiver. 389 Because splicing is a processing that mixer selects one media stream 390 from multiple streams rather than mixing them, the number of output 391 RTP packets containing substitutive content is equal to the number of 392 input substitutive RTP packets (from substitutive RTP stream) during 393 splicing, the mixer does not need to modify loss packet fields in 394 receiver report blocks unless the reporting intervals spans the 395 splicing point. But mixer needs to change the SSRC field in report 396 block to the SSRC identifier of original media source and rewrite the 397 extended highest sequence number field to the corresponding original 398 extended highest sequence number before forwarding the RTCP reception 399 reports to original media source. 401 When a RTCP receiver report spans the splicing point, it reflects the 402 characteristics of the combination of main RTP packets and 403 substitutive RTP packets, in which case, mixer needs to divide the 404 receiver report into two separated receiver reports and send them to 405 their original media sources respectively. For each separated 406 receiver report, mixer also needs to make the corresponding changes 407 to the packet loss fields in report block besides the SSRC field and 408 the extended highest sequence number field. 410 Based on above RTCP operating mechanism, the media source will see 411 the reception quality of its stream received by mixer, and the 412 reception quality of spliced stream received by RTP receiver. 414 For the media source whose content is terminated on mixer and is not 415 being passed to receiver, mixer must act as a receiver and send 416 reception reports to the media source. 418 4.3. Media Clipping Considerations 420 This section provides informative guideline about how media clipping 421 may shape and how mixer deal with the media clipping. 423 If the time slot for substitutive RTP stream mismatches (shorter or 424 longer than) the duration of the reserved main RTP stream for 425 replacing, the media clipping may occur at the splicing point which 426 usually is the joint between two independently decodable frames. 428 At the splicing in point, mixer can fill the substitutive content up 429 receiver's buffer with several seconds earlier than the presentation 430 time of substitutive content so that smooth playback can be achieved 431 without pauses or stuttering on RTP receiver. 433 Compared to buffering method used at splicing in point, things become 434 somewhat complex at splicing out point. The case that insertion 435 duration is shorter than the reserved gap time may cause a little 436 playback latency of main RTP stream on RTP receiver, but not 437 adversely impact the quality of user experience. However, in case 438 that insertion duration is longer than the reserved gap duration, 439 there exists an overlap of the substitutive RTP stream and the main 440 RTP stream at splicing out point, which may cause synchronization 441 problem and result in a perceptible media clipping. 443 To guard against a media clipping at splicing out point, main RTP 444 source may reserve a bit extra playback delay (e.g., 500 445 milliseconds) to send out the first main RTP packet after splicing 446 ends. Note that the delay should not be too long to smoothly 447 playback the coming main RTP stream. But if the splicing is still 448 unfinished when the first main RTP packet has reached, mixer must 449 terminate the splicing and switch back to main RTP stream even if 450 this may cause media stuttering on receiver. 452 Another reason to cause media clipping is synchronization delay at 453 splicing point if RTP receiver needs to synchronize multiple current 454 streams for playback. How to address this issue is discussed in 455 detail in [RFC6051], which provides three feasible approaches to 456 reduce synchronization delay. 458 4.4. Congestion Control Considerations 460 Provided that the substitutive content has somewhat different 461 characteristics to the main content it replaces (e.g., the more 462 dynamic content, the higher bandwidth occupation), or substitutive 463 content may be encoded with different codec and has different 464 encoding bitrate, some challenge raise to network capacity and 465 receiver buffer size. A more dynamic content or a higher encoding 466 bitrate stream might overload the network and possibly exceed the 467 receiver's media consumption rate, which might flood receiver's 468 buffer and eventually result in a buffer overflow. Either network 469 overload or buffer overflow would induce network congestion and 470 congestion-caused packet loss. 472 To be robust to network congestion and packet loss, mixer must 473 continuously monitor the network situation by means of a variety of 474 manners: 476 1. RTCP receiver reports indicate packet loss [RFC3550]. 478 2. RTCP NACKs for lost packet recovery [RFC4585]. 480 3. RTCP ECN Feedback information [I-D.ietf-avtcore-ecn-for-rtp]. 482 Upon detection of above three types of RTCP reports during splicing, 483 mixer will treat them with three different manners as following: 485 1. If mixer receives the RTCP receiver reports with packet loss 486 indication, it will process them as the description given in 487 section 7.3 of [RFC3550]. 489 2. If mixer receives the RTCP NACK packets defined in [RFC4585] from 490 RTP receiver for packet loss recovery, it first identifies the 491 content category of lost packets to which the NACK corresponds. 492 Then, mixer will generate new RTCP NACK for the lost packets with 493 its own SSRC, and make corresponding changes to their sequence 494 numbers to match original, pre-spliced, packets. If the lost 495 substitutive content comes from local media file storage, mixer 496 acting as substitutive media source will directly fetch the lost 497 substitutive content and retransmit it to RTP receiver. 499 It is somewhat complex that the lost packets requested in a 500 single RTCP NACK message not only contain the main content but 501 also the substitutive content. To address this, mixer must 502 divide the RTCP NACK packet into two separate RTCP NACK packets: 503 one requests for the lost main content, and another requests for 504 the lost substitutive content. 506 3. In [I-D.ietf-avtcore-ecn-for-rtp], two RTCP extensions are 507 defined for ECN feedback: RTP/AVPF transport layer ECN feedback 508 packet for urgent ECN information, and RTCP XR ECN summary report 509 block for regular reporting of the ECN marking information. 511 If an ECN-aware mixer receives any RTCP ECN feedback (i.e., RTCP 512 ECN feedback packets or RTCP XR summary reports) from RTP 513 receiver, it must operates as description given in section 8.4 of 514 [I-D.ietf-avtcore-ecn-for-rtp], terminating the RTCP ECN feedback 515 packets from downstream receivers, and driving congestion control 516 loop and bitrate adaptation between itself and downstream 517 receiver as if it were the media source. In addition, an ECN- 518 aware RTP mixer must generate RTCP ECN feedback relating to the 519 input RTP streams it terminates, and driving congestion control 520 loop and bitrate adaptation between itself and upstream sender as 521 if it were the RTP sender. 523 Once mixer learns that congestion is being experienced on its 524 downstream link by means of above three detection mechanisms, it 525 should adapt the bitrate of output stream in response to network 526 congestion. The bitrate adaptation may be determined by a TCP- 527 friendly bitrate adaptation algorithm specified in [RFC5348], or by a 528 DCCP congestion control algorithms defined in [RFC5762]. 530 In practice, during splicing, the real reason to cause congestion 531 usually is the different characteristic of substitutive RTP stream 532 (more dynamic content or higher encoding bitrate) with main RTP 533 stream, and that stream transcoding or thinning on mixer is very 534 inefficient and difficult operation. Therefore, a means that enables 535 substitutive media source to limit the media bitrate it is currently 536 generating even in the absence of congestion on the path between 537 itself and mixer is desirable. The TMMBR message defined in 538 [RFC5104] provides an effective method. When mixer detects 539 congestion on its downstream link during splicing, it uses TMMBR to 540 request substitutive media source to reduce the media bitrate to a 541 value that is in compliance with congestion control principles for 542 the slowest link. Upon reception of TMMBR, substitutive media source 543 applies its congestion control algorithm and responds Temporary 544 Maximum Media Stream Bit Rate Notification (TMMBN) to mixer. 546 From above analysis, to reduce the risk of congestion and remain the 547 bandwidth consumption stable over time, the substitutive RTP stream 548 is RECOMMENDED to be encoded at an appropriate bitrate to match that 549 of main RTP stream. If the substitutive RTP stream comes from 550 substitutive media source, the source had better has some knowledge 551 about the media encoding bitrate of main content in advance. How it 552 knows that is out of scope in this draft. 554 4.5. Processing Splicing in User Invisibility Case 556 Compared to above user visibility case, the primary difference in 557 this case is mixer MUST NOT include CSRC list in outgoing packets 558 (i.e., CSRC count field is set to zero and CSRC list fields are 559 absent). 561 Therefore, due to the absence of CRSC list in current RTP stream, RTP 562 receiver only initiates SDES, BYE and APP packets to mixer without 563 any knowledge of main media source and substitutive media source. 564 This creates a danger that loops involving those sources could not be 565 detected. 567 5. Implementation Considerations 569 When mixer is used to handle RTP splicing, RTP receiver does not need 570 any RTP/RTCP extension for splicing. As a trade-off, additional 571 overhead could be induced on mixer which uses its own sequence number 572 space and timing model. So mixer will rewrite RTP sequence number 573 and timestamp whatever splicing is active or not, and generate RTCP 574 flows for both sides. In case mixer serves multiple main RTP streams 575 simultaneously, this may lead to more overhead on mixer. 577 In addition, there is a potential issue with loop detection, which 578 would be problematic if User Invisibility Requirement is required. 580 6. Security Considerations 582 If any payload internal security mechanisms (e.g., SSH, SSL etc) are 583 used, only media source and RTP receiver can learn the security 584 keying material generated by such internal security mechanism, any 585 middlebox (e.g., mixer) between media source and RTP receiver can't 586 get such keying material. Only when regular transport security 587 mechanisms (e.g., SRTP, IPSec, etc) are used, mixer will process the 588 packets passing through it. 590 The security considerations of the RTP specification [RFC3550], the 591 Extended RTP profile for RTCP-Based Feedback [RFC4585], and the 592 Secure Real-time Transport Protocol [RFC3711] apply. Mixer must be 593 trusted by main media source and insertion media source, and must be 594 included in the security context. 596 7. IANA Considerations 598 No IANA actions are required. 600 8. Acknowledgments 602 The following individuals have reviewed the earlier versions of this 603 specification and provided very valuable comments: Colin Perkins, 604 Magnus Westerlund, Roni Even, Tom Van Caenegem, Joerg Ott, David R 605 Oran, Cullen Jennings, Ali C Begen, and Ning Zong. 607 9. Change Log 609 9.1. draft-xia-avtext-splicing-for-rtp-01 611 The following are the major changes compared to previous version 00: 613 o Use mixer to handle both user visible and invisible splicing. 615 o Add one subsection to describe media clipping considerations. 617 o Add one subsection to describe congestion control considerations. 619 9.2. draft-xia-avtext-splicing-for-rtp-00 621 The following are the major changes compared to previous AVT I-D 622 version 00: 624 o Change primary RTP stream to main RTP stream, add current RTP 625 stream as the streaming received by RTP receiver. 627 o Eliminate the ambiguity of inserted content with substitutive 628 content which replaces the main content rather than pause it. 630 o Clarify the signaling requirements. 632 o Delete the description on Mixer and MCU in section 4, mainly focus 633 on the direction whether a Translator can act as a Splicer. 635 o Add section 5 to describe the exact guidance on how an RTP 636 Translator is used to handle splicing. 638 o Modify the security considerations section and add acknowledges 639 section. 641 10. References 643 10.1. Normative References 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, March 1997. 648 [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, 649 "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, 650 January 1998. 652 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 653 Jacobson, "RTP: A Transport Protocol for Real-Time 654 Applications", STD 64, RFC 3550, July 2003. 656 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 657 Video Conferences with Minimal Control", STD 65, RFC 3551, 658 July 2003. 660 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 661 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 662 RFC 3711, March 2004. 664 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 665 "Extended RTP Profile for Real-time Transport Control 666 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 667 July 2006. 669 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 670 "Codec Control Messages in the RTP Audio-Visual Profile 671 with Feedback (AVPF)", RFC 5104, February 2008. 673 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 674 January 2008. 676 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 677 Flows", RFC 6051, November 2010. 679 [I-D.ietf-avtcore-ecn-for-rtp] 680 Westerlund, M., "Explicit Congestion Notification (ECN) 681 for RTP over UDP", draft-ietf-avtcore-ecn-for-rtp-02 (work 682 in progress), October 2010. 684 10.2. Informative References 686 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 687 Friendly Rate Control (TFRC): Protocol Specification", 688 RFC 5348, September 2008. 690 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 691 Protocol (RTCP) Extensions for Single-Source Multicast 692 Sessions with Unicast Feedback", RFC 5760, February 2010. 694 [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control 695 Protocol (DCCP)", RFC 5762, April 2010. 697 [SCTE30] Society of Cable Telecommunications Engineers (SCTE), 698 "Digital Program Insertion Splicing API", 2001. 700 [SCTE35] Society of Cable Telecommunications Engineers (SCTE), 701 "Digital Program Insertion Cueing Message for Cable", 702 2004. 704 [H.323] ITU-T Recommendation H.323, "Packet-based multimedia 705 communications systems", June 2006. 707 Author's Address 709 Jinwei Xia 710 Huawei 711 Software No.101 712 Nanjing, Yuhuatai District 210012 713 China 715 Phone: +86-025-86622310 716 Email: xiajinwei@huawei.com