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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 07 September 2011 15:16 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 6EF8321F85F7 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 08:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=-1.080, 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 O+7dF47CnAIw for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 08:16:07 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD6F21F855F for <rtcweb@ietf.org>; Wed, 7 Sep 2011 08:16:06 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta09.westchester.pa.mail.comcast.net with comcast id VrD31h0021vXlb859rHxoN; Wed, 07 Sep 2011 15:17:57 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta17.westchester.pa.mail.comcast.net with comcast id VrHv1h01e0tdiYw3drHwfz; Wed, 07 Sep 2011 15:17:57 +0000
Message-ID: <4E678B44.9080208@alum.mit.edu>
Date: Wed, 07 Sep 2011 11:18:28 -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: rtcweb@ietf.org
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>
In-Reply-To: <4E677CB8.40203@skype.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 15:16:08 -0000

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.

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