Subject: [MMUSIC] SDPCapNeg-06: Usage of truncated syntax as capability definitions

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

I find the suggestion that one uses truncated SDP attributes as an 
indication that one has a capability very worrying. The reason I think 
that is that it is ambigous in addition to breaking the defined syntax 
of attributes. In short there are in most cases no defined meaning for a 
SDP attribute without its value. To make a general rule without explicit 
defining that meaning for different attributes will be causing ambiogus 
results. Lets look at some examples of this.

1. a=rtpmap: in the form "a=rtpmap" it says nothing that rtp/avp hasen't 
already told you. "a=rtpmap: 97 AMR/8000" does provide some information 
about that you have some type of support for AMR. But it doesn't tell 
you what support in regards to payload configurations. In fact even with 
a single a=fmtp line you only know that one out of several different 
configurations are supported. To declare your capabilites for which AMR 
payload configurations you suport, you actually need a matrix over the 
features. That can't be done without explicit definition of how AMR is 
going to be interpreted and preferably in another syntax then what is 
used to provide a single configuration.

2. I think "a=rtcp-fb" is another one that has similar issues as AMR. In 
this case even worse as it combines with RTP payload formats for the 
payload specific feedback messages. For example PLI may be supported for 
some video codecs and not others. Thus requiring one to list the media 
types which one supports PLI with.

I would suggest that one actually uses another attribute for defining 
capabilities and for that create a structure that allows different 
capabilities to be explicitly defined for each functionality separately. 
Overloading capability definitions on SDP attributes defined for 
configuration is not a good idea.

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:23:23 -0400

Magnus Westerlund wrote:
> of attributes. In short there are in most cases no defined meaning for 
> a SDP attribute without its value. To make a general rule without 
> explicit defining that meaning for different attributes will be 
> causing ambiogus results.
The idea was to allow for such capabilities to be defined, but not for 
them to actually be used; this would strictly limit the use to the 
capability negotiation framework itself (since the contained attribute . 
However, in looking through the document, I can't seem to find text that 
prevents such attribute capabilities from being used by a potential 
configuration. If I either find it or add text to that effect, would 
that address your concern ?

The reason the functionality is in there is primarily because we had it 
in RFC 3407. From a capability point of view, I think there are use 
cases for this (e.g. indicate that you support the "crypto" attribute 
without necessarily listing all the necessary parameters for it), and 
with the above clarifications, I don't believe it's harmful in any way 
either.

> Lets look at some examples of this.
>
> 1. a=rtpmap: in the form "a=rtpmap" it says nothing that rtp/avp 
> hasen't already told you. "a=rtpmap: 97 AMR/8000" does provide some 
> information about that you have some type of support for AMR. But it 
> doesn't tell you what support in regards to payload configurations. In 
> fact even with a single a=fmtp line you only know that one out of 
> several different configurations are supported. To declare your 
> capabilites for which AMR payload configurations you suport, you 
> actually need a matrix over the features. That can't be done without 
> explicit definition of how AMR is going to be interpreted and 
> preferably in another syntax then what is used to provide a single 
> configuration.
>
> 2. I think "a=rtcp-fb" is another one that has similar issues as AMR. 
> In this case even worse as it combines with RTP payload formats for 
> the payload specific feedback messages. For example PLI may be 
> supported for some video codecs and not others. Thus requiring one to 
> list the media types which one supports PLI with.
>
> capabilities to be explicitly defined for each functionality 
> separately. Overloading capability definitions on SDP attributes 
> defined for configuration is not a good idea.
>
The attribute and transport protocol capabilities defined in the 
document are intended to be capabilities, not just configuration lists 
(we have the potential configuration attribute for that). Having said 
that, I agree that you can construct more elaborate capability 
structures, but would rather not go there in the core document.

-- Flemming