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

Matthew Kaufman <matthew.kaufman@skype.net> Wed, 05 October 2011 04:23 UTC

Return-Path: <matthew.kaufman@skype.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800B121F8B9E for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 21:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.795
X-Spam-Level:
X-Spam-Status: No, score=-5.795 tagged_above=-999 required=5 tests=[AWL=0.803, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po2bKoPDnnfh for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 21:23:41 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2917D21F8B90 for <rtcweb@ietf.org>; Tue, 4 Oct 2011 21:23:41 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 72A0716F6; Wed, 5 Oct 2011 06:26:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to: content-type; s=mx; bh=N1feImp1//qiieIztYhcxkkCB4Q=; b=TEW7I4cwD yeetRitWaEXLFLbZD8U1Q1ufYNy6sj1x9rVN94VpjYFWmPZShFNdltp++RWZ4jJV 61OGkhekoK4AYgVyh1/22tiWCMh6xDW4SyHbsf1wwliznAsnj7mCide9MuHHQfE8 z+Qe1ukJufZkPuRNMuWRBBPfId9WFq8f78=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type; q=dns; s=mx; b=j2rxQsqOggC7HudPF9lCawvJCILwQ63c5Cqg6vD3eQIRZAX2 PAvoJUX5txXKpCUFKoP709NOGdndjBcn8VyZ/8IXcRCbfqaCxcnWdBOq9eQToTHR 2nYGCE7cPzsFMBd0wPo2p+cMiNwSyARC0OO+xM50C+BST/QxFkWPmYjbbJs=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 680157FC; Wed, 5 Oct 2011 06:26:47 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 443B635071FA; Wed, 5 Oct 2011 06:26:47 +0200 (CEST)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpHXeBcdqibC; Wed, 5 Oct 2011 06:26:46 +0200 (CEST)
Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 617273506EF4; Wed, 5 Oct 2011 06:26:45 +0200 (CEST)
Message-ID: <4E8BDC3B.7000501@skype.net>
Date: Tue, 04 Oct 2011 21:25:31 -0700
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Roman Shpount <roman@telurix.com>
References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <CAD5OKxt_3bnODVCWxrrrKVWO3R3Or1FjhMOHwgUzq3-h6dW0LA@mail.gmail.com> <4E8BC0ED.2020001@skype.net> <CAD5OKxv_xO0y+71X6ag-2te6TTey4Z77ezvBuYwS89022rL1hQ@mail.gmail.com>
In-Reply-To: <CAD5OKxv_xO0y+71X6ag-2te6TTey4Z77ezvBuYwS89022rL1hQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------020408080909010904050704"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Low Level Javascript API Proposal avail on the webrtc list
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2011 04:23:42 -0000

On 10/4/2011 8:19 PM, Roman Shpount wrote:
>
>
> On Tue, Oct 4, 2011 at 10:29 PM, Matthew Kaufman 
> <matthew.kaufman@skype.net <mailto:matthew.kaufman@skype.net>> wrote:
>
>
>     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?

How about I rephrase?

If I generate an offer by writing SDP code in C++ using Win32 APIs to 
allocate sockets and send and receive packets, and I send a SIP packet 
that gets multiple answers in the same dialog, how do I process those 
answers using the Win32 API? See how silly that sounds?

Seriously though, if you need an additional local endpoint because of 
forking, you need to create a second connection object, which will then 
give you an onCandidates() callback, as I understand this API proposal. 
The other way to do it is to have the connection object be able to bind 
to multiple possible far endpoints, but that's not exactly what this API 
says, and it isn't clear that it is needed. (Because it isn't how other 
SIP devices use their network stacks to solve this problem either).

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

I don't see why you can't create a second connection object (or extend 
this API to allow cloning), and add streams and candidates to that 
connection object. Should be possible to add the same stream to two 
different connection objects, too.

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

Lots of ways to handle this... but yes, the current version of this 
proposed specification doesn't expose any sort of prioritization.
>
> 6. How do we deal with CODEC negotiated parameters? 

I believe that the codec parameters are exposed by the codec object, at 
least that's how I read this spec.

> It is possible to have codec level parameter that needs to be 
> negotiated via offer/answer exchange.

Maybe. Or maybe there's an offer-answer at the server that picks the 
right answer and then sends that down as a setting to the browser.

> 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).

That's just a bug with how RTP works.

> Is it going to be implemented in JavaScript?

I suppose it might need to be, if you really need to select 
connection-level things to match codec-level things and vice versa. Or 
control it up at the server and then send the right settings down.

> 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 answer.

Except that we often don't want the codec parameters to be "selected by 
the browser". We want to know what the browser can do and just set them 
a particular way.

I've already suggested that the format of the "detailed knowledge" can 
actually just reuse the parameter strings that are already defined for 
use in SDP.

Matthew Kaufman