11 Jun
2009
11 Jun
'09
1:33 p.m.
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(a)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
11 Jun
11 Jun
2:18 p.m.
On Jun 11, 2009 at 13:33, Juha Heinanen <jh(a)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(a)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
3:18 p.m.
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
5647
days inactive
5647
days old
2 comments
2 participants
participants (2)
-
Andrei Pelinescu-Onciul -
jh＠tutpro.com