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>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture:
 Browser application with separate webserver & voipserver)
Precedence: list

On Sep 7, 2011, at 8:16 AM, Matthew Kaufman wrote:

> On 9/7/2011 4:10 AM, Harald Alvestrand wrote:
>>=20
>> Since more people than I may be confused, I'm forking a subthread...
>>=20
>> what is a bridged line appearance, and why is it hard to do in SIP?
>>=20
>> My terminology cache is totally blank.
>>=20
>=20
> 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:
>=20
> 1. Shared line appearance
>=20
> 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.
>=20
> 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.)
>=20
> 2. Bridged line appearance
>=20
> 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.
>=20
> 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."
>=20
> 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.
>=20
> 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.
>=20
> 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.=20

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.=20

(oh, and you could replace SIP with the word Jingle in the above =
paragraph and it would equally true)