From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6354.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc6354.txt (limited to 'doc/rfc/rfc6354.txt') diff --git a/doc/rfc/rfc6354.txt b/doc/rfc/rfc6354.txt new file mode 100644 index 0000000..2d13bff --- /dev/null +++ b/doc/rfc/rfc6354.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) Q. Xie +Request for Comments: 6354 August 2011 +Updates: 2198, 4102 +Category: Standards Track +ISSN: 2070-1721 + + + Forward-Shifted RTP Redundancy Payload Support + +Abstract + + This document defines a simple enhancement to support RTP sessions + with forward-shifted redundant encodings, i.e., redundant data sent + before the corresponding primary data. Forward-shifted redundancy + can be used to conceal losses of a large number of consecutive media + frames (e.g., consecutive loss of seconds or even tens of seconds of + media). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6354. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Xie Standards Track [Page 1] + +RFC 6354 Forward-Shifted RTP Redundancy August 2011 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Sending Redundant Data Inband vs. Out-of-Band ..............3 + 2. Conventions .....................................................4 + 3. Allowing Forward-Shifted Redundant Data .........................4 + 4. Registration of Media Type "fwdred" .............................5 + 5. Mapping Media Type Parameters into SDP ..........................7 + 6. Usage in Offer/Answer ...........................................7 + 7. IANA Considerations .............................................7 + 8. Security Considerations .........................................8 + 9. Normative References ............................................8 + Appendix A. Anti-Shadow Loss Concealment Using + Forward-Shifted Redundancy .............................9 + A.1. Sender-Side Operations .....................................9 + A.2. Receiver-Side Operations ..................................11 + A.2.1. Normal-Mode Operation ................................11 + A.2.2. Anti-Shadow-Mode Operation ...........................12 + +1. Introduction + + This document defines a simple enhancement to RFC 2198 [RFC2198] to + support RTP sessions with forward-shifted redundant encodings, i.e., + redundant data sent before the corresponding primary data. + + Forward-shifted redundancy can be used to conceal losses of a large + number of consecutive media frames (e.g., consecutive loss of seconds + of media). Such capability is highly desirable, especially in + wireless mobile communication environments where the radio signal to + a mobile wireless media receiver can be temporarily blocked by tall + buildings, mountains, tunnels, etc. In other words, the receiver + enters into a shadow of the radio coverage. No new data will be + received when the receiver is in a shadow. + + + + + + +Xie Standards Track [Page 2] + +RFC 6354 Forward-Shifted RTP Redundancy August 2011 + + + In some extreme cases, the receiver may have to spend seconds or even + tens of seconds in a shadow. The traditional backward-shifted + redundant encoding scheme (i.e., redundant data is sent after the + primary data), as currently supported by RFC 2198 [RFC2198], does not + address such consecutive frame losses. + + In contrast, the forward-shifted redundancy scheme allows one to + apply effective anti-shadow loss management at the receiver (as + illustrated in Appendix A), thus preventing service interruptions + when a mobile receiver runs into such a shadow. + + Anti-shadow loss concealment as described in this document can be + readily applied to the streaming of pre-recorded media. Because of + the need of generating the forward-shifted anti-shadow redundant + stream, to apply anti-shadow loss concealment to the streaming of + live media will require the insertion of a delay equal to or greater + than the amount of forward-shifting at the source of media. + +1.1. Sending Redundant Data Inband vs. Out-of-Band + + Regardless of the direction of time shift (e.g., forward-shifting, or + backward-shifting as in RFC 2198) or the encoding scheme (e.g., + Forward Error Correction (FEC), or non-FEC), there is always the + option of sending the redundant data and the primary data either in + the same RTP session (i.e., inband) or in separate RTP sessions + (i.e., out-of-band). There are pros and cons for either approach, as + outlined below. + + Inband Approach: + + o Pro: A single RTP session is faster to set up and easier to + manage. + + o Pro: A single RTP session presents a simpler problem for NAT/ + firewall traversal. + + o Pro: Less overall overhead -- one source of RTP/UDP/IP overhead. + + o Con: Lack of flexibility -- difficult for middle boxes such as + gateways to add/remove the redundant data. + + o Con: Need more specification -- special payload formats need to be + defined to carry the redundant data inband. + + + + + + + + +Xie Standards Track [Page 3] + +RFC 6354 Forward-Shifted RTP Redundancy August 2011 + + + Out-of-Band Approach: + + o Pro: Flexibility -- redundant data can be more easily added, + removed, or replaced by a middle box such as a gateway. + + o Pro: Little or no specification -- no new payload format is + needed. + + o Con: Multiple RTP sessions may take longer to set up and may be + more complex to manage. + + o Con: Multiple RTP sessions for NAT/firewall traversal are harder + to address. + + o Con: Bigger overall overhead -- more than one source of RTP/UDP/IP + overhead. + + It is noteworthy that the specification of inband payload formats, as + described in this document and in RFC 2198, does not preclude a + deployment from using the out-of-band approach. Rather, it gives the + deployment the choice to use whichever approach is deemed most + beneficial under a given circumstance. + +2. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +3. Allowing Forward-Shifted Redundant Data + + In RFC 2198, the timestamp offset in the additional header + corresponding to a redundant block is defined as a 14-bit unsigned + offset of the timestamp relative to the timestamp given in the RTP + header. As stated in RFC 2198: + + The use of an unsigned offset implies that redundant data must be + sent after the primary data, and is hence a time to be subtracted + from the current timestamp to determine the timestamp of the data + for which this block is the redundancy. + + This effectively prevents RFC 2198 from being used to support + forward-shifted redundant blocks. + + + + + + + + +Xie Standards Track [Page 4] + +RFC 6354 Forward-Shifted RTP Redundancy August 2011 + + + In order to support the use of forward-shifted redundant blocks, the + media type "fwdred", which allows a parameter called "forwardshift", + is introduced to indicate the capability of and willingness to use + forward-shifted redundancy and the base value of timestamp forward- + shifting. The base value of "forwardshift" is an integer equal to or + greater than '0' in RTP timestamp units. + + In an RTP session that uses forward-shifted redundant encodings, the + timestamp of a redundant block in a received RTP packet is determined + as follows: + + timestamp of redundant block = timestamp in RTP header + - timestamp offset in additional header + + forward-shift base value + + Note that generally, in a forward-shifted session, the timestamp + offset in the additional header is set to '0'. + + The sender MUST NOT change the contents of a packet that appears in a + forward-shifted stream when it is time to send it in the main stream. + +4. Registration of Media Type "fwdred" + + The definition is based on media type "red" defined in RFC 2198 + [RFC2198] and RFC 4102 [RFC4102], with the addition of the + "forwardshift" parameter. + + Type names: audio, text + + Subtype names: fwdred + + Required parameters: + + rate: as defined in [RFC4102]. + + pt: as defined in [RFC4102]. + + forwardshift: An unsigned integer can be specified as the value. + + If this parameter has a value greater than '0', it indicates + that the sender of this parameter will use forward-shifting + with a base value as specified when sending out redundant data. + This value is in RTP timestamp units. + + If this parameter has a value of '0', it indicates that the + sender of this parameter will not use forward-shifting when + sending its redundant data; i.e., the sender will have the same + behaviors as defined in RFC 2198. + + + +Xie Standards Track [Page 5] + +RFC 6354 Forward-Shifted RTP Redundancy August 2011 + + + Optional parameters: + + ptime: as defined in [RFC4102] [RFC4566]. + + maxptime: as defined in [RFC4102] [RFC4867]. + + Encoding considerations: + + This media type is framed binary data (see RFC 4288, Section 4.8) + and is only defined for transfer of RTP redundant data frames + specified in RFC 2198. + + Security considerations: See Section 6 of RFC 2198. + + Interoperability considerations: none. + + Published specification: + + RTP redundant data frame format is specified in RFC 2198. + + Applications that use this media type: + + It is expected that real-time audio/video, text streaming, and + conferencing tools/applications that want protection against + losses of a large number of consecutive frames will be interested + in using this type. + + Additional information: none. + + Person & email address to contact for further information: + + Qiaobing Xie + + Intended usage: COMMON + + Restrictions on usage: + + This media type depends on RTP framing, and hence is only defined + for transfer via RTP (RFC 3550 [RFC3550]). Transfer within other + framing protocols is not defined at this time. + + Author: + + Qiaobing Xie + + Change controller: + + IETF Audio/Video Transport working group delegated from the IESG. + + + +Xie Standards Track [Page 6] + +RFC 6354 Forward-Shifted RTP Redundancy August 2011 + + +5. Mapping Media Type Parameters into SDP + + The information carried in the media type specification has a + specific mapping to fields in the Session Description Protocol (SDP) + [RFC4566], which is commonly used to describe RTP sessions. When SDP + is used to specify sessions employing the forward-shifted redundant + format, the mapping is as follows: + + o The media type ("audio") goes in SDP "m=" as the media name. + + o The media subtype ("fwdred") goes in SDP "a=rtpmap" as the + encoding name. + + o The required parameter "forwardshift" goes in the SDP "a=fmtp" + attribute by copying it directly from the media type string as + "forwardshift=value". + + The following is an example of usage that indicates forward-shifted + (by 5.1 sec) redundancy: + + m=audio 12345 RTP/AVP 121 0 5 + a=rtpmap:121 fwdred/8000/1 + a=fmtp:121 0/5 forwardshift=40800 + + The following is an example of usage that indicates sending + redundancy without forward-shifting (equivalent to RFC 2198): + + m=audio 12345 RTP/AVP 121 0 5 + a=rtpmap:121 fwdred/8000/1 + a=fmtp:121 0/5 forwardshift=0 + +6. Usage in Offer/Answer + + The "forwardshift" SDP parameter specified in this document is + declarative, and all reasonable values are expected to be supported. + +7. IANA Considerations + + IANA made the assignments described below per this document. + + o IANA added the following to the "Audio Media Types" registry: + + fwdred [RFC6354] + + o IANA added the following to the "Text Media Types" registry: + + fwdred [RFC6354] + + + + +Xie Standards Track [Page 7] + +RFC 6354 Forward-Shifted RTP Redundancy August 2011 + + +8. Security Considerations + + Security considerations discussed in Section 6 of [RFC2198], + Section 4 of [RFC4856], and Sections 9 and 14 of [RFC3550] apply to + this specification. In addition, to prevent denial-of-service + attacks, a receiver SHOULD be prepared to ignore a 'forwardshift' + parameter declaration if it considers the offset value in the + declaration excessive. In such a case, the receiver SHOULD also + ignore the redundant stream in the resultant RTP session. + +9. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., + Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- + Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, + September 1997. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + [RFC4102] Jones, P., "Registration of the text/red MIME Sub-Type", + RFC 4102, June 2005. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [RFC4856] Casner, S., "Media Type Registration of Payload Formats in + the RTP Profile for Audio and Video Conferences", + RFC 4856, February 2007. + + [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, + "RTP Payload Format and File Storage Format for the + Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband + (AMR-WB) Audio Codecs", RFC 4867, April 2007. + + + + + + + + + + + + + +Xie Standards Track [Page 8] + +RFC 6354 Forward-Shifted RTP Redundancy August 2011 + + +Appendix A. Anti-Shadow Loss Concealment Using Forward-Shifted + Redundancy + + (This Appendix is included for Informational purposes.) + + It is not unusual in a wireless mobile communication environment that + the radio signal to a mobile wireless media receiver can be + temporarily blocked by tall buildings, mountains, tunnels, etc. for a + period of time. In other words, the receiver enters into a shadow of + the radio coverage. When the receiver is in such a shadow, no new + data will be received. In some extreme cases, the receiver may have + to spend seconds or even tens of seconds in such a shadow. + + Without special design considerations to compensate for the loss of + data due to shadowing, a mobile user may experience an unacceptable + level of service interruptions. Traditional redundant encoding + schemes (including RFC 2198 and most FEC schemes) are known to be + ineffective in dealing with such losses of consecutive frames. + + However, the employment of forward-shifted redundancy, in combination + with the anti-shadow loss concealment at the receiver, as described + here, can effectively prevent service interruptions due to the effect + of shadowing. + +A.1. Sender-Side Operations + + For anti-shadow loss management, the RTP sender simply adds a + forward-shifted redundant stream (called anti-shadow or AS stream) + while transmitting the primary media stream. The amount of forward- + shifting, which should remain constant for the duration of the + session, will determine the maximal length of shadows that can be + completely concealed at the receiver, as explained below. + + Except for the fact that the redundant stream is forward-shifted + relative to the primary stream (i.e., the redundant data is sent + ahead of the corresponding primary data), the design decision and + trade-offs on the quality, encoding, bandwidth overhead, etc. of the + redundant stream are not different from the traditional RTP payload + redundant scheme. + + The following diagram illustrates a segment of the transmission + sequence of a forward-shifted redundant RTP session, in which the AS + stream is forward-shifted by 155 frames. If, for simplicity here, we + assume that the value of the timestamp is incremented by 1 between + two consecutive frames, this forward-shifted redundancy can then be + indicated with: + + forwardshift=155 + + + +Xie Standards Track [Page 9] + +RFC 6354 Forward-Shifted RTP Redundancy August 2011 + + + and the setting of the timestamp offset to 0 in all the additional + headers. This can mean 3.1 seconds of forward-shifting if each frame + represents 20 ms of original media. + + Primary stream AS stream + + ... | | + v v + Pkt k+8 [ 111 ] [ 266 ] + | | + v v + Pkt k+7 [ 110 ] [ 265 ] + | | + v v + ^ Pkt k+6 [ 109 ] [ 264 ] + | | | + | v v + Pkt k+5 [ 108 ] [ 263 ] + T | | + I v v + M Pkt k+4 [ 107 ] [ 262 ] + E | | + v v + Pkt k+3 [ 106 ] [ 261 ] + | | + v v + Pkt k+2 [ 105 ] [ 260 ] + | | + v v + Pkt k+1 [ 104 ] [ 259 ] + | | + v v + Pkt k [ 103 ] [ 258 ] + | | + v v + + (Transmitted first) + + Figure 1: An Example of Forward-Shifted Redundant RTP Packet + Transmission + + + + + + + + + + + +Xie Standards Track [Page 10] + +RFC 6354 Forward-Shifted RTP Redundancy August 2011 + + +A.2. Receiver-Side Operations + + The anti-shadow receiver is illustrated in the following diagram. + + +---------+ + normal mode sw1 | media | media + Primary stream ======================o___o==>| decoder |===> output + AS stream ---- +---------+ device + | AS mode o + | +---------+ | + | | anti- | | + ------->| shadow |---- + | buffer | + +---------+ + | + V + expired frames + discarded + + Figure 2: Anti-Shadow RTP Receiver + + The anti-shadow receiver operates between two modes -- "normal mode" + and "AS mode". When the receiver is not in a shadow (i.e., when it + still receives new data), it operates in the normal mode. Otherwise, + it operates in the AS mode. + +A.2.1. Normal-Mode Operation + + In the normal mode, after receiving a new RTP packet that contains + the primary data and forward-shifted AS data, the receiver passes the + primary data directly to the appropriate media decoder for play-out + (a de-jittering buffer may be used before the play-out, but for + simplicity we assume that none is used here), while the received AS + data is stored in an anti-shadow buffer. + + Moreover, data stored in the anti-shadow buffer will be continuously + checked to determine whether it has expired. If any redundant data + in the anti-shadow buffer is found to have a timestamp older (i.e., + smaller) than that of the last primary frame passed to the media + decoder, it will be considered expired and be purged from the + anti-shadow buffer. + + The following example illustrates the operation of the anti-shadow + buffer in normal mode. We use the same assumption as in Figure 1, + and assume that the initial timestamp value is 103 when the session + starts. + + + + + +Xie Standards Track [Page 11] + +RFC 6354 Forward-Shifted RTP Redundancy August 2011 + + + Timestamp Timestamp + Time being of media in + (in ms) played out AS buffer Note + ------------------------------------------------------------------ + t < 0 -- (buffer empty) + ... + t=0 103 258 (hold 1 AS frame) + t=20 104 258-259 (hold 2 AS frames) + t=40 105 258-260 (hold 3 AS frames) + + ... + t=3080 257 258-412 (full, hold 155 AS frames) + t=3100 258 259-413 (full, frame 258 purged) + t=3120 259 260-414 (full, frame 259 purged) + ... + + t=6240 415 416-570 (always holds 3.1 sec + worth of redundant data) + ... + + Figure 3: Example of Anti-Shadow Buffer Operation in Normal Mode + + Before the beginning of the session (t<0), the anti-shadow buffer + will be empty. When the first primary frame is received, the play- + out will start immediately, and the first received AS frame is stored + in the anti-shadow buffer. With the arrival of more forward-shifted + redundant frames, the anti-shadow buffer will gradually be filled up. + + For the example shown in Figure 3, after 3.08 seconds (the amount of + the forward-shifting minus one frame) from the start of the session, + the anti-shadow buffer will be full, holding exactly 3.1 seconds + worth of redundant data, with the oldest frame corresponding to + t=3.1 sec and the youngest frame corresponding to t=6.18 sec. + + It is not difficult to see that in normal mode, because of the + continuous purge of expired frames and the addition of new frames, + the anti-shadow buffer will always be full, holding the next + 'forwardshift' amount of redundant frames. + +A.2.2. Anti-Shadow-Mode Operation + + When the receiver enters a shadow (or any other conditions that + prevent the receiver from getting new media data), the receiver + switches to the anti-shadow mode, in which it simply continues the + play-out from the forward-shifted redundant data stored in the + anti-shadow buffer. + + + + + +Xie Standards Track [Page 12] + +RFC 6354 Forward-Shifted RTP Redundancy August 2011 + + + For the example in Figure 3, if the receiver enters a shadow at + t=3120, it can continue the play-out by using the forward-shifted + redundant frames (ts=260-414) from the anti-shadow buffer. As long + as the receiver can move out of the shadow by t=6240, there will be + no service interruption. + + When the shadow condition ends (meaning new data starts to arrive + again), the receiver immediately switches back to the normal mode of + operation, playing out from newly arrived primary frames. At the + same time, the arrival of new AS frames will start to re-fill the + anti-shadow buffer. + + However, if the duration of the shadow is longer than the amount of + forward-shifting, the receiver will run out of media frames from its + anti-shadow buffer. At that point, service interruption will occur. + +Author's Address + + Qiaobing Xie + 15901 Wetherburn Rd. + Chesterfield, MO 63017 + US + + Phone: +1-847-893-0222 + EMail: Qiaobing.Xie@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + +Xie Standards Track [Page 13] + -- cgit v1.2.3