2010/5/3 Henning Westerholt henning.westerholt@1und1.de:
16.10 CANCEL Processing [...] If a response context is not found, the element does not have any knowledge of the request to apply the CANCEL to. It MUST statelessly forward the CANCEL request (it may have statelessly forwarded the associated request previously).
Hi Iñaki,
ok, but i think in the default server configuration we don't do it this way:
if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; }
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).
Regards.
PS: I've open a thread in sip-implementors about this topic.