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

Roman Shpount <> Wed, 05 October 2011 03:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C279221F8B95 for <>; Tue, 4 Oct 2011 20:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.626
X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.350, 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 sm7pi6EscfAD for <>; Tue, 4 Oct 2011 20:16:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B601A21F8B88 for <>; Tue, 4 Oct 2011 20:16:23 -0700 (PDT)
Received: by gyd12 with SMTP id 12so1390969gyd.31 for <>; Tue, 04 Oct 2011 20:19:30 -0700 (PDT)
Received: by with SMTP id 4mr14574659pba.23.1317784769712; Tue, 04 Oct 2011 20:19:29 -0700 (PDT)
Received: from ( []) by with ESMTPS id ki1sm2563296pbb.3.2011. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 20:19:29 -0700 (PDT)
Received: by pzk37 with SMTP id 37so3084957pzk.9 for <>; Tue, 04 Oct 2011 20:19:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id r2mr13538893pbi.71.1317784768332; Tue, 04 Oct 2011 20:19:28 -0700 (PDT)
Received: by with HTTP; Tue, 4 Oct 2011 20:19:28 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Tue, 04 Oct 2011 23:19:28 -0400
Message-ID: <>
From: Roman Shpount <>
To: Matthew Kaufman <>
Content-Type: multipart/alternative; boundary="bcaec520f61101c4fe04ae84ad9f"
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 03:16:29 -0000

On Tue, Oct 4, 2011 at 10:29 PM, 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 SDP
> exchange and resolve forking issues at that end without involving the client
> at all.)

Let me rephrase my questions:

3. If I generate an offer using this API and then send it to the web server,
which will deal with SIP end of things, and will get multiple answers in the
same dialog, how do I process those answers via this API? What I need is an
ability to provide an answer update to the connection. Should I just remove
old streams and candidates and add a new ones?

4. Same thing with an offer that created multiple dialogs. I want to clone
the connection and add streams and candidates to it. I don't think this is
possible with the current API.

Few new questions:

5. What is the priority order for generating candidates when multiple
STUN/TURN servers are specified? How would this be affected if we also have
proxies? I am not sure this is part of any specification so far and probably
should be part of RTC spec defined by IETF

6. How do we deal with CODEC negotiated parameters? It is possible to have
codec level parameter that needs to be negotiated via offer/answer exchange.
There are also codec level parameters that are affected by stream level
parameters (like iLBC mode=30 that only makes sense with ptime dividable by
30). Is it going to be implemented in JavaScript? This might not be the best
idea, since this will require JavaScript to have a detailed knowledge about
each codec implementation provided by the browser. For third party call
control, it would be more robust to provide a way to return actual codec
parameters selected by the browser so that they can be returned in the
Roman Shpount