Subject: [MMUSIC] SDP Capability Negotation: Minutes of 1/30/07 design team conference call

From: Flemming Andreasen <[email-masked]>
Date: Mon, 05 Feb 2007 20:12:25 -0500

Greetings

The SDP Capability Negotiation Design team had a conference call on 
1/30/07. The attendees were:

    Flemming Andreasen
    Thomas Stach
    Roni Even
    Bob Gilman
    Colin Perkins
    Joerg Ott

The SDP capability negotiation document has been split in two and the 
initial core framework document has been published in 
draft-ietf-mmusic-sdp-capability-negotiation-01.txt. The document notes 
an issue related to potential configurations, where the semantics 
currently differ between the session and the media level, yet the same 
attribute is used for this. The design team agreed to the different 
semantics (latent capability at session-level and actual offer at the 
media level), however the team also felt there should be two different 
attributes for this. Colin noted that the core framework does not 
actully use latent potential configuration at the session-level, so we 
can leave this out of the core and instead include it in the media 
capabilities document, which is being worked separately. The team agreed 
with this.

Transport capabilities are currently numbered from 1, and the transport 
capability from the "m=" line must be included explicitly as a 
capability. It would be more efficient to say that transport capability 
0 is the transport protocol from the "m=" line. The reason this is not 
done however is due to concerns with middle-boxes changing "m=" lines 
(e.g. to translate between RTP and SRTP) while allowing unknown 
attributes to pass through, in which case the implicitly referenced 
transport capability has now been changed with potential errors and 
inconsistencies as a result. The document will clarify this reasoning.

Media Processing before answer was discussed as well. When a potential 
configuration is selected by the answerer, the offerer may not be able 
to process media correctly before receiving the answer. Previously, it 
was possible to e.g. assign different payload types to RTP and SRTP and 
then differentiate based on that (although keying may still be an 
issue). The core document does not enable this functionality; instead 
media capabilities will be needed (or alternative heuristics or methods 
employed).

Joerg had provided an extensive review of the document as well, and the 
comments (as well as other comments received subsequently) will be 
addressed in the next version of the document.

Work is also ongoing on the media capabilities document.

Thanks

-- Flemming

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