Re: [rtcweb] Another consideration about signaling

"Kevin P. Fleming" <kpfleming@digium.com> Mon, 10 October 2011 16:46 UTC

Return-Path: <kpfleming@digium.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 BD44521F8C30 for <rtcweb@ietfa.amsl.com>; Mon, 10 Oct 2011 09:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.507
X-Spam-Level:
X-Spam-Status: No, score=-103.507 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, 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 l645OxsUrnlr for <rtcweb@ietfa.amsl.com>; Mon, 10 Oct 2011 09:46:51 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id E82BF21F8C42 for <rtcweb@ietf.org>; Mon, 10 Oct 2011 09:46:50 -0700 (PDT)
Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from <kpfleming@digium.com>) id 1RDJ06-0003Xs-Ln for rtcweb@ietf.org; Mon, 10 Oct 2011 11:46:50 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 97F72D82A3 for <rtcweb@ietf.org>; Mon, 10 Oct 2011 11:46:50 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qiZ9USxHs5R for <rtcweb@ietf.org>; Mon, 10 Oct 2011 11:46:50 -0500 (CDT)
Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 2C899D8024 for <rtcweb@ietf.org>; Mon, 10 Oct 2011 11:46:50 -0500 (CDT)
Message-ID: <4E932179.7080000@digium.com>
Date: Mon, 10 Oct 2011 11:46:49 -0500
From: "Kevin P. Fleming" <kpfleming@digium.com>
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
CC: rtcweb@ietf.org
References: <CALiegfmoPWfhtBRiOfgLHG1uhJK_kK2t11xMoop-fT6qW4DUJQ@mail.gmail.com> <4E8F57EB.8030504@digium.com> <CABw3bnOD5APidfbqNscXdPURyY-AMQZqoyYPm6v2xWo5VWKOLA@mail.gmail.com> <4E905B7F.7010505@digium.com> <CABw3bnN2O6zgREBoWEdW2jj6-A4df05KJ_Y49LT3tsUXaXewwA@mail.gmail.com> <4E930845.60809@digium.com> <CALiegfnvBADCrGuWUB57=VQ+RWyN83JbZkp7a27UvoZ+XBwVMA@mail.gmail.com>
In-Reply-To: <CALiegfnvBADCrGuWUB57=VQ+RWyN83JbZkp7a27UvoZ+XBwVMA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Another consideration about signaling
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: Mon, 10 Oct 2011 16:46:51 -0000

On 10/10/2011 11:41 AM, Iñaki Baz Castillo wrote:
> 2011/10/10 Kevin P. Fleming<kpfleming@digium.com>om>:
>> In this situation, if the XYZ application wants to display the states of
>> other sessions, it will have to have some API between itself and the
>> communications server (the browser is not involved here) in order to monitor
>> (and potentially control) those sessions. This allows the web application
>> developer to be completely insulated from the signaling protocol that is
>> used, and instead just use an API provided by the communications server in
>> order to track and control communications sessions. Thus, the choice of
>> signaling protocol is irrelevant, as long as a hypothetical web application
>> developer can find and use a suitable communications server that implements
>> the chosen protocol *and* provides adequate APIs for the web application to
>> fulfill its requirements.
>
> Hi Kevin. Yes. In fact, in case the signaling is carried via
> WebSocket, the WebSocket server could be a separate server (not
> colocated within the web server) so you get the web server and the
> signaling server in different servers (and you would need some kind of
> proprietary communication between them in order for the web server to
> get the sessions status).
>
> But that's changes nothing in the design on RTCweb IMHO.

That's correct; the only reason I brought it up is that the choice of 
SIP as the RTCWEB signaling protocol, or something else, does not impact 
this at all. Choosing Jingle does not make this easier for the web 
application developer, and choosing SIP does not make it harder... in 
either case, they either *are* the signaling endpoint at the server end, 
or they aren't. Originally you had stated that if SIP was chosen, it 
would make this sort of application harder to build, because the 
application would not be likely to implement a SIP UA itself, and so it 
wouldn't have access to the session state information.

I'm not advocating that SIP be chosen... but for entirely different 
reasons :-)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org