[reSIProcate] CANCEL without To-tag not working

[Adam Roach]

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