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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 01:16:56 -0400

> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: Monday, June 25, 2001 4:45 PM
> To: Jonathan Rosenberg; 'Barry Desborough'; 'Paul Kyzivat'
> Cc: [email-masked]
> Subject: Re: [Sip-implementors] another problem related to 
> multiple call
> l egs at UAC
> 
> 
> Jonathan Rosenberg writes:
> <snip>
> > Harpreet writes:
> > > Another thing  Section 5.2 of bis 03.txt also says that
> > > "A proxy client generates a CANCEL request for branches without
> > >    a final response after it has forked a request and
> > > receives a 2xx or
> > >    6xx response from one of the branches. "
> > > Whereas section 17.4, pg. 122 says that
> > > "After receiving a 2xx, the server MAY terminate all other
> > >              pending requests by sending a CANCEL request"
> > >
> > > Note that there is no "MAY" in section 5.2.
> >
> > These need to be consistent. Honestly, it should probably 
> be a SHOULD as
> > opposed to a MAY in both places. Anyone object to me changing that?
> >
> 
> Wouldn't that break the cancel-feature of the 
> Request-Disposition header in
> the caller preferences draft? If the proxies always cancel 
> the other legs,
> then clients that do fancy things with multiple answers could 
> never work.

No; caller preferences would override this otherwise default behavior.

> 
> 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.

-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

_______________________________________________
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: "Bob Penfield" <[email-masked]>
Date: Tue, 26 Jun 2001 08:48:11 -0400

Jonathan Rosenberg writes:

> Bob Penfield writes:
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]