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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 1 Mar 2001 02:19:41 -0500

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

Its the Contact thats the issue. It needs to be unique within the phone, and
associated with just that call thats being picked up. So, it would need to
be something like:

REGISTER sip:mydomain.com SIP/2.0
From: sip:[email-masked]
To: sip:[email-masked]
Contact: sip:[email-masked]
....

where that extra bit at the end of the number in the user portion of the
register binds this address with pickup for a specific call.

-Jonathan R.

> 
> Alan Johnston
> WorldCom
> sip:[email-masked]
> 
> Jonathan Rosenberg wrote:
> 
> >
> >
> > > -----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.
> 

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