[Kamailio-Devel] [ openser-Bugs-2711585 ] t_relay() reports errors when there is none

SourceForge.net noreply at sourceforge.net
Tue Apr 14 17:44:23 CEST 2009

Bugs item #2711585, was opened at 2009-03-25 10:40
Message generated for change (Comment added) made by henningw
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: t_relay() reports errors when there is none

Initial Comment:
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 at;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 at 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 at 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


>Comment By: Henning Westerholt (henningw)
Date: 2009-04-14 15:44

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.


Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-03-30 11:00

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.


Comment By: Nobody/Anonymous (nobody)
Date: 2009-03-30 09:50

yes please.  ERROR and CRITICAL level messages should be reserved to errors
in the code, running out of resources, etc. serious situations.


Comment By: Daniel-Constantin Mierla (miconda)
Date: 2009-03-30 09:38

Do you want these errors suppressed?


You can respond by visiting: 

More information about the Devel mailing list