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

From: Rohan Mahy <[email-masked]>
Date: Mon, 26 Feb 2001 09:10:24 -0800

At 08:10 PM 2/25/01 , Jonathan Rosenberg wrote:
>[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

sounds like an implementation choice to me.

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

this is trivial to fix: the second phone/gw just creates some local state, 
so that when an INVITE for that request-uri arrives, it simply replies with 
a 200.  Note that on an analog phone, you are already "offhook" anyway.

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

agreed.

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

All you've done is moved the problem around.  Now all calls that can be 
picked up have to go through this B2BUA.  Eventually this will need the 
performance of some kind of proxy (but it needs to keep more state and 
handle twice as many transactions), so if you want to provide redundancy or 
load sharing you need to add some additional state-sharing scheme, 
etc.  Congratulations, you've just recreated the MGCP model over SIP!  ;-)

IMO, B2BUA is an overused crutch.  I don't object to folks implementing 
their own services with it, but I don't want us to cripple the spec, or 
actively encourage others to recreate that which we try to avoid.

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

I object to yanking the text about acting on a REGISTER in progress.  If 
you want to yank the reference to "this is how you do call pickup" that's 
fine with me.

We have already discussed how to do this in our proxy in a distributed way, 
and we don't have to ring the phone.

There is room for implementations using both models.

thanks,
-rohan

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

_______________________________________________
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: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 26 Feb 2001 21:04:56 -0500

> >    a. its hard to do in a distributed system where the registrar and proxy

It requires some additional signalling, but I would not say
that it is hard.  It is not as complicated as building a B2BUA that
has to deal with the state and scale of every ringing phone in an
environment.  One not well thought out means: proxy could do a
short lived implied or explicit SUBSCRIBE and get a NOTIFY
from the registrar with additional contacts as added.  I think the
proxy/registrar is the correct place for this feature.

> actively encourage others to recreate that which we try to avoid.

I am with you on this.  There is a great danger that B2BUAs start
getting stuffed into networks where proxys are more appropriate.
It then gets harder and harder to allow two end points  to send
messages without content and headers getting filtered out or
mucked up by B2BUAs in the middle which do not explicitly
support the extensions of the end points.

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

We were planning on supporting pickup in our UA using this technique.
Of course if no proxy/registrars support it we are just one hand
clapping.