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