[SR-Users] Wrong handling CANCEL message

[Henning Westerholt]

On Monday 03 May 2010, Iñaki Baz Castillo wrote:
> > We just drop them. In the sr configuration i think there is also a
> > similar method implemented (etc/sip-router.cfg, route[CATCH_CANCEL]). In
> > the past on our systems we've tried to forward them stateless, but this
> > created some loop conditions, if i remember correctly. Sending a final
> > response to the CANCEL (e.g. 491) also not worked out really well.
> 
> Hi Henning, the problem is that the transaction still remains in
> memory for a while after the 200 has been routed (this is correct
> according to invfix draft which covers a bug in RFC 3261). So the
> CANCEL  after the 200 *does* match the transaction in TM and then
> kamailio replies 200 for the CANCEL (which doesn't make sense as there
> is nothing to cancel).
> 
> After the proxy relays the 200 for the INVITE the transaction gets in
> "Accepted" state (draft invfix) for a while. During this state a
> CANCEL would match the transaction but it shouldn't generate a 200 for
> such CANCEL (it's better to ignore it or reply 481).

Hi Iñaki,

ah, i thought you refer here to the general handling of CANCEL messages. Now 
it makes more sense for me, thanks for the clarification.

Cheers,

Henning