Subject: RE: [SIP] on directed pick up service

From: Scott Bradner <[email-masked]>
Date: Thu, 6 Jul 2000 07:27:05 -0400 (EDT)

> But don't you have to know what the service is and how it behaves before you
> can define the protocol to support it?

I would hope that we are not so limited that we define protocols
that only support the services we can agree to today - the Internet
would not be what it is if that was the way that IP had been defined

Scott

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Amar Singh <[email-masked]>
Date: Thu, 6 Jul 2000 11:17:33 -0700

How does directed pickup work when redirect server is used instead of proxy
server. 

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, July 05, 2000 9:17 PM
To: Jo Hornsby
Cc: Krishna G; [email-masked]
Subject: Re: [SIP] on directed pick up service

Jo Hornsby wrote:
> 
> > > Basically, a typical call flow for such a scenario would be:
> > >
> > > A --INVITE--> P             B --INVITE--> C
> > >                 --INVITE-->
> > >                 <---180----
> > >   <--RINGING-
> > > (At this point, User 2 hears B ringing from C)
> > >                 <--------REGISTER--------
> > >                 -----------200---------->
> > >                 ----------INVITE-------->
> > >                 <--------RINGING---------
> > >                 <----------200-----------
> > >                 --CANCEL-->
> > > (yada yada)
> > >
> > > (In the above case, P is a forking proxy that CANCELs pending
> > > branches upon reception of a 200 response, and which also acts as
> > > a Registrar.)
> >
> > *** Now how does C know that it has to send the REGISTER request to P?
> 
> Blind faith. &:)
> 
> But seriously, this is where things potentially break-down, or not.
> Something like "Directed Pick-Up" (if indeed that is the correct
> term) does require some sort of sane configuration/application.

How is it done in the circuit switched world? After all, both phones
need to be part of the same PBX for this to work. Well, both terminals
are hard wired to the same PBX. You can think of that as the ultimate in
hardcoded configuration. The same is true here. As Jo has correctly
pointed out, the service works assuming that both phones are configured
to use the same proxy server.

Alex Hardisty writes:
> 2) Directed call pick-up requires me to enter the number of the telephone
> that is ringing, so am I entering the number of the UA or am I entering my
> personal number? If the latter it's not Directed Call Pickup but Personal
> User Mobility. What's the service definition here?

The service definition is whatever you want it to be. We here at IETF
don't specify services, but rather protocols to support services.

If the service you want is something as close as possible to existing
call pickup, you can do that. A terminal is typically associated with a
number, and would register itself as the handler for that number:

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

The phone for extension 4321 would normally send a similar registration:

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

when I am sitting at extension 4321, and hear 1234 ringing, and want to
pick it up, I would dial the appropriate service code and then enter the
extension I want to pick up. This would cause that phone to send an
additional register:

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

Now, this terminal begins to ring also and I can pick it up.

Note that the "smarts" for this service are actually distributed; some
of it is in the UA (which needs to know to send registers formatted this
way when implementing the directed pickup service), and some in the
proxy (which is doing normal registrations).

> One point I neglected to mention before was that this isn't
> exactly the same as "Directed Pick-Up" (in my experience of the
> term), anyway.  P may send an additional INVITE to C, but that
> doesn't mean that B stops ringing (indeed, I can imagine
> situations where that would be completely undesirable --
> preemptively registering a holiday address, for example -- since
> User 2's call would suddenly "disappear").  It's only once User 2
> picks up from C, that B _might_ stop ringing.

Correct. Note however, that causing the original terminal to stop
ringing can
also be achieved with some additional smarts in the phones, sending an
additional REGISTER to unregister the original address...

-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: (732) 741-7244
http://www.dynamicsoft.com

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 06 Jul 2000 13:13:37 -0700

Everyone involved in pickups could all use multicast for registrations and 
listen for registrations involving heir calls.  However, IMO it's much 
easier to set this up with a proxy.

This is a bit like saying "Here is how to protect stone, wood, brick, and 
steel buildings from huricanes", and then asking how to protect a grass hut 
from huricances.  You can do it, but it is hard.  If your goal is huricane 
protection, use building materials suitable for easily attaining your goal.

If you want SIP features and services requiring some centralized knowledge, 
take advantage of forking proxies.

thanks,
-rohan

---

From: Dale Tonogai <[email-masked]>
Date: Mon, 10 Jul 2000 09:10:24 -0700

I have a couple of questions on how this would work.

(1) How does the user agent know that the subsequent INVITE that it receives
is for
    the call that is being picked up?  I suppose you could look at the To
header, but
    the information may not be useful if the call had already been
forwarded.

(2) It seems a little odd that the user agent has to be ready to receive the
INVITE 
    for the picked up call even before it knows that its REGISTER request
was
    successful.  Since the REGISTER response could get lost, the INVITE
could arrive
    before the REGISTER transaction was completed.

Dale