Subject: [MMUSIC] SDPCapNeg-06: Media capabilites negotiation

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Jul 2007 19:14:06 +0200

I would like to expand a bit on what I consdier being media capabilites 
negotiation. It has quite some implications for the SDPCapNeg 
definition. However, I don't think that the full solution needs to be 
included in the core spec. It could be an extension if some capabilites 
of the core exist. But lets start on what I would like to see as 
possible and what it would be used for.

In the requirements document requirement 10 exist which says:

REQ-10: It MUST be possible to indicate and negotiate alternative
    media formats on a per media stream basis.

       For example, many implementations support multiple codecs, but
       only one at a time.  Changes between codecs cannot be done on-
       the-fly, e.g. when receiving a simple RTP payload type change.

However, to my knowledge that is not the close to the whole truth for 
devices with limited capabilites. Because they not be able to provide 
certain codecs when another media streams uses a particular codec. A 
good example would be that a device can't decode AAC when combined with 
H.264 while it could do AAC when doing H.263. Such constraints are 
complex to describe but do exist.

In addition there is the issue of correctly describe what ones 
capabilites are in regards to a specific media format. This is actually 
a combination of the device capabilites in regards to the payload 
format, transport and encoding/decoding. Thus another language is need 
than the one used to configure devices when describing capabilites. For 
example in a capability language one can do efficient encoding of 
independent capabilites while configurations needs to list all 
permutations.

There is also the issues around configuring more advanced relations for 
media which I already brought up in the other emails. This include 
issues with:

- Media before answer
- Media descriptions dependent on other media descriptions
- Media configurations depending on transport

There should be consideration on these issues and what it means for the 
core of the proposal.

cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 23 Jul 2007 12:34:42 -0400

Magnus Westerlund wrote:
> I would like to expand a bit on what I consdier being media 
> capabilites negotiation. It has quite some implications for the 
> SDPCapNeg definition. However, I don't think that the full solution 
> needs to be included in the core spec. It could be an extension if 
> some capabilites of the core exist. But lets start on what I would 
> like to see as possible and what it would be used for.
>
Pleaes note that requirement 10 is not in scope for the core document 
but instead is an enhancement (per REQ-310)
> good example would be that a device can't decode AAC when combined 
> with H.264 while it could do AAC when doing H.263. Such constraints 
> are complex to describe 
Agreed - I believe REQ-160 talks about this (out of scope as well).
> capabilites are in regards to a specific media format. This is 
> actually a combination of the device capabilites in regards to the 
> payload format, transport and encoding/decoding. Thus another language 
> is need than the one used to configure devices when describing 
> capabilites. For example in a capability language one can do efficient 
> encoding of independent capabilites while configurations needs to list 
> all permutations.
>
> There is also the issues around configuring more advanced relations 
> for media which I already brought up in the other emails. This include 
> issues with:
>
> - Media before answer
> There should be consideration on these issues and what it means for 
> the core of the proposal.
I'm not sure how to address this comment without effectively halting 
further progress until we have the media capabilities work done. While I 
agree it would be desirable to have the media capabilities work done as 
validation that we can address the extensions you are looking for, I 
think it would add significant delay and so far there hasn't been 
somewhat limited interest in solving the whole media capabilities 
negotiation issue. Can you propose something here ?

Thanks

-- Flemming