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

Gustavo García <> Wed, 26 June 2013 23:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C65E311E814C for <>; Wed, 26 Jun 2013 16:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iJH1cZa4CF4E for <>; Wed, 26 Jun 2013 16:30:10 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 1132211E8111 for <>; Wed, 26 Jun 2013 16:30:09 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Wed, 26 Jun 2013 16:30:10 PDT
Received: by with SMTP id v1so61975yhn.8 for <>; Wed, 26 Jun 2013 16:30:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=mJEjrKB9iI6NpKxx2T0+uHoguO7lHzRVlmY40IbIuNo=; b=J5RF3JEpxSVhhrtzUm1hzI4/eaaczow9wVCSTorZZwA5fWefW0+ocyUWZrciZd09ng x7WmaWI8TG2o1N/jos8H1tUyetyc21rJbZHHlvdFKITmA5qQx0na2OD85GcyVzI9ZXRt f+FD60TakBvw7X+mzQUWqfSzAbdx/pKpWNWQIlCunmah/qFWBkgVgZirml0OdXStpUYM acAOScZgy8r4tb8cVX5MK+PEwTaFsNRU+J64Lh7YyRTxCie8Pt0Mjb2aDkuTXB3GTEDD 978Oa2lTpINjFPrhNDeB8YcYmv1WmLrRtz5RKmZpZuR/g5E3UTF0XuwpS/1xi9uxUo5b 97aA==
X-Received: by with SMTP id j59mr3292457yhf.204.1372289404457; Wed, 26 Jun 2013 16:30:04 -0700 (PDT)
X-Received: by with SMTP id j59mr3292452yhf.204.1372289404360; Wed, 26 Jun 2013 16:30:04 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id v68sm228051yhn.22.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 16:30:03 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1283)
From: =?iso-8859-1?Q?Gustavo_Garc=EDa?= <>
In-Reply-To: <>
Date: Wed, 26 Jun 2013 19:29:59 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQmQ+3/bX7M0y0IsJa6HgZbkU2+ABhV8RhaTa2Y0EBp+YNxbDpU5PS5ElY3F7DFYHNfdG99ua+wvd0CzimDny1yTSYbvhlmpt2RUJgdes1hbdXbSlZslDSC52wfpuWLJV63dL8M5EyjA+hacudlZz6tebopLYQ==
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Jun 2013 23:30:14 -0000

"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.
- 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. 

In my opinion the only reasonable approaches are:
- Change the API now
- Change the API in one year

+1 to Iñaki's request too


On 18/06/2013, at 15:19, Matthew Jordan wrote:

> On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu <> 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: &
> _______________________________________________
> rtcweb mailing list