Hi Klaus, I guess, you're right. I didn't know that. Then openser should keep CANCEL in transaction context until transaction expires (probably until wt_timer expires) and transmit it if provisional response is received during that time. Thanks for clarification.
Michael On Tuesday 02 August 2005 07:52 pm, you wrote: > 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:[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 > > > > > > _______________________________________________ Users mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/users
