[Users] CANCEL problem

[Michael Ulitskiy]

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: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
> > 
> > 
> 
>