4 May
2010
4 May
'10
11:08 a.m.
On Monday 03 May 2010, Iñaki Baz Castillo wrote:
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
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).