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

Peter Thatcher <> Wed, 19 June 2013 17:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5677521F9E2C for <>; Wed, 19 Jun 2013 10:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.741
X-Spam-Status: No, score=-1.741 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nRGB6BLnuY2I for <>; Wed, 19 Jun 2013 10:30:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::231]) by (Postfix) with ESMTP id 180D621F9E33 for <>; Wed, 19 Jun 2013 10:30:07 -0700 (PDT)
Received: by with SMTP id ld11so5411374pab.36 for <>; Wed, 19 Jun 2013 10:30:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TcfpJcw9leA9sPWv4ux6ZnDqC7V+4ch8GIOyLW+0a40=; b=Uyz7XCS5WbPnJgsyMQOCw8dEldm6FGHQpHX4dehUQKUToKXEkuIg3XceScKZolPR9x dpY5XYgmat9KTtek7Q1WmSVy7eUef/4i390CLr0rCQPeO3gxir73UDR1ejEvqd1hmEEY K6Ch6Cq1fwWcegZmlJTfb52csYoC1f4MxQCPboYfBS3lvmQchvmvHBTJ6JZPKHaR88PA vL2RqzqhfQOTBVtd0h8U2eaS4SzjYHSNll3nuIdKVKWY5EROBFWkjYpQtqEk+JANBxiU QOU5MqMd9iv+v7xUjECirLXQnTvgnA8VeUGsVd0q2qnxDoO1GA24ZaVKyuk5veeErDvQ GOfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=TcfpJcw9leA9sPWv4ux6ZnDqC7V+4ch8GIOyLW+0a40=; b=aMYDBbtw9NQqbGgR9+58JW42nse14hVfnxEnZZZ3FOLMr6o/czM23ni8ooqrQorAI4 mTmbNkyixmdJlWmcfIqT8ZRDiJu3SFFiOq6kCVyG8NdKpo4OU2XarUi29sWqJw/B9r2F ZmMwrWNDkoFIitEMbpuaQCs7bsrBuWvZjbMSfTSfjUoYPs5xfXlGxKC55++ZwZhXyQbT IsoUKAE0RmoGjwjP40cVTuu6UdU1lDnV/uMro1PDMSCgXFZa06j1eXMUI+TKcWbwlw2n VdQAJuZ8z6g4PJ774AIYrOXBuFMhh+3U6U2dmxPqx1FBHInRzeN40WAQaQT5BHK4I7mE YOoA==
X-Received: by with SMTP id nv7mr3890458pbc.70.1371663007723; Wed, 19 Jun 2013 10:30:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Jun 2013 10:29:26 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Peter Thatcher <>
Date: Wed, 19 Jun 2013 10:29:26 -0700
Message-ID: <>
To: Iñaki Baz Castillo <>
Content-Type: multipart/alternative; boundary="e89a8f923c7a53d25b04df852ee0"
X-Gm-Message-State: ALoCoQlYT5FJanOcEdOuUbxMA8/M5xv0zT+AFIBZMX6K2wqj9PUnCbjq8d4JVUgIMLoOvZ/LokuYugnR8j62FCEJUNjTb4Jo/t/CMNLysaHNoSVrdysuSO0qAwdrGRTbyxzHxWButnhfMUkz+aQLFp6n+B1snJ12u67bdhnr9LGumvcqH97E2CQfrYk8TG1RxBAQ6kp9mJiT
Cc: "" <>
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, 19 Jun 2013 17:30:12 -0000

On Wed, Jun 19, 2013 at 9:54 AM, Iñaki Baz Castillo <> wrote:

> 2013/6/19 Peter Thatcher <>
> >>
> >> The summary of what I want/believe:
> >> 1) I want as close to raw access to RTP/ICE streams, media, sources,
> outputs, codecs as viable. Obviously doing the actual transmission,
> encoding/decoding from JS is not feasible (yet), nor is secure [ICE must
> occur for mutual agreement to exchange data between peers], but having
> controls for how these components are wired together is extremely feasible
> from JS and would allow immensely powerful apps to be produced from JS.
> >
> >
> > What would you like to do that you can't do via SDP right now?  You said
> this isn't just about working through SDP.  But I don't see anything
> concrete you can't do right now with sufficient SDP
> parsing/building/munging/hackery.
> If the "solution" with the current API/model is "SDP
> parsing/building/munging/hackery" then let me strongly say that:
> *** I don't want SDP ***
> :)

It may be helpful to respond to your original request to the WG chairs with
something a little more clear, specific, concise, and actionable then your
original email.  I know many people reading this thread will just think
"what's this?  Oh, just more SDP ranting" and it will fall on deaf ears.

Also, explaining your use case and specific pain points may be helpful.

> >
> > The WG may dislike and reject your proposal
> With all due respect,
> And which proposal will the WG accept then?

I don't know.  Perhaps none of them.  It's possible we'll be stuck with SDP
munging forever.

But I think you'll maximize your chances of success by being clear with
what you need, propose digestible solutions, avoid being ranty, and not try
to blow it all up and start from scratch.  But I could be wrong.  Maybe
there's a better way.

> It's frustrating IMHO that
> we still have no pro-SDP arguments in this long thread and still must
> accept that the SDP model would be the chosen one. Does the silence
> strategy mean "SDP usage was already voted two years ago, ignore
> current complains"? That could be a good argument if during the last
> TWO years we had *something* really good and usable based on the SDP
> model, but we don't have that. Instead we have tons of drafts and
> alternatives to make SDP fulfil WebRTC requirements, and none of them
> is good.

> IMHO current complains are based on the *experience* of the people
> trying to make the SDP model work in WebRTC, including people that
> were in favour of SDP two years ago and now have changed their mind
> (like me).

It may help you to understand this from the other side's perspective.  Many
people in the WG like SDP and want to use SDP for everything and don't want
to change SDP much, if at all.   And when someone comes through ranting
about SDP, they don't find that persuasive.

If there's new information gained in the last two years that might be
persuasive, present that.  But try to do it in clear, concise, way that
says "here's what I'm trying to do", "here's my experience", "here's my
pain", "here's how I think we can fix it".  That might be a lot more
persuasive.  Then again, it might now;  who knows? :)

>> Anyone who argues that they need/want that simple SDP media negotiation
API must understand that a lower level API would allow a wrapper API to
produce the same WebRTC API the have today but be built entirely from
> That depends on how low-level you go.  If you go too low-level, it
becomes infeasible to do things correctly and performantly in JavaScript.

There are tons of bug in current WebRTC implementations. Yes, there
will be also bugs in future JS libraries dealing with WebRTC internals
(those we propose), but they can be potentially fixed without
requiring upgrading the browser, and without waiting for all the
browser vendors to fix/implement them.

And with all due respect, I don't agree at all with the "JavaScript
performance issue" that worries you, but I think that it is not up to
me to prove that a problem does not exist ;)

Best regards.

Iñaki Baz Castillo