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

On Wed, Aug 29, 2012 at 9:41 AM, Roman Shpount <roman@telurix.com> wrote:

>
> On Wed, Aug 29, 2012 at 12:09 PM, Timothy B. Terriberry <
> tterriberry@mozilla.com> wrote:
>
>> 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"?
>>
>
> My main issue with offer/answer and SDP is that we are trying to use them
> to implement an API, when those things were clearly designed for a network
> protocol. A lot of things that normally fall under the real time media
> stack API cannot be expressed via offer/answer, so we add things like
> hints. The API needs to inform the signaling application about
> its capabilities (ie codecs supported, media types, security methods),
> allow the signaling stack to select its preferences (for instance listen
> only audio call with Opus codec preferred), and make the make the media
> stack generate an offer. When an answer is received, signaling stack needs
> to examine this answer, modify it according to its preferences and pass it
> on to the underlying stack. It then needs to be able to generate new
> offers, or to provide the modified answer to a previous offer. Doing this
> by manipulating SDP and by trying to fit this into offer/answer
> is cumbersome and of no real benefit.
>

> First of all, SDP has a clear internal structure (ie SDP lines with a very
> few known types of well defined formats). API should be dealing with this
> data packaged in the structures, not in a string blob. It is trivial to
> define a mapping from SDP to a session description object.
>

We currently have a SessionDescription object in the API, which can convert
to/from SDP. One can certainly imagine having specific accessors on this
object so that the description can be changed without having to do
operations on a string blob.

>
>

> Offer/answer would be better implemented by decomposing it into set of
> lower level operations, such as creating data connections, selecting
> encryption to be used over this data connection, and then selecting media
> to be transmitted over this media connection independently.
>
> To summarize, from my point of view, it is not that I want to through away
> offer/answer. I just think it is inappropriate as a model for an API. I
> would argue that building WebRTC API on top of offer/answer will make
> application harder to implement and control, and in the end of the day,
> will make interop with offer/answer harder as well.
>
> 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.
>
>
> I am pretty sure current API cannot be mapped to Jingle without some
> extensions or additional work. When thing mostly the same does not make it
> easier to build an interoperable solutions. It really depends on the exact
> difference. Current WebRTC proposal will only work with other WebRTC
> implementations or some sort of media and signaling translation device.
>

As Tim mentions... I'm pretty sure it can be mapped 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.
>>
>
> These extensions are under IETF purview, but the API that controls their
> use is under W3C purview. I think, for interop it would be better to
> disable some of those features via the API instead of relying on
> offer/answer and SDP to negotiate that these things are not supported by
> the remote party.
>

Well, you can do this - strip anything you don't want out of the local
description, then you don't even have to negotiate it off via offer/answer.

>
>
>> 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.
>>
>
> I would be more then happy to help designing or implementing this within
> the current API or an alternative that will be proposed.
> _____________
> Roman Shpount
>