12 May
2012
12 May
'12
9:21 a.m.
i have been wondering why kamailio refuses to forward bye to $du
sip:192.26.99.39:8000;transport=tcp;lr;ftag=a8266461a81c723o0
wireshark shows that it is not even trying to set up tcp connection to
the destination and with telnet i can verify that tcp connection can be
set up.
debug at level 3 is below.
-- juha
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: rr [loose.c:776]: URI to be
processed: 'sip:192.26.99.39:8000;transport=tcp;lr;ftag=a8266461a81c723o0'
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: rr [loose.c:785]: Next URI is a
loose router
...
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_lookup.c:1379]: DEBUG:
t_newtran: msg id=5 , global msg id=5 , T on entrance=(nil)
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_lookup.c:527]:
t_lookup_request: start searching: hash=30919, isACK=0
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_lookup.c:485]: DEBUG:
RFC3261 transaction matching failed
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_lookup.c:709]: DEBUG:
t_lookup_request: no transaction found
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_hooks.c:374]: DBG:
trans=0xb486de58, callback type 1, id 0 entered
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: <core> [md5utils.c:67]:
DEBUG: MD5 calculated: d28c87700c1c48b71a3b7f63090bf160
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: <core> [dns_cache.c:3400]:
dns_sip_resolve(192.26.99.39, 0, 0), ip, ret=0
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: <core>
[msg_translator.c:204]: check_via_address(192.98.100.135, 192.168.0.145, 0)
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: ERROR: tm [../../forward.h:171]:
msg_send: ERROR: tcp_send failed
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_fwd.c:1365]: t_send_branch:
send to 192.26.99.39:8000 (2) failed
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: ERROR: tm [t_fwd.c:1383]: ERROR:
t_send_branch: sending request on branch 0 failed
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_funcs.c:361]:
ERROR:tm:t_relay_to: t_forward_nonack returned error
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_funcs.c:369]: -477 error
reply generation delayed
14 May
14 May
5:39 p.m.
Hello,
one possibility could be no-connect/connection-reuse option set in
cofig, could it be in your case?
Cheers,
Daniel
On 5/12/12 3:21 PM, Juha Heinanen wrote:
i have been wondering why kamailio refuses to forward
bye to $du
sip:192.26.99.39:8000;transport=tcp;lr;ftag=a8266461a81c723o0
wireshark shows that it is not even trying to set up tcp connection to
the destination and with telnet i can verify that tcp connection can be
set up.
debug at level 3 is below.
-- juha
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: rr [loose.c:776]: URI to be
processed: 'sip:192.26.99.39:8000;transport=tcp;lr;ftag=a8266461a81c723o0'
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: rr [loose.c:785]: Next URI is a
loose router
...
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_lookup.c:1379]: DEBUG:
t_newtran: msg id=5 , global msg id=5 , T on entrance=(nil)
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_lookup.c:527]:
t_lookup_request: start searching: hash=30919, isACK=0
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_lookup.c:485]: DEBUG:
RFC3261 transaction matching failed
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_lookup.c:709]: DEBUG:
t_lookup_request: no transaction found
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_hooks.c:374]: DBG:
trans=0xb486de58, callback type 1, id 0 entered
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: <core> [md5utils.c:67]:
DEBUG: MD5 calculated: d28c87700c1c48b71a3b7f63090bf160
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: <core> [dns_cache.c:3400]:
dns_sip_resolve(192.26.99.39, 0, 0), ip, ret=0
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: <core>
[msg_translator.c:204]: check_via_address(192.98.100.135, 192.168.0.145, 0)
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: ERROR: tm [../../forward.h:171]:
msg_send: ERROR: tcp_send failed
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_fwd.c:1365]: t_send_branch:
send to 192.26.99.39:8000 (2) failed
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: ERROR: tm [t_fwd.c:1383]: ERROR:
t_send_branch: sending request on branch 0 failed
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_funcs.c:361]:
ERROR:tm:t_relay_to: t_forward_nonack returned error
May 12 15:58:30 sars /usr/sbin/sip-proxy[25453]: DEBUG: tm [t_funcs.c:369]: -477 error
reply generation delayed
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
15 May
15 May
2:29 a.m.
Daniel-Constantin Mierla writes:
one possibility could be no-connect/connection-reuse
option set in
cofig, could it be in your case?
i have not set any such parameters in config. i'm
calling set_forward_no_connect() on some requests, but never on
in-dialog requests.
could it be that set_forward_no_connect() has effect also on subsequent
requests?
i have not found a corresponding call to turn connect mode back on after
calling set_forward_no_connect() which i guess means that it has effect
only during the next transaction.
-- juha
3:48 a.m.
Hello,
On 5/15/12 8:29 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
the flag should not have effect for other
requests, unless you set the
global parameter, but not when you use the function.
To troubleshoot, the code of tcp_send() has to be checked and see where
it returns error code without a debug message. Is this often or
occasionally?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
one possibility could be
no-connect/connection-reuse option set in
cofig, could it be in your case?
i have not set any such parameters in config.
i'm
calling set_forward_no_connect() on some requests, but never on
in-dialog requests.
could it be that set_forward_no_connect() has effect also on subsequent
requests?
i have not found a corresponding call to turn connect mode back on after
calling set_forward_no_connect() which i guess means that it has effect
only during the next transaction.
4:05 a.m.
Juha Heinanen writes:
i have been wondering why kamailio refuses to forward
bye to $du
sip:192.26.99.39:8000;transport=tcp;lr;ftag=a8266461a81c723o0
wireshark shows that it is not even trying to set up tcp connection to
the destination and with telnet i can verify that tcp connection can be
set up.
i did more tests and it turned out to be my mistake in the script. i
had called set_forward_no_connect() on bye.
sorry about the noise.
-- juha
4:08 a.m.
Hello,
On 5/15/12 10:05 AM, Juha Heinanen wrote:
Juha Heinanen writes:
I wonder if would be better we to catch this situation and print a more
descriptive error message (or even make it a warning/info)...
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
i have been wondering why kamailio refuses to
forward bye to $du
sip:192.26.99.39:8000;transport=tcp;lr;ftag=a8266461a81c723o0
wireshark shows that it is not even trying to set up tcp connection to
the destination and with telnet i can verify that tcp connection can be
set up.
i did more tests and it turned out to be my mistake in the script. i
had called set_forward_no_connect() on bye.
sorry about the noise.
4611
days inactive
4614
days old
5 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Juha Heinanen