Re: [reSIProcate] CANCEL without To-tag not working
Thanks for the clarification Adam, nice to hear that my concerns for the
stack was unjustified.
The UA is apparently some simple analog phone adapter, so we'll pass
this on to the vendor.
Thanks again
Björn A.
On Fri, 2010-02-19 at 08:19 -0600, Adam Roach wrote:
> 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