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

Bernard Aboba <bernard_aboba@hotmail.com> Wed, 06 July 2011 06:06 UTC

Return-Path: <bernard_aboba@hotmail.com>
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 285FD21F8603 for <rtcweb@ietfa.amsl.com>; Tue, 5 Jul 2011 23:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZSks2REHwe3 for <rtcweb@ietfa.amsl.com>; Tue, 5 Jul 2011 23:06:54 -0700 (PDT)
Received: from blu0-omc3-s7.blu0.hotmail.com (blu0-omc3-s7.blu0.hotmail.com [65.55.116.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBD621F85EC for <rtcweb@ietf.org>; Tue, 5 Jul 2011 23:06:45 -0700 (PDT)
Received: from BLU152-W2 ([65.55.116.73]) by blu0-omc3-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jul 2011 23:06:45 -0700
Message-ID: <BLU152-w2EFC2C55649AF1665D96A935E0@phx.gbl>
Content-Type: multipart/alternative; boundary="_3c8c217e-a003-49e2-b30d-c5c717d4d46f_"
X-Originating-IP: [98.203.198.61]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: rtcweb@ietf.org
Date: Tue, 05 Jul 2011 23:06:44 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Jul 2011 06:06:45.0065 (UTC) FILETIME=[E214B390:01CC3BA2]
Subject: Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture
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, 06 Jul 2011 06:06:55 -0000

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. 

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