RE: Poll for preferred API alternative

Hi All,

I think the discussion on SDP issues raises an important point as some people might be of the impression that the PeerConnectionAPI is almost complete but reality is that the SDP blob that comes out of it is not specified and it is likely that it will end up looking quite different to SDP that existing implementations are familiar with. We are therefore quite some way from a standard API that will be interoperable between different browsers and legacy implementations without a lot of tweaking and knowledge of SDP in the application.

So actually adoption of a lower level API might not result in as big a delay in specifying a standard API as it might appear at first glance but maybe be at the cost of more complex applications.  However if the current API is really going to be a high level API and be interoperable between browsers we need to move forward with specifying what the SDP looks like in more detail.

I would not go as far as to say we should scrap the use of SDP in the API as there was clear consensus for going with SDP in the IETF when the decision was made probably a year ago but I think we are a long way from complete until the SDP is more clearly specified.

What we do need however for a successful standard is to get consensus between the major browser vendors and that might need some compromises and possibly the specification of two API's at different levels. Do the browser vendors think that possible?

So I am staying a bit on the fence and asking for some compromises so that we can share the success that would come from a widely accepted standard API or API's.

Regards
Andy





From: Tim Panton [mailto:thp@westhawk.co.uk]
Sent: 06 September 2012 00:48
To: Justin Uberti
Cc: Cullen Jennings (fluffy); public-webrtc@w3.org
Subject: Re: Poll for preferred API alternative

I was under the impression that one of the advantages of our adoption of SDP to date was that we could extensively re-use existing code
and that this would give us a high degree of interoperability with a much shorter development time than not using SDP.
Do you still feel that this will be the case ?

T.

On 3 Sep 2012, at 23:34, Justin Uberti wrote:


Right - we've been working on getting all the basics in place, but we expect to start interop testing in the near future, which will bring all these issues to the surface.

While using something other than SDP would make it easier to massage the session description, I'm not sure it would remove the interoperability issue you refer to.

On Mon, Sep 3, 2012 at 9:37 AM, Cullen Jennings (fluffy) <fluffy@cisco.com<mailto:fluffy@cisco.com>> wrote:

On Aug 31, 2012, at 3:15 PM, Tim Panton <thp@westhawk.co.uk<mailto:thp@westhawk.co.uk>> wrote:

> My experience in phono is that we _always_ have to parse-fillet-rewrite the SDP in both directions to get chrome to interop with anything.
>
It's true that the current Chrome SDP is not really workable SDP but I think that is simply an issue with they have not got around to that part of yet - the WebRTC/RTCWeb WGs have not even started serious WG discussion about what SDP extensions are going to be MTI. I think the chrome guys intent is to implement SDP that is widely compatible once we get around to figuring out what that is.