Re: SDP wrapper? Object-oriented API?

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
Roman,

     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.

Gili