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

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.

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


> 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