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

Paul Kyzivat <> Wed, 07 September 2011 23:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A5A921F8B77 for <>; Wed, 7 Sep 2011 16:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.369
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tqWPYINBT6gW for <>; Wed, 7 Sep 2011 16:36:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 45D9721F8B6B for <>; Wed, 7 Sep 2011 16:36:02 -0700 (PDT)
Received: from ([]) by with comcast id Vzdo1h0051YDfWL51zdtXo; Wed, 07 Sep 2011 23:37:53 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id Vzds1h00j0tdiYw3gzdsap; Wed, 07 Sep 2011 23:37:53 +0000
Message-ID: <>
Date: Wed, 07 Sep 2011 19:38:25 -0400
From: Paul Kyzivat <>
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 <>
References: <> <> <BLU152-W72696F07F16816B1B267593100@phx.gbl> <> <> <> <> <> <> <> <>
In-Reply-To: <>
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-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Sep 2011 23:36:05 -0000


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.


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 <
> <>> 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 mailing list
> <>
>     <>