I'm confused (Re: Poll for preferred API alternative)

Roman Shpount wrote:
> PeerConnection API was created to simplify interoperability, but ended
> up as something that will not work with SIP (modified offer/answer, a
> large number of SDP extensions that are not supported by anything
> currently existing, no support for forking) or  Jingle (Jingle was not

This seems like a somewhat nonsensical argument. "It's possible to make 
JSEP API calls that do things outside of 3264 O/A, therefore we should 
throw that away all 3264 semantics and use something that has no 
relation to it at all"?

SIP and Jingle aren't the same things. One API that can handle both is 
by necessity going to be able to do some things they might not be able 
to do on their own. It's still much easier to build an application that 
interoperates with SIP if everything works _mostly_ the same. Given that 
the maintainer of libjingle is the primary author and proponent of the 
JSEP API, I'm also pretty sure that API will handle what Jingle needs to 
do just fine.

As for extensions... if you're referring to things like BUNDLE and msid, 
these are something the SDP for a SIP-compatible application is going to 
have to deal with, regardless of what the W3C API looks like. They're 
also squarely under the purview of the IETF.

And finally for forking: Mozilla would like to support it, and we've 
discussed options for cloning PeerConnection objects that would allow 
you to do it. Someone does need to do the real work of writing up a 
proposal for that API and defining what the semantics are, but that 
would be equally true of any other solution that would allow forking. 
There are lots of issues like this, for which real work needs to be 
done, but all this time spent debating whether or not we should throw 
away all the work we have done and start over (again) is just keeping 
people from actually working on them.

Received on Wednesday, 29 August 2012 16:10:28 UTC