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

[Paul Kyzivat <[e-mail]>]

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