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

From: Flemming Andreasen <[email-masked]>
Date: Mon, 25 Jun 2007 13:14:01 -0400

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