draft-ietf-avt-forward-shifted-red-05.txt   draft-ietf-avt-forward-shifted-red-06.txt 
Audio Video Transport WG Q. Xie Audio Video Transport WG Q. Xie
Internet-Draft TRG Internet-Draft TRG
Updates: 2198, 4102 June 24, 2010 Updates: 2198, 4102 August 18, 2010
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: December 26, 2010 Expires: February 19, 2011
Forward-shifted RTP Redundancy Payload Support Forward-shifted RTP Redundancy Payload Support
draft-ietf-avt-forward-shifted-red-05.txt draft-ietf-avt-forward-shifted-red-06.txt
Abstract Abstract
This document defines a simple enhancement to RFC 2198 to support RTP This document defines a simple enhancement to support RTP sessions
sessions with forward-shifted redundant encodings, i.e., redundant with forward-shifted redundant encodings, i.e., redundant data sent
data sent before the corresponding primary data. Forward-shifted before the corresponding primary data. Forward-shifted redundancy
redundancy can be used to conceal losses of a large number of can be used to conceal losses of a large number of consecutive media
consecutive media frames (e.g., consecutive loss of seconds or even frames (e.g., consecutive loss of seconds or even tens of seconds of
tens of seconds of media). media).
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 26, 2010. This Internet-Draft will expire on February 19, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 27 skipping to change at page 2, line 27
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. 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 . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . 8
A.1. Sender Side Operations . . . . . . . . . . . . . . . . . . 8 A.1. Sender Side Operations . . . . . . . . . . . . . . . . . . 9
A.2. Receiver Side Operations . . . . . . . . . . . . . . . . . 10 A.2. Receiver Side Operations . . . . . . . . . . . . . . . . . 10
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 5, line 27 skipping to change at page 5, line 27
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 SHOULD be set to '0'.
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
stream. If a sender does change the contents of a packet that
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
skipping to change at page 7, line 36 skipping to change at page 7, line 44
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 optional "forwardshift" SDP parameter specified in this document
is declarative, and all reasonable values are expected to be is declarative, and all reasonable values are expected to be
supported. supported.
7. IANA Considerations 7. IANA Considerations
The registration of the new subtype "fwdred", as described in RFC EDITOR'S NOTE: please replace "RFCXXXX" with the number of this
Section 4, is required. specification.
This section requests the following IANA actions:
o addition of the following assignment in the "Audio Media Types"
registry:
fwdred [RFCXXXX]
o addition of the following assignment in the "Text Media Types"
registry:
fwdred [RFCXXXX]
8. Security Considerations 8. Security Considerations
See Section 6 "Security Considerations" of RFC 2198 [RFC2198]. In Security Considerations discussed in Section 6 of [RFC2198] apply to
addition, since an excessive forwardshift value can be signalled, as this specification. In addition, to prevent denial of service
a denial of service, a receive SHOULD be prepared to ignore attacks, a receiver SHOULD be prepared to ignore a 'forwardshift'
outrageous values. 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 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 9, line 5 skipping to change at page 9, line 29
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 fast that it is forward-shifted relative to the Except for the fact that it is forward-shifted relative to the
primary stream (i.e., the redundant data is sent ahead of the primary stream (i.e., the redundant data is sent ahead of the
corresponding primary data), the design decision and trade-offs on corresponding primary data), the design decision and trade-offs on
the quality, encoding, bandwidth overhead, etc. of the redundant the quality, encoding, bandwidth overhead, etc. of the redundant
stream is not different from the traditional RTP payload redundant stream is not different from the traditional RTP payload redundant
scheme. 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 the value of timestamp is incremented by 1 between two
 End of changes. 12 change blocks. 
21 lines changed or deleted 41 lines changed or added

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