idnits 2.17.1 draft-peilin-avt-rtp-burst-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC4585]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2009) is 5520 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-avt-rtcp-guidelines' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC4588' is defined on line 564, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-avt-rtcp-guidelines-00 ** Downref: Normative reference to an Informational draft: draft-ietf-avt-rtcp-guidelines (ref. 'I-D.ietf-avt-rtcp-guidelines') -- Possible downref: Normative reference to a draft: ref. 'I-D.levin-avt-rtcp-burst' == Outdated reference: A later version (-03) exists of draft-versteeg-avt-rapid-synchronization-for-rtp-01 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport P. Yang 3 Internet-Draft Huawei Technologies Co., Ltd. 4 Intended status: Standards Track B. Lei 5 Expires: September 9, 2009 China Telecom 6 Z. Zou 7 Huawei Technologies Co., Ltd. 8 March 8, 2009 10 Extensions to RTCP for Rapid Synchronization 11 draft-peilin-avt-rtp-burst-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 9, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document specifies an extension to "Extended RTP Profile for 50 Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) 51 " [RFC4585] to reduce multicast session synchronization time and 52 improve the user experience when a video receiver joins a multicast 53 stream. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Rapid Synchronization Mechanism Description . . . . . . . . . 3 60 3. Rapid Synchronization Mechanism Flow . . . . . . . . . . . . . 6 61 4. The format of new extended RTCP Transport Layer Feedback 62 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. RTCP Rapid Synchronization Request(RSR) . . . . . . . . . 7 64 4.2. RTCP Rapid Synchronization Indication(RSI) . . . . . . . . 8 65 4.3. RTCP Synchronization Rate Adaptation(SRA) . . . . . . . . 10 66 4.4. RTCP Synchronization Completed Notification(SCN) . . . . . 10 67 4.5. RTCP Synchronization Completed Response(SCR) . . . . . . . 11 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 Both "Extensions to RTCP Feedback Mechanism for Burst Streaming" 76 [I-D.levin-avt-rtcp-burst] and "Unicast-Based Rapid Synchronization 77 with RTP Multicast Sessions" 78 [I-D.versteeg-avt-rapid-synchronization-for-rtp] introduce some 79 reasons, such as the key information to appear in the stream, for a 80 synchronization delay while joining a multicast group to receive 81 video multicast streaming in a random point in time. These reasons 82 are main factors affecting the experience of multicast session 83 synchronization. 85 It is clear that the IETF needs to define a method to solve these 86 reasons and improve multicast session synchronization which can be 87 used to extend the existing RTP and RTCP mechanisms. This document 88 proposes extensions for rapid synchronization multicast session based 89 on RTP control protocol(RTCP) to improve the experience of multicast 90 session and reduce synchronization time when a receiver wishes to 91 join another multicast session. 93 1.1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Rapid Synchronization Mechanism Description 101 The real-time transport protocol (RTP) [RFC3550] provides video 102 delivery services with real-time characteristics, such as video 103 broadcasts in which receivers can frequently switch among different 104 multicast sessions. In order to achieve rapid synchronization and 105 reduce the synchronization delay between multicast sessions, a cached 106 Retransmission Server (RS) is employed to send an accelerated unicast 107 streaming to the requesting Receiver and temporarily replace the 108 multicast session. 110 The set of new extended RTCP Transport Layer Feedback Messages 111 defined in this document is designed to support rapid synchronization 112 mechanism as described below: 114 1) Receiver sends a rapid synchronization request for the new channel 115 and at the same time to request to cease all the data streams of the 116 current unicast channel if it is being used. This request is sent in 117 an extended RTCP Transport Layer Feedback Message "RTCP Rapid 118 Synchronization Request (RSR)", which is defined in the Section 4.1. 119 The extended RTCP message includes the SSRC of the media source of 120 the current channel that should stop and the SSRC of media source of 121 the new channel. The receiver indicates that it needs to receive 122 media streaming with the key information "as soon as possible" using 123 the default Bitrate on the first RSR request by sending the new 124 extended RTCP RSR Message to the Retransmission Server. Later, an 125 adaptive Bitrate will be used for the following RTCP RSR Message 126 requests. The Adaptive Bitrate will be adjusted based on receiver's 127 feedback of network transportation situation. 128 Note that since no RTP packets have been received yet for this 129 session, the SSRC should be obtained out-of-band. 131 2) Retransmission Server receives the RTCP RSR Message, and decides 132 whether to accept it or not. The Retransmission Server sends a new 133 extended RTCP Message "RTCP Rapid Synchronization Indication" (RSI) 134 to the Receiver. This new RTCP Transport Layer Feedback Message 135 "RTCP Rapid Synchronization Indication" (RSI) is defined in 136 Section 4.2. The RTCP RSI Message contains the result of Rapid 137 Synchronization Request, First sequence number of the unicast stream 138 and the expected minimum interval of the extend RTCP Transport Layer 139 Feedback Message "RTCP Synchronization Rate Adaptation (SRA)". 141 Note that when Retransmission Server Receives RTCP RSR Message, it 142 MUST also disable all the data streams of the current channel 143 provided to the Receiver. For example, the Retransmission Server 144 should cancel the earlier pending rapid synchronization operation or 145 stop the ongoing synchronization operation by ceasing the relevant 146 unicast burst media stream of the current channel. The 147 retransmission service for the current channel provided to the 148 receiver also SHOULD be disabled. 150 3) If Retransmission Server grants the rapid synchronization request, 151 it transmits the unicast media stream of the new channel to Receiver 152 at an accelerated rate. 154 4) Since it receives the unicast burst media stream, Receiver can 155 test for a maximum optimal network speed for the burst media stream 156 transfer. The method for testing the maximum optimal network speed 157 is based on the receiving packets of unicast burst media stream. If 158 there is no packet loss or stationary loss, it indicates that higher 159 bitrate is possible. It indicates that lower bitrate is necessary if 160 packet loss is higher. The Receiver will make its feedback to 161 Retransmission Server by sending a new extended RTCP Message "RTCP 162 Synchronization Rate Adaptation (SRA)" according to the result of the 163 maximum optimal network speed test, and give a Proposed Adaptive 164 Bitrate. This new RTCP Transport Layer Feedback Message "RTCP 165 Synchronization Rate Adaptation (SRA)" is defined in Section 4.3. 167 5) Receiving the RTCP SRA Message, the Retransmission Server adjusts 168 its current transmitting bitrate to the maximum optimal bitrate 169 according to the RTCP SRA Message proposal of the Receiver and the 170 current condition of Retransmission Server. 172 6) Once unicast burst media stream is synchronized with multicast 173 media stream(that is to say, the unicast burst media catches up with 174 Real-time multicast media stream, Retransmission Server first 175 decreases its transmitting bitrate to a lower rate, and then sends 176 the RTCP Message "RTCP Synchronization Completed Notification (SCN)" 177 to instruct the Receiver to join the multicast session. This new 178 RTCP Transport Layer Feedback Message "RTCP Synchronization Completed 179 Notification (SCN)" is defined in Section 4.4. 181 7) After the Receiver receives the RTCP SCN Message, it immediately 182 sends multicast session join message to start receiving real-time 183 multicast media stream. 185 8) When the Receiver receives the multicast RTP flow, it sends the 186 RTCP Message "RTCP Synchronization Completed Response (SCR)" to the 187 Retransmission Server to ask to terminate the unicast burst media 188 stream. This new RTCP Transport Layer Feedback Message "RTCP 189 Synchronization Completed Response (SCR)" is defined in Section 4.5. 190 The RTCP SCR message contains the first sequence number of the 191 multicast RTP flow. 193 Note that during the burst unicast streaming, either the loss of key 194 information or data of random access point should cause the receiver 195 join the new multicast session. Whereafter, the receiver sends RTCP 196 Message "RTCP Synchronization Completed Response (SCR)", which 197 includes the reason of termination, to the Retransmission Server to 198 request for ceasing the current burst unicast. 200 9) When the Retransmission Server receives the first sequence number 201 of the multicast RTP flow, it will transmit the unicast media stream 202 until the first sequence number. 204 10) When the Receiver requests to switch to a second channel, the 205 rapid synchronization request message - the RTCP Transport Layer 206 Feedback Message "RTCP Rapid Synchronization Request (RSR)" shall use 207 the previous optimal bitrate for optimal rapid Synchronization of 208 multicast session. 210 Note that when the Receiver requests to switch to a second channel, 211 there may be an earlier rapid synchronization operation that is 212 pending or active. If the Receiver does not receive unicast burst 213 media stream. So RTCP RSR message shall use the default bitrate. If 214 the Receiver has received unicast burst media stream, RTCP RSR 215 message shall use the actual bitrate by measuring the burst unicast 216 media stream. 218 3. Rapid Synchronization Mechanism Flow 220 The flow diagram for rapid synchronization mechanism is illustrated 221 in Figure 1. This mechanism can be implemented using the extensions 222 of RTCP Transport Layer Feedback Messages defined in this document. 223 In this rapid synchronization mechanism, it can be supported by 224 sending video streaming based on unicast with key information from 225 Retransmission Server to Receiver. In the meantime, Retransmission 226 Server will adjust to the optimal maximum sending bitrate in terms of 227 network situation based on Receiver's feedback. 229 RTP Retransmission Router Receiver 230 Sender Server 232 v v v v 233 | | | | 234 | | | | 235 | RTP multicast session flow | | 236 |===================================>| | 237 | | | | 238 | RTCP Rapid Synchronization Request(default bitrate) | 239 | |<-------------------------------------------| 240 | | | | 241 | | RTCP Rapid Synchronization Indication() | 242 | |------------------------------------------->| 243 | | | | 244 | | RTP unicast burst (at actual bitrate) | 245 | |===========================================>| 246 | | | | 247 | | RTCP Synchronization Rate Adaptation() | 248 | |<-------------------------------------------| 249 | | | | 250 | | RTP unicast burst(at adaptive bitrate) | 251 | |===========================================>| 252 | | | | 253 | RTCP Synchronization Completed Notification() | 254 | |------------------------------------------->| 255 | | | | 256 | | | IGMP Join | 257 | | |<-------------------| 258 | | | | 259 | RTP multicast session flow | 260 |===================================>|===================>| 261 | | | | 262 | RTCP Synchronization Completed Response() | 263 | |<-------------------------------------------| 264 | | | | 265 ----------------------------------------------------------------- 266 Change to the second channel 267 ----------------------------------------------------------------- 268 | | | | 269 | RTCP Rapid Synchronization Request(adaptive bitrate) | 270 | |<-------------------------------------------| 271 | | | | 272 | | RTCP Rapid Synchronization Indication() | 273 | |------------------------------------------->| 274 | | | | 275 | | RTP unicast burst(at adaptive bitrate) | 276 | |===========================================>| 277 | | | | 278 | | | | 279 v v v v 281 Figure 1: Flow diagram for rapid synchronization 283 4. The format of new extended RTCP Transport Layer Feedback Messages 285 This section defines the format of new RTCP Transport Layer Feedback 286 Messages that are exchanged between the Retransmission Server and 287 Receiver during rapid synchronization. 289 4.1. RTCP Rapid Synchronization Request(RSR) 291 The RTCP RSR Request message is identified by PT=RTPFB and FMT=5. 293 The RTCP RSR Request is mandatory. 295 The RTCP RSR Request is used by Receiver to request rapid 296 synchronization for a new multicast RTP session and to request for 297 ceasing all data streams associated with the current channel provided 298 to the receiver . 300 The RTCP RSR field has the structure depicted in Figure 2. 302 0 1 2 3 303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Default/Adaptive Bitrate | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | SSRC of Current Unicast Burst | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 2: Syntax for the RSR messag 312 Default Bitrate/Adaptive Bitrate 314 The Default Bitrate/Adaptive Bitrate field is four octets. The 315 Default Bitrate indicated by Receiver at the first time to request 316 rapid synchronization, it depends on the Receiver's configuration. 317 Adaptive Bitrate: Adaptive Bitrate is used when the Receiver requests 318 a second rapid synchronization. It is the final adaptive bitrate of 319 previous rapid synchronization. The Adaptive Bitrate will be 320 adjusted dependence on network transportation situation. The Default 321 Bitrate/Adaptive Bitrate must be higher than multicast bitrate. 323 SSRC of Current Unicast Burst 325 The SSRC of Current Unicast Burst field is four octets. The SSRC of 326 unicast burst indicates the unicast burst media stream of the current 327 channel. This field is used to request Retransmission Server to 328 cease the unicast burst media stream of the current channel. 330 4.2. RTCP Rapid Synchronization Indication(RSI) 332 The RTCP RSI Indication message is identified by PT=RTPFB and FMT=6. 334 The RTCP RSI field has the structure depicted in Figure 3. 336 0 1 2 3 337 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Result | Reserved |I| Reason-type | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | First Unicast Sequence Number | Min SRA Interval | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Figure 3: Syntax for the RSI message 346 Result 348 The Result field is one octet. The Result value are assigned as 349 follows: 351 1 for Success 353 2 for Failure 355 Min SRA Interval Flag (I): 1 bit 357 When theMin SRA Interval Flag Bit is set to 1, the Min SRA Interval 358 field indicates the interval in number of packets. Otherwise, when 359 the Min SRA Interval Flag Bit is set to 0,the Min SRA Interval field 360 indicates the time interval. Its default value is set to 0. 362 Reserved 364 The Reserved fields are one octet and are set to zero on 365 transmission, and ignored on reception. 367 Reason-type 369 The Reason-type field is two octets. The Reason-type field depends 370 on the Result field. This field defines the initial set of 371 successful type when the Result field set to 1 (Success). In the 372 meantime, this field also defines the initial set of failure reason 373 when the Result field set to 2 (Failure). 375 for Success Result: 377 1 for joining the multicast session immediately 379 2 for waiting for notification to join multicast session 381 First Unicast Sequence Number 383 The First Unicast Sequence Number field is two octets. The First 384 Unicast Sequence Number field indicates the first packet that will be 385 sent as part of the rapid synchronization. This field allows 386 Receiver to know if one or more packets are dropped at the beginning 387 of rapid synchronization. The First Unicast Sequence Number field is 388 constructed by putting the 16-bit RTP sequence number. 390 Min SRA Interval 392 The Min SRA Interval field is two octets. The Min SAR Interval field 393 specifies the allowed minimum time/packet number before sending a 394 Synchronization Rate Adaptation(SAR). If theMin SRA Interval Flag 395 Bit is set to 0, it is in units of 1/10 second. Otherwise, the Min 396 SRA Interval field indicates the interval in number of packets. If 397 network situation is unstable, Receiver will send the RTCP SAR 398 Message at "Min SRA Interval" interval ( or receiving the packet 399 number of the "Min SRA Interval"). When transmitting bitrate reach a 400 stable state - maximum optimal bitrate, Receiver will send the RTCP 401 SAR Message at longer interval and even won't send. 403 4.3. RTCP Synchronization Rate Adaptation(SRA) 405 The RTCP SAR Request message is identified by PT=RTPFB and FMT=7. 407 The RTCP SRA field has the structure depicted in Figure 4. 409 0 1 2 3 410 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Proposed Adaptive Bitrate | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Number of packet loss | Period of packets lost | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Figure 4: Syntax for the SRA message 419 Proposed Adaptive Bitrate 421 The Proposed Adaptive Bitrate field is four octets. The Proposed 422 Adaptive Bitrate field indicates that the final optimum rate of 423 transportation is used from Retransmission Server to Receiver. It 424 gradually adjusts the bitreate that Reveive can receive. If there is 425 no packet loss or stationary loss, it indicates that higher bitrate 426 is possible. It indicates that lower bitrate is necessary if packet 427 loss is higher. 429 Number of packets lost 431 The Number of packets lost field is two octets. 433 Period of packets lost 435 The Period of packets lost field is two octets. It is in units of 436 1/10 second. 438 4.4. RTCP Synchronization Completed Notification(SCN) 440 The RTCP SCN notification indication message is identified by 441 PT=RTPFB and FMT=8. 443 The RTCP SCN field has the structure depicted in Figure 5. 445 0 1 2 3 446 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Final Optimal Adaptive Bitrate | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Figure 5: Syntax for the SCN messag 453 Final Optimal Adaptive Bitrate 455 The Final Optimal Adaptive Bitrate field is four octets. The Final 456 Optimal Adaptive Bitrate field indicates the final optimal 457 transmission rate from Retransmission Server to Receiver. Receiver 458 can use this rate to request subsequent Rapid Synchronization. 460 4.5. RTCP Synchronization Completed Response(SCR) 462 The RTCP SCR response message is identified by PT=RTPFB and FMT=9. 464 The RTCP SCR field has the structure depicted in Figure 6. 466 0 1 2 3 467 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Type | Reserved |First Multicast Sequence Number| 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 Figure 6: Syntax for the SCR message 474 Type 476 1 for the response of joining the multicast session immediately 478 2 2 for indicating either key information or data of random 479 access point of the current burst unicast media stream get lost 480 and requesting to cease the current burst unicast media stream 481 for the associated multicast session that the Receiver is going 482 to join. 484 When the Type field is set to 1. It indicates that the Receive 485 responses the type of joining the multicast session immediately 487 When the Type field is set to 2. It indicates that either key 488 information or data of random access point of the current burst 489 unicast media stream get lost,the receiver requests the 490 Retransmission Server to cease the current burst unicast media stream 491 for the associated multicast session that the Receiver is going to 492 join . 494 Note that when the Type field is set to 2. The SSRC field in RTCP 495 extension feedback message indicates the SSRC of burst unicast media 496 stream for the associated multicast group that the Receiver is going 497 to join. 499 Reserved 501 The Reserved fields are three octets and are set to zero on 502 transmission, and ignored by the receiver. 504 First Multicast Sequence Number 506 The First Multicast Sequence Number field is two octets. When the 507 Type field is set to 1, the First Multicast Sequence Number field 508 indicates the first sequence number received from the multicast 509 stream. When Retransmission Server receives the message, it sends 510 unicast stream until First Multicast Sequence Number. 512 When the Type field is set to 2, the First Multicast Sequence Number 513 is set to 0x0. 515 5. Security Considerations 517 TBC. 519 6. Change Log 521 The following are the major changes compared to version 00: 523 1.In the Rapid Synchronization Mechanism Description section, some 524 steps' descriptions have been modified 526 2. In the format of new extended RTCP Transport Layer Feedback 527 Messages section, some fields of feedback message have been 528 redefined. 530 3. Editorial changes to several points 532 7. Normative References 534 [I-D.ietf-avt-rtcp-guidelines] 535 Ott, J. and C. Perkins, "Guidelines for Extending the RTP 536 Control Protocol (RTCP)", 537 draft-ietf-avt-rtcp-guidelines-00 (work in progress), 538 July 2008. 540 [I-D.levin-avt-rtcp-burst] 541 Levin, O. and Z. Vax, "Extensions to RTCP Feedback 542 Mechanism for Burst Streaming", 543 draft-levin-avt-rtcp-burst-00 (work in progress), 544 October 2008. 546 [I-D.versteeg-avt-rapid-synchronization-for-rtp] 547 Steeg, B., Begen, A., and T. Caenegem, "Unicast-Based 548 Rapid Synchronization with RTP Multicast Sessions", 549 draft-versteeg-avt-rapid-synchronization-for-rtp-01 (work 550 in progress), November 2008. 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, March 1997. 555 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 556 Jacobson, "RTP: A Transport Protocol for Real-Time 557 Applications", STD 64, RFC 3550, July 2003. 559 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 560 "Extended RTP Profile for Real-time Transport Control 561 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 562 July 2006. 564 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 565 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 566 July 2006. 568 Authors' Addresses 570 Peilin Yang 571 Huawei Technologies Co., Ltd. 572 No.91 Baixia Road 573 Nanjing 210001 574 P.R.China 576 Email: yangpeilin@huawei.com 577 Baohua Lei 578 China Telecom 579 No.118, Xizhimenneidajie 580 Xicheng District 581 Beijing 100035 582 P.R.China 584 Email: Leibh@ctbri.com.cn 586 Zixuan Zou 587 Huawei Technologies Co., Ltd. 588 Huawei Industrial Base 589 Shenzhen 590 P.R.China 592 Email: tendyntu@huawei.com