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

Bernard Aboba <bernard_aboba@hotmail.com> Thu, 07 July 2011 04:46 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 5B18821F87CB for <rtcweb@ietfa.amsl.com>; Wed, 6 Jul 2011 21:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.536
X-Spam-Level:
X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.062, 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 IfUNPjT0jStB for <rtcweb@ietfa.amsl.com>; Wed, 6 Jul 2011 21:46:18 -0700 (PDT)
Received: from blu0-omc4-s21.blu0.hotmail.com (blu0-omc4-s21.blu0.hotmail.com [65.55.111.160]) by ietfa.amsl.com (Postfix) with ESMTP id AA17B21F87C6 for <rtcweb@ietf.org>; Wed, 6 Jul 2011 21:46:18 -0700 (PDT)
Received: from BLU152-W17 ([65.55.111.137]) by blu0-omc4-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 21:46:17 -0700
Message-ID: <blu152-w1786E2C2CB4335F60B7F7D93410@phx.gbl>
Content-Type: multipart/alternative; boundary="_8672e6dc-4b4e-478c-8ff3-4ca1f309f3ef_"
X-Originating-IP: [98.203.198.61]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: fluffy@cisco.com
Date: Wed, 06 Jul 2011 21:46:17 -0700
Importance: Normal
In-Reply-To: <DFCE8D1D-AC5F-455A-B45D-C09DB6F7D5F8@cisco.com>
References: <BLU152-w2EFC2C55649AF1665D96A935E0@phx.gbl>, <DFCE8D1D-AC5F-455A-B45D-C09DB6F7D5F8@cisco.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Jul 2011 04:46:17.0997 (UTC) FILETIME=[CF5653D0:01CC3C60]
Cc: rtcweb@ietf.org
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: Thu, 07 Jul 2011 04:46:19 -0000

My understanding of the API is that the signalling callback is handed the SDP blob which includes ICE candidates gathered as directed, to manipulate and send as it pleases.  Once an answer is received it is passed down.  The spec is indeed vague on some points, but hey, that's what sample code is for : (

> Subject: Re: [rtcweb] Media neg-eo-tiation and signalling archa-tecture
> From: fluffy@cisco.com
> Date: Wed, 6 Jul 2011 21:43:25 -0600
> CC: rtcweb@ietf.org
> To: bernard_aboba@hotmail.com
> 
> 
> On Jul 6, 2011, at 12:06 AM, Bernard Aboba wrote:
> 
> > 
> > 
> > * 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.")
> 
> Hmm - my understanding was only the ICE related information was communicated that way and the SDP related information when across the channel set up by ICE but I could be totally wrong. It's pretty vague in the spec - I got that idea by talking to some of the people involved. Anyways, glad to retract that WhatWG is doing low path and just change it to not clear. 
> 
>