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

From: Flemming Andreasen <[email-masked]>
Date: Sun, 18 Feb 2007 10:42:16 -0500

Greetings

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

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

1) The team first discussed the new version of the core SDP capability 
negotiation document (draft-ietf-mmusic-sdp-capability-negotiation-02.txt)
1a) Contrary to what was discussed last week, the actual configuration 
attribute still includes the parameters from the potential configuration 
attribute that were selected from the offer. The reason for this is that 
a single potential configuration attribute can include alternatives, and 
the offerer may need to know which alternative was chosen (e.g. RTP or 
SRTP) without having to try and infer that somehow.

1b) Discussion around limiting attributes to use with the attribute 
capabilities ("a=acap")
Thomas had proposed specifying explicitly allowed attributes only, 
however Flemming had some concerns with that. After additional 
discussion, the team had consensus to specify which well-known 
attributes SHOULD NOT be used with it. More text is needed on this (e.g. 
rtpmap and fmtp, although rtpmap is up for discussion with respect to 
media before answer).

1c) Are capabilities additive or do they completely replace the actual 
configuration ?
Currently, the document does not specify it one way or the other. It was 
noted at as an issue that needs further consideration and clear 
specification in the document - currently, it's not clear what the right 
answer is.

1d) "v0" option tag
During discussion of the media capabilities, it was decided that we 
should have a more descriptive option tag name for the base protocol 
(e.g. "cap_v0").

2) The team then discussed the media capabilities document 
(draft-ietf-mmusic-sdp-media-capabilities-00.txt)
2a) Structure of media capabilities
It is not clear that the current structure around media capabilities is 
the right one. We need to look further into non-RTP based transports as 
well as more complicated capabilities to verify. SDPng found that 
supporting things like
- Forward Error Correction
- Redundancy encoding
- Layered Codecs
was non-trivial and requried quite a bit of work to encompass. We need 
to look further into this.

2b) The "a=cmed" attribute
The "cmed" uses implicit references to media capabilities. There is a 
concern with middle-boxes enforcing policies and potentially reordering 
media formats. Consensus to have explicit capabilities for all media 
capabilities instead.

2c) Option tags
The base protocol defines the option tag "v0", and the media 
capabilities document defines the option tag "v1", however the media 
capabilities document should not be seen as a replacement/update to the 
base protocol, but rather just an extension. A different (and more 
descriptive option tag) should therefore be used for the media 
capabilities (same goes for the base protocol).

2d) Latent Configurations
Discussion around whether attributes should be allowed. Consensus that 
they should. "crypto" attribute is an example of an attribute that is 
not particulary well-suited as a latent configuration capabily since it 
includes keying material. Still, it can be provided. If a more suitable 
format is desired for latent configurations, then new attributes can be 
defined, however we should not modify existing attributes.

Thanks

-- Flemming

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