I kind of agree with both of you in that "lets not forever grow SIP" and
perhaps use a separate layer for "remote control operation". However, being
a newbie to SIP, I would like some comments on why the following scenario
may not work.
(1) Lets say that User A issued an INVITE to User B.
(2) User B returns 100 TRYING followed by 180 RINGING.
(3) User C which wants to pick up the User B, sends a REFER (through a proxy
server who has the session context and is able to idenitfy the Call-ID that
is needed) to User B.
(4) The receipt of REFER will cause User B to issue an INVITE to C that
contains all the SDP info for media setup.
(5) User C returns a NOTIFY to User B so that the "ringing" signal is
removed.
(6) Further, User C sends a 200 OK to User A. which was actually waiting for
an 200 OK from User B.
User A at that point establishes the RTP session and User A and User C are
active in a conversation.
Comments!!
Satish
-----Original Message-----
From: James Undery [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 22, 2001 2:45 AM
To: Rick Dean
Cc: Richard Verhoeven; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [Sip-implementors] SIP and Call Pickup
Rick Dean wrote:
>
> 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.
>
I'll agree with Rick here, this has minimal place in base SIP, my choice
for the solution would be to use CPL at the proxy to forward on no
answer. This solution doesn't model the PSTN behaviour exactly, however,
in my opinion solves the underlying problem better.
Directed pickup also causes problem when multiple proxies are handling
one domain as they would all have to be notified of the change in
registration in case they were handling a call for which this was a
directed pickup.
James Undery
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
