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

[Paul Kyzivat <[e-mail]>]

Mary,

My assertion that the analog implementation of these features was easy 
was in reference to support of multiple "extensions" on a single analog 
line, as Matthew mentioned earlier, where shared line appearances and 
bridging come "for free", though with some limitations.

I realize that it got considerably more complex with analog PBXs.

	Thanks,
	Paul

On 9/7/11 2:24 PM, Mary Barnes wrote:
> Just one comment below [MB].
>
> Mary.
>
> On Wed, Sep 7, 2011 at 10:18 AM, Paul Kyzivat <[e-mail]
> <mailto:[e-mail]>> 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. 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.
>
>     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.
>
> [MB] These features we not trivial in analog telephony by any means
> (speaking as someone who wrote LOTS of code for these ancient telephony
> systems).  IMHO, it's this misconception that the services and
> functionality in analog telephony systems was simple that's led to the
> difficulty in getting any operability for these services defined for
> SIP.  Many of the legacy telephone systems were no more designed for a
> host of complex services than SIP was.  However, it would have been nice
> if services had been considered in the initial design for SIP.  While
> there is the concept that many services can be accomplished with basic
> SIP building blocks/headers, we have way too many situations where this
> has proven to not be at all simple.  But, I don't think SIP/VoIP is any
> worse off than were the legacy systems. And, I agree with Paul there
> isn't any magic dust that will make it any easier for RTCWEB to support
> these features.  [/MB]
>
>
>             Thanks,
>             Paul
>
>
>     On 9/7/11 10:16 AM, Matthew Kaufman wrote:
>
>         On 9/7/2011 4:10 AM, Harald Alvestrand wrote:
>
>
>             Since more people than I may be confused, I'm forking a
>             subthread...
>
>             what is a bridged line appearance, and why is it hard to do
>             in SIP?
>
>             My terminology cache is totally blank.
>
>
>         Key system (and home phone) emulation requires two things that
>         are hard
>         to do (because there's no final specification, not because it is
>         impossible) (and because there's 3+ alternatives, and almost no
>         phones
>         implement more than one of them) in SIP:
>
>         1. Shared line appearance
>
>         This is where you can be on a call on one handset, see that the
>         line is
>         in use at the other handset. Place the call on hold at the
>         first, pick
>         it up at the second.
>
>         In business PBX cases, this is used for executive/assistant
>         cases. In
>         key system emulation it is used for "Bob, pick up the call
>         holding on
>         line 3". And for home phones it is the usual "put the phone on
>         hold in
>         the kitchen, pick it up in the den." (My wife wanted this
>         functionality,
>         so I had to add proprietary support for shared line appearance on my
>         home PBX.)
>
>         2. Bridged line appearance
>
>         This is where you can be on a call on one handset, see that line
>         is in
>         use at the other handset, and pick up the second handset to join
>         the call.
>
>         In the business PBX and key system case this is sometimes used for
>         supervisors to join a call to help, but the real common case is
>         the home
>         phones... "kids, go pick up the extension in the living room and
>         talk to
>         grandma."
>
>         With POTS, this works by simply paralleling two handsets on the same
>         copper pair. For SIP it requires everything shared line
>         appearance does
>         *plus* automatic barge-in + conference on pickup.
>
>         The BLISS WG has been working, for a long time, on taking the
>         various
>         interim proposals and creating a standard out of them, but we're
>         still
>         not there... and yet without it, there's no way to use phones
>         from two
>         different vendors to accomplish this.
>
>         Whereas with WebRTC implemented *without SIP*, it is fairly easy to
>         build a web app that runs on multiple browsers from multiple
>         vendors and
>         implements this.
>
>         So this type of ability to innovate and implement applications
>         without
>         going through the standards process is why we *definitely* don't
>         want
>         SIP baked in to the browser.
>
>         Not to be confused with the arguments against SDP offer/answer,
>         which is
>         only slightly affected by the above use cases (in that you can do
>         smarter things at the bridge for bridged line appearance if you
>         aren't
>         doing a reinvite/re-offer/re-answer but instead have on hand all the
>         capabilities of the first device when the second goes to join).
>
>         Matthew Kaufman
>         _________________________________________________
>         rtcweb mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/__listinfo/rtcweb
>         <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>
>     _________________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>