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

Alexandre GOUAILLARD <> Mon, 01 July 2013 01:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8EB7E21F9ED1 for <>; Sun, 30 Jun 2013 18:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wtFnEDgf1CsZ for <>; Sun, 30 Jun 2013 18:53:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c02::229]) by (Postfix) with ESMTP id 8B30821F9EC6 for <>; Sun, 30 Jun 2013 18:53:00 -0700 (PDT)
Received: by with SMTP id n10so4277134oag.28 for <>; Sun, 30 Jun 2013 18:52:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=p+AIdQ384hP80aehpKRAzYPEThXiEM4uA1WmhIjWsTY=; b=iQGevU5OySPWpKQxeBwByohwmo2HInFwzIxsaU2WLy87aby++U+RXzCUaSduceqMlV 4hMU7YOqtGRpWt8usBhkHwZpc7haYrPKcsxy9o1zfKB43IG4nxXnrhY4k3JlFW0y/iyD nJyxNpSbS8qg8byoGBO7tvgzJfDcfoqVGMuBNVyaT4+m3KO5PmL5ybnNuDRdo3/Avbqc W8jvjq2ryjnCN8/L3apgLZk6RQW5oYSM3niU4TFpLx3v1JbktqCw4Ie28WfkCekj5k1j PT5a2TDQyKswtqBsUQ1/nZVT/h5zRDFyF2Cu9p3VrrwTL3PRL9lQ3Xm4ivy1ShoU9z/6 W2nQ==
MIME-Version: 1.0
X-Received: by with SMTP id n5mr9597690obx.88.1372643578942; Sun, 30 Jun 2013 18:52:58 -0700 (PDT)
Received: by with HTTP; Sun, 30 Jun 2013 18:52:58 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Mon, 1 Jul 2013 09:52:58 +0800
Message-ID: <>
From: Alexandre GOUAILLARD <>
To: "" <>
Content-Type: multipart/alternative; boundary=047d7b2e4146ed20fb04e0697cb9
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: Mon, 01 Jul 2013 01:53:02 -0000

dear all,

I will speak for the first time on this thread, so I guess I belong to that
silent majority. I will make some candid comments here, hoping this help.
This is *NOT* a call for more flame wars, far from it.

The reasons why it took me so long to write here are manifold. In order:
1. The repeated shocks coming from non-constructive posts (understatement
of the century), which make me feel like putting on my anti-riot
protection, hide behind a virtual pillar not to take a lost bullet or die
under friendly fire. (sometimes make me feel like being back in
junior-high, which is just a slight variation of the previous feeling).
2. the time needed to find, read and digest all the RFC / proposals and to
start getting the big picture.
3. the fact that it is difficult to articulate the pain points not knowing
what is supposed to be difficult, and what is difficult because of wrong
design. Coming from another field, and having a hacker mentality,
everything is equally new and challenging, and our team just went ahead and
find solutions. Being able to separate what is challenging because it's new
and what is challenging because it shouldn't be done  that way is hard at
best without the right background and the global picture in mind. That is
slowly changing.
4. I don't have a proposal to make it better at this stage.
5. webrct world is developing fast and we need to stay in the race,
allocating most of our time to development, and maybe not enough to the
standard part (our mistake). That is changing too.

ok, that might have helped to answer the why people are silent, but not
what should be done next. Here are a few more details.

1. we don't want to see webrtc being slow down. We would vote against
anything that bring us back to zero like a complete rewrite. We would favor
transition plans.
2. today, we manipulate SDP for the following things:
  - bandwidth limitation, as a temporary work around while corresponding
constraints are not honored.
  - codec order
  - ICE candidate priority
3. We are available to give comment on other people proposal (if most of
bitterness and non-constructive "I told you so", "i m not going to write a
draft for something that should already be there", "feel free to wait until
the end for my official rebuttal, so everybody will have lost their time"
messages are left at the door), and spend some time testing, but it's very
likely that we will *NOT* make a proposal ourselves.
4. We like the *concept* of separating functions/features in the peer
connection, and we are interested in the way datachannels are set up, *but*
we haven't took the time to dig into it enough. Now webrct expo in atlanta
is over, this should change, hence this e-mail.



On Thu, Jun 27, 2013 at 11:05 AM, Marc Abrams <> wrote:

> It’s pretty telling when you have Digium and others making statements like
> “...that relying on SDP hasn't been a panacea for interoperability, “ or
> “... [they would] rather write an entirely new channel driver for Asterisk
> than have to re-write [their] SDP handling, “ you know that it’s not “just”
> an SDB Rebellion. It’s a problem. And waving your hands and claiming it’s
> necessary does not make SDP the solution.
> We should punt on SDP for v1.0 and move on.
> Thanks.
> marc.
> __________________
> +1-949-270-0935
> On Jun 26, 2013, at 5:12 PM, Peter Thatcher <> wrote:
> On Wed, Jun 26, 2013 at 4:57 PM, Gustavo Garcia Bernardo <>
> wrote:
>> 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.
> Even the "SDP rebellion" aside (by the way, you guys need some Star Wars
> jokes), it would very useful to have a good idea of who is working on what
> and how well the API is working for them, and what things could be added or
> changed to help.   Most of the WG does seem to have any real experience
> actually using the API, and I think that limits are ability to design the
> right API.  More input from people actually using the API could only help,
> and I look forward to hearing more.
> 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.
> I apologize if I missed the link to your prototype.  I'd like to see it.
>  Can you repost the link?
>> Sent from mobile
>> Peter Thatcher <> wrote:
>> On Wed, Jun 26, 2013 at 4:29 PM, Gustavo García <> 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 <>
>>> 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
>>> >
>>> >
>>> _______________________________________________
>>> rtcweb mailing list
>> ------------------------------
>> 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:
> _______________________________________________
> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list