3 May
2010
3 May
'10
1:32 p.m.
2010/5/3 Henning Westerholt <henning.westerholt(a)1und1.de>de>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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.