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

[Peter Thatcher <[e-mail]>]

On Wed, Jun 19, 2013 at 9:54 AM, Iñaki Baz Castillo <[e-mail]> wrote:

> 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 ***
>
> :)
>

It may be helpful to respond to your original request to the WG chairs with
something a little more clear, specific, concise, and actionable then your
original email.  I know many people reading this thread will just think
"what's this?  Oh, just more SDP ranting" and it will fall on deaf ears.

Also, explaining your use case and specific pain points may be helpful.


>
>
>
>
> >
> > The WG may dislike and reject your proposal
>
>
> With all due respect,
>
> And which proposal will the WG accept then?


I don't know.  Perhaps none of them.  It's possible we'll be stuck with SDP
munging forever.

But I think you'll maximize your chances of success by being clear with
what you need, propose digestible solutions, avoid being ranty, and not try
to blow it all up and start from scratch.  But I could be wrong.  Maybe
there's a better way.



> 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).
>

It may help you to understand this from the other side's perspective.  Many
people in the WG like SDP and want to use SDP for everything and don't want
to change SDP much, if at all.   And when someone comes through ranting
about SDP, they don't find that persuasive.

If there's new information gained in the last two years that might be
persuasive, present that.  But try to do it in clear, concise, way that
says "here's what I'm trying to do", "here's my experience", "here's my
pain", "here's how I think we can fix it".  That might be a lot more
persuasive.  Then again, it might now;  who knows? :)



>> 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]>