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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/