Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver)

[Paul Kyzivat <[e-mail]>]

On 9/8/11 11:45 AM, Asveren, Tolga wrote:
> Some questions/comments inline...
>
> Thanks,
> Tolga
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
> Behalf
>> Of Paul Kyzivat
>> Sent: Thursday, September 08, 2011 11:23 AM
>> To: Matthew Kaufman
>> Cc: [e-mail]
>> 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.

Agreed - clearly either sort of service could be provided.

At the moment its a battle for dominance between a number of these 
services, so often they have negative motivation to federate. But this 
too shall pass, and it will be acknowledged that Facebook users can have 
friends on LinkedIn, and that LinkedIn users can have Contacts on Facebook.

>> 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"?

Yes. What else could I mean? A web browser without an JS can't really do 
much interesting.

	Thanks,
	Paul

> I am not entirely sold on the idea that SIP endpoint is equivalent to a
> webbrowser from architectural point of view (even with JS).