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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 07 September 2011 23:36 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5A921F8B77 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 16:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.369
X-Spam-Level:
X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, MANGLED_ONLINE=2.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqWPYINBT6gW for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 16:36:04 -0700 (PDT)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 45D9721F8B6B for <rtcweb@ietf.org>; Wed, 7 Sep 2011 16:36:02 -0700 (PDT)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta01.westchester.pa.mail.comcast.net with comcast id Vzdo1h0051YDfWL51zdtXo; Wed, 07 Sep 2011 23:37:53 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id Vzds1h00j0tdiYw3gzdsap; Wed, 07 Sep 2011 23:37:53 +0000
Message-ID: <4E680071.6080800@alum.mit.edu>
Date: Wed, 07 Sep 2011 19:38:25 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Mary Barnes <mary.ietf.barnes@gmail.com>
References: <CAM_kxqci51=BnUFe-67Qs4eCxtGY50HDsRPrLjYULnBZJoH0Ow@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <BLU152-W72696F07F16816B1B267593100@phx.gbl> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no> <4E677CB8.40203@skype.net> <4E678B44.9080208@alum.mit.edu> <CAHBDyN57bwciBFgePiwQatO-xKTuTtTOwuDW7ziDabNqquFPPg@mail.gmail.com>
In-Reply-To: <CAHBDyN57bwciBFgePiwQatO-xKTuTtTOwuDW7ziDabNqquFPPg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Sep 2011 23:36:05 -0000

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 <pkyzivat@alum.mit.edu
> <mailto:pkyzivat@alum.mit.edu>> 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
>         rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>         https://www.ietf.org/mailman/__listinfo/rtcweb
>         <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>
>     _________________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>