idnits 2.17.1 draft-xie-avt-forward-shifted-red-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 533. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 399 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 (December 29, 2006) is 6327 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 266, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (ref. '5') (Obsoleted by RFC 8866) Summary: 4 errors (**), 0 flaws (~~), 6 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 (if approved) Motorola 5 Expires: July 2, 2007 December 29, 2006 7 Forward-shifted RTP Redundancy Payload Support 8 draft-xie-avt-forward-shifted-red-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 2, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document defines a simple enhancement to RFC 2198 to support RTP 42 sessions with forward-shifted redundant encodings, i.e., redundant 43 data is sent before the corresponding primary data. Forward-shifted 44 redundancy can be used to conceal losses of a large number of 45 consecutive media frames (e.g., consecutive loss of seconds or even 46 tens of seconds of media). 48 Table of Contents 50 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Allowing Forward-shifted Redundant Data . . . . . . . . . . . 3 53 4. Updated Registration of Media Type "red" . . . . . . . . . . . 4 54 5. Mapping MIME Parameters into SDP . . . . . . . . . . . . . . . 5 55 6. Usage in Offer/Answer . . . . . . . . . . . . . . . . . . . . 6 56 7. Backward Compatibility with RFC 2198 . . . . . . . . . . . . . 6 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 10. Normative References . . . . . . . . . . . . . . . . . . . . 7 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 61 A. Anti-shadow Loss Concealment Using Forward-shifted 62 Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 A.1 Sender Side Operations . . . . . . . . . . . . . . . . . . 8 64 A.2 Receiver Side Operations . . . . . . . . . . . . . . . . . 10 65 A.2.1 Normal Mode Operation . . . . . . . . . . . . . . . . 10 66 A.2.2 Anti-shadow Mode Operation . . . . . . . . . . . . . . 11 67 Intellectual Property and Copyright Statements . . . . . . . . 13 69 1. Conventions 71 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 72 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 73 they appear in this document, are to be interpreted as described in 74 RFC 2119 [2]. 76 2. Introduction 78 This document defines a simple enhancement to RFC 2198 [3] to support 79 RTP sessions with forward-shifted redundant encodings, i.e., 80 redundant data is sent before the corresponding primary data. 82 Forward-shifted redundancy can be used to conceal losses of a large 83 number of consecutive media frames (e.g., consecutive loss of seconds 84 of media). Such capability is highly desirable, especially in 85 wireless mobile communication environments where the radio signal to 86 a mobile wireless media receiver can be temporarily blocked by tall 87 buildings, mountains, tunnels, etc. In other words, the receiver 88 enters into a shadow of the radio coverage. No new data will be 89 received when the receiver is in a shadow. 91 In some extreme cases, the receiver may have to spend seconds or even 92 tens of seconds in a shadow. The traditional backward-shifted 93 redundant encoding scheme (i.e., redundant data must be sent after 94 the primary data), as currently supported by RFC 2198 [3], is known 95 to be ineffective in dealing with such consecutive frame losses. 97 However, forward-shifted redundancy, in combination with the anti- 98 shadow loss management at the receiver (as described in Appendix A) 99 can effectively prevent service interruptions when a mobile receiver 100 runs into such a shadow. 102 3. Allowing Forward-shifted Redundant Data 104 In RFC 2198, the timestamp offset in the additional header 105 corresponding to a redundant block is defined as a 14 bits unsigned 106 offset of timestamp relative to timestamp given in the RTP header. 107 As stated in RFC 2198: 109 "The use of an unsigned offset implies that redundant data must be 110 sent after the primary data, and is hence a time to be subtracted 111 from the current timestamp to determine the timestamp of the data 112 for which this block is the redundancy." 114 This effectively prevents RFC 2198 from being used to support 115 forward-shifted redundant blocks. 117 In order to support the use of forward-shifted redundant blocks, an 118 optional MIME parameters, "forwardshift", is introduced for 119 indicating the capability and willingness of using forward-shifted 120 redundancy and the base value of timestamp forward-shifting. The 121 base value of "forwardshift" is an integer equal or greater than '0'. 122 In an RTP session which uses forward-shifted redundant encodings, the 123 timestamp of a redundant block in a received RTP packet is determined 124 as follows: 126 timestamp of redundant block = timestamp in RTP header 127 - timestamp offset in additional header 128 + forward shift base value 130 4. Updated Registration of Media Type "red" 132 (The definition is based on RFC 2198 [3], added with the optional 133 "forwardshift" parameter, and updated with the new template specified 134 in [6].) 136 Type name: audio 138 Subtype names: red 140 Required parameters: none 142 Optional parameters: 144 forwardshift: An unsigned integer can be specified as value. 146 If this parameter is present with a value of '0', it indicates 147 that the sender of this parameter is capable of and willing to 148 receive forward-shifted redundant data, but there will be no 149 forward shifting when it sends out its own redundant data. 151 If this parameter is present with a value greater than '0', it 152 indicates that the sender of this parameter is capable of and 153 willing to receive forward-shifted redundant data, and will use 154 forward shifting with a base value as specified when sending 155 out redundant data if forward-shifted redundancy is allowed for 156 the session. 158 If this parameter is not present, it MUST be assumed that 159 forward-shifted redundancy is not supported and MUST NOT be 160 used in the session. In other words, forward-shifted 161 redundancy can only be used in a session if both ends indicate 162 the capability. 164 Encoding considerations: 165 This media type is framed binary data (see RFC 4288, Section 4.8) 166 and is only defined for transfer of RTP redundant data frames 167 specified in RFC 2198. 169 Security considerations: See Section 6 "Security Considerations" of 170 RFC 2198. 172 Interoperability considerations: 173 Existing RFC 2198 implementations will not send "forwardshift" 174 parameter in their SDP and will ignore "forwardshift" parameter 175 they receive. As a result, forward-shifted redundancy will not be 176 used in the session and thus ensures the interoperability between 177 a legacy RFC 2198 endpoint and a forward-shifted redundancy 178 capable endpoint. 180 Published specification: 181 RTP redundant data frame format is specified in RFC 2198. 183 Applications that use this media type: 184 It is expected that real-time audio/video applications that want 185 protection against losses of a large number of consecutive frames 186 will be interested in using this type. 188 Additional information: none 190 Person & email address to contact for further information: 191 Qiaobing Xie 193 Intended usage: COMMON 195 Restrictions on usage: 196 This media type depends on RTP framing, and hence is only defined 197 for transfer via RTP (RFC 3550 [4]). Transfer within other 198 framing protocols is not defined at this time. 200 Author: 201 Qiaobing Xie 203 Change controller: 204 IETF Audio/Video Transport working group delegated from the IESG. 206 5. Mapping MIME Parameters into SDP 208 The information carried in the MIME media type specification has a 209 specific mapping to fields in the Session Description Protocol (SDP) 210 [5], which is commonly used to describe RTP sessions. When SDP is 211 used to specify sessions employing the forward-shifted redundant 212 format, the mapping is as follows: 214 o The MIME type ("audio") goes in SDP "m=" as the media name. 216 o The MIME subtype ("red") goes in SDP "a=rtpmap" as the encoding 217 name. 219 o The optional parameter "forwardshift" goes in the SDP "a=fmtp" 220 attribute by copying it directly from the MIME media type string 221 as "forwardshift=value". 223 Example of usage of indicating forward-shifted (by 5.1 sec) 224 redundancy: 226 m=audio 12345 RTP/AVP 121 0 5 227 a=rtpmap:121 red/8000/1 228 a=fmtp:121 0/5 forwardshift=40800 230 Example of usage of indicating only willingness for receiving 231 forward-shifted redundancy (but won't send forward-shifted 232 redundancy): 234 m=audio 12345 RTP/AVP 121 0 5 235 a=rtpmap:121 red/8000/1 236 a=fmtp:121 0/5 forwardshift=0 238 6. Usage in Offer/Answer 240 The optional "forwardshift" SDP parameter specified in this document 241 is declarative, and all reasonable values are expected to be 242 supported. Furthermore, if "forwardshift" parameter is absent from 243 either Offer or Answer, forward-shifted redundancy MUST NOT be used 244 in the session. 246 7. Backward Compatibility with RFC 2198 248 Existing RFC 2198 implementations will not send "forwardshift" 249 parameter in their SDP and will ignore "forwardshift" parameter they 250 receive. As a result, forward-shifted redundancy will not be used in 251 the session and thus ensures the interoperability between a legacy 252 RFC 2198 endpoint and a forward-shifted redundancy capable endpoint. 254 8. IANA Considerations 256 The MIME subtype registration, "red" originally defined in RFC 2198 257 [3], is updated with the additional optional parameter "forwardshift" 258 (see Section 4). 260 9. Security Considerations 262 See Section 6 "Security Considerations" of RFC 2198 [3]. 264 10. Normative References 266 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 267 BCP 9, RFC 2026, October 1996. 269 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 270 Levels", BCP 14, RFC 2119, March 1997. 272 [3] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., 273 Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload 274 for Redundant Audio Data", RFC 2198, September 1997. 276 [4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 277 "RTP: A Transport Protocol for Real-Time Applications", 278 RFC 3550, July 2003. 280 [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 281 Description Protocol", RFC 4566, July 2006. 283 [6] Casner, S., "Media Type Registration of RTP Payload Formats", 284 draft-ietf-avt-rfc3555bis-05.txt (work in progress), 285 October 2006. 287 Authors' Addresses 289 Qiaobing Xie 290 Motorola, Inc. 291 1501 W. Shure Drive, 2-F9 292 Arlington Heights, IL 60004 293 US 295 Phone: +1-847-632-3028 296 Email: Qiaobing.Xie@Motorola.com 297 Joe Schumacher 298 Motorola, Inc. 299 1501 W. Shure Drive, 2-B11 300 Arlington Heights, IL 60004 301 US 303 Phone: +1-847-632-5978 304 Email: j.schumacher@motorola.com 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, 357 Primary stream AS stream 359 ... | | 360 v v 361 Pkt k+8 [ 111 ] [ 266 ] 362 | | 363 v v 364 Pkt k+7 [ 110 ] [ 265 ] 365 | | 366 v v 367 ^ Pkt k+6 [ 109 ] [ 264 ] 368 | | | 369 | v v 370 Pkt k+5 [ 108 ] [ 263 ] 371 T | | 372 I v v 373 M Pkt k+4 [ 107 ] [ 262 ] 374 E | | 375 v v 376 Pkt k+3 [ 106 ] [ 261 ] 377 | | 378 v v 379 Pkt k+2 [ 105 ] [ 260 ] 380 | | 381 v v 382 Pkt k+1 [ 104 ] [ 259 ] 383 | | 384 v v 385 Pkt k [ 103 ] [ 258 ] 386 | | 387 v v 389 Transmit first 391 Figure 1. An example of forward-shifted redundant RTP packet 392 transmission. 394 A.2 Receiver Side Operations 396 The anti-shadow receiver is illustrated in the following diagram. 398 +---------+ 399 normal mode sw1 | media | media 400 Primary stream ======================o___o==>| decoder |===> output 401 AS stream ---- +---------+ device 402 | AS mode o 403 | +---------+ | 404 | | anti- | | 405 ------->| shadow |---- 406 | buffer | 407 +---------+ 408 | 409 V 410 expired frames 411 discarded 413 Figure 2. Anti-shadow RTP receiver. 415 The anti-shadow receiver operates between two modes - "normal mode" 416 and "AS mode". When the receiver is not in a shadow (it can easily 417 tell that if it is still receiving new data), the receiver operates 418 in the normal mode. Otherwise, it operates in the AS mode. 420 A.2.1 Normal Mode Operation 422 In the normal mode, after receiving a new RTP packet that contains 423 the primary data and forward-shifted AS data, the receiver passes the 424 primary data directly to the appropriate media decoder for play-out 425 (a de-jittering buffer may be used before the play-out, but for 426 simplicity we assume none is used here), while the received AS data 427 is stored in an anti-shadow buffer. 429 Moreover, data stored in the anti-shadow buffer will be continuously 430 checked to determine whether it has expired. If a redundant data in 431 the anti-shadow buffer is found to have a timestamp older (i.e., 432 smaller) than that of the last primary frame passed to the media 433 decoder, it will be considered expired and be purged from the anti- 434 shadowing buffer. 436 The following example illustrates the operation of the anti-shadow 437 buffer in normal mode. We use the same assumption as in Figure 1, 438 and assume that the initial timestamp value is 103 when the session 439 starts. 441 Timestamp Timestamp 442 Time being of media in 443 (in ms) played out AS buffer Note 444 ------------------------------------------------------------------ 445 t < 0 -- (buffer empty) 446 ... 447 t=0 103 258 (hold 1 AS frame) 448 t=20 104 258-259 (hold 2 AS frames) 449 t=40 105 258-260 (hold 3 AS frames) 451 ... 452 t=3080 257 258-412 (full, hold 154 AS frames) 453 t=3100 258 259-413 (full, frame 258 purged) 454 t=3120 259 260-414 (full, frame 259 purged) 455 ... 457 t=6240 415 416-570 (always holds 3.08 sec 458 worth of redundant data) 459 ... 461 Figure 3. Example of anti-shadow buffer operation in normal mode. 463 At the beginning of the session (t=0), the anti-shadow buffer will be 464 empty. When the first primary frame is received, the play-out will 465 start immediately, and the first received AS frame is stored in the 466 anti-shadow buffer. And with the arriving of more forward-shifted 467 redundant frames, the anti-shadow buffer will gradually be filled up. 469 For the example shown in Figure 1, after 3.08 seconds (the amount of 470 the forward-shifting minus one frame) from the start of the session, 471 the anti-shadow buffer will be full, holding exactly 3.08 seconds 472 worth of redundant data, with the oldest frame corresponding to t=3.1 473 sec and youngest frame corresponding to t=6.18 sec. 475 And it is not difficult to see that in normal mode because of the 476 continuous purge of expired frames and the addition of new frames, 477 the anti-shadowing buffer will always be full holding the next 478 forward-shift amount of redundant frames. 480 A.2.2 Anti-shadow Mode Operation 482 When the receiver enters a shadow (or any other conditions that 483 prevent the receiver from getting new media data), the receiver 484 switches to the anti-shadow mode, in which it simply continues the 485 play-out from the forward-shifted redundant data stored in the anti- 486 shadow buffer. 488 For the example in Figure 3, if the receiver enters a shadow at 489 t=3120, it can continue the play-out by using the forward-shifted 490 redundant frames (ts=260-414) from the anti-shadow buffer. As far as 491 the receiver can move out of the shadow by t=6240, there will be no 492 service interruption. 494 When the shadow condition ends (meaning new data starts to arrive 495 again), the receiver immediately switches back to normal mode of 496 operation, playing out from newly arrived primary frames. And at the 497 same time, the arrival of new AS frames will start to re-fill the 498 anti-shadow buffer. 500 However, if the duration of the shadow is longer than the amount of 501 forward-shifting, the receiver will run out of media frames from its 502 anti-shadow buffer. At that point, service interruption will occur. 504 Anti-shadow loss concealment described above can be readily applied 505 to the streaming of pre-recorded media. Because of the need of 506 generating the forward-shifted anti-shadow redundant stream, to apply 507 anti-shadow loss concealment to the streaming of live media will 508 require the insertion of a delay equal to or greater than the amount 509 of forward-shifting at the source of media. 511 Intellectual Property Statement 513 The IETF takes no position regarding the validity or scope of any 514 Intellectual Property Rights or other rights that might be claimed to 515 pertain to the implementation or use of the technology described in 516 this document or the extent to which any license under such rights 517 might or might not be available; nor does it represent that it has 518 made any independent effort to identify any such rights. Information 519 on the procedures with respect to rights in RFC documents can be 520 found in BCP 78 and BCP 79. 522 Copies of IPR disclosures made to the IETF Secretariat and any 523 assurances of licenses to be made available, or the result of an 524 attempt made to obtain a general license or permission for the use of 525 such proprietary rights by implementers or users of this 526 specification can be obtained from the IETF on-line IPR repository at 527 http://www.ietf.org/ipr. 529 The IETF invites any interested party to bring to its attention any 530 copyrights, patents or patent applications, or other proprietary 531 rights that may cover technology that may be required to implement 532 this standard. Please address the information to the IETF at 533 ietf-ipr@ietf.org. 535 Disclaimer of Validity 537 This document and the information contained herein are provided on an 538 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 539 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 540 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 541 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 542 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 543 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 545 Copyright Statement 547 Copyright (C) The Internet Society (2006). This document is subject 548 to the rights, licenses and restrictions contained in BCP 78, and 549 except as set forth therein, the authors retain all their rights. 551 Acknowledgment 553 Funding for the RFC Editor function is currently provided by the 554 Internet Society.