Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture

Stefan Håkansson LK <> Wed, 06 July 2011 06:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE14121F8504 for <>; Tue, 5 Jul 2011 23:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.196
X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KVZPRzgq3PbA for <>; Tue, 5 Jul 2011 23:21:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E970F21F84FD for <>; Tue, 5 Jul 2011 23:21:11 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-41-4e13fed61d48
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 70.08.20773.6DEF31E4; Wed, 6 Jul 2011 08:21:11 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 6 Jul 2011 08:21:10 +0200
Message-ID: <>
Date: Wed, 06 Jul 2011 08:21:07 +0200
From: Stefan Håkansson LK <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
References: <BLU152-w2EFC2C55649AF1665D96A935E0@phx.gbl>
In-Reply-To: <BLU152-w2EFC2C55649AF1665D96A935E0@phx.gbl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture
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, 06 Jul 2011 06:21:12 -0000

On 2011-07-06 08:06, Bernard Aboba wrote:
> Stefan said:
> A couple of quick comments:
> * The last slide now says that WhatWG proposal is low path; this is not true. The WhatWG proposal as I read it is mute on how the SDPs are exchanged, it just hands those SDPs over to the
> application (though high path is indicated: "Communications are coordinated via a signaling channel provided by script in the page via the server, e.g. using XMLHttpRequest.")
> * Notably the WhatWG PeerConnection API does allow both high path and low path. You can exchange all the SDPs over the server as the spec indicates, but if your application
> initially only sets up a PeerConnection with no media Streams, there will be a peer-to-peer datagram channel available. It can be used by the web app to exchange the SDPs
> for media negotiation when you add Streams (then we have a separate thread on that datagram channel - is it reliable or not - or would the app have to add reliability)
> * Even if you use the low path approach you still need a high path available all the time. It is needed to exchange candidates so that ICE can be used to open the low path -
> and this would have to be done at the start of the session and every time you do a NIC change (a use case you added BTW!)
> Stefan
> [BA] I agree that the WhatWG proposal is not inherently low, medium or high path.   The signalling mechanism is totally up to the signalling callback function.
> I did have a question about how the PeerConnection API manages the gathering of the ICE candidates, though.  It was my (naive?) assumption that beyond the host candidates (always included?),
> the other gathered candidates would based based on the Type information passed (e.g. STUN/STUNS, TURN/TURNS).   If the SDP Blob is not considered "opaque" the signalling
> callback could manipulate/change it, to affect the  subsequent ICE processing.  The peer could do the same thing on its end.  If this were true (is it?) then that would allow quite a bit
> of flexibility.
[SH] I have the same understanding.
> I was also a bit uncertain about the precise timing of when ICE connectivity checks are kicked off within the API, and how things like a NIC change are handled.   For example, is it
> envisaged that it would be possible to implement RTCWEB mobility (e.g. handoff of media between interfaces)?
[SH] I think that is the assumption. Quote from the API spec "...any 
time the network topology changes and the ICE Agent performs an ICE