idnits 2.17.1 draft-ietf-avt-rtp-retransmission-04.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-04' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 841 has weird spacing: '... delay and ...' == Line 851 has weird spacing: '... sent seldo...' == Line 962 has weird spacing: '...ockrate of th...' == Line 1009 has weird spacing: '...ockrate of th...' == Line 1056 has weird spacing: '...ockrate of th...' == 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 (December 2002) is 7803 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? '1' on line 847 looks like a reference -- Missing reference section? '9' on line 88 looks like a reference -- Missing reference section? '2' on line 150 looks like a reference -- Missing reference section? '10' on line 166 looks like a reference -- Missing reference section? '3' on line 220 looks like a reference -- Missing reference section? '4' on line 412 looks like a reference -- Missing reference section? '5' on line 589 looks like a reference -- Missing reference section? '6' on line 622 looks like a reference -- Missing reference section? '7' on line 692 looks like a reference -- Missing reference section? '11' on line 874 looks like a reference -- Missing reference section? '8' on line 1106 looks like a reference Summary: 4 errors (**), 1 flaw (~~), 12 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft 3 draft-ietf-avt-rtp-retransmission- Jose Rey/Matsushita 4 04.txt David Leon/Nokia 5 Akihiro Miyazaki/Matsushita 6 Viktor Varsa/Nokia 7 Rolf Hakenberg/Matsushita 9 Expires: May 2003 December 2002 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 RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 [Note to RFC Editor: This paragraph is to be deleted when this 34 draft is published as an RFC. References in this draft to RFC XXXX 35 should be replaced with the RFC number assigned to this document. 36 References in this draft to RFC YYYY should be replaced with the RFC 37 number assigned the draft-ietf-mmusic-fid when published as RFC. 38 References in this draft to RFC ZZZZ should be replaced with the RFC 39 number assigned the draft-ietf-avt-rtcp-bw when published as RFC. 40 References in this draft to RFC UUUU should be replaced with the 41 RFC number assigned the draft-ietf-avt-srtp when published as RFC. 42 References in this draft to RFC VVVV should be replaced with the RFC 43 number assigned the draft-ietf-avt-rtcp-feedback when published as 44 RFC. References in this draft to RFC WWWW should be replaced with 45 the RFC number of the revision of RFC 1889 being drafted as draft- 46 ietf-avt-rtp-new. Main changes since draft-ietf-avt-rtp- 47 retransmission-02.txt: this document is the result of the merging of 48 draft-ietf-avt-selret-05.txt and draft-ietf-avt-rtp-retransmission- 49 02.txt. Main changes since draft-ietf-avt-rtp-retransmission-03.txt: 50 RTSP section new drafted.] 52 IETF draft - Expires May 2003 1 53 Abstract 55 RTP retransmission is an effective packet loss recovery technique 56 for real-time applications with relaxed delay bounds. This document 57 describes an RTP payload format for performing retransmissions. 58 Retransmitted RTP packets are sent in a separate stream from the 59 original RTP stream. It is assumed that feedback from receivers to 60 senders is available. In particular, it is assumed that RTCP 61 feedback as defined in the extended RTP profile for RTCP-based 62 feedback [1] ( denoted AVPF ), is available in this memo. 64 Table of Contents 66 1. Introduction....................................................3 67 2. Terminology.....................................................3 68 3. Requirements and design rationale for a retransmission scheme...4 69 4. Retransmission payload format...................................6 70 5. Association of a retransmission stream with its original stream.7 71 6. Use with the extended RTP profile for RTCP-based feedback.......8 72 7. Congestion control.............................................10 73 8. SDP usage......................................................11 74 9. RTSP considerations............................................14 75 10. Implementation examples.......................................15 76 11. IANA considerations...........................................18 77 12. Security considerations.......................................22 78 13. Acknowledgements..............................................22 79 14. References....................................................22 80 Author's Addresses................................................23 82 Rey/Leon/Miyazaki/Varsa/Hakenberg 2 83 1. Introduction 85 Packet losses between an RTP sender and receiver may significantly 86 degrade the quality of the received media. Several techniques, such 87 as forward error correction (FEC), retransmissions or interleaving 88 may be considered to increase packet loss resiliency. RFC 2354 [9] 89 discusses the different options. 91 When choosing a repair technique for a particular application, the 92 tolerable latency of the application has to be taken into account. 93 In the case of multimedia conferencing, the end-to-end delay has to 94 be at most a few hundred milliseconds in order to guarantee 95 interactivity, which usually excludes the use of retransmission. 97 However, in the case of multimedia streaming, the user can tolerate 98 an initial latency as part of the session set-up and thus an end-to- 99 end delay of several seconds may be acceptable. Retransmission may 100 thus be considered for such applications. 102 This document specifies a retransmission method for RTP applicable 103 to unicast and (small) multicast groups: it defines a payload format 104 for retransmitted RTP packets and provides protocol rules for the 105 sender and the receiver involved in retransmissions. 107 Furthermore, this retransmission payload format was designed for use 108 with the extended RTP profile for RTCP-based feedback, AVPF [1]. It 109 may also be used with other RTP profiles defined in the future. 111 The AVPF profile allows for more frequent feedback and for early 112 feedback. It defines a small number of general-purpose feedback 113 messages, e.g. ACKs and NACKs, as well as codec and application- 114 specific feedback messages. See [1] for details. 116 2. Terminology 118 The following terms are used in this document: 120 Original packet: refers to an RTP packet which carries user data 121 sent for the first time by an RTP sender. 123 Original stream: refers to the RTP stream of original packets. 125 Retransmission packet: refers to an RTP packet whose payload 126 includes the payload of an already sent original packet. Such a 127 retransmission packet is said to be associated with the original RTP 128 packet. 130 Retransmission request: a means by which an RTP receiver is able to 131 request that the RTP sender should send a retransmission packet for 132 a given original packet. Usually, an RTCP NACK message as specified 133 in [1] is used as retransmission request for lost packets. 135 Rey/Leon/Miyazaki/Varsa/Hakenberg 3 136 Retransmission stream: the stream of retransmission packets 137 associated with an original stream. 139 Session-multiplexing: scheme by which the original stream and the 140 associated retransmission stream are sent into two different RTP 141 sessions. 143 SSRC-multiplexing: scheme by which the original stream and the 144 retransmission stream are sent in the same RTP session with 145 different SSRC values. 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [2]. 151 3. Requirements and design rationale for a retransmission scheme 153 The retransmission scheme is designed to fulfil the following set of 154 requirements: 156 1. It must not break general RTP and RTCP mechanisms 157 2. It must be suitable for unicast and small multicast groups. 158 3. It must work with mixers and translators. 159 4. It must work with all known payload types. 160 5. It must not prevent the use multiple payload types in a session. 161 6. In order to support the largest variety of payload formats the 162 RTP receiver must be able to indicate how many and which RTP 163 packets were lost. This requirement is referred to as sequence 164 number preservation. Without such a requirement, it would be 165 impossible to use retransmission with payload formats, such as 166 conversational text [10] or most audio/video streaming 167 applications, that use the RTP sequence number to detect lost 168 packets. 170 When designing a solution for RTP retransmission, several approaches 171 may be considered for the multiplexing of the original RTP packets 172 and the retransmitted RTP packets. 174 One approach may be to retransmit the RTP packet with its original 175 sequence number and send original and retransmission packets in the 176 same stream. The retransmission packet would then be identical to 177 the original RTP packet, i.e. the same header (and thus same 178 sequence number) and the same payload. However, such an approach is 179 not acceptable because it would corrupt the RTCP statistics. As a 180 consequence, requirement 1 would not be met. Correct RTCP statistics 181 require that for every RTP packet within the RTP stream, the 182 sequence number be increased by one. 184 Another approach may be to multiplex original RTP packets and 185 retransmission packets in the same stream using the payload type 186 field. With such an approach the original stream and the 188 Rey/Leon/Miyazaki/Varsa/Hakenberg 4 189 retransmission stream would share the same sequence number space. As 190 a result, the RTP receiver would not be able to infer how many and 191 which original packets (i.e. with which sequence number) were lost. 193 In other words, this feature does not satisfy the sequence number 194 preservation requirement (requirement 6). This in turn implies that 195 requirement 4 would not be met. Interoperability with mixers and 196 translators would also be more difficult if they do not understand 197 this new payload type in a sender RTP stream. For these reasons, a 198 solution based on payload type multiplexing of original packets and 199 retransmission packets in the same RTP stream is excluded. 201 Finally, the original and retransmission packets may be sent in two 202 separate streams. These two streams may be multiplexed either by 203 sending them in two different sessions , i.e. session-multiplexing, 204 or in the same session using different SSRCs, i.e. SSRC-multi- 205 plexing. Since original and retransmission packets carry media of 206 the same type, the objections in Section 5.2 of RTP, RFC WWWW [3] to 207 RTP multiplexing do not apply. 209 Using two separate streams satisfies all the requirements listed in 210 this section. Mixers and translators may process the original stream 211 and simply discard the retransmission stream if they are unable to 212 utilise it. 214 3.1 Multiplexing scheme choice 216 Session-multiplexing and SSRC-multiplexing have different pros and 217 cons: 219 Session-multiplexing is based on sending the retransmission stream 220 in a different RTP session (as defined in RTP [3]) from that of the 221 original stream, i.e. the original and retransmission streams are 222 sent to different network addresses and/or port numbers. Having a 223 separate session allows more flexibility. In multicast, using two 224 sessions for retransmission allows a receiver to choose whether to 225 subscribe or not to the RTP session carrying the retransmission 226 stream. It is also possible for the original session to be single- 227 source multicast and have separate unicast sessions to convey 228 retransmissions to each of the receivers, which will then receive 229 only the retransmission packets they requested. 231 The use of separate sessions also allows differential treatment by 232 the network and may simplify processing in mixers, translators and 233 packet caches. 235 With SSRC-multiplexing, a single session is needed for the original 236 and the retransmission stream. This allows streaming servers and 237 middleware which are involved in a high number of concurrent 238 sessions to minimise their port usage. 240 This retransmission payload format allows both session-multiplexing 241 and SSRC-multiplexing. From an implementation point of view, there 243 Rey/Leon/Miyazaki/Varsa/Hakenberg 5 244 is little difference between the two approaches. Hence, in order to 245 maximise interoperability, both multiplexing approaches SHOULD be 246 supported. 248 4. Retransmission payload format 250 The format of a retransmission packet is shown below: 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | RTP Header | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | OSN | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 257 | Original RTP Packet Payload | 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 The RTP header usage is as follows: 263 If the original and the retransmission streams are sent in separate 264 RTP sessions, the same SSRC value MUST be used for the original 265 stream and the retransmission stream. In case of an SSRC collision, 266 an RTCP BYE packet MUST be sent for the original RTP session. After 267 a new SSRC identifier is obtained, the SSRC of the retransmission 268 session MUST be set to this value. 270 If the original stream and the retransmission stream are sent in the 271 same RTP session, two different SSRC values MUST be used for the 272 original stream and the retransmission stream as required by RTP. 274 For either multiplexing scheme, the sequence number has the standard 275 definition, i.e. it MUST be one higher than the sequence number of 276 the preceding packet sent in the retransmission stream. 278 The retransmission packet timestamp is set to the original 279 timestamp, i.e. to the timestamp of the original packet. As a 280 consequence, the initial RTP timestamp for the first packet of the 281 retransmission stream is not random but equal to the original 282 timestamp of the first packet requested for retransmission. See the 283 security considerations section in this document for security 284 implications. 286 Implementers have to be aware that the RTCP jitter value for the 287 retransmission stream does not reflect the actual network jitter 288 since there could be little correlation between the time a packet is 289 retransmitted and its original timestamp. 291 The payload type is dynamic. Each payload type of the original 292 stream MUST map to a different payload type value in the 293 retransmission stream. Therefore, when multiple payload types are 295 Rey/Leon/Miyazaki/Varsa/Hakenberg 6 296 used in the original stream, multiple dynamic payload types will be 297 mapped to this retransmission payload format. See Section 8 for the 298 specification of how the mapping between original and retransmission 299 payload types is done. 301 As the retransmission packet timestamp carries the original media 302 timestamp, the timestamp clockrate used by the retransmission 303 payload type is the same as the one used by the associated original 304 payload type. It is thus possible to retransmit RTP packets whose 305 payload types have different timestamp clockrates in the same 306 retransmission stream if the original payload types have different 307 clock rates, but this is usually not the case. 309 If the original RTP header carried any profile-specific payload 310 header, the retransmission packet MUST include this payload header. 312 If the original RTP header carried an RTP header extension, the 313 retransmission packet SHOULD carry the same header extension. 315 The retransmission payload carries a payload header followed by the 316 original RTP packet payload. The length of payload header is 2 317 octets. The payload header contains only one field, OSN, which MUST 318 be set to the sequence number of the associated original RTP packet. 320 If the original RTP packet contained RTP padding, that padding must 321 be removed before constructing the retransmission packet. If padding 322 of the retransmission packet is needed, padding is performed as with 323 any RTP packets and the padding bit is set. 325 All other fields of the RTP header MUST have the same value as in 326 the associated original RTP packet 328 5. Association of a retransmission stream with its original stream 330 5.1 Retransmission session sharing 332 In the case of session-multiplexing, a retransmission session MUST 333 map to exactly one original session, i.e. the same retransmission 334 session cannot be used for different original sessions. 336 If retransmission session sharing were allowed, a receiver joining 337 the retransmission session would also receive the retransmissions 338 belonging to all other original sessions which the receiver may have 339 not joined. For example, a receiver wishing to receive only audio 340 would receive retransmitted video packets if an audio and video 341 session would share the same retransmission session. 343 5.2 CNAME use 345 A sender MUST use the same CNAME for an original stream and its 346 associated retransmission stream. 348 Rey/Leon/Miyazaki/Varsa/Hakenberg 7 349 5.3 Association at the receiver 351 A receiver receiving multiple original and retransmission streams 352 needs to associate each retransmission stream with its original 353 stream. The association is done differently depending on whether 354 session-multiplexing or SSRC-multiplexing is used. 356 If session-multiplexing is used, the receiver associates the two 357 streams having the same SSRC in the two sessions. Note that the 358 payload type field cannot be used to do this coupling as several 359 media streams may have the same payload type value. The two sessions 360 are themselves associated out-of-band. See the SDP section to see 361 how the grouping of the two sessions is done with SDP. 363 If SSRC-multiplexing is used, the receiver should first of all look 364 for two streams that have the same CNAME in the session. In some 365 cases, the CNAME may not be enough to determine the association as 366 multiple original streams in the same session may share the same 367 CNAME. For example, there can be in the same video session multiple 368 video streams mapping to different SSRCs and still using the same 369 CNAME and possibly the same PT values. Each (or some of) these 370 streams may have an associated retransmission stream. 372 In order to find out the association between original and 373 retransmission streams having the same CNAME, the receiver SHOULD 374 behave as follows. 376 The association can generally be resolved when the receiver receives 377 a retransmission packet matching a retransmission request which had 378 been sent earlier. Upon reception of a retransmission whose original 379 sequence number had been previously requested, the receiver can 380 derive that the SSRC of the retransmission packet is associated to 381 the sender SSRC from which the packet was requested. In order to 382 avoid ambiguity, the receiver MUST NOT have two outstanding requests 383 for the same packet sequence number in two different original 384 streams before the association is resolved. Note that since the 385 initial packet timestamps are random, the probability of having two 386 outstanding requests for the same packet sequence number would be 387 very small. 389 If the receiver discovers that two senders are using the same SSRC 390 or if it receives an RTCP BYE packet, it MUST stop requesting 391 retransmissions for that SSRC. Upon reception of original RTP 392 packets with a new SSRC, the receiver MUST perform the SSRC 393 association again as described in this section. 395 6. Use with the extended RTP profile for RTCP-based feedback 397 This section gives general hints for the usage of this payload 398 format with the extended RTP profile for RTCP-based feedback [1], 399 denoted AVPF. 401 Rey/Leon/Miyazaki/Varsa/Hakenberg 8 402 6.1 RTCP Receiver reports 404 If the original RTP stream and the retransmission stream are sent to 405 separate RTP sessions, the receiver will then send report blocks for 406 the original stream and the retransmission stream in separate RTCP 407 receiver reports (RR) packets belonging to separate RTP sessions. 408 RTCP packets reporting on the original stream are sent in the 409 original RTP session while RTCP packets reporting on the 410 retransmission stream are sent in the retransmission session. The 411 RTCP bandwidth for these two sessions may be chosen independently 412 (for example through RTCP bandwidth modifiers RFC ZZZZ [4]). 414 If the original RTP stream and the retransmission stream are sent in 415 the same session (SSRC multiplexing), the receiver sends report 416 blocks for the original and the retransmission streams in the same 417 RTCP RR packet. 419 6.2 Retransmission requests 421 The NACK message format defined in the AVPF profile SHOULD be used 422 by receivers to send retransmission requests. 423 Whether a receiver chooses to request a packet or not is an 424 implementation issue. An actual receiver implementation should take 425 into account such factors as the tolerable application delay, the 426 network environment and the media type. 428 The receiver should generally assess whether the retransmitted 429 packet would still be useful at the time it is received. The 430 timestamp of the missing packet can be estimated from the timestamps 431 of packets preceding and/or following the sequence number gap caused 432 by the missing packet in the original stream. In most cases, some 433 form of linear estimate of the timestamp is good enough. 435 Furthermore, a receiver should compute an estimate of the round-trip 436 time (RTT) to the sender. This can be done, for example, by 437 measuring the retransmission delay to receive a retransmission 438 packet after a NACK message has been sent for that packet. This 439 estimate may also be obtained from past observations, RTCP report 440 round-trip time if available or any other means. 442 The receiver should not send a retransmission request as soon as it 443 detects a missing sequence number but should add some extra delay to 444 compensate for packet reordering. This extra delay may, for example, 445 be based on past observations of the experienced packet reordering. 447 To increase the robustness to the loss of a NACK message or of a 448 retransmission packet, a receiver may send a new NACK message. This 449 is referred to as multiple retransmissions. Before sending a new 450 NACK message for a missing packet, the receiver should rely on a 451 timer to be reasonably sure that the previous retransmission attempt 452 has failed in order not to cause unnecessary retransmissions. 454 Rey/Leon/Miyazaki/Varsa/Hakenberg 9 455 NACK packets MUST be sent only for the original RTP stream. If a 456 receiver wanted to perform multiple-retransmissions by sending a 457 NACK in the retransmission stream, it would not be able to know the 458 original sequence number and a timestamp estimation of the packet it 459 requests. 461 6.3 Timing rules 463 The RTCP NACK packet may be sent in a regular full compound RTCP 464 packet or in an early RTCP packet, as per AVPF [1]. Sending a NACK 465 in an early packet allows to react more quickly to a given packet 466 loss. However, in that case if a new packet loss occurs right after 467 the early RTCP packet was sent, the receiver will then have to wait 468 for the next regular RTCP compound packet after the early packet. 469 Sending NACK packets only in regular RTCP compound decreases the 470 maximum delay between detecting an original packet loss and being 471 able to send a NACK message for that packet. Implementers should 472 consider the possible implications of this fact for the application 473 being used. 475 Furthermore, receivers may make use of the minimum interval between 476 regular RTCP compound packets. This can be used, for example, to 477 keep reception reporting down to a given minimum, while still 478 allowing receivers to react to periods requiring more frequent 479 feedback, e.g. times of higher packet loss rate. In this way, 480 receivers will try to keep the amount of sent RTCP packets as low as 481 specified by the minimum interval, but are still able to report 482 packet losses quickly enough. Note that although RTCP packets may be 483 suppressed because they do not contain NACK packets, the reserved 484 RTCP bandwidth is the same as if they were sent. See AVPF [1] for 485 details. 487 7. Congestion control 489 RTP retransmission poses a risk of increasing network congestion. In 490 a best-effort environment, packet loss is caused by congestion. 491 Reacting to loss by retransmission of older data without decreasing 492 the rate of the original stream would thus further increase 493 congestion. Implementations SHOULD follow the recommendations below 494 in order to use retransmission. 496 The RTP profile under which the retransmission scheme is used 497 defines an appropriate congestion control mechanism in different 498 environments. Following the rules under the profile, an RTP 499 application can determine its acceptable bitrate and packet rate in 500 order to be fair to other TCP or RTP flows. 502 If an RTP application uses retransmission, the acceptable packet 503 rate and bitrate includes both the original and retransmitted data. 504 This guarantees that an application using retransmission achieves 505 the same fairness as one that does not. Such a rule would translate 506 in practice into the following actions: 508 Rey/Leon/Miyazaki/Varsa/Hakenberg 10 509 If enhanced service is used, it should be made sure that the total 510 bitrate and packet rate do not exceed that of the requested service. 511 It should be further monitored that the requested services are 512 actually delivered. In a best-effort environment, the sender SHOULD 513 NOT send retransmission packets without reducing the packet rate and 514 bitrate of the original stream (for example by encoding the data at 515 a lower rate). 517 In addition, the sender MAY selectively retransmit only the packets 518 that it deems important and ignore NACK messages for other packets 519 in order to limit the bitrate. 521 These congestion control mechanisms should keep the packet loss rate 522 within acceptable parameters. Packet loss is considered acceptable 523 if a TCP flow across the same network path and experiencing the same 524 network conditions would achieve an average throughput, measured on 525 a reasonable timescale, that is not less than the RTP flow is 526 achieving. If the packet loss rate exceed acceptable parameters, 527 this would mean that congestion is not kept under control and 528 retransmission should then not be used. It may further be necessary 529 to adapt the transmission rate (or the number of layers subscribed 530 for a layered multicast session), or to arrange for the receiver to 531 leave the session if the loss rate is unacceptably high. 533 8. SDP usage 535 8.1 Introduction 537 This section specifies how to describe the use of retransmission 538 with the Session Description Protocol (SDP), RFC 2327 [5]. As 539 specified in this document, the retransmission stream may be 540 conveyed in a separate RTP session, i.e. through session- 541 multiplexing, or in the same RTP session as the original stream 542 through SSRC-multiplexing. 544 The following attributes and parameters are introduced in this 545 document: "rtx", "rtx-time" and "apt". 547 The binding used for the retransmission stream to the payload type 548 number is indicated by an rtpmap attribute. The MIME subtype name 549 used in the binding is "rtx", as specified in Section 11. 551 An OPTIONAL payload format-specific parameter indicates the maximum 552 time a server will try to retransmit a packet. 553 The syntax is as follows: 555 a=fmtp : rtx-time= 556 where, 557 indicates the dynamic payload type number assigned to 558 the retransmission payload format in an rtpmap attribute. 560 Rey/Leon/Miyazaki/Varsa/Hakenberg 11 561 indicates the time in milliseconds, measured 562 from the time a packet was first sent until the time the server 563 will stop trying to retransmit the packet. The absence of the 564 rtx-time parameter for a retransmission stream means that the 565 maximum retransmission time is not defined, but MAY be 566 negotiated by other means. 568 Additionally, a new SDP payload-format-specific parameter "apt" MUST 569 be used to map the RTX payload type to the associated original 570 stream payload type as seen in the SDP description examples below. 571 If multiple payload types are used in the original stream, then 572 multiple "apt" parameters MUST be included to map each original 573 stream payload type to a different RTX payload type. The syntax of 574 this parameter is as follows: 576 a=fmtp : apt= 577 where, 578 indicates the dynamic payload type number assigned to 579 the retransmission payload format. 580 indicates the original stream payload type to which 581 this retransmission stream payload type is associated. 583 Some SDP description examples are presented in the following 584 subsections. 586 8.2 Mapping MIME Parameters into SDP 588 The information carried in the MIME media type specification has a 589 specific mapping to fields in SDP [5], which is commonly used to 590 describe RTP sessions. When SDP is used to specify retransmissions 591 for an RTP stream, the mapping is done as follows: 593 - The MIME types ("video"), ("audio") and ("text") go in the SDP 594 "m=" as the media name. 596 - The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding 597 name. The RTP clock rate in "a=rtpmap" MUST be that of the 598 retransmission payload type. See Section 4 for details on this. 600 - The AVPF profile-specific parameters "ack" and "nack" go in SDP 601 "a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types of 602 feedback. See the AVPF profile [1] for details. 604 - The retransmission payload format-specific parameters "apt" and 605 "rtx-time" go in the SDP "a=fmtp" as a semicolon separated list of 606 parameter=value pairs. 608 - Any remaining parameters go in the SDP "a=fmtp" attribute by 609 copying them directly from the MIME media type string as a semicolon 610 separated list of parameter=value pairs. 612 Rey/Leon/Miyazaki/Varsa/Hakenberg 12 613 In the following sections some example SDP descriptions are 614 presented. 616 8.3 SDP description with session-multiplexing 618 In the case of session-multiplexing, the SDP description contains 619 one media specification "m" line per RTP session. The SDP MUST 620 provide the grouping of the original and associated retransmission 621 sessions' "m" lines, using the Flow Identification (FID) semantics 622 defined in RFC YYYY [6]. 624 The following example specifies two original, AMR and MPEG-4, 625 streams on ports 49170 and 49174 and their corresponding 626 retransmission streams on ports 49172 and 49176, respectively: 628 v=0 629 o=mascha 2980675221 2980675778 IN IP4 at.home.ru 630 c=IN IP4 125.25.5.1 631 a=group:FID 1 2 632 a=group:FID 3 4 633 m=audio 49170 RTP/AVPF 96 634 a=rtpmap:96 AMR/8000 635 a=fmtp:96 octet-align=1 636 a=rtcp-fb:96 nack 637 a=mid:1 638 m=audio 49172 RTP/AVPF 97 639 a=rtpmap:97 rtx/8000 640 a=fmtp:97 apt=96;rtx-time=3000 641 a=mid:2 642 m=video 49174 RTP/AVPF 98 643 a=rtpmap:98 MP4V-ES/90000 644 a=rtcp-fb:98 nack 645 a=fmtp:98 profile-level-id=8;config=01010000012000884006682C2090A21F 646 a=mid:3 647 m=video 49176 RTP/AVPF 99 648 a=rtpmap:99 rtx/90000 649 a=fmtp:99 apt=98;rtx-time=3000 650 a=mid:4 652 A special case of the SDP description is a description that contains 653 only one original session "m" line and one retransmission session 654 "m" line, the grouping is then obvious and FID semantics MAY be 655 omitted in this special case only. 657 This is illustrated in the following example, which is an SDP 658 description for a single original MPEG-4 stream and its 659 corresponding retransmission session: 661 v=0 662 o=mascha 2980675221 2980675778 IN IP4 at.home.ru 663 c=IN IP4 125.25.5.1 664 m=video 49170 RTP/AVPF 96 666 Rey/Leon/Miyazaki/Varsa/Hakenberg 13 667 a=rtpmap:96 MP4V-ES/90000 668 a=rtcp-fb:96 nack 669 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F 670 m=video 49172 RTP/AVPF 97 671 a=rtpmap:97 rtx/90000 672 a=fmtp:97 apt=96;rtx-time=3000 674 8.4 SDP description with SSRC-multiplexing 676 The following is an example of an SDP description for an RTP video 677 session using SSRC-multiplexing with similar parameters as in the 678 single-session example above: 680 v=0 681 o=mascha 2980675221 2980675778 IN IP4 at.home.ru 682 c=IN IP4 125.25.5.1 683 m=video 49170 RTP/AVPF 96 97 684 a=rtpmap:96 MP4V-ES/90000 685 a=rtcp-fb:96 nack 686 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F 687 a=rtpmap:97 rtx/90000 688 a=fmtp:97 apt=96;rtx-time=3000 690 9. RTSP considerations 692 The Real-time Streaming Protocol (RTSP), RFC 2326 [7] is an 693 application-level protocol for control over the delivery of data 694 with real-time properties. This section looks at the issues involved 695 in controlling RTP sessions that use retransmissions. 697 9.1 RTSP control with SSRC-multiplexing 699 In the case of SSRC-multiplexing, the "m" line includes both 700 original and retransmission payload types and has a single RTSP 701 "control" attribute. The receiver uses the "m" line to request SETUP 702 and TEARDOWN of the whole media session. The RTP profile contained 703 in the transport header MUST be the AVPF profile or another suitable 704 profile allowing extended feedback. 706 In order to control the sending of the session original media 707 stream, the receiver sends as usual PLAY and PAUSE requests to the 708 sender for the session. The RTP-info header that is used to set RTP- 709 specific parameters in the PLAY response MUST be set according to 710 the RTP information of the original stream. 712 When the receiver starts receiving the original stream, it can then 713 request retransmission through RTCP NACKs without additional RTSP 714 signalling. 716 9.2 RTSP control with session-multiplexing 718 Rey/Leon/Miyazaki/Varsa/Hakenberg 14 719 In the case of session-multiplexing, each SDP "m" line has an RTSP 720 "control" attribute. Hence, when retransmission is used, both the 721 original session and the retransmission have their own "control" 722 attributes. The receiver can associate the original session and the 723 retransmission session through the FID semantics as specified in 724 Section 8. 726 The original and the retransmission streams are set up and torn down 727 separately through their respective media "control" attribute. The 728 RTP profile contained in the transport header MUST be the AVPF 729 profile or another suitable profile allowing extended feedback for 730 both the original and the retransmission session. 732 The RTSP presentation SHOULD support aggregate control and SHOULD 733 contain a session level RTSP URL. The receiver SHOULD use aggregate 734 control for an original session and its associated retransmission 735 session. Otherwise, there would need to be two different 'session- 736 id' values, i.e. different values for the original and 737 retransmission sessions, and the sender would not know how to 738 associate them. 740 The session-level "control" attribute is then used as usual to 741 control the playing of the original stream. When the receiver starts 742 receiving the original stream, it can then request retransmissions 743 through RTCP without additional RTSP signalling. 745 9.3 Retransmission in pause state 747 Because of the nature of retransmissions, the sending of 748 retransmission packets SHOULD NOT be controlled through RTSP PLAY 749 and PAUSE requests. The PLAY and PAUSE requests should not affect 750 the retransmission stream. Retransmission packets are sent upon 751 receiver requests in the original RTCP stream, regardless of the 752 state. 754 9.4 Cache control 756 Retransmission streams SHOULD NOT be cached. 758 In the case of session-multiplexing, the "Cache-Control" header 759 SHOULD be set to "no-cache" for the retransmission stream. 761 In the case of SSRC-multiplexing, RTSP cannot specify independent 762 caching for the retransmission stream, because there is a single "m" 763 line in SDP. Therefore, the implementer should take this fact into 764 account when deciding whether to cache an SSRC-multiplexed session 765 or not. 767 10. Implementation examples 769 This document mandates only the sender and receiver behaviours that 770 are necessary for interoperability. In addition, certain algorithms, 772 Rey/Leon/Miyazaki/Varsa/Hakenberg 15 773 such as rate control or buffer management when targeted at specific 774 environments, may enhance the retransmission efficiency. 776 This section gives an overview of different implementation options 777 allowed within this specification. 779 The first example is a server-driven retransmission implementation. 780 With this implementation, it is possible to retransmit lost RTP 781 packets, detect efficiently the loss of retransmissions and perform 782 multiple retransmissions, if needed. Most of the necessary processing 783 is done at the server. 785 The second example shows a receiver-driven implementation. It 786 illustrates how a receiver may increase the retransmission 787 efficiency. This implementation also increases the sender scalability 788 by reducing the load required at the sender. 790 The third example shows how retransmissions may be used in (small) 791 multicast groups in conjunction with layered encoding. It illustrates 792 that retransmissions and layered encoding may be complementary 793 techniques. 795 10.1 A sender-driven retransmission example 797 This section gives an implementation example of multiple 798 retransmissions. The sender transmits the original data in RTP 799 packets using the MPEG-4 video RTP payload format. 800 It is assumed that Generic NACK feedback messages are used, as per 801 [1]. An SDP description example with SSRC-multiplexing is given 802 below: 804 v=0 805 o=mascha 2980675221 2980675778 IN IP4 at.home.ru 806 c=IN IP4 125.25.5.1 807 m=video 49170 RTP/AVPF 96 97 808 a=rtpmap:96 MP4V-ES/90000 809 a=rtcp-fb:96 nack 810 a=rtpmap:97 rtx/90000 811 a=fmtp:97 apt=96;rtx-time=3000 813 The format-specific parameter "rtx-time" would indicate that the 814 server will buffer the sent packets in a retransmission 815 buffer for 3.0 seconds, after which the packets are deleted from 816 the retransmission buffer and will never be sent again. 818 In this implementation example, the required RTP receiver processing 819 to handle retransmission is very limited. The receiver detects packet 820 loss from the gaps observed in the received sequence numbers. It 821 signals lost packets to the sender through RTCP NACK messages as 822 defined in the AVPF profile [1]. The receiver should take into 823 account the signalled sender retransmission buffer length in order to 824 dimension its own reception buffer. It should also derive from the 826 Rey/Leon/Miyazaki/Varsa/Hakenberg 16 827 buffer length the maximum number of times retransmission of a packet 828 can be requested. 830 The sender should retransmit the packets selectively, i.e. it should 831 choose whether to retransmit a requested packet depending on the 832 packet importance, the observed QoS and congestion state of the 833 network connection to the receiver. Obviously, the sender processing 834 increases with the number of receivers as state information and 835 processing load must be allocated to each receiver. 837 10.2 A receiver-driven retransmission example 839 The receiver may have more accurate information than the sender about 840 the current network QoS such as available bandwidth, packet loss 841 rate, delay and jitter. In addition, other receiver-specific 842 parameters like buffer level, estimated importance of the lost packet 843 and application level QoS may be used by the receiver to make a more 844 efficient use of RTP retransmission through selective requests. 846 Furthermore, a receiver may acknowledge the received packets. This 847 can be done by sending ACK messages, as per [1]. Upon receiving an 848 ACK, the sender may delete all the acknowledged packets from its 849 retransmission buffer. Note that this would also require only limited 850 increase in the required RTCP bandwidth as long as ACK packets are 851 sent seldom enough. With the receiver-driven retransmission 852 implementation, processing load and buffer requirements at the sender 853 are decreased, allowing greater sender scalability. 855 Note that choosing between the sender-driven implementation and the 856 receiver-driven implementation does not imply any changes in the SDP 857 description, except for the need to signal the use of ACK RTCP 858 packets, by means of an additional SDP "a=rtcp-fb" line, as follows: 860 v=0 861 o=mascha 2980675221 2980675778 IN IP4 at.home.ru 862 c=IN IP4 125.25.5.1 863 m=video 49170 RTP/AVPF 96 97 864 a=rtpmap:96 MP4V-ES/90000 865 a=rtcp-fb:96 nack 866 a=rtcp-fb:96 ack 867 a=rtpmap:97 rtx/90000 868 a=fmtp:97 apt=96;rtx-time=3000 870 10.3 Retransmissions with Layered Transmissions 872 This section shows how to combine retransmissions with layered 873 encoding. Note that the retransmission framework is not intended as a 874 complete solution to reliable multicast. Refer to RFC 2887 [11], for 875 an overview of the problems related with reliable multicast 876 transmission. 878 Packets of different importance are sent in different RTP sessions. 879 The retransmission streams corresponding to the different layers can 881 Rey/Leon/Miyazaki/Varsa/Hakenberg 17 882 themselves be seen as different retransmission layers. The relative 883 importance of the different retransmission streams should reflect the 884 relative importance of the different original streams. 886 A retransmission stream may be sent in the same RTP session as its 887 corresponding original layer through SSRC multiplexing or in a 888 different RTP session through session multiplexing. 890 An SDP description example for SSRC-multiplexing is given below: 892 c=IN IP4 224.2.1.1/127/3 893 m=video 8000 RTP/AVPF 98 99 894 a=rtpmap:98 MP4V-ES/90000 895 a=rtcp-fb:98 nack 896 a=rtpmap:99 rtx/90000 897 a=fmtp:99 apt=98;rtx-time=3000 899 The server and the receiver may implement the retransmission methods 900 illustrated in the previous examples. In addition, they may choose to 901 request and retransmit a lost packet depending on the layer it 902 belongs to. 904 11. IANA considerations 906 11.1 Registration of audio/rtx 908 MIME type: audio 910 MIME subtype: rtx 912 Required parameters: 914 rate: the RTP timestamp clockrate is equal to the RTP timestamp 915 clockrate of the media that is retransmitted. 917 apt: associated payload type. The value of this parameter is 918 the payload type of the associated original stream. 920 Optional parameters: 922 rtx-time: indicates the time in milliseconds, measured from the 923 time a packet was first sent until the time the server will 924 stop trying to retransmit the packet 926 Encoding considerations: this type is only defined for transfer via 927 RTP. 929 Security considerations: see Section 12 of RFC XXXX 931 Interoperability considerations: none 933 Rey/Leon/Miyazaki/Varsa/Hakenberg 18 934 Published specification: RFC XXXX 936 Applications which use this media type: multimedia streaming 937 applications 939 Additional information: none 941 Person & email address to contact for further information: 942 rey@panasonic.de 943 david.leon@nokia.com 944 avt@ietf.org 946 Intended usage: COMMON 948 Author/Change controller: 949 Jose Rey 950 David Leon 951 IETF AVT WG 953 11.2 Registration of video/rtx 955 MIME type: video 957 MIME subtype: rtx 959 Required parameters: 961 rate: the RTP timestamp clockrate is equal to the RTP timestamp 962 clockrate of the media that is retransmitted. 964 apt: associated payload type. The value of this parameter is 965 the payload type of the associated original stream. 967 Optional parameters: 969 rtx-time: indicates the time in milliseconds, measured from the 970 time a packet was first sent until the time the server will 971 stop trying to retransmit the packet 973 Encoding considerations: this type is only defined for transfer via 974 RTP. 976 Security considerations: see Section 12 of RFC XXXX 978 Interoperability considerations: none 980 Published specification: RFC XXXX 982 Applications which use this media type: multimedia streaming 983 applications 985 Additional information: none 987 Rey/Leon/Miyazaki/Varsa/Hakenberg 19 988 Person & email address to contact for further information: 989 rey@panasonic.de 990 david.leon@nokia.com 991 avt@ietf.org 993 Intended usage: COMMON 995 Author/Change controller: 996 Jose Rey 997 David Leon 998 IETF AVT WG 1000 11.3 Registration of text/rtx 1002 MIME type: text 1004 MIME subtype: rtx 1006 Required parameters: 1008 rate: the RTP timestamp clockrate is equal to the RTP timestamp 1009 clockrate of the media that is retransmitted. 1011 apt: associated payload type. The value of this parameter is 1012 the payload type of the associated original stream. 1014 Optional parameters: 1016 rtx-time: indicates the time in milliseconds, measured from the 1017 time a packet was first sent until the time the server will 1018 stop trying to retransmit the packet 1020 Encoding considerations: this type is only defined for transfer via 1021 RTP. 1023 Security considerations: see Section 12 of RFC XXXX 1025 Interoperability considerations: none 1027 Published specification: RFC XXXX 1029 Applications which use this media type: multimedia streaming 1030 applications 1032 Additional information: none 1034 Person & email address to contact for further information: 1035 rey@panasonic.de 1036 david.leon@nokia.com 1037 avt@ietf.org 1039 Intended usage: COMMON 1041 Rey/Leon/Miyazaki/Varsa/Hakenberg 20 1042 Author/Change controller: 1043 Jose Rey 1044 David Leon 1045 IETF AVT WG 1047 11.4 Registration of application/rtx 1049 MIME type: application 1051 MIME subtype: rtx 1053 Required parameters: 1055 rate: the RTP timestamp clockrate is equal to the RTP timestamp 1056 clockrate of the media that is retransmitted. 1058 apt: associated payload type. The value of this parameter is 1059 the payload type of the associated original stream. 1061 Optional parameters: 1063 rtx-time: indicates the time in milliseconds, measured from the 1064 time a packet was first sent until the time the server will 1065 stop trying to retransmit the packet 1067 Encoding considerations: this type is only defined for transfer via 1068 RTP. 1070 Security considerations: see Section 12 of RFC XXXX 1072 Interoperability considerations: none 1074 Published specification: RFC XXXX 1076 Applications which use this media type: multimedia streaming 1077 applications 1079 Additional information: none 1081 Person & email address to contact for further information: 1082 rey@panasonic.de 1083 david.leon@nokia.com 1084 avt@ietf.org 1086 Intended usage: COMMON 1088 Author/Change controller: 1089 Jose Rey 1090 David Leon 1091 IETF AVT WG 1093 Rey/Leon/Miyazaki/Varsa/Hakenberg 21 1094 12. Security considerations 1096 Applications utilising encryption SHOULD encrypt both the original 1097 and the retransmission stream. Old keys will likely need to be 1098 cached so that when the keys change for the original stream, the old 1099 key is used until it is determined that the key has changed on the 1100 retransmission packets as well. 1102 The use of the same key for the retransmitted stream and the 1103 original stream may lead to security problems, e.g. two-time pads. 1104 This sharing has to be evaluated towards the chosen security 1105 protocol and security algorithms, e.g. the Secure Real-Time 1106 Transport Protocol (SRTP) RFC UUUU [8] establishes requirements for 1107 avoiding the two-time pad. 1109 RTP recommends that the initial RTP timestamp SHOULD be random to 1110 secure the stream against known plain text attacks. This payload 1111 format does not follow this recommendation as the initial timestamp 1112 will be the media timestamp of the first retransmitted packet. 1114 However, since the initial timestamp of the original stream is 1115 itself random, if the original stream is encrypted, the first 1116 retransmitted packet timestamp would also be random to an attacker. 1117 Therefore, security would not be compromised. 1119 Congestion control considerations with the use of retransmission are 1120 dealt with in Section 7 of this document. 1122 Any other security considerations of the profile under which the 1123 retransmission scheme is used should be applied. 1125 13. Acknowledgements 1127 We would like to express our gratitude to Carsten Burmeister for his 1128 participation in the development of this document. Our thanks also 1129 go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus Westerlund, 1130 Go Hori and Rahul Agarwal for their helpful comments. 1132 14. References 1134 14.1 Normative References 1136 1 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP 1137 profile for RTCP-based feedback", RFC VVVV, September 2002. 1139 2 S. Bradner, "Key words for use in RFCs to Indicate Requirement 1140 Levels", BCP 14, RFC 2119, March 1997 1142 3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A 1143 Transport Protocol for Real-Time Applications", RFC WWWW, May 1144 2002. 1146 Rey/Leon/Miyazaki/Varsa/Hakenberg 22 1147 4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", RFC ZZZZ, 1148 May 2002. 1150 5 M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 1151 2327, April 1998. 1153 6 G. Camarillo,J. Holler, G. AP. Eriksson, "Grouping of media lines 1154 in SDP", RFC YYYY, February 2002. 1156 7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol 1157 (RTSP)", RFC 2326, April 1998. 1159 8 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. 1160 Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", 1161 RFC UUUU, June 2002. 1163 14.2 Non-normative References 1165 9 C. Perkins, O. Hodson, "Options for Repair of Streaming Media", 1166 RFC 2354, June 1998. 1168 10 J. Hellstrom, "RTP for conversational text", RFC 2793, May 2000 1170 11 M. Handley, et al., "The Reliable Multicast Design Space for Bulk 1171 Data Transfer", RFC 2887, August 2000. 1173 Author's Addresses 1175 Jose Rey rey@panasonic.de 1176 Panasonic European Laboratories GmbH 1177 Monzastr. 4c 1178 D-63225 Langen, Germany 1179 Phone: +49-6103-766-134 1180 Fax: +49-6103-766-166 1182 David Leon david.leon@nokia.com 1183 Nokia Research Center 1184 6000 Connection Drive 1185 Irving, TX. USA 1186 Phone: 1-972-374-1860 1188 Akihiro Miyazaki akihiro@isl.mei.co.jp 1189 Core Software Development Center 1190 Corporate Software Development Division 1191 Matsushita Electric Industrial Co., Ltd. 1192 1006 Kadoma, Kadoma City, Osaka 571-8501, Japan 1193 Phone: +81-6-6900-9192 1194 Fax: +81-6-6900-9193 1196 Viktor Varsa viktor.varsa@nokia.com 1197 Nokia Research Center 1199 Rey/Leon/Miyazaki/Varsa/Hakenberg 23 1200 6000 Connection Drive 1201 Irving, TX. USA 1202 Phone: 1-972-374-1861 1204 Rolf Hakenberg hakenberg@panasonic.de 1205 Panasonic European Laboratories GmbH 1206 Monzastr. 4c 1207 D-63225 Langen, Germany 1208 Phone: +49-6103-766-162 1209 Fax: +49-6103-766-166 1211 Rey/Leon/Miyazaki/Varsa/Hakenberg 24