Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion

Harald Alvestrand <harald@alvestrand.no> Thu, 20 October 2011 17:54 UTC

Return-Path: <harald@alvestrand.no>
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 6487A21F8BBB for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 10:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 dLZWIAjR81t1 for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 10:54:06 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 371BD21F8BB6 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 10:54:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8457B39E16F for <rtcweb@ietf.org>; Thu, 20 Oct 2011 19:54:05 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIEvf2NnSTQj for <rtcweb@ietf.org>; Thu, 20 Oct 2011 19:54:04 +0200 (CEST)
Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id B5DC839E072 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 19:54:04 +0200 (CEST)
Message-ID: <4EA0603C.7050304@alvestrand.no>
Date: Thu, 20 Oct 2011 19:54:04 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CA+9kkMBQDne_p7LmH_e38NQWqjjNh0jKjuLMZrtNh10db90hYg@mail.gmail.com> <4E9E9794.8000901@alvestrand.no> <4E9FD139.2010406@ericsson.com> <CAAJUQMix=d3orAbUFtE-9Okb2EAwmV7yBpXFEX+zA23-17vRKw@mail.gmail.com>
In-Reply-To: <CAAJUQMix=d3orAbUFtE-9Okb2EAwmV7yBpXFEX+zA23-17vRKw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion
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, 20 Oct 2011 17:54:07 -0000

On 10/20/2011 06:59 PM, Wolfgang Beck wrote:
> On Thu, Oct 20, 2011 at 9:43 AM, Magnus Westerlund
> <magnus.westerlund@ericsson.com>  wrote:
>
>>  From my perspective both draft-beck-rtcweb-alt-ic-00 and
>> draft-ibc-rtcweb-sip-websocket-00 are relevant documents to the
>> discussion as they provides useful proposals on how interconnect and SIP
>> interop respectively can be done. But as they aren't proposals for how
>> the actual signaling solution should work. Thus these are homework but
>> don't get presentation time.
> It's a bit difficult to present an actual signaling situation if the
> proposal is not to specify a signaling solution at all..
Well, there's always the idea of specifying how the group's goals can be 
met without specifying a "signaling solution" (noting that, as Inaki has 
pointed out, this term has multiple meanings).

A logical approach would involve showing that it is possible to do all 
the tasks that need to be done by the functions otherwise described as 
"signalling" through a reasonably described API, that all the tricky 
bits (such as deciding to use codec parameters that did not exist when 
the Javascript was written) can be done using only the information that 
this API will be willing to expose to the Javascript, and that it's 
reasonable to assume that the API cannot be used in ways that would 
negatively impact the safety, security and stability of the browser 
platform.

I believe specifying an API such as is being proposed is a significant 
chunk of work, but I do not have the competence to even evaluate the 
size of the effort from the present state of my ignorance, far less the 
chances of arriving at something that can be used successfully.

I'm just somewhat skeptical.

                Harald