[Users] CANCEL problem

[Bogdan-Andrei Iancu]

Hi guys,

Klaus Darilion wrote:

> What is the correct behavior in this scenario?
>
> As the proxy didn't received a "100.." yet, it must not send the 
> CANCEL. IMO it should withhold the CANCEL unless a provisional 
> response is received, but should stop sending INVITE retransmission.
>
> Of course this rises the problem that the callee reponses with a 200 
> OK instead of a provisional response and then the call can't be 
> cancelled anymore.


This is a well known race which may happen in SIP flows even in direct 
UAC to UAS configuration (without any middle entity). The 200 OK (from 
UAS) and the CANCEL (from UAC) may cross one the way....
This kind of race can be detected and solved only by the end points (UAs):
    if a UAC sent CANCEL and receives 200 OK -> it should generate a BYE
    if a UAS sent 200 OK and received a CANCEL -> it should also 
generate a BYE.
basically the race may be detected only by on of the end-points (which 
will also trigger the BYE), but for safety reason (since the 
"intelligence" of other party is not known), both parties should try to 
BYE the call if race was detected.

This is not RFC specified, but IMHO, it's the way it should be solved.

regards,
bogdan

>
> regards,
> klaus
>
> btw: I think this should be fixe in openser (in opposite to ser)
> http://openser.org/diffs-0.8.14.php (TM module)
>
> Michael Ulitskiy wrote:
>
>> Hello,
>>
>> I found something that I believe is problem with CANCEL processing in tm
>> module. I'm using openser 0.10.x today's cvs.
>> If openser forwards an INVITE and then it receives CANCEL before
>> it receives a provisional reply from INVITE recipient, it never 
>> forwards CANCEL
>> to its destination.
>> CANCEL is handled the same way as INVITE and I'm sure it hits t_relay().
>> Here's relevant part of the config:
>>
>> xlog("L_INFO","$rm: cseq=$cs: ruri=$ru received from $si:$sp\n");
>> if (allow_trusted()) {
>>            if (!lookup("location")) {
>>                    xlog("L_INFO","$rm: cseq=$cs: $ru: not found\n");
>>                    sl_send_reply("404","Not found");
>>                    exit;
>>            }
>>            xlog("L_INFO","$rm: cseq=$cs: lookup: $ru flags: $mF\n");;
>>            route(1);
>>            exit;
>> }
>> if (uri==myself) {
>>            rewritehost("192.168.80.26");
>>            route(1);
>> }
>>
>> route[1]
>> {
>>  xlog("L_INFO","$rm: cseq=$cs: $ru: RELAYING to $du (flags: $mF)...\n");
>>         if (!t_relay()) {
>>                 xlog("L_NOTICE","$rm: cseq=$cs: ERROR: t_relay 
>> failed\n");;
>>                 if (!is_method("ACK")) {
>>                    sl_reply_error();
>>                 }
>>         };
>> }
>>
>>
>> Here's ser log:
>>  0(1015) INVITE: cseq=102: ruri=sip:xyz_100_1_st2 at 192.168.83.61 
>> received from 192.168.80.26:5060
>>  0(1015) INVITE: cseq=102: lookup: 
>> sip:xyz_100_1_st2 at 192.168.0.249:5060 flags: 00000040
>>  0(1015) INVITE: cseq=102: sip:xyz_100_1_st2 at 192.168.0.249:5060: 
>> RELAYING to sip:192.168.76.250:1058 (flags: 00000040)
>>  0(1015) CANCEL: cseq=102: ruri=sip:xyz_100_1_st2 at 192.168.83.61 
>> received from 192.168.80.26:5060
>>  0(1015) CANCEL: cseq=102: lookup: 
>> sip:xyz_100_1_st2 at 192.168.0.249:5060 flags: 00000040
>>  0(1015) CANCEL: cseq=102: sip:xyz_100_1_st2 at 192.168.0.249:5060: 
>> RELAYING to sip:192.168.76.250:1058 (flags: 00000040)
>>  0(1015) ACK: cseq=102: ruri=sip:xyz_100_1_st2 at 192.168.83.61 received 
>> from 192.168.80.26:5060
>>  0(1015) <null>: cseq=102: onreply_route_log: received: 100 Trying 
>> from 192.168.76.250:1058
>>  0(1015) <null>: cseq=102: onreply_route_log: received: 180 Ringing 
>> from 192.168.76.250:1058
>>
>> I've replaced ip addresses with 192.168.x.x, but recipient is behind 
>> NAT. As you can see according to this log CANCEL is getting relayed, 
>> but ngrep actually shows that it's not sent and
>> invited client sends "Trying", then "Ringing".
>> It happens only if INVITE is already forwarded and CANCEL is received 
>> before any provisional reply.
>> If CANCEL happens after openser received "100 Trying", everything 
>> works fine and call is cancelled.
>> It looks to me as a bug or some kind of race.
>> Any clues?
>>
>> Thanks,
>> Michael
>>
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>