Subject: RE: A case related to "home Phone" type of functionality in SIP

From: Sean Olson <[email-masked]>
Date: Thu, 6 Jan 2000 17:49:13 -0600 (CST)

> 
> In a business environment, we call this a "single line extension".
> 
> SIP approaches tend to have the property that each phone is uniquely
> addressed, whereas in the PSTN each circuit is uniquely addressed.
> 
> The obvious solution is to combine a parallel search proxy and some UAS
> behavior.
> 
> The sequence is:
> 1) Incoming call reaches parallel proxy.
> 2) Parallel proxy invites all UASes in extension group.
> 3) User answers one extension.
> 4) Parallel proxy cancels unanswered legs. Those phones stop ringing.
> 5) Answering phone send INVITE to other phones in group, with "NO RING"
> specified somehow, and long expire timer.
> 
> 

In a business environment, this is a perfectly acceptable and reasonable
solution. For a home environment, multicast/DHCP seems more reasonable
because Joe consumer can go to Radio Shack, buy a 3com SIP phone, and
plug it into his home IP network and it works with zero (or 
almost-zero) configuration. Plus, it doesn't require the home user 
to buy/maintain a parallel proxy.

(By multicast, I mean both signalling and media).

-----------------------------------------------------------------
Sean Olson            mailto:[email-masked]
Ericsson Inc.         tel:(972)583-5472 
                      fax:(972)669-0154

---

From: Dean Willis <[email-masked]>
Date: Thu, 06 Jan 2000 19:43:04 -0600

Are you saying that the first phone would multicast the media streams to the
others on the local LAN, or that the INVITES and media would be sent
multicast across the ISP network?

If the former, it might work. COuld be pretty cool.

If the latter, no, it's not going to happen that way.

1) No ISP that I know of will provide a multicast feed, especially for a
lowly dialup user.

2) Every SIP phone in the country is going to listen to a universal
multicast group, then make application discard decisions on the INVITES that
don't apply to it  . . . Or, we could statically allocate a multicast
address for each home network . . .not. The INVITE will come in UNICAST.

3) Personally, I've never managed to get multicast routing working right
over the bizarre equipment that has accumulated at my house.

4) In our own internal network, we often saw join times that took seven or
eight minutes to propaget back to the source of a multicast. That's some
serious post-dial delay. I'm not sure we even try to route multicast
anymore.

5) The firewall issues that occur with cross-domain multicast are mind
boggling. Anything coming into my house is by-definition cross-domain.

Hey, I love multicast. I spent more than two years building really cool
businesses (Real Broadcast Netork, skyMCI, etc.) around it, and I'm here to
tell you it just isn't going to happen across an Internet backbone for the
average user any time soon.

--
Dean

> -----Original Message-----
> From: Sean Olson [mailto:[email-masked]]
> Sent: Thursday, January 06, 2000 5:49 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: A case related to "home Phone" type of functionality in SIP
>
>
> >

---

From: "ANIRBAN ROY" <[email-masked]>
Date: Fri, 07 Jan 2000 15:28:02 +0530

hi ,

lets say in a house there are 3 phones B, C, D. now User "A" calls to this house

Please tell me one question

When a call is going on between two user A and B and the third person "C" picks
up the phone from the same house what happens then????.

#       does a 200 Response goes back to the caller. Or the 200 Response just
append the Multicast Address with address "C".

#   RTP data goes directly from caller to callee. When there are more than one
user is in conversation how Proxy makes it sure that the RTP data will be send
to particular multicast address. As because Proxy only work in the signalling
layer.

Please reply

Anirban

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jan 2000 13:15:15 -0500

I'd rather not delve too much farther into the technical details of how
until we have understood what we want to accomplish. There have been
lots of ideas already in the last few days on how to do this, and they
all are solutions to slightly different problems.

So, given there appears to be interest in working on this, let me ask
the next question - who is willing to volunteer to work on a design team
to develop some documents for this? First step is requirements. If there
are sufficient people who are willing to actually do the work (phone
conferences, mail discussions and possibly a face to face), I will
discuss the possibility of adding this as a work item with my co-chairs
and the ADs.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Dean Willis <[email-masked]>
Date: Sat, 08 Jan 2000 12:03:15 -0600

> discuss the possibility of adding this as a work item with my co-chairs

My team is already working on a variation of this to meet the business
expectation of "single line extension" as supported off of common PBX and
Centrex systems.

The terse and badly written spec we have says:
-----
"Feature: Single Line Extension
Description: Provides the ability to give the customer single line set
extensions, either on the same or different premises - even in different
buildings.   This "line" will ring at each location and work just like an
extension.  There are several variations of Single Line Extension.
Sequential-First Wins, Parallel, etc.
-----

So, the basic idea is to capture the effect of this function as would be
experienced by a PBX user. This is slightly richer than the traditional home
experience, as most of these PBX phones are also "multiline" phones. This
means that if another user picks up a phone in the extension group, that
user can select whether to participate in the ongoing group call (an
"extension") or select another line for new dial tone and a new call. SIP
phones are basically multiline phones in this context.

If we added the capability for phones to display status on extensions that
join or leave the call, we would satisfy most of the requirements expressed
so far on this list. It would also be a terribly useful feature for
conference bridges . . .

Essentially, I view an extension group as a dynamically extended conference
brdige group.

I would be willing to support a common effort to standardize some kind of
solution.

I would like to see a solution that works outside the scope of a single
broadcast/multicast domain.

--
Dean