- From: Jim Barnett <Jim.Barnett@genesyslab.com>
- Date: Thu, 9 Aug 2012 12:10:58 -0700
- To: "Wolfgang Beck" <wolfgang.beck01@googlemail.com>, <public-webrtc@w3.org>
This is the part of the Microsoft proposal that I'm trying to understand. They say that there are interoperability problems with SDP. However if the proposed solution is for the two sides to negotiate _some_ means of exchanging _some_ sort of description - won't that be a lot worse for interoperability? I'm willing to believe that there are better solutions than SDP, but "y'all work it out by yourselves" doesn't seem like one. Microsoft may have something else in mind, but I haven't been able to figure out what it is. It's a separate question whether we want to have a JavaScript API object that gets serialized as SDP. In that case, the SDP provides the interoperability and the JS object provides programming ease. I like that idea, but the group as a whole rejected it at the recent F2F. - Jim -----Original Message----- From: Wolfgang Beck [mailto:wolfgang.beck01@googlemail.com] Sent: Thursday, August 09, 2012 3:01 PM To: public-webrtc@w3.org Cc: Jim Barnett Subject: Re: Microsoft API Proposal On 08/09/2012 05:50 PM, Jim Barnett wrote: > Martin, > Yes, it's true that the building the signaling channel is the application's problem. > I'm wondering about how the applications interpret the messages that are sent on the signaling channel. > SDP specifies a syntax and semantics, so that when an application receives an SDP message over the signaling > channel, it knows what it is and how to interpret it. How will an application know that the message it has > received over the signaling channel is a RealTimeMedia description? > > - Jim That's the problem of the web applications (the servers) that talk to each other. They have to agree on a signaling protocol, they can agree on a way to exchange media descriptions. SDP looks foreign and cumbersome in an environment that easily serializes and parses complex data structures (JSON). What I got from the discussions is that it was only chosen so that google can re-use their existing SDP offer/answer libraries. SIP interconnection should not be the reason. Would it really harm if JSEP dropped SDP in favor of some Javascript object? It could still have an toSDP function.. Wolfgang Beck
Received on Thursday, 9 August 2012 19:12:10 UTC