Redirecting a ringing call to the contact
of an unregister message seems like
unobvious behavior to me. We got into
trouble for overloading the user of the
"contact" header, lets not do it again
with REGISTER.
The normal way to find an end point is
to use a proxy, but do proxies proxy
REGISTER requests? If not, you need
permission enough to register for
the "B" so you can learn his contacts.
Which one will you choose if there are
multiple? The proxy might be serial
forking.
If the "B" phone is deciding who has
permission to take calls, then do you have an
access list on each phone? How does
the phone validate requests?
Maybe radius or kerberos authentication would
let them use a central password database.
I suppose a central proxy could know the
password for each phone and help you
with the regstier after it validated you,
but SIP proxies can't retry requests with
additional authorization headers, so it
has to be a B2BUA. Please don't have
the proxy add authorization headers
to the URI using ?-delimiter. It would
only work for basic anyway.
The whole take stuff is not well defined in
SIP. You can't really do it with REFER because
you are working a deal with the call recipient not
originator.
When I write "take" in SIP I am meaning
contacting the UA leaving the call, unlike replaces
which contacts the staying UA.
Supposing the call originator was willing
using REFER, you still don't the call-id you need.
I don't know how to learn a call-id using only SIP.
Using SUBSCRIBE to sniff every packet
ahead of time doesn't seem workable to me.
Let us not forever grow SIP. How about using
a new separable layer for remote control
operation? and leave SIP to negotiating
media sessions.
--
Rick
On Wed, Feb 21, 2001 at 10:23:53PM +0100, Richard Verhoeven wrote:
>
> > The strategy does not scale well to non-directed
> > pickup. Are you suggesting to register for every phone
> > wishing to be pickup capable? Are you are assuming
> > a large memory capacity on each phone to monitor
> > so many call legs? Forking proxies have
> > trouble with PSTN gateways. The REGISTER
> > responses would grow very large with big
> > pickup groups, not fitting in unfragmented UDP.
> > The strategy totally breaks for redirect
> > servers or proxies which don't support
> > parallel forking.
> >
> > Other options include ....
> > 1) passing all calls through a B2BUA ahead of time.
> > Call it a PBX.
> > 2) using a remote control protocol to transfer
> > the call. The command would
> > probably come from a centralized server
> > which the phones trust. See
> > http://phonectl.sfour.com/
>
> When the client supports REGISTER requests, the Call Pickup
> can be done with a REGISTER request directly to the SIP
> client that is ringing. What is wrong with the following
> scenario:
>
> Client A calls client B. RP does Call Pickup.
>
> A -> B INVITE
> B -> A 180 Ringing
> RP-> B REGISTER
> B -> RP 200 OK
> B -> A 302 Moved Temporary
> A -> B ACK
> A -> RP INVITE
> RP-> A 200 OK
> A -> RP ACK
>
> With an expire time of zero seconds, the REGISTER request
> would not actually register anything, just cancel a possible
> registration. However, the client B is allowed to redirect
> the current call according to the information in the
> REGISTER request.
>
> In a call-center setting, client B could be a SIP server
> with queueing capabilities, where each REGISTER request
> would redirect the first call in the queue.
>
> Richard Verhoeven.
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
