idnits 2.17.1 draft-ietf-avt-rtp-retransmission-10.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-10' == 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 1356 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 (January 2004) is 7399 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 1117 looks like a reference -- Missing reference section? '2' on line 155 looks like a reference -- Missing reference section? '9' on line 184 looks like a reference -- Missing reference section? '3' on line 381 looks like a reference -- Missing reference section? '4' on line 509 looks like a reference -- Missing reference section? '11' on line 539 looks like a reference -- Missing reference section? '5' on line 855 looks like a reference -- Missing reference section? '6' on line 891 looks like a reference -- Missing reference section? '7' on line 961 looks like a reference -- Missing reference section? '10' on line 1148 looks like a reference -- Missing reference section? '12' on line 1221 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 10.txt D. Leon/Nokia 5 A. Miyazaki/Matsushita 6 V. Varsa/Nokia 7 R. Hakenberg/Matsushita 9 Expires: July 2004 January 2004 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 (2004). 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..................................................2 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 With sufficient latency, the efficiency of the repair scheme can 90 be increased. The sender may use the receiver feedback in 91 order to react to losses before their playout time at the 92 receiver. 94 In the case of multimedia streaming, the user can tolerate an 95 initial latency as part of the session set-up and thus an end-to- 96 end delay of several seconds may be acceptable. RTP 97 retransmission as defined in this document is targeted at such 98 applications. 100 At this point, the attention of the reader is called to the fact 101 that the retransmission mechanism for RTP described in this 102 document may be encumbered by patent applications filed from 103 Matsushita. Please refer to the IPR Notices section for details. 105 Furthermore, the RTP retransmission method defined herein is 106 applicable to unicast and (small) multicast groups. The present 107 document defines a payload format for retransmitted RTP packets 108 and provides protocol rules for the sender and the receiver 109 involved in retransmissions. 111 This retransmission payload format was designed for use with the 112 extended RTP profile for RTCP-based feedback, AVPF [1]. It may 113 also be used with other RTP profiles defined in the future. 115 The AVPF profile allows for more frequent feedback and for early 116 feedback. It defines a small number of general-purpose feedback 117 messages, e.g. ACKs and NACKs, as well as codec and application- 118 specific feedback messages. See [1] for details. 120 2. Terminology 122 The following terms are used in this document: 124 Original packet: refers to an RTP packet which carries user data 125 sent for the first time by an RTP sender. 127 Original stream: refers to the RTP stream of original packets. 129 Retransmission packet: refers to an RTP packet which is to be used 130 by the receiver instead of a lost original packet. Such a 131 retransmission packet is said to be associated with the original 132 RTP packet. 134 Retransmission request: a means by which an RTP receiver is able 135 to request that the RTP sender should send a retransmission packet 136 for a given original packet. Usually, an RTCP NACK packet as 137 specified in [1] is used as retransmission request for lost 138 packets. 140 Retransmission stream: the stream of retransmission packets 141 associated with an original stream. 143 Session-multiplexing: scheme by which the original stream and the 144 associated retransmission stream are sent into two different RTP 145 sessions. 147 SSRC-multiplexing: scheme by which the original stream and the 148 retransmission stream are sent in the same RTP session with 149 different SSRC values. 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 152 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 153 in this document are to be interpreted as described in RFC 2119 154 [2]. 156 3. Requirements and design rationale for a retransmission scheme 158 The use of retransmissions in RTP as a repair method for streaming 159 media is appropriate in those scenarios with relaxed delay bounds 160 and where full reliability is not a requirement. More 161 specifically, RTP retransmission allows to trade-off reliability 162 vs. delay, i.e. the endpoints may give up retransmitting a lost 163 packet after a given buffering time has elapsed. Unlike TCP there 164 is thus no head-of-line blocking caused by RTP retransmissions. 165 The implementer should be aware that in cases where full 166 reliability is required or higher delay and jitter can be 167 tolerated, TCP or other transport options should be considered. 169 The RTP retransmission scheme defined in this document is designed 170 to fulfil the following set of requirements: 172 1. It must not break general RTP and RTCP mechanisms. 173 2. It must be suitable for unicast and small multicast groups. 174 3. It must work with mixers and translators. 175 4. It must work with all known payload types. 176 5. It must not prevent the use of multiple payload types in a 177 session. 178 6. In order to support the largest variety of payload formats, the 179 RTP receiver must be able to derive how many and which RTP 180 packets were lost as a result of a gap in received RTP sequence 181 numbers. This requirement is referred to as sequence number 182 preservation. Without such a requirement, it would be 183 impossible to use retransmission with payload formats, such as 184 conversational text [9] or most audio/video streaming 185 applications, that use the RTP sequence number to detect lost 186 packets. 188 When designing a solution for RTP retransmission, several 189 approaches may be considered for the multiplexing of the original 190 RTP packets and the retransmitted RTP packets. 192 One approach may be to retransmit the RTP packet with its original 193 sequence number and send original and retransmission packets in 194 the same RTP stream. The retransmission packet would then be 195 identical to the original RTP packet, i.e. the same header (and 196 thus same sequence number) and the same payload. However, such an 197 approach is not acceptable because it would corrupt the RTCP 198 statistics. As a consequence, requirement 1 would not be met. 199 Correct RTCP statistics require that for every RTP packet within 200 the RTP stream, the sequence number be increased by one. 202 Another approach may be to multiplex original RTP packets and 203 retransmission packets in the same RTP stream using different 204 payload type values. With such an approach, the original packets 205 and the retransmission packets would share the same sequence 206 number space. As a result, the RTP receiver would not be able to 207 infer how many and which original packets (which sequence numbers) 208 were lost. 210 In other words, this approach does not satisfy the sequence number 211 preservation requirement (requirement 6). This in turn implies 212 that requirement 4 would not be met. Interoperability with mixers 213 and translators would also be more difficult if they did not 214 understand this new retransmission payload type in a sender RTP 215 stream. For these reasons, a solution based on payload type 216 multiplexing of original packets and retransmission packets in the 217 same RTP stream is excluded. 219 Finally, the original and retransmission packets may be sent in 220 two separate streams. These two streams may be multiplexed either 221 by sending them in two different sessions , i.e. session- 222 multiplexing, or in the same session using different SSRC values, 223 i.e. SSRC-multiplexing. Since original and retransmission packets 224 carry media of the same type, the objections in Section 5.2 of RTP 225 [3] to RTP multiplexing do not apply in this case. 227 Mixers and translators may process the original stream and simply 228 discard the retransmission stream if they are unable to utilise 229 it. 231 On the other hand, sending the original and retransmission packets 232 in two separate streams does not alone satisfy requirements 1 and 233 6. For this purpose, this document includes the original sequence 234 number in the retransmitted packets. 236 In this manner, using two separate streams satisfies all the 237 requirements listed in this section. 239 3.1 Multiplexing scheme choice 241 Session-multiplexing and SSRC-multiplexing have different pros and 242 cons: 244 Session-multiplexing is based on sending the retransmission stream 245 in a different RTP session (as defined in RTP [3]) from that of 246 the original stream, i.e. the original and retransmission streams 247 are sent to different network addresses and/or port numbers. 248 Having a separate session allows more flexibility. In multicast, 249 using two separate sessions for the original and the 250 retransmission streams allows a receiver to choose whether or not 251 to subscribe to the RTP session carrying the retransmission 252 stream. The original session may also be single-source multicast 253 while separate unicast sessions are used to convey retransmissions 254 to each of the receivers, which as a result will receive only the 255 retransmission packets they request. 257 The use of separate sessions also facilitates differential 258 treatment by the network and may simplify processing in mixers, 259 translators and packet caches. 261 With SSRC-multiplexing, a single session is needed for the 262 original and the retransmission stream. This allows streaming 263 servers and middleware which are involved in a high number of 264 concurrent sessions to minimise their port usage. 266 This retransmission payload format allows both session- 267 multiplexing and SSRC-multiplexing for unicast sessions. From an 268 implementation point of view, there is little difference between 269 the two approaches. Hence, in order to maximise interoperability, 270 both multiplexing approaches SHOULD be supported by senders and 271 receivers. For multicast sessions, session-multiplexing MUST be 272 used because the association of the original stream and the 273 retransmission stream is problematic if SSRC-multiplexing is used 274 with multicast sessions(see Section 5.3 for motivation). 276 4. Retransmission payload format 278 The format of a retransmission packet is shown below: 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | RTP Header | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | OSN | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 287 | Original RTP Packet Payload | 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 The RTP header usage is as follows: 293 In the case of session-multiplexing, the same SSRC value MUST be 294 used for the original stream and the retransmission stream. In 295 the case of an SSRC collision in either the original session or 296 the retransmission session, the RTP specification requires that an 297 RTCP BYE packet MUST be sent in the session where the collision 298 happened. In addition, an RTCP BYE packet MUST also be sent for 299 the associated stream in its own session. After a new SSRC 300 identifier is obtained, the SSRC of both streams MUST be set to 301 this value. 303 In the case of SSRC-multiplexing, two different SSRC values MUST 304 be used for the original stream and the retransmission stream as 305 required by RTP. If an SSRC collision is detected for either the 306 original stream or the retransmission stream, the RTP 307 specification requires that an RTCP BYE packet MUST be sent for 308 this stream. An RTCP BYE packet MUST NOT be sent for the 309 associated stream. Therefore, only the stream that experienced 310 SSRC collision MUST choose a new SSRC value. Refer to Section 5.3 311 for the implications on the original and retransmission stream 312 SSRC association at the receiver. 314 For either multiplexing scheme, the sequence number has the 315 standard definition, i.e. it MUST be one higher than the sequence 316 number of the preceding packet sent in the retransmission stream. 318 The retransmission packet timestamp MUST be set to the original 319 timestamp, i.e. to the timestamp of the original packet. As a 320 consequence, the initial RTP timestamp for the first packet of the 321 retransmission stream is not random but equal to the original 322 timestamp of the first packet that is retransmitted. See the 323 security considerations section in this document for security 324 implications. 326 Implementers have to be aware that the RTCP jitter value for the 327 retransmission stream does not reflect the actual network jitter 328 since there could be little correlation between the time a packet 329 is retransmitted and its original timestamp. 331 The payload type is dynamic. If multiple payload types using 332 retransmission are present in the original stream, then for each 333 of these, a dynamic payload type MUST be mapped to the 334 retransmission payload format. See Section 8.1 for the 335 specification of how the mapping between original and 336 retransmission payload types is done with SDP. 338 As the retransmission packet timestamp carries the original media 339 timestamp, the timestamp clockrate used by the retransmission 340 payload type MUST be the same as the one used by the associated 341 original payload type. Therefore, if an RTP stream carries 342 payload types of different clockrates, this will also be the case 343 for the associated retransmission stream. Note that an RTP stream 344 does not usually carry payload types of different clockrates. 346 The payload of the RTP retransmission packet comprises the 347 retransmission payload header followed by the payload of the 348 original RTP packet. The length of the retransmission payload 349 header is 2 octets. This payload header contains only one field, 350 OSN (original sequence number), which MUST be set to the sequence 351 number of the associated original RTP packet. The original RTP 352 packet payload, including any possible payload headers specific to 353 the original payload type, MUST be placed right after the 354 retransmission payload header. 356 For payload formats that support encoding at multiple rates, 357 instead of retransmitting the same payload as the original RTP 358 packet the sender MAY retransmit the same data encoded at a lower 359 rate. This aims at limiting the bandwidth usage of the 360 retransmission stream. When doing so, the sender MUST ensure that 361 the receiver will still be able to decode the payload of the 362 already sent original packets that might have been encoded based 363 on the payload of the lost original packet. In addition, if the 364 sender chooses to retransmit at a lower rate, the values in the 365 payload header of the original RTP packet may not longer apply to 366 the retransmission packet and may need to be modified in the 367 retransmission packet to reflect the change in rate. The sender 368 SHOULD trade-off the decrease in bandwidth usage with the decrease 369 in quality caused by resending at a lower rate. 371 If the original RTP header carried any profile-specific 372 extensions, the retransmission packet SHOULD include the same 373 extensions immediately following the fixed RTP header as expected 374 by applications running under this profile. In this case, the 375 retransmission payload header MUST be placed after the profile- 376 specific extensions. 378 If the original RTP header carried an RTP header extension, the 379 retransmission packet SHOULD carry the same header extension. 380 This header extension MUST be placed right after the fixed RTP 381 header, as specified in RTP [3]. In this case, the retransmission 382 payload header MUST be placed after the header extension. 384 If the original RTP packet contained RTP padding, that padding 385 MUST be removed before constructing the retransmission packet. If 386 padding of the retransmission packet is needed, padding MUST be 387 performed as with any RTP packets and the padding bit MUST be set. 389 The marker bit (M), the CSRC count (CC) and the CSRC list of the 390 original RTP header MUST be copied "as is" into the RTP header of 391 the retransmission packet. 393 5. Association of a retransmission stream to its original stream 395 5.1 Retransmission session sharing 397 In the case of session-multiplexing, a retransmission session MUST 398 map to exactly one original session, i.e. the same retransmission 399 session cannot be used for different original sessions. 401 If retransmission session sharing were allowed, it would be a 402 problem for receivers, since they would receive retransmissions 403 for original sessions they might not have joined. For example, a 404 receiver wishing to receive only audio would receive also 405 retransmitted video packets if an audio and video session shared 406 the same retransmission session. 408 5.2 CNAME use 410 In both the session-multiplexing and the SSRC-multiplexing cases, 411 a sender MUST use the same CNAME for an original stream and its 412 associated retransmission stream. 414 5.3 Association at the receiver 416 A receiver receiving multiple original and retransmission streams 417 needs to associate each retransmission stream with its original 418 stream. The association is done differently depending on whether 419 session-multiplexing or SSRC-multiplexing is used. 421 If session-multiplexing is used, the receiver associates the two 422 streams having the same SSRC in the two sessions. Note that the 423 payload type field cannot be used to perform the association as 424 several media streams may have the same payload type value. The 425 two sessions are themselves associated out-of-band. See Section 8 426 for how the grouping of the two sessions is done with SDP. 428 If SSRC-multiplexing is used, the receiver should first of all 429 look for two streams that have the same CNAME in the session. In 430 some cases, the CNAME may not be enough to determine the 431 association as multiple original streams in the same session may 432 share the same CNAME. For example, there can be in the same video 433 session multiple video streams mapping to different SSRCs and 434 still using the same CNAME and possibly the same PT values. Each 435 (or some) of these streams may have an associated retransmission 436 stream. 438 In this case, in order to find out the association between 439 original and retransmission streams having the same CNAME, the 440 receiver SHOULD behave as follows. 442 The association can generally be resolved when the receiver 443 receives a retransmission packet matching a retransmission request 444 which had been sent earlier. Upon reception of a retransmission 445 packet whose original sequence number has been previously 446 requested, the receiver can derive that the SSRC of the 447 retransmission packet is associated to the sender SSRC from which 448 the packet was requested. 450 However, this mechanism might fail if there are two outstanding 451 requests for the same packet sequence number in two different 452 original streams of the session. Note that since the initial 453 packet sequence numbers are random, the probability of having two 454 outstanding requests for the same packet sequence number would be 455 very small. Nevertheless, in order to avoid ambiguity in the 456 unicast case, the receiver MUST NOT have two outstanding requests 457 for the same packet sequence number in two different original 458 streams before the association is resolved. In multicast, this 459 ambiguity cannot be completely avoided, because another receiver 460 may have requested the same sequence number from another stream. 461 Therefore, SSRC-multiplexing MUST NOT be used in multicast 462 sessions. 464 If the receiver discovers that two senders are using the same SSRC 465 or if it receives an RTCP BYE packet, it MUST stop requesting 466 retransmissions for that SSRC. Upon reception of original RTP 467 packets with a new SSRC, the receiver MUST perform the SSRC 468 association again as described in this section. 470 6. Use with the extended RTP profile for RTCP-based feedback 472 This section gives general hints for the usage of this payload 473 format with the extended RTP profile for RTCP-based feedback, 474 denoted AVPF [1]. Note that the general RTCP send and receive 475 rules and the RTCP packet format as specified in RTP apply, except 476 for the changes that the AVPF profile introduces. In short, the 477 AVPF profile relaxes the RTCP timing rules and specifies 478 additional general-purpose RTCP feedback messages. See [1] for 479 details. 481 6.1 RTCP at the sender 483 In the case of session-multiplexing, Sender Report (SR) packets 484 for the original stream are sent in the original session and SR 485 packets for the retransmission stream are sent in the 486 retransmission session according to the rules of RTP. 488 In the case of SSRC-multiplexing, SR packets for both original and 489 retransmission streams are sent in the same session according to 490 the rules of RTP. The original and retransmission streams are 491 seen, as far the RTCP bandwidth calculation is concerned, as 492 independent senders belonging to the same RTP session and are thus 493 equally sharing the RTCP bandwidth assigned to senders. 495 Note that in both cases, session- and SSRC-multiplexing, BYE 496 packets MUST still be sent for both streams as specified in RTP. 497 In other words, it is not enough to send BYE packets for the 498 original stream only. 500 6.2 RTCP Receiver Reports 502 In the case of session-multiplexing, the receiver will send report 503 blocks for the original stream and the retransmission stream in 504 separate Receiver Report (RR) packets belonging to separate RTP 505 sessions. RR packets reporting on the original stream are sent in 506 the original RTP session while RR packets reporting on the 507 retransmission stream are sent in the retransmission session. The 508 RTCP bandwidth for these two sessions may be chosen independently 509 (for example through RTCP bandwidth modifiers [4]). 511 In the case of SSRC-multiplexing, the receiver sends report blocks 512 for the original and the retransmission streams in the same RR 513 packet since there is a single session. 515 6.3 Retransmission requests 517 The NACK feedback message format defined in the AVPF profile 518 SHOULD be used by receivers to send retransmission requests. 519 Whether a receiver chooses to request a packet or not is an 520 implementation issue. An actual receiver implementation should 521 take into account such factors as the tolerable application delay, 522 the network environment and the media type. 524 The receiver should generally assess whether the retransmitted 525 packet would still be useful at the time it is received. The 526 timestamp of the missing packet can be estimated from the 527 timestamps of packets preceding and/or following the sequence 528 number gap caused by the missing packet in the original stream. 529 In most cases, some form of linear estimate of the timestamp is 530 good enough. 532 Furthermore, a receiver should compute an estimate of the round- 533 trip time (RTT) to the sender. This can be done, for example, by 534 measuring the retransmission delay to receive a retransmission 535 packet after a NACK has been sent for that packet. This estimate 536 may also be obtained from past observations, RTCP report round- 537 trip time if available or any other means. A standard mechanism 538 for the receiver to estimate the RTT is specified in RTP Extended 539 Reports [11]. 541 The receiver should not send a retransmission request as soon as 542 it detects a missing sequence number but should add some extra 543 delay to compensate for packet reordering. This extra delay may, 544 for example, be based on past observations of the experienced 545 packet reordering. 547 To increase the robustness to the loss of a NACK or of a 548 retransmission packet, a receiver may send a new NACK for the same 549 packet. This is referred to as multiple retransmissions. Before 550 sending a new NACK for a missing packet, the receiver should rely 551 on a timer to be reasonably sure that the previous retransmission 552 attempt has failed in order to avoid unnecessary retransmissions. 554 NACKs MUST be sent only for the original RTP stream. Otherwise, 555 if a receiver wanted to perform multiple retransmissions by 556 sending a NACK in the retransmission stream, it would not be able 557 to know the original sequence number and a timestamp estimation of 558 the packet it requests. 560 6.4 Timing rules 561 The NACK feedback message may be sent in a regular full compound 562 RTCP packet or in an early RTCP packet, as per AVPF [1]. Sending 563 a NACK in an early packet allows to react more quickly to a given 564 packet loss. However, in that case if a new packet loss occurs 565 right after the early RTCP packet was sent, the receiver will then 566 have to wait for the next regular RTCP compound packet after the 567 early packet. Sending NACKs only in regular RTCP compound 568 decreases the maximum delay between detecting an original packet 569 loss and being able to send a NACK for that packet. Implementers 570 should consider the possible implications of this fact for the 571 application being used. 573 Furthermore, receivers may make use of the minimum interval 574 between regular RTCP compound packets. This interval can be used 575 to keep regular receiver reporting down to a minimum, while still 576 allowing receivers to send early RTCP packets during periods 577 requiring more frequent feedback, e.g. times of higher packet loss 578 rate. Note that although RTCP packets may be suppressed because 579 they do not contain NACKs, the same RTCP bandwidth as if they were 580 sent needs to be available. See AVPF [1] for details on the use 581 of the minimum interval. 583 7. Congestion control 585 RTP retransmission poses a risk of increasing network congestion. 586 In a best-effort environment, packet loss is caused by congestion. 587 Reacting to loss by retransmission of older data without 588 decreasing the rate of the original stream would thus further 589 increase congestion. Implementations SHOULD follow the 590 recommendations below in order to use retransmission. 592 The RTP profile under which the retransmission scheme is used 593 defines an appropriate congestion control mechanism in different 594 environments. Following the rules under the profile, an RTP 595 application can determine its acceptable bitrate and packet rate 596 in order to be fair to other TCP or RTP flows. 598 If an RTP application uses retransmission, the acceptable packet 599 rate and bitrate includes both the original and retransmitted 600 data. This guarantees that an application using retransmission 601 achieves the same fairness as one that does not. Such a rule 602 would translate in practice into the following actions: 604 If enhanced service is used, it should be made sure that the total 605 bitrate and packet rate do not exceed that of the requested 606 service. It should be further monitored that the requested 607 services are actually delivered. In a best-effort environment, 608 the sender SHOULD NOT send retransmission packets without reducing 609 the packet rate and bitrate of the original stream (for example by 610 encoding the data at a lower rate). 612 In addition, the sender MAY selectively retransmit only the 613 packets that it deems important and ignore NACK messages for other 614 packets in order to limit the bitrate. 616 These congestion control mechanisms should keep the packet loss 617 rate within acceptable parameters. Packet loss is considered 618 acceptable if a TCP flow across the same network path and 619 experiencing the same network conditions would achieve, on a 620 reasonable timescale, an average throughput, that is not less than 621 the one the RTP flow achieves. If the packet loss rate exceeds an 622 acceptable level, it SHOULD be concluded that congestion is not 623 kept under control and retransmission SHOULD NOT then be used. It 624 may further be necessary to adapt the transmission rate (or the 625 number of layers subscribed for a layered multicast session), or 626 to arrange for the receiver to leave the session. 628 8. Retransmission Payload Format MIME type registration 630 8.1 Introduction 632 The following MIME subtype name and parameters are introduced in 633 this document: "rtx", "rtx-time" and "apt". 635 The binding used for the retransmission stream to the payload type 636 number is indicated by an rtpmap attribute. The MIME subtype name 637 used in the binding is "rtx". 639 The "apt" (associated payload type) parameter MUST be used to map 640 the retransmission payload type to the associated original stream 641 payload type. If multiple original payload types are used, then 642 multiple "apt" parameters MUST be included to map each original 643 payload type to a different retransmission payload type. 645 An OPTIONAL payload-format-specific parameter, "rtx-time", 646 indicates the maximum time a sender will keep an original RTP 647 packet in its buffers available for retransmission. This time 648 starts with the first transmission of the packet. 650 The syntax is as follows: 652 a=fmtp: apt=;rtx-time= 653 where, 655 : indicates the dynamic payload type number assigned 656 to the retransmission payload format in an rtpmap attribute. 658 : the value of the original stream payload type to 659 which this retransmission stream payload type is associated. 661 : specifies the time in milliseconds (measured 662 from the time a packet was first sent) that a sender keeps an 663 RTP packet in its buffers available for retransmission. The 664 absence of the rtx-time parameter for a retransmission stream 665 means that the maximum retransmission time is not defined, 666 but MAY be negotiated by other means. 668 8.2 Registration of audio/rtx 670 MIME type: audio 672 MIME subtype: rtx 674 Required parameters: 676 rate: the RTP timestamp clockrate is equal to the RTP 677 timestamp clockrate of the media that is retransmitted. 679 apt: associated payload type. The value of this parameter is 680 the payload type of the associated original stream. 682 Optional parameters: 684 rtx-time: indicates the time in milliseconds (measured from 685 the time a packet was first sent) that the sender keeps an 686 RTP packet in its buffers available for retransmission. 688 Encoding considerations: this type is only defined for transfer 689 via RTP. 691 Security considerations: see Section 12 of RFC XXXX 693 Interoperability considerations: none 695 Published specification: RFC XXXX 697 Applications which use this media type: multimedia streaming 698 applications 700 Additional information: none 702 Person & email address to contact for further information: 703 rey@panasonic.de 704 david.leon@nokia.com 705 avt@ietf.org 707 Intended usage: COMMON 709 Author/Change controller: 710 Jose Rey 711 David Leon 712 IETF AVT WG 714 8.3 Registration of video/rtx 716 MIME type: video 718 MIME subtype: rtx 720 Required parameters: 722 rate: the RTP timestamp clockrate is equal to the RTP 723 timestamp clockrate of the media that is retransmitted. 725 apt: associated payload type. The value of this parameter is 726 the payload type of the associated original stream. 728 Optional parameters: 730 rtx-time: indicates the time in milliseconds (measured from 731 the time a packet was first sent) that the sender keeps an 732 RTP packet in its buffers available for retransmission. 734 Encoding considerations: this type is only defined for transfer 735 via RTP. 737 Security considerations: see Section 12 of RFC XXXX 739 Interoperability considerations: none 741 Published specification: RFC XXXX 743 Applications which use this media type: multimedia streaming 744 applications 746 Additional information: none 748 Person & email address to contact for further information: 749 rey@panasonic.de 750 david.leon@nokia.com 751 avt@ietf.org 753 Intended usage: COMMON 755 Author/Change controller: 756 Jose Rey 757 David Leon 758 IETF AVT WG 760 8.4 Registration of text/rtx 762 MIME type: text 764 MIME subtype: rtx 766 Required parameters: 768 rate: the RTP timestamp clockrate is equal to the RTP 769 timestamp clockrate of the media that is retransmitted. 771 apt: associated payload type. The value of this parameter is 772 the payload type of the associated original stream. 774 Optional parameters: 776 rtx-time: indicates the time in milliseconds (measured from 777 the time a packet was first sent) that the sender keeps an 778 RTP packet in its buffers available for retransmission. 780 Encoding considerations: this type is only defined for transfer 781 via RTP. 783 Security considerations: see Section 12 of RFC XXXX 785 Interoperability considerations: none 787 Published specification: RFC XXXX 789 Applications which use this media type: multimedia streaming 790 applications 792 Additional information: none 794 Person & email address to contact for further information: 795 rey@panasonic.de 796 david.leon@nokia.com 797 avt@ietf.org 799 Intended usage: COMMON 801 Author/Change controller: 802 Jose Rey 803 David Leon 804 IETF AVT WG 806 8.5 Registration of application/rtx 808 MIME type: application 810 MIME subtype: rtx 812 Required parameters: 814 rate: the RTP timestamp clockrate is equal to the RTP 815 timestamp clockrate of the media that is retransmitted. 817 apt: associated payload type. The value of this parameter is 818 the payload type of the associated original stream. 820 Optional parameters: 822 rtx-time: indicates the time in milliseconds (measured from 823 the time a packet was first sent) that the sender keeps an 824 RTP packet in its buffers available for retransmission. 826 Encoding considerations: this type is only defined for transfer 827 via RTP. 829 Security considerations: see Section 12 of RFC XXXX 831 Interoperability considerations: none 833 Published specification: RFC XXXX 835 Applications which use this media type: multimedia streaming 836 applications 838 Additional information: none 840 Person & email address to contact for further information: 841 rey@panasonic.de 842 david.leon@nokia.com 843 avt@ietf.org 845 Intended usage: COMMON 847 Author/Change controller: 848 Jose Rey 849 David Leon 850 IETF AVT WG 852 8.6 Mapping to SDP 854 The information carried in the MIME media type specification has a 855 specific mapping to fields in SDP [5], which is commonly used to 856 describe RTP sessions. When SDP is used to specify 857 retransmissions for an RTP stream, the mapping is done as 858 follows: 860 - The MIME types ("video"), ("audio"), ("text") and 861 ("application") go in the SDP "m=" as the media name. 863 - The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding 864 name. The RTP clock rate in "a=rtpmap" MUST be that of the 865 retransmission payload type. See Section 4 for details on this. 867 - The AVPF profile-specific parameters "ack" and "nack" go in SDP 868 "a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types 869 of feedback. See the AVPF profile [1] for details. 871 - The retransmission payload-format-specific parameters "apt" and 872 "rtx-time" go in the SDP "a=fmtp" as a semicolon separated list of 873 parameter=value pairs. 875 - Any remaining parameters go in the SDP "a=fmtp" attribute by 876 copying them directly from the MIME media type string as a 877 semicolon separated list of parameter=value pairs. 879 In the following sections some example SDP descriptions are 880 presented. In some of these examples, long lines are folded to 881 meet the column width constraints of this document; the backslash 882 ("\") at the end of a line and the carriage return that follows it 883 should be ignored. 885 8.7 SDP description with session-multiplexing 887 In the case of session-multiplexing, the SDP description contains 888 one media specification "m" line per RTP session. The SDP MUST 889 provide the grouping of the original and associated retransmission 890 sessions' "m" lines, using the Flow Identification (FID) semantics 891 defined in RFC 3388 [6]. 893 The following example specifies two original, AMR and MPEG-4, 894 streams on ports 49170 and 49174 and their corresponding 895 retransmission streams on ports 49172 and 49176, respectively: 897 v=0 898 o=mascha 2980675221 2980675778 IN IP4 host.example.net 899 c=IN IP4 192.0.2.0 900 a=group:FID 1 2 901 a=group:FID 3 4 902 m=audio 49170 RTP/AVPF 96 903 a=rtpmap:96 AMR/8000 904 a=fmtp:96 octet-align=1 905 a=rtcp-fb:96 nack 906 a=mid:1 907 m=audio 49172 RTP/AVPF 97 908 a=rtpmap:97 rtx/8000 909 a=fmtp:97 apt=96;rtx-time=3000 910 a=mid:2 911 m=video 49174 RTP/AVPF 98 912 a=rtpmap:98 MP4V-ES/90000 913 a=rtcp-fb:98 nack 914 a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\ 915 0A21F 916 a=mid:3 917 m=video 49176 RTP/AVPF 99 918 a=rtpmap:99 rtx/90000 919 a=fmtp:99 apt=98;rtx-time=3000 920 a=mid:4 921 A special case of the SDP description is a description that 922 contains only one original session "m" line and one retransmission 923 session "m" line, the grouping is then obvious and FID semantics 924 MAY be omitted in this special case only. 926 This is illustrated in the following example, which is an SDP 927 description for a single original MPEG-4 stream and its 928 corresponding retransmission session: 930 v=0 931 o=mascha 2980675221 2980675778 IN IP4 host.example.net 932 c=IN IP4 192.0.2.0 933 m=video 49170 RTP/AVPF 96 934 a=rtpmap:96 MP4V-ES/90000 935 a=rtcp-fb:96 nack 936 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\ 937 0A21F 938 m=video 49172 RTP/AVPF 97 939 a=rtpmap:97 rtx/90000 940 a=fmtp:97 apt=96;rtx-time=3000 942 8.8 SDP description with SSRC-multiplexing 944 The following is an example of an SDP description for an RTP video 945 session using SSRC-multiplexing with similar parameters as in the 946 single-session example above: 948 v=0 949 o=mascha 2980675221 2980675778 IN IP4 host.example.net 950 c=IN IP4 192.0.2.0 951 m=video 49170 RTP/AVPF 96 97 952 a=rtpmap:96 MP4V-ES/90000 953 a=rtcp-fb:96 nack 954 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\ 955 0A21F 956 a=rtpmap:97 rtx/90000 957 a=fmtp:97 apt=96;rtx-time=3000 959 9. RTSP considerations 961 The Real-time Streaming Protocol (RTSP), RFC 2326 [7] is an 962 application-level protocol for control over the delivery of data 963 with real-time properties. This section looks at the issues 964 involved in controlling RTP sessions that use retransmissions. 966 9.1 RTSP control with SSRC-multiplexing 968 In the case of SSRC-multiplexing, the "m" line includes both 969 original and retransmission payload types and has a single RTSP 970 "control" attribute. The receiver uses the "m" line to request 971 SETUP and TEARDOWN of the whole media session. The RTP profile 972 contained in the Transport header MUST be the AVPF profile or 973 another suitable profile allowing extended feedback. If the SSRC 974 value is included in the SETUP response's Transport header, it 975 MUST be that of the original stream. 977 In order to control the sending of the session original media 978 stream, the receiver sends as usual PLAY and PAUSE requests to the 979 sender for the session. The RTP-info header that is used to set 980 RTP-specific parameters in the PLAY response MUST be set according 981 to the RTP information of the original stream. 983 When the receiver starts receiving the original stream, it can 984 then request retransmission through RTCP NACKs without additional 985 RTSP signalling. 987 9.2 RTSP control with session-multiplexing 989 In the case of session-multiplexing, each SDP "m" line has an RTSP 990 "control" attribute. Hence, when retransmission is used, both the 991 original session and the retransmission have their own "control" 992 attributes. The receiver can associate the original session and 993 the retransmission session through the FID semantics as specified 994 in Section 8. 996 The original and the retransmission streams are set up and torn 997 down separately through their respective media "control" 998 attribute. The RTP profile contained in the Transport header MUST 999 be the AVPF profile or another suitable profile allowing extended 1000 feedback for both the original and the retransmission session. 1002 The RTSP presentation SHOULD support aggregate control and SHOULD 1003 contain a session level RTSP URL. The receiver SHOULD use 1004 aggregate control for an original session and its associated 1005 retransmission session. Otherwise, there would need to be two 1006 different 'session-id' values, i.e. different values for the 1007 original and retransmission sessions, and the sender would not 1008 know how to associate them. 1010 The session-level "control" attribute is then used as usual to 1011 control the playing of the original stream. When the receiver 1012 starts receiving the original stream, it can then request 1013 retransmissions through RTCP without additional RTSP signalling. 1015 9.3 RTSP control of the retransmission stream 1017 Because of the nature of retransmissions, the sending of 1018 retransmission packets SHOULD NOT be controlled through RTSP PLAY 1019 and PAUSE requests. The PLAY and PAUSE requests SHOULD NOT affect 1020 the retransmission stream. Retransmission packets are sent upon 1021 receiver requests in the original RTCP stream, regardless of the 1022 state. 1024 9.4 Cache control 1025 Retransmission streams SHOULD NOT be cached. 1027 In the case of session-multiplexing, the "Cache-Control" header 1028 SHOULD be set to "no-cache" for the retransmission stream. 1030 In the case of SSRC-multiplexing, RTSP cannot specify independent 1031 caching for the retransmission stream, because there is a single 1032 "m" line in SDP. Therefore, the implementer should take this fact 1033 into account when deciding whether to cache an SSRC-multiplexed 1034 session or not. 1036 10. Implementation examples 1038 This document mandates only the sender and receiver behaviours 1039 that are necessary for interoperability. In addition, certain 1040 algorithms, such as rate control or buffer management when 1041 targeted at specific environments, may enhance the retransmission 1042 efficiency. 1044 This section gives an overview of different implementation options 1045 allowed within this specification. 1047 The first example describes a minimal receiver implementation. 1048 With this implementation, it is possible to retransmit lost RTP 1049 packets, detect efficiently the loss of retransmissions and 1050 perform multiple retransmissions, if needed. Most of the 1051 necessary processing is done at the server. 1053 The second example shows how a receiver may implement additional 1054 enhancements that might help reduce sender buffer requirements and 1055 optimise the retransmission efficiency 1057 The third example shows how retransmissions may be used in (small) 1058 multicast groups in conjunction with layered encoding. It 1059 illustrates that retransmissions and layered encoding may be 1060 complementary techniques. 1062 10.1 A minimal receiver implementation example 1064 This section gives an example of an implementation supporting 1065 multiple retransmissions. The sender transmits the original data 1066 in RTP packets using the MPEG-4 video RTP payload format. 1067 It is assumed that NACK feedback messages are used, as per 1068 [1]. An SDP description example with SSRC-multiplexing is given 1069 below: 1071 v=0 1072 o=mascha 2980675221 2980675778 IN IP4 host.example.net 1073 c=IN IP4 192.0.2.0 1074 m=video 49170 RTP/AVPF 96 97 1075 a=rtpmap:96 MP4V-ES/90000 1076 a=rtcp-fb:96 nack 1077 a=rtpmap:97 rtx/90000 1078 a=fmtp:97 apt=96;rtx-time=3000 1080 The format-specific parameter "rtx-time" indicates that the server 1081 will buffer the sent packets in a retransmission buffer for 3.0 1082 seconds, after which the packets are deleted from the 1083 retransmission buffer and will never be sent again. 1085 In this implementation example, the required RTP receiver 1086 processing to handle retransmission is kept to a minimum. The 1087 receiver detects packet loss from the gaps observed in the 1088 received sequence numbers. It signals lost packets to the sender 1089 through NACKs as defined in the AVPF profile [1]. The receiver 1090 should take into account the signalled sender retransmission 1091 buffer length in order to dimension its own reception buffer. It 1092 should also derive from the buffer length the maximum number of 1093 times the retransmission of a packet can be requested. 1095 The sender should retransmit the packets selectively, i.e. it 1096 should choose whether to retransmit a requested packet depending 1097 on the packet importance, the observed QoS and congestion state of 1098 the network connection to the receiver. Obviously, the sender 1099 processing increases with the number of receivers as state 1100 information and processing load must be allocated to each 1101 receiver. 1103 10.2 An enhanced receiver implementation example 1105 The receiver may have more accurate information than the sender 1106 about the current network QoS such as available bandwidth, packet 1107 loss rate, delay and jitter. In addition, other receiver-specific 1108 parameters such as buffer level, estimated importance of the lost 1109 packet and application level QoS may be used by the receiver to 1110 make a more efficient use of RTP retransmission by selectively 1111 sending NACKs for important lost packets and not for others. For 1112 example, a receiver may decide to suppress a request for a packet 1113 loss that could be concealed locally, or for a retransmission that 1114 would arrive late. 1116 Furthermore, a receiver may acknowledge the received packets. 1117 This can be done by sending ACKs, as per [1]. Upon receiving an 1118 ACK, the sender may delete all the acknowledged packets from its 1119 retransmission buffer. Note that this would also require only 1120 limited increase in the required RTCP bandwidth as long as ACK 1121 packets are sent seldom enough. 1123 This implementation may help reduce buffer requirements at the 1124 sender and optimise the performance of the implementation by using 1125 selective requests. 1127 Note that these receiver enhancements do not need to be negotiated 1128 as they do not affect the sender implementation. However, in 1129 order to allow the receiver to acknowledge packets, it is needed 1130 to allow the use of ACKs in the SDP description, by means of an 1131 additional SDP "a=rtcp-fb" line, as follows: 1133 v=0 1134 o=mascha 2980675221 2980675778 IN IP4 host.example.net 1135 c=IN IP4 192.0.2.0 1136 m=video 49170 RTP/AVPF 96 97 1137 a=rtpmap:96 MP4V-ES/90000 1138 a=rtcp-fb:96 nack 1139 a=rtcp-fb:96 ack 1140 a=rtpmap:97 rtx/90000 1141 a=fmtp:97 apt=96;rtx-time=3000 1143 10.3 Retransmission of Layered Encoded Media in Multicast 1145 This section shows how to combine retransmissions with layered 1146 encoding in multicast sessions. Note that the retransmission 1147 framework is not intended as a complete solution to reliable 1148 multicast. Refer to RFC 2887 [10], for an overview of the 1149 problems related with reliable multicast transmission. 1151 Packets of different importance are sent in different RTP 1152 sessions. The retransmission streams corresponding to the 1153 different layers can themselves be seen as different 1154 retransmission layers. The relative importance of the different 1155 retransmission streams should reflect the relative importance of 1156 the different original streams. 1158 In multicast, SSRC-multiplexing of the original and retransmission 1159 streams is not allowed as per Section 5.3 of this document. For 1160 this reason, the retransmission stream(s) MUST be sent in 1161 different RTP session(s) using session-multiplexing. 1163 An SDP description example of multicast retransmissions for 1164 layered encoded media is given below: 1166 m=video 8000 RTP/AVPF 98 1167 c=IN IP4 192.0.2.0/127/3 1168 a=rtpmap:98 MP4V-ES/90000 1169 a=rtcp-fb:98 nack 1170 m=video 8000 RTP/AVPF 99 1171 c=IN IP4 192.0.2.4/127/3 1172 a=rtpmap:99 rtx/90000 1173 a=fmtp:99 apt=98;rtx-time=3000 1175 The server and the receiver may implement the retransmission 1176 methods illustrated in the previous examples. In addition, they 1177 may choose to request and retransmit a lost packet depending on 1178 the layer it belongs to. 1180 11. IANA considerations 1181 A new MIME subtype name, "rtx", has been registered for four 1182 different media types, as follows: "video", "audio", "text" and 1183 "application". An additional REQUIRED parameter, "apt", and an 1184 OPTIONAL parameter, "rtx-time", are defined. See Section 8 for 1185 details. 1187 12. Security considerations 1189 If cryptography is used to provide security services on the 1190 original stream, then the same services, with equivalent 1191 cryptographic strength, MUST be provided on the retransmission 1192 stream. Old keys will likely need to be cached so that when the 1193 keys change for the original stream, the old key is used until it 1194 is determined that the key has changed on the retransmission 1195 packets as well. 1197 The use of the same key for the retransmitted stream and the 1198 original stream may lead to security problems, e.g. two-time pads. 1199 This sharing has to be evaluated towards the chosen security 1200 protocol and security algorithms. 1202 Furthermore, it is RECOMMENDED that the cryptography mechanisms 1203 used for this payload format provide protection against known 1204 plaintext attacks. RTP recommends that the initial RTP timestamp 1205 SHOULD be random to secure the stream against known plaintext 1206 attacks. This payload format does not follow this recommendation 1207 as the initial timestamp will be the media timestamp of the first 1208 retransmitted packet. However, since the initial timestamp of the 1209 original stream is itself random, if the original stream is 1210 encrypted, the first retransmitted packet timestamp would also be 1211 random to an attacker. Therefore, confidentiality would not be 1212 compromised. 1214 Congestion control considerations with the use of retransmission 1215 are dealt with in Section 7 of this document. 1217 Any other security considerations of the profile under which the 1218 retransmission scheme is used should be applied. The 1219 retransmission payload format MUST NOT be used under the SAVP 1220 profile defined by the Secure Real-Time Transport Protocol 1221 (SRTP)[12] but instead an extension of SRTP should be defined to 1222 secure the AVPF profile. The definition of such a profile is out 1223 of the scope of this document. 1225 13. Acknowledgements 1227 We would like to express our gratitude to Carsten Burmeister for 1228 his participation in the development of this document. Our thanks 1229 also go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus 1230 Westerlund, Go Hori and Rahul Agarwal for their helpful comments. 1232 14. References 1234 14.1 Normative References 1236 1 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP 1237 profile for RTCP-based feedback", draft-ietf-avt-rtcp-feedback- 1238 04.txt, September 2002. 1240 2 S. Bradner, "Key words for use in RFCs to Indicate Requirement 1241 Levels", BCP 14, RFC 2119, March 1997 1243 3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A 1244 Transport Protocol for Real-Time Applications", draft-ietf-avt- 1245 rtp-new-12.txt, March 2003. 1247 4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", draft- 1248 ietf-avt-rtcp-bw-05.txt, May 2002. 1250 5 M. Handley, V. Jacobson, "SDP: Session Description Protocol", 1251 RFC 2327, April 1998. 1253 6 G. Camarillo, J. Holler, G. AP. Eriksson, "Grouping of media 1254 lines in the Session Description Protocol (SDP)", RFC 3388, 1255 December 2002. 1257 7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming 1258 Protocol (RTSP)", RFC 2326, April 1998. 1260 14.2 Informative References 1262 8 C. Perkins, O. Hodson, "Options for Repair of Streaming Media", 1263 RFC 2354, June 1998. 1265 9 G. Hellstrom, "RTP for conversational text", RFC 2793, May 2000 1267 10 M. Handley, et al., "The Reliable Multicast Design Space for 1268 Bulk Data Transfer", RFC 2887, August 2000. 1270 11 Friedman, et. al., "RTP Extended Reports", Work in Progress. 1272 12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. 1273 Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", 1274 draft-ietf-avt-srtp-05.txt, June 2002. 1276 13 R. Hovey and S. Bradner, "The Organizations Involved in the IETF 1277 Standards Process," BCP 11, RFC 2028, IETF, October 1996. 1279 15. Author's Addresses 1281 Jose Rey rey@panasonic.de 1282 Panasonic European Laboratories GmbH 1283 Monzastr. 4c 1284 D-63225 Langen, Germany 1285 Phone: +49-6103-766-134 1286 Fax: +49-6103-766-166 1288 David Leon david.leon@nokia.com 1289 Nokia Research Center 1290 6000 Connection Drive 1291 Irving, TX. USA 1292 Phone: 1-972-374-1860 1294 Akihiro Miyazaki akihiro@isl.mei.co.jp 1295 Core Software Development Center 1296 Corporate Software Development Division 1297 Matsushita Electric Industrial Co., Ltd. 1298 1006 Kadoma, Kadoma City, Osaka 571-8501, Japan 1299 Phone: +81-6-6900-9192 1300 Fax: +81-6-6900-9193 1302 Viktor Varsa viktor.varsa@nokia.com 1303 Nokia Research Center 1304 6000 Connection Drive 1305 Irving, TX. USA 1306 Phone: 1-972-374-1861 1308 Rolf Hakenberg hakenberg@panasonic.de 1309 Panasonic European Laboratories GmbH 1310 Monzastr. 4c 1311 D-63225 Langen, Germany 1312 Phone: +49-6103-766-162 1313 Fax: +49-6103-766-166 1315 IPR Notices 1317 The IETF has been notified of intellectual property rights claimed 1318 in regard to some or all of the specification contained in this 1319 document. For details on the IPR statement, please visit the IETF 1320 IPR web page, http://www.ietf.org/ietf/IPR. 1322 The IETF takes no position regarding the validity or scope of any 1323 intellectual property or other rights that might be claimed to 1324 pertain to the implementation or use of the technology described 1325 in this document or the extent to which any license under such 1326 rights might or might not be available; neither does it represent 1327 that it has made any effort to identify any such rights. 1328 Information on the IETF's procedures with respect to rights in 1329 standards-track and standards-related documentation can be found 1330 in BCP 11 [13]. Copies of claims of rights made available for 1331 publication and any assurances of licenses to be made available, 1332 or the result of an attempt made to obtain a general license or 1333 permission for the use of such proprietary rights by implementers 1334 or users of this specification can be obtained from the IETF 1335 Secretariat. 1337 The IETF invites any interested party to bring to its attention 1338 any copyrights, patents or patent applications, or other 1339 proprietary rights which may cover technology that may be required 1340 to practice this standard. Please address the information to the 1341 IETF Executive Director. 1343 Full Copyright Statement 1345 Copyright (C) The Internet Society (2004). All Rights Reserved. 1347 This document and translations of it may be copied and furnished 1348 to others, and derivative works that comment on or otherwise 1349 explain it or assist in its implementation may be prepared, 1350 copied, published and distributed, in whole or in part, without 1351 restriction of any kind, provided that the above copyright notice 1352 and this paragraph are included on all such copies and derivative 1353 works. However, this document itself may not be modified in any 1354 way, such as by removing the copyright notice or references to the 1355 Internet Society or other Internet organizations, except as needed 1356 for the purpose of developing Internet standards in which case 1357 the procedures for copyrights defined in the Internet Standards 1358 process must be followed, or as required to translate it into 1359 languages other than English. 1361 The limited permissions granted above are perpetual and will 1362 not be revoked by the Internet Society or its successors or 1363 assigns. 1365 This document and the information contained herein is provided on 1366 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1367 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1368 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1369 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.