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

Matthew Kaufman <matthew.kaufman@skype.net> Wed, 07 September 2011 14:15 UTC

Return-Path: <matthew.kaufman@skype.net>
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 ACDCD21F8B72 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 07:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level:
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 X5-NcFdRdWKU for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 07:15:20 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3AF21F8B4D for <rtcweb@ietf.org>; Wed, 7 Sep 2011 07:15:20 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 219D716F6; Wed, 7 Sep 2011 16:17:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=IjHOLHHKF4ZXOH aNbMiWmWUjSq4=; b=XmZjy69qetljvfX87ECzQynYpmo6lN1c/PQrbzqUey7ZiR 4fS4ClEQAUnUlsN1uWzH1OYG69mGKxKV6bgJByUj7hQALY9v9AAzYm9J4sO8p3MQ 5lr7rrqGcy5uTn1NBuciF+Gdubk1F5k50v1AvnTPQvm4dnipdrSV+0/1uypaM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=jVSz5zGunRmJdCUVry0rsl FaSU03nglNtccyvD4kMACKi8AR/fpGYzY9M+m3pGBjD8Mfue+BudleCIWnMJU2vs ye038ttDe2+RtvxfYuLPo6bOP/6HuQ7Y2kU1namrafDbWKpssG79sgEufSAj1bLq RkIDzMkfv3V7T/ci5590U=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 16D05CF; Wed, 7 Sep 2011 16:17:08 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id B188135080A4; Wed, 7 Sep 2011 16:17:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPRY2EFpvi9a; Wed, 7 Sep 2011 16:17:06 +0200 (CEST)
Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id B2617350809D; Wed, 7 Sep 2011 16:17:05 +0200 (CEST)
Message-ID: <4E677CB8.40203@skype.net>
Date: Wed, 07 Sep 2011 07:16:24 -0700
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: Harald Alvestrand <harald@alvestrand.no>
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>
In-Reply-To: <4E67513C.3030600@alvestrand.no>
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 14:15:21 -0000

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