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

[Iñaki Baz Castillo <[e-mail]>]

2013/6/19 Peter Thatcher <[e-mail]>

>>
>> The summary of what I want/believe:
>> 1) I want as close to raw access to RTP/ICE streams, media, sources, outputs, codecs as viable. Obviously doing the actual transmission, encoding/decoding from JS is not feasible (yet), nor is secure [ICE must occur for mutual agreement to exchange data between peers], but having controls for how these components are wired together is extremely feasible from JS and would allow immensely powerful apps to be produced from JS.
>
>
> What would you like to do that you can't do via SDP right now?  You said this isn't just about working through SDP.  But I don't see anything concrete you can't do right now with sufficient SDP parsing/building/munging/hackery.


If the "solution" with the current API/model is "SDP
parsing/building/munging/hackery" then let me strongly say that:

*** I don't want SDP ***

:)




>
> The WG may dislike and reject your proposal


With all due respect,

And which proposal will the WG accept then? It's frustrating IMHO that
we still have no pro-SDP arguments in this long thread and still must
accept that the SDP model would be the chosen one. Does the silence
strategy mean "SDP usage was already voted two years ago, ignore
current complains"? That could be a good argument if during the last
TWO years we had *something* really good and usable based on the SDP
model, but we don't have that. Instead we have tons of drafts and
alternatives to make SDP fulfil WebRTC requirements, and none of them
is good.

IMHO current complains are based on the *experience* of the people
trying to make the SDP model work in WebRTC, including people that
were in favour of SDP two years ago and now have changed their mind
(like me).



>> Anyone who argues that they need/want that simple SDP media negotiation API must understand that a lower level API would allow a wrapper API to produce the same WebRTC API the have today but be built entirely from JavaScript
>
>
> That depends on how low-level you go.  If you go too low-level, it becomes infeasible to do things correctly and performantly in JavaScript.

There are tons of bug in current WebRTC implementations. Yes, there
will be also bugs in future JS libraries dealing with WebRTC internals
(those we propose), but they can be potentially fixed without
requiring upgrading the browser, and without waiting for all the
browser vendors to fix/implement them.

And with all due respect, I don't agree at all with the "JavaScript
performance issue" that worries you, but I think that it is not up to
me to prove that a problem does not exist ;)



Best regards.


--
Iñaki Baz Castillo
<[e-mail]>