Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver)
Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 08 September 2011 15:20 UTC
Return-Path: <pkyzivat@alum.mit.edu>
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 C98A121F8A6F for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 08:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Level:
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 baApT1WsrDmD for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 08:20:18 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9E34621F891D for <rtcweb@ietf.org>; Thu, 8 Sep 2011 08:20:18 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta05.westchester.pa.mail.comcast.net with comcast id WEHF1h0051c6gX855FNBwB; Thu, 08 Sep 2011 15:22:11 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id WFN91h04Y0tdiYw3jFNAFw; Thu, 08 Sep 2011 15:22:11 +0000
Message-ID: <4E68DDC5.3050209@alum.mit.edu>
Date: Thu, 08 Sep 2011 11:22:45 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Matthew Kaufman <matthew.kaufman@skype.net>
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>
In-Reply-To: <4E67EBCF.5050206@skype.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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:20:20 -0000
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? 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. Thanks, Paul
- [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