idnits 2.17.1 draft-ietf-avt-rtp-retransmission-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1072 has weird spacing: '... sender may ...' == Line 1270 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7741 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) -- Missing reference section? '8' on line 75 looks like a reference -- Missing reference section? '1' on line 1071 looks like a reference -- Missing reference section? '2' on line 136 looks like a reference -- Missing reference section? '9' on line 165 looks like a reference -- Missing reference section? '3' on line 351 looks like a reference -- Missing reference section? '4' on line 474 looks like a reference -- Missing reference section? '11' on line 503 looks like a reference -- Missing reference section? '5' on line 818 looks like a reference -- Missing reference section? '6' on line 850 looks like a reference -- Missing reference section? '7' on line 918 looks like a reference -- Missing reference section? '10' on line 1102 looks like a reference -- Missing reference section? '12' on line 1168 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft 3 draft-ietf-avt-rtp-retransmission-05.txt J. Rey/Matsushita 4 D. Leon/Nokia 5 A. Miyazaki/Matsushita 6 V. Varsa/Nokia 7 R. Hakenberg/Matsushita 9 Expires: August 2003 February 2003 11 RTP Retransmission Payload Format 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC 2026. 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 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference 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 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 [Note to RFC Editor: This paragraph is to be deleted when this 38 draft is published as an RFC. References in this draft to RFC XXXX 39 should be replaced with the RFC number assigned to this document.] 41 Abstract 43 RTP retransmission is an effective packet loss recovery technique 44 for real-time applications with relaxed delay bounds. This document 45 describes an RTP payload format for performing retransmissions. 46 Retransmitted RTP packets are sent in a separate stream from the 47 original RTP stream. It is assumed that feedback from receivers to 48 senders is available. In particular, it is assumed that RTCP 49 feedback as defined in the extended RTP profile for RTCP-based 50 feedback (denoted RTP/AVPF), is available in this memo. 52 Table of Contents 54 1. Introduction....................................................3 55 2. Terminology.....................................................3 56 3. Requirements and design rationale for a retransmission scheme...4 57 4. Retransmission payload format...................................6 58 5. Association of a retransmission stream with its original stream.8 59 6. Use with the extended RTP profile for RTCP-based feedback......10 60 7. Congestion control.............................................12 61 8. Retransmission Payload Format MIME type registration...........13 62 9. RTSP considerations............................................19 63 10. Implementation examples.......................................20 64 11. IANA considerations...........................................23 65 12. Security considerations.......................................23 66 13. Acknowledgements..............................................24 67 14. References....................................................24 68 Author's Addresses................................................25 70 1. Introduction 72 Packet losses between an RTP sender and receiver may significantly 73 degrade the quality of the received media. Several techniques, such 74 as forward error correction (FEC), retransmissions or interleaving 75 may be considered to increase packet loss resiliency. RFC 2354 [8] 76 discusses the different options. 78 When choosing a repair technique for a particular application, the 79 tolerable latency of the application has to be taken into account. 80 In the case of multimedia conferencing, the end-to-end delay has to 81 be at most a few hundred milliseconds in order to guarantee 82 interactivity, which usually excludes the use of retransmission. 84 However, in the case of multimedia streaming, the user can tolerate 85 an initial latency as part of the session set-up and thus an end-to- 86 end delay of several seconds may be acceptable. Retransmission may 87 thus be considered for such applications. 89 This document specifies a retransmission method for RTP applicable 90 to unicast and (small) multicast groups: it defines a payload format 91 for retransmitted RTP packets and provides protocol rules for the 92 sender and the receiver involved in retransmissions. 94 Furthermore, this retransmission payload format was designed for use 95 with the extended RTP profile for RTCP-based feedback, AVPF [1]. It 96 may also be used with other RTP profiles defined in the future. 98 The AVPF profile allows for more frequent feedback and for early 99 feedback. It defines a small number of general-purpose feedback 100 messages, e.g. ACKs and NACKs, as well as codec and application- 101 specific feedback messages. See [1] for details. 103 2. Terminology 105 The following terms are used in this document: 107 Original packet: refers to an RTP packet which carries user data 108 sent for the first time by an RTP sender. 110 Original stream: refers to the RTP stream of original packets. 112 Retransmission packet: refers to an RTP packet which is to be used 113 by the receiver instead of a lost original packet. Such a 114 retransmission packet is said to be associated with the original RTP 115 packet. 117 Retransmission request: a means by which an RTP receiver is able to 118 request that the RTP sender should send a retransmission packet for 119 a given original packet. Usually, an RTCP NACK packet as specified 120 in [1] is used as retransmission request for lost packets. 122 Retransmission stream: the stream of retransmission packets 123 associated with an original stream. 125 Session-multiplexing: scheme by which the original stream and the 126 associated retransmission stream are sent into two different RTP 127 sessions. 129 SSRC-multiplexing: scheme by which the original stream and the 130 retransmission stream are sent in the same RTP session with 131 different SSRC values. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [2]. 137 3. Requirements and design rationale for a retransmission scheme 139 The use of retransmissions in RTP as a repair method for streaming 140 media is appropriate in those scenarios with relaxed delay bounds 141 and where full reliability is not a requirement. More specifically, 142 RTP retransmission allows to trade-off reliability vs. delay, i.e. 143 the endpoints may give up retransmitting a lost packet after a given 144 buffering time has elapsed. Unlike TCP there is thus no head-of- 145 line blocking caused by RTP retransmissions. The implementer should 146 be aware that in cases where full reliability is required or higher 147 delay and jitter can be tolerated, TCP or other transport options 148 should be considered. 150 The RTP retransmission scheme defined in this document is designed 151 to fulfil the following set of requirements: 153 1. It must not break general RTP and RTCP mechanisms. 154 2. It must be suitable for unicast and small multicast groups. 155 3. It must work with mixers and translators. 156 4. It must work with all known payload types. 157 5. It must not prevent the use of multiple payload types in a 158 session. 159 6. In order to support the largest variety of payload formats, the 160 RTP receiver must be able to derive how many and which RTP 161 packets were lost as a result of a gap in received RTP sequence 162 numbers. This requirement is referred to as sequence number 163 preservation. Without such a requirement, it would be impossible 164 to use retransmission with payload formats, such as 165 conversational text [9] or most audio/video streaming 166 applications, that use the RTP sequence number to detect lost 167 packets. 169 When designing a solution for RTP retransmission, several approaches 170 may be considered for the multiplexing of the original RTP packets 171 and the retransmitted RTP packets. 173 One approach may be to retransmit the RTP packet with its original 174 sequence number and send original and retransmission packets in the 175 same RTP stream. The retransmission packet would then be identical 176 to the original RTP packet, i.e. the same header (and thus same 177 sequence number) and the same payload. However, such an approach is 178 not acceptable because it would corrupt the RTCP statistics. As a 179 consequence, requirement 1 would not be met. Correct RTCP 180 statistics require that for every RTP packet within the RTP stream, 181 the sequence number be increased by one. 183 Another approach may be to multiplex original RTP packets and 184 retransmission packets in the same RTP stream using different 185 payload type values. With such an approach, the original packets 186 and the retransmission packets would share the same sequence number 187 space. As a result, the RTP receiver would not be able to infer how 188 many and which original packets (which sequence numbers) were lost. 190 In other words, this approach does not satisfy the sequence number 191 preservation requirement (requirement 6). This in turn implies that 192 requirement 4 would not be met. Interoperability with mixers and 193 translators would also be more difficult if they did not understand 194 this new retransmission payload type in a sender RTP stream. For 195 these reasons, a solution based on payload type multiplexing of 196 original packets and retransmission packets in the same RTP stream 197 is excluded. 199 Finally, the original and retransmission packets may be sent in two 200 separate streams. These two streams may be multiplexed either by 201 sending them in two different sessions , i.e. session-multiplexing, 202 or in the same session using different SSRC values, i.e. SSRC- 203 multiplexing. Since original and retransmission packets carry media 204 of the same type, the objections in Section 5.2 of RTP [3] to RTP 205 multiplexing do not apply in this case. 207 Mixers and translators may process the original stream and simply 208 discard the retransmission stream if they are unable to utilise it. 209 Using two separate streams thus satisfies all the requirements 210 listed in this section. 212 3.1 Multiplexing scheme choice 214 Session-multiplexing and SSRC-multiplexing have different pros and 215 cons: 217 Session-multiplexing is based on sending the retransmission stream 218 in a different RTP session (as defined in RTP [3]) from that of the 219 original stream, i.e. the original and retransmission streams are 220 sent to different network addresses and/or port numbers. Having a 221 separate session allows more flexibility. In multicast, using two 222 separate sessions for the original and the retransmission streams 223 allows a receiver to choose whether or not to subscribe to the RTP 224 session carrying the retransmission stream. The original session 225 may also be single-source multicast while separate unicast sessions 226 are used to convey retransmissions to each of the receivers, which 227 as a result will receive only the retransmission packets they 228 request. 230 The use of separate sessions also facilitates differential treatment 231 by the network and may simplify processing in mixers, translators 232 and packet caches. 234 With SSRC-multiplexing, a single session is needed for the original 235 and the retransmission stream. This allows streaming servers and 236 middleware which are involved in a high number of concurrent 237 sessions to minimise their port usage. 239 This retransmission payload format allows both session-multiplexing 240 and SSRC-multiplexing for unicast sessions. From an implementation 241 point of view, there is little difference between the two 242 approaches. Hence, in order to maximise interoperability, both 243 multiplexing approaches SHOULD be supported by senders and 244 receivers. For multicast sessions, session-multiplexing MUST be 245 used because the association of the original stream and the 246 retransmission stream is problematic if SSRC-multiplexing is used 247 with multicast sessions(see Section 5.3 for motivation). 249 4. Retransmission payload format 251 The format of a retransmission packet is shown below: 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | RTP Header | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | OSN | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 258 | Original RTP Packet Payload | 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 The RTP header usage is as follows: 264 In the case of session-multiplexing, the same SSRC value MUST be 265 used for the original stream and the retransmission stream. In the 266 case of an SSRC collision in either the original session or the 267 retransmission session, the RTP specification requires that an RTCP 268 BYE packet MUST be sent in the session where the collision happened. 269 In addition, an RTCP BYE packet MUST also be sent for the associated 270 stream in its own session. After a new SSRC identifier is obtained, 271 the SSRC of both streams MUST be set to this value. 273 In the case of SSRC-multiplexing, two different SSRC values MUST be 274 used for the original stream and the retransmission stream as 275 required by RTP. If an SSRC collision is detected for either the 276 original stream or the retransmission stream, the RTP specification 277 requires that an RTCP BYE packet MUST be sent for this stream. No 278 RTCP BYE packet MUST be sent for the associated stream. Therefore, 279 only the stream that experienced SSRC collision will choose a new 280 SSRC value. Refer to Section 5.3 for the implications on the 281 original and retransmission stream SSRC association at the receiver. 283 For either multiplexing scheme, the sequence number has the standard 284 definition, i.e. it MUST be one higher than the sequence number of 285 the preceding packet sent in the retransmission stream. 287 The retransmission packet timestamp is set to the original 288 timestamp, i.e. to the timestamp of the original packet. As a 289 consequence, the initial RTP timestamp for the first packet of the 290 retransmission stream is not random but equal to the original 291 timestamp of the first packet that is retransmitted. See the 292 security considerations section in this document for security 293 implications. 295 Implementers have to be aware that the RTCP jitter value for the 296 retransmission stream does not reflect the actual network jitter 297 since there could be little correlation between the time a packet is 298 retransmitted and its original timestamp. 300 The payload type is dynamic. Each payload type of the original 301 stream MUST map to a different payload type value in the 302 retransmission stream. Therefore, when multiple payload types are 303 used in the original stream, multiple dynamic payload types will be 304 mapped to the retransmission payload format. See Section 8.1 for 305 the specification of how the mapping between original and 306 retransmission payload types is done with SDP. 308 As the retransmission packet timestamp carries the original media 309 timestamp, the timestamp clockrate used by the retransmission 310 payload type is the same as the one used by the associated original 311 payload type. It is thus possible to send retransmission packets 312 whose original payload types have different timestamp clockrates in 313 the same retransmission stream. Note that an RTP stream does not 314 usually carry payload types of different clockrates. 316 The payload of the RTP retransmission packet comprises the 317 retransmission payload header followed by the payload of the 318 original RTP packet. The length of the retransmission payload 319 header is 2 octets. This payload header contains only one field, 320 OSN, which MUST be set to the sequence number of the associated 321 original RTP packet. The original RTP packet payload, including any 322 possible payload headers specific to the original payload type, is 323 placed right after the retransmission payload header. 325 For payload types that support encoding at multiple rates, instead 326 of retransmitting the same payload as the original RTP packet the 327 sender MAY retransmit the same data encoded at a lower rate. This 328 aims at limiting the bandwidth usage of the retransmission stream. 330 When doing so, the sender MUST ensure that the receiver will still 331 be able to decode the payload of the already sent original packets 332 that might have been encoded based on the payload of the lost 333 original packet. In addition, if the sender chooses to retransmit 334 at a lower rate, the values in the payload header of the original 335 RTP packet may not longer apply to the retransmission packet and may 336 need to be modified in the retransmission packet to reflect the 337 change in rate. The sender should trade-off the decrease in 338 bandwidth usage with the decrease in quality caused by resending at 339 a lower rate. 341 If the original RTP header carried any profile-specific extensions, 342 the retransmission packet SHOULD include the same extensions 343 immediately following the fixed RTP header as expected by 344 applications running under this profile. In this case, the 345 retransmission payload header is thus placed after the profile- 346 specific extensions. 348 If the original RTP header carried an RTP header extension, the 349 retransmission packet SHOULD carry the same header extension. This 350 header extension MUST be placed right after the fixed RTP header, as 351 specified in RTP [3]. In this case, the retransmission payload 352 header is thus placed after the header extension. 354 If the original RTP packet contained RTP padding, that padding MUST 355 be removed before constructing the retransmission packet. If 356 padding of the retransmission packet is needed, padding is performed 357 as with any RTP packets and the padding bit is set. 359 The M, CC and CSRC bit of the original RTP header MUST remain 360 unchanged in the retransmission packet. 362 5. Association of a retransmission stream with its original stream 364 5.1 Retransmission session sharing 366 In the case of session-multiplexing, a retransmission session MUST 367 map to exactly one original session, i.e. the same retransmission 368 session cannot be used for different original sessions. 370 If retransmission session sharing were allowed, it would be a 371 problem for receivers, since they would receive retransmissions for 372 original sessions they might not have joined. For example, a 373 receiver wishing to receive only audio would receive also 374 retransmitted video packets if an audio and video session shared the 375 same retransmission session. 377 5.2 CNAME use 379 In both the session-multiplexing and the SSRC-multiplexing cases, a 380 sender MUST use the same CNAME for an original stream and its 381 associated retransmission stream. 383 5.3 Association at the receiver 385 A receiver receiving multiple original and retransmission streams 386 needs to associate each retransmission stream with its original 387 stream. The association is done differently depending on whether 388 session-multiplexing or SSRC-multiplexing is used. 390 If session-multiplexing is used, the receiver associates the two 391 streams having the same SSRC in the two sessions. Note that the 392 payload type field cannot be used to perform the association as 393 several media streams may have the same payload type value. The two 394 sessions are themselves associated out-of-band. See Section 8 for 395 how the grouping of the two sessions is done with SDP. 397 If SSRC-multiplexing is used, the receiver should first of all look 398 for two streams that have the same CNAME in the session. In some 399 cases, the CNAME may not be enough to determine the association as 400 multiple original streams in the same session may share the same 401 CNAME. For example, there can be in the same video session multiple 402 video streams mapping to different SSRCs and still using the same 403 CNAME and possibly the same PT values. Each (or some) of these 404 streams may have an associated retransmission stream. 406 In this case, in order to find out the association between original 407 and retransmission streams having the same CNAME, the receiver 408 SHOULD behave as follows. 410 The association can generally be resolved when the receiver receives 411 a retransmission packet matching a retransmission request which had 412 been sent earlier. Upon reception of a retransmission packet whose 413 original sequence number has been previously requested, the receiver 414 can derive that the SSRC of the retransmission packet is associated 415 to the sender SSRC from which the packet was requested. 417 However, this mechanism might fail if there are two outstanding 418 requests for the same packet sequence number in two different 419 original streams of the session. Note that since the initial packet 420 sequence numbers are random, the probability of having two 421 outstanding requests for the same packet sequence number would be 422 very small. Nevertheless, in order to avoid ambiguity in the 423 unicast case, the receiver MUST NOT have two outstanding requests 424 for the same packet sequence number in two different original 425 streams before the association is resolved. In multicast, this 426 ambiguity cannot be completely avoided, because another receiver may 427 have requested the same sequence number from another stream. 428 Therefore, SSRC-multiplexing MUST NOT be used in multicast sessions. 430 If the receiver discovers that two senders are using the same SSRC 431 or if it receives an RTCP BYE packet, it MUST stop requesting 432 retransmissions for that SSRC. Upon reception of original RTP 433 packets with a new SSRC, the receiver MUST perform the SSRC 434 association again as described in this section. 436 6. Use with the extended RTP profile for RTCP-based feedback 438 This section gives general hints for the usage of this payload 439 format with the extended RTP profile for RTCP-based feedback, 440 denoted AVPF [1]. Note that the general RTCP send and receive rules 441 and the RTCP packet format as specified in RTP apply, except for the 442 changes that the AVPF profile introduces. In short, the AVPF 443 profile relaxes the RTCP timing rules and specifies additional 444 general-purpose RTCP feedback messages. See [1] for details. 446 6.1 RTCP at the sender 448 In the case of session-multiplexing, Sender Report (SR) packets for 449 the original stream are sent in the original session and SR packets 450 for the retransmission stream are sent in the retransmission session 451 according to the rules of RTP. 453 In the case of SSRC-multiplexing, SR packets for both original and 454 retransmission streams are sent in the same session according to the 455 rules of RTP. The original and retransmission streams are seen, as 456 far the RTCP bandwidth calculation is concerned, as independent 457 senders belonging to the same RTP session and are thus equally 458 sharing the RTCP bandwidth assigned to senders. 460 Note that in both cases, session- and SSRC-multiplexing, BYE packets 461 MUST still be sent for both streams as specified in RTP. In other 462 words, it is not enough to send BYE packets for the original stream 463 only. 465 6.2 RTCP Receiver Reports 467 In the case of session-multiplexing, the receiver will send report 468 blocks for the original stream and the retransmission stream in 469 separate Receiver Report (RR) packets belonging to separate RTP 470 sessions. RR packets reporting on the original stream are sent in 471 the original RTP session while RR packets reporting on the 472 retransmission stream are sent in the retransmission session. The 473 RTCP bandwidth for these two sessions may be chosen independently 474 (for example through RTCP bandwidth modifiers [4]). 476 In the case of SSRC-multiplexing, the receiver sends report blocks 477 for the original and the retransmission streams in the same RR 478 packet since there is a single session. 480 6.3 Retransmission requests 482 The NACK feedback message format defined in the AVPF profile SHOULD 483 be used by receivers to send retransmission requests. Whether a 484 receiver chooses to request a packet or not is an implementation 485 issue. An actual receiver implementation should take into account 486 such factors as the tolerable application delay, the network 487 environment and the media type. 489 The receiver should generally assess whether the retransmitted 490 packet would still be useful at the time it is received. The 491 timestamp of the missing packet can be estimated from the timestamps 492 of packets preceding and/or following the sequence number gap caused 493 by the missing packet in the original stream. In most cases, some 494 form of linear estimate of the timestamp is good enough. 496 Furthermore, a receiver should compute an estimate of the round-trip 497 time (RTT) to the sender. This can be done, for example, by 498 measuring the retransmission delay to receive a retransmission 499 packet after a NACK has been sent for that packet. This estimate 500 may also be obtained from past observations, RTCP report round-trip 501 time if available or any other means. A standard mechanism for the 502 receiver to estimate the RTT is specified in RTP Extended Reports 503 [11]. 505 The receiver should not send a retransmission request as soon as it 506 detects a missing sequence number but should add some extra delay to 507 compensate for packet reordering. This extra delay may, for 508 example, be based on past observations of the experienced packet 509 reordering. 511 To increase the robustness to the loss of a NACK or of a 512 retransmission packet, a receiver may send a new NACK for the same 513 packet. This is referred to as multiple retransmissions. Before 514 sending a new NACK for a missing packet, the receiver should rely on 515 a timer to be reasonably sure that the previous retransmission 516 attempt has failed in order to avoid unnecessary retransmissions. 518 NACKs MUST be sent only for the original RTP stream. Otherwise, if 519 a receiver wanted to perform multiple retransmissions by sending a 520 NACK in the retransmission stream, it would not be able to know the 521 original sequence number and a timestamp estimation of the packet it 522 requests. 524 6.4 Timing rules 526 The NACK feedback message may be sent in a regular full compound 527 RTCP packet or in an early RTCP packet, as per AVPF [1]. Sending a 528 NACK in an early packet allows to react more quickly to a given 529 packet loss. However, in that case if a new packet loss occurs 530 right after the early RTCP packet was sent, the receiver will then 531 have to wait for the next regular RTCP compound packet after the 532 early packet. Sending NACKs only in regular RTCP compound decreases 533 the maximum delay between detecting an original packet loss and 534 being able to send a NACK for that packet. Implementers should 535 consider the possible implications of this fact for the application 536 being used. 538 Furthermore, receivers may make use of the minimum interval between 539 regular RTCP compound packets. This interval can be used to keep 540 regular receiver reporting down to a minimum, while still allowing 541 receivers to send early RTCP packets during periods requiring more 542 frequent feedback, e.g. times of higher packet loss rate.. Note 543 that although RTCP packets may be suppressed because they do not 544 contain NACKs, the same RTCP bandwidth as if they were sent needs to 545 be available. See AVPF [1] for details on the use of the minimum 546 interval. 548 7. Congestion control 550 RTP retransmission poses a risk of increasing network congestion. 551 In a best-effort environment, packet loss is caused by congestion. 552 Reacting to loss by retransmission of older data without decreasing 553 the rate of the original stream would thus further increase 554 congestion. Implementations SHOULD follow the recommendations below 555 in order to use retransmission. 557 The RTP profile under which the retransmission scheme is used 558 defines an appropriate congestion control mechanism in different 559 environments. Following the rules under the profile, an RTP 560 application can determine its acceptable bitrate and packet rate in 561 order to be fair to other TCP or RTP flows. 563 If an RTP application uses retransmission, the acceptable packet 564 rate and bitrate includes both the original and retransmitted data. 565 This guarantees that an application using retransmission achieves 566 the same fairness as one that does not. Such a rule would translate 567 in practice into the following actions: 569 If enhanced service is used, it should be made sure that the total 570 bitrate and packet rate do not exceed that of the requested service. 571 It should be further monitored that the requested services are 572 actually delivered. In a best-effort environment, the sender SHOULD 573 NOT send retransmission packets without reducing the packet rate and 574 bitrate of the original stream (for example by encoding the data at 575 a lower rate). 577 In addition, the sender MAY selectively retransmit only the packets 578 that it deems important and ignore NACK messages for other packets 579 in order to limit the bitrate. 581 These congestion control mechanisms should keep the packet loss rate 582 within acceptable parameters. Packet loss is considered acceptable 583 if a TCP flow across the same network path and experiencing the same 584 network conditions would achieve, on a reasonable timescale, an 585 average throughput, that is not less than the one the RTP flow 586 achieves. If the packet loss rate exceeds an acceptable level, it 587 should be concluded that congestion is not kept under control and 588 retransmission should then not be used. It may further be necessary 589 to adapt the transmission rate (or the number of layers subscribed 590 for a layered multicast session), or to arrange for the receiver to 591 leave the session. 593 8. Retransmission Payload Format MIME type registration 595 8.1 Introduction 597 The following MIME subtype name and parameters are introduced in 598 this document: "rtx", "rtx-time" and "apt". 600 The binding used for the retransmission stream to the payload type 601 number is indicated by an rtpmap attribute. The MIME subtype name 602 used in the binding is "rtx". 604 The "apt" (associated payload type) parameter MUST be used to map 605 the retransmission payload type to the associated original stream 606 payload type. If multiple payload types are used for the original 607 streams, then multiple "apt" parameters MUST be included to map each 608 original stream payload type to a different retransmission payload 609 type. 611 An OPTIONAL payload-format-specific parameter, "rtx-time," indicates 612 the maximum time a server will try to retransmit a packet. 614 The syntax is as follows: 616 a=fmtp: apt=;rtx-time= 617 where, 619 : indicates the dynamic payload type number assigned to 620 the retransmission payload format in an rtpmap attribute. 622 : the value of the original stream payload type to 623 which this retransmission stream payload type is associated. 625 : indicates the time in milliseconds, measured 626 from the time a packet was first sent until the time the server 627 will stop trying to retransmit the packet. The absence of the 628 rtx-time parameter for a retransmission stream means that the 629 maximum retransmission time is not defined, but MAY be 630 negotiated by other means. 632 8.2 Registration of audio/rtx 634 MIME type: audio 636 MIME subtype: rtx 638 Required parameters: 640 rate: the RTP timestamp clockrate is equal to the RTP timestamp 641 clockrate of the media that is retransmitted. 643 apt: associated payload type. The value of this parameter is 644 the payload type of the associated original stream. 646 Optional parameters: 648 rtx-time: indicates the time in milliseconds, measured from the 649 time a packet was first sent until the time the server will 650 stop trying to retransmit the packet. 652 Encoding considerations: this type is only defined for transfer via 653 RTP. 655 Security considerations: see Section 12 of RFC XXXX 657 Interoperability considerations: none 659 Published specification: RFC XXXX 661 Applications which use this media type: multimedia streaming 662 applications 664 Additional information: none 666 Person & email address to contact for further information: 667 rey@panasonic.de 668 david.leon@nokia.com 669 avt@ietf.org 671 Intended usage: COMMON 673 Author/Change controller: 674 Jose Rey 675 David Leon 676 IETF AVT WG 678 8.3 Registration of video/rtx 680 MIME type: video 682 MIME subtype: rtx 684 Required parameters: 686 rate: the RTP timestamp clockrate is equal to the RTP timestamp 687 clockrate of the media that is retransmitted. 689 apt: associated payload type. The value of this parameter is 690 the payload type of the associated original stream. 692 Optional parameters: 694 rtx-time: indicates the time in milliseconds, measured from the 695 time a packet was first sent until the time the server will 696 stop trying to retransmit the packet. 698 Encoding considerations: this type is only defined for transfer via 699 RTP. 701 Security considerations: see Section 12 of RFC XXXX 703 Interoperability considerations: none 705 Published specification: RFC XXXX 707 Applications which use this media type: multimedia streaming 708 applications 710 Additional information: none 712 Person & email address to contact for further information: 713 rey@panasonic.de 714 david.leon@nokia.com 715 avt@ietf.org 717 Intended usage: COMMON 719 Author/Change controller: 720 Jose Rey 721 David Leon 722 IETF AVT WG 724 8.4 Registration of text/rtx 726 MIME type: text 728 MIME subtype: rtx 730 Required parameters: 732 rate: the RTP timestamp clockrate is equal to the RTP timestamp 733 clockrate of the media that is retransmitted. 735 apt: associated payload type. The value of this parameter is 736 the payload type of the associated original stream. 738 Optional parameters: 740 rtx-time: indicates the time in milliseconds, measured from the 741 time a packet was first sent until the time the server will 742 stop trying to retransmit the packet. 744 Encoding considerations: this type is only defined for transfer via 745 RTP. 747 Security considerations: see Section 12 of RFC XXXX 749 Interoperability considerations: none 751 Published specification: RFC XXXX 753 Applications which use this media type: multimedia streaming 754 applications 756 Additional information: none 758 Person & email address to contact for further information: 759 rey@panasonic.de 760 david.leon@nokia.com 761 avt@ietf.org 763 Intended usage: COMMON 765 Author/Change controller: 766 Jose Rey 767 David Leon 768 IETF AVT WG 770 8.5 Registration of application/rtx 772 MIME type: application 774 MIME subtype: rtx 776 Required parameters: 778 rate: the RTP timestamp clockrate is equal to the RTP timestamp 779 clockrate of the media that is retransmitted. 781 apt: associated payload type. The value of this parameter is 782 the payload type of the associated original stream. 784 Optional parameters: 786 rtx-time: indicates the time in milliseconds, measured from the 787 time a packet was first sent until the time the server will 788 stop trying to retransmit the packet. 790 Encoding considerations: this type is only defined for transfer via 791 RTP. 793 Security considerations: see Section 12 of RFC XXXX 795 Interoperability considerations: none 796 Published specification: RFC XXXX 798 Applications which use this media type: multimedia streaming 799 applications 801 Additional information: none 803 Person & email address to contact for further information: 804 rey@panasonic.de 805 david.leon@nokia.com 806 avt@ietf.org 808 Intended usage: COMMON 810 Author/Change controller: 811 Jose Rey 812 David Leon 813 IETF AVT WG 815 8.6 Mapping to SDP 817 The information carried in the MIME media type specification has a 818 specific mapping to fields in SDP [5], which is commonly used to 819 describe RTP sessions. When SDP is used to specify retransmissions 820 for an RTP stream, the mapping is done as follows: 822 - The MIME types ("video"), ("audio") and ("text") go in the SDP 823 "m=" as the media name. 825 - The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding 826 name. The RTP clock rate in "a=rtpmap" MUST be that of the 827 retransmission payload type. See Section 4 for details on this. 829 - The AVPF profile-specific parameters "ack" and "nack" go in SDP 830 "a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types of 831 feedback. See the AVPF profile [1] for details. 833 - The retransmission payload-format-specific parameters "apt" and 834 "rtx-time" go in the SDP "a=fmtp" as a semicolon separated list of 835 parameter=value pairs. 837 - Any remaining parameters go in the SDP "a=fmtp" attribute by 838 copying them directly from the MIME media type string as a semicolon 839 separated list of parameter=value pairs. 841 In the following sections some example SDP descriptions are 842 presented. 844 8.7 SDP description with session-multiplexing 846 In the case of session-multiplexing, the SDP description contains 847 one media specification "m" line per RTP session. The SDP MUST 848 provide the grouping of the original and associated retransmission 849 sessions' "m" lines, using the Flow Identification (FID) semantics 850 defined in RFC 3388 [6]. 852 The following example specifies two original, AMR and MPEG-4, 853 streams on ports 49170 and 49174 and their corresponding 854 retransmission streams on ports 49172 and 49176, respectively: 856 v=0 857 o=mascha 2980675221 2980675778 IN IP4 at.home.ru 858 c=IN IP4 125.25.5.1 859 a=group:FID 1 2 860 a=group:FID 3 4 861 m=audio 49170 RTP/AVPF 96 862 a=rtpmap:96 AMR/8000 863 a=fmtp:96 octet-align=1 864 a=rtcp-fb:96 nack 865 a=mid:1 866 m=audio 49172 RTP/AVPF 97 867 a=rtpmap:97 rtx/8000 868 a=fmtp:97 apt=96;rtx-time=3000 869 a=mid:2 870 m=video 49174 RTP/AVPF 98 871 a=rtpmap:98 MP4V-ES/90000 872 a=rtcp-fb:98 nack 873 a=fmtp:98 profile-level-id=8;config=01010000012000884006682C2090A21F 874 a=mid:3 875 m=video 49176 RTP/AVPF 99 876 a=rtpmap:99 rtx/90000 877 a=fmtp:99 apt=98;rtx-time=3000 878 a=mid:4 880 A special case of the SDP description is a description that contains 881 only one original session "m" line and one retransmission session 882 "m" line, the grouping is then obvious and FID semantics MAY be 883 omitted in this special case only. 885 This is illustrated in the following example, which is an SDP 886 description for a single original MPEG-4 stream and its 887 corresponding retransmission session: 889 v=0 890 o=mascha 2980675221 2980675778 IN IP4 at.home.ru 891 c=IN IP4 125.25.5.1 892 m=video 49170 RTP/AVPF 96 893 a=rtpmap:96 MP4V-ES/90000 894 a=rtcp-fb:96 nack 895 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F 896 m=video 49172 RTP/AVPF 97 897 a=rtpmap:97 rtx/90000 898 a=fmtp:97 apt=96;rtx-time=3000 900 8.8 SDP description with SSRC-multiplexing 902 The following is an example of an SDP description for an RTP video 903 session using SSRC-multiplexing with similar parameters as in the 904 single-session example above: 906 v=0 907 o=mascha 2980675221 2980675778 IN IP4 at.home.ru 908 c=IN IP4 125.25.5.1 909 m=video 49170 RTP/AVPF 96 97 910 a=rtpmap:96 MP4V-ES/90000 911 a=rtcp-fb:96 nack 912 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F 913 a=rtpmap:97 rtx/90000 914 a=fmtp:97 apt=96;rtx-time=3000 916 9. RTSP considerations 918 The Real-time Streaming Protocol (RTSP), RFC 2326 [7] is an 919 application-level protocol for control over the delivery of data 920 with real-time properties. This section looks at the issues 921 involved in controlling RTP sessions that use retransmissions. 923 9.1 RTSP control with SSRC-multiplexing 925 In the case of SSRC-multiplexing, the "m" line includes both 926 original and retransmission payload types and has a single RTSP 927 "control" attribute. The receiver uses the "m" line to request 928 SETUP and TEARDOWN of the whole media session. The RTP profile 929 contained in the transport header MUST be the AVPF profile or 930 another suitable profile allowing extended feedback. 932 In order to control the sending of the session original media 933 stream, the receiver sends as usual PLAY and PAUSE requests to the 934 sender for the session. The RTP-info header that is used to set 935 RTP-specific parameters in the PLAY response MUST be set according 936 to the RTP information of the original stream. 938 When the receiver starts receiving the original stream, it can then 939 request retransmission through RTCP NACKs without additional RTSP 940 signalling. 942 9.2 RTSP control with session-multiplexing 944 In the case of session-multiplexing, each SDP "m" line has an RTSP 945 "control" attribute. Hence, when retransmission is used, both the 946 original session and the retransmission have their own "control" 947 attributes. The receiver can associate the original session and the 948 retransmission session through the FID semantics as specified in 949 Section 8. 951 The original and the retransmission streams are set up and torn down 952 separately through their respective media "control" attribute. The 953 RTP profile contained in the transport header MUST be the AVPF 954 profile or another suitable profile allowing extended feedback for 955 both the original and the retransmission session. 957 The RTSP presentation SHOULD support aggregate control and SHOULD 958 contain a session level RTSP URL. The receiver SHOULD use aggregate 959 control for an original session and its associated retransmission 960 session. Otherwise, there would need to be two different 'session- 961 id' values, i.e. different values for the original and 962 retransmission sessions, and the sender would not know how to 963 associate them. 965 The session-level "control" attribute is then used as usual to 966 control the playing of the original stream. When the receiver 967 starts receiving the original stream, it can then request 968 retransmissions through RTCP without additional RTSP signalling. 970 9.3 RTSP control of the retransmission stream 972 Because of the nature of retransmissions, the sending of 973 retransmission packets SHOULD NOT be controlled through RTSP PLAY 974 and PAUSE requests. The PLAY and PAUSE requests should not affect 975 the retransmission stream. Retransmission packets are sent upon 976 receiver requests in the original RTCP stream, regardless of the 977 state. 979 9.4 Cache control 981 Retransmission streams SHOULD NOT be cached. 983 In the case of session-multiplexing, the "Cache-Control" header 984 SHOULD be set to "no-cache" for the retransmission stream. 986 In the case of SSRC-multiplexing, RTSP cannot specify independent 987 caching for the retransmission stream, because there is a single "m" 988 line in SDP. Therefore, the implementer should take this fact into 989 account when deciding whether to cache an SSRC-multiplexed session 990 or not. 992 10. Implementation examples 994 This document mandates only the sender and receiver behaviours that 995 are necessary for interoperability. In addition, certain algorithms, 996 such as rate control or buffer management when targeted at specific 997 environments, may enhance the retransmission efficiency. 999 This section gives an overview of different implementation options 1000 allowed within this specification. 1002 The first example describes a minimal receiver implementation. With 1003 this implementation, it is possible to retransmit lost RTP packets, 1004 detect efficiently the loss of retransmissions and perform multiple 1005 retransmissions, if needed. Most of the necessary processing is done 1006 at the server. 1008 The second example shows how a receiver may implement additional 1009 enhancements that might help reduce sender buffer requirements and 1010 optimise the retransmission efficiency 1012 The third example shows how retransmissions may be used in (small) 1013 multicast groups in conjunction with layered encoding. It 1014 illustrates that retransmissions and layered encoding may be 1015 complementary techniques. 1017 10.1 A minimal receiver implementation example 1019 This section gives an example of an implementation supporting 1020 multiple retransmissions. The sender transmits the original data in 1021 RTP packets using the MPEG-4 video RTP payload format. 1022 It is assumed that NACK feedback messages are used, as per 1023 [1]. An SDP description example with SSRC-multiplexing is given 1024 below: 1026 v=0 1027 o=mascha 2980675221 2980675778 IN IP4 at.home.ru 1028 c=IN IP4 125.25.5.1 1029 m=video 49170 RTP/AVPF 96 97 1030 a=rtpmap:96 MP4V-ES/90000 1031 a=rtcp-fb:96 nack 1032 a=rtpmap:97 rtx/90000 1033 a=fmtp:97 apt=96;rtx-time=3000 1035 The format-specific parameter "rtx-time" indicates that the server 1036 will buffer the sent packets in a retransmission buffer for 3.0 1037 seconds, after which the packets are deleted from the retransmission 1038 buffer and will never be sent again. 1040 In this implementation example, the required RTP receiver processing 1041 to handle retransmission is kept to a minimum. The receiver detects 1042 packet loss from the gaps observed in the received sequence numbers. 1043 It signals lost packets to the sender through NACKs as defined in the 1044 AVPF profile [1]. The receiver should take into account the 1045 signalled sender retransmission buffer length in order to dimension 1046 its own reception buffer. It should also derive from the buffer 1047 length the maximum number of times the retransmission of a packet can 1048 be requested. 1050 The sender should retransmit the packets selectively, i.e. it should 1051 choose whether to retransmit a requested packet depending on the 1052 packet importance, the observed QoS and congestion state of the 1053 network connection to the receiver. Obviously, the sender processing 1054 increases with the number of receivers as state information and 1055 processing load must be allocated to each receiver. 1057 10.2 An enhanced receiver implementation example 1059 The receiver may have more accurate information than the sender about 1060 the current network QoS such as available bandwidth, packet loss 1061 rate, delay and jitter. In addition, other receiver-specific 1062 parameters such as buffer level, estimated importance of the lost 1063 packet and application level QoS may be used by the receiver to make 1064 a more efficient use of RTP retransmission by selectively sending 1065 NACKs for important lost packets and not for others. For example, a 1066 receiver may decide to suppress a request for a packet loss that 1067 could be concealed locally, or for a retransmission that would arrive 1068 late. 1070 Furthermore, a receiver may acknowledge the received packets. This 1071 can be done by sending ACKs, as per [1]. Upon receiving an ACK, the 1072 sender may delete all the acknowledged packets from its 1073 retransmission buffer. Note that this would also require only 1074 limited increase in the required RTCP bandwidth as long as ACK 1075 packets are sent seldom enough. 1077 This implementation may help reduce buffer requirements at the sender 1078 and optimise the performance of the implementation by using selective 1079 requests. 1081 Note that these receiver enhancements do not need to be negotiated as 1082 they do not affect the sender implementation. However, in order to 1083 allow the receiver to acknowledge packets, it is needed to allow the 1084 use of ACKs in the SDP description, by means of an additional SDP 1085 "a=rtcp-fb" line, as follows: 1087 v=0 1088 o=mascha 2980675221 2980675778 IN IP4 at.home.ru 1089 c=IN IP4 125.25.5.1 1090 m=video 49170 RTP/AVPF 96 97 1091 a=rtpmap:96 MP4V-ES/90000 1092 a=rtcp-fb:96 nack 1093 a=rtcp-fb:96 ack 1094 a=rtpmap:97 rtx/90000 1095 a=fmtp:97 apt=96;rtx-time=3000 1097 10.3 Retransmission of Layered Encoded Media in Multicast 1099 This section shows how to combine retransmissions with layered 1100 encoding in multicast sessions. Note that the retransmission 1101 framework is not intended as a complete solution to reliable 1102 multicast. Refer to RFC 2887 [10], for an overview of the problems 1103 related with reliable multicast transmission. 1105 Packets of different importance are sent in different RTP sessions. 1106 The retransmission streams corresponding to the different layers can 1107 themselves be seen as different retransmission layers. The relative 1108 importance of the different retransmission streams should reflect the 1109 relative importance of the different original streams. 1111 In multicast, SSRC-multiplexing of the original and retransmission 1112 streams is not allowed as per Section 5.3 of this document. For this 1113 reason, the retransmission stream(s) MUST be sent in different RTP 1114 session(s) using session-multiplexing. 1116 An SDP description example of multicast retransmissions for layered 1117 encoded media is given below: 1119 c=IN IP4 224.2.1.1/127/3 1120 m=video 8000 RTP/AVPF 98 1121 a=rtpmap:98 MP4V-ES/90000 1122 a=rtcp-fb:98 nack 1123 c=IN IP4 224.2.1.4/127/3 1124 m=video 8000 RTP/AVPF 99 1125 a=rtpmap:99 rtx/90000 1126 a=fmtp:99 apt=98;rtx-time=3000 1128 The server and the receiver may implement the retransmission methods 1129 illustrated in the previous examples. In addition, they may choose 1130 to request and retransmit a lost packet depending on the layer it 1131 belongs to. 1133 11. IANA considerations 1135 A new MIME subtype name, "rtx", has been registered. An additional 1136 REQUIRED parameter, "apt", and an OPTIONAL parameter, "rtx-time", 1137 are defined. See Section 8 for details. 1139 12. Security considerations 1141 Applications utilising encryption SHOULD encrypt both the original 1142 and the retransmission stream. Old keys will likely need to be 1143 cached so that when the keys change for the original stream, the old 1144 key is used until it is determined that the key has changed on the 1145 retransmission packets as well. 1147 The use of the same key for the retransmitted stream and the 1148 original stream may lead to security problems, e.g. two-time pads. 1149 This sharing has to be evaluated towards the chosen security 1150 protocol and security algorithms. 1152 RTP recommends that the initial RTP timestamp SHOULD be random to 1153 secure the stream against known plain text attacks. This payload 1154 format does not follow this recommendation as the initial timestamp 1155 will be the media timestamp of the first retransmitted packet. 1157 However, since the initial timestamp of the original stream is 1158 itself random, if the original stream is encrypted, the first 1159 retransmitted packet timestamp would also be random to an attacker. 1160 Therefore, confidentiality would not be compromised. 1162 Congestion control considerations with the use of retransmission are 1163 dealt with in Section 7 of this document. 1165 Any other security considerations of the profile under which the 1166 retransmission scheme is used should be applied. The retransmission 1167 payload format MUST NOT be used under the SAVP profile defined by 1168 the Secure Real-Time Transport Protocol (SRTP)[12] but instead an 1169 extension of SRTP should be defined to secure the AVPF profile. The 1170 definition of such a profile is out of the scope of this document. 1172 13. Acknowledgements 1174 We would like to express our gratitude to Carsten Burmeister for his 1175 participation in the development of this document. Our thanks also 1176 go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus Westerlund, 1177 Go Hori and Rahul Agarwal for their helpful comments. 1179 14. References 1181 14.1 Normative References 1183 1 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP 1184 profile for RTCP-based feedback", draft-ietf-avt-rtcp-feedback- 1185 04.txt, September 2002. 1187 2 S. Bradner, "Key words for use in RFCs to Indicate Requirement 1188 Levels", BCP 14, RFC 2119, March 1997 1190 3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A 1191 Transport Protocol for Real-Time Applications", draft-ietf-avt- 1192 rtp-new-11.txt, May 2002. 1194 4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", draft- 1195 ietf-avt-rtcp-bw-05.txt, May 2002. 1197 5 M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 1198 2327, April 1998. 1200 6 G. Camarillo, J. Holler, G. AP. Eriksson, "Grouping of media lines 1201 in the Session Description Protocol (SDP)", RFC 3388, December 1202 2002. 1204 7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol 1205 (RTSP)", RFC 2326, April 1998. 1207 14.2 Informative References 1209 8 C. Perkins, O. Hodson, "Options for Repair of Streaming Media", 1210 RFC 2354, June 1998. 1212 9 G. Hellstrom, "RTP for conversational text", RFC 2793, May 2000 1214 10 M. Handley, et al., "The Reliable Multicast Design Space for Bulk 1215 Data Transfer", RFC 2887, August 2000. 1217 11 Friedman, et. al., "RTP Extended Reports", Work in Progress. 1219 12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. 1220 Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", 1221 draft-ietf-avt-srtp-05.txt, June 2002. 1223 Author's Addresses 1225 Jose Rey rey@panasonic.de 1226 Panasonic European Laboratories GmbH 1227 Monzastr. 4c 1228 D-63225 Langen, Germany 1229 Phone: +49-6103-766-134 1230 Fax: +49-6103-766-166 1232 David Leon david.leon@nokia.com 1233 Nokia Research Center 1234 6000 Connection Drive 1235 Irving, TX. USA 1236 Phone: 1-972-374-1860 1238 Akihiro Miyazaki akihiro@isl.mei.co.jp 1239 Core Software Development Center 1240 Corporate Software Development Division 1241 Matsushita Electric Industrial Co., Ltd. 1242 1006 Kadoma, Kadoma City, Osaka 571-8501, Japan 1243 Phone: +81-6-6900-9192 1244 Fax: +81-6-6900-9193 1246 Viktor Varsa viktor.varsa@nokia.com 1247 Nokia Research Center 1248 6000 Connection Drive 1249 Irving, TX. USA 1250 Phone: 1-972-374-1861 1252 Rolf Hakenberg hakenberg@panasonic.de 1253 Panasonic European Laboratories GmbH 1254 Monzastr. 4c 1255 D-63225 Langen, Germany 1256 Phone: +49-6103-766-162 1257 Fax: +49-6103-766-166 1258 Full Copyright Statement 1260 "Copyright (C) The Internet Society (date). All Rights Reserved. 1262 This document and translations of it may be copied and furnished to 1263 others, and derivative works that comment on or otherwise explain it 1264 or assist in its implementation may be prepared, copied, published 1265 and distributed, in whole or in part, without restriction of any 1266 kind, provided that the above copyright notice and this paragraph are 1267 included on all such copies and derivative works. However, this 1268 document itself may not be modified in any way, such as by removing 1269 the copyright notice or references to the Internet Society or other 1270 Internet organizations, except as needed for the purpose of 1271 developing Internet standards in which case the procedures for 1272 copyrights defined in the Internet Standards process must be 1273 followed, or as required to translate it into languages other than 1274 English. 1276 The limited permissions granted above are perpetual and will 1277 not be revoked by the Internet Society or its successors or 1278 assigns. 1280 This document and the information contained herein is provided on an 1281 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1282 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1283 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1284 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1285 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."