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

Peter Thatcher <pthatcher@google.com> Wed, 26 June 2013 23:46 UTC

Return-Path: <pthatcher@google.com>
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 8DD1A21F994A for <rtcweb@ietfa.amsl.com>; Wed, 26 Jun 2013 16:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level:
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
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 CWlLjB+6Ha9r for <rtcweb@ietfa.amsl.com>; Wed, 26 Jun 2013 16:46:41 -0700 (PDT)
Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD7221F93DA for <rtcweb@ietf.org>; Wed, 26 Jun 2013 16:46:41 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id t12so38661pdi.35 for <rtcweb@ietf.org>; Wed, 26 Jun 2013 16:46:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iRIlrRHselYUXxsPYW95U2iQ/3FbIbOBGiYxhf7Bur4=; b=RN5beGJK9lAg+X1Om2pdVIQUtOxHe5q1TZDWJmQY2UxdHHveuu2D1RgGyOfylIZf8S o7Ptl6yzlS01JH2FafWtSFzBFE7KtfpH9aousWWze4do5i7p9u4e717qUYzdbdWbFvH/ 7S7JzCCVNkFqrX+mnr81dK8+xY08XM6TWCKoQYRADOwQAR7eaW/CUwzI03yVaqpDwTjP izgraDOJD0fEF9i2vFfC7oJgdtON4Rc3vETbdiv1Tt7rvv2TnWjAWvSRun22xwBt8cPO ZOIrJ9Q5pE+rs4AfR+4tXunon2IxX1qBGNCizdr5g69442yja3RqDvsLJOEt8LZo5d0X r7wQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=iRIlrRHselYUXxsPYW95U2iQ/3FbIbOBGiYxhf7Bur4=; b=SCj6mNHNpJALWUGO2V8dQS+wtlFWASLpdP51T6Gt5jOtNyVbx+xA4mqLm+OrK/GDhQ cwOiT+KrRfrCQKGJ4MGq790zZT2kLNfAoSljXfY8O2uB/mOnEHJumYgGYt0c53SBa31P netrcDzXyjoPyXxHBuWoU9IJbiSjd4VJJKq5mVn+lIe7A6u5dnnrCs3bihSJeWdFvo29 xELG/Zyvl0GRwSYxXw0MJGXiZi/B1+AQyyE6UW+G4D+w1yadh2ZZxPQR8li5nwKfIz1E 57YFDlyb9/1RhnZFlBgg0edfZtTHN9Z4SAcY9HtV4fXpOJMT2Q3ChHmAlBzbzlX9tKs5 tqfA==
X-Received: by 10.66.246.194 with SMTP id xy2mr3121888pac.131.1372290400712; Wed, 26 Jun 2013 16:46:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.216.163 with HTTP; Wed, 26 Jun 2013 16:46:00 -0700 (PDT)
In-Reply-To: <782A8339-9A9D-49AE-85E6-9FAD55436807@tokbox.com>
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>
From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 26 Jun 2013 16:46:00 -0700
Message-ID: <CAJrXDUFGj0hU1gHptFkPMCUu_idCxh8uyJ2=67g-P8a9DHD1Cw@mail.gmail.com>
To: =?UTF-8?Q?Gustavo_Garc=C3=ADa?= <ggb@tokbox.com>
Content-Type: multipart/alternative; boundary=047d7b15ae49dd1c9e04e01741a4
X-Gm-Message-State: ALoCoQmIelsO/5HlVO/naK5XOgTeQdfTZpUTjD77ooI+bYg2+SkpLDlUjTffc2S35L+oY2OAeJXZGbsfMwJf4D3i8Q6szlyjsT+aYEq1dThtEGwiTHFSqZP/V4NjEL4UY/iBb3Mcku438O4nLFs8WQQBU55QTwCFyXwk1f4ZoR2U5bt9IUB5jiJZ6PlRsHPSXQxstHEpvChz
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
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:46:51 -0000

On Wed, Jun 26, 2013 at 4:29 PM, Gustavo García <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>;
> 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
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>