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

[Peter Thatcher <[e-mail]>]

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
>