Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

Iñaki Baz Castillo <> Tue, 09 July 2013 10:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5260621F9FC8 for <>; Tue, 9 Jul 2013 03:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.647
X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, 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 NQi6KaT7cnX1 for <>; Tue, 9 Jul 2013 03:09:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 09B0D21F9FA4 for <>; Tue, 9 Jul 2013 03:09:38 -0700 (PDT)
Received: by with SMTP id hu16so2789499qab.8 for <>; Tue, 09 Jul 2013 03:09:37 -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=Pzd2FV/Sn5ZS+vmvvH8A59pG9RzPN62vF0bqvXma4R8=; b=behGv1IIQE3W3E1SDkaz0O3NyeziLeremPflI+cL0HW0YUZQsjFg3JNwVL4QEjDRQi eGlfoIb+zTCBZdcE+3/2xJI0oUNrj1dxyn58rZjbb2x+b7osLDc0i6enR1dRWUgdyzW/ iFgBa0RSvOcxGoNBNpGC0ULlOZC1nF6+SNH94PnepK/M/6IkObpOoDUxXpaP2Py2IIo4 wYyKGYdMgtQGeZmjPP8pGyNjF4rgKebsVf1FBbgrrJXKnASEaFi13pA2PkBGlX/pbP+c tCOFHTHgTdZj1PhHBP/VrTpwaQd24mO9kZJIXahsxDEkaG7Q5UiLQvlXo8zg17WmLdM+ AdKQ==
X-Received: by with SMTP id f15mr7749629qaq.115.1373364577481; Tue, 09 Jul 2013 03:09:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 9 Jul 2013 03:09:17 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Iñaki Baz Castillo <>
Date: Tue, 09 Jul 2013 12:09:17 +0200
Message-ID: <>
To: Silvia Pfeiffer <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQk9L19kHnJWTNaCd+HlbSA8VkftvuIIIyfqAOaQmS58HOITKwxQoj/gUqTGGgUuA7G+CW7I
Cc: "<>" <>
Subject: Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface
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: Tue, 09 Jul 2013 10:09:44 -0000

2013/7/9 Silvia Pfeiffer <>:
> I think there are two groups objecting and there are two things to
> object against.
> Here's what I'm reading...
> Web Developers really just want to be given functionality. They can
> build their own nice API on top of what browsers implement (jquery did
> a marvellous job of that). But they want functionality. Seeing as some
> things are not currently possible with SDP and O/A, they either want
> to extend those to allow their functionality, or - in particular where
> SDP & O/A are overkill - want an option to get out of using SDP & O/A
> and use something else.
> Telco engineers want their existing devices to be interoperable with
> browsers as well as the ability to develop new devices in the future
> with extended functionality. So, on behalf of the first goal, they
> object to including functionality into SDP that other devices don't
> already support, and on behalf of the second goal, they are torn
> between extending SDP & O/A and starting new.

Hi Silvia,

Another important point is that many of those telco engineers have
clearly recognized that they don't know Web, nor JS, nor designing JS
APIs for the Web, and that they just want WebRTC to be compatible with
their current business (literally: "I want browsers to be compatible
with SIP").

For example, two years ago the initial proposal by many of those telco
engineers was "allow plain RTP and mandate SIP as in-the-wire protocol
for WebRTC" (this is true). I also remember that somebody proposed
that the browser should include a "call history" panel, which clearly
shows a limited and wrong WWW vision.

They strongly think that by mandating SDP O/A they are done and have
accomplished their job in this WG on behalf of their big companies
(those that have never succeeded in the WWW). And of course, they are
much more used to IETF processes than Web guys (is Facebook
represented in this WG?), thus the only argument they expose
*nowadays* is: "SDP mandate was talked about and agreed two years ago
in a meeting full of telco engineers".

And then, the current spec is basically an opaque and unmanageable SDP
blob generated by the browser that must be sent by the JS to the peer.
The same "logic" within a phone. But here is the problem: a web
application is all but **fixed** code and **fixed** logic. Don't kill
the Web.

> I certainly want a simple API, but I am not sure whether what we
> currently have is already the simplest possible (given current
> circumstances),

What we have now is not a real API.

> nor am I sure whether it wouldn't just be possible to
> build a simple one on top the jquery way, which would be sufficient
> for now.

An API should be good enough to not require an extra layer on top of
it to make it feasible for developers.

As developer in JsSIP project I must say that we have properly
implemented SIP pure protocol on top of JS and WebSocket, no problems
at all (regardless how complex SIP becomes sometimes). The only real
problem we have if related to WebRTC "API". Tons of hours dealing with
unexpected/wrong specifications and behaviors (and yes, SDP blob
hackery). We would be very happy if we could generate our *own* SDP
with JS (which means we need to retrieve *real* JS Objects from the
WebRTC stack rather than an opaque SDP blob). And telcos, ey!!!, we
are doing SIP even much more than you !!! believe us !!!

Best regards.

Iñaki Baz Castillo