Subject: [SIP] RE: [Sip-implementors] SIP and Call Pickup

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 25 Feb 2001 23:10:13 -0500

[moving over to the sip list, as we are now talking about changes to sip]

A few thoughts on directed pickup.

1. The mechanism in rfc2543 is a hack. It is meant to provide call pickup as
a side effect of register behavior. What would happen is that the register
would cause the original INVITE to fork to the second phone. The second
phone then answers, which causes the first call to be CANCELed. As such,
Alan's flow is wrong. The proxy would not CANCEL on receipt of REGISTER (why
would it do that?). Rather, it would generate the second INVITE, and when
its answered, then CANCEL. However, this mechanism has some big problems:

   a. its hard to do in a distributed system where the registrar and proxy
are separated
   b. it doesn't actually provide directed call pickup, since the user
experience is much different. IN this mode, the second phone will actually
ring!

2. The other proposals so far, involving REFER or a REGISTER directly to the
first phone, will not work. They both defined additional, service specific
semantics to these requests. Bad, bad.

3. It is possible to do directed pickup with a B2BUA. I worked through a
call flow for it, and it emulates completely the PSTN service. It requires
no extensions to SIP, just logic for the service in the picking-up phone and
in the B2BUA. Can it be done without a B2BUA in a distributed way? Maybe.
But, I'm not going to get hung up on emulating every infrequently used PSTN
service in a distributed way.

4. I believe we should actually remove the current text on directed pickup.
Thats because:

   a. we said that we don't standardize services, but here is random text in
the middle of a section which does just that. It was definitely an
afterthought.
   b. it doesn't work easily when the registrar and proxy are separated
   c. it doesn't actually do directed pickup as defined
   d. I don't think its that widely implemented.

Can anyone comment on d? Would anyone object to yanking this text?

-Jonathan R.

> -----Original Message-----
> From: Neil Deason [mailto:[email-masked]]
> Sent: Thursday, February 22, 2001 10:23 AM
> To: Alan Johnston
> Cc: Richard Verhoeven; Rick Dean; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Sip-implementors] SIP and Call Pickup
> 
> 
> Alan Johnston wrote:
> > 
> > Adding Call Pickup and Park is on my to do list for the SIP
> > Service Examples I-D (draft-ietf-sip-service-examples-00.txt),
> > but I haven't had any suggestions for how to do this.
> > 
> > What about using the mechanism described in bis, but hiding it
> > from the caller behind a proxy?  The REGISTER message from C
> > would expire immediately and be directed at B via the proxy.
> > The proxy could then cross-reference the pending INVITE to B,
> > consult policy to see if C is authorized to pickup B's calls,
> > then cancel the pending INVITE and direct the call to C.
> > 
> > 
> >      Caller A         Proxy          B Called           C Picks
> > Up Call
> >        |                |              |                   |
> >        |    INVITE F1   |              |                   |
> >        |--------------->|   INVITE F2  |                   |
> >        |(100 Trying) F3 |------------->|                   |
> >        |<---------------|180 Ringing F4|                   |
> >        | 180 Ringing F5 |<-------------|                   |
> >        |<---------------|              |                   |
> >        |                |              |    REGISTER F6    |
> >        |                |<---------------------------------|
> >        |                |              |    200 OK F7      |
> >        |                |--------------------------------->|
> >        |                |              |                   |
> >        |                |   CANCEL F8  |                   |
> >        |                |------------->|                   |
> >        |                |   200 OK F9  |                   |
> >        |                |<-------------|                   |
> >        |                |    487 F10   |                   |
> >        |                |<-------------|                   |
> >        |                |    ACK F11   |                   |
> >        |                |------------->|                   |
> >        |                |              |    INVITE F12     |
> >        |                |--------------------------------->|
> >        |                |              | 180 Ringing F13   |
> >        | 180 Ringing F14|<---------------------------------|
> >        |<---------------|              |      200 OK F15   |
> >        |                |<---------------------------------|
> >        |   200 OK F16   |              |                   |
> >        |<---------------|              |                   |
> >        |     ACK F17    |              |                   |
> >        |--------------->|              |     ACK F18       |
> >        |                |--------------------------------->|
> >        |               Both way RTP Established            |
> >        |<=================================================>|
> > 
> > Comments?
> 
> I think this would work. The Proxy could perhaps just fork
> again upon receipt of F6, letting both B and C ring and doing
> the CANCEL on which ever leg doesn't answer 200. 
> 
> However, I don't really like promoting the use of REGISTER
> for this as a good idea. It overloads REGISTER and is using 
> SIP as a call control protocol. The whole area of a SIP call 
> control framework seems to need more work so I wouldn't want 
> this perceived to be _the_ way. Anyway if users have intelligent 
> and intuitive access to forwarding services through CPL call 
> pick up is redundant.
> 
> Cheers,
> Neil.
> -- 
> Ubiquity Software Corporation, UK        http://www.ubiquity.net
> _______________________________________________
> Sip-implementors mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 

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

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Scott Hoffpauir" <[email-masked]>
Date: Mon, 26 Feb 2001 00:11:32 -0500

We do call pickup with a B2BUA, which as stated doesn't require anything out
of the ordinary. With wide scale deployment of voice mail, this service
isn't really that useful. There are many better call completion features
today (voice mail, forking, etc.) which will eventually obsolete call
pickup. Last time I used it was about 10 years ago. I think it should be
yanked.

Scott

BroadSoft
240-364-5106

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jonathan Rosenberg
Sent: Sunday, February 25, 2001 11:10 PM
To: 'Neil Deason'; Alan Johnston
Cc: Richard Verhoeven; Rick Dean; [email-masked];
[email-masked]; [email-masked]'
Subject: [SIP] RE: [Sip-implementors] SIP and Call Pickup

-Jonathan R.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 26 Feb 2001 00:47:32 -0600

Scott,

I agree 100%.  It was a dumb feature to try and make digital
Centrex phones mimic the behavior of a keyset.  Nobody liked it,
nobody used it.

Yank it, please...

--Brian

Scott Hoffpauir wrote:                           (Mon, 26 Feb 2001 00:11:32)

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 26 Feb 2001 10:08:14 -0500

I've removed the service description from the draft. However, this still
leaves the question what, if anything, the draft should say about the
desired behavior if the registration does change while sequential
forking, say, is going on. The current wording is:

  If the registration is changed while a user agent or proxy server
  processes an invitation, the new information {\SHOULD} be used.

I suspect the simplest behavior is to say that this is
implementation-dependent. In other words, if you want to allow adding a
new location to an on-going search in your proxy, fine, but you can't
rely on this to build a new service. 

(I'm trimming the cc list, since presumably everyone is on the SIP
mailing list and doesn't need to see two copies of each message.)
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs