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: Gustavo García <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 >
- [rtcweb] DataChannels API and external negotiation Randell Jesup
- Re: [rtcweb] DataChannels API and external negoti… Michael Tuexen
- Re: [rtcweb] DataChannels API and external negoti… piranna@gmail.com
- Re: [rtcweb] DataChannels API and external negoti… piranna@gmail.com
- Re: [rtcweb] DataChannels API and external negoti… Martin Thomson
- Re: [rtcweb] DataChannels API and external negoti… Randell Jesup
- Re: [rtcweb] DataChannels API and external negoti… Martin Thomson
- Re: [rtcweb] DataChannels API and external negoti… Peter Thatcher
- Re: [rtcweb] DataChannels API and external negoti… Randell Jesup
- Re: [rtcweb] DataChannels API and external negoti… Randell Jesup
- Re: [rtcweb] DataChannels API and external negoti… Michael Tuexen
- Re: [rtcweb] DataChannels API and external negoti… piranna@gmail.com
- Re: [rtcweb] DataChannels API and external negoti… Peter Thatcher
- Re: [rtcweb] DataChannels API and external negoti… MARCON, JEROME (JEROME)
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Adrian Georgescu
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Matthew Jordan
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Martin Thomson
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Gustavo Garcia Bernardo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Gustavo García
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Martin Thomson
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Marc Abrams
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Alexandre GOUAILLARD