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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Feb 2001 07:08:35 -0500

> -----Original Message-----
> From: Daniel G. Petrie [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 9:05 PM
> To: Rohan Mahy
> Cc: Jonathan Rosenberg; 'Neil Deason'; Alan Johnston; Richard 
> Verhoeven;
> Rick Dean; [email-masked]; [email-masked];
> [email-masked]'
> Subject: Re: [SIP] RE: [Sip-implementors] SIP and Call Pickup
> 
> 
> 
> 
> Rohan Mahy wrote:
> 
> > 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
> >
> 
> 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.

Indeed, it is exactly a sub/not mechanism thats needed. Its a pretty complex
one, though, in  terms of scalability. Basically, every single active
transaction through a proxy needs to generate a subcsription from the
transaction, towards the registrar, for those registrations used to proxy
the call. This means that your subscription count scales with the number of
simultaneous transactions through the proxy. Yuck. Note that this is the
case even when the registrar/proxy are co-located. In this case, the
communication is between software components in the same process, but the
need is identical.

Is it harder than a B2BUA? Hard to say. 

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

I think that can work; you need to be careful about what Contact URI you
place in the REGISTER for directed pickups. It can't be the same thing you
put in REGISTER for receiving normal phone calls.

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

Not really. THere is more state, yes. But, we don't have the other drawbacks
of the MGCP approach. Thats a separate flame war that I'd rather not start.

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

The drawbacks in terms of scalability, reliability and performance of a
B2BUA are well known (at least, I hope they are), so I think that will cause
people to think a bit before using a B2BUA when a proxy will do.

That aside, there are just lots of services that can't be done any other
way. Perhaps call park isn't one of them, and thats fine. I do recall
someone posted a note on why the mechanism in rfc2543 was not call pickup,
for many reasons. I couldn't find the note in the archive, so maybe I just
imagined it. 

Anyway, the issue at hand is twofold:

1. should the spec say anything about call pickup

   Given our trend not to define services, I would say no. 

2. should the spec still have this capability of sending a register in the
middle of a call
   to add contacts

   Given that several people said they rely on this feature, it looks like
it stays.

-Jonathan R.
---
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: Alan Johnston <[email-masked]>
Date: Wed, 28 Feb 2001 07:20:41 -0600

All,

I plan to add the corrected call flow (forking INVITE instead of CANCEL) to the
new draft of the Service Examples so we can all take a look at the details -
such as the Request-URI of the REGISTER as Jonathan points out.

Alan Johnston
WorldCom
sip:[email-masked]