Re: Poll for preferred API alternative

On Wed, Aug 29, 2012 at 8:30 AM, Stefan Hakansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> 1) Continue with a design based on the PeerConnection object, using SDP as
> part of the API, roughly in the style of the current API description.
> 2) Remove the PeerConnection object and all use of SDP from the API, and
> pursue an API roughly in the style of Microsoft’s CU-WebRTC proposal.
>

I would hope 2 is chosen.

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 using SDP to
begin with). I think having a big black box of SDP will make
interoperability harder, not easier.

I also think that keeping the offer/answer and ICE state machines hidden
within the browser is undesirable. WebRTC application would primarily need
to communicate and interoperate with other instances of the same WebRTC
application. If some sort of session negotiation protocol is chosen and
used by this application, it should be possible to enforce it for this
application, without it being changed with the browser update. If WebRTC
application needs to interop with external real time communication devices,
it should also be possible to fix the session negotiation protocol within
the application and do no depend on browser updates to modify it.
_____________
Roman Shpount