idnits 2.17.1 draft-ietf-avt-rtp-retransmission-06.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. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1074 has weird spacing: '... sender may ...' == Line 1301 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 7713 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 77 looks like a reference -- Missing reference section? '1' on line 1073 looks like a reference -- Missing reference section? '2' on line 138 looks like a reference -- Missing reference section? '9' on line 167 looks like a reference -- Missing reference section? '3' on line 353 looks like a reference -- Missing reference section? '4' on line 476 looks like a reference -- Missing reference section? '11' on line 505 looks like a reference -- Missing reference section? '5' on line 820 looks like a reference -- Missing reference section? '6' on line 852 looks like a reference -- Missing reference section? '7' on line 920 looks like a reference -- Missing reference section? '10' on line 1104 looks like a reference -- Missing reference section? '12' on line 1173 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft 3 draft-ietf-avt-rtp-retransmission-06.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 69 15. IPR Notices...................................................26 70 16. Full Copyright Statement......................................26 72 1. Introduction 74 Packet losses between an RTP sender and receiver may significantly 75 degrade the quality of the received media. Several techniques, such 76 as forward error correction (FEC), retransmissions or interleaving 77 may be considered to increase packet loss resiliency. RFC 2354 [8] 78 discusses the different options. 80 When choosing a repair technique for a particular application, the 81 tolerable latency of the application has to be taken into account. 82 In the case of multimedia conferencing, the end-to-end delay has to 83 be at most a few hundred milliseconds in order to guarantee 84 interactivity, which usually excludes the use of retransmission. 86 However, in the case of multimedia streaming, the user can tolerate 87 an initial latency as part of the session set-up and thus an end-to- 88 end delay of several seconds may be acceptable. Retransmission may 89 thus be considered for such applications. 91 This document specifies a retransmission method for RTP applicable 92 to unicast and (small) multicast groups: it defines a payload format 93 for retransmitted RTP packets and provides protocol rules for the 94 sender and the receiver involved in retransmissions. 96 Furthermore, this retransmission payload format was designed for use 97 with the extended RTP profile for RTCP-based feedback, AVPF [1]. It 98 may also be used with other RTP profiles defined in the future. 100 The AVPF profile allows for more frequent feedback and for early 101 feedback. It defines a small number of general-purpose feedback 102 messages, e.g. ACKs and NACKs, as well as codec and application- 103 specific feedback messages. See [1] for details. 105 2. Terminology 107 The following terms are used in this document: 109 Original packet: refers to an RTP packet which carries user data 110 sent for the first time by an RTP sender. 112 Original stream: refers to the RTP stream of original packets. 114 Retransmission packet: refers to an RTP packet which is to be used 115 by the receiver instead of a lost original packet. Such a 116 retransmission packet is said to be associated with the original RTP 117 packet. 119 Retransmission request: a means by which an RTP receiver is able to 120 request that the RTP sender should send a retransmission packet for 121 a given original packet. Usually, an RTCP NACK packet as specified 122 in [1] is used as retransmission request for lost packets. 124 Retransmission stream: the stream of retransmission packets 125 associated with an original stream. 127 Session-multiplexing: scheme by which the original stream and the 128 associated retransmission stream are sent into two different RTP 129 sessions. 131 SSRC-multiplexing: scheme by which the original stream and the 132 retransmission stream are sent in the same RTP session with 133 different SSRC values. 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [2]. 139 3. Requirements and design rationale for a retransmission scheme 141 The use of retransmissions in RTP as a repair method for streaming 142 media is appropriate in those scenarios with relaxed delay bounds 143 and where full reliability is not a requirement. More specifically, 144 RTP retransmission allows to trade-off reliability vs. delay, i.e. 145 the endpoints may give up retransmitting a lost packet after a given 146 buffering time has elapsed. Unlike TCP there is thus no head-of- 147 line blocking caused by RTP retransmissions. The implementer should 148 be aware that in cases where full reliability is required or higher 149 delay and jitter can be tolerated, TCP or other transport options 150 should be considered. 152 The RTP retransmission scheme defined in this document is designed 153 to fulfil the following set of requirements: 155 1. It must not break general RTP and RTCP mechanisms. 156 2. It must be suitable for unicast and small multicast groups. 157 3. It must work with mixers and translators. 158 4. It must work with all known payload types. 159 5. It must not prevent the use of multiple payload types in a 160 session. 161 6. In order to support the largest variety of payload formats, the 162 RTP receiver must be able to derive how many and which RTP 163 packets were lost as a result of a gap in received RTP sequence 164 numbers. This requirement is referred to as sequence number 165 preservation. Without such a requirement, it would be impossible 166 to use retransmission with payload formats, such as 167 conversational text [9] or most audio/video streaming 168 applications, that use the RTP sequence number to detect lost 169 packets. 171 When designing a solution for RTP retransmission, several approaches 172 may be considered for the multiplexing of the original RTP packets 173 and the retransmitted RTP packets. 175 One approach may be to retransmit the RTP packet with its original 176 sequence number and send original and retransmission packets in the 177 same RTP stream. The retransmission packet would then be identical 178 to the original RTP packet, i.e. the same header (and thus same 179 sequence number) and the same payload. However, such an approach is 180 not acceptable because it would corrupt the RTCP statistics. As a 181 consequence, requirement 1 would not be met. Correct RTCP 182 statistics require that for every RTP packet within the RTP stream, 183 the sequence number be increased by one. 185 Another approach may be to multiplex original RTP packets and 186 retransmission packets in the same RTP stream using different 187 payload type values. With such an approach, the original packets 188 and the retransmission packets would share the same sequence number 189 space. As a result, the RTP receiver would not be able to infer how 190 many and which original packets (which sequence numbers) were lost. 192 In other words, this approach does not satisfy the sequence number 193 preservation requirement (requirement 6). This in turn implies that 194 requirement 4 would not be met. Interoperability with mixers and 195 translators would also be more difficult if they did not understand 196 this new retransmission payload type in a sender RTP stream. For 197 these reasons, a solution based on payload type multiplexing of 198 original packets and retransmission packets in the same RTP stream 199 is excluded. 201 Finally, the original and retransmission packets may be sent in two 202 separate streams. These two streams may be multiplexed either by 203 sending them in two different sessions , i.e. session-multiplexing, 204 or in the same session using different SSRC values, i.e. SSRC- 205 multiplexing. Since original and retransmission packets carry media 206 of the same type, the objections in Section 5.2 of RTP [3] to RTP 207 multiplexing do not apply in this case. 209 Mixers and translators may process the original stream and simply 210 discard the retransmission stream if they are unable to utilise it. 211 Using two separate streams thus satisfies all the requirements 212 listed in this section. 214 3.1 Multiplexing scheme choice 216 Session-multiplexing and SSRC-multiplexing have different pros and 217 cons: 219 Session-multiplexing is based on sending the retransmission stream 220 in a different RTP session (as defined in RTP [3]) from that of the 221 original stream, i.e. the original and retransmission streams are 222 sent to different network addresses and/or port numbers. Having a 223 separate session allows more flexibility. In multicast, using two 224 separate sessions for the original and the retransmission streams 225 allows a receiver to choose whether or not to subscribe to the RTP 226 session carrying the retransmission stream. The original session 227 may also be single-source multicast while separate unicast sessions 228 are used to convey retransmissions to each of the receivers, which 229 as a result will receive only the retransmission packets they 230 request. 232 The use of separate sessions also facilitates differential treatment 233 by the network and may simplify processing in mixers, translators 234 and packet caches. 236 With SSRC-multiplexing, a single session is needed for the original 237 and the retransmission stream. This allows streaming servers and 238 middleware which are involved in a high number of concurrent 239 sessions to minimise their port usage. 241 This retransmission payload format allows both session-multiplexing 242 and SSRC-multiplexing for unicast sessions. From an implementation 243 point of view, there is little difference between the two 244 approaches. Hence, in order to maximise interoperability, both 245 multiplexing approaches SHOULD be supported by senders and 246 receivers. For multicast sessions, session-multiplexing MUST be 247 used because the association of the original stream and the 248 retransmission stream is problematic if SSRC-multiplexing is used 249 with multicast sessions(see Section 5.3 for motivation). 251 4. Retransmission payload format 253 The format of a retransmission packet is shown below: 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | RTP Header | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | OSN | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 260 | Original RTP Packet Payload | 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 The RTP header usage is as follows: 266 In the case of session-multiplexing, the same SSRC value MUST be 267 used for the original stream and the retransmission stream. In the 268 case of an SSRC collision in either the original session or the 269 retransmission session, the RTP specification requires that an RTCP 270 BYE packet MUST be sent in the session where the collision happened. 271 In addition, an RTCP BYE packet MUST also be sent for the associated 272 stream in its own session. After a new SSRC identifier is obtained, 273 the SSRC of both streams MUST be set to this value. 275 In the case of SSRC-multiplexing, two different SSRC values MUST be 276 used for the original stream and the retransmission stream as 277 required by RTP. If an SSRC collision is detected for either the 278 original stream or the retransmission stream, the RTP specification 279 requires that an RTCP BYE packet MUST be sent for this stream. No 280 RTCP BYE packet MUST be sent for the associated stream. Therefore, 281 only the stream that experienced SSRC collision will choose a new 282 SSRC value. Refer to Section 5.3 for the implications on the 283 original and retransmission stream SSRC association at the receiver. 285 For either multiplexing scheme, the sequence number has the standard 286 definition, i.e. it MUST be one higher than the sequence number of 287 the preceding packet sent in the retransmission stream. 289 The retransmission packet timestamp is set to the original 290 timestamp, i.e. to the timestamp of the original packet. As a 291 consequence, the initial RTP timestamp for the first packet of the 292 retransmission stream is not random but equal to the original 293 timestamp of the first packet that is retransmitted. See the 294 security considerations section in this document for security 295 implications. 297 Implementers have to be aware that the RTCP jitter value for the 298 retransmission stream does not reflect the actual network jitter 299 since there could be little correlation between the time a packet is 300 retransmitted and its original timestamp. 302 The payload type is dynamic. Each payload type of the original 303 stream MUST map to a different payload type value in the 304 retransmission stream. Therefore, when multiple payload types are 305 used in the original stream, multiple dynamic payload types will be 306 mapped to the retransmission payload format. See Section 8.1 for 307 the specification of how the mapping between original and 308 retransmission payload types is done with SDP. 310 As the retransmission packet timestamp carries the original media 311 timestamp, the timestamp clockrate used by the retransmission 312 payload type is the same as the one used by the associated original 313 payload type. It is thus possible to send retransmission packets 314 whose original payload types have different timestamp clockrates in 315 the same retransmission stream. Note that an RTP stream does not 316 usually carry payload types of different clockrates. 318 The payload of the RTP retransmission packet comprises the 319 retransmission payload header followed by the payload of the 320 original RTP packet. The length of the retransmission payload 321 header is 2 octets. This payload header contains only one field, 322 OSN, which MUST be set to the sequence number of the associated 323 original RTP packet. The original RTP packet payload, including any 324 possible payload headers specific to the original payload type, is 325 placed right after the retransmission payload header. 327 For payload types that support encoding at multiple rates, instead 328 of retransmitting the same payload as the original RTP packet the 329 sender MAY retransmit the same data encoded at a lower rate. This 330 aims at limiting the bandwidth usage of the retransmission stream. 332 When doing so, the sender MUST ensure that the receiver will still 333 be able to decode the payload of the already sent original packets 334 that might have been encoded based on the payload of the lost 335 original packet. In addition, if the sender chooses to retransmit 336 at a lower rate, the values in the payload header of the original 337 RTP packet may not longer apply to the retransmission packet and may 338 need to be modified in the retransmission packet to reflect the 339 change in rate. The sender should trade-off the decrease in 340 bandwidth usage with the decrease in quality caused by resending at 341 a lower rate. 343 If the original RTP header carried any profile-specific extensions, 344 the retransmission packet SHOULD include the same extensions 345 immediately following the fixed RTP header as expected by 346 applications running under this profile. In this case, the 347 retransmission payload header is thus placed after the profile- 348 specific extensions. 350 If the original RTP header carried an RTP header extension, the 351 retransmission packet SHOULD carry the same header extension. This 352 header extension MUST be placed right after the fixed RTP header, as 353 specified in RTP [3]. In this case, the retransmission payload 354 header is thus placed after the header extension. 356 If the original RTP packet contained RTP padding, that padding MUST 357 be removed before constructing the retransmission packet. If 358 padding of the retransmission packet is needed, padding is performed 359 as with any RTP packets and the padding bit is set. 361 The M, CC and CSRC bit of the original RTP header MUST be copied "as 362 is" into the RTP header of the retransmission packet. 364 5. Association of a retransmission stream with its original stream 366 5.1 Retransmission session sharing 368 In the case of session-multiplexing, a retransmission session MUST 369 map to exactly one original session, i.e. the same retransmission 370 session cannot be used for different original sessions. 372 If retransmission session sharing were allowed, it would be a 373 problem for receivers, since they would receive retransmissions for 374 original sessions they might not have joined. For example, a 375 receiver wishing to receive only audio would receive also 376 retransmitted video packets if an audio and video session shared the 377 same retransmission session. 379 5.2 CNAME use 381 In both the session-multiplexing and the SSRC-multiplexing cases, a 382 sender MUST use the same CNAME for an original stream and its 383 associated retransmission stream. 385 5.3 Association at the receiver 387 A receiver receiving multiple original and retransmission streams 388 needs to associate each retransmission stream with its original 389 stream. The association is done differently depending on whether 390 session-multiplexing or SSRC-multiplexing is used. 392 If session-multiplexing is used, the receiver associates the two 393 streams having the same SSRC in the two sessions. Note that the 394 payload type field cannot be used to perform the association as 395 several media streams may have the same payload type value. The two 396 sessions are themselves associated out-of-band. See Section 8 for 397 how the grouping of the two sessions is done with SDP. 399 If SSRC-multiplexing is used, the receiver should first of all look 400 for two streams that have the same CNAME in the session. In some 401 cases, the CNAME may not be enough to determine the association as 402 multiple original streams in the same session may share the same 403 CNAME. For example, there can be in the same video session multiple 404 video streams mapping to different SSRCs and still using the same 405 CNAME and possibly the same PT values. Each (or some) of these 406 streams may have an associated retransmission stream. 408 In this case, in order to find out the association between original 409 and retransmission streams having the same CNAME, the receiver 410 SHOULD behave as follows. 412 The association can generally be resolved when the receiver receives 413 a retransmission packet matching a retransmission request which had 414 been sent earlier. Upon reception of a retransmission packet whose 415 original sequence number has been previously requested, the receiver 416 can derive that the SSRC of the retransmission packet is associated 417 to the sender SSRC from which the packet was requested. 419 However, this mechanism might fail if there are two outstanding 420 requests for the same packet sequence number in two different 421 original streams of the session. Note that since the initial packet 422 sequence numbers are random, the probability of having two 423 outstanding requests for the same packet sequence number would be 424 very small. Nevertheless, in order to avoid ambiguity in the 425 unicast case, the receiver MUST NOT have two outstanding requests 426 for the same packet sequence number in two different original 427 streams before the association is resolved. In multicast, this 428 ambiguity cannot be completely avoided, because another receiver may 429 have requested the same sequence number from another stream. 430 Therefore, SSRC-multiplexing MUST NOT be used in multicast sessions. 432 If the receiver discovers that two senders are using the same SSRC 433 or if it receives an RTCP BYE packet, it MUST stop requesting 434 retransmissions for that SSRC. Upon reception of original RTP 435 packets with a new SSRC, the receiver MUST perform the SSRC 436 association again as described in this section. 438 6. Use with the extended RTP profile for RTCP-based feedback 440 This section gives general hints for the usage of this payload 441 format with the extended RTP profile for RTCP-based feedback, 442 denoted AVPF [1]. Note that the general RTCP send and receive rules 443 and the RTCP packet format as specified in RTP apply, except for the 444 changes that the AVPF profile introduces. In short, the AVPF 445 profile relaxes the RTCP timing rules and specifies additional 446 general-purpose RTCP feedback messages. See [1] for details. 448 6.1 RTCP at the sender 450 In the case of session-multiplexing, Sender Report (SR) packets for 451 the original stream are sent in the original session and SR packets 452 for the retransmission stream are sent in the retransmission session 453 according to the rules of RTP. 455 In the case of SSRC-multiplexing, SR packets for both original and 456 retransmission streams are sent in the same session according to the 457 rules of RTP. The original and retransmission streams are seen, as 458 far the RTCP bandwidth calculation is concerned, as independent 459 senders belonging to the same RTP session and are thus equally 460 sharing the RTCP bandwidth assigned to senders. 462 Note that in both cases, session- and SSRC-multiplexing, BYE packets 463 MUST still be sent for both streams as specified in RTP. In other 464 words, it is not enough to send BYE packets for the original stream 465 only. 467 6.2 RTCP Receiver Reports 469 In the case of session-multiplexing, the receiver will send report 470 blocks for the original stream and the retransmission stream in 471 separate Receiver Report (RR) packets belonging to separate RTP 472 sessions. RR packets reporting on the original stream are sent in 473 the original RTP session while RR packets reporting on the 474 retransmission stream are sent in the retransmission session. The 475 RTCP bandwidth for these two sessions may be chosen independently 476 (for example through RTCP bandwidth modifiers [4]). 478 In the case of SSRC-multiplexing, the receiver sends report blocks 479 for the original and the retransmission streams in the same RR 480 packet since there is a single session. 482 6.3 Retransmission requests 484 The NACK feedback message format defined in the AVPF profile SHOULD 485 be used by receivers to send retransmission requests. Whether a 486 receiver chooses to request a packet or not is an implementation 487 issue. An actual receiver implementation should take into account 488 such factors as the tolerable application delay, the network 489 environment and the media type. 491 The receiver should generally assess whether the retransmitted 492 packet would still be useful at the time it is received. The 493 timestamp of the missing packet can be estimated from the timestamps 494 of packets preceding and/or following the sequence number gap caused 495 by the missing packet in the original stream. In most cases, some 496 form of linear estimate of the timestamp is good enough. 498 Furthermore, a receiver should compute an estimate of the round-trip 499 time (RTT) to the sender. This can be done, for example, by 500 measuring the retransmission delay to receive a retransmission 501 packet after a NACK has been sent for that packet. This estimate 502 may also be obtained from past observations, RTCP report round-trip 503 time if available or any other means. A standard mechanism for the 504 receiver to estimate the RTT is specified in RTP Extended Reports 505 [11]. 507 The receiver should not send a retransmission request as soon as it 508 detects a missing sequence number but should add some extra delay to 509 compensate for packet reordering. This extra delay may, for 510 example, be based on past observations of the experienced packet 511 reordering. 513 To increase the robustness to the loss of a NACK or of a 514 retransmission packet, a receiver may send a new NACK for the same 515 packet. This is referred to as multiple retransmissions. Before 516 sending a new NACK for a missing packet, the receiver should rely on 517 a timer to be reasonably sure that the previous retransmission 518 attempt has failed in order to avoid unnecessary retransmissions. 520 NACKs MUST be sent only for the original RTP stream. Otherwise, if 521 a receiver wanted to perform multiple retransmissions by sending a 522 NACK in the retransmission stream, it would not be able to know the 523 original sequence number and a timestamp estimation of the packet it 524 requests. 526 6.4 Timing rules 528 The NACK feedback message may be sent in a regular full compound 529 RTCP packet or in an early RTCP packet, as per AVPF [1]. Sending a 530 NACK in an early packet allows to react more quickly to a given 531 packet loss. However, in that case if a new packet loss occurs 532 right after the early RTCP packet was sent, the receiver will then 533 have to wait for the next regular RTCP compound packet after the 534 early packet. Sending NACKs only in regular RTCP compound decreases 535 the maximum delay between detecting an original packet loss and 536 being able to send a NACK for that packet. Implementers should 537 consider the possible implications of this fact for the application 538 being used. 540 Furthermore, receivers may make use of the minimum interval between 541 regular RTCP compound packets. This interval can be used to keep 542 regular receiver reporting down to a minimum, while still allowing 543 receivers to send early RTCP packets during periods requiring more 544 frequent feedback, e.g. times of higher packet loss rate.. Note 545 that although RTCP packets may be suppressed because they do not 546 contain NACKs, the same RTCP bandwidth as if they were sent needs to 547 be available. See AVPF [1] for details on the use of the minimum 548 interval. 550 7. Congestion control 552 RTP retransmission poses a risk of increasing network congestion. 553 In a best-effort environment, packet loss is caused by congestion. 554 Reacting to loss by retransmission of older data without decreasing 555 the rate of the original stream would thus further increase 556 congestion. Implementations SHOULD follow the recommendations below 557 in order to use retransmission. 559 The RTP profile under which the retransmission scheme is used 560 defines an appropriate congestion control mechanism in different 561 environments. Following the rules under the profile, an RTP 562 application can determine its acceptable bitrate and packet rate in 563 order to be fair to other TCP or RTP flows. 565 If an RTP application uses retransmission, the acceptable packet 566 rate and bitrate includes both the original and retransmitted data. 567 This guarantees that an application using retransmission achieves 568 the same fairness as one that does not. Such a rule would translate 569 in practice into the following actions: 571 If enhanced service is used, it should be made sure that the total 572 bitrate and packet rate do not exceed that of the requested service. 573 It should be further monitored that the requested services are 574 actually delivered. In a best-effort environment, the sender SHOULD 575 NOT send retransmission packets without reducing the packet rate and 576 bitrate of the original stream (for example by encoding the data at 577 a lower rate). 579 In addition, the sender MAY selectively retransmit only the packets 580 that it deems important and ignore NACK messages for other packets 581 in order to limit the bitrate. 583 These congestion control mechanisms should keep the packet loss rate 584 within acceptable parameters. Packet loss is considered acceptable 585 if a TCP flow across the same network path and experiencing the same 586 network conditions would achieve, on a reasonable timescale, an 587 average throughput, that is not less than the one the RTP flow 588 achieves. If the packet loss rate exceeds an acceptable level, it 589 should be concluded that congestion is not kept under control and 590 retransmission should then not be used. It may further be necessary 591 to adapt the transmission rate (or the number of layers subscribed 592 for a layered multicast session), or to arrange for the receiver to 593 leave the session. 595 8. Retransmission Payload Format MIME type registration 597 8.1 Introduction 599 The following MIME subtype name and parameters are introduced in 600 this document: "rtx", "rtx-time" and "apt". 602 The binding used for the retransmission stream to the payload type 603 number is indicated by an rtpmap attribute. The MIME subtype name 604 used in the binding is "rtx". 606 The "apt" (associated payload type) parameter MUST be used to map 607 the retransmission payload type to the associated original stream 608 payload type. If multiple payload types are used for the original 609 streams, then multiple "apt" parameters MUST be included to map each 610 original stream payload type to a different retransmission payload 611 type. 613 An OPTIONAL payload-format-specific parameter, "rtx-time," indicates 614 the maximum time a server will try to retransmit a packet. 616 The syntax is as follows: 618 a=fmtp: apt=;rtx-time= 619 where, 621 : indicates the dynamic payload type number assigned to 622 the retransmission payload format in an rtpmap attribute. 624 : the value of the original stream payload type to 625 which this retransmission stream payload type is associated. 627 : indicates the time in milliseconds, measured 628 from the time a packet was first sent until the time the server 629 will stop trying to retransmit the packet. The absence of the 630 rtx-time parameter for a retransmission stream means that the 631 maximum retransmission time is not defined, but MAY be 632 negotiated by other means. 634 8.2 Registration of audio/rtx 636 MIME type: audio 638 MIME subtype: rtx 640 Required parameters: 642 rate: the RTP timestamp clockrate is equal to the RTP timestamp 643 clockrate of the media that is retransmitted. 645 apt: associated payload type. The value of this parameter is 646 the payload type of the associated original stream. 648 Optional parameters: 650 rtx-time: indicates the time in milliseconds, measured from the 651 time a packet was first sent until the time the server will 652 stop trying to retransmit the packet. 654 Encoding considerations: this type is only defined for transfer via 655 RTP. 657 Security considerations: see Section 12 of RFC XXXX 659 Interoperability considerations: none 661 Published specification: RFC XXXX 663 Applications which use this media type: multimedia streaming 664 applications 666 Additional information: none 668 Person & email address to contact for further information: 669 rey@panasonic.de 670 david.leon@nokia.com 671 avt@ietf.org 673 Intended usage: COMMON 675 Author/Change controller: 676 Jose Rey 677 David Leon 678 IETF AVT WG 680 8.3 Registration of video/rtx 682 MIME type: video 684 MIME subtype: rtx 686 Required parameters: 688 rate: the RTP timestamp clockrate is equal to the RTP timestamp 689 clockrate of the media that is retransmitted. 691 apt: associated payload type. The value of this parameter is 692 the payload type of the associated original stream. 694 Optional parameters: 696 rtx-time: indicates the time in milliseconds, measured from the 697 time a packet was first sent until the time the server will 698 stop trying to retransmit the packet. 700 Encoding considerations: this type is only defined for transfer via 701 RTP. 703 Security considerations: see Section 12 of RFC XXXX 705 Interoperability considerations: none 707 Published specification: RFC XXXX 709 Applications which use this media type: multimedia streaming 710 applications 712 Additional information: none 714 Person & email address to contact for further information: 715 rey@panasonic.de 716 david.leon@nokia.com 717 avt@ietf.org 719 Intended usage: COMMON 721 Author/Change controller: 722 Jose Rey 723 David Leon 724 IETF AVT WG 726 8.4 Registration of text/rtx 728 MIME type: text 730 MIME subtype: rtx 732 Required parameters: 734 rate: the RTP timestamp clockrate is equal to the RTP timestamp 735 clockrate of the media that is retransmitted. 737 apt: associated payload type. The value of this parameter is 738 the payload type of the associated original stream. 740 Optional parameters: 742 rtx-time: indicates the time in milliseconds, measured from the 743 time a packet was first sent until the time the server will 744 stop trying to retransmit the packet. 746 Encoding considerations: this type is only defined for transfer via 747 RTP. 749 Security considerations: see Section 12 of RFC XXXX 751 Interoperability considerations: none 753 Published specification: RFC XXXX 755 Applications which use this media type: multimedia streaming 756 applications 758 Additional information: none 760 Person & email address to contact for further information: 761 rey@panasonic.de 762 david.leon@nokia.com 763 avt@ietf.org 765 Intended usage: COMMON 767 Author/Change controller: 768 Jose Rey 769 David Leon 770 IETF AVT WG 772 8.5 Registration of application/rtx 774 MIME type: application 776 MIME subtype: rtx 778 Required parameters: 780 rate: the RTP timestamp clockrate is equal to the RTP timestamp 781 clockrate of the media that is retransmitted. 783 apt: associated payload type. The value of this parameter is 784 the payload type of the associated original stream. 786 Optional parameters: 788 rtx-time: indicates the time in milliseconds, measured from the 789 time a packet was first sent until the time the server will 790 stop trying to retransmit the packet. 792 Encoding considerations: this type is only defined for transfer via 793 RTP. 795 Security considerations: see Section 12 of RFC XXXX 797 Interoperability considerations: none 798 Published specification: RFC XXXX 800 Applications which use this media type: multimedia streaming 801 applications 803 Additional information: none 805 Person & email address to contact for further information: 806 rey@panasonic.de 807 david.leon@nokia.com 808 avt@ietf.org 810 Intended usage: COMMON 812 Author/Change controller: 813 Jose Rey 814 David Leon 815 IETF AVT WG 817 8.6 Mapping to SDP 819 The information carried in the MIME media type specification has a 820 specific mapping to fields in SDP [5], which is commonly used to 821 describe RTP sessions. When SDP is used to specify retransmissions 822 for an RTP stream, the mapping is done as follows: 824 - The MIME types ("video"), ("audio"), ("text") and ("application") 825 go in the SDP "m=" as the media name. 827 - The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding 828 name. The RTP clock rate in "a=rtpmap" MUST be that of the 829 retransmission payload type. See Section 4 for details on this. 831 - The AVPF profile-specific parameters "ack" and "nack" go in SDP 832 "a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types of 833 feedback. See the AVPF profile [1] for details. 835 - The retransmission payload-format-specific parameters "apt" and 836 "rtx-time" go in the SDP "a=fmtp" as a semicolon separated list of 837 parameter=value pairs. 839 - Any remaining parameters go in the SDP "a=fmtp" attribute by 840 copying them directly from the MIME media type string as a semicolon 841 separated list of parameter=value pairs. 843 In the following sections some example SDP descriptions are 844 presented. 846 8.7 SDP description with session-multiplexing 848 In the case of session-multiplexing, the SDP description contains 849 one media specification "m" line per RTP session. The SDP MUST 850 provide the grouping of the original and associated retransmission 851 sessions' "m" lines, using the Flow Identification (FID) semantics 852 defined in RFC 3388 [6]. 854 The following example specifies two original, AMR and MPEG-4, 855 streams on ports 49170 and 49174 and their corresponding 856 retransmission streams on ports 49172 and 49176, respectively: 858 v=0 859 o=mascha 2980675221 2980675778 IN IP4 host.example.net 860 c=IN IP4 192.0.2.0 861 a=group:FID 1 2 862 a=group:FID 3 4 863 m=audio 49170 RTP/AVPF 96 864 a=rtpmap:96 AMR/8000 865 a=fmtp:96 octet-align=1 866 a=rtcp-fb:96 nack 867 a=mid:1 868 m=audio 49172 RTP/AVPF 97 869 a=rtpmap:97 rtx/8000 870 a=fmtp:97 apt=96;rtx-time=3000 871 a=mid:2 872 m=video 49174 RTP/AVPF 98 873 a=rtpmap:98 MP4V-ES/90000 874 a=rtcp-fb:98 nack 875 a=fmtp:98 profile-level-id=8;config=01010000012000884006682C2090A21F 876 a=mid:3 877 m=video 49176 RTP/AVPF 99 878 a=rtpmap:99 rtx/90000 879 a=fmtp:99 apt=98;rtx-time=3000 880 a=mid:4 882 A special case of the SDP description is a description that contains 883 only one original session "m" line and one retransmission session 884 "m" line, the grouping is then obvious and FID semantics MAY be 885 omitted in this special case only. 887 This is illustrated in the following example, which is an SDP 888 description for a single original MPEG-4 stream and its 889 corresponding retransmission session: 891 v=0 892 o=mascha 2980675221 2980675778 IN IP4 host.example.net 893 c=IN IP4 192.0.2.0 894 m=video 49170 RTP/AVPF 96 895 a=rtpmap:96 MP4V-ES/90000 896 a=rtcp-fb:96 nack 897 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F 898 m=video 49172 RTP/AVPF 97 899 a=rtpmap:97 rtx/90000 900 a=fmtp:97 apt=96;rtx-time=3000 902 8.8 SDP description with SSRC-multiplexing 904 The following is an example of an SDP description for an RTP video 905 session using SSRC-multiplexing with similar parameters as in the 906 single-session example above: 908 v=0 909 o=mascha 2980675221 2980675778 IN IP4 host.example.net 910 c=IN IP4 192.0.2.0 911 m=video 49170 RTP/AVPF 96 97 912 a=rtpmap:96 MP4V-ES/90000 913 a=rtcp-fb:96 nack 914 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F 915 a=rtpmap:97 rtx/90000 916 a=fmtp:97 apt=96;rtx-time=3000 918 9. RTSP considerations 920 The Real-time Streaming Protocol (RTSP), RFC 2326 [7] is an 921 application-level protocol for control over the delivery of data 922 with real-time properties. This section looks at the issues 923 involved in controlling RTP sessions that use retransmissions. 925 9.1 RTSP control with SSRC-multiplexing 927 In the case of SSRC-multiplexing, the "m" line includes both 928 original and retransmission payload types and has a single RTSP 929 "control" attribute. The receiver uses the "m" line to request 930 SETUP and TEARDOWN of the whole media session. The RTP profile 931 contained in the transport header MUST be the AVPF profile or 932 another suitable profile allowing extended feedback. 934 In order to control the sending of the session original media 935 stream, the receiver sends as usual PLAY and PAUSE requests to the 936 sender for the session. The RTP-info header that is used to set 937 RTP-specific parameters in the PLAY response MUST be set according 938 to the RTP information of the original stream. 940 When the receiver starts receiving the original stream, it can then 941 request retransmission through RTCP NACKs without additional RTSP 942 signalling. 944 9.2 RTSP control with session-multiplexing 946 In the case of session-multiplexing, each SDP "m" line has an RTSP 947 "control" attribute. Hence, when retransmission is used, both the 948 original session and the retransmission have their own "control" 949 attributes. The receiver can associate the original session and the 950 retransmission session through the FID semantics as specified in 951 Section 8. 953 The original and the retransmission streams are set up and torn down 954 separately through their respective media "control" attribute. The 955 RTP profile contained in the transport header MUST be the AVPF 956 profile or another suitable profile allowing extended feedback for 957 both the original and the retransmission session. 959 The RTSP presentation SHOULD support aggregate control and SHOULD 960 contain a session level RTSP URL. The receiver SHOULD use aggregate 961 control for an original session and its associated retransmission 962 session. Otherwise, there would need to be two different 'session- 963 id' values, i.e. different values for the original and 964 retransmission sessions, and the sender would not know how to 965 associate them. 967 The session-level "control" attribute is then used as usual to 968 control the playing of the original stream. When the receiver 969 starts receiving the original stream, it can then request 970 retransmissions through RTCP without additional RTSP signalling. 972 9.3 RTSP control of the retransmission stream 974 Because of the nature of retransmissions, the sending of 975 retransmission packets SHOULD NOT be controlled through RTSP PLAY 976 and PAUSE requests. The PLAY and PAUSE requests SHOULD NOT affect 977 the retransmission stream. Retransmission packets are sent upon 978 receiver requests in the original RTCP stream, regardless of the 979 state. 981 9.4 Cache control 983 Retransmission streams SHOULD NOT be cached. 985 In the case of session-multiplexing, the "Cache-Control" header 986 SHOULD be set to "no-cache" for the retransmission stream. 988 In the case of SSRC-multiplexing, RTSP cannot specify independent 989 caching for the retransmission stream, because there is a single "m" 990 line in SDP. Therefore, the implementer should take this fact into 991 account when deciding whether to cache an SSRC-multiplexed session 992 or not. 994 10. Implementation examples 996 This document mandates only the sender and receiver behaviours that 997 are necessary for interoperability. In addition, certain algorithms, 998 such as rate control or buffer management when targeted at specific 999 environments, may enhance the retransmission efficiency. 1001 This section gives an overview of different implementation options 1002 allowed within this specification. 1004 The first example describes a minimal receiver implementation. With 1005 this implementation, it is possible to retransmit lost RTP packets, 1006 detect efficiently the loss of retransmissions and perform multiple 1007 retransmissions, if needed. Most of the necessary processing is done 1008 at the server. 1010 The second example shows how a receiver may implement additional 1011 enhancements that might help reduce sender buffer requirements and 1012 optimise the retransmission efficiency 1014 The third example shows how retransmissions may be used in (small) 1015 multicast groups in conjunction with layered encoding. It 1016 illustrates that retransmissions and layered encoding may be 1017 complementary techniques. 1019 10.1 A minimal receiver implementation example 1021 This section gives an example of an implementation supporting 1022 multiple retransmissions. The sender transmits the original data in 1023 RTP packets using the MPEG-4 video RTP payload format. 1024 It is assumed that NACK feedback messages are used, as per 1025 [1]. An SDP description example with SSRC-multiplexing is given 1026 below: 1028 v=0 1029 o=mascha 2980675221 2980675778 IN IP4 host.example.net 1030 c=IN IP4 192.0.2.0 1031 m=video 49170 RTP/AVPF 96 97 1032 a=rtpmap:96 MP4V-ES/90000 1033 a=rtcp-fb:96 nack 1034 a=rtpmap:97 rtx/90000 1035 a=fmtp:97 apt=96;rtx-time=3000 1037 The format-specific parameter "rtx-time" indicates that the server 1038 will buffer the sent packets in a retransmission buffer for 3.0 1039 seconds, after which the packets are deleted from the retransmission 1040 buffer and will never be sent again. 1042 In this implementation example, the required RTP receiver processing 1043 to handle retransmission is kept to a minimum. The receiver detects 1044 packet loss from the gaps observed in the received sequence numbers. 1045 It signals lost packets to the sender through NACKs as defined in the 1046 AVPF profile [1]. The receiver should take into account the 1047 signalled sender retransmission buffer length in order to dimension 1048 its own reception buffer. It should also derive from the buffer 1049 length the maximum number of times the retransmission of a packet can 1050 be requested. 1052 The sender should retransmit the packets selectively, i.e. it should 1053 choose whether to retransmit a requested packet depending on the 1054 packet importance, the observed QoS and congestion state of the 1055 network connection to the receiver. Obviously, the sender processing 1056 increases with the number of receivers as state information and 1057 processing load must be allocated to each receiver. 1059 10.2 An enhanced receiver implementation example 1061 The receiver may have more accurate information than the sender about 1062 the current network QoS such as available bandwidth, packet loss 1063 rate, delay and jitter. In addition, other receiver-specific 1064 parameters such as buffer level, estimated importance of the lost 1065 packet and application level QoS may be used by the receiver to make 1066 a more efficient use of RTP retransmission by selectively sending 1067 NACKs for important lost packets and not for others. For example, a 1068 receiver may decide to suppress a request for a packet loss that 1069 could be concealed locally, or for a retransmission that would arrive 1070 late. 1072 Furthermore, a receiver may acknowledge the received packets. This 1073 can be done by sending ACKs, as per [1]. Upon receiving an ACK, the 1074 sender may delete all the acknowledged packets from its 1075 retransmission buffer. Note that this would also require only 1076 limited increase in the required RTCP bandwidth as long as ACK 1077 packets are sent seldom enough. 1079 This implementation may help reduce buffer requirements at the sender 1080 and optimise the performance of the implementation by using selective 1081 requests. 1083 Note that these receiver enhancements do not need to be negotiated as 1084 they do not affect the sender implementation. However, in order to 1085 allow the receiver to acknowledge packets, it is needed to allow the 1086 use of ACKs in the SDP description, by means of an additional SDP 1087 "a=rtcp-fb" line, as follows: 1089 v=0 1090 o=mascha 2980675221 2980675778 IN IP4 host.example.net 1091 c=IN IP4 192.0.2.0 1092 m=video 49170 RTP/AVPF 96 97 1093 a=rtpmap:96 MP4V-ES/90000 1094 a=rtcp-fb:96 nack 1095 a=rtcp-fb:96 ack 1096 a=rtpmap:97 rtx/90000 1097 a=fmtp:97 apt=96;rtx-time=3000 1099 10.3 Retransmission of Layered Encoded Media in Multicast 1101 This section shows how to combine retransmissions with layered 1102 encoding in multicast sessions. Note that the retransmission 1103 framework is not intended as a complete solution to reliable 1104 multicast. Refer to RFC 2887 [10], for an overview of the problems 1105 related with reliable multicast transmission. 1107 Packets of different importance are sent in different RTP sessions. 1108 The retransmission streams corresponding to the different layers can 1109 themselves be seen as different retransmission layers. The relative 1110 importance of the different retransmission streams should reflect the 1111 relative importance of the different original streams. 1113 In multicast, SSRC-multiplexing of the original and retransmission 1114 streams is not allowed as per Section 5.3 of this document. For this 1115 reason, the retransmission stream(s) MUST be sent in different RTP 1116 session(s) using session-multiplexing. 1118 An SDP description example of multicast retransmissions for layered 1119 encoded media is given below: 1121 m=video 8000 RTP/AVPF 98 1122 c=IN IP4 192.0.2.0/127/3 1123 a=rtpmap:98 MP4V-ES/90000 1124 a=rtcp-fb:98 nack 1125 m=video 8000 RTP/AVPF 99 1126 c=IN IP4 192.0.2.4/127/3 1127 a=rtpmap:99 rtx/90000 1128 a=fmtp:99 apt=98;rtx-time=3000 1130 The server and the receiver may implement the retransmission methods 1131 illustrated in the previous examples. In addition, they may choose 1132 to request and retransmit a lost packet depending on the layer it 1133 belongs to. 1135 11. IANA considerations 1137 A new MIME subtype name, "rtx", has been registered for four 1138 different media types, as follows: "video", "audio", "text" and 1139 "application". An additional REQUIRED parameter, "apt", and an 1140 OPTIONAL parameter, "rtx-time", are defined. See Section 8 for 1141 details. 1143 12. Security considerations 1145 If cryptography is used to provide security services on the original 1146 stream, then the same services, with equivalent cryptographic 1147 strength, MUST be provided on the retransmission stream. Old keys 1148 will likely need to be cached so that when the keys change for the 1149 original stream, the old key is used until it is determined that the 1150 key has changed on the retransmission packets as well. 1152 The use of the same key for the retransmitted stream and the 1153 original stream may lead to security problems, e.g. two-time pads. 1154 This sharing has to be evaluated towards the chosen security 1155 protocol and security algorithms. 1157 RTP recommends that the initial RTP timestamp SHOULD be random to 1158 secure the stream against known plain text attacks. This payload 1159 format does not follow this recommendation as the initial timestamp 1160 will be the media timestamp of the first retransmitted packet. 1162 However, since the initial timestamp of the original stream is 1163 itself random, if the original stream is encrypted, the first 1164 retransmitted packet timestamp would also be random to an attacker. 1165 Therefore, confidentiality would not be compromised. 1167 Congestion control considerations with the use of retransmission are 1168 dealt with in Section 7 of this document. 1170 Any other security considerations of the profile under which the 1171 retransmission scheme is used should be applied. The retransmission 1172 payload format MUST NOT be used under the SAVP profile defined by 1173 the Secure Real-Time Transport Protocol (SRTP)[12] but instead an 1174 extension of SRTP should be defined to secure the AVPF profile. The 1175 definition of such a profile is out of the scope of this document. 1177 13. Acknowledgements 1179 We would like to express our gratitude to Carsten Burmeister for his 1180 participation in the development of this document. Our thanks also 1181 go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus Westerlund, 1182 Go Hori and Rahul Agarwal for their helpful comments. 1184 14. References 1186 14.1 Normative References 1188 1 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP 1189 profile for RTCP-based feedback", draft-ietf-avt-rtcp-feedback- 1190 04.txt, September 2002. 1192 2 S. Bradner, "Key words for use in RFCs to Indicate Requirement 1193 Levels", BCP 14, RFC 2119, March 1997 1195 3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A 1196 Transport Protocol for Real-Time Applications", draft-ietf-avt- 1197 rtp-new-11.txt, May 2002. 1199 4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", draft- 1200 ietf-avt-rtcp-bw-05.txt, May 2002. 1202 5 M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 1203 2327, April 1998. 1205 6 G. Camarillo, J. Holler, G. AP. Eriksson, "Grouping of media lines 1206 in the Session Description Protocol (SDP)", RFC 3388, December 1207 2002. 1209 7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol 1210 (RTSP)", RFC 2326, April 1998. 1212 14.2 Informative References 1214 8 C. Perkins, O. Hodson, "Options for Repair of Streaming Media", 1215 RFC 2354, June 1998. 1217 9 G. Hellstrom, "RTP for conversational text", RFC 2793, May 2000 1219 10 M. Handley, et al., "The Reliable Multicast Design Space for Bulk 1220 Data Transfer", RFC 2887, August 2000. 1222 11 Friedman, et. al., "RTP Extended Reports", Work in Progress. 1224 12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. 1225 Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", 1226 draft-ietf-avt-srtp-05.txt, June 2002. 1228 13 R. Hovey and S. Bradner, "The Organizations Involved in the IETF 1229 Standards Process," BCP 11, RFC 2028, IETF, October 1996. 1231 Author's Addresses 1233 Jose Rey rey@panasonic.de 1234 Panasonic European Laboratories GmbH 1235 Monzastr. 4c 1236 D-63225 Langen, Germany 1237 Phone: +49-6103-766-134 1238 Fax: +49-6103-766-166 1240 David Leon david.leon@nokia.com 1241 Nokia Research Center 1242 6000 Connection Drive 1243 Irving, TX. USA 1244 Phone: 1-972-374-1860 1246 Akihiro Miyazaki akihiro@isl.mei.co.jp 1247 Core Software Development Center 1248 Corporate Software Development Division 1249 Matsushita Electric Industrial Co., Ltd. 1250 1006 Kadoma, Kadoma City, Osaka 571-8501, Japan 1251 Phone: +81-6-6900-9192 1252 Fax: +81-6-6900-9193 1254 Viktor Varsa viktor.varsa@nokia.com 1255 Nokia Research Center 1256 6000 Connection Drive 1257 Irving, TX. USA 1258 Phone: 1-972-374-1861 1260 Rolf Hakenberg hakenberg@panasonic.de 1261 Panasonic European Laboratories GmbH 1262 Monzastr. 4c 1263 D-63225 Langen, Germany 1264 Phone: +49-6103-766-162 1265 Fax: +49-6103-766-166 1267 IPR Notices 1269 The IETF takes no position regarding the validity or scope of any 1270 intellectual property or other rights that might be claimed to 1271 pertain to the implementation or use of the technology described in 1272 this document or the extent to which any license under such rights 1273 might or might not be available; neither does it represent that it 1274 has made any effort to identify any such rights. Information on the 1275 IETF's procedures with respect to rights in standards-track and 1276 standards-related documentation can be found in BCP 11 [13]. Copies 1277 of claims of rights made available for publication and any assurances 1278 of licenses to be made available, or the result of an attempt made to 1279 obtain a general license or permission for the use of such 1280 proprietary rights by implementers or users of this specification can 1281 be obtained from the IETF Secretariat. 1283 The IETF invites any interested party to bring to its attention any 1284 copyrights, patents or patent applications, or other proprietary 1285 rights which may cover technology that may be required to practice 1286 this standard. Please address the information to the IETF Executive 1287 Director. 1289 Full Copyright Statement 1291 "Copyright (C) The Internet Society (2003). All Rights Reserved. 1293 This document and translations of it may be copied and furnished to 1294 others, and derivative works that comment on or otherwise explain it 1295 or assist in its implementation may be prepared, copied, published 1296 and distributed, in whole or in part, without restriction of any 1297 kind, provided that the above copyright notice and this paragraph are 1298 included on all such copies and derivative works. However, this 1299 document itself may not be modified in any way, such as by removing 1300 the copyright notice or references to the Internet Society or other 1301 Internet organizations, except as needed for the purpose of 1302 developing Internet standards in which case the procedures for 1303 copyrights defined in the Internet Standards process must be 1304 followed, or as required to translate it into languages other than 1305 English. 1307 The limited permissions granted above are perpetual and will 1308 not be revoked by the Internet Society or its successors or 1309 assigns. 1311 This document and the information contained herein is provided on an 1312 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1313 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1314 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1315 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1316 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."