draft-ietf-avt-forward-shifted-red-06.txt   draft-ietf-avt-forward-shifted-red-07.txt 
Audio Video Transport WG Q. Xie AVTCORE Q. Xie
Internet-Draft TRG Internet-Draft TRG
Updates: 2198, 4102 August 18, 2010 Updates: 2198, 4102 (if approved) June 10, 2011
(if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: February 19, 2011 Expires: December 12, 2011
Forward-shifted RTP Redundancy Payload Support Forward-shifted RTP Redundancy Payload Support
draft-ietf-avt-forward-shifted-red-06.txt draft-ietf-avt-forward-shifted-red-07.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).
skipping to change at page 1, line 37 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 19, 2011. This Internet-Draft will expire on December 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 28
Table of Contents Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Sending Redundant Data Inband vs. Out-of-band . . . . . . 3 2.1. Sending Redundant Data Inband vs. Out-of-band . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . 8 Forward-shifted Redundancy . . . . . . . . . . . . . 9
A.1. Sender Side Operations . . . . . . . . . . . . . . . . . . 9 A.1. Sender Side Operations . . . . . . . . . . . . . . . . . . 9
A.2. Receiver Side Operations . . . . . . . . . . . . . . . . . 10 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Conventions 1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 3, line 29 skipping to change at page 3, line 29
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.
In some extreme cases, the receiver may have to spend seconds or even In some extreme cases, the receiver may have to spend seconds or even
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], is known primary data), as currently supported by RFC 2198 [RFC2198], is not
to be ineffective in dealing with such consecutive frame losses. known to be effective in dealing with such consecutive frame losses.
In contrast, the forward-shifted redundancy, when used in combination In contrast, the forward-shifted redundancy scheme allows one to
with the anti-shadow loss management at the receiver (as described in apply effective anti-shadow loss management at the receiver (as
Appendix A), can effectively prevent service interruptions when a illustrated in Appendix A), thus preventing service interruptions
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 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 2.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., FEC, backward-shifting as in RFC 2198) or the encoding scheme (e.g.,
or non-FEC), there is always the option of sending the redundant data Forward Error Correction (FEC), or non-FEC), there is always the
and the primary data either in the same RTP session (i.e., inband) or option of sending the redundant data and the primary data either in
in separate RTP sessions (i.e., out-of-band). There are pros and the same RTP session (i.e., inband) or in separate RTP sessions
cons for either approach, as outlined below. (i.e., out-of-band). There are pros and cons for either approach, as
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 setup 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 RTP/UDP/IP overhead.
skipping to change at page 5, line 25 skipping to change at page 5, line 29
In an RTP session which uses forward-shifted redundant encodings, the In an RTP session which 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, generally in a forward-shifted session, the timestamp offset in
the additional header SHOULD be set to '0'. 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 comes time to send it in the main
stream. If a sender does change the contents of a packet that stream.
appears in a forward shifted stream when it comes time to send it in
the main stream, the receiver behavior is undefined.
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 optional [RFC2198] and RFC 4102 [RFC4102], with the addition of the optional
"forwardshift" parameter.) "forwardshift" parameter.)
Type names: audio, text Type names: audio, text
Subtype names: fwdred Subtype names: fwdred
Required parameters: none Required parameters:
rate: as defined in [RFC4102].
pt: as defined in [RFC4102].
Optional parameters: Optional parameters:
forwardshift: An unsigned integer can be specified as value. forwardshift: An unsigned integer can be specified as value.
If this parameter is present with a value greater than '0', it If this parameter is present with a value greater than '0', it
indicates that the sender of this parameter will use forward indicates that the sender of this parameter will use forward
shifting with a base value as specified when sending out shifting with a base value as specified when sending out
redundant data. This value is in RTP timestamp units. redundant data. This value is in RTP timestamp units.
If this parameter is absent or present with a value of '0', it If this parameter is absent or present with a value of '0', it
indicates that the sender of this parameter will not use indicates that the sender of this parameter will not use
forward shifting when sending its redundant data, i.e., the forward shifting when sending its redundant data, i.e., the
sender will have the same behaviors as defined in RFC 2198. sender will have the same behaviors as defined in RFC 2198.
ptime: as defined in [RFC4102].
maxptime: as defined in [RFC4102].
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 "Security Considerations" of
RFC 2198. RFC 2198.
Interoperability considerations: None. Interoperability considerations: None.
skipping to change at page 8, line 17 skipping to change at page 8, line 25
fwdred [RFCXXXX] fwdred [RFCXXXX]
o addition of the following assignment in the "Text Media Types" o addition of the following assignment in the "Text Media Types"
registry: registry:
fwdred [RFCXXXX] fwdred [RFCXXXX]
8. Security Considerations 8. Security Considerations
Security Considerations discussed in Section 6 of [RFC2198] apply to Security considerations discussed in Section 6 of [RFC2198], Section
this specification. In addition, to prevent denial of service 4 of [RFC4856], and Sections 9 and 14 of [RFC3550] apply to this
attacks, a receiver SHOULD be prepared to ignore a 'forwardshift' specification. In addition, to prevent denial of service attacks, a
parameter declaration if it considers the offset value in the receiver SHOULD be prepared to ignore a 'forwardshift' parameter
declaration excessive. In such a case, the receiver SHOULD also declaration if it considers the offset value in the declaration
ignore the redundant stream in the resultant RTP session. excessive. In such a case, the receiver SHOULD also 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.
skipping to change at page 8, line 44 skipping to change at page 9, line 8
[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", 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
the RTP Profile for Audio and Video Conferences",
RFC 4856, March 2007.
Appendix A. Anti-shadow Loss Concealment Using Forward-shifted Appendix A. Anti-shadow Loss Concealment Using Forward-shifted
Redundancy Redundancy
(Informational)
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 the loss of data
due to shadowing, a mobile user may experience an unacceptable level due to shadowing, a mobile user may experience an unacceptable level
skipping to change at page 13, line 29 skipping to change at page 13, line 32
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 The Resource Group
1700 Pennsylvania Ave. NW 1700 Pennsylvania Ave. NW
Washington, DC 20006 Washington, DC 20006
US US
Phone: +1-314-420-8248 Phone: +1-847-893-0222
Email: Qiaobing.Xie@gmail.com Email: Qiaobing.Xie@gmail.com
 End of changes. 20 change blocks. 
33 lines changed or deleted 46 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/