Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened .

[Robin Raymond <[e-mail]>]

Things to consider:
1) Many people who agreed with SDP have since changed their mind
2) If we opt to go with SDP in version #1 knowing that edge cases are 
causing major pains, those not doing SIP are having great pains, whose 
to say we will be able to fix it in version 2? At that point deployed 
systems will actually rely upon it and it will be even harder to affect 
change and then people will have two methods to do the same thing and 
have to support both because some browsers will be stuck on version 1 
for a long time to come.
3) SDP has become a serialized surface API for object control/properties 
and the only way to extend this in the future is via SDP extensions; 
that's a huge part of the issue and objection. That's also probably why 
so many are focused on extending SDP because they know it doesn't do 
anything beyond a simple demo at this point and is not ready for prime 
time deployments and many real-world use cases.
4) There is very few people saying SDP is "good" or "right". The 
arguments seem to fall into "we've made that choice", "it's too late", 
"we'll fix it later", "we must get something out now"
5) The cost of fixing it now could be much less than everyone working 
around this later

That's why I'd like to head up with a proposal with a JS shim for 
supporting SDP. We can get both worlds and put this debate truly to rest 
and (hopefully) even bring Microsoft onboard. I've written a media 
engine/RTC so I've got a good handle on what's involved and I've seen 
the webrtc C++ engine too. So I've got an idea as to what's going on 
under the hood and I have real world experience having written a SIP 
softphone client from scratch. Presently I'm trying to mangle Open Peer 
to utilize this SDP thing. Keep in mind, even I was okay at first with 
using SDP thinking I'd just parse/generate it until I thought about all 
its long term consequences as a surface API and then becomes strongly 
opposed to using it.

Making a simple surface API that isn't reliant on SDP and creating a JS 
SDP shim is entirely possible/feasible and will allow for a flexible 
future where we don't have tons of competing extensions to SDP with no 
idea what each browser actually/officially supports.

-Robin

> Hutton, Andrew <mailto:[e-mail]>
> 20 June, 2013 1:00 PM
>
> No it is not the only argument it is just stating the fact that we had 
> the debate previously in which the arguments were made and the balance 
> was in favor of SDP. As I said I don't really want to reopen all the 
> old arguments.
>
> I am saying that people are getting frustrated and considering a 
> change because we are concentrating on extending SDP rather than 
> keeping things simple and focusing on the current deliverables as 
> specified in the charter. If we had not gone this route then I think 
> we would have more success and people would not have become so frustrated.
>
> Changing fundamental decisions at a late stage is not a major deal and 
> comes with great costs so needs even more justification than the 
> original decision did.
>
> Andy.
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> Iñaki Baz Castillo <mailto:[e-mail]>
> 20 June, 2013 12:41 PM
>
> Hi Andrew, please don't take me wrong but:
>
> So the only arguments pro-SDP are "it was debated many times" (it
> seems it does not matter than many people that agreed then have
> changed their mind after getting experience), "let do something simple
> for now based on SDP, something that allows a simple PSTN call" (so
> SDP will be here forever and any future WebRTC app will have to deal
> with SDP nightmares and will be subject to its O/A model, forever and
> ever).
>
>