idnits 2.17.1 draft-xie-avt-forward-shifted-red-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 568. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2198, but the abstract doesn't seem to directly say this. It does mention RFC2198 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 398 has weird spacing: '...al mode sw1 ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2198, updated by this document, for RFC5378 checks: 1997-06-25) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 3, 2007) is 6291 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) == Unused Reference: '1' is defined on line 289, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (ref. '5') (Obsoleted by RFC 8866) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio Video Transport WG Q. Xie 3 Internet-Draft J. Schumacher 4 Updates: RFC 2198 Motorola 5 (if approved) February 3, 2007 6 Intended status: Standards Track 7 Expires: August 7, 2007 9 Forward-shifted RTP Redundancy Payload Support 10 draft-xie-avt-forward-shifted-red-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 7, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines a simple enhancement to RFC 2198 to support RTP 44 sessions with forward-shifted redundant encodings, i.e., redundant 45 data is sent before the corresponding primary data. Forward-shifted 46 redundancy can be used to conceal losses of a large number of 47 consecutive media frames (e.g., consecutive loss of seconds or even 48 tens of seconds of media). 50 Table of Contents 52 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Sending Redundant Data Inband vs. Out-of-band . . . . . . 3 55 3. Allowing Forward-shifted Redundant Data . . . . . . . . . . . 4 56 4. Registration of Media Type "fwdred" . . . . . . . . . . . . . 5 57 5. Mapping MIME Parameters into SDP . . . . . . . . . . . . . . . 6 58 6. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . . . 7 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 62 Appendix A. Anti-shadow Loss Concealment Using 63 Forward-shifted Redundancy . . . . . . . . . . . . . 8 64 A.1. Sender Side Operations . . . . . . . . . . . . . . . . . . 8 65 A.2. Receiver Side Operations . . . . . . . . . . . . . . . . . 10 66 A.2.1. Normal Mode Operation . . . . . . . . . . . . . . . . 11 67 A.2.2. Anti-shadow Mode Operation . . . . . . . . . . . . . . 12 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 69 Intellectual Property and Copyright Statements . . . . . . . . . . 14 71 1. Conventions 73 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 74 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 75 they appear in this document, are to be interpreted as described in 76 RFC 2119 [2]. 78 2. Introduction 80 This document defines a simple enhancement to RFC 2198 [3] to support 81 RTP sessions with forward-shifted redundant encodings, i.e., 82 redundant data is sent before the corresponding primary data. 84 Forward-shifted redundancy can be used to conceal losses of a large 85 number of consecutive media frames (e.g., consecutive loss of seconds 86 of media). Such capability is highly desirable, especially in 87 wireless mobile communication environments where the radio signal to 88 a mobile wireless media receiver can be temporarily blocked by tall 89 buildings, mountains, tunnels, etc. In other words, the receiver 90 enters into a shadow of the radio coverage. No new data will be 91 received when the receiver is in a shadow. 93 In some extreme cases, the receiver may have to spend seconds or even 94 tens of seconds in a shadow. The traditional backward-shifted 95 redundant encoding scheme (i.e., redundant data is sent after the 96 primary data), as currently supported by RFC 2198 [3], is known to be 97 ineffective in dealing with such consecutive frame losses. 99 In contrast, the forward-shifted redundancy, when used in combination 100 with the anti-shadow loss management at the receiver (as described in 101 Appendix A), can effectively prevent service interruptions when a 102 mobile receiver runs into such a shadow. 104 2.1. Sending Redundant Data Inband vs. Out-of-band 106 Regardless of the direction of time shift (e.g., forward-shifting or 107 backward-shifting as in RFC 2198) or the encoding scheme (e.g., FEC, 108 or non-FEC), there is always the option of sending the redundant data 109 and the primary data either in the same RTP session (i.e., inband) or 110 in separate RTP sessions (i.e., out-of-band). There are pros and 111 cons for either approach, as outlined below. 113 Inband Approach: 115 o Pro: A single RTP session is faster to setup and easier to manage. 117 o Pro: A single RTP session presents a simpler problem for NAT/ 118 firewall traverse. 120 o Pro: Less overall overhead - one RTP/UDP/IP overhead. 122 o Con: Lack of flexibility - difficult for middle boxes such as 123 gateways to add/remove the redundant data. 125 o Con: Need more specification - special payload formats need to be 126 defined to carry the redundant data inband. 128 Out-of-band Approach: 130 o Pro: Flexibility - redundant data can be more easily added, 131 removed, or replaced by a middle box such as a gateway. 133 o Pro: Little or none specification - no new payload format is 134 needed. 136 o Con: Multiple RTP sessions may take longer to setup and more 137 complexity to manage. 139 o Con: Multiple RTP sessions NAT/firewall traverse are harder to 140 address. 142 o Con: Bigger overall overhead - more than one RTP/UDP/IP overhead. 144 It is noteworthy that the specification of inband payload formats 145 such as this and RFC 2198 does not preclude a deployment from using 146 the out-of-band approach. Rather, it gives the deployment the choose 147 to use whichever approach deemed most beneficiary under a given 148 circumstance. 150 3. Allowing Forward-shifted Redundant Data 152 In RFC 2198, the timestamp offset in the additional header 153 corresponding to a redundant block is defined as a 14 bits unsigned 154 offset of timestamp relative to timestamp given in the RTP header. 155 As stated in RFC 2198: 157 "The use of an unsigned offset implies that redundant data must be 158 sent after the primary data, and is hence a time to be subtracted 159 from the current timestamp to determine the timestamp of the data 160 for which this block is the redundancy." 162 This effectively prevents RFC 2198 from being used to support 163 forward-shifted redundant blocks. 165 In order to support the use of forward-shifted redundant blocks, the 166 media type "fwdred" which allows an optional MIME parameters, 167 "forwardshift", is introduced for indicating the capability and 168 willingness of using forward-shifted redundancy and the base value of 169 timestamp forward-shifting. The base value of "forwardshift" is an 170 integer equal or greater than '0'. 172 In an RTP session which uses forward-shifted redundant encodings, the 173 timestamp of a redundant block in a received RTP packet is determined 174 as follows: 176 timestamp of redundant block = timestamp in RTP header 177 - timestamp offset in additional header 178 + forward shift base value 180 4. Registration of Media Type "fwdred" 182 (The definition is based on media type "red" defined in RFC 2198 [3], 183 with the addition of the optional "forwardshift" parameter.) 185 Type name: audio 187 Subtype names: fwdred 189 Required parameters: none 191 Optional parameters: 193 forwardshift: An unsigned integer can be specified as value. 195 If this parameter is present with a value greater than '0', it 196 indicates that the sender of this parameter will use forward 197 shifting with a base value as specified when sending out 198 redundant data. 200 If this parameter is absent or present with a value of '0', it 201 indicates that the sender of this parameter will not use 202 forward shifting when sending its redundant data. I.e., the 203 sender will have the same behaviors as define in RFC 2198. 205 Encoding considerations: 206 This media type is framed binary data (see RFC 4288, Section 4.8) 207 and is only defined for transfer of RTP redundant data frames 208 specified in RFC 2198. 210 Security considerations: See Section 6 "Security Considerations" of 211 RFC 2198. 213 Interoperability considerations: None. 215 Published specification: 216 RTP redundant data frame format is specified in RFC 2198. 218 Applications that use this media type: 219 It is expected that real-time audio/video applications that want 220 protection against losses of a large number of consecutive frames 221 will be interested in using this type. 223 Additional information: none 225 Person & email address to contact for further information: 226 Qiaobing Xie 228 Intended usage: COMMON 230 Restrictions on usage: 231 This media type depends on RTP framing, and hence is only defined 232 for transfer via RTP (RFC 3550 [4]). Transfer within other 233 framing protocols is not defined at this time. 235 Author: 236 Qiaobing Xie 238 Change controller: 239 IETF Audio/Video Transport working group delegated from the IESG. 241 5. Mapping MIME Parameters into SDP 243 The information carried in the MIME media type specification has a 244 specific mapping to fields in the Session Description Protocol (SDP) 245 [5], which is commonly used to describe RTP sessions. When SDP is 246 used to specify sessions employing the forward-shifted redundant 247 format, the mapping is as follows: 249 o The MIME type ("audio") goes in SDP "m=" as the media name. 251 o The MIME subtype ("fwdred") goes in SDP "a=rtpmap" as the encoding 252 name. 254 o The optional parameter "forwardshift" goes in the SDP "a=fmtp" 255 attribute by copying it directly from the MIME media type string 256 as "forwardshift=value". 258 Example of usage of indicating forward-shifted (by 5.1 sec) 259 redundancy: 261 m=audio 12345 RTP/AVP 121 0 5 262 a=rtpmap:121 fwdred/8000/1 263 a=fmtp:121 0/5 forwardshift=40800 265 Example of usage of indicating sending redundancy without forward- 266 shifting (equivalent to RFC 2198): 268 m=audio 12345 RTP/AVP 121 0 5 269 a=rtpmap:121 fwdred/8000/1 270 a=fmtp:121 0/5 forwardshift=0 272 6. Usage in Offer/Answer 274 The optional "forwardshift" SDP parameter specified in this document 275 is declarative, and all reasonable values are expected to be 276 supported. 278 7. IANA Considerations 280 The registration of the new MIME subtype "fwdred", as described in 281 Section 4, is required. 283 8. Security Considerations 285 See Section 6 "Security Considerations" of RFC 2198 [3]. 287 9. Normative References 289 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 290 BCP 9, RFC 2026, October 1996. 292 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 293 Levels", BCP 14, RFC 2119, March 1997. 295 [3] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., 296 Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload 297 for Redundant Audio Data", RFC 2198, September 1997. 299 [4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 300 "RTP: A Transport Protocol for Real-Time Applications", 301 RFC 3550, July 2003. 303 [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 304 Description Protocol", RFC 4566, July 2006. 306 Appendix A. Anti-shadow Loss Concealment Using Forward-shifted 307 Redundancy 309 It is not unusual in a wireless mobile communication environment 310 where the radio signal to a mobile wireless media receiver can be 311 temporarily blocked by tall buildings, mountains, tunnels, etc. for a 312 period of time. In other words, the receiver enters into a shadow of 313 the radio coverage. When the receiver is in such a shadow no new 314 data will be received. In some extreme cases, the receiver may have 315 to spend seconds or even tens of seconds in such a shadow. 317 Without special design considerations to compensate the loss of data 318 due to shadowing, a mobile user may experience an unacceptable level 319 of service interruptions. And traditional redundant encoding schemes 320 (including RFC 2198 and most FEC schemes) are known to be ineffective 321 in dealing with such losses of consecutive frames. 323 However, the employment of forward-shifted redundancy, in combination 324 with the anti-shadow loss concealment at the receiver, as described 325 here, can effectively prevent service interruptions due to the effect 326 of shadowing. 328 A.1. Sender Side Operations 330 For anti-shadow loss management, the RTP sender simply adds a 331 forward-shifted redundant stream (called anti-shadow or AS stream) 332 while transmitting the primary media stream. The amount of forward- 333 shifting, which should remain constant for the duration of the 334 session, will determine the maximal length of shadows that can be 335 completely concealed at the receiver, as explained below. 337 Except for the fast that it is forward-shifted relative to the 338 primary stream (i.e., the redundant data is sent ahead of the 339 corresponding primary data), the design decision and trade-offs on 340 the quality, encoding, bandwidth overhead, etc. of the redundant 341 stream is not different from the traditional RTP payload redundant 342 scheme. 344 The following diagram illustrates a segment of the transmission 345 sequence of a forward-shifted redundant RTP session, in which the AS 346 stream is forward-shifted by 155 frames. If, for simplicity here, we 347 assume the value of timestamp is incremented by 1 between two 348 consecutive frames, this forward-shifted redundancy can then be 349 indicated with: 351 forwardshift=155 353 and the setting of timestamp offset to 0 in all the additional 354 headers. This can mean a 3.1 second of forward shifting if each 355 frame represents 20 ms of original media, 356 Primary stream AS stream 358 ... | | 359 v v 360 Pkt k+8 [ 111 ] [ 266 ] 361 | | 362 v v 363 Pkt k+7 [ 110 ] [ 265 ] 364 | | 365 v v 366 ^ Pkt k+6 [ 109 ] [ 264 ] 367 | | | 368 | v v 369 Pkt k+5 [ 108 ] [ 263 ] 370 T | | 371 I v v 372 M Pkt k+4 [ 107 ] [ 262 ] 373 E | | 374 v v 375 Pkt k+3 [ 106 ] [ 261 ] 376 | | 377 v v 378 Pkt k+2 [ 105 ] [ 260 ] 379 | | 380 v v 381 Pkt k+1 [ 104 ] [ 259 ] 382 | | 383 v v 384 Pkt k [ 103 ] [ 258 ] 385 | | 386 v v 388 Transmit first 390 Figure 1. An example of forward-shifted redundant RTP packet 391 transmission. 393 A.2. Receiver Side Operations 395 The anti-shadow receiver is illustrated in the following diagram. 397 +---------+ 398 normal mode sw1 | media | media 399 Primary stream ======================o___o==>| decoder |===> output 400 AS stream ---- +---------+ device 401 | AS mode o 402 | +---------+ | 403 | | anti- | | 404 ------->| shadow |---- 405 | buffer | 406 +---------+ 407 | 408 V 409 expired frames 410 discarded 412 Figure 2. Anti-shadow RTP receiver. 414 The anti-shadow receiver operates between two modes - "normal mode" 415 and "AS mode". When the receiver is not in a shadow (it can easily 416 tell that if it is still receiving new data), the receiver operates 417 in the normal mode. Otherwise, it operates in the AS mode. 419 A.2.1. Normal Mode Operation 421 In the normal mode, after receiving a new RTP packet that contains 422 the primary data and forward-shifted AS data, the receiver passes the 423 primary data directly to the appropriate media decoder for play-out 424 (a de-jittering buffer may be used before the play-out, but for 425 simplicity we assume none is used here), while the received AS data 426 is stored in an anti-shadow buffer. 428 Moreover, data stored in the anti-shadow buffer will be continuously 429 checked to determine whether it has expired. If a redundant data in 430 the anti-shadow buffer is found to have a timestamp older (i.e., 431 smaller) than that of the last primary frame passed to the media 432 decoder, it will be considered expired and be purged from the anti- 433 shadowing buffer. 435 The following example illustrates the operation of the anti-shadow 436 buffer in normal mode. We use the same assumption as in Figure 1, 437 and assume that the initial timestamp value is 103 when the session 438 starts. 440 Timestamp Timestamp 441 Time being of media in 442 (in ms) played out AS buffer Note 443 ------------------------------------------------------------------ 444 t < 0 -- (buffer empty) 445 ... 446 t=0 103 258 (hold 1 AS frame) 447 t=20 104 258-259 (hold 2 AS frames) 448 t=40 105 258-260 (hold 3 AS frames) 450 ... 451 t=3080 257 258-412 (full, hold 154 AS frames) 452 t=3100 258 259-413 (full, frame 258 purged) 453 t=3120 259 260-414 (full, frame 259 purged) 454 ... 456 t=6240 415 416-570 (always holds 3.08 sec 457 worth of redundant data) 458 ... 460 Figure 3. Example of anti-shadow buffer operation in normal mode. 462 At the beginning of the session (t=0), the anti-shadow buffer will be 463 empty. When the first primary frame is received, the play-out will 464 start immediately, and the first received AS frame is stored in the 465 anti-shadow buffer. And with the arriving of more forward-shifted 466 redundant frames, the anti-shadow buffer will gradually be filled up. 468 For the example shown in Figure 1, after 3.08 seconds (the amount of 469 the forward-shifting minus one frame) from the start of the session, 470 the anti-shadow buffer will be full, holding exactly 3.08 seconds 471 worth of redundant data, with the oldest frame corresponding to t=3.1 472 sec and youngest frame corresponding to t=6.18 sec. 474 And it is not difficult to see that in normal mode because of the 475 continuous purge of expired frames and the addition of new frames, 476 the anti-shadowing buffer will always be full holding the next 477 forward-shift amount of redundant frames. 479 A.2.2. Anti-shadow Mode Operation 481 When the receiver enters a shadow (or any other conditions that 482 prevent the receiver from getting new media data), the receiver 483 switches to the anti-shadow mode, in which it simply continues the 484 play-out from the forward-shifted redundant data stored in the anti- 485 shadow buffer. 487 For the example in Figure 3, if the receiver enters a shadow at 488 t=3120, it can continue the play-out by using the forward-shifted 489 redundant frames (ts=260-414) from the anti-shadow buffer. As far as 490 the receiver can move out of the shadow by t=6240, there will be no 491 service interruption. 493 When the shadow condition ends (meaning new data starts to arrive 494 again), the receiver immediately switches back to normal mode of 495 operation, playing out from newly arrived primary frames. And at the 496 same time, the arrival of new AS frames will start to re-fill the 497 anti-shadow buffer. 499 However, if the duration of the shadow is longer than the amount of 500 forward-shifting, the receiver will run out of media frames from its 501 anti-shadow buffer. At that point, service interruption will occur. 503 Anti-shadow loss concealment described above can be readily applied 504 to the streaming of pre-recorded media. Because of the need of 505 generating the forward-shifted anti-shadow redundant stream, to apply 506 anti-shadow loss concealment to the streaming of live media will 507 require the insertion of a delay equal to or greater than the amount 508 of forward-shifting at the source of media. 510 Authors' Addresses 512 Qiaobing Xie 513 Motorola, Inc. 514 1501 W. Shure Drive, 2-F9 515 Arlington Heights, IL 60004 516 US 518 Phone: +1-847-632-3028 519 Email: Qiaobing.Xie@Motorola.com 521 Joe Schumacher 522 Motorola, Inc. 523 1501 W. Shure Drive, 2-B11 524 Arlington Heights, IL 60004 525 US 527 Phone: +1-847-632-5978 528 Email: j.schumacher@motorola.com 530 Full Copyright Statement 532 Copyright (C) The IETF Trust (2007). 534 This document is subject to the rights, licenses and restrictions 535 contained in BCP 78, and except as set forth therein, the authors 536 retain all their rights. 538 This document and the information contained herein are provided on an 539 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 540 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 541 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 542 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 543 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 544 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 546 Intellectual Property 548 The IETF takes no position regarding the validity or scope of any 549 Intellectual Property Rights or other rights that might be claimed to 550 pertain to the implementation or use of the technology described in 551 this document or the extent to which any license under such rights 552 might or might not be available; nor does it represent that it has 553 made any independent effort to identify any such rights. Information 554 on the procedures with respect to rights in RFC documents can be 555 found in BCP 78 and BCP 79. 557 Copies of IPR disclosures made to the IETF Secretariat and any 558 assurances of licenses to be made available, or the result of an 559 attempt made to obtain a general license or permission for the use of 560 such proprietary rights by implementers or users of this 561 specification can be obtained from the IETF on-line IPR repository at 562 http://www.ietf.org/ipr. 564 The IETF invites any interested party to bring to its attention any 565 copyrights, patents or patent applications, or other proprietary 566 rights that may cover technology that may be required to implement 567 this standard. Please address the information to the IETF at 568 ietf-ipr@ietf.org. 570 Acknowledgment 572 Funding for the RFC Editor function is provided by the IETF 573 Administrative Support Activity (IASA).