[Users] CANCEL problem

[Michael Ulitskiy]

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