[SR-Users] Wrong handling CANCEL message

[Iñaki Baz Castillo]

2010/5/3 Henning Westerholt <henning.westerholt at 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.

-- 
Iñaki Baz Castillo
<ibc at aliax.net>