Subject: Re:[Sip] [Sip-implementors] another problem related to multiple call l egs at UAC

From: "Bob Penfield" <[email-masked]>
Date: Tue, 26 Jun 2001 10:10:12 -0400

oops, I messed up who wrote what

Jonathan Rosenberg writes:
> Bob Penfield writes:
> >
> > For example, I use a one-number service (unfortunately PSTN
> > based) with a
> > call screening feature that tells the callee who the call is
> > for and who is
> > holding and asks the callee to press 1 to accept the call. The service
> > simultaneouly rings my office, home, and cell phone. If this were
> > implemented in SIP with a forking proxy to get to all the devices I
> > registered, and the proxy canceled the unanswered call legs
> > as soon as one
> > answered, I could not receive the call if my wife picked up
> > the home phone
> > before I answered my office or cell phone.
> >
> > I think it should be a MAY.
>
> Won't help. The caller here doesn't know about this service, so they would
> simply generate the CANCEL. Even if this weren't true, you have another
> problem. Multiple accepted call legs would only be established under the
> race condition where you and your wife pick up at once. What you REALLY
want
> is that when you wife picks up, you can still pick up that call (even
though
> your phone isn't ringing anymore) at any time until she hangs up, and then
> press 1 to accept. THis is the standard home phone line behavior, which
the
> single line extension group was working on. Doing this properly requires
far
> more than just not cancelling.
>
> I have some ideas on how to actually support this given our current set of
> tools for conferencing, and so I will (hopefully) have a draft on how to
> properly do it before London.

You don't necessarily need conferencing to do this.

To implement this service in SIPland would require some sort of application
server to prompt callees with the screening information. BTW, as long as my
wife does not press 1 to accept the call, I can still pick up the call even
if I answer long after she does because the service keeps ringing the other
phones until a callee presses 1.

But anyway, it would look something like this:

+--------+         +------------+         +-----+------->home
| caller |-------->| app server |-------->|proxy|------->office
+--------+         +------------+         +-----+------->cell

The SIP URL people use to call me would point to the app server. The app
server would know to send an invite to my local proxy/registrar. The app
server would act as a B2BUA or connect to the accepting callee using REFER.
But in this case, the app server is the UAC that is capable of handling
multiple 200-OKs (it would send SDP in the ACK as opposed to the INVITE).
The app server would issue a cancel when the callee accepts by pressing 1.
If my local proxy always canceled incomplete legs when it got the first
200-OK, it breaks the application. And if the proxy does not support caller
preferences, then the app server can't tell it not to cancel.

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 18:23:58 -0400

> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 8:48 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Re:[Sip] [Sip-implementors] another problem related 
> to multiple
> call l egs at UAC
> 
> 
> > > <snip>

Egads. Not a very nice user interface, but thats a separate discussion. 

> +--------+              +------------+              
> +-----+------------>
> home
> | caller |------------->| app server 
> |------------->|proxy|------------>
> office
> +--------+              +------------+              
> +-----+------------>
> cell
> 

Well, it comes down to which is the more common case. What you want is
readily supported so long as caller prefs is supported in the proxies.
Agreed. However, it is not the common case. The more common case is a normal
forked call whose objective is to reach the first user that picks up. Since
the caller doesn't know which proxies have forked, pushing the
responsibility to CANCEL to the caller doesn't seem appropriate.
Effectively, every UA would have to generate a CANCEL every time it gets a
2xx. Yuck. Thus, I would argue that the proxies which fork are the ones that
should be handling the CANCEL in the common case.

In other words, the common case should be the one thats a SHOULD, and the
exceptional cases handled with extensions.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com