Re: [reSIProcate] CANCEL without To-tag not working
On 2/19/10 03:11, Feb 19, Bjorn Andersson wrote:
Thanks Scott, I now realize that this has nothing to do with To-tag,
here is the problem:
UA sends an INVITE with a procedure code to initiate call diversion, and
our system responds with a 200 Ok to connect it to the gateway for
playing an acknowledgment message. The UA does not like a 200 Ok without
a prior provisonal and sends CANCEL:
-- IMVITE ->
<- 200 Ok -- (state UAS_Accepted)
-- CANCEL -> ServerInviteSession::dispatchAccepted resends 200 OK
<- 200 OK --
Is this really the right thing to do? Shouldn't the UA be allowed to
cancel in this phase (no ACK has been sent)?
Nope. Once the 200 has hit the wire, the die is cast.
One thing most people don't fully understand is that "CANCEL" is a
suggestion -- a hint, really -- to end the INVITE transaction without
any additional delay. In fact, it would be perfectly valid for the order
of events to look like:
-- INVITE -->
<-- 183 -----
-- CANCEL -->
<-- 200 ----- (response to CANCEL)
<-- 200 ----- (response to INVITE)
When you send a CANCEL, you must wait for the response to the INVITE to
find out what really happened. And if a session was set up when you
don't want one, it is up to the calling user agent to send a BYE.
I'm also boggled that there is a device out there that has problems with
a final response before a provisional response. Are you sure that's what
it is really having trouble with?
/a