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

["Asveren, Tolga" <[e-mail]>]

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. 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb