Subject: [SIP] on directed pick up service

From: "rafi" <[email-masked]>
Date: Wed, 5 Jul 2000 17:57:55 +0530

Hi,

        I am trying to understand how "directed pick up" service
can be achieved using SIP. RFC 2543 mentions following 
paragraph regarding this

   " If a registration is changed while a user agent or proxy server
processes an invitation, new information SHOULD be used "

   Now consider the following scenario

  A -------------------B  ----------------C
 (user 1)          (user 2)          (user 2 currently  present here )

 User 1 at  A is calling  user 2  at  B who is  currently present at C.
 Initially an  INVITE message is send to B which process the message.
 User 2 who is currently at C  comes to know about the call at C(How
exactly  C comes to know  that a call for him is pending at B is not known
 to me).  User 2 now changes his registration so that he can receive call at C.
 But how  A come to know about that  without releasing current call it not clear
 to me. Can someone help me in understanding this ?  I know  I am missing
some point here.

Thank You
Rafi Assadi H.M.
Silicon Automation Systems
Bangalore, INDIA

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 5 Jul 2000 13:51:40 +0100

> exactly  C comes to know  that a call for him is pending at B is not
> known to me).

One example is that User 2 hears B ringing.

> User 2 now changes his registration so that he can
> receive call at C.  But how  A come to know about that without
> releasing current call it not clear to me. Can someone help me in
> understanding this ?  I know  I am missing some point here.

Yes, you are missing a point -- the call has to be made through a
proxy. &:)

(Actually, that's probably not entirely true.  If the registration
was made over multicast, for instance, A could have listened.  And
no doubt there's lots of other ways similar results could be
achieved.)

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

HTH,

 - Jo.

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

---

From: "Alex Hardisty" <[email-masked]>
Date: Wed, 5 Jul 2000 15:25:06 +0100

Jo,

> Yes, you are missing a point -- the call has to be made through a

Is it as simple as you make it sound?

1) How do I know which proxy to send my pick-up request (the REGISTER in
your example) to? Surely, I'd want to send it to the UA that I can hear
ringing?

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?

> A --INVITE--> P             B --INVITE--> C

In your example I don't understand why B sends an INVITE to C before it
receives the INVITE from the proxy.

--
Alex Hardisty
PQM Consultants

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 5 Jul 2000 15:58:21 +0100

> Is it as simple as you make it sound?

Well, no doubt it can be far more convoluted; I was representing
a simple case that required nothing outsida 2543.

> 1) How do I know which proxy to send my pick-up request (the REGISTER
> in your example) to? Surely, I'd want to send it to the UA that I can
> hear ringing?

The thing is, it's not a "pick-up request"; it's using existing
SIP mechanisms to achieve an affect similar to directed pick-up.

Now, of course, it would be possible to define some method,
or something, which B could act upon, but that would require
extensions.  It would also be possible just to use existing SIP
mechanisms in the same way, and allow A to act as a registrar
(this is similar to the listening to multicast I mentioned).

All of these methods have their pros and cons, and no doubt
I've missed a plethora of other options.

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

Now you're exposing my ignorance of "convential telephony" (IN?)
terminology.  Apologies.

The REGISTER request sent in this case would probably typically
be the SIP URL seen by the proxy in the INVITE request, which
would be "Personal User Mobility", I guess.  That need not
necessarily be the case, however, if the proxy is clever enough
to notice that the SIP URL it had resolved to had been given a
new registration (this would be "Directed Call Pickup"?).

> receives the INVITE from the proxy.

You got me (it shouldn't be there)! &:)

Not that I was using it for spacing, or anything...

 - Jo.

---

From: "Krishna G" <[email-masked]>
Date: Wed, 5 Jul 2000 21:32:03 +0530

Hi Jo,

    I have not understood a few things in UR response. Please find my
questions embedded below some specific points of UR response.

> One example is that User 2 hears B ringing.

*** What R the other ways? What is the purpose of the INVITE from B to C in
UR call flow diagram?

> A --INVITE--> P             B --INVITE--> C

*** Now how does C know that it has to send the REGISTER request to P? What
should the user do if the Registrar entity he has registered with is
diferent from the Proxy (P in UR example)? Lets assume that the Proxy P is
the Registrar for the user. Now are U saying that the Proxy/Registrar entity
(P in UR example) should check if it has sent an INVITE message to the user
from whom it has received a REGISTER. If it has, then it should send another
INVITE message, this time to C?

Could U please clarify the above things.

Thanks and Regards,

Krishna G.

---

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 5 Jul 2000 17:26:17 +0100

> *** What R the other ways?

I don't know -- could be literally anything (although some, such
as another "telephone call", might defeat the purpose...).

Being paged (over some sort of PA system) might be another example.

> What is the purpose of the INVITE from 
> B to C in
> UR call flow diagram?

To once-again reaffirm that I'm a complete muppet. &:)

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

The best analogy I can think of is of a small office that has their
own Telephone Switch.  All inbound calls to that office go through
this Switch.  Now if you replace that Switch with a Proxy, then
hopefully things become a little clearer.  This scenario does require
all the appropriate admistration/configuration of the Proxy being
the only entry point onto the SIP "network", and that all UAs in
the office use that Proxy as their Registrar.

> What should the user do if the Registrar entity he has
> registered with is diferent from the Proxy (P in UR example)?

Caveat: as long as User 2 is allowed to register from C, that isn't
really a problem; a UA can register with multiple registrars.

> Lets assume that the Proxy P is the Registrar for the user. Now
> are U saying that the Proxy/Registrar entity (P in UR example)
> should check if it has sent an INVITE message to the user
> from whom it has received a REGISTER. If it has, then it should 
> send another INVITE message, this time to C?

Yes.  That's exactly it.

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.

 - Jo.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 05 Jul 2000 10:44:59 -0700

Rafi,  et al.

Presumably, A sent the call to a (forking) proxy acting on behalf of 
user2.  Presumably the proxy has access to changes in registrations, either 
directly or through some event notification process.

when user2's proxy gets a REGISTER for user2 from C, it should extend an 
INVITE to C based on this new information.  it could also CANCEL the INVITE 
to B, or just allow both to proceed until either B or C sent a final response.

user2 knows to send the REGISTER to that proxy preumably because there was 
a button (for example) on the phone associated with a URL, which happened 
to be a register for user2.

if you wanted to do directed pickup, you would collect the userinfo portion 
of the register and insert that in the URL, and you would probably make the 
Expires header time very short.

thanks,
-rohan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jul 2000 00:16:57 -0400

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

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

> 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: "Alex Hardisty" <[email-masked]>
Date: Thu, 6 Jul 2000 10:20:50 +0100

> don't specify services, but rather protocols to support services.

But don't you have to know what the service is and how it behaves before you
can define the protocol to support it? Or at least, have some specification
of the characteristics of the group of services for which you want to define
a general protocol?

To me this lack of service descriptions appears to be a weakness of the IETF
approach. If I buy SIP phones from one vendor, a SIP PBX from another vendor
and a SIP based voicemail server from somewhere else, how can I be sure of
interoperability between them? How can I be sure they will handle, for
example, call transfer, call forwarding, and message waiting in a consistent
manner?

What happens as the services start to become more complex, perhaps involving
many different server types? Services in the mobility area (both terminal
and personal mobility) typically involve upto 8 different functional
entities with many detailed information flows between them. If there is no
specification for how the service should work, how will a major corporation
establish a Worldwide service to provide corporate mobility with equipment
sourced from several vendors?

--
Alex Hardisty
PQM Consultants

---

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

Alex,

How can you be sure you will get these interoperable features using the ITU 
approach?  You can't.  The H.323 family of protocols has specified 
individual features in the H.450 series, however very few vendors have 
bothered to implement most of this because it is a lot of work for each 
additional feature.  In other words, there is very little market incentive 
to build new services using this approach.

Now compare that to the Internet. If someone wants a new service, they 
build it.  Perhaps they need to extend an existing protocol, so they write 
an Internet Draft on it.  If the service is compelling, then people will 
use the service.  If people use the service, others will build in support 
for the service, or offer a competing service.  Service A may not work 
exactly like service B, but user A may pick service B because they like the 
way it works.

To be more specific to this example, a few folks on the list wrote about 
how you could implement "xyz" feature *without changing the exisiting 
protocol*.  That should be clue #1 that something good is going on.  Now 
you can go ask vendors for "xyz" feature on their UA, xyz registration 
feature on the proxy, xyz tool for easily administering this, etc.  You can 
do it yourself, you can go to one vendor, you can hire an integrator to do 
that work, whatever you want.

thanks,
-rohan

---

From: "Alex Hardisty" <[email-masked]>
Date: Mon, 10 Jul 2000 15:22:53 +0100

Rohan,

Firstly, thanks for your reply ... and thanks also to the other people that
replied before. I'm quite new to the IETF way of doing things, although not
to Telecoms Standardization. This discussion is therefore quite educational
for me. Coming from a background of developing pure telephony services for
PBXs and of writing Standards in ECMA for QSIG supplementary services, I do
not yet find the IETF approach entirely natural. However, I'm beginning to
see some of the benefits it offers.

ECMA's approach (please note that I didn't mention ITU-T and H.323) in
specifying protocols for QSIG services (such as Call Forwarding and Call
Transfer) has been to ensure that only the minimum requirements for
achieving multi-vendor interworking are specified, and in such a way that
each implementor is free to add value to the service itself as seen by the
user. This approach does not appear too different from what IETF does and it
is not without its commercial success. It has still proved to be beneficial
to spend a little time understanding what the users are going to want to
achieve with a particular service or group of services before looking at the
existing, established protocol and working out how, if at all, it needs to
be extended to support the service(s). In no way does such activity
constrain the protocol to only supporting services that we think of or agree
to today.

Regards
--
Alex Hardisty
PQM Consultants