- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 20 Jul 2011 12:58:19 +0200
- 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 UTC