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 _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
