Subject: RE: [MMUSIC] SDPCapNeg Issue #3: Inconsistent media-level selection of session-level attribute capabilities

From: "Even, Roni" <[email-masked]>
Date: Mon, 2 Jul 2007 09:33:12 +0300

Flemming,

I am OK with the suggestion. This does not prevent addressing the problem for specific media cases in the media extensions to this work and using grouping.

The examples are suing multiple media streams that have relationship, this is not only an issue for this work and is discussed in the contents of adding grouping attributes.

Roni

________________________________

From: Flemming Andreasen [mailto:[email-masked]] 
Sent: Monday, June 25, 2007 8:14 PM
To: mmusic
Subject: [MMUSIC] SDPCapNeg Issue #3: Inconsistent media-level selection of session-level attribute capabilities

The SDP Capability Negotiation framework allows attribute capabilities to be defined at the session-level and at the media-level. When a session-level attribute capability is used by a potential configuration, the session-level attribute is effectively added to the SDP. The capability negotiation framework however does not provide for any coordination between potential configurations chosen by media stream A and media stream B. Thus, it is possible that media stream A selects a potential configuration that uses session-level attribute A, and media stream B selects a potential configuration that uses session-level (or media-level) attribute B, where attribute A and B conflict or interact with each other. 

The design team discussed two different solutions to this issue in Prague:
1) Explain the issue in the document as outlined above and recommend that people avoid using session-level capabilities for cases where such inconsistencies may occur.
2) On the offering side, make sure that we generate sane offers where this issue is not present in the actual configuration SDP to begin with. On the answering side, the answerer will need to look at the resulting potential configuration SDPs. If a potential configuration SDP doesn't make sense (e.g. as a result of the above), the answerer must discard it and move on to the next.

Note that the above is only a problem if we have one or more session-level attributes that can interact or conflict with another session-level or media-level attribute. This is related to SDPCapNeg Issue #1, where we recognized this as a general issue, but didn't find a lot of examples with existing SDP attributes. The primary example we found in terms of conflicts was with a session-level "keymgt" attribute and a media level "crypto" attribute (or potentially multiple "keymgt" attributes at the session-level), however this particular interaction is well-known.

A slightly different set of problems related to this issue is when we need *coordination* between session-level attributes from multiple media streams in order for a particular functionality to actually work. The grouping framework (RFC 3388) is an example of this. If we use the SDP capability negotiation framework to select a session-level group attribute (provided as an attribute capability), and we require two media streams to do this consistently, we could have a problem. The FEC grouping semantics is at least in theory one example where this could cause problems, however in practice, it is unclear that this poses a significant problem with the currently defined grouping semantics. 

In terms of a solution to this CapNeg issue, I believe it is difficult to rely on the answerer to determine what does and does not make sense, at least if we want to have consistent operation between different implementations. Since there doesn't seem to be a huge problem here in practice anyway, the recommended solution is option 1, i.e. explain the issue in the document and avoid using session-level capabilities where this may pose a problem. If you disagree with this, please let me know. 

Thanks 

-- Flemming 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic