< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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