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

Gustavo Garcia Bernardo <ggb@tid.es> Wed, 26 June 2013 23:58 UTC

Return-Path: <ggb@tid.es>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD8A21F9A5C for <rtcweb@ietfa.amsl.com>; Wed, 26 Jun 2013 16:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gv+kb2igJyy for <rtcweb@ietfa.amsl.com>; Wed, 26 Jun 2013 16:58:38 -0700 (PDT)
Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id D2A4121F9A52 for <rtcweb@ietf.org>; Wed, 26 Jun 2013 16:58:36 -0700 (PDT)
Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MP000C5EYLN16@tid.hi.inet> for rtcweb@ietf.org; Thu, 27 Jun 2013 01:58:35 +0200 (MEST)
Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id F2.21.02911.B208BC15; Thu, 27 Jun 2013 01:58:35 +0200 (CEST)
Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MP000C59YLM16@tid.hi.inet> for rtcweb@ietf.org; Thu, 27 Jun 2013 01:58:35 +0200 (MEST)
Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Thu, 27 Jun 2013 01:57:31 +0200
Date: Wed, 26 Jun 2013 23:57:31 +0000
From: Gustavo Garcia Bernardo <ggb@tid.es>
In-reply-to: <CAJrXDUFGj0hU1gHptFkPMCUu_idCxh8uyJ2=67g-P8a9DHD1Cw@mail.gmail.com>
To: "pthatcher@google.com" <pthatcher@google.com>, "ggb@tokbox.com" <ggb@tokbox.com>
Message-id: <6dylyuxdj0v9xctq6nv1tpyy.1372290845930@email.android.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_V6ZZJSgIEjy7/9AQ98vLpg)"
Content-language: en-US
Accept-Language: en-US, es-ES
Thread-topic: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
Thread-index: AQHObFEKDQ1B0y4wlEq3/uPYuSNPJJk7t0YAgAzYtoCAAAR6AIAAJQrQ
X-AuditID: 0a5f4e69-b7f118e000000b5f-09-51cb802bc4dd
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42Lhivcz1NVuOB1o8PWIiMXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKWHvUqeBIdsWMNXtZGhifR3QxcnBICJhING5j72LkBDLFJC7c W8/WxcjFISSwnVFiz5HFUM4vRol7rQcZIZxpjBKvrk9kBWlhEVCVeNhzG6ydTUBL4l/vNRYQ W1jAQ6Jz4UVmEJtTIFhi3e5XbCC2iECYxP39j8HizALqEksnN4DFhQT0JO7cmwI2k1fATeLB 2/dQtqDEj8n3WCDqsyQWdt1jg7DFJZpbb4LFGQVkJd7Nn88KMd9T4mTLA0YI201i9o4nzBCv CUgs2XMeyhaVePn4HyvEM5OZJba1TGOcwCg2C8m+WUj2zUKyD8LWk7gxdQpUXFti2cLXzBC2 rsSMf4dYkMUXMLKvYhQrTirKTM8oyU3MzEk3MNLLyNTLzEst2cQIibvMHYzLd6ocYhTgYFTi 4f3AeDpQiDWxrLgy9xCjBAezkghvaA5QiDclsbIqtSg/vqg0J7X4ECMTB6dUA6NsYYx+ee7V 49b758qvb323kM/851y+jnrDQzsmOqp8+/sw5sShCMbFxi+P/Vx9VD/YccWzqnP+SpZe+tZ7 utvvxFz8xbF7769MH+2EbX0K+YoXVM5d235n/yPpZ40FT9Zn9CXNusFqpl0R21b47c3fHZ9L Xt1zMe2WlTbJZZ/EzqOVKjytzlCJpTgj0VCLuag4EQDAWifMmQIAAA==
References: <5158F0FC.3070104@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02B56F@FR711WXCHMBA02.zeu.alcatel-lucent.com> <5165CF9D.6030302@jesup.org> <FC4978CB-360E-4F47-9A31-941121589E8A@ag-projects.com> <CAN2PU+4MWZQSY=VVwNpyjEnV3aHB1zLgwuRyOYiOm_nTcEL6ZQ@mail.gmail.com> <782A8339-9A9D-49AE-85E6-9FAD55436807@tokbox.com> <CAJrXDUFGj0hU1gHptFkPMCUu_idCxh8uyJ2=67g-P8a9DHD1Cw@mail.gmail.com>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Gustavo Garcia Bernardo <ggb@tid.es>
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2013 23:58:46 -0000

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.

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.


Sent from mobile

Peter Thatcher <pthatcher@google.com>; wrote:

On Wed, Jun 26, 2013 at 4:29 PM, Gustavo García <ggb@tokbox.com<mailto:ggb@tokbox.com>> 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 <ag@ag-projects.com<mailto:ag@ag-projects.com>> 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
> rtcweb@ietf.org<mailto:rtcweb@ietf.org>
> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
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