idnits 2.17.1 draft-ietf-avt-rtp-retransmission-09.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: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-ietf-avt-rtp-retransmission-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-avt-rtp-retransmission-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-avt-rtp-retransmission-', but the file name used is 'draft-ietf-avt-rtp-retransmission-09' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- 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 1341 has weird spacing: '...for the purpo...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (August 2003) is 7531 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 81 looks like a reference -- Missing reference section? '1' on line 1102 looks like a reference -- Missing reference section? '2' on line 144 looks like a reference -- Missing reference section? '9' on line 173 looks like a reference -- Missing reference section? '3' on line 365 looks like a reference -- Missing reference section? '4' on line 493 looks like a reference -- Missing reference section? '11' on line 523 looks like a reference -- Missing reference section? '5' on line 840 looks like a reference -- Missing reference section? '6' on line 876 looks like a reference -- Missing reference section? '7' on line 946 looks like a reference -- Missing reference section? '10' on line 1133 looks like a reference -- Missing reference section? '12' on line 1206 looks like a reference Summary: 2 errors (**), 1 flaw (~~), 5 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- J. Rey/Matsushita 4 09.txt D. Leon/Nokia 5 A. Miyazaki/Matsushita 6 V. Varsa/Nokia 7 R. Hakenberg/Matsushita 9 Expires: February 2004 August 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 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 [Note to RFC Editor: This paragraph is to be deleted when this 39 draft is published as an RFC. References in this draft to RFC 40 XXXX should be replaced with the RFC number assigned to this 41 document.] 43 Abstract 45 RTP retransmission is an effective packet loss recovery technique 46 for real-time applications with relaxed delay bounds. This 47 document describes an RTP payload format for performing 48 retransmissions. Retransmitted RTP packets are sent in a separate 49 stream from the original RTP stream. It is assumed that feedback 50 from receivers to senders is available. In particular, it is 51 assumed that RTCP feedback as defined in the extended RTP profile 52 for RTCP-based feedback (denoted RTP/AVPF), is available in this 53 memo. 55 Table of Contents 57 1. Introduction..................................................3 58 2. Terminology...................................................3 59 3. Requirements and design rationale for a retransmission scheme.4 60 4. Retransmission payload format.................................6 61 5. Asocciation of a retransmission stream to its original stream.8 62 6. Use with the extended RTP profile for RTCP-based feedback....10 63 7. Congestion control...........................................12 64 8. Retransmission Payload Format MIME type registration.........13 65 9. RTSP considerations..........................................19 66 10. Implementation examples.....................................21 67 11. IANA considerations.........................................23 68 12. Security considerations.....................................24 69 13. Acknowledgements............................................24 70 14. References..................................................25 71 15. Author's Addresses..........................................25 72 IPR Notices.....................................................26 73 Full Copyright Statement........................................27 75 1. Introduction 77 Packet losses between an RTP sender and receiver may significantly 78 degrade the quality of the received media. Several techniques, 79 such as forward error correction (FEC), retransmissions or 80 interleaving may be considered to increase packet loss resiliency. 81 RFC 2354 [8] discusses the different options. 83 When choosing a repair technique for a particular application, the 84 tolerable latency of the application has to be taken into account. 85 In the case of multimedia conferencing, the end-to-end delay has 86 to be at most a few hundred milliseconds in order to guarantee 87 interactivity, which usually excludes the use of retransmission. 89 However, in the case of multimedia streaming, the user can 90 tolerate an initial latency as part of the session set-up and thus 91 an end-to-end delay of several seconds may be acceptable. 92 Retransmission may thus be considered for such applications. 94 This document specifies a retransmission method for RTP applicable 95 to unicast and (small) multicast groups: it defines a payload 96 format for retransmitted RTP packets and provides protocol rules 97 for the sender and the receiver involved in retransmissions. 99 Furthermore, this retransmission payload format was designed for 100 use with the extended RTP profile for RTCP-based feedback, AVPF 101 [1]. It may also be used with other RTP profiles defined in the 102 future. 104 The AVPF profile allows for more frequent feedback and for early 105 feedback. It defines a small number of general-purpose feedback 106 messages, e.g. ACKs and NACKs, as well as codec and application- 107 specific feedback messages. See [1] for details. 109 2. Terminology 111 The following terms are used in this document: 113 Original packet: refers to an RTP packet which carries user data 114 sent for the first time by an RTP sender. 116 Original stream: refers to the RTP stream of original packets. 118 Retransmission packet: refers to an RTP packet which is to be used 119 by the receiver instead of a lost original packet. Such a 120 retransmission packet is said to be associated with the original 121 RTP packet. 123 Retransmission request: a means by which an RTP receiver is able 124 to request that the RTP sender should send a retransmission packet 125 for a given original packet. Usually, an RTCP NACK packet as 126 specified in [1] is used as retransmission request for lost 127 packets. 129 Retransmission stream: the stream of retransmission packets 130 associated with an original stream. 132 Session-multiplexing: scheme by which the original stream and the 133 associated retransmission stream are sent into two different RTP 134 sessions. 136 SSRC-multiplexing: scheme by which the original stream and the 137 retransmission stream are sent in the same RTP session with 138 different SSRC values. 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 141 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 142 in this document are to be interpreted as described in RFC 2119 143 [2]. 145 3. Requirements and design rationale for a retransmission scheme 147 The use of retransmissions in RTP as a repair method for streaming 148 media is appropriate in those scenarios with relaxed delay bounds 149 and where full reliability is not a requirement. More 150 specifically, RTP retransmission allows to trade-off reliability 151 vs. delay, i.e. the endpoints may give up retransmitting a lost 152 packet after a given buffering time has elapsed. Unlike TCP there 153 is thus no head-of-line blocking caused by RTP retransmissions. 154 The implementer should be aware that in cases where full 155 reliability is required or higher delay and jitter can be 156 tolerated, TCP or other transport options should be considered. 158 The RTP retransmission scheme defined in this document is designed 159 to fulfil the following set of requirements: 161 1. It must not break general RTP and RTCP mechanisms. 162 2. It must be suitable for unicast and small multicast groups. 163 3. It must work with mixers and translators. 164 4. It must work with all known payload types. 165 5. It must not prevent the use of multiple payload types in a 166 session. 167 6. In order to support the largest variety of payload formats, the 168 RTP receiver must be able to derive how many and which RTP 169 packets were lost as a result of a gap in received RTP sequence 170 numbers. This requirement is referred to as sequence number 171 preservation. Without such a requirement, it would be 172 impossible to use retransmission with payload formats, such as 173 conversational text [9] or most audio/video streaming 174 applications, that use the RTP sequence number to detect lost 175 packets. 177 When designing a solution for RTP retransmission, several 178 approaches may be considered for the multiplexing of the original 179 RTP packets and the retransmitted RTP packets. 181 One approach may be to retransmit the RTP packet with its original 182 sequence number and send original and retransmission packets in 183 the same RTP stream. The retransmission packet would then be 184 identical to the original RTP packet, i.e. the same header (and 185 thus same sequence number) and the same payload. However, such an 186 approach is not acceptable because it would corrupt the RTCP 187 statistics. As a consequence, requirement 1 would not be met. 188 Correct RTCP statistics require that for every RTP packet within 189 the RTP stream, the sequence number be increased by one. 191 Another approach may be to multiplex original RTP packets and 192 retransmission packets in the same RTP stream using different 193 payload type values. With such an approach, the original packets 194 and the retransmission packets would share the same sequence 195 number space. As a result, the RTP receiver would not be able to 196 infer how many and which original packets (which sequence numbers) 197 were lost. 199 In other words, this approach does not satisfy the sequence number 200 preservation requirement (requirement 6). This in turn implies 201 that requirement 4 would not be met. Interoperability with mixers 202 and translators would also be more difficult if they did not 203 understand this new retransmission payload type in a sender RTP 204 stream. For these reasons, a solution based on payload type 205 multiplexing of original packets and retransmission packets in the 206 same RTP stream is excluded. 208 Finally, the original and retransmission packets may be sent in 209 two separate streams. These two streams may be multiplexed either 210 by sending them in two different sessions , i.e. session- 211 multiplexing, or in the same session using different SSRC values, 212 i.e. SSRC-multiplexing. Since original and retransmission packets 213 carry media of the same type, the objections in Section 5.2 of RTP 214 [3] to RTP multiplexing do not apply in this case. 216 Mixers and translators may process the original stream and simply 217 discard the retransmission stream if they are unable to utilise 218 it. Using two separate streams thus satisfies all the 219 requirements listed in this section. 221 3.1 Multiplexing scheme choice 223 Session-multiplexing and SSRC-multiplexing have different pros and 224 cons: 226 Session-multiplexing is based on sending the retransmission stream 227 in a different RTP session (as defined in RTP [3]) from that of 228 the original stream, i.e. the original and retransmission streams 229 are sent to different network addresses and/or port numbers. 231 Having a separate session allows more flexibility. In multicast, 232 using two separate sessions for the original and the 233 retransmission streams allows a receiver to choose whether or not 234 to subscribe to the RTP session carrying the retransmission 235 stream. The original session may also be single-source multicast 236 while separate unicast sessions are used to convey retransmissions 237 to each of the receivers, which as a result will receive only the 238 retransmission packets they request. 240 The use of separate sessions also facilitates differential 241 treatment by the network and may simplify processing in mixers, 242 translators and packet caches. 244 With SSRC-multiplexing, a single session is needed for the 245 original and the retransmission stream. This allows streaming 246 servers and middleware which are involved in a high number of 247 concurrent sessions to minimise their port usage. 249 This retransmission payload format allows both session- 250 multiplexing and SSRC-multiplexing for unicast sessions. From an 251 implementation point of view, there is little difference between 252 the two approaches. Hence, in order to maximise interoperability, 253 both multiplexing approaches SHOULD be supported by senders and 254 receivers. For multicast sessions, session-multiplexing MUST be 255 used because the association of the original stream and the 256 retransmission stream is problematic if SSRC-multiplexing is used 257 with multicast sessions(see Section 5.3 for motivation). 259 4. Retransmission payload format 261 The format of a retransmission packet is shown below: 263 0 1 2 3 264 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | RTP Header | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | OSN | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 270 | Original RTP Packet Payload | 271 | | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 The RTP header usage is as follows: 276 In the case of session-multiplexing, the same SSRC value MUST be 277 used for the original stream and the retransmission stream. In 278 the case of an SSRC collision in either the original session or 279 the retransmission session, the RTP specification requires that an 280 RTCP BYE packet MUST be sent in the session where the collision 281 happened. In addition, an RTCP BYE packet MUST also be sent for 282 the associated stream in its own session. After a new SSRC 283 identifier is obtained, the SSRC of both streams MUST be set to 284 this value. 286 In the case of SSRC-multiplexing, two different SSRC values MUST 287 be used for the original stream and the retransmission stream as 288 required by RTP. If an SSRC collision is detected for either the 289 original stream or the retransmission stream, the RTP 290 specification requires that an RTCP BYE packet MUST be sent for 291 this stream. An RTCP BYE packet MUST NOT be sent for the 292 associated stream. Therefore, only the stream that experienced 293 SSRC collision will choose a new SSRC value. Refer to Section 5.3 294 for the implications on the original and retransmission stream 295 SSRC association at the receiver. 297 For either multiplexing scheme, the sequence number has the 298 standard definition, i.e. it MUST be one higher than the sequence 299 number of the preceding packet sent in the retransmission stream. 301 The retransmission packet timestamp is set to the original 302 timestamp, i.e. to the timestamp of the original packet. As a 303 consequence, the initial RTP timestamp for the first packet of the 304 retransmission stream is not random but equal to the original 305 timestamp of the first packet that is retransmitted. See the 306 security considerations section in this document for security 307 implications. 309 Implementers have to be aware that the RTCP jitter value for the 310 retransmission stream does not reflect the actual network jitter 311 since there could be little correlation between the time a packet 312 is retransmitted and its original timestamp. 314 The payload type is dynamic. Each payload type of the original 315 stream MUST map to a different payload type value in the 316 retransmission stream. Therefore, when multiple payload types are 317 used in the original stream, multiple dynamic payload types will 318 be mapped to the retransmission payload format. See Section 8.1 319 for the specification of how the mapping between original and 320 retransmission payload types is done with SDP. 322 As the retransmission packet timestamp carries the original media 323 timestamp, the timestamp clockrate used by the retransmission 324 payload type is the same as the one used by the associated 325 original payload type. Therefore, if an RTP stream carries 326 payload types of different clockrates, this will also be the case 327 for the associated retransmission stream. Note that an RTP stream 328 does not usually carry payload types of different clockrates. 330 The payload of the RTP retransmission packet comprises the 331 retransmission payload header followed by the payload of the 332 original RTP packet. The length of the retransmission payload 333 header is 2 octets. This payload header contains only one field, 334 OSN (original sequence number), which MUST be set to the sequence 335 number of the associated original RTP packet. The original RTP 336 packet payload, including any possible payload headers specific to 337 the original payload type, is placed right after the 338 retransmission payload header. 340 For payload formats that support encoding at multiple rates, 341 instead of retransmitting the same payload as the original RTP 342 packet the sender MAY retransmit the same data encoded at a lower 343 rate. This aims at limiting the bandwidth usage of the 344 retransmission stream. When doing so, the sender MUST ensure that 345 the receiver will still be able to decode the payload of the 346 already sent original packets that might have been encoded based 347 on the payload of the lost original packet. In addition, if the 348 sender chooses to retransmit at a lower rate, the values in the 349 payload header of the original RTP packet may not longer apply to 350 the retransmission packet and may need to be modified in the 351 retransmission packet to reflect the change in rate. The sender 352 should trade-off the decrease in bandwidth usage with the decrease 353 in quality caused by resending at a lower rate. 355 If the original RTP header carried any profile-specific 356 extensions, the retransmission packet SHOULD include the same 357 extensions immediately following the fixed RTP header as expected 358 by applications running under this profile. In this case, the 359 retransmission payload header is thus placed after the profile- 360 specific extensions. 362 If the original RTP header carried an RTP header extension, the 363 retransmission packet SHOULD carry the same header extension. 364 This header extension MUST be placed right after the fixed RTP 365 header, as specified in RTP [3]. In this case, the retransmission 366 payload header is thus placed after the header extension. 368 If the original RTP packet contained RTP padding, that padding 369 MUST be removed before constructing the retransmission packet. If 370 padding of the retransmission packet is needed, padding is 371 performed as with any RTP packets and the padding bit is set. 373 The marker bit (M), the CSRC count (CC) and the CSRC list of the 374 original RTP header MUST be copied "as is" into the RTP header of 375 the retransmission packet. 377 5. Association of a retransmission stream to its original stream 379 5.1 Retransmission session sharing 381 In the case of session-multiplexing, a retransmission session MUST 382 map to exactly one original session, i.e. the same retransmission 383 session cannot be used for different original sessions. 385 If retransmission session sharing were allowed, it would be a 386 problem for receivers, since they would receive retransmissions 387 for original sessions they might not have joined. For example, a 388 receiver wishing to receive only audio would receive also 389 retransmitted video packets if an audio and video session shared 390 the same retransmission session. 392 5.2 CNAME use 394 In both the session-multiplexing and the SSRC-multiplexing cases, 395 a sender MUST use the same CNAME for an original stream and its 396 associated retransmission stream. 398 5.3 Association at the receiver 400 A receiver receiving multiple original and retransmission streams 401 needs to associate each retransmission stream with its original 402 stream. The association is done differently depending on whether 403 session-multiplexing or SSRC-multiplexing is used. 405 If session-multiplexing is used, the receiver associates the two 406 streams having the same SSRC in the two sessions. Note that the 407 payload type field cannot be used to perform the association as 408 several media streams may have the same payload type value. The 409 two sessions are themselves associated out-of-band. See Section 8 410 for how the grouping of the two sessions is done with SDP. 412 If SSRC-multiplexing is used, the receiver should first of all 413 look for two streams that have the same CNAME in the session. In 414 some cases, the CNAME may not be enough to determine the 415 association as multiple original streams in the same session may 416 share the same CNAME. For example, there can be in the same video 417 session multiple video streams mapping to different SSRCs and 418 still using the same CNAME and possibly the same PT values. Each 419 (or some) of these streams may have an associated retransmission 420 stream. 422 In this case, in order to find out the association between 423 original and retransmission streams having the same CNAME, the 424 receiver SHOULD behave as follows. 426 The association can generally be resolved when the receiver 427 receives a retransmission packet matching a retransmission request 428 which had been sent earlier. Upon reception of a retransmission 429 packet whose original sequence number has been previously 430 requested, the receiver can derive that the SSRC of the 431 retransmission packet is associated to the sender SSRC from which 432 the packet was requested. 434 However, this mechanism might fail if there are two outstanding 435 requests for the same packet sequence number in two different 436 original streams of the session. Note that since the initial 437 packet sequence numbers are random, the probability of having two 438 outstanding requests for the same packet sequence number would be 439 very small. Nevertheless, in order to avoid ambiguity in the 440 unicast case, the receiver MUST NOT have two outstanding requests 441 for the same packet sequence number in two different original 442 streams before the association is resolved. In multicast, this 443 ambiguity cannot be completely avoided, because another receiver 444 may have requested the same sequence number from another stream. 445 Therefore, SSRC-multiplexing MUST NOT be used in multicast 446 sessions. 448 If the receiver discovers that two senders are using the same SSRC 449 or if it receives an RTCP BYE packet, it MUST stop requesting 450 retransmissions for that SSRC. Upon reception of original RTP 451 packets with a new SSRC, the receiver MUST perform the SSRC 452 association again as described in this section. 454 6. Use with the extended RTP profile for RTCP-based feedback 456 This section gives general hints for the usage of this payload 457 format with the extended RTP profile for RTCP-based feedback, 458 denoted AVPF [1]. Note that the general RTCP send and receive 459 rules and the RTCP packet format as specified in RTP apply, except 460 for the changes that the AVPF profile introduces. In short, the 461 AVPF profile relaxes the RTCP timing rules and specifies 462 additional general-purpose RTCP feedback messages. See [1] for 463 details. 465 6.1 RTCP at the sender 467 In the case of session-multiplexing, Sender Report (SR) packets 468 for the original stream are sent in the original session and SR 469 packets for the retransmission stream are sent in the 470 retransmission session according to the rules of RTP. 472 In the case of SSRC-multiplexing, SR packets for both original and 473 retransmission streams are sent in the same session according to 474 the rules of RTP. The original and retransmission streams are 475 seen, as far the RTCP bandwidth calculation is concerned, as 476 independent senders belonging to the same RTP session and are thus 477 equally sharing the RTCP bandwidth assigned to senders. 479 Note that in both cases, session- and SSRC-multiplexing, BYE 480 packets MUST still be sent for both streams as specified in RTP. 481 In other words, it is not enough to send BYE packets for the 482 original stream only. 484 6.2 RTCP Receiver Reports 486 In the case of session-multiplexing, the receiver will send report 487 blocks for the original stream and the retransmission stream in 488 separate Receiver Report (RR) packets belonging to separate RTP 489 sessions. RR packets reporting on the original stream are sent in 490 the original RTP session while RR packets reporting on the 491 retransmission stream are sent in the retransmission session. The 492 RTCP bandwidth for these two sessions may be chosen independently 493 (for example through RTCP bandwidth modifiers [4]). 495 In the case of SSRC-multiplexing, the receiver sends report blocks 496 for the original and the retransmission streams in the same RR 497 packet since there is a single session. 499 6.3 Retransmission requests 501 The NACK feedback message format defined in the AVPF profile 502 SHOULD be used by receivers to send retransmission requests. 503 Whether a receiver chooses to request a packet or not is an 504 implementation issue. An actual receiver implementation should 505 take into account such factors as the tolerable application delay, 506 the network environment and the media type. 508 The receiver should generally assess whether the retransmitted 509 packet would still be useful at the time it is received. The 510 timestamp of the missing packet can be estimated from the 511 timestamps of packets preceding and/or following the sequence 512 number gap caused by the missing packet in the original stream. 513 In most cases, some form of linear estimate of the timestamp is 514 good enough. 516 Furthermore, a receiver should compute an estimate of the round- 517 trip time (RTT) to the sender. This can be done, for example, by 518 measuring the retransmission delay to receive a retransmission 519 packet after a NACK has been sent for that packet. This estimate 520 may also be obtained from past observations, RTCP report round- 521 trip time if available or any other means. A standard mechanism 522 for the receiver to estimate the RTT is specified in RTP Extended 523 Reports [11]. 525 The receiver should not send a retransmission request as soon as 526 it detects a missing sequence number but should add some extra 527 delay to compensate for packet reordering. This extra delay may, 528 for example, be based on past observations of the experienced 529 packet reordering. 531 To increase the robustness to the loss of a NACK or of a 532 retransmission packet, a receiver may send a new NACK for the same 533 packet. This is referred to as multiple retransmissions. Before 534 sending a new NACK for a missing packet, the receiver should rely 535 on a timer to be reasonably sure that the previous retransmission 536 attempt has failed in order to avoid unnecessary retransmissions. 538 NACKs MUST be sent only for the original RTP stream. Otherwise, 539 if a receiver wanted to perform multiple retransmissions by 540 sending a NACK in the retransmission stream, it would not be able 541 to know the original sequence number and a timestamp estimation of 542 the packet it requests. 544 6.4 Timing rules 546 The NACK feedback message may be sent in a regular full compound 547 RTCP packet or in an early RTCP packet, as per AVPF [1]. Sending 548 a NACK in an early packet allows to react more quickly to a given 549 packet loss. However, in that case if a new packet loss occurs 550 right after the early RTCP packet was sent, the receiver will then 551 have to wait for the next regular RTCP compound packet after the 552 early packet. Sending NACKs only in regular RTCP compound 553 decreases the maximum delay between detecting an original packet 554 loss and being able to send a NACK for that packet. Implementers 555 should consider the possible implications of this fact for the 556 application being used. 558 Furthermore, receivers may make use of the minimum interval 559 between regular RTCP compound packets. This interval can be used 560 to keep regular receiver reporting down to a minimum, while still 561 allowing receivers to send early RTCP packets during periods 562 requiring more frequent feedback, e.g. times of higher packet loss 563 rate. Note that although RTCP packets may be suppressed because 564 they do not contain NACKs, the same RTCP bandwidth as if they were 565 sent needs to be available. See AVPF [1] for details on the use 566 of the minimum interval. 568 7. Congestion control 570 RTP retransmission poses a risk of increasing network congestion. 571 In a best-effort environment, packet loss is caused by congestion. 572 Reacting to loss by retransmission of older data without 573 decreasing the rate of the original stream would thus further 574 increase congestion. Implementations SHOULD follow the 575 recommendations below in order to use retransmission. 577 The RTP profile under which the retransmission scheme is used 578 defines an appropriate congestion control mechanism in different 579 environments. Following the rules under the profile, an RTP 580 application can determine its acceptable bitrate and packet rate 581 in order to be fair to other TCP or RTP flows. 583 If an RTP application uses retransmission, the acceptable packet 584 rate and bitrate includes both the original and retransmitted 585 data. This guarantees that an application using retransmission 586 achieves the same fairness as one that does not. Such a rule 587 would translate in practice into the following actions: 589 If enhanced service is used, it should be made sure that the total 590 bitrate and packet rate do not exceed that of the requested 591 service. It should be further monitored that the requested 592 services are actually delivered. In a best-effort environment, 593 the sender SHOULD NOT send retransmission packets without reducing 594 the packet rate and bitrate of the original stream (for example by 595 encoding the data at a lower rate). 597 In addition, the sender MAY selectively retransmit only the 598 packets that it deems important and ignore NACK messages for other 599 packets in order to limit the bitrate. 601 These congestion control mechanisms should keep the packet loss 602 rate within acceptable parameters. Packet loss is considered 603 acceptable if a TCP flow across the same network path and 604 experiencing the same network conditions would achieve, on a 605 reasonable timescale, an average throughput, that is not less than 606 the one the RTP flow achieves. If the packet loss rate exceeds an 607 acceptable level, it SHOULD be concluded that congestion is not 608 kept under control and retransmission SHOULD NOT then be used. It 609 may further be necessary to adapt the transmission rate (or the 610 number of layers subscribed for a layered multicast session), or 611 to arrange for the receiver to leave the session. 613 8. Retransmission Payload Format MIME type registration 615 8.1 Introduction 617 The following MIME subtype name and parameters are introduced in 618 this document: "rtx", "rtx-time" and "apt". 620 The binding used for the retransmission stream to the payload type 621 number is indicated by an rtpmap attribute. The MIME subtype name 622 used in the binding is "rtx". 624 The "apt" (associated payload type) parameter MUST be used to map 625 the retransmission payload type to the associated original stream 626 payload type. If multiple original payload types are used, then 627 multiple "apt" parameters MUST be included to map each original 628 payload type to a different retransmission payload type. 630 An OPTIONAL payload-format-specific parameter, "rtx-time", 631 indicates the maximum time a sender will keep an original RTP 632 packet in its buffers available for retransmission. This time 633 starts with the first transmission of the packet. 635 The syntax is as follows: 637 a=fmtp: apt=;rtx-time= 638 where, 640 : indicates the dynamic payload type number assigned 641 to the retransmission payload format in an rtpmap attribute. 643 : the value of the original stream payload type to 644 which this retransmission stream payload type is associated. 646 : specifies the time in milliseconds (measured 647 from the time a packet was first sent) that a sender keeps an 648 RTP packet in its buffers available for retransmission. The 649 absence of the rtx-time parameter for a retransmission stream 650 means that the maximum retransmission time is not defined, 651 but MAY be negotiated by other means. 653 8.2 Registration of audio/rtx 655 MIME type: audio 657 MIME subtype: rtx 659 Required parameters: 661 rate: the RTP timestamp clockrate is equal to the RTP 662 timestamp clockrate of the media that is retransmitted. 664 apt: associated payload type. The value of this parameter is 665 the payload type of the associated original stream. 667 Optional parameters: 669 rtx-time: indicates the time in milliseconds (measured from 670 the time a packet was first sent) that the sender keeps an 671 RTP packet in its buffers available for retransmission. 673 Encoding considerations: this type is only defined for transfer 674 via RTP. 676 Security considerations: see Section 12 of RFC XXXX 678 Interoperability considerations: none 680 Published specification: RFC XXXX 682 Applications which use this media type: multimedia streaming 683 applications 685 Additional information: none 687 Person & email address to contact for further information: 688 rey@panasonic.de 689 david.leon@nokia.com 690 avt@ietf.org 692 Intended usage: COMMON 694 Author/Change controller: 695 Jose Rey 696 David Leon 697 IETF AVT WG 699 8.3 Registration of video/rtx 701 MIME type: video 703 MIME subtype: rtx 705 Required parameters: 707 rate: the RTP timestamp clockrate is equal to the RTP 708 timestamp clockrate of the media that is retransmitted. 710 apt: associated payload type. The value of this parameter is 711 the payload type of the associated original stream. 713 Optional parameters: 715 rtx-time: indicates the time in milliseconds (measured from 716 the time a packet was first sent) that the sender keeps an 717 RTP packet in its buffers available for retransmission. 719 Encoding considerations: this type is only defined for transfer 720 via RTP. 722 Security considerations: see Section 12 of RFC XXXX 724 Interoperability considerations: none 726 Published specification: RFC XXXX 728 Applications which use this media type: multimedia streaming 729 applications 731 Additional information: none 733 Person & email address to contact for further information: 734 rey@panasonic.de 735 david.leon@nokia.com 736 avt@ietf.org 738 Intended usage: COMMON 740 Author/Change controller: 741 Jose Rey 742 David Leon 743 IETF AVT WG 745 8.4 Registration of text/rtx 747 MIME type: text 749 MIME subtype: rtx 751 Required parameters: 753 rate: the RTP timestamp clockrate is equal to the RTP 754 timestamp clockrate of the media that is retransmitted. 756 apt: associated payload type. The value of this parameter is 757 the payload type of the associated original stream. 759 Optional parameters: 761 rtx-time: indicates the time in milliseconds (measured from 762 the time a packet was first sent) that the sender keeps an 763 RTP packet in its buffers available for retransmission. 765 Encoding considerations: this type is only defined for transfer 766 via RTP. 768 Security considerations: see Section 12 of RFC XXXX 770 Interoperability considerations: none 772 Published specification: RFC XXXX 774 Applications which use this media type: multimedia streaming 775 applications 777 Additional information: none 779 Person & email address to contact for further information: 780 rey@panasonic.de 781 david.leon@nokia.com 782 avt@ietf.org 784 Intended usage: COMMON 786 Author/Change controller: 787 Jose Rey 788 David Leon 789 IETF AVT WG 791 8.5 Registration of application/rtx 793 MIME type: application 795 MIME subtype: rtx 797 Required parameters: 799 rate: the RTP timestamp clockrate is equal to the RTP 800 timestamp clockrate of the media that is retransmitted. 802 apt: associated payload type. The value of this parameter is 803 the payload type of the associated original stream. 805 Optional parameters: 807 rtx-time: indicates the time in milliseconds (measured from 808 the time a packet was first sent) that the sender keeps an 809 RTP packet in its buffers available for retransmission. 811 Encoding considerations: this type is only defined for transfer 812 via RTP. 814 Security considerations: see Section 12 of RFC XXXX 816 Interoperability considerations: none 818 Published specification: RFC XXXX 820 Applications which use this media type: multimedia streaming 821 applications 823 Additional information: none 825 Person & email address to contact for further information: 826 rey@panasonic.de 827 david.leon@nokia.com 828 avt@ietf.org 830 Intended usage: COMMON 832 Author/Change controller: 833 Jose Rey 834 David Leon 835 IETF AVT WG 837 8.6 Mapping to SDP 839 The information carried in the MIME media type specification has a 840 specific mapping to fields in SDP [5], which is commonly used to 841 describe RTP sessions. When SDP is used to specify 842 retransmissions for an RTP stream, the mapping is done as 843 follows: 845 - The MIME types ("video"), ("audio"), ("text") and 846 ("application") go in the SDP "m=" as the media name. 848 - The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding 849 name. The RTP clock rate in "a=rtpmap" MUST be that of the 850 retransmission payload type. See Section 4 for details on this. 852 - The AVPF profile-specific parameters "ack" and "nack" go in SDP 853 "a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types 854 of feedback. See the AVPF profile [1] for details. 856 - The retransmission payload-format-specific parameters "apt" and 857 "rtx-time" go in the SDP "a=fmtp" as a semicolon separated list of 858 parameter=value pairs. 860 - Any remaining parameters go in the SDP "a=fmtp" attribute by 861 copying them directly from the MIME media type string as a 862 semicolon separated list of parameter=value pairs. 864 In the following sections some example SDP descriptions are 865 presented. In some of these examples, long lines are folded to 866 meet the column width constraints of this document; the backslash 867 ("\") at the end of a line and the carriage return that follows it 868 should be ignored. 870 8.7 SDP description with session-multiplexing 872 In the case of session-multiplexing, the SDP description contains 873 one media specification "m" line per RTP session. The SDP MUST 874 provide the grouping of the original and associated retransmission 875 sessions' "m" lines, using the Flow Identification (FID) semantics 876 defined in RFC 3388 [6]. 878 The following example specifies two original, AMR and MPEG-4, 879 streams on ports 49170 and 49174 and their corresponding 880 retransmission streams on ports 49172 and 49176, respectively: 882 v=0 883 o=mascha 2980675221 2980675778 IN IP4 host.example.net 884 c=IN IP4 192.0.2.0 885 a=group:FID 1 2 886 a=group:FID 3 4 887 m=audio 49170 RTP/AVPF 96 888 a=rtpmap:96 AMR/8000 889 a=fmtp:96 octet-align=1 890 a=rtcp-fb:96 nack 891 a=mid:1 892 m=audio 49172 RTP/AVPF 97 893 a=rtpmap:97 rtx/8000 894 a=fmtp:97 apt=96;rtx-time=3000 895 a=mid:2 896 m=video 49174 RTP/AVPF 98 897 a=rtpmap:98 MP4V-ES/90000 898 a=rtcp-fb:98 nack 899 a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\ 900 0A21F 901 a=mid:3 902 m=video 49176 RTP/AVPF 99 903 a=rtpmap:99 rtx/90000 904 a=fmtp:99 apt=98;rtx-time=3000 905 a=mid:4 906 A special case of the SDP description is a description that 907 contains only one original session "m" line and one retransmission 908 session "m" line, the grouping is then obvious and FID semantics 909 MAY be omitted in this special case only. 911 This is illustrated in the following example, which is an SDP 912 description for a single original MPEG-4 stream and its 913 corresponding retransmission session: 915 v=0 916 o=mascha 2980675221 2980675778 IN IP4 host.example.net 917 c=IN IP4 192.0.2.0 918 m=video 49170 RTP/AVPF 96 919 a=rtpmap:96 MP4V-ES/90000 920 a=rtcp-fb:96 nack 921 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\ 922 0A21F 923 m=video 49172 RTP/AVPF 97 924 a=rtpmap:97 rtx/90000 925 a=fmtp:97 apt=96;rtx-time=3000 927 8.8 SDP description with SSRC-multiplexing 929 The following is an example of an SDP description for an RTP video 930 session using SSRC-multiplexing with similar parameters as in the 931 single-session example above: 933 v=0 934 o=mascha 2980675221 2980675778 IN IP4 host.example.net 935 c=IN IP4 192.0.2.0 936 m=video 49170 RTP/AVPF 96 97 937 a=rtpmap:96 MP4V-ES/90000 938 a=rtcp-fb:96 nack 939 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\ 940 0A21F 941 a=rtpmap:97 rtx/90000 942 a=fmtp:97 apt=96;rtx-time=3000 944 9. RTSP considerations 946 The Real-time Streaming Protocol (RTSP), RFC 2326 [7] is an 947 application-level protocol for control over the delivery of data 948 with real-time properties. This section looks at the issues 949 involved in controlling RTP sessions that use retransmissions. 951 9.1 RTSP control with SSRC-multiplexing 953 In the case of SSRC-multiplexing, the "m" line includes both 954 original and retransmission payload types and has a single RTSP 955 "control" attribute. The receiver uses the "m" line to request 956 SETUP and TEARDOWN of the whole media session. The RTP profile 957 contained in the Transport header MUST be the AVPF profile or 958 another suitable profile allowing extended feedback. If the SSRC 959 value is included in the SETUP response's Transport header, it 960 MUST be that of the original stream. 962 In order to control the sending of the session original media 963 stream, the receiver sends as usual PLAY and PAUSE requests to the 964 sender for the session. The RTP-info header that is used to set 965 RTP-specific parameters in the PLAY response MUST be set according 966 to the RTP information of the original stream. 968 When the receiver starts receiving the original stream, it can 969 then request retransmission through RTCP NACKs without additional 970 RTSP signalling. 972 9.2 RTSP control with session-multiplexing 974 In the case of session-multiplexing, each SDP "m" line has an RTSP 975 "control" attribute. Hence, when retransmission is used, both the 976 original session and the retransmission have their own "control" 977 attributes. The receiver can associate the original session and 978 the retransmission session through the FID semantics as specified 979 in Section 8. 981 The original and the retransmission streams are set up and torn 982 down separately through their respective media "control" 983 attribute. The RTP profile contained in the Transport header MUST 984 be the AVPF profile or another suitable profile allowing extended 985 feedback for both the original and the retransmission session. 987 The RTSP presentation SHOULD support aggregate control and SHOULD 988 contain a session level RTSP URL. The receiver SHOULD use 989 aggregate control for an original session and its associated 990 retransmission session. Otherwise, there would need to be two 991 different 'session-id' values, i.e. different values for the 992 original and retransmission sessions, and the sender would not 993 know how to associate them. 995 The session-level "control" attribute is then used as usual to 996 control the playing of the original stream. When the receiver 997 starts receiving the original stream, it can then request 998 retransmissions through RTCP without additional RTSP signalling. 1000 9.3 RTSP control of the retransmission stream 1002 Because of the nature of retransmissions, the sending of 1003 retransmission packets SHOULD NOT be controlled through RTSP PLAY 1004 and PAUSE requests. The PLAY and PAUSE requests SHOULD NOT affect 1005 the retransmission stream. Retransmission packets are sent upon 1006 receiver requests in the original RTCP stream, regardless of the 1007 state. 1009 9.4 Cache control 1010 Retransmission streams SHOULD NOT be cached. 1012 In the case of session-multiplexing, the "Cache-Control" header 1013 SHOULD be set to "no-cache" for the retransmission stream. 1015 In the case of SSRC-multiplexing, RTSP cannot specify independent 1016 caching for the retransmission stream, because there is a single 1017 "m" line in SDP. Therefore, the implementer should take this fact 1018 into account when deciding whether to cache an SSRC-multiplexed 1019 session or not. 1021 10. Implementation examples 1023 This document mandates only the sender and receiver behaviours 1024 that are necessary for interoperability. In addition, certain 1025 algorithms, such as rate control or buffer management when 1026 targeted at specific environments, may enhance the retransmission 1027 efficiency. 1029 This section gives an overview of different implementation options 1030 allowed within this specification. 1032 The first example describes a minimal receiver implementation. 1033 With this implementation, it is possible to retransmit lost RTP 1034 packets, detect efficiently the loss of retransmissions and 1035 perform multiple retransmissions, if needed. Most of the 1036 necessary processing is done at the server. 1038 The second example shows how a receiver may implement additional 1039 enhancements that might help reduce sender buffer requirements and 1040 optimise the retransmission efficiency 1042 The third example shows how retransmissions may be used in (small) 1043 multicast groups in conjunction with layered encoding. It 1044 illustrates that retransmissions and layered encoding may be 1045 complementary techniques. 1047 10.1 A minimal receiver implementation example 1049 This section gives an example of an implementation supporting 1050 multiple retransmissions. The sender transmits the original data 1051 in RTP packets using the MPEG-4 video RTP payload format. 1052 It is assumed that NACK feedback messages are used, as per 1053 [1]. An SDP description example with SSRC-multiplexing is given 1054 below: 1056 v=0 1057 o=mascha 2980675221 2980675778 IN IP4 host.example.net 1058 c=IN IP4 192.0.2.0 1059 m=video 49170 RTP/AVPF 96 97 1060 a=rtpmap:96 MP4V-ES/90000 1061 a=rtcp-fb:96 nack 1062 a=rtpmap:97 rtx/90000 1063 a=fmtp:97 apt=96;rtx-time=3000 1065 The format-specific parameter "rtx-time" indicates that the server 1066 will buffer the sent packets in a retransmission buffer for 3.0 1067 seconds, after which the packets are deleted from the 1068 retransmission buffer and will never be sent again. 1070 In this implementation example, the required RTP receiver 1071 processing to handle retransmission is kept to a minimum. The 1072 receiver detects packet loss from the gaps observed in the 1073 received sequence numbers. It signals lost packets to the sender 1074 through NACKs as defined in the AVPF profile [1]. The receiver 1075 should take into account the signalled sender retransmission 1076 buffer length in order to dimension its own reception buffer. It 1077 should also derive from the buffer length the maximum number of 1078 times the retransmission of a packet can be requested. 1080 The sender should retransmit the packets selectively, i.e. it 1081 should choose whether to retransmit a requested packet depending 1082 on the packet importance, the observed QoS and congestion state of 1083 the network connection to the receiver. Obviously, the sender 1084 processing increases with the number of receivers as state 1085 information and processing load must be allocated to each 1086 receiver. 1088 10.2 An enhanced receiver implementation example 1090 The receiver may have more accurate information than the sender 1091 about the current network QoS such as available bandwidth, packet 1092 loss rate, delay and jitter. In addition, other receiver-specific 1093 parameters such as buffer level, estimated importance of the lost 1094 packet and application level QoS may be used by the receiver to 1095 make a more efficient use of RTP retransmission by selectively 1096 sending NACKs for important lost packets and not for others. For 1097 example, a receiver may decide to suppress a request for a packet 1098 loss that could be concealed locally, or for a retransmission that 1099 would arrive late. 1101 Furthermore, a receiver may acknowledge the received packets. 1102 This can be done by sending ACKs, as per [1]. Upon receiving an 1103 ACK, the sender may delete all the acknowledged packets from its 1104 retransmission buffer. Note that this would also require only 1105 limited increase in the required RTCP bandwidth as long as ACK 1106 packets are sent seldom enough. 1108 This implementation may help reduce buffer requirements at the 1109 sender and optimise the performance of the implementation by using 1110 selective requests. 1112 Note that these receiver enhancements do not need to be negotiated 1113 as they do not affect the sender implementation. However, in 1114 order to allow the receiver to acknowledge packets, it is needed 1115 to allow the use of ACKs in the SDP description, by means of an 1116 additional SDP "a=rtcp-fb" line, as follows: 1118 v=0 1119 o=mascha 2980675221 2980675778 IN IP4 host.example.net 1120 c=IN IP4 192.0.2.0 1121 m=video 49170 RTP/AVPF 96 97 1122 a=rtpmap:96 MP4V-ES/90000 1123 a=rtcp-fb:96 nack 1124 a=rtcp-fb:96 ack 1125 a=rtpmap:97 rtx/90000 1126 a=fmtp:97 apt=96;rtx-time=3000 1128 10.3 Retransmission of Layered Encoded Media in Multicast 1130 This section shows how to combine retransmissions with layered 1131 encoding in multicast sessions. Note that the retransmission 1132 framework is not intended as a complete solution to reliable 1133 multicast. Refer to RFC 2887 [10], for an overview of the 1134 problems related with reliable multicast transmission. 1136 Packets of different importance are sent in different RTP 1137 sessions. The retransmission streams corresponding to the 1138 different layers can themselves be seen as different 1139 retransmission layers. The relative importance of the different 1140 retransmission streams should reflect the relative importance of 1141 the different original streams. 1143 In multicast, SSRC-multiplexing of the original and retransmission 1144 streams is not allowed as per Section 5.3 of this document. For 1145 this reason, the retransmission stream(s) MUST be sent in 1146 different RTP session(s) using session-multiplexing. 1148 An SDP description example of multicast retransmissions for 1149 layered encoded media is given below: 1151 m=video 8000 RTP/AVPF 98 1152 c=IN IP4 192.0.2.0/127/3 1153 a=rtpmap:98 MP4V-ES/90000 1154 a=rtcp-fb:98 nack 1155 m=video 8000 RTP/AVPF 99 1156 c=IN IP4 192.0.2.4/127/3 1157 a=rtpmap:99 rtx/90000 1158 a=fmtp:99 apt=98;rtx-time=3000 1160 The server and the receiver may implement the retransmission 1161 methods illustrated in the previous examples. In addition, they 1162 may choose to request and retransmit a lost packet depending on 1163 the layer it belongs to. 1165 11. IANA considerations 1166 A new MIME subtype name, "rtx", has been registered for four 1167 different media types, as follows: "video", "audio", "text" and 1168 "application". An additional REQUIRED parameter, "apt", and an 1169 OPTIONAL parameter, "rtx-time", are defined. See Section 8 for 1170 details. 1172 12. Security considerations 1174 If cryptography is used to provide security services on the 1175 original stream, then the same services, with equivalent 1176 cryptographic strength, MUST be provided on the retransmission 1177 stream. Old keys will likely need to be cached so that when the 1178 keys change for the original stream, the old key is used until it 1179 is determined that the key has changed on the retransmission 1180 packets as well. 1182 The use of the same key for the retransmitted stream and the 1183 original stream may lead to security problems, e.g. two-time pads. 1184 This sharing has to be evaluated towards the chosen security 1185 protocol and security algorithms. 1187 Furthermore, it is RECOMMENDED that the cryptography mechanisms 1188 used for this payload format provide protection against known 1189 plaintext attacks. RTP recommends that the initial RTP timestamp 1190 SHOULD be random to secure the stream against known plaintext 1191 attacks. This payload format does not follow this recommendation 1192 as the initial timestamp will be the media timestamp of the first 1193 retransmitted packet. However, since the initial timestamp of the 1194 original stream is itself random, if the original stream is 1195 encrypted, the first retransmitted packet timestamp would also be 1196 random to an attacker. Therefore, confidentiality would not be 1197 compromised. 1199 Congestion control considerations with the use of retransmission 1200 are dealt with in Section 7 of this document. 1202 Any other security considerations of the profile under which the 1203 retransmission scheme is used should be applied. The 1204 retransmission payload format MUST NOT be used under the SAVP 1205 profile defined by the Secure Real-Time Transport Protocol 1206 (SRTP)[12] but instead an extension of SRTP should be defined to 1207 secure the AVPF profile. The definition of such a profile is out 1208 of the scope of this document. 1210 13. Acknowledgements 1212 We would like to express our gratitude to Carsten Burmeister for 1213 his participation in the development of this document. Our thanks 1214 also go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus 1215 Westerlund, Go Hori and Rahul Agarwal for their helpful comments. 1217 14. References 1219 14.1 Normative References 1221 1 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP 1222 profile for RTCP-based feedback", draft-ietf-avt-rtcp-feedback- 1223 04.txt, September 2002. 1225 2 S. Bradner, "Key words for use in RFCs to Indicate Requirement 1226 Levels", BCP 14, RFC 2119, March 1997 1228 3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A 1229 Transport Protocol for Real-Time Applications", draft-ietf-avt- 1230 rtp-new-12.txt, March 2003. 1232 4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", draft- 1233 ietf-avt-rtcp-bw-05.txt, May 2002. 1235 5 M. Handley, V. Jacobson, "SDP: Session Description Protocol", 1236 RFC 2327, April 1998. 1238 6 G. Camarillo, J. Holler, G. AP. Eriksson, "Grouping of media 1239 lines in the Session Description Protocol (SDP)", RFC 3388, 1240 December 2002. 1242 7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming 1243 Protocol (RTSP)", RFC 2326, April 1998. 1245 14.2 Informative References 1247 8 C. Perkins, O. Hodson, "Options for Repair of Streaming Media", 1248 RFC 2354, June 1998. 1250 9 G. Hellstrom, "RTP for conversational text", RFC 2793, May 2000 1252 10 M. Handley, et al., "The Reliable Multicast Design Space for 1253 Bulk Data Transfer", RFC 2887, August 2000. 1255 11 Friedman, et. al., "RTP Extended Reports", Work in Progress. 1257 12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. 1258 Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", 1259 draft-ietf-avt-srtp-05.txt, June 2002. 1261 13 R. Hovey and S. Bradner, "The Organizations Involved in the IETF 1262 Standards Process," BCP 11, RFC 2028, IETF, October 1996. 1264 15. Author's Addresses 1266 Jose Rey rey@panasonic.de 1267 Panasonic European Laboratories GmbH 1268 Monzastr. 4c 1269 D-63225 Langen, Germany 1270 Phone: +49-6103-766-134 1271 Fax: +49-6103-766-166 1273 David Leon david.leon@nokia.com 1274 Nokia Research Center 1275 6000 Connection Drive 1276 Irving, TX. USA 1277 Phone: 1-972-374-1860 1279 Akihiro Miyazaki akihiro@isl.mei.co.jp 1280 Core Software Development Center 1281 Corporate Software Development Division 1282 Matsushita Electric Industrial Co., Ltd. 1283 1006 Kadoma, Kadoma City, Osaka 571-8501, Japan 1284 Phone: +81-6-6900-9192 1285 Fax: +81-6-6900-9193 1287 Viktor Varsa viktor.varsa@nokia.com 1288 Nokia Research Center 1289 6000 Connection Drive 1290 Irving, TX. USA 1291 Phone: 1-972-374-1861 1293 Rolf Hakenberg hakenberg@panasonic.de 1294 Panasonic European Laboratories GmbH 1295 Monzastr. 4c 1296 D-63225 Langen, Germany 1297 Phone: +49-6103-766-162 1298 Fax: +49-6103-766-166 1300 IPR Notices 1302 The IETF has been notified of intellectual property rights claimed 1303 in regard to some or all of the specification contained in this 1304 document. For more information consult the online list of claimed 1305 rights. 1307 The IETF takes no position regarding the validity or scope of any 1308 intellectual property or other rights that might be claimed to 1309 pertain to the implementation or use of the technology described 1310 in this document or the extent to which any license under such 1311 rights might or might not be available; neither does it represent 1312 that it has made any effort to identify any such rights. 1313 Information on the IETF's procedures with respect to rights in 1314 standards-track and standards-related documentation can be found 1315 in BCP 11 [13]. Copies of claims of rights made available for 1316 publication and any assurances of licenses to be made available, 1317 or the result of an attempt made to obtain a general license or 1318 permission for the use of such proprietary rights by implementers 1319 or users of this specification can be obtained from the IETF 1320 Secretariat. 1322 The IETF invites any interested party to bring to its attention 1323 any copyrights, patents or patent applications, or other 1324 proprietary rights which may cover technology that may be required 1325 to practice this standard. Please address the information to the 1326 IETF Executive Director. 1328 Full Copyright Statement 1330 Copyright (C) The Internet Society (2003). All Rights Reserved. 1332 This document and translations of it may be copied and furnished 1333 to others, and derivative works that comment on or otherwise 1334 explain it or assist in its implementation may be prepared, 1335 copied, published and distributed, in whole or in part, without 1336 restriction of any kind, provided that the above copyright notice 1337 and this paragraph are included on all such copies and derivative 1338 works. However, this document itself may not be modified in any 1339 way, such as by removing the copyright notice or references to the 1340 Internet Society or other Internet organizations, except as needed 1341 for the purpose of developing Internet standards in which case 1342 the procedures for copyrights defined in the Internet Standards 1343 process must be followed, or as required to translate it into 1344 languages other than English. 1346 The limited permissions granted above are perpetual and will 1347 not be revoked by the Internet Society or its successors or 1348 assigns. 1350 This document and the information contained herein is provided on 1351 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1352 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1353 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1354 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1355 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.