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

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

Agreed with all you said, and thanks ;)

2013/6/19 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]>
>



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