idnits 2.17.1 draft-ietf-avt-rtp-retransmission-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1592. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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-12' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 -- 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 == 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 (September 15, 2005) is 6791 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 104 looks like a reference -- Missing reference section? '1' on line 1383 looks like a reference -- Missing reference section? '2' on line 173 looks like a reference -- Missing reference section? '9' on line 202 looks like a reference -- Missing reference section? '3' on line 1466 looks like a reference -- Missing reference section? '4' on line 527 looks like a reference -- Missing reference section? '11' on line 557 looks like a reference -- Missing reference section? '5' on line 908 looks like a reference -- Missing reference section? '6' on line 944 looks like a reference -- Missing reference section? '7' on line 1015 looks like a reference -- Missing reference section? '10' on line 1159 looks like a reference -- Missing reference section? '12' on line 1243 looks like a reference Summary: 4 errors (**), 1 flaw (~~), 5 warnings (==), 19 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/Panasonic 4 12.txt D. Leon/Nokia 5 A. Miyazaki/Panasonic 6 V. Varsa/Nokia 7 R. Hakenberg/Panasonic 9 Expires: March 15, 2006 September 15, 2005 11 RTP Retransmission Payload Format 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 [Note to RFC Editor: This paragraph shall be deleted upon 38 publication as an RFC. References in this draft to RFC XXXX 39 should be replaced with the RFC number assigned to this document.] 41 Abstract 43 RTP retransmission is an effective packet loss recovery technique 44 for real-time applications with relaxed delay bounds. This 45 document describes an RTP payload format for performing 46 retransmissions. Retransmitted RTP packets are sent in a separate 47 stream from the original RTP stream. It is assumed that feedback 48 from receivers to senders is available. In particular, it is 49 assumed that RTCP feedback as defined in the extended RTP profile 50 for RTCP-based feedback (denoted RTP/AVPF), is available in this 51 memo. 53 Table of Contents 55 1. Introduction..................................................3 56 2. Terminology...................................................3 57 3. Requirements and design rationale for a retransmission scheme.4 58 3.1 Multiplexing scheme choice..................................6 59 4. Retransmission payload format.................................7 60 5. Association of retransmission and original streams............9 61 5.1 Retransmission session sharing..............................9 62 5.2 CNAME use...................................................9 63 5.3 Association at the receiver.................................9 64 6. Use with the extended RTP profile for RTCP-based feedback....10 65 6.1 RTCP at the sender.........................................11 66 6.2 RTCP Receiver Reports......................................11 67 6.3 Retransmission requests....................................11 68 6.4 Timing rules...............................................12 69 7. Congestion control...........................................13 70 8. Retransmission Payload Format MIME type registration.........14 71 8.1 Introduction...............................................14 72 8.2 Registration of audio/rtx..................................15 73 8.3 Registration of video/rtx..................................16 74 8.4 Registration of text/rtx...................................17 75 8.5 Registration of application/rtx............................17 76 8.6 Mapping to SDP.............................................18 77 8.7 SDP description with session-multiplexing..................19 78 8.8 SDP description with SSRC-multiplexing.....................20 79 9. RTSP considerations..........................................20 80 9.1 RTSP control with SSRC-multiplexing........................21 81 9.2 RTSP control with session-multiplexing.....................21 82 9.3 RTSP control of the retransmission stream..................22 83 9.4 Cache control..............................................22 84 10. Implementation examples.....................................22 85 10.1 A minimal receiver implementation example.................22 86 10.2 Retransmission of Layered Encoded Media in Multicast......23 87 11. IANA considerations.........................................24 88 12. Security considerations.....................................24 89 13. Acknowledgements............................................25 90 14. References..................................................25 91 14.1 Normative References......................................25 92 14.2 Informative References....................................26 93 15. Author's Addresses..........................................26 94 Appendix A. How to control the number of rtxs. per packet.......27 95 IPR Notices.....................................................31 96 Full Copyright Statement........................................32 98 1. Introduction 100 Packet losses between an RTP sender and receiver may significantly 101 degrade the quality of the received media. Several techniques, 102 such as forward error correction (FEC), retransmissions or 103 interleaving may be considered to increase packet loss resiliency. 104 RFC 2354 [8] discusses the different options. 106 When choosing a repair technique for a particular application, the 107 tolerable latency of the application has to be taken into account. 108 In the case of multimedia conferencing, the end-to-end delay has 109 to be at most a few hundred milliseconds in order to guarantee 110 interactivity, which usually excludes the use of retransmission. 112 With sufficient latency, the efficiency of the repair scheme can 113 be increased. The sender may use the receiver feedback in 114 order to react to losses before their playout time at the 115 receiver. 117 In the case of multimedia streaming, the user can tolerate an 118 initial latency as part of the session set-up and thus an end-to- 119 end delay of several seconds may be acceptable. RTP 120 retransmission as defined in this document is targeted at such 121 applications. 123 Furthermore, the RTP retransmission method defined herein is 124 applicable to unicast and (small) multicast groups. The present 125 document defines a payload format for retransmitted RTP packets 126 and provides protocol rules for the sender and the receiver 127 involved in retransmissions. 129 This retransmission payload format was designed for use with the 130 extended RTP profile for RTCP-based feedback, AVPF [1]. It may 131 also be used with other RTP profiles defined in the future. 133 The AVPF profile allows for more frequent feedback and for early 134 feedback. It defines a general-purpose feedback message, i.e. 135 NACK, as well as codec and application-specific feedback messages. 136 See [1] for details. 138 2. Terminology 140 The following terms are used in this document: 142 Original packet: refers to an RTP packet which carries user data 143 sent for the first time by an RTP sender. 145 Original stream: refers to the RTP stream of original packets. 147 Retransmission packet: refers to an RTP packet which is to be used 148 by the receiver instead of a lost original packet. Such a 149 retransmission packet is said to be associated with the original 150 RTP packet. 152 Retransmission request: a means by which an RTP receiver is able 153 to request that the RTP sender should send a retransmission packet 154 for a given original packet. Usually, an RTCP NACK packet as 155 specified in [1] is used as retransmission request for lost 156 packets. 158 Retransmission stream: the stream of retransmission packets 159 associated with an original stream. 161 Session-multiplexing: scheme by which the original stream and the 162 associated retransmission stream are sent into two different RTP 163 sessions. 165 SSRC-multiplexing: scheme by which the original stream and the 166 retransmission stream are sent in the same RTP session with 167 different SSRC values. 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 170 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 171 in this document are to be interpreted as described in RFC 2119 172 [2]. 174 3. Requirements and design rationale for a retransmission scheme 176 The use of retransmissions in RTP as a repair method for streaming 177 media is appropriate in those scenarios with relaxed delay bounds 178 and where full reliability is not a requirement. More 179 specifically, RTP retransmission allows to trade-off reliability 180 vs. delay, i.e. the endpoints may give up retransmitting a lost 181 packet after a given buffering time has elapsed. Unlike TCP there 182 is thus no head-of-line blocking caused by RTP retransmissions. 183 The implementer should be aware that in cases where full 184 reliability is required or higher delay and jitter can be 185 tolerated, TCP or other transport options should be considered. 187 The RTP retransmission scheme defined in this document is designed 188 to fulfil the following set of requirements: 190 1. It must not break general RTP and RTCP mechanisms. 191 2. It must be suitable for unicast and small multicast groups. 192 3. It must work with mixers and translators. 193 4. It must work with all known payload types. 194 5. It must not prevent the use of multiple payload types in a 195 session. 196 6. In order to support the largest variety of payload formats, the 197 RTP receiver must be able to derive how many and which RTP 198 packets were lost as a result of a gap in received RTP sequence 199 numbers. This requirement is referred to as sequence number 200 preservation. Without such a requirement, it would be 201 impossible to use retransmission with payload formats, such as 202 conversational text [9] or most audio/video streaming 203 applications, that use the RTP sequence number to detect lost 204 packets. 206 When designing a solution for RTP retransmission, several 207 approaches may be considered for the multiplexing of the original 208 RTP packets and the retransmitted RTP packets. 210 One approach may be to retransmit the RTP packet with its original 211 sequence number and send original and retransmission packets in 212 the same RTP stream. The retransmission packet would then be 213 identical to the original RTP packet, i.e. the same header (and 214 thus same sequence number) and the same payload. However, such an 215 approach is not acceptable because it would corrupt the RTCP 216 statistics. As a consequence, requirement 1 would not be met. 217 Correct RTCP statistics require that for every RTP packet within 218 the RTP stream, the sequence number be increased by one. 220 Another approach may be to multiplex original RTP packets and 221 retransmission packets in the same RTP stream using different 222 payload type values. With such an approach, the original packets 223 and the retransmission packets would share the same sequence 224 number space. As a result, the RTP receiver would not be able to 225 infer how many and which original packets (which sequence numbers) 226 were lost. 228 In other words, this approach does not satisfy the sequence number 229 preservation requirement (requirement 6). This in turn implies 230 that requirement 4 would not be met. Interoperability with mixers 231 and translators would also be more difficult if they did not 232 understand this new retransmission payload type in a sender RTP 233 stream. For these reasons, a solution based on payload type 234 multiplexing of original packets and retransmission packets in the 235 same RTP stream is excluded. 237 Finally, the original and retransmission packets may be sent in 238 two separate streams. These two streams may be multiplexed either 239 by sending them in two different sessions , i.e., session- 240 multiplexing, or in the same session using different SSRC values, 241 i.e. SSRC-multiplexing. Since original and retransmission packets 242 carry media of the same type, the objections in Section 5.2 of RTP 243 [3] to RTP multiplexing do not apply in this case. 245 Mixers and translators may process the original stream and simply 246 discard the retransmission stream if they are unable to utilise 247 it. 249 On the other hand, sending the original and retransmission packets 250 in two separate streams does not alone satisfy requirements 1 and 251 6. For this purpose, this document includes the original sequence 252 number in the retransmitted packets. 254 In this manner, using two separate streams satisfies all the 255 requirements listed in this section. 257 3.1 Multiplexing scheme choice 259 Session-multiplexing and SSRC-multiplexing have different pros and 260 cons: 262 Session-multiplexing is based on sending the retransmission stream 263 in a different RTP session (as defined in RTP [3]) from that of 264 the original stream, i.e. the original and retransmission streams 265 are sent to different network addresses and/or port numbers. 266 Having a separate session allows more flexibility. In multicast, 267 using two separate sessions for the original and the 268 retransmission streams allows a receiver to choose whether or not 269 to subscribe to the RTP session carrying the retransmission 270 stream. The original session may also be single-source multicast 271 while separate unicast sessions are used to convey retransmissions 272 to each of the receivers, which as a result will receive only the 273 retransmission packets they request. 275 The use of separate sessions also facilitates differential 276 treatment by the network and may simplify processing in mixers, 277 translators and packet caches. 279 With SSRC-multiplexing, a single session is needed for the 280 original and the retransmission stream. This allows streaming 281 servers and middleware which are involved in a high number of 282 concurrent sessions to minimise their port usage. 284 This retransmission payload format allows both session- 285 multiplexing and SSRC-multiplexing for unicast sessions. From an 286 implementation point of view, there is little difference between 287 the two approaches. Hence, in order to maximise interoperability, 288 both multiplexing approaches SHOULD be supported by senders and 289 receivers. For multicast sessions, session-multiplexing MUST be 290 used because the association of the original stream and the 291 retransmission stream is problematic if SSRC-multiplexing is used 292 with multicast sessions(see Section 5.3 for motivation). 294 4. Retransmission payload format 296 The format of a retransmission packet is shown below: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | RTP Header | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | OSN | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 305 | Original RTP Packet Payload | 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 The RTP header usage is as follows: 311 In the case of session-multiplexing, the same SSRC value MUST be 312 used for the original stream and the retransmission stream. In 313 the case of an SSRC collision in either the original session or 314 the retransmission session, the RTP specification requires that an 315 RTCP BYE packet MUST be sent in the session where the collision 316 happened. In addition, an RTCP BYE packet MUST also be sent for 317 the associated stream in its own session. After a new SSRC 318 identifier is obtained, the SSRC of both streams MUST be set to 319 this value. 321 In the case of SSRC-multiplexing, two different SSRC values MUST 322 be used for the original stream and the retransmission stream as 323 required by RTP. If an SSRC collision is detected for either the 324 original stream or the retransmission stream, the RTP 325 specification requires that an RTCP BYE packet MUST be sent for 326 this stream. An RTCP BYE packet MUST NOT be sent for the 327 associated stream. Therefore, only the stream that experienced 328 SSRC collision MUST choose a new SSRC value. Refer to Section 5.3 329 for the implications on the original and retransmission stream 330 SSRC association at the receiver. 332 For either multiplexing scheme, the sequence number has the 333 standard definition, i.e. it MUST be one higher than the sequence 334 number of the preceding packet sent in the retransmission stream. 336 The retransmission packet timestamp MUST be set to the original 337 timestamp, i.e. to the timestamp of the original packet. As a 338 consequence, the initial RTP timestamp for the first packet of the 339 retransmission stream is not random but equal to the original 340 timestamp of the first packet that is retransmitted. See the 341 security considerations section in this document for security 342 implications. 344 Implementers have to be aware that the RTCP jitter value for the 345 retransmission stream does not reflect the actual network jitter 346 since there could be little correlation between the time a packet 347 is retransmitted and its original timestamp. 349 The payload type is dynamic. If multiple payload types using 350 retransmission are present in the original stream, then for each 351 of these, a dynamic payload type MUST be mapped to the 352 retransmission payload format. See Section 8.1 for the 353 specification of how the mapping between original and 354 retransmission payload types is done with SDP. 356 As the retransmission packet timestamp carries the original media 357 timestamp, the timestamp clockrate used by the retransmission 358 payload type MUST be the same as the one used by the associated 359 original payload type. Therefore, if an RTP stream carries 360 payload types of different clockrates, this will also be the case 361 for the associated retransmission stream. Note that an RTP stream 362 does not usually carry payload types of different clockrates. 364 The payload of the RTP retransmission packet comprises the 365 retransmission payload header followed by the payload of the 366 original RTP packet. The length of the retransmission payload 367 header is 2 octets. This payload header contains only one field, 368 OSN (original sequence number), which MUST be set to the sequence 369 number of the associated original RTP packet. The original RTP 370 packet payload, including any possible payload headers specific to 371 the original payload type, MUST be placed right after the 372 retransmission payload header. 374 For payload formats that support encoding at multiple rates, 375 instead of retransmitting the same payload as the original RTP 376 packet the sender MAY retransmit the same data encoded at a lower 377 rate. This aims at limiting the bandwidth usage of the 378 retransmission stream. When doing so, the sender MUST ensure that 379 the receiver will still be able to decode the payload of the 380 already sent original packets that might have been encoded based 381 on the payload of the lost original packet. In addition, if the 382 sender chooses to retransmit at a lower rate, the values in the 383 payload header of the original RTP packet may not longer apply to 384 the retransmission packet and may need to be modified in the 385 retransmission packet to reflect the change in rate. The sender 386 SHOULD trade-off the decrease in bandwidth usage with the decrease 387 in quality caused by resending at a lower rate. 389 If the original RTP header carried any profile-specific 390 extensions, the retransmission packet SHOULD include the same 391 extensions immediately following the fixed RTP header as expected 392 by applications running under this profile. In this case, the 393 retransmission payload header MUST be placed after the profile- 394 specific extensions. 396 If the original RTP header carried an RTP header extension, the 397 retransmission packet SHOULD carry the same header extension. 398 This header extension MUST be placed right after the fixed RTP 399 header, as specified in RTP [3]. In this case, the retransmission 400 payload header MUST be placed after the header extension. 402 If the original RTP packet contained RTP padding, that padding 403 MUST be removed before constructing the retransmission packet. If 404 padding of the retransmission packet is needed, padding MUST be 405 performed as with any RTP packets and the padding bit MUST be set. 407 The marker bit (M), the CSRC count (CC) and the CSRC list of the 408 original RTP header MUST be copied "as is" into the RTP header of 409 the retransmission packet. 411 5. Association of retransmission and original streams 413 5.1 Retransmission session sharing 415 In the case of session-multiplexing, a retransmission session MUST 416 map to exactly one original session, i.e. the same retransmission 417 session cannot be used for different original sessions. 419 If retransmission session sharing were allowed, it would be a 420 problem for receivers, since they would receive retransmissions 421 for original sessions they might not have joined. For example, a 422 receiver wishing to receive only audio would receive also 423 retransmitted video packets if an audio and video session shared 424 the same retransmission session. 426 5.2 CNAME use 428 In both the session-multiplexing and the SSRC-multiplexing cases, 429 a sender MUST use the same CNAME [3] for an original stream and 430 its associated retransmission stream. 432 5.3 Association at the receiver 434 A receiver receiving multiple original and retransmission streams 435 needs to associate each retransmission stream with its original 436 stream. The association is done differently depending on whether 437 session-multiplexing or SSRC-multiplexing is used. 439 If session-multiplexing is used, the receiver associates the two 440 streams having the same SSRC in the two sessions. Note that the 441 payload type field cannot be used to perform the association as 442 several media streams may have the same payload type value. The 443 two sessions are themselves associated out-of-band. See Section 8 444 for how the grouping of the two sessions is done with SDP. 446 If SSRC-multiplexing is used, the receiver should first of all 447 look for two streams that have the same CNAME in the session. In 448 some cases, the CNAME may not be enough to determine the 449 association as multiple original streams in the same session may 450 share the same CNAME. For example, there can be in the same video 451 session multiple video streams mapping to different SSRCs and 452 still using the same CNAME and possibly the same PT values. Each 453 (or some) of these streams may have an associated retransmission 454 stream. 456 In this case, in order to find out the association between 457 original and retransmission streams having the same CNAME, the 458 receiver SHOULD behave as follows. 460 The association can generally be resolved when the receiver 461 receives a retransmission packet matching a retransmission request 462 which had been sent earlier. Upon reception of a retransmission 463 packet whose original sequence number has been previously 464 requested, the receiver can derive that the SSRC of the 465 retransmission packet is associated to the sender SSRC from which 466 the packet was requested. 468 However, this mechanism might fail if there are two outstanding 469 requests for the same packet sequence number in two different 470 original streams of the session. Note that since the initial 471 packet sequence numbers are random, the probability of having two 472 outstanding requests for the same packet sequence number would be 473 very small. Nevertheless, in order to avoid ambiguity in the 474 unicast case, the receiver MUST NOT have two outstanding requests 475 for the same packet sequence number in two different original 476 streams before the association is resolved. In multicast, this 477 ambiguity cannot be completely avoided, because another receiver 478 may have requested the same sequence number from another stream. 479 Therefore, SSRC-multiplexing MUST NOT be used in multicast 480 sessions. 482 If the receiver discovers that two senders are using the same SSRC 483 or if it receives an RTCP BYE packet, it MUST stop requesting 484 retransmissions for that SSRC. Upon reception of original RTP 485 packets with a new SSRC, the receiver MUST perform the SSRC 486 association again as described in this section. 488 6. Use with the extended RTP profile for RTCP-based feedback 490 This section gives general hints for the usage of this payload 491 format with the extended RTP profile for RTCP-based feedback, 492 denoted AVPF [1]. Note that the general RTCP send and receive 493 rules and the RTCP packet format as specified in RTP apply, except 494 for the changes that the AVPF profile introduces. In short, the 495 AVPF profile relaxes the RTCP timing rules and specifies 496 additional general-purpose RTCP feedback messages. See [1] for 497 details. 499 6.1 RTCP at the sender 501 In the case of session-multiplexing, Sender Report (SR) packets 502 for the original stream are sent in the original session and SR 503 packets for the retransmission stream are sent in the 504 retransmission session according to the rules of RTP. 506 In the case of SSRC-multiplexing, SR packets for both original and 507 retransmission streams are sent in the same session according to 508 the rules of RTP. The original and retransmission streams are 509 seen, as far the RTCP bandwidth calculation is concerned, as 510 independent senders belonging to the same RTP session and are thus 511 equally sharing the RTCP bandwidth assigned to senders. 513 Note that in both cases, session- and SSRC-multiplexing, BYE 514 packets MUST still be sent for both streams as specified in RTP. 515 In other words, it is not enough to send BYE packets for the 516 original stream only. 518 6.2 RTCP Receiver Reports 520 In the case of session-multiplexing, the receiver will send report 521 blocks for the original stream and the retransmission stream in 522 separate Receiver Report (RR) packets belonging to separate RTP 523 sessions. RR packets reporting on the original stream are sent in 524 the original RTP session while RR packets reporting on the 525 retransmission stream are sent in the retransmission session. The 526 RTCP bandwidth for these two sessions may be chosen independently 527 (for example through RTCP bandwidth modifiers [4]). 529 In the case of SSRC-multiplexing, the receiver sends report blocks 530 for the original and the retransmission streams in the same RR 531 packet since there is a single session. 533 6.3 Retransmission requests 535 The NACK feedback message format defined in the AVPF profile 536 SHOULD be used by receivers to send retransmission requests. 537 Whether a receiver chooses to request a packet or not is an 538 implementation issue. An actual receiver implementation should 539 take into account such factors as the tolerable application delay, 540 the network environment and the media type. 542 The receiver should generally assess whether the retransmitted 543 packet would still be useful at the time it is received. The 544 timestamp of the missing packet can be estimated from the 545 timestamps of packets preceding and/or following the sequence 546 number gap caused by the missing packet in the original stream. 547 In most cases, some form of linear estimate of the timestamp is 548 good enough. 550 Furthermore, a receiver should compute an estimate of the round- 551 trip time (RTT) to the sender. This can be done, for example, by 552 measuring the retransmission delay to receive a retransmission 553 packet after a NACK has been sent for that packet. This estimate 554 may also be obtained from past observations, RTCP report round- 555 trip time if available or any other means. A standard mechanism 556 for the receiver to estimate the RTT is specified in RTP Extended 557 Reports [11]. 559 The receiver should not send a retransmission request as soon as 560 it detects a missing sequence number but should add some extra 561 delay to compensate for packet reordering. This extra delay may, 562 for example, be based on past observations of the experienced 563 packet reordering. It should be noted that, in environments where 564 packet reordering is rare or does not take place, e.g., if the 565 underlying datalink layer affords ordered delivery, the delay may 566 be extremely low or even take the value zero. In such cases, an 567 appropriate "reorder delay" algorithm may not actually be timer- 568 based, but packet-based. E.g., if n number of packets are 569 received after a gap is detected, then it may be assumed that the 570 packet was truly lost rather than out of order. This may turn out 571 to be far easier to code on some platforms as a very short fixed 572 FIFO packet buffer as opposed to the timer-based mechanism. 574 To increase the robustness to the loss of a NACK or of a 575 retransmission packet, a receiver may send a new NACK for the same 576 packet. This is referred to as multiple retransmissions. Before 577 sending a new NACK for a missing packet, the receiver should rely 578 on a timer to be reasonably sure that the previous retransmission 579 attempt has failed and so avoid unnecessary retransmissions. The 580 timer value shall be based on the observed round-trip time. Both, 581 a static or an adaptive value MAY be used. E.g.: an adaptive timer 582 could be one that changes its value with every new request for the 583 same packet. This document does not provide any guidelines as to 584 how this adaptive value should be calculated because no 585 experiments have been done to find this out. 587 NACKs MUST be sent only for the original RTP stream. Otherwise, 588 if a receiver wanted to perform multiple retransmissions by 589 sending a NACK in the retransmission stream, it would not be able 590 to know the original sequence number and a timestamp estimation of 591 the packet it requests. 593 Appendix A gives some guidelines as to how to control the number 594 of retransmissions. 596 6.4 Timing rules 598 The NACK feedback message may be sent in a regular full compound 599 RTCP packet or in an early RTCP packet, as per AVPF [1]. Sending 600 a NACK in an early packet allows to react more quickly to a given 601 packet loss. However, in that case if a new packet loss occurs 602 right after the early RTCP packet was sent, the receiver will then 603 have to wait for the next regular RTCP compound packet after the 604 early packet. Sending NACKs only in regular RTCP compound 605 decreases the maximum delay between detecting an original packet 606 loss and being able to send a NACK for that packet. Implementers 607 should consider the possible implications of this fact for the 608 application being used. 610 Furthermore, receivers may make use of the minimum interval 611 between regular RTCP compound packets. This interval can be used 612 to keep regular receiver reporting down to a minimum, while still 613 allowing receivers to send early RTCP packets during periods 614 requiring more frequent feedback, e.g. times of higher packet loss 615 rate. Note that although RTCP packets may be suppressed because 616 they do not contain NACKs, the same RTCP bandwidth as if they were 617 sent needs to be available. See AVPF [1] for details on the use 618 of the minimum interval. 620 7. Congestion control 622 RTP retransmission poses a risk of increasing network congestion. 623 In a best-effort environment, packet loss is caused by congestion. 624 Reacting to loss by retransmission of older data without 625 decreasing the rate of the original stream would thus further 626 increase congestion. Implementations SHOULD follow the 627 recommendations below in order to use retransmission. 629 The RTP profile under which the retransmission scheme is used 630 defines an appropriate congestion control mechanism in different 631 environments. Following the rules under the profile, an RTP 632 application can determine its acceptable bitrate and packet rate 633 in order to be fair to other TCP or RTP flows. 635 If an RTP application uses retransmission, the acceptable packet 636 rate and bitrate includes both the original and retransmitted 637 data. This guarantees that an application using retransmission 638 achieves the same fairness as one that does not. Such a rule 639 would translate in practice into the following actions: 641 If enhanced service is used, it should be made sure that the total 642 bitrate and packet rate do not exceed that of the requested 643 service. It should be further monitored that the requested 644 services are actually delivered. In a best-effort environment, 645 the sender SHOULD NOT send retransmission packets without reducing 646 the packet rate and bitrate of the original stream (for example by 647 encoding the data at a lower rate). 649 In addition, the sender MAY selectively retransmit only the 650 packets that it deems important and ignore NACK messages for other 651 packets in order to limit the bitrate. 653 These congestion control mechanisms should keep the packet loss 654 rate within acceptable parameters. In the context of congestion 655 control, packet loss is considered acceptable if a TCP flow across 656 the same network path and experiencing the same network conditions 657 would achieve, on a reasonable timescale, an average throughput, 658 that is not less than the one the RTP flow achieves. If congestion 659 is not kept under control, then retransmission SHOULD NOT be used. 661 Retransmissions MAY still be sent in some cases, e. g., in 662 wireless links where packet losses are not caused by congestion, 663 if the server (or the client that makes the retransmission 664 request) estimates that a particular packet or frame is important 665 to continue play out, or if an RTSP PAUSE has been issued to allow 666 the buffer to fill up (RTSP PAUSE does not affect the sending of 667 retransmissions.) 669 Finally, it may further be necessary to adapt the transmission 670 rate (or the number of layers subscribed for a layered multicast 671 session), or to arrange for the receiver to leave the session. 673 8. Retransmission Payload Format MIME type registration 675 8.1 Introduction 677 The following MIME subtype name and parameters are introduced in 678 this document: "rtx", "rtx-time" and "apt". 680 The binding used for the retransmission stream to the payload type 681 number is indicated by an rtpmap attribute. The MIME subtype name 682 used in the binding is "rtx". 684 The "apt" (associated payload type) parameter MUST be used to map 685 the retransmission payload type to the associated original stream 686 payload type. If multiple original payload types are used, then 687 multiple "apt" parameters MUST be included to map each original 688 payload type to a different retransmission payload type. 690 An OPTIONAL payload-format-specific parameter, "rtx-time", 691 indicates the maximum time a sender will keep an original RTP 692 packet in its buffers available for retransmission. This time 693 starts with the first transmission of the packet. 695 The syntax is as follows: 697 a=fmtp: apt=;rtx-time= 698 where, 700 : indicates the dynamic payload type number assigned 701 to the retransmission payload format in an rtpmap attribute. 703 : the value of the original stream payload type to 704 which this retransmission stream payload type is associated. 706 : specifies the time in milliseconds (measured 707 from the time a packet was first sent) that a sender keeps an 708 RTP packet in its buffers available for retransmission. The 709 absence of the rtx-time parameter for a retransmission stream 710 means that the maximum retransmission time is not defined, 711 but MAY be negotiated by other means. 713 8.2 Registration of audio/rtx 715 MIME type: audio 717 MIME subtype: rtx 719 Required parameters: 721 rate: the RTP timestamp clockrate is equal to the RTP 722 timestamp clockrate of the media that is retransmitted. 724 apt: associated payload type. The value of this parameter is 725 the payload type of the associated original stream. 727 Optional parameters: 729 rtx-time: indicates the time in milliseconds (measured from 730 the time a packet was first sent) that the sender keeps an 731 RTP packet in its buffers available for retransmission. 733 Encoding considerations: this type is only defined for transfer 734 via RTP. 736 Security considerations: see Section 12 of RFC XXXX 738 Interoperability considerations: none 740 Published specification: RFC XXXX 742 Applications which use this media type: multimedia streaming 743 applications 745 Additional information: none 747 Person & email address to contact for further information: 748 jose.rey@eu.panasonic.com 749 david.leon@nokia.com 750 avt@ietf.org 752 Intended usage: COMMON 754 Authors: 755 Jose Rey 756 David Leon 758 Change controller: 760 IETF AVT WG delegated from the IESG 762 8.3 Registration of video/rtx 764 MIME type: video 766 MIME subtype: rtx 768 Required parameters: 770 rate: the RTP timestamp clockrate is equal to the RTP 771 timestamp clockrate of the media that is retransmitted. 773 apt: associated payload type. The value of this parameter is 774 the payload type of the associated original stream. 776 Optional parameters: 778 rtx-time: indicates the time in milliseconds (measured from 779 the time a packet was first sent) that the sender keeps an 780 RTP packet in its buffers available for retransmission. 782 Encoding considerations: this type is only defined for transfer 783 via RTP. 785 Security considerations: see Section 12 of RFC XXXX 787 Interoperability considerations: none 789 Published specification: RFC XXXX 791 Applications which use this media type: multimedia streaming 792 applications 794 Additional information: none 796 Person & email address to contact for further information: 797 jose.rey@eu.panasonic.com 798 david.leon@nokia.com 799 avt@ietf.org 801 Intended usage: COMMON 803 Authors: 804 Jose Rey 805 David Leon 807 Change controller: 808 IETF AVT WG delegated from the IESG 810 8.4 Registration of text/rtx 812 MIME type: text 814 MIME subtype: rtx 816 Required parameters: 818 rate: the RTP timestamp clockrate is equal to the RTP 819 timestamp clockrate of the media that is retransmitted. 821 apt: associated payload type. The value of this parameter is 822 the payload type of the associated original stream. 824 Optional parameters: 826 rtx-time: indicates the time in milliseconds (measured from 827 the time a packet was first sent) that the sender keeps an 828 RTP packet in its buffers available for retransmission. 830 Encoding considerations: this type is only defined for transfer 831 via RTP. 833 Security considerations: see Section 12 of RFC XXXX 835 Interoperability considerations: none 837 Published specification: RFC XXXX 839 Applications which use this media type: multimedia streaming 840 applications 842 Additional information: none 844 Person & email address to contact for further information: 845 jose.rey@eu.panasonic.com 846 david.leon@nokia.com 847 avt@ietf.org 849 Intended usage: COMMON 851 Authors: 852 Jose Rey 853 David Leon 855 Change controller: 856 IETF AVT WG delegated from the IESG 858 8.5 Registration of application/rtx 860 MIME type: application 861 MIME subtype: rtx 863 Required parameters: 865 rate: the RTP timestamp clockrate is equal to the RTP 866 timestamp clockrate of the media that is retransmitted. 868 apt: associated payload type. The value of this parameter is 869 the payload type of the associated original stream. 871 Optional parameters: 873 rtx-time: indicates the time in milliseconds (measured from 874 the time a packet was first sent) that the sender keeps an 875 RTP packet in its buffers available for retransmission. 877 Encoding considerations: this type is only defined for transfer 878 via RTP. 880 Security considerations: see Section 12 of RFC XXXX 882 Interoperability considerations: none 884 Published specification: RFC XXXX 886 Applications which use this media type: multimedia streaming 887 applications 889 Additional information: none 891 Person & email address to contact for further information: 892 jose.rey@eu.panasonic.com 893 david.leon@nokia.com 894 avt@ietf.org 896 Intended usage: COMMON 898 Authors: 899 Jose Rey 900 David Leon 902 Change controller: 903 IETF AVT WG delegated from the IESG 905 8.6 Mapping to SDP 907 The information carried in the MIME media type specification has a 908 specific mapping to fields in SDP [5], which is commonly used to 909 describe RTP sessions. When SDP is used to specify 910 retransmissions for an RTP stream, the mapping is done as 911 follows: 913 - The MIME types ("video"), ("audio"), ("text") and 914 ("application") go in the SDP "m=" as the media name. 916 - The MIME subtype ("rtx") goes in SDP "a=rtpmap" as the encoding 917 name. The RTP clock rate in "a=rtpmap" MUST be that of the 918 retransmission payload type. See Section 4 for details on this. 920 - The AVPF profile-specific parameters "ack" and "nack" go in SDP 921 "a=rtcp-fb". Several SDP "a=rtcp-fb" are used for several types 922 of feedback. See the AVPF profile [1] for details. 924 - The retransmission payload-format-specific parameters "apt" and 925 "rtx-time" go in the SDP "a=fmtp" as a semicolon separated list of 926 parameter=value pairs. 928 - Any remaining parameters go in the SDP "a=fmtp" attribute by 929 copying them directly from the MIME media type string as a 930 semicolon separated list of parameter=value pairs. 932 In the following sections some example SDP descriptions are 933 presented. In some of these examples, long lines are folded to 934 meet the column width constraints of this document; the backslash 935 ("\") at the end of a line and the carriage return that follows it 936 should be ignored. 938 8.7 SDP description with session-multiplexing 940 In the case of session-multiplexing, the SDP description contains 941 one media specification "m" line per RTP session. The SDP MUST 942 provide the grouping of the original and associated retransmission 943 sessions' "m" lines, using the Flow Identification (FID) semantics 944 defined in RFC 3388 [6]. 946 The following example specifies two original, AMR and MPEG-4, 947 streams on ports 49170 and 49174 and their corresponding 948 retransmission streams on ports 49172 and 49176, respectively: 950 v=0 951 o=mascha 2980675221 2980675778 IN IP4 host.example.net 952 c=IN IP4 192.0.2.0 953 a=group:FID 1 2 954 a=group:FID 3 4 955 m=audio 49170 RTP/AVPF 96 956 a=rtpmap:96 AMR/8000 957 a=fmtp:96 octet-align=1 958 a=rtcp-fb:96 nack 959 a=mid:1 960 m=audio 49172 RTP/AVPF 97 961 a=rtpmap:97 rtx/8000 962 a=fmtp:97 apt=96;rtx-time=3000 963 a=mid:2 964 m=video 49174 RTP/AVPF 98 965 a=rtpmap:98 MP4V-ES/90000 966 a=rtcp-fb:98 nack 967 a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\ 968 0A21F 969 a=mid:3 970 m=video 49176 RTP/AVPF 99 971 a=rtpmap:99 rtx/90000 972 a=fmtp:99 apt=98;rtx-time=3000 973 a=mid:4 975 A special case of the SDP description is a description that 976 contains only one original session "m" line and one retransmission 977 session "m" line, the grouping is then obvious and FID semantics 978 MAY be omitted in this special case only. 980 This is illustrated in the following example, which is an SDP 981 description for a single original MPEG-4 stream and its 982 corresponding retransmission session: 984 v=0 985 o=mascha 2980675221 2980675778 IN IP4 host.example.net 986 c=IN IP4 192.0.2.0 987 m=video 49170 RTP/AVPF 96 988 a=rtpmap:96 MP4V-ES/90000 989 a=rtcp-fb:96 nack 990 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\ 991 0A21F 992 m=video 49172 RTP/AVPF 97 993 a=rtpmap:97 rtx/90000 994 a=fmtp:97 apt=96;rtx-time=3000 996 8.8 SDP description with SSRC-multiplexing 998 The following is an example of an SDP description for an RTP video 999 session using SSRC-multiplexing with similar parameters as in the 1000 single-session example above: 1002 v=0 1003 o=mascha 2980675221 2980675778 IN IP4 host.example.net 1004 c=IN IP4 192.0.2.0 1005 m=video 49170 RTP/AVPF 96 97 1006 a=rtpmap:96 MP4V-ES/90000 1007 a=rtcp-fb:96 nack 1008 a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\ 1009 0A21F 1010 a=rtpmap:97 rtx/90000 1011 a=fmtp:97 apt=96;rtx-time=3000 1013 9. RTSP considerations 1015 The Real-time Streaming Protocol (RTSP), RFC 2326 [7] is an 1016 application-level protocol for control over the delivery of data 1017 with real-time properties. This section looks at the issues 1018 involved in controlling RTP sessions that use retransmissions. 1020 9.1 RTSP control with SSRC-multiplexing 1022 In the case of SSRC-multiplexing, the "m" line includes both 1023 original and retransmission payload types and has a single RTSP 1024 "control" attribute. The receiver uses the "m" line to request 1025 SETUP and TEARDOWN of the whole media session. The RTP profile 1026 contained in the Transport header MUST be the AVPF profile or 1027 another suitable profile allowing extended feedback. If the SSRC 1028 value is included in the SETUP response's Transport header, it 1029 MUST be that of the original stream. 1031 In order to control the sending of the session original media 1032 stream, the receiver sends as usual PLAY and PAUSE requests to the 1033 sender for the session. The RTP-info header that is used to set 1034 RTP-specific parameters in the PLAY response MUST be set according 1035 to the RTP information of the original stream. 1037 When the receiver starts receiving the original stream, it can 1038 then request retransmission through RTCP NACKs without additional 1039 RTSP signalling. 1041 9.2 RTSP control with session-multiplexing 1043 In the case of session-multiplexing, each SDP "m" line has an RTSP 1044 "control" attribute. Hence, when retransmission is used, both the 1045 original session and the retransmission have their own "control" 1046 attributes. The receiver can associate the original session and 1047 the retransmission session through the FID semantics as specified 1048 in Section 8. 1050 The original and the retransmission streams are set up and torn 1051 down separately through their respective media "control" 1052 attribute. The RTP profile contained in the Transport header MUST 1053 be the AVPF profile or another suitable profile allowing extended 1054 feedback for both the original and the retransmission session. 1056 The RTSP presentation SHOULD support aggregate control and SHOULD 1057 contain a session level RTSP URL. The receiver SHOULD use 1058 aggregate control for an original session and its associated 1059 retransmission session. Otherwise, there would need to be two 1060 different 'session-id' values, i.e. different values for the 1061 original and retransmission sessions, and the sender would not 1062 know how to associate them. 1064 The session-level "control" attribute is then used as usual to 1065 control the playing of the original stream. When the receiver 1066 starts receiving the original stream, it can then request 1067 retransmissions through RTCP without additional RTSP signalling. 1069 9.3 RTSP control of the retransmission stream 1071 Because of the nature of retransmissions, the sending of 1072 retransmission packets SHOULD NOT be controlled through RTSP PLAY 1073 and PAUSE requests. The PLAY and PAUSE requests SHOULD NOT affect 1074 the retransmission stream. Retransmission packets are sent upon 1075 receiver requests in the original RTCP stream, regardless of the 1076 state. 1078 9.4 Cache control 1080 Retransmission streams SHOULD NOT be cached. 1082 In the case of session-multiplexing, the "Cache-Control" header 1083 SHOULD be set to "no-cache" for the retransmission stream. 1085 In the case of SSRC-multiplexing, RTSP cannot specify independent 1086 caching for the retransmission stream, because there is a single 1087 "m" line in SDP. Therefore, the implementer should take this fact 1088 into account when deciding whether to cache an SSRC-multiplexed 1089 session or not. 1091 10. Implementation examples 1093 This document mandates only the sender and receiver behaviours 1094 that are necessary for interoperability. In addition, certain 1095 algorithms, such as rate control or buffer management when 1096 targeted at specific environments, may enhance the retransmission 1097 efficiency. 1099 This section gives an overview of different implementation options 1100 allowed within this specification. 1102 The first example describes a minimal receiver implementation. 1103 With this implementation, it is possible to retransmit lost RTP 1104 packets, detect efficiently the loss of retransmissions and 1105 perform multiple retransmissions, if needed. Most of the 1106 necessary processing is done at the server. 1108 The second example shows how retransmissions may be used in 1109 (small) multicast groups in conjunction with layered encoding. It 1110 illustrates that retransmissions and layered encoding may be 1111 complementary techniques. 1113 10.1 A minimal receiver implementation example 1115 This section gives an example of an implementation supporting 1116 multiple retransmissions. The sender transmits the original data 1117 in RTP packets using the MPEG-4 video RTP payload format. 1118 It is assumed that NACK feedback messages are used, as per 1119 [1]. An SDP description example with SSRC-multiplexing is given 1120 below: 1122 v=0 1123 o=mascha 2980675221 2980675778 IN IP4 host.example.net 1124 c=IN IP4 192.0.2.0 1125 m=video 49170 RTP/AVPF 96 97 1126 a=rtpmap:96 MP4V-ES/90000 1127 a=rtcp-fb:96 nack 1128 a=rtpmap:97 rtx/90000 1129 a=fmtp:97 apt=96;rtx-time=3000 1131 The format-specific parameter "rtx-time" indicates that the server 1132 will buffer the sent packets in a retransmission buffer for 3.0 1133 seconds, after which the packets are deleted from the 1134 retransmission buffer and will never be sent again. 1136 In this implementation example, the required RTP receiver 1137 processing to handle retransmission is kept to a minimum. The 1138 receiver detects packet loss from the gaps observed in the 1139 received sequence numbers. It signals lost packets to the sender 1140 through NACKs as defined in the AVPF profile [1]. The receiver 1141 should take into account the signalled sender retransmission 1142 buffer length in order to dimension its own reception buffer. It 1143 should also derive from the buffer length the maximum number of 1144 times the retransmission of a packet can be requested. 1146 The sender should retransmit the packets selectively, i.e. it 1147 should choose whether to retransmit a requested packet depending 1148 on the packet importance, the observed QoS and congestion state of 1149 the network connection to the receiver. Obviously, the sender 1150 processing increases with the number of receivers as state 1151 information and processing load must be allocated to each 1152 receiver. 1154 10.2 Retransmission of Layered Encoded Media in Multicast 1156 This section shows how to combine retransmissions with layered 1157 encoding in multicast sessions. Note that the retransmission 1158 framework is not intended as a complete solution to reliable 1159 multicast. Refer to RFC 2887 [10], for an overview of the 1160 problems related with reliable multicast transmission. 1162 Packets of different importance are sent in different RTP 1163 sessions. The retransmission streams corresponding to the 1164 different layers can themselves be seen as different 1165 retransmission layers. The relative importance of the different 1166 retransmission streams should reflect the relative importance of 1167 the different original streams. 1169 In multicast, SSRC-multiplexing of the original and retransmission 1170 streams is not allowed as per Section 5.3 of this document. For 1171 this reason, the retransmission stream(s) MUST be sent in 1172 different RTP session(s) using session-multiplexing. 1174 An SDP description example of multicast retransmissions for 1175 layered encoded media is given below: 1177 m=video 8000 RTP/AVPF 98 1178 c=IN IP4 224.2.1.0/127/3 1179 a=rtpmap:98 MP4V-ES/90000 1180 a=rtcp-fb:98 nack 1181 m=video 8000 RTP/AVPF 99 1182 c=IN IP4 224.2.1.3/127/3 1183 a=rtpmap:99 rtx/90000 1184 a=fmtp:99 apt=98;rtx-time=3000 1186 The server and the receiver may implement the retransmission 1187 methods illustrated in the previous examples. In addition, they 1188 may choose to request and retransmit a lost packet depending on 1189 the layer it belongs to. 1191 11. IANA considerations 1193 A new MIME subtype name, "rtx", has been registered for four 1194 different media types, as follows: "video", "audio", "text" and 1195 "application". An additional REQUIRED parameter, "apt", and an 1196 OPTIONAL parameter, "rtx-time", are defined. See Section 8 for 1197 details. 1199 12. Security considerations 1201 RTP packets using the payload format defined in this specification 1202 are subject to the general security considerations discussed in 1203 RTP, Section 9. 1205 In common streaming scenarios message authentication, data 1206 integrity, replay protection and confidentiality are desired. 1208 The absence of authentication may enable man-in-the-middle and 1209 replay attacks, which can be very harmful for RTP retransmission. 1210 For example: tampered RTCP packets may trigger inappropriate 1211 retransmissions that effectively reduce the actual bitrate share 1212 allocated to the original data stream, tampered RTP retransmission 1213 packets could cause the client's decoder to crash, tampered 1214 retransmission requests may invalidate the SSRC association 1215 mechanism described in Section 5 of this document. On the other 1216 hand, replayed packets could lead to false re-ordering and RTT 1217 measurements (required for the retransmission request strategy) 1218 and may cause the receiver buffer to overflow. 1220 Further, in order to ensure confidentiality of the data, the 1221 original payload data needs to be encrypted. There is actually no 1222 need to encrypt the 2-byte retransmission payload header since it 1223 does not provide any hints about the data content. 1225 Furthermore, it is RECOMMENDED that the cryptography mechanisms 1226 used for this payload format provide protection against known 1227 plaintext attacks. RTP recommends that the initial RTP timestamp 1228 SHOULD be random to secure the stream against known plaintext 1229 attacks. This payload format does not follow this recommendation 1230 as the initial timestamp will be the media timestamp of the first 1231 retransmitted packet. However, since the initial timestamp of the 1232 original stream is itself random, if the original stream is 1233 encrypted, the first retransmitted packet timestamp would also be 1234 random to an attacker. Therefore, confidentiality would not be 1235 compromised. 1237 If cryptography is used to provide security services on the 1238 original stream, then the same services, with equivalent 1239 cryptographic strength, MUST be provided on the retransmission 1240 stream. The use of the same key for the retransmitted stream and 1241 the original stream may lead to security problems, e. g., two-time 1242 pads. Refer to Section 9.1 of the Secure Real-Time Transport 1243 Protocol (SRTP)[12] for a discussion the implications of two-time 1244 pads and how to avoid them. 1246 At the time of writing this document, SRTP does not provide all 1247 the security services mentioned. There are, at least, two reasons 1248 for this: 1) the occurrence of two-time pads and 2) the fact that 1249 this payload format typically works under the RTP/AVPF profile 1250 while SRTP only supports RTP/AVP. An adapted variant of SRTP 1251 shall solve these shortcomings in the future. 1253 Congestion control considerations with the use of retransmission 1254 are dealt with in Section 7 of this document. 1256 13. Acknowledgements 1258 We would like to express our gratitude to Carsten Burmeister for 1259 his participation in the development of this document. Our thanks 1260 also go to Koichi Hata, Colin Perkins, Stephen Casner, Magnus 1261 Westerlund, Go Hori and Rahul Agarwal for their helpful comments. 1263 14. References 1265 14.1 Normative References 1267 1 J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey, "Extended RTP 1268 profile for RTCP-based feedback", draft-ietf-avt-rtcp-feedback- 1269 11.txt, August 2004. 1271 2 S. Bradner, "Key words for use in RFCs to Indicate Requirement 1272 Levels", BCP 14, RFC 2119, March 1997 1274 3 H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, "RTP: A 1275 Transport Protocol for Real-Time Applications", RFC 3550, July 1276 2003. 1278 4 S. Casner, "SDP bandwidth modifiers for RTCP bandwidth", RFC 1279 3556, July 2003. 1281 5 M. Handley, V. Jacobson, "SDP: Session Description Protocol", 1282 RFC 2327, April 1998. 1284 6 G. Camarillo, J. Holler, G. AP. Eriksson, "Grouping of media 1285 lines in the Session Description Protocol (SDP)", RFC 3388, 1286 December 2002. 1288 7 H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming 1289 Protocol (RTSP)", RFC 2326, April 1998. 1291 14.2 Informative References 1293 8 C. Perkins, O. Hodson, "Options for Repair of Streaming Media", 1294 RFC 2354, June 1998. 1296 9 G. Hellstrom, "RTP for conversational text", RFC 2793, May 2000 1298 10 M. Handley, et al., "The Reliable Multicast Design Space for 1299 Bulk Data Transfer", RFC 2887, August 2000. 1301 11 Friedman, et. al., "RTP Extended Reports", Work in Progress. 1303 12 M. Baugher, D. A. McGrew, D. Oran, R. Blom, E. Carrara, M. 1304 Naslund, K. Norrman, "The Secure Real-Time Transport Protocol", 1305 RFC 3711, March 2004. 1307 13 R. Hovey and S. Bradner, "The Organizations Involved in the IETF 1308 Standards Process," BCP 11, RFC 2028, IETF, October 1996. 1310 15. Author's Addresses 1312 Jose Rey jose.rey@eu.panasonic.com 1313 Panasonic R&D Center Germany GmbH 1314 Monzastr. 4c 1315 D-63225 Langen, Germany 1316 Phone: +49-6103-766-134 1317 Fax: +49-6103-766-166 1319 David Leon david.leon@nokia.com 1320 Nokia Research Center 1321 6000 Connection Drive 1322 Irving, TX. USA 1323 Phone: 1-972-374-1860 1325 Akihiro Miyazaki miyazaki.akihiro@jp.panasonic.com 1326 CE Architecture Development Center 1327 Matsushita Electric Industrial Co., Ltd. 1328 1006 Kadoma, Kadoma City, Osaka 571-8501, Japan 1329 Phone: +81-6-6900-9172 1330 Fax: +81-6-6900-9173 1332 Viktor Varsa viktor.varsa@nokia.com 1333 Nokia Research Center 1334 6000 Connection Drive 1335 Irving, TX. USA 1336 Phone: 1-972-374-1861 1338 Rolf Hakenberg rolf.hakenberg@eu.panasonic.com 1339 Panasonic R&D Center Germany GmbH 1340 Monzastr. 4c 1341 D-63225 Langen, Germany 1342 Phone: +49-6103-766-162 1343 Fax: +49-6103-766-166 1345 Appendix A. How to control the number of rtxs. per packet 1347 Finding out the number of retransmissions (rtxs.) per packet for 1348 achieving the best possible transmission is a difficult task. Of 1349 course, the absolute minimum should be one (1) - otherwise, do not 1350 use this payload format. Moreover, as of date of publication, the 1351 authors were not aware of any studies on the number of 1352 retransmissions per packet that should be used for best 1353 performance. To help implementers and researchers on this item, 1354 this section describes an estimate of the buffering time required 1355 for achieving a given number of retransmissions. Once this time 1356 has been calculated, it can be communicated to the client via SDP 1357 parameter "rtx-time", as defined in this document. 1359 Scenario and Assumptions 1360 ======================== 1361 * Streaming scenario with relaxed delay bounds. Client and server 1362 are provided with buffering space as indicated by the parameter 1363 "rtx-time" in SDP. 1365 * RTP AVPF profile used with SSRC-multiplexing retransmission 1366 scheme: 1 SSRC for original packets, 1 for retransmission packets. 1368 * Default RTCP bandwidth share for SRs and RRs, i.e., SR+RR=0.05. 1369 We have senders (2) and receivers (1). Receivers and senders get 1370 equally 1/3 of the RTCP bandwidth share because the proportion of 1371 senders is greater than 1/4 of session members. 1373 * avg-rtcp-size is approximated by 120 bytes. This is a rounded- 1374 up average of 2 SRs, one for each SSRC, containing 40/8/28/32 1375 bytes for IPv6/UDP/SR/SDES with CNAME, thus making 105 bytes each; 1376 and a RR with 40/8/64/32 bytes for IPv6/UDP/2*RR/SDES, making 157 1377 bytes. Since senders and receivers share the RTCP bandwidth 1378 equally, then avg-rtcp-size=(157+105+105)/3=117,3~=120 bytes. The 1379 important characteristic of this value is that it is something 1380 over 100 bytes, which seems to be a representative figure for 1381 typical configurations. 1383 * The profile used is AVPF [1] and Generic NACKs are used for 1384 requesting retransmissions. This adds 16 bytes of overhead for 1 1385 NACK and 4 bytes more for every additional NACK FCI field. 1387 * We assume a worst-case scenario in which each packet exhausts 1388 its corresponding number of available retransmissions, N, before 1389 it is received. This means that if a packet may be requested for 1390 retransmission a maximum of 2 times, the corresponding generic 1391 NACK report block requesting that particular packet is sent in two 1392 consecutive RTCP compounds; likewise, if it is requested for 1393 retransmission 10 times, then the generic NACK is sent 10 times. 1394 This assumption makes the RTCP packet size approx. constant after 1395 N*RTCP intervals (seconds), namely to avg-rtcp-size= 120 + 1396 (receiver-RTCP-bw-share)*(12 + 4*N). In our case, the receiver 1397 RTCP bandwidth share is 1/3, thus avg-rtcp-size = 124 + 4*N/3. 1399 * Two delay parameters are difficult to approximate and may be 1400 implementation-dependent. Therefore, we list them here explicitly 1401 without assigning them a particular value: one is the packet loss 1402 detection time (T2) and the other feedback processing and queuing 1403 time for retransmissions (T5). Implementers shall assign 1404 appropriate values to these two parameters . 1406 Graphically, we have: 1408 Sender 1409 +-+---------------------------------^-----\----------------- 1410 \ \ / \ 1411 \ \ | | 1412 SN=0 \ \ SN=1 / \ RTX(SN=0) 1413 \ \ / \ 1414 X \ / \ 1415 `. / \ 1416 \ / \ 1417 \ | | 1418 \ / \ ...... 1419 \ / \ 1420 -------------V----D--------/-----------------------V-------- 1421 T1 T2 T3 T4 T5 T1 ........ 1422 Receiver 1424 Legend: 1425 ======= 1426 DL : downlink (client->server) 1427 UL : uplink (server->client) 1428 Time unit is seconds, s. 1429 Bitrate unit is bit per second, bps. 1431 DL transmission time : T1= physical-delay-DL + 1432 tx-delay-DL(=avg-pkt-size/DL-bitrate) + interarrival-delay-jitter 1434 Time to detect packet loss : T2= pkt-loss-detect-time 1435 Time to report packet loss : T3= time-to-next-rtcp-report 1437 UL transmission time : T4= physical-delay-UL + 1438 transmission-delay-UL + interarrival-delay-jitter 1440 Retransmissions processing time : T5= feedback-processing-time + 1441 rtx-queuing-time 1443 Goal 1444 ==== 1445 To find an estimate of the buffering time, T(), that a streaming 1446 server shall use in order to enable a given number of 1447 retransmissions for each packet, N. This time is approximately 1448 equal at the server and at the client, if one considers that the 1449 client starts buffering T1 seconds later. 1451 Solution 1452 ======== 1453 First we find the value of the estimate for 1 retransmission, 1454 T(1)=T: 1456 T = T1 + T2 + T3 + T4 + T5 1458 Since T1 + T4 ~= RTT, 1460 T = RTT + T2 + T3 + T5 1462 The worst case for T3 would be that we assume that reporting has 1463 to wait a whole RTCP interval and that the maximum randomization 1464 factor of 1.5 is applied. Therefore, after applying the 1465 subsequent compensation to avoid traffic bursts (see RTP Section 1466 A.7 [3]), we have that T3 = 1.5/1.21828*RTCP-Interval. Thus, 1468 T = RTT + 1.2312*RTCP-Interval + T2 + T5 1470 On the other hand, RTCP-Interval = avg-rtcp-size*8*(senders + 1471 receivers)/(RR+RS). In this scenario: sender + receivers = 3; 1472 RR+RS is the receiver report plus sender report bandwidth share, 1473 in this case, equal to the default 5% of session bandwidth, bw. 1474 We assume an average RTCP packet size, avg-rtcp-size=120 bytes. 1475 This includes Thus: 1477 T = RTT + 1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5 1479 for 1 retransmission. 1481 For enabling N retransmissions, the available buffering time in a 1482 streaming server or client is 1483 approximately: 1485 T(N) = N*(RTT+1.2312*avg-rtcp-size*8*3/(0.05*bw) + T2 + T5) 1487 where, as per above, 1489 avg-rtcp-size = 120 + (receiver-RTCP-bw-share=1/3)*(12 + 4*N) = 1490 = 124 + 4*N/3. 1492 Numbers 1493 ======== 1494 If we ignore the effect of T2 and T5, i.e., assume all losses are 1495 detected immediately and that there is no additional delay due to 1496 feedback processing or retransmission queuing, we have the 1497 following buffering times for different values of N: 1499 RTCP w/ several Generic NACKs; variable packet size= 124 + 4*N/3 1500 bytes 1502 |============|=====|======================================| 1503 | RTP BW | RTT | N value | 1504 |============|=====|======================================| 1506 1,00 2,00 5,00 7,00 10,00 1507 64000 0,05 1,21 2,44 6,28 8,97 13,18 1508 128000 0,05 0,63 1,27 3,27 4,66 6,84 1509 256000 0,05 0,34 0,68 1,76 2,50 3,67 1510 512000 0,05 0,19 0,39 1,00 1,43 2,09 1511 1024000 0,05 0,12 0,25 0,63 0,89 1,29 1512 5000000 0,05 0,06 0,13 0,33 0,46 0,66 1513 10000000 0,05 0,06 0,11 0,29 0,41 0,58 1515 64000 0,2 1,36 2,74 7,03 10,02 14,68 1516 128000 0,2 0,78 1,57 4,02 5,71 8,34 1517 256000 0,2 0,49 0,98 2,51 3,55 5,17 1518 512000 0,2 0,34 0,69 1,75 2,48 3,59 1519 1024000 0,2 0,27 0,55 1,38 1,94 2,79 1520 5000000 0,2 0,21 0,43 1,08 1,51 2,16 1521 10000000 0,2 0,21 0,41 1,04 1,46 2,08 1523 64000 1 2,16 4,34 11,03 15,62 22,68 1524 128000 1 1,58 3,17 8,02 11,31 16,34 1525 256000 1 1,29 2,58 6,51 9,15 13,17 1526 512000 1 1,14 2,29 5,75 8,08 11,59 1527 1024000 1 1,07 2,15 5,38 7,54 10,79 1528 5000000 1 1,01 2,03 5,08 7,11 10,16 1529 10000000 1 1,01 2,01 5,04 7,06 10,08 1531 To quantify the error of not taking the Generic NACKS into 1532 account, we can do the same numbers, but ignoring the Generic NACK 1533 contribution, avg-rtcp-size ~= 120 bytes. As we see from below, 1534 this may result in a buffer estimation error of 1-1.5 seconds (5- 1535 10%) for lower bandwidth values and higher number of 1536 retransmissions. This effect is low in this case. Nevertheless, 1537 it should be carefully evaluated for the particular scenario; that 1538 is why the formula includes it. 1540 RTCP w/o Generic NACK, fixed packet size ~= 120 bytes 1542 |============|=====|======================================| 1543 | RTP BW | RTT | N value | 1544 |============|=====|======================================| 1545 1,00 2,00 5,00 7,00 10,00 1546 64000 0,05 1,16 2,32 5,79 8,11 11,58 1547 128000 0,05 0,60 1,21 3,02 4,23 6,04 1548 256000 0,05 0,33 0,65 1,64 2,29 3,27 1549 512000 0,05 0,19 0,38 0,94 1,32 1,89 1550 1024000 0,05 0,12 0,24 0,60 0,83 1,19 1551 5000000 0,05 0,06 0,13 0,32 0,45 0,64 1552 10000000 0,05 0,06 0,11 0,29 0,40 0,57 1554 64000 0,2 1,31 2,62 6,54 9,16 13,08 1555 128000 0,2 0,75 1,51 3,77 5,28 7,54 1556 256000 0,2 0,48 0,95 2,39 3,34 4,77 1557 512000 0,2 0,34 0,68 1,69 2,37 3,39 1558 1024000 0,2 0,27 0,54 1,35 1,88 2,69 1559 5000000 0,2 0,21 0,43 1,07 1,50 2,14 1560 10000000 0,2 0,21 0,41 1,04 1,45 2,07 1562 64000 1 2,11 4,22 10,54 14,76 21,08 1563 128000 1 1,55 3,11 7,77 10,88 15,54 1564 256000 1 1,28 2,55 6,39 8,94 12,77 1565 512000 1 1,14 2,28 5,69 7,97 11,39 1566 1024000 1 1,07 2,14 5,35 7,48 10,69 1567 5000000 1 1,01 2,03 5,07 7,10 10,14 1568 10000000 1 1,01 2,01 5,04 7,05 10,07 1570 IPR Notices 1572 The IETF takes no position regarding the validity or scope of any 1573 Intellectual Property Rights or other rights that might be claimed 1574 to pertain to the implementation or use of the technology 1575 described in this document or the extent to which any license 1576 under such rights might or might not be available; nor does it 1577 represent that it has made any independent effort to identify any 1578 such rights. Information on the procedures with respect to rights 1579 in RFC documents can be found in BCP 78 and BCP 79. 1581 Copies of IPR disclosures made to the IETF Secretariat and any 1582 assurances of licenses to be made available, or the result of an 1583 attempt made to obtain a general license or permission for the use 1584 of such proprietary rights by implementers or users of this 1585 specification can be obtained from the IETF on-line IPR repository 1586 at http://www.ietf.org/ipr. 1588 The IETF invites any interested party to bring to its attention 1589 any copyrights, patents or patent applications, or other 1590 proprietary rights that may cover technology that may be required 1591 to implement this standard. Please address the information to the 1592 IETF at ietf-ipr@ietf.org. 1594 Full Copyright Statement 1596 Copyright (C) The Internet Society (2005). This document is 1597 subject to the rights, licenses and restrictions contained in BCP 1598 78, and except as set forth therein, the authors retain all their 1599 rights. 1601 This document and the information contained herein are provided on 1602 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1603 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1604 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1605 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1606 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1607 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1608 PARTICULAR PURPOSE.