Re: Microsoft API Proposal

Not sure where you picked that up from, but SDP was not chosen to make life
easier for Google. The whole reason I added the SessionDescription object
to JSEP was to allow for a future where the session description could be a
Javascript object with individual accessors, but still serialize to SDP
when needed.


On Thu, Aug 9, 2012 at 12:10 PM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

> 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
>
>