draft-ietf-mmusic-rfc4756bis-04.txt   draft-ietf-mmusic-rfc4756bis-05.txt 
MMUSIC A. Begen MMUSIC A. Begen
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Obsoletes: 4756 October 15, 2009 Obsoletes: 4756 October 19, 2009
(if approved) (if approved)
Updates: 3388bis, 5576 Updates: 3388bis, 5576
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: April 18, 2010 Expires: April 22, 2010
Forward Error Correction Grouping Semantics in Session Description Forward Error Correction Grouping Semantics in Session Description
Protocol Protocol
draft-ietf-mmusic-rfc4756bis-04 draft-ietf-mmusic-rfc4756bis-05
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2010. This Internet-Draft will expire on April 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 6, line 49 skipping to change at page 6, line 49
4. FEC Grouping 4. FEC Grouping
4.1. New Grouping Semantics 4.1. New Grouping Semantics
Each "a=group" line is used to indicate an association relationship Each "a=group" line is used to indicate an association relationship
between the source and repair flows. The flows included in one between the source and repair flows. The flows included in one
"a=group" line are called an FEC Group. If there are more than one "a=group" line are called an FEC Group. If there are more than one
repair flows included in an FEC group, they MUST be considered to be repair flows included in an FEC group, they MUST be considered to be
additive. Repair flows that are not additive MUST be indicated in additive. Repair flows that are not additive MUST be indicated in
separate FEC groups. separate FEC groups. However, if two (or more) repair flows are
additive in an FEC group, it does not necessarily mean that these
repair flows will also be additive in any other FEC group.
Generally, in order to express multiple relations between the source
and repair flows, each source and repair flow MAY appear in more than
one FEC group.
By extending [I-D.ietf-mmusic-rfc3388bis] we define "FEC-XR" as the By extending [I-D.ietf-mmusic-rfc3388bis] we define "FEC-XR" as the
new grouping semantics that can support the features of the FEC new grouping semantics that can support the features of the FEC
Framework. Framework.
The "a=group:FEC-XR" semantics MUST always be used to associate the The "a=group:FEC-XR" semantics MUST always be used to associate the
source and repair flows except when the source and repair flows are source and repair flows except when the source and repair flows are
specified in the same media description, i.e., in the same "m" line. specified in the same media description, i.e., in the same "m" line.
4.2. SDP Example 4.2. SDP Example
skipping to change at page 9, line 52 skipping to change at page 10, line 13
cases are indistinguishable. cases are indistinguishable.
When a node is offered a session with the "FEC-XR" grouping semantics When a node is offered a session with the "FEC-XR" grouping semantics
but it does not support line grouping or the FEC grouping semantics, but it does not support line grouping or the FEC grouping semantics,
the node SHOULD respond to the offer either: the node SHOULD respond to the offer either:
o With an answer that ignores the grouping attribute. o With an answer that ignores the grouping attribute.
In this case, the original sender of the offer MUST first check In this case, the original sender of the offer MUST first check
whether using the "FEC" grouping semantics will create any whether using the "FEC" grouping semantics will create any
ambiguity or not, while keeping in mind the limitations explained ambiguity or not, while keeping its limitations in mind. If using
in Section 3.1. If using the "FEC" semantics rather than the the "FEC" semantics rather than the "FEC-XR" semantics still
"FEC-XR" semantics still provides an exact association among the provides an exact association among the source and repair flows,
source and repair flows, the sender of the offer MUST send a new the sender of the offer MUST send a new offer using the "FEC"
offer using the "FEC" semantics. However, if an exact association semantics. However, if an exact association cannot be described,
cannot be described, the sender MUST send a new offer without FEC. the sender MUST send a new offer without FEC.
o With a refusal to the request (e.g., 488 Not Acceptable Here or o With a refusal to the request (e.g., 488 Not Acceptable Here or
606 Not Acceptable in SIP). 606 Not Acceptable in SIP).
In this case, if the sender of the offer still wishes to establish In this case, if the sender of the offer still wishes to establish
the session, it MUST first check whether using the "FEC" grouping the session, it MUST first check whether using the "FEC" grouping
semantics will create any ambiguity or not, while keeping in mind semantics will create any ambiguity or not, while keeping its
the limitations explained in Section 3.1. If using the "FEC" limitations in mind. If using the "FEC" semantics rather than the
semantics rather than the "FEC-XR" semantics still provides an "FEC-XR" semantics still provides an exact association among the
exact association among the source and repair flows, the sender of source and repair flows, the sender of the offer SHOULD send a new
the offer SHOULD send a new offer using the "FEC" semantics. offer using the "FEC" semantics. However, if an exact association
However, if an exact association cannot be described, the sender cannot be described, the sender SHOULD send a new offer without
SHOULD send a new offer without FEC. FEC.
Note that in both cases described above, when the sender of the offer Note that in both cases described above, when the sender of the offer
sends a new offer with the "FEC" semantics, and the node understands sends a new offer with the "FEC" semantics, and the node understands
it, the session will be established and the rules pertaining to it, the session will be established and the rules pertaining to
[RFC4756] will be valid. [RFC4756] will be valid.
However, if the node does not understand the "FEC" semantics, it However, if the node does not understand the "FEC" semantics, it
SHOULD respond to the offer either (1) with an answer that ignores SHOULD respond to the offer either (1) with an answer that ignores
the grouping attribute, or (2) with a refusal to the request. In the the grouping attribute, or (2) with a refusal to the request. In the
first case, the sender MUST send a new offer without FEC. In the first case, the sender MUST send a new offer without FEC. In the
 End of changes. 7 change blocks. 
18 lines changed or deleted 24 lines changed or added

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