--- 1/draft-ietf-mmusic-rfc4756bis-04.txt 2009-10-19 19:12:10.000000000 +0200 +++ 2/draft-ietf-mmusic-rfc4756bis-05.txt 2009-10-19 19:12:10.000000000 +0200 @@ -1,23 +1,23 @@ MMUSIC A. Begen Internet-Draft Cisco Systems -Obsoletes: 4756 October 15, 2009 +Obsoletes: 4756 October 19, 2009 (if approved) Updates: 3388bis, 5576 (if approved) Intended status: Standards Track -Expires: April 18, 2010 +Expires: April 22, 2010 Forward Error Correction Grouping Semantics in Session Description Protocol - draft-ietf-mmusic-rfc4756bis-04 + draft-ietf-mmusic-rfc4756bis-05 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -26,21 +26,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at 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 (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -261,21 +261,27 @@ 4. FEC Grouping 4.1. New Grouping Semantics Each "a=group" line is used to indicate an association relationship 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 repair flows included in an FEC group, they MUST be considered to be 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 new grouping semantics that can support the features of the FEC Framework. 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 specified in the same media description, i.e., in the same "m" line. 4.2. SDP Example @@ -406,39 +412,39 @@ cases are indistinguishable. 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, the node SHOULD respond to the offer either: o With an answer that ignores the grouping attribute. In this case, the original sender of the offer MUST first check whether using the "FEC" grouping semantics will create any - ambiguity or not, while keeping in mind the limitations explained - in Section 3.1. If using the "FEC" semantics rather than the - "FEC-XR" semantics still provides an exact association among the - source and repair flows, the sender of the offer MUST send a new - offer using the "FEC" semantics. However, if an exact association - cannot be described, the sender MUST send a new offer without FEC. + ambiguity or not, while keeping its limitations in mind. If using + the "FEC" semantics rather than the "FEC-XR" semantics still + provides an exact association among the source and repair flows, + the sender of the offer MUST send a new offer using the "FEC" + semantics. However, if an exact association cannot be described, + the sender MUST send a new offer without FEC. o With a refusal to the request (e.g., 488 Not Acceptable Here or 606 Not Acceptable in SIP). In this case, if the sender of the offer still wishes to establish the session, it MUST first check whether using the "FEC" grouping - semantics will create any ambiguity or not, while keeping in mind - the limitations explained in Section 3.1. If using the "FEC" - semantics rather than the "FEC-XR" semantics still provides an - exact association among the source and repair flows, the sender of - the offer SHOULD send a new offer using the "FEC" semantics. - However, if an exact association cannot be described, the sender - SHOULD send a new offer without FEC. + semantics will create any ambiguity or not, while keeping its + limitations in mind. If using the "FEC" semantics rather than the + "FEC-XR" semantics still provides an exact association among the + source and repair flows, the sender of the offer SHOULD send a new + offer using the "FEC" semantics. However, if an exact association + cannot be described, the sender SHOULD send a new offer without + FEC. 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 it, the session will be established and the rules pertaining to [RFC4756] will be valid. However, if the node does not understand the "FEC" semantics, it 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 first case, the sender MUST send a new offer without FEC. In the