draft-ietf-mmusic-fec-grouping-02.txt   draft-ietf-mmusic-fec-grouping-03.txt 
MMUSIC Working Group Adam Li MMUSIC Working Group Adam Li
INTERNET-DRAFT HyerVision INTERNET-DRAFT HyerVision
Expires: June 5, 2006 December 5, 2005 Expires: September 5, 2006 March 5, 2006
FEC Grouping Semantics in SDP Forward Error Correction Grouping Semantics
<draft-ietf-mmusic-fec-grouping-02.txt> in Session Description Protocol
<draft-ietf-mmusic-fec-grouping-03.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 24 skipping to change at page 2, line 24
5. Security Consideration...........................................4 5. Security Consideration...........................................4
6. IANA Considerations..............................................5 6. IANA Considerations..............................................5
7. Acknowledgments..................................................5 7. Acknowledgments..................................................5
8. Author's Address.................................................5 8. Author's Address.................................................5
9. References.......................................................5 9. References.......................................................5
9.1. Normative References........................................5 9.1. Normative References........................................5
9.2. Informative References......................................5 9.2. Informative References......................................5
1. Introduction 1. Introduction
The media lines in an SDP [3] session are usually associated with The media lines in an SDP [3] session may be associated with each
each other. SDP itself does not provide methods to convey the other in various ways. SDP itself does not provide methods to convey
relationships between the media lines. Such relationships are the relationships between the media lines. Such relationships are
indicated the extension to SDP as defined in Grouping of Media Lines indicated the extension to SDP as defined in Grouping of Media Lines
in the Session Description Protocol (RFC 3388) [2]. RFC 3388 defines in the Session Description Protocol (RFC 3388) [2]. RFC 3388 defines
two types of semantics: Lip Synchronization, and Flow Identification. two types of semantics: Lip Synchronization, and Flow Identification.
Forward Error Correction (FEC) is a common technique to achieve Forward Error Correction (FEC) is a common technique to achieve
robust communication in error-prone environments. In this document, robust communication in error-prone environments. In this document,
we define the semantics that allows for grouping of FEC streams with we define the semantics that allows for grouping of FEC streams with
the protected payload streams in SDP by further extending RFC 3388. the protected payload streams in SDP by further extending RFC 3388.
2. Terminology 2. Terminology
skipping to change at page 3, line 5 skipping to change at page 3, line 5
Forward Error Correction (FEC) is a common technique to achieve Forward Error Correction (FEC) is a common technique to achieve
robust communication in error-prone environments. In FEC, robust communication in error-prone environments. In FEC,
communication uses a bandwidth that is more than payload to send communication uses a bandwidth that is more than payload to send
redundantly coded payload information. The receivers can readily redundantly coded payload information. The receivers can readily
recover the original payload even when some communication is lost in recover the original payload even when some communication is lost in
the transmission. Compare to other error correction technique (such the transmission. Compare to other error correction technique (such
as re-transmission), FEC can achieve much lower transmission delay, as re-transmission), FEC can achieve much lower transmission delay,
and does not have the problem of implosion from retransmission and does not have the problem of implosion from retransmission
requests in various multicast scenarios. requests in various multicast scenarios.
In general, the FEC data can be send in two different ways: (1) In general, the FEC data can be sent in two different ways: (1)
multiplexed together with the original payload stream, or (2) as a multiplexed together with the original payload stream, or (2) as a
separate stream. It is thus necessary to define mechanisms to separate stream. It is thus necessary to define mechanisms to
indicate the association relationship between the FEC data and the indicate the association relationship between the FEC data and the
payload data they protect. payload data they protect.
When FEC data are multiplexed with the original payload stream, the When FEC data are multiplexed with the original payload stream, the
association relationship is indicated as specified in RTP Payload for association relationship is indicated as specified in RTP Payload for
Redundant Audio Data (RFC 2198) [4]. As an example, such relationship Redundant Audio Data (RFC 2198) [4]. As an example, such relationship
can be indicated as in the generic RFC payload format for FEC [5]. can be indicated as in the generic RFC payload format for FEC [5].
skipping to change at page 3, line 53 skipping to change at page 3, line 53
4.2. Offer / Answer Consideration 4.2. Offer / Answer Consideration
The backward compatibility in offer / answer is generally handled as The backward compatibility in offer / answer is generally handled as
specified in RFC 3388 [2]. specified in RFC 3388 [2].
Depending on the implementation, a node that does not understand FEC Depending on the implementation, a node that does not understand FEC
grouping (either does not understand line grouping at all, or just grouping (either does not understand line grouping at all, or just
does not understand the FEC semantics) might respond to an offer does not understand the FEC semantics) might respond to an offer
containing FEC grouping either (1) with an answer which ignores the containing FEC grouping either (1) with an answer which ignores the
grouping attribute, or (2) with a refusal to the request (e.g., 488 grouping attribute, or (2) with a refusal to the request (e.g., 488
Not acceptable here or 606 Not Acceptable). Not acceptable here or 606 Not Acceptable in SIP).
In the first case, the original sender of the offer MUST establish In the first case, the original sender of the offer MUST establish
the connection without FEC. In the second case, if the sender of the the connection without FEC. In the second case, if the sender of the
offer still wishes to establish the session, it SHOULD re-try the offer still wishes to establish the session, it SHOULD re-try the
request with an offer without FEC. request with an offer without FEC.
4.3. Example of FEC Grouping 4.3. Example of FEC Grouping
The following example shows a session description of a multicast The following example shows a session description of a multicast
conference. The first media stream (mid:1) contains the audio stream. conference. The first media stream (mid:1) contains the audio stream.
skipping to change at page 5, line 45 skipping to change at page 5, line 45
9.1. Normative References 9.1. Normative References
[1] S. Bradner, "Key words for use in RFCs to Indicate Requirement [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[2] G. Camarillo, J. Holler, and H. Schulzrinne, "Grouping of Media [2] G. Camarillo, J. Holler, and H. Schulzrinne, "Grouping of Media
Lines in the Session Description Protocol (SDP)", RFC 3388, Lines in the Session Description Protocol (SDP)", RFC 3388,
December 2002. December 2002.
9.2. Informative References 9.2. Informative References
[3] M. Handley, and V. Jacobson, "SDP: Session Description [3] M. Handley, V. Jacobson, and C. Perkins, "SDP: Session
Protocol", RFC 2327, April 1998. Description Protocol", IETF work in progress, January 2006.
[4] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. [4] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C.
Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload for Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload for
Redundant Audio Data", RFC 2198, September 1997. Redundant Audio Data", RFC 2198, September 1997.
[5] A. Li, "An RFC Payload Format for Generic FEC", IETF work in [5] A. Li, "An RFC Payload Format for Generic FEC", IETF work in
progress. progress, March 2006.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
skipping to change at page 7, line 18 skipping to change at page 7, line 18
modifications upon the publication of this specification: modifications upon the publication of this specification:
- Replace all occurrences of RFC XXXX with the RFC number this - Replace all occurrences of RFC XXXX with the RFC number this
specification receives when being published. specification receives when being published.
- Replace reference [5] and all occurrences of RFC YYYY with the - Replace reference [5] and all occurrences of RFC YYYY with the
corresponding title and RFC number of that ID when it is published. corresponding title and RFC number of that ID when it is published.
- Remove this Section. - Remove this Section.
This Internet-Draft expires June 5, 2006. This Internet-Draft expires September 5, 2006.
 End of changes. 9 change blocks. 
12 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/