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:[EMAIL PROTECTED] received from > > 192.168.80.26:5060 > > 0(1015) INVITE: cseq=102: lookup: sip:[EMAIL PROTECTED]:5060 flags: > > 00000040 > > 0(1015) INVITE: cseq=102: sip:[EMAIL PROTECTED]:5060: RELAYING to > > sip:192.168.76.250:1058 (flags: 00000040) > > 0(1015) CANCEL: cseq=102: ruri=sip:[EMAIL PROTECTED] received from > > 192.168.80.26:5060 > > 0(1015) CANCEL: cseq=102: lookup: sip:[EMAIL PROTECTED]:5060 flags: > > 00000040 > > 0(1015) CANCEL: cseq=102: sip:[EMAIL PROTECTED]:5060: RELAYING to > > sip:192.168.76.250:1058 (flags: 00000040) > > 0(1015) ACK: cseq=102: ruri=sip:[EMAIL PROTECTED] 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 > > [email protected] > > http://openser.org/cgi-bin/mailman/listinfo/users > > > > > > _______________________________________________ Users mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/users
