W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2011

Re: Signaling & peerconnection API questions

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 20 Jul 2011 12:58:19 +0200
Message-ID: <4E26B4CB.9040705@ericsson.com>
To: public-webrtc@w3.org
On 2011-07-20 01:29, Cullen Jennings wrote:
>
> On Jul 19, 2011, at 4:20 , Harald Alvestrand wrote:
>
>> On 07/18/11 23:07, Ian Hickson wrote:
>>> On Mon, 18 Jul 2011, Prakash wrote:
>>>> Excellent. Thanks Ian. I was most concerned about interop with non
>>>> browser/existing systems. If the message is not opaque, then anyone
>>>> should be able to translate it if needed.
>>> Indeed. Compatibility with SIP in particular was high on my mind when
>>> designing this API; the intent is that it should be almost trivial to do a
>>> SIP gateway for this stuff. (I mean, as trivial as this stuff can get,
>>> anyway...)
>>>
>> FWIW, this is one area where Ian and I still don't agree; I think SDP is a representation format we need to avoid, and that we're better off with a JSON-based format where the relevant information can be easily transformed into SDP when needed.
>>
>> This is what the current Google WebRTC implementation supports.
>>
>> We fully agree that the format needs to be
>> a) documented
>> b) possible to map into SDP for gatewaying purposes
>>
>>               Harald
>>
>
>
> I'm going to argue something very counter intuitive here but I am in the Ian camp on SDP vs creating something new. I am going to argue that SDP is an awful design for negotiation of media and that is why we should use it.

<snip>

>  From a practical point, doing something new is going to be a huge chunk of work with no gain.
And we would need to create a place, structure and method for adding the 
parameters/info for new codecs developed in the future. The SDPs can be 
derived from the RTP-payload description (and I think we have consensus 
on using RTP), and examples are usually provided.
>
>
>
>
>
>
Received on Wednesday, 20 July 2011 10:58:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 July 2011 10:58:54 GMT