[Users] CANCEL problem

[Klaus Darilion]

Hi Michael!

RFC3261 page 54:
If no provisional response has been received, the CANCEL request MUST
    NOT be sent; rather, the client MUST wait for the arrival of a
    provisional response before sending the request.


Thus, the proxy should withhold the CANCEL until a provisional response 
is received. If no provisional response is received for a certain time, 
the proxy may discard the whole transaction.

Also take a look at section 16.10 and section 16.7 step 10.

regards
klaus

Michael Ulitskiy wrote:
> On Tuesday 02 August 2005 06:25 pm, you 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.
> 
> 
> I must confess, I didn't read RFC specifically on this subject, but behavior
> you described makes no sense to me. If proxy didn't cancel the call the callee
> keeps ringing forever.
> 
> 
> 
>>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.
> 
> 
> it's not the case here. UA replies correctly with 100, but a little too late.
> It was my understanding that CANCEL should be forwarded to cancel a call
> regardless of receiving any response. Please correct me if I'm wrong.
> 
>  
> 
>>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
> 
>