Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

[Tim Panton <[e-mail]>]

On 12 Oct 2011, at 13:25, Harald Alvestrand wrote:

> On 10/12/11 14:13, Tim Panton wrote:
>> 
>> 
>> On 12 Oct 2011, at 12:39, Harald Alvestrand wrote:
>> 
>>> On 10/12/11 12:31, Tim Panton wrote:
>>>> 
>>>> 
>>>> On 12 Oct 2011, at 11:00, Harald Alvestrand wrote:
>>>> 
>>>>> On 10/12/11 11:46, Neil Stratford wrote:
>>>>>> 
>>>>>> On Wed, Oct 12, 2011 at 10:01 AM, Harald Alvestrand <[e-mail]> wrote
>>>>>> One of the worries I have with doing a "low level spec" unconstrained by our present competence (ignorance?) in  is that I'm reasonably sure we have the knowledge to generate and parse SDP, because the codebases we are building on already generate and parse SDP, and the information present there is enough to set up calls, because we're already setting up calls using that information.
>>>>>> 
>>>>>> I'm less sure of our "getting things right" if we start off by describing the capabilities and control knobs to be exposed in an unconstrained API.
>>>>>> 
>>>>>> As a counter argument, those very same codebases that generate and parse SDP also contain internal APIs that look a lot like a low level spec API, and the information they present is enough to generate and parse SDP and set up calls.
>>>>>> 
>>>>>> Maybe we don't like those APIs and perhaps they expose too much as they were never intended to be made public, but they do exist already.
>>>>> Yup. And I suspect they're all subtly different.
>>>>> 
>>>> 
>>>> You could look at that in a positive light - 
>>>> as evidence that there are multiple ways to solve this problem and deduce:
>>>>  a) it isn't impossibly hard
>>>>  b) there isn't one 'correct' way of doing it.
>>>> 
>>>> Which would lead me back to specifying as _little_ as possible and letting innovation take place.
>>>> 
>>> We have to specify enough for interoperation in at least the use cases of the scenarios document.
>>> In enough detail for interoperation to happen.
>>> 
>>> That could turn out to be a lot, especially if we can't point to existing specs and say "use that".
>> 
>> So, to paraphrase (and make sure I understand) - your argument is that if we don't use SDP,
>> we will have to specify all the fields and associated meanings for every codec we expect to support.
>> 
>> If we do use SDP, then we just point at existing usage and say - 'there, use that' .
>> 
>> If we use a subset or variant on SDP we can say - 'use that, except for this bit to do with port allocation'.
>> 
>> Is that a fair (if informal) summary?
> Yes, exactly.
> 
> We've been around this bush a few times under the guise of "why don't we redefine SDP in JSON" or "why don't we redefine SDP in XML"; this time, it somewhat resembles "why don't we reencode SDP as API calls". I believe a lot of the same arguments apply.
> 


Lets assume we use a subset/variant of SDP as a codec capability description 'language' - (i.e. we won't be using the parts that relate to network properties).

The question then becomes: 'Is current SDP usage so idiosyncratic that it is difficult/impossible to describe a mapping to/from (say) a set of javascript objects which would work for all existing and future codecs that play by the current rules?' 


Tim.