draft-ietf-avt-forward-shifted-red-07.txt   draft-ietf-avt-forward-shifted-red-08.txt 
AVTCORE Q. Xie AVTCORE Q. Xie
Internet-Draft TRG Internet-Draft TRG
Updates: 2198, 4102 (if approved) June 10, 2011 Updates: 2198, 4102 (if approved) June 17, 2011
Intended status: Standards Track Intended status: Standards Track
Expires: December 12, 2011 Expires: December 19, 2011
Forward-shifted RTP Redundancy Payload Support Forward-shifted RTP Redundancy Payload Support
draft-ietf-avt-forward-shifted-red-07.txt 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).
skipping to change at page 1, line 36 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 December 12, 2011. This Internet-Draft will expire on December 19, 2011.
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 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 not primary data), as currently supported by RFC 2198 [RFC2198], does not
known to be effective in dealing with 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 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
skipping to change at page 5, line 14 skipping to change at page 5, line 14
"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 an optional parameter, media type "fwdred" which allows a parameter, "forwardshift", is
"forwardshift", is introduced for indicating the capability and introduced for indicating the capability and willingness of using
willingness of using forward-shifted redundancy and the base value of forward-shifted redundancy and the base value of timestamp forward-
timestamp forward-shifting. The base value of "forwardshift" is an shifting. The base value of "forwardshift" is an integer equal or
integer equal 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 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 is 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. 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 optional [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].
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 has a value greater than '0', it indicates
indicates that the sender of this parameter will use forward that the sender of this parameter will use forward shifting
shifting with a base value as specified when sending out with a base value as specified when sending out redundant data.
redundant data. This value is in RTP timestamp units. This value is in RTP timestamp units.
If this parameter is absent or present with a value of '0', it If this parameter has a value of '0', it indicates that the
indicates that the sender of this parameter will not use sender of this parameter will not use forward shifting when
forward shifting when sending its redundant data, i.e., the sending its redundant data, i.e., the sender will have the same
sender will have the same behaviors as defined in RFC 2198. behaviors as defined in RFC 2198.
Optional parameters:
ptime: as defined in [RFC4102]. ptime: as defined in [RFC4102].
maxptime: 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.
skipping to change at page 7, line 28 skipping to change at page 7, line 28
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:
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 optional 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) Example of usage of indicating forward-shifted (by 5.1 sec)
redundancy: 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- Example of usage of indicating sending redundancy without forward-
shifting (equivalent to RFC 2198): 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 optional "forwardshift" SDP parameter specified in this document The "forwardshift" SDP parameter specified in this document is
is declarative, and all reasonable values are expected to be declarative, and all reasonable values are expected to be supported.
supported.
7. IANA Considerations 7. IANA Considerations
RFC EDITOR'S NOTE: please replace "RFCXXXX" with the number of this RFC EDITOR'S NOTE: please replace "RFCXXXX" with the number of this
specification. specification.
This section requests the following IANA actions: This section requests the following IANA actions:
o addition of the following assignment in the "Audio Media Types" o addition of the following assignment in the "Audio Media Types"
registry: registry:
 End of changes. 12 change blocks. 
26 lines changed or deleted 25 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/