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

From: Flemming Andreasen <[email-masked]>
Date: Tue, 13 Feb 2007 09:43:37 -0500

Greetings

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

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

The call centered on the new media capabilities document, which Roni and 
Bob have been working on. The issues discussed were:

1) Relationship to RFC 3407
The core capability negotiation document and the media capabilities 
document provide everything that RFC 3407 does (and then some). In lieu 
of this, the team discussed whether these two documents should obsolete 
RFC 3407 or not. The intent is for this work to replace RFC 3407 going 
forward, however it is possible that interworking with RFC 3407 may 
still be required.

2) Numbering of media capabilites (codecs)
Discussion around whether we need to explicitly definie media types in 
the "m=" line. This is similar to the discussion we had around transport 
capabilities and the conclusion is the same: we will require them to be 
specified explicitly, even though they are already part of the "m=" line.

3) Discussion around how we specify the same codecs with different 
parameters
Currently will have multiple instances in cmed line. Alternatives include:
- Changing pcfg attribute to specify potential configurations differently.
- Another level of indirection in the cmed line allowing for composite 
capabilities to be built (and referenced in the pcfg attribute). .

The authors will look further into this.

4) Discussion around what goes in answers.

The m= line in the answer needs to be in accordance with the accepted 
configuration (the way it's done currently). The "acfg" attribute in the 
core should be changed to just reference the pcfg attribute from the 
offer (as opposed to spell it out).

5) Latent configuration attribute
Further work is needed on this - the authors are currently debating 
format and contents.
It was suggested that the lcfg: attribute need not include all the 
attributes of a typical pcfg: line; it might be enough to announce the 
capability to do video, for example, without specifying all the details. 
The details would, of course, be carried in the subsequent offer, if 
any. This would avoid complicating and expanding the initial offer - 
after all, the latent configuration might never be used. The tradeoff, 
of course, is that it might turn out that the two parties cannot support 
a compatible set of attributes. It was decided to examine both options 
and make a decision after that. The latent configuration may require the 
transport parameter(s). One question (which arose before): if we do 
include attributes within the lcfg: attribute, one of those is quite 
likely to be a crypto: attribute, so what do we do with the key material?

6) Attributes in "capar"
The team discussed Thomas Stach's email with respect to attributes 
permitted (or forbidden) within capar: attribute lines. Thomas agreed to 
investigate further to help us understand the uses of the attributes he 
identified. He noted that some may be obsolete; he will try to look at 
the most useful first.

The meeting concluded with Bob and Roni promising to continue work on 
the version 2 document in order to send it to the list before the next 
meeting.

Thanks (and thanks to Bob for help with taking notes)

-- Flemming

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

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 20 Feb 2007 11:00:05 +0200

Hi,

 Item number 2 about explicitly numbering of media capabilities.

There are two ways to do it. The first it to specify the subtypes in the cmed line. The second is to use a media level mcap attribute that will assign a number to the subtypes in the m line. The current version use the second option.

Roni 

________________________________

From: Flemming Andreasen [mailto:[email-masked]] 
Sent: Tuesday, February 13, 2007 4:44 PM
To: mmusic
Subject: [MMUSIC] SDP Capability Negotation: Minutes of 2/6/07 design team conference call

Greetings 

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

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

The call centered on the new media capabilities document, which Roni and Bob have been working on. The issues discussed were:

1) Relationship to RFC 3407
The core capability negotiation document and the media capabilities document provide everything that RFC 3407 does (and then some). In lieu of this, the team discussed whether these two documents should obsolete RFC 3407 or not. The intent is for this work to replace RFC 3407 going forward, however it is possible that interworking with RFC 3407 may still be required. 

2) Numbering of media capabilites (codecs)
Discussion around whether we need to explicitly definie media types in the "m=" line. This is similar to the discussion we had around transport capabilities and the conclusion is the same: we will require them to be specified explicitly, even though they are already part of the "m=" line. 

3) Discussion around how we specify the same codecs with different parameters
Currently will have multiple instances in cmed line. Alternatives include:
- Changing pcfg attribute to specify potential configurations differently.
- Another level of indirection in the cmed line allowing for composite capabilities to be built (and referenced in the pcfg attribute). . 

The m= line in the answer needs to be in accordance with the accepted configuration (the way it's done currently). The "acfg" attribute in the core should be changed to just reference the pcfg attribute from the offer (as opposed to spell it out). 

5) Latent configuration attribute
Further work is needed on this - the authors are currently debating format and contents.
It was suggested that the lcfg: attribute need not include all the attributes of a typical pcfg: line; it might be enough to announce the capability to do video, for example, without specifying all the details. The details would, of course, be carried in the subsequent offer, if any. This would avoid complicating and expanding the initial offer - after all, the latent configuration might never be used. The tradeoff, of course, is that it might turn out that the two parties cannot support a compatible set of attributes. It was decided to examine both options and make a decision after that. The latent configuration may require the transport parameter(s). One question (which arose before): if we do include attributes within the lcfg: attribute, one of those is quite likely to be a crypto: attribute, so what do we do with the key material?

6) Attributes in "capar"
The team discussed Thomas Stach's email with respect to attributes permitted (or forbidden) within capar: attribute lines. Thomas agreed to investigate further to help us understand the uses of the attributes he identified. He noted that some may be obsolete; he will try to look at the most useful first.

The meeting concluded with Bob and Roni promising to continue work on the version 2 document in order to send it to the list before the next meeting.

-- Flemming

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 20 Feb 2007 13:54:54 +0200

Hi,

I am answering myself. The reason for specifying in cmed line is because the order of codecs in the m-line may change by an intermediary that does not support the capability negotiation.

Roni

From: Even, Roni [mailto:[email-masked]] 
Sent: Tuesday, February 20, 2007 11:00 AM
To: Flemming Andreasen; mmusic
Subject: RE: [MMUSIC] SDP Capability Negotation: Minutes of 2/6/07 design teamconference call

Hi,

Roni 

Greetings 

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

6) Attributes in "capar"

-- Flemming