Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver)
"Asveren, Tolga" <tasveren@sonusnet.com> Thu, 08 September 2011 15:44 UTC
Return-Path: <tasveren@sonusnet.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 D0D7921F8B1A for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 08:44:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 HeE4oyNaJhki for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 08:44:20 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 05DCB21F8ADE for <rtcweb@ietf.org>; Thu, 8 Sep 2011 08:44:19 -0700 (PDT)
Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p88FkeRb008782; Thu, 8 Sep 2011 11:46:40 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 08 Sep 2011 11:45:47 -0400
Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E703C28AF1@sonusmail04.sonusnet.com>
In-Reply-To: <4E68DDC5.3050209@alum.mit.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver)
Thread-Index: AcxuOxf78N8rOtbXRhy9k2of9l/DpgAAUhaw
References: <CAM_kxqci51=BnUFe-67Qs4eCxtGY50HDsRPrLjYULnBZJoH0Ow@mail.gmail.com>, <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <BLU152-W72696F07F16816B1B267593100@phx.gbl> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com><4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no><4E677CB8.40203@skype.net> <4E678B44.9080208@alum.mit.edu><4E67EBCF.5050206@skype.net> <4E68DDC5.3050209@alum.mit.edu>
From: "Asveren, Tolga" <tasveren@sonusnet.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Matthew Kaufman <matthew.kaufman@skype.net>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver)
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, 08 Sep 2011 15:44:20 -0000
Some questions/comments inline... Thanks, Tolga > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, September 08, 2011 11:23 AM > To: Matthew Kaufman > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & > architecture: Browser application with separate webserver & voipserver) > > On 9/7/11 6:10 PM, Matthew Kaufman wrote: > > On 9/7/11 8:18 AM, Paul Kyzivat wrote: > >> Matthew, > >> > >> Good summary. > >> > >> I agree that webrtc provides flexibility in how to implement the UI > >> portions of these features with generic webrtc clients. But it doesn't > >> make these features trivial to implement. > > > > I didn't say that it did. But the flexibility does allow the feature to > > be implemented in whatever combination of client-side Javascript and > > server-side programming you wish. > > > >> In particular, the bridged line appearance still requires that a > >> conference be established. With generic rtcweb clients, that probably > >> means a central mixer. Setting that up is relatively easy if there is > >> a central media termination point in rtcweb server, and it *has* mixer > >> capabilities. > > > > Agree. > > > >> > >> My point is not that rtcweb doesn't help with this case - just that > >> these features that are so trivial in analog telephony just aren't so > >> simple with voip, no matter how you do it. > > > > Also agree. > > > > The real difference comes with the programming model. With a SIP phone, > > to add bridged line appearance support you need to write a new spec > > (that doesn't exist), get consensus around that spec, and then upgrade > > the phone firmware. With an SCCP (Skinny) phone, to add bridged line > > appearance support you simply write some additional code that runs at > > the server end that changes when the lights are commanded to turn on and > > off, controls what happens when a lit line button is pushed, and > > commands the phone to send the right kind of media to the right place. > > I think what you are saying is that with rtcweb you can build a > replacement for Cisco Call Manager - with rtcweb replacking SCCP, and > the call manager itself subsumed into a web server. This then allows any > rtcweb enabled user device to be used instead of a Cisco proprietary > phone. I agree with that, and its likely to be a good thing. (But maybe > not for Cisco.) > > At a macro level that thing seems to have the same centralized > architecture as the Call Manager. Call Manager never bought into the sip > vision that the phones should be largely autonomous, and this approach > using rtcweb doesn't either. > > The complexity of standardizing features like bridged line appearance > arises if you try to follow that sip vision and allow autonomous sip > devices to cooperate in that feature. > > I've been pondering this for a long time. I have realized its not > practical to standardize all the features that span multiple devices > attached to the same AOR - that having a server for the AOR coordinate > the features across the multiple devices is more practical. And that > rtcweb is a great way to do that without locking down the choice of > devices. > > But I think the situation is different for coordinating features that > span the multiple endpoints of a realtime communication session. Then it > comes down to a case by case analysis of how important it is for a > particular feature to be ubiquitous. For instance, maybe you want to use > Facebook as your "call agent" for realtime communications. But does that > mean you can't communicate with me because I'm not a Facebook user? [TOLGA] Yes, I think so if the service provided by Facebook is "capability to establish a call to another Facebook user". If it is "capability to call any phone number", then one would be able to call any phone number, and if it the ability to call a Service-X identity, it will do so. I guess the notion of "capability to call anybody" is very vague. It all depends on the "identity context" + "identity to call" and that will be determined by the service AFAICS. > Ideally you can still reach me while using Facebook as your call agent. > Then there are *some* features that will ideally still work, while there > might be other features that only work when both ends are facebook users. > > Those features that are to be more ubiquitous will require more > standardization effort than those that aren't. (No free lunch.) > > Rtcweb ought to work with both sorts. > > > There is no reason why we should make a web browser, which has the added > > advantage of a local execution environment for Javascript, *less* > > capable than the aforementioned server-controlled phone. > > Note that Call Manager can use SIP phones as well as SCCP phones. And > when those sip phones have the Cisco secret sauce (which deviates only > mildly from *real* sip) they have all the functionality of the SCCP phones. > > I would expect that whatever way this debate ends (sip in the browser or > not) the web browser should have the same level of functionality. [TOLGA] Can I assume that you mean "webbrowser + JS" instead of "webbrowser as is"? I am not entirely sold on the idea that SIP endpoint is equivalent to a webbrowser from architectural point of view (even with JS). > > Thanks, > Paul > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] Some misunderstandings about <Usecase & … Nguyen Duong Tuan
- Re: [rtcweb] Some misunderstandings about <Usecas… Ravindran Parthasarathi
- Re: [rtcweb] Some misunderstandings about <Usecas… Bernard Aboba
- Re: [rtcweb] Some misunderstandings about <Usecas… Nguyen Duong Tuan
- Re: [rtcweb] Usecase & architecture: Browser appl… Ravindran Parthasarathi
- Re: [rtcweb] Usecase & architecture: Browser appl… Matthew Kaufman
- Re: [rtcweb] Usecase & architecture: Browser appl… Ravindran Parthasarathi
- Re: [rtcweb] Usecase & architecture: Browser appl… Matthew Kaufman
- Re: [rtcweb] Usecase & architecture: Browser appl… Ravindran Parthasarathi
- [rtcweb] Bridged line appearance? (Re: Usecase & … Harald Alvestrand
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Matthew Kaufman
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Matthew Kaufman
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Cullen Jennings
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Cullen Jennings
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Tim Panton
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Paul Kyzivat
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Mary Barnes
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Matthew Kaufman
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Matthew Kaufman
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Matthew Kaufman
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Paul Kyzivat
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Paul Kyzivat
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Asveren, Tolga
- Re: [rtcweb] Bridged line appearance? (Re: Usecas… Paul Kyzivat