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

Cullen Jennings <fluffy@cisco.com> Wed, 07 September 2011 14:57 UTC

Return-Path: <fluffy@cisco.com>
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 16B6D21F8B55 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 07:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.267
X-Spam-Level:
X-Spam-Status: No, score=-103.267 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 2LPbxbSW2I1B for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 07:57:42 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id DE27721F8B52 for <rtcweb@ietf.org>; Wed, 7 Sep 2011 07:57:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3013; q=dns/txt; s=iport; t=1315407572; x=1316617172; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=E/6VJHHZBuQFKVUKUSP8aTHqrZETxH3IppfBPjLi8cw=; b=XDsiR0PEWHasDIl1Vtq+GXfXOcFjRajjYM6nK7oaeZVZUyvrRX6CMra5 S+1FtHueVUUN1ugg4Tw0dpRJ0zqcer3kNZUVtWnetJwkGwsh3r1LTgfCg 8xkWzmVuRMTDdYgCz86MT0x7xHVYQvzbrWWVzjYxnV7cw+D2OzDJQYRN7 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAIKGZ06rRDoJ/2dsb2JhbABDp214gUYBAQEBAgESAScuEQULCxIGIwtJDgY1h1OYbgGeS4YLYASHbItGhRKMIg
X-IronPort-AV: E=Sophos;i="4.68,345,1312156800"; d="scan'208";a="679192"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 07 Sep 2011 14:59:32 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p87ExVsE030255; Wed, 7 Sep 2011 14:59:32 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <4E677CB8.40203@skype.net>
Date: Wed, 7 Sep 2011 08:59:31 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <5DD808C2-D4ED-45E4-8D18-02613281A62D@cisco.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>
To: Matthew Kaufman <matthew.kaufman@skype.net>
X-Mailer: Apple Mail (2.1084)
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:57:47 -0000

On Sep 7, 2011, at 8: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.

I've sort of been humoring you but I'm going to push this one a bit. I think you are wrong. 

Give me one reasons why it would be any harder to do if the browser did SIP than if it did the type of API you are talking about. I think you are just wrong here. The web app in the JS and in the web server would still just use SIP to set up media the way it wanted - just like you would do with the other API. No one is proposing we use the BLISS shared line appearance or anything like that - we are proposing that when A wants to say what codecs to use for sending media to B, use that part of SIP. 

(oh, and you could replace SIP with the word Jingle in the above paragraph and it would equally true)