W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2013

Re: SDP wrapper? Object-oriented API?

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Wed, 19 Jun 2013 11:11:48 -0400
Message-ID: <51C1CA34.3020608@bbs.darktech.org>
To: Roman Shpount <roman@telurix.com>
CC: Iñaki Baz Castillo <ibc@aliax.net>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, public-webrtc@w3.org, piranna@gmail.com, Frédéric Luart <frederic.luart@apizee.com>
On 19/06/2013 10:59 AM, Roman Shpount wrote:
> On Wed, Jun 19, 2013 at 10:45 AM, cowwoc <cowwoc@bbs.darktech.org 
> <mailto:cowwoc@bbs.darktech.org>> wrote:
>         Disregarding the whole section about replacing Offer/Answer
>     since I believe it is out of scope for this discussion, are you
>     asking for a Javascript API that interacts directly with WebRTC
>     without having to pass through a blob/opaque-token? I agree the
>     latter is not ideal, but at the end of the day what's the big
>     deal? If vendors want SDP and end-users want a Javascript API,
>     agreeing to a blob is a decent compromise.
> Since you are disregarding the main point of discussion, there is no 
> point to discuss it any further. The problem is not SDP. The problem 
> is Offer/Answer. Creating API object layers on top of SDP is a waste 
> of time. What you are proposing does not address the underlying issue. 
> Changing from string blob to an object does not give us anything 
> except slightly better cosmetics. It is putting lipstick on a pig. The 
> issue is ability to change media session settings without 
> renegotiating all the settings in the session. You should be able to 
> change transmit codec without going through offer/answer. You should 
> be able to disable echo canceler and noise suppression without going 
> through offer answer. You should be able to add video to an existing 
> audio session without disturbing the audio and doing the offer/answer.
> Also, if you read the discussion carefully, you will realize that O/A 
> with SDP will never be accepted as a browser interface. It is too 
> complex, not easily testable, and cannot be defined in a way that 
> allows interoperable implementations. The sooner it is going to be 
> scrapped the sooner we will get something that can be a standard.
> I was quiet a few previous months waiting for this group to realize 
> what corner that got themselves into. Now, with bundle discussions and 
> with real life implementation experience I think the group is getting 
> ready to move on to something productive.
> _____________
> Roman Shpount

     Thank you for pointing out the difference between our two 
proposals. If I understand you correctly,

 1. I am proposing an abstraction for reading/writing SDP or whatever
    format is chosen by the vendors.
 2. You are proposing replacing offer/answer with a mechanism for
    negotiating call properties in mid-call.

     I agree that your proposal would satisfy my request (I would be 
more than happy if things went your way). I didn't go down this road 
because it was my understanding that this proposal was shot down in the 
past. I'd like to separate our two discussion threads because I don't 
want to risk my own proposal getting rejected if yours does.

     The two proposals would be judged separately on their own merits.

Received on Wednesday, 19 June 2013 15:12:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:44 UTC