idnits 2.17.1 draft-ietf-avtext-splicing-for-rtp-00.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 8, 2011) is 4583 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2250' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'RFC3551' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'RFC5117' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'RFC5760' is defined on line 673, 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 8, 2011 5 Expires: April 10, 2012 7 Content Splicing for RTP Sessions 8 draft-ietf-avtext-splicing-for-rtp-00 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 February 12, 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 . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . 15 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 an 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 switches between substitutive content and main content, 273 and only forward one of them at one point of time. A RFC3550 mixer 274 seems to have such capability to select a media stream, always under 275 its own SSRC, which can be used for reception reports to media 276 sources and receivers. Moreover, mixer includes the CSRC list in 277 outgoing packets to indicate the source(s) of content, this 278 facilitates the system debugging. From this point of view, an RTP 279 mixer may have some chance to be Splicer. In next four subsections 280 (from subsection 4.1 to subsection 4.4), we start analyzing how an 281 RTP mixer handles RTP splicing and how it satisfies the general 282 requirements listed in section 3. 284 In subsection 4.5, we specially consider the special requirement 6 285 (i.e., User Invisibility Requirement) since it needs to mask any 286 splicing clue on user (e.g, CSRC list must not be included in 287 outgoing packets to prevent user from identifying the difference 288 between main RTP stream and substitutive RTP stream) when mixer is 289 used. 291 4.1. RTP Processing in RTP Mixer 293 Once mixer has learnt when to do splicing, it must get ready for the 294 coming splicing in advance, e.g., fetches the substitutive content 295 either from local media file storage or via substitutive RTP stream 296 earlier than splicing in point. If the substitutive content comes 297 from local media file storage, mixer can construct the substitutive 298 RTP stream using its own SSRC and leave the CSRC list blank in the 299 output stream. 301 When the main RTP stream begins, mixer terminates the main RTP 302 stream. Using the main RTP packets, mixer generates the current 303 media stream with its own SSRC, sequence number space and timing 304 model. Moreover, mixer inserts the SSRC of main RTP stream into CSRC 305 list in the current media stream. 307 When splicing begins, mixer switches to the substitutive RTP stream 308 at splicing in point, extracts the payload data (i.e., substitutive 309 content), encodes substitutive content and outputs it instead of main 310 content in the current media stream. Moreover, mixer inserts the 311 SSRC of substitutive RTP stream into CSRC list in the current media 312 stream. 314 When splicing ends, mixer switches to the main RTP stream at splicing 315 out point, extracts the payload data (i.e., main content), encodes 316 main content and outputs it instead of substitutive content in the 317 current media stream. Moreover, mixer inserts the SSRC of main RTP 318 stream into CSRC list in the current media stream. 320 The whole RTP splicing procedure is perhaps best explained by a 321 pseudo code example: 323 if (main RTP stream begins) { 324 the main RTP stream is terminated on mixer and main content is 325 encoded by mixer with its own SSRC identifier; 327 the sequence numbers of the current RTP packets which contain main 328 content are allocated by mixer, until the splicing begins; 330 the timestamp of the current RTP packet increments linearly; 332 the CSRC list of the current RTP packet indicates SSRC of main RTP 333 stream; 334 } 336 else if (splicing begins) { 337 the substitutive RTP stream is terminated on mixer and 338 substitutive content is encoded by mixer with its own SSRC 339 identifier; 341 the sequence numbers of the current RTP packets which contain 342 substitutive content are allocated by mixer and maintain 343 consistent with the sequence numbers of previous current RTP 344 packets, until the splicing end; 346 the timestamp of the current RTP packet increments linearly; 348 the CSRC list of the current RTP packet indicates SSRC of 349 substitutive RTP stream; 351 } 353 else if (splicing ends) { 354 the main RTP stream is terminated on mixer and main content is 355 encoded by mixer with its own SSRC identifier; 357 the sequence numbers of the current RTP packets which contain main 358 content are allocated by mixer and maintain consistent with the 359 sequence numbers of previous current RTP packets, until the next 360 splicing begins; 362 the timestamp of the current RTP packets increments linearly; 364 the CSRC list the current RTP indicates SSRC of main RTP stream; 365 } 367 Splicing may occur more than one time during the lifetime of main RTP 368 stream, this means mixer needs to output main content and 369 substitutive content in turn with its own SSRC identifier. From user 370 point of view, the only source of the current stream is mixer 371 wherever the content comes from. 373 Note that, the substitutive content should be outputted in the range 374 of splicing duration. Any gap or overlap between main RTP stream and 375 substitutive RTP stream may induce media clipping at splicing point. 376 More details about preventing media clipping are introduced in 377 section 4.3. 379 4.2. RTCP Processing in RTP Mixer 381 By monitoring available bandwidth and buffer levels and by computing 382 network metrics such as packet loss, network jitter, and delay, RTP 383 receiver can learn the situation on it and can communicate this 384 information to media source via RTCP reception reports. 386 According to the description in section 7.3 of [RFC3550], mixer 387 divides RTCP flow between media source and receiver into two separate 388 RTCP loops, media source probably has no idea about the situation on 389 receiver. Hence, mixer may use some mechanisms, allowing media 390 source to at least some degree to have some knowledge of the 391 situation on receiver when its content is being passed to receiver. 393 Because splicing is a processing that mixer selects one media stream 394 from multiple streams rather than mixing them, the number of the 395 original, pre-spliced RTP packets will be equal to the number of 396 spliced RTP packets, i.e., mixer changes the sequence numbers of RTP 397 packets but not changes the sum of them. When mixer receives RTCP 398 reception reports sent from downstream receiver, it must change the 399 SSRC in report block to the SSRC identifier of original media source 400 and rewrite the extended highest sequence number to the corresponding 401 original extended highest sequence number before forwarding the RTCP 402 reception reports to original media source. In such case, the media 403 source will see the reception quality of its stream received by 404 mixer, and the reception quality of spliced stream received by RTP 405 receiver. 407 For the media source whose content is terminated on mixer and is not 408 being passed to receiver, mixer must act as a receiver and therefore 409 send reception reports to the media source. 411 4.3. Media Clipping Considerations 413 This section provides informative guideline about how media clipping 414 may shape and how mixer deal with the media clipping. 416 Media clippings potentially occur at the splicing point if the time 417 slot for substitutive RTP stream mismatches (shorter or longer than) 418 the duration of the reserved main RTP stream for replacing. 420 At the splicing in point, mixer usually start the substitutive 421 content with independently decodable frames and fill the substitutive 422 content up receiver's buffer with several seconds earlier than the 423 presentation time of substitutive content. By this way, smooth 424 playback can be achieved without pauses or stuttering. 426 Compared to buffering method used at splicing in point, things become 427 somewhat complex at splicing out point. The case that insertion 428 duration is shorter than the reserved gap time may cause a little 429 playback latency of main RTP stream on RTP receiver, but not 430 adversely impact the quality of user experience. However, in case 431 that insertion duration is longer than the reserved gap duration, 432 there exists an overlap of the substitutive RTP stream and the main 433 RTP stream at splicing out point, which may cause synchronization 434 problem and result in a perceptible media clipping. 436 To guard against a media clipping at splicing out point, main RTP 437 source may reserve a bit extra playback delay (e.g., 500 438 milliseconds) to send out the first main RTP packet after splicing 439 ends. Note that the delay should not be too long to smoothly 440 playback the coming main RTP stream. But if the splicing is still 441 unfinished when the first main RTP packet has reached, mixer must 442 terminate the splicing and switch back to main RTP stream even if 443 this may cause media stuttering on receiver. 445 4.4. Congestion Control Considerations 447 Provided that the substitutive content has somewhat different 448 characteristics to the main content it replaces (e.g., the more 449 dynamic content, the higher bandwidth occupation), or substitutive 450 content may be encoded with different codec and has different 451 encoding bitrate, some challenge raise to network capacity and 452 receiver buffer size. A more dynamic content or a higher encoding 453 bitrate stream might overload the network and possibly exceed the 454 receiver's media consumption rate, which might flood receiver's 455 buffer and eventually result in a buffer overflow. Either network 456 overload or buffer overflow would induce network congestion and 457 congestion-caused packet loss. 459 To be robust to network congestion and packet loss, mixer must 460 continuously monitor the network situation by means of a variety of 461 manners: 463 1. RTCP receiver reports indicate packet loss [RFC3550]. 465 2. RTCP NACKs for lost packet recovery [RFC4585]. 467 3. RTCP ECN Feedback information [I-D.ietf-avtcore-ecn-for-rtp]. 469 Upon detection of above three types of RTCP reports during splicing, 470 mixer will treat them with three different manners as following: 472 1. If mixer receives the RTCP receiver reports with packet loss 473 indication, it will process them as the description given in 474 section 7.3 of [RFC3550]. 476 2. If mixer receives the RTCP NACK packets defined in [RFC4585] from 477 RTP receiver for packet loss recovery, it first identifies the 478 content category of lost packets to which the NACK corresponds. 479 Then, mixer will generate new RTCP NACK for the lost packets with 480 its own SSRC, and make corresponding changes to their sequence 481 numbers to match original, pre-spliced, packets. If the lost 482 substitutive content comes from local media file storage, mixer 483 acting as substitutive media source will directly fetch the lost 484 substitutive content and retransmit it to RTP receiver. 486 It is somewhat complex that the lost packets requested in a 487 single RTCP NACK message not only contain the main content but 488 also the substitutive content. To address this, mixer must 489 divide the RTCP NACK packet into two separate RTCP NACK packets: 490 one requests for the lost main content, and another requests for 491 the lost substitutive content. 493 3. In [I-D.ietf-avtcore-ecn-for-rtp], two RTCP extensions are 494 defined for ECN feedback: RTP/AVPF transport layer ECN feedback 495 packet for urgent ECN information, and RTCP XR ECN summary report 496 block for regular reporting of the ECN marking information. 498 If an ECN-aware mixer receives any RTCP ECN feedback (i.e., RTCP 499 ECN feedback packets or RTCP XR summary reports) from RTP 500 receiver, it must operates as description given in section 8.4 of 501 [I-D.ietf-avtcore-ecn-for-rtp], terminating the RTCP ECN feedback 502 packets from downstream receivers, and driving congestion control 503 loop and bitrate adaptation between itself and downstream 504 receiver as if it were the media source. In addition, an ECN- 505 aware RTP mixer must generate RTCP ECN feedback relating to the 506 input RTP streams it terminates, and driving congestion control 507 loop and bitrate adaptation between itself and upstream sender as 508 if it were the RTP sender. 510 Once mixer learns that congestion is being experienced on its 511 downstream link by means of above three detection mechanisms, it 512 should adapt the bitrate of output stream in response to network 513 congestion. The bitrate adaptation may be determined by a TCP- 514 friendly bitrate adaptation algorithm specified in [RFC5348], or by a 515 DCCP congestion control algorithms defined in [RFC5762]. 517 In practice, during splicing, the real reason to cause congestion 518 usually is the different characteristic of substitutive RTP stream 519 (more dynamic content or higher encoding bitrate) with main RTP 520 stream, and that stream transcoding or thinning on mixer is very 521 inefficient and difficult operation. Therefore, a means that enables 522 substitutive media source to limit the media bitrate it is currently 523 generating even in the absence of congestion on the path between 524 itself and mixer is desirable. The TMMBR message defined in 525 [RFC5104] provides an effective method. When mixer detects 526 congestion on its downstream link during splicing, it uses TMMBR to 527 request substitutive media source to reduce the media bitrate to a 528 value that is in compliance with congestion control principles for 529 the slowest link. Upon reception of TMMBR, substitutive media source 530 applies its congestion control algorithm and responds Temporary 531 Maximum Media Stream Bit Rate Notification (TMMBN) to mixer. 533 From above analysis, to reduce the risk of congestion and remain the 534 bandwidth consumption stable over time, the substitutive RTP stream 535 is RECOMMENDED to be encoded at an appropriate bitrate to match that 536 of main RTP stream. If the substitutive RTP stream comes from 537 substitutive media source, the source had better has some knowledge 538 about the media encoding bitrate of main content in advance. How it 539 knows that is out of scope in this draft. 541 4.5. Processing Splicing in User Invisibility Case 543 Compared to above user visibility case, the primary difference in 544 this case is mixer MUST NOT include CSRC list in outgoing packets 545 (i.e., CSRC count field is set to zero and CSRC list fields are 546 absent). 548 Therefore, due to the absence of CRSC list in current RTP stream, RTP 549 receiver only initiates SDES, BYE and APP packets to mixer without 550 any knowledge of main media source and substitutive media source. 551 This creates a danger that loops involving those sources could not be 552 detected. 554 5. Implementation Considerations 556 When mixer is used to handle RTP splicing, RTP receiver does not need 557 any RTP/RTCP extension for splicing. As a trade-off, additional 558 overhead could be induced on mixer which uses its own sequence number 559 space and timing model. So mixer will rewrite RTP sequence number 560 and timestamp whatever splicing is active or not, and generate RTCP 561 flows for both sides. In case mixer serves multiple main RTP streams 562 simultaneously, this may lead to more overhead on mixer. 564 In addition, there is a potential issue with loop detection, which 565 would be problematic if User Invisibility Requirement is required. 567 6. Security Considerations 569 If any payload internal security mechanisms (e.g., SSH, SSL etc) are 570 used, only media source and RTP receiver can learn the security 571 keying material generated by such internal security mechanism, any 572 middlebox (e.g., mixer) between media source and RTP receiver can't 573 get such keying material. Only when regular transport security 574 mechanisms (e.g., SRTP, IPSec, etc) are used, mixer will process the 575 packets passing through it. 577 The security considerations of the RTP specification [RFC3550], the 578 Extended RTP profile for RTCP-Based Feedback [RFC4585], and the 579 Secure Real-time Transport Protocol [RFC3711] apply. Mixer must be 580 trusted by main media source and insertion media source, and must be 581 included in the security context. 583 7. IANA Considerations 585 No IANA actions are required. 587 8. Acknowledgments 589 The following individuals have reviewed the earlier versions of this 590 specification and provided very valuable comments: Colin Perkins, 591 Magnus Westerlund, Roni Even, Tom Van Caenegem, Joerg Ott, David R 592 Oran, Cullen Jennings, Ali C Begen, and Ning Zong. 594 9. Change Log 596 9.1. draft-xia-avtext-splicing-for-rtp-01 598 The following are the major changes compared to previous version 00: 600 o Use mixer to handle both user visible and invisible splicing. 602 o Add one subsection to describe media clipping considerations. 604 o Add one subsection to describe congestion control considerations. 606 9.2. draft-xia-avtext-splicing-for-rtp-00 608 The following are the major changes compared to previous AVT I-D 609 version 00: 611 o Change primary RTP stream to main RTP stream, add current RTP 612 stream as the streaming received by RTP receiver. 614 o Eliminate the ambiguity of inserted content with substitutive 615 content which replaces the main content rather than pause it. 617 o Clarify the signaling requirements. 619 o Delete the description on Mixer and MCU in section 4, mainly focus 620 on the direction whether a Translator can act as a Splicer. 622 o Add section 5 to describe the exact guidance on how an RTP 623 Translator is used to handle splicing. 625 o Modify the security considerations section and add acknowledges 626 section. 628 10. References 629 10.1. Normative References 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, March 1997. 634 [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, 635 "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, 636 January 1998. 638 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 639 Jacobson, "RTP: A Transport Protocol for Real-Time 640 Applications", STD 64, RFC 3550, July 2003. 642 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 643 Video Conferences with Minimal Control", STD 65, RFC 3551, 644 July 2003. 646 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 647 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 648 RFC 3711, March 2004. 650 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 651 "Extended RTP Profile for Real-time Transport Control 652 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 653 July 2006. 655 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 656 "Codec Control Messages in the RTP Audio-Visual Profile 657 with Feedback (AVPF)", RFC 5104, February 2008. 659 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 660 January 2008. 662 [I-D.ietf-avtcore-ecn-for-rtp] 663 Westerlund, M., "Explicit Congestion Notification (ECN) 664 for RTP over UDP", draft-ietf-avtcore-ecn-for-rtp-02 (work 665 in progress), October 2010. 667 10.2. Informative References 669 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 670 Friendly Rate Control (TFRC): Protocol Specification", 671 RFC 5348, September 2008. 673 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 674 Protocol (RTCP) Extensions for Single-Source Multicast 675 Sessions with Unicast Feedback", RFC 5760, February 2010. 677 [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control 678 Protocol (DCCP)", RFC 5762, April 2010. 680 [SCTE30] Society of Cable Telecommunications Engineers (SCTE), 681 "Digital Program Insertion Splicing API", 2001. 683 [SCTE35] Society of Cable Telecommunications Engineers (SCTE), 684 "Digital Program Insertion Cueing Message for Cable", 685 2004. 687 [H.323] ITU-T Recommendation H.323, "Packet-based multimedia 688 communications systems", June 2006. 690 Author's Address 692 Jinwei Xia 693 Huawei 694 Software No.101 695 Nanjing, Yuhuatai District 210012 696 China 698 Phone: +86-025-86622310 699 Email: xiajinwei@huawei.com