Re: [rtcweb] Low Level Javascript API Proposal avail on the webrtc list

Neil Stratford <> Wed, 05 October 2011 09:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E858321F8B73 for <>; Wed, 5 Oct 2011 02:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8urAcDMWUCaf for <>; Wed, 5 Oct 2011 02:49:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5246421F8B35 for <>; Wed, 5 Oct 2011 02:49:42 -0700 (PDT)
Received: by iaby26 with SMTP id y26so1990337iab.31 for <>; Wed, 05 Oct 2011 02:52:49 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id c17mr3906052ibf.87.1317808369576; Wed, 05 Oct 2011 02:52:49 -0700 (PDT)
Received: by with HTTP; Wed, 5 Oct 2011 02:52:49 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 05 Oct 2011 10:52:49 +0100
X-Google-Sender-Auth: YZYqYKZt2d-xgQ96_iWPMeuekts
Message-ID: <>
From: Neil Stratford <>
Content-Type: multipart/alternative; boundary="0015176f0b4cc02b5f04ae8a2b95"
Subject: Re: [rtcweb] Low Level Javascript API Proposal avail on the webrtc list
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, 05 Oct 2011 09:50:07 -0000

On Wed, Oct 5, 2011 at 10:31 AM, Iñaki Baz Castillo <> wrote:

> 2011/10/5 Matthew Kaufman <>:
> > This stuff is exactly what you'll need to add yet more code to solve if
> you
> > try to bake SDP offer-answer into the browser to turn it 90% of the way
> into
> > a SIP phone.
> >
> > And exactly what you *don't* need browser code to solve if it is done
> > elsewhere (for instance, the server might be handling the entire SIP and
> > exchange and resolve forking issues at that end without involving the
> client
> > at all.)
> No please. The client CAN be intelligent, and that is how SIP usually
> works (intelligence in endpoints rather than in servers).
> You can do that if you want (you can build a custom
> SIP<-->EasySimpleJsonProtocol gateway in server side), but please
> don't mandate it. Let me to deal with SDP's in client side (at
> JavaScript level), please. Others could choose what to do, but don't
> force me to create a ugly application protocol gateway just because
> some people prefer to make web clients as "simple as possible".

I don't think that anyone is saying that we want to mandate a simple Json
signalling protocol - just that you have the option of coding it all in
javascript at the client side, or at the server side if you wanted to. The
important thing in my view is not to bake SDP into the JS API with the
browser in such a way that we can only build something that looks like SIP.

By SDP 'client side at JavaScript level' are you proposing that the JS API
accepts SDP directly as a parameter, or that you parse the SDP in JS and set
the ICE connection and codecs up as appropriate? (Which is my preference.)