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

Iñaki Baz Castillo <> Wed, 19 June 2013 16:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4071521F9D88 for <>; Wed, 19 Jun 2013 09:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.659
X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qytM+P-lGxMB for <>; Wed, 19 Jun 2013 09:54:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 902EC21F9DAC for <>; Wed, 19 Jun 2013 09:54:30 -0700 (PDT)
Received: by with SMTP id s14so3445989qeb.29 for <>; Wed, 19 Jun 2013 09:54:30 -0700 (PDT)
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:content-transfer-encoding:x-gm-message-state; bh=98OoeDStPBtLcfUoXQtKkAPlzF/GWl7aj3sK7Ya8EhE=; b=Pk3H9BnqAbfAEFspkkIt5VjMhQ+w7IGdxW/65jSs8jgysYlmFUFO9/d2DdLQrS62a9 dwffv68UcSgWz705S6yEb9ZlpyyWq12LCm2R5zP3fVub0Uut1ItIiYFx22u1W2YJTBKo Mhg1t6eBeB8Ztnfuuo5LmfwoPRS2wZ2DSFTGcKZFCPaWybpZKAPHOFpLcigd5hrtoLR6 ND0i6y8knVsZ1NCCp41iuS1NURg/JwDrGxNafIwAGJj+Ik4u3sh04/8k0Hx/k57Oqkyb iyy2gcy4D7LWsThpZUOi4xRvkXjF9tiuH6gKdDxU2EgMS8jypz1o+kTV/nCbd3CFS/GO G2OA==
X-Received: by with SMTP id k7mr1437965qcv.129.1371660869967; Wed, 19 Jun 2013 09:54:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Jun 2013 09:54:09 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Iñaki Baz Castillo <>
Date: Wed, 19 Jun 2013 18:54:09 +0200
Message-ID: <>
To: Peter Thatcher <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkqbQc95vZIMMa1YkzEJIPrR1UhKh1AJaovYhBHhpaHXEHy4Dgnra31zIS94Zd7uGVrRGrP
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 16:54:55 -0000

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 ***


> The WG may dislike and reject your proposal

With all due respect,

And which proposal will the WG accept then? 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).

>> 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 JavaScript
> 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