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

[Peter Thatcher <[e-mail]>]

On Wed, Jun 26, 2013 at 4:57 PM, Gustavo Garcia Bernardo <[e-mail]> wrote:

>  Getting the feeling of that silent mayority is what we are doing in this
> thread.  Hope we can put something together as Robin volunteered to lead.
>
>
Even the "SDP rebellion" aside (by the way, you guys need some Star Wars
jokes), it would very useful to have a good idea of who is working on what
and how well the API is working for them, and what things could be added or
changed to help.   Most of the WG does seem to have any real experience
actually using the API, and I think that limits are ability to design the
right API.  More input from people actually using the API could only help,
and I look forward to hearing more.

 There is a working implementation of cu-web-rtc, look for it in Microsoft
> html labs page.  Obviously my prototype is quick and dirty but you get my
> point on what you can do.
>
>
I apologize if I missed the link to your prototype.  I'd like to see it.
 Can you repost the link?


>
>  Sent from mobile
>
> Peter Thatcher <[e-mail]> wrote:
>
>  On Wed, Jun 26, 2013 at 4:29 PM, Gustavo García <[e-mail]> wrote:
>
>> "We reject kings, presidents and voting. We believe in rough consensus
>> and running code". (IETF TAO)
>>
>> - Lot of developers building stuff beyond a PSTN interconnection demo are
>> having problems with the existing model.   Complexity, limitations and
>> incompatibilities make us feel like fighting an API instead of using it.
>> - There are a lot of issues (bugs, incompatibilities, feature requests)
>> because of SDP and O/A.  Take a look at webrtc issue tracker.
>> - The actual experience of people using the API should be a stronger
>> argument than a voting done one year ago.  Specially when most of
>> developers are not participating in IETF voting and after realizing the
>> implications of SDP and O/A model f.e. on all those endless Plan-XXX
>>  discussions.
>>
>
>  If there's a great "silent majority" out there, I think it would help
> the WG a lot for them to come on the forum and give clear, concrete
> examples (not ranty, please) of what they're trying to do and what their
> pain points are.   I think that's much more helpful than just remaining
> silently in pain.  On the flip side, if app developers love using the
> current API and think SDP O/A is great, they should express that as well.
>
>
>> - There is a much more simple solution (something like CU-RTC-Web) and
>> you can always write a SDP/O/A/PeerConnection API on top of it (I had a
>> prototype working in a couple of hours), but the other way around is much
>> more hard if not impossible.
>>
>
>  You know you're in trouble when CU-RTC-Web is considered "much more
> simple" :).
>
>  I think your "bulid RtcPeerConnection on top in JS" is a great idea, but
> you had a prototype in a couple of hours?  I have a hard time you could
> implement much of SDP O/A correctly in a couple of ours.  And how could you
> test such a thing, without a working implementation of CU-RTC-Web?
>
>
>> In my opinion the only reasonable approaches are:
>> - Change the API now
>> - Change the API in one year
>>
>>
>  You could add:
>
>  - Change the API every couple weeks by changing what SDP is
> generated/supported.
>
>
>  :)
>
>  +1 to Iñaki's request too
>>
>> G.
>>
>> On 18/06/2013, at 15:19, Matthew Jordan wrote:
>>
>> >
>> > On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu <[e-mail]>
>> wrote:
>> > +1
>> >
>> > While working with the specs, some may have realised that SDP is not
>> such a great idea to put in practice and may also want to come forward to
>> admit their mistake.
>> >
>> > Regards,
>> > Adrian
>> >
>> >
>> > In the Asterisk project, we were able to use our legacy SIP stack to
>> enable very basic WebRTC communication with Chrome and FireFox. That sounds
>> nice, until you realize we have to continually preface that with
>> "sometimes".
>> >
>> > Because the answer is, more often than not, something breaks.
>> Invariably, the breakages have been in the SDPs sent to Asterisk by the
>> browser. What SDP breaks us changes depending on the browser being used,
>> the version of said browser, and whether or not some new WebRTC SDP feature
>> has been put in the browser's latest release. And just when we think we
>> have to modify Asterisk to handle the new SDP sent by some browser, the
>> browser changes again. As a result, Asterisk 11 hasn't changed a lot since
>> we released; we've been trying to avoid coding to a moving target. We
>> always envisioned that things would quiet down and the browsers would
>> settle on an implementation of SDP that we could adapt to - but it doesn't
>> seem like things are quieting down as much as we'd like. And sure, the SIP
>> stack in Asterisk is crufty, and sure, sometimes the fault is in our
>> implementation, not the browser's - but I think we on the Asterisk project
>> can certainly say that relying on SDP hasn't been a panacea for
>> interoperability.
>> >
>> > It feels like maintaining compatibility with "traditional" SDP
>> implementations is getting harder for the browsers to manage and holding
>> the entire process back. As one of those older "traditional"
>> implementations, I'd rather write an entirely new channel driver for
>> Asterisk than have to re-write our SDP handling.
>> >
>> > So... +1 to Inaki's request.
>> >
>> > Matt
>> >
>> > --
>> > Matthew Jordan
>> > Digium, Inc. | Engineering Manager
>> > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> > Check us out at: http://digium.com & http://asterisk.org
>>   > _______________________________________________
>> > rtcweb mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>
> ------------------------------
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>