draft-ietf-mmusic-rfc4756bis-09.txt   draft-ietf-mmusic-rfc4756bis-10.txt 
MMUSIC A. Begen MMUSIC A. Begen
Internet-Draft Cisco Internet-Draft Cisco
Obsoletes: 4756 May 10, 2010 Obsoletes: 4756 June 9, 2010
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: November 11, 2010 Expires: December 11, 2010
Forward Error Correction Grouping Semantics in Session Description Forward Error Correction Grouping Semantics in Session Description
Protocol Protocol
draft-ietf-mmusic-rfc4756bis-09 draft-ietf-mmusic-rfc4756bis-10
Abstract Abstract
This document defines the semantics for grouping the associated This document defines the semantics for grouping the associated
source and Forward Error Correction (FEC)-based repair flows in the source and Forward Error Correction (FEC)-based repair flows in the
Session Description Protocol (SDP). The semantics defined in this Session Description Protocol (SDP). The semantics defined in this
document are to be used with the SDP Grouping Framework (RFC document are to be used with the SDP Grouping Framework (RFC
3388bis). These semantics allow the description of grouping 3388bis). These semantics allow the description of grouping
relationships between the source and repair flows when one or more relationships between the source and repair flows when one or more
source and/or repair flow are associated in the same group, and they source and/or repair flow are associated in the same group, and they
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 November 11, 2010. This Internet-Draft will expire on December 11, 2010.
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 10, line 35 skipping to change at page 10, line 35
payload type. payload type.
The additivity of the repair flows is handled in the same way as The additivity of the repair flows is handled in the same way as
described in Section 4.2. In other words, the repair flows that are described in Section 4.2. In other words, the repair flows that are
included in an "a=ssrc-group" line MUST be additive. Repair flows included in an "a=ssrc-group" line MUST be additive. Repair flows
that are not additive MUST be indicated in separate "a=ssrc-group" that are not additive MUST be indicated in separate "a=ssrc-group"
lines. lines.
4.4. "FEC" Grouping Semantics 4.4. "FEC" Grouping Semantics
This document deprecates the usage of the "FEC" semantics: "FEC-FR" This document deprecates the usage of the "FEC" semantics. Sessions
must be used instead. However, it is RECOMMENDED to implement the negotiated between two endpoints implementing this specification MUST
"FEC" semantics as defined in this section for backward compatibility use the "FEC-FR" semantics and not the "FEC" semantics. Section 4.5
reasons. details how an implementation supporting this specification detects
peers that do not support this specification (based on their SDP
answer to the initial offer). When this occurs, the offering
implementation SHOULD initiate a new offer using the "FEC" semantics
as defined in this section.
The "FEC" grouping semantics had been originally introduced in The "FEC" grouping semantics had been originally introduced in
[RFC4756]. The "FEC" semantics used the "a=group" line from [RFC4756]. The "FEC" semantics used the "a=group" line from
[RFC3388] to form an FEC Group to indicate the association [RFC3388] to form an FEC Group to indicate the association
relationship between the source and repair flows. relationship between the source and repair flows.
In the "FEC" semantics, a source or repair flow can only appear in a In the "FEC" semantics, a source or repair flow can only appear in a
single "a=group:FEC" line. Thus, all the source and repair flows single "a=group:FEC" line. Thus, all the source and repair flows
that are somehow related to each other have to be listed in the same that are somehow related to each other have to be listed in the same
"a=group:FEC" line. For example, for the scenario sketched in "a=group:FEC" line. For example, for the scenario sketched in
Figure 1, we have to write "a=group:FEC S1 S2 R1 R2" regardless of Figure 1, we have to write "a=group:FEC S1 S2 R1 R2" regardless of
which repair flows protect which particular source flows. Similarly, which repair flows protect which particular source flows. Similarly,
for the scenario sketched in Figure 3, we have to write "a=group:FEC for the scenario sketched in Figure 3, we have to write "a=group:FEC
S4 R5 R6 R7" regardless of which repair flows are additive. However, S4 R5 R6 R7" regardless of which repair flows are additive. However,
the interpretation of these lines would be ambiguous. the interpretation of these lines would be ambiguous.
In certain simple scenarios such as where there is one source flow In certain simple scenarios such as where there is one source flow
and one repair flow, these limitations may not be a concern. In and one repair flow, these limitations may not be a concern. In
Offer/Answer model scenarios, when the "FEC-FR" semantics are not Offer/Answer model scenarios, when the "FEC-FR" semantics are not
understood by the answerer, the "FEC" semantics may be offered understood by the answerer, the "FEC" semantics can be offered
provided that the "FEC" semantics provide an exact association among provided that the "FEC" semantics provide an exact association among
the source and repair flows and do not create any ambiguity. See the source and repair flows and do not create any ambiguity. See
Section 4.5 for details. Section 4.5 for details.
4.5. SDP Offer/Answer Model and RFC 4756 Backward-Compatibility 4.5. SDP Offer/Answer Model and RFC 4756 Backward-Compatibility
Considerations Considerations
When offering FEC grouping using SDP in an Offer/Answer model When offering FEC grouping using SDP in an Offer/Answer model
[RFC3264], the following considerations apply. [RFC3264], the following considerations apply.
skipping to change at page 11, line 34 skipping to change at page 11, line 38
cases are indistinguishable. cases are indistinguishable.
Implementations are RECOMMENDED to support the "FEC" semantics Implementations are RECOMMENDED to support the "FEC" semantics
specified in Section 4.4 for backward compatibility reasons. If the specified in Section 4.4 for backward compatibility reasons. If the
sender of the offer supports the "FEC" semantics, it SHOULD fall back sender of the offer supports the "FEC" semantics, it SHOULD fall back
to using the "FEC" semantics when the "FEC-FR" semantics are not to using the "FEC" semantics when the "FEC-FR" semantics are not
understood by the node. understood by the node.
When a node is offered a session with the "FEC-FR" grouping semantics When a node is offered a session with the "FEC-FR" 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 responds to the offer either: as per [I-D.ietf-mmusic-rfc3388bis], the node responds 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, if the original sender of the offer supports the In this case, if the original sender of the offer
"FEC" semantics described in Section 4.4, it MUST first check
whether using the "FEC" semantics will create any ambiguity or * does support the "FEC" semantics described in Section 4.4, it
not, while keeping its limitations in mind. If using the "FEC" MUST first check whether using the "FEC" semantics will create
semantics rather than the "FEC-FR" semantics still provides an any ambiguity or not. If using the "FEC" semantics still
exact association among the source and repair flows, the sender provides an exact association among the source and repair
SHOULD send a new offer using the "FEC" semantics. However, if an flows, the sender SHOULD send a new offer using the "FEC"
exact association cannot be described or the sender does not semantics. However, if an exact association cannot be
support the "FEC" semantics, it MUST send a new offer without FEC. described, it MUST send a new offer without FEC.
* does not support the "FEC" semantics described in Section 4.4,
it 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 original sender of the offer
the session and supports the "FEC" semantics, it MUST first check
whether using the "FEC" grouping semantics from Section 4.4 will
create any ambiguity or not, while keeping its limitations in
mind. If using the "FEC" semantics rather than the "FEC-FR"
semantics still provides an exact association among the source and
repair flows, the sender SHOULD send a new offer using the "FEC"
semantics. However, if an exact association cannot be described
or the sender does not support the "FEC" semantics, it SHOULD send
a new offer without FEC.
This behavior is as specified in [I-D.ietf-mmusic-rfc3388bis]. Note * does support the "FEC" semantics and still wish to establish
that in both cases described above, when the sender of the offer the session, it MUST first check whether using the "FEC"
sends a new offer with the "FEC" semantics, and the node understands semantics will create any ambiguity or not. If using the "FEC"
it, the session will be established and the rules pertaining to the semantics still provides an exact association among the source
"FEC" semantics will apply. and repair flows, the sender SHOULD send a new offer using the
"FEC" semantics. However, if an exact association cannot be
described, it SHOULD send a new offer without FEC.
If the node does not understand the "FEC" semantics, it responds to * does not support the "FEC" semantics described in Section 4.4,
the offer, as specified in [I-D.ietf-mmusic-rfc3388bis], either (1) it SHOULD send a new offer without FEC.
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 the "FEC"
semantics will apply.
As specified in [I-D.ietf-mmusic-rfc3388bis], if the node does not
understand the "FEC" semantics, it responds to the offer, either (1)
with an answer that ignores the grouping attribute, or (2) with a 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 refusal to the request. In the first case, the sender must send a
new offer without FEC. In the second case, if the sender still new offer without FEC. In the second case, if the sender still
wishes to establish the session, it should retry the request with an wishes to establish the session, it should retry the request with an
offer without FEC. offer without FEC.
5. Security Considerations 5. Security Considerations
There is a weak threat for the receiver that the FEC grouping can be There is a weak threat for the receiver that the FEC grouping can be
modified to indicate FEC relationships that do not exist. Such modified to indicate FEC relationships that do not exist. Such
skipping to change at page 14, line 10 skipping to change at page 14, line 17
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, June 2009.
8.2. Informative References 8.2. Informative References
[I-D.ietf-fecframe-framework] [I-D.ietf-fecframe-framework]
Watson, M., "Forward Error Correction (FEC) Framework", Watson, M., "Forward Error Correction (FEC) Framework",
draft-ietf-fecframe-framework-07 (work in progress), draft-ietf-fecframe-framework-08 (work in progress),
March 2010. June 2010.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002. Description Protocol (SDP)", RFC 3388, December 2002.
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol", RFC 4756, November 2006. Session Description Protocol", RFC 4756, November 2006.
Author's Address Author's Address
 End of changes. 12 change blocks. 
38 lines changed or deleted 47 lines changed or added

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