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

[Matthew Kaufman <[e-mail]>]

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.

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.

Matthew Kaufman