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@test.fi by test@test.fi as sip:test@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@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@test.fi Jun 11 13:03:33 localhost /usr/sbin/sip-router[1727]: INFO: Routing in-dialog ACK from sip:test@test.fi to sip:jh@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@test.fi
with same config file, kamailio doesn't give the warning about not releasing transaction nor notice about unmatched cancel.
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; };
why is cancel not matched? in case mailing list accepts attachments, wireshark dump (which looks good to me), is enclosed.
-- juha
On Jun 11, 2009 at 13:33, Juha Heinanen jh@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@test.fi by test@test.fi as sip:test@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@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@test.fi Jun 11 13:03:33 localhost /usr/sbin/sip-router[1727]: INFO: Routing in-dialog ACK from sip:test@test.fi to sip:jh@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@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
Andrei Pelinescu-Onciul writes:
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()).
andrei,
for the initial invite, i call t_next_contacts(), set t_on_branch, t_on_reply, t_on_failure and call t_relay().
then when cancel comes, i call t_check_trans() followed by t_relay().
for ack from twinkle to 478, i call t_check_trans() and call t_relay().
for some reason t_relay doesn't seem to notice that this ack belongs to transaction and relays it back to itself at which point i get notice about unmatched ack (sorry the error in my previous message).
i don't call t_newtrans() anywhere.
i'll turn on debug to get more info.
-- juha
-
Andrei Pelinescu-Onciul -
jh＠tutpro.com