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
- Re: [rtcweb] Friday Call details for signaling di… Harald Alvestrand
- [rtcweb] Friday Call details for signaling discus… Ted Hardie
- [rtcweb] Friday Agenda: Re: Friday Call details f… Magnus Westerlund
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Iñaki Baz Castillo
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Harald Alvestrand
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Iñaki Baz Castillo
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Iñaki Baz Castillo
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Harald Alvestrand
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Magnus Westerlund
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Magnus Westerlund
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Wolfgang Beck
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Matthew Kaufman
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Bernard Aboba
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Harald Alvestrand
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Hadriel Kaplan
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Christer Holmberg