[sr-dev] cancel/ack problems

[Andrei Pelinescu-Onciul]

On Jun 11, 2009 at 13:33, Juha Heinanen <jh at tutpro.com> wrote:
Content-Description: message body text
> now that db issues have been solved, i tried make a call.  twinkle user
> test called twinkle user jh, but before jh answered, test canceled the
> call.  i got to syslog:
> 
> Jun 11 13:03:31 localhost /usr/sbin/sip-router[1727]: INFO: INVITE <sip:jh at test.fi> by <test at test.fi> as <sip:test at test.fi> from <192.98.101.10> is authorized
> Jun 11 13:03:31 localhost /usr/sbin/sip-router[1727]: INFO: Routing first INVITE to <sip:jh_test_fi at 192.98.101.10:5074;transport=udp> and <<null>>
> Jun 11 13:03:33 localhost /usr/sbin/sip-router[1726]: INFO: Relaying CANCEL to <sip:jh at test.fi>
> Jun 11 13:03:33 localhost /usr/sbin/sip-router[1727]: INFO: Routing in-dialog ACK from <sip:test at test.fi> to <sip:jh at test.fi>
> Jun 11 13:03:33 localhost /usr/sbin/sip-router[1727]: WARNING: tm [t_lookup.c:1499]: WARNING: script writer didn't release transaction
> Jun 11 13:03:33 localhost /usr/sbin/sip-router[1727]: NOTICE: Discarding unmatched ACK <sip:jh at test.fi>
> 
> with same config file, kamailio doesn't give the warning about not
> releasing transaction nor notice about unmatched cancel.

The releasing transaction warning is printed because somehow a
transaction was created or looked up in the script and then nothing was
done with it (e.g. no t_release(), t_reply() or t_relay()), which
 looks like a script error.
You might have a t_newtran() somewhere in the script, or the
!t_check_trans() check might be malfunctioning, but I can't tell without
seeing the script (or at least knowing what other t_*() functions are
used before t_check_trans()).

> 
> notice comes from this:
> 
> 	# Relay CANCEL without further processing
> 	if (is_method("CANCEL")) {
> 		if (!t_check_trans()) {
> 			xlog("L_NOTICE", "Discarding unmatched CANCEL to <$ru>\n");
> 			exit;
> 		};

That's strange, the notice is about an ACK and the script fragment here
deals with a CANCEL.

> 
> why is cancel not matched?  in case mailing list accepts attachments,
> wireshark dump (which looks good to me), is enclosed.

Is it a CANCEL or an ACK? Could you send me the whole log with maximum
debugging? (there are some DBG()s in tm that might help)

Andrei