Menu
▾
▴
#565 t_relay() reports errors when there is none
if destination is not reachable, t_relay() reports to syslog, when where is none. for example,
Mar 25 12:33:09 taimen /usr/sbin/kamailio[26385]: INFO: Routing first INVITE to <sip:jh@192.98.102.10:5555;transport=tcp> and <<null>>
Mar 25 12:33:14 taimen /usr/sbin/kamailio[26385]: ERROR:core:tcp_blocking_connect: timeout 5 s elapsed from 5 s
Mar 25 12:33:14 taimen /usr/sbin/kamailio[26385]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed
Mar 25 12:33:14 taimen /usr/sbin/kamailio[26385]: ERROR:core:tcp_send: connect failed
Mar 25 12:33:14 taimen /usr/sbin/kamailio[26385]: ERROR:tm:msg_send: tcp_send failed
Mar 25 12:33:14 taimen /usr/sbin/kamailio[26385]: ERROR:tm:t_forward_nonack: sending request failed
and in case name does not resolve:
Mar 25 12:39:28 taimen /usr/sbin/kamailio[26387]: INFO: Routing next INVITE to <<sip:jh@foo.bar>;q=0>
Mar 25 12:39:28 taimen /usr/sbin/kamailio[26387]: CRITICAL:core:mk_proxy: could not resolve hostname: "foo.bar"
Mar 25 12:39:28 taimen /usr/sbin/kamailio[26387]: ERROR:tm:uri2proxy: bad host name in URI <sip:jh@foo.bar>
Mar 25 12:39:28 taimen /usr/sbin/kamailio[26387]: ERROR:tm:t_forward_nonack: failure to add branches
Mar 25 12:39:28 taimen /usr/sbin/kamailio[26387]: ERROR:tm:w_t_relay: t_forward_nonack failed
errors must only be reported, when there is an error in the code.
-- juha
Do you want these errors suppressed?
yes please. ERROR and CRITICAL level messages should be reserved to errors in the code, running out of resources, etc. serious situations.
I agree on it.
Imagine a phone registered via TCP that is switched off without sending a un-REGISTER. Any request to this user would generate ERROR and CRITICAL logs about TCP connection.
In most of the deployments SIP TCP is not very extended and the above scenario with UDP doesn't generate ERROR/CRITICAL logs.
I think these logs should be converted to WARN.
While i agree that the tm errors could be decreased to the WARN level, i don't think that its a good idea to generally suppress core network connection problems or DNS resolution failures. The WARN level is too noisy for some production setups, so people will use the ERROR level for logging.