Hi all,
I have Kamailio set as an SBC with freeswitch behind - that all works fine. Freeswitch can send calls out VIA Kamailio to external IP address’, but if I try sending a call to another IP hosted by Kamailio the seems to go nowhere…
Supplier -> Kamailio -> Customer1 -> Kamailio -> Customer2
The Kamailio server has multiple assigned IPs, which are used to multi-tennant - but I cant for the like of me to get Tennant to tenant calls to work (via freeswitch)
Any pointers?
Hi,
1. Do you have a listener (listen=) for all necessary IPs and transports?
2. Outbound interface selection is done either via the 'mhomed' option,
https://www.kamailio.org/wiki/cookbooks/5.0.x/core#mhomed
or, if it's not doing what you want, by manually steering it via $fs:
https://www.kamailio.org/wiki/cookbooks/5.0.x/pseudovariables#fs_-_forced_so...
-- Alex
On Fri, Nov 03, 2017 at 02:04:37PM +0000, Oz Mortimer wrote:
I have listen commented out - which means it listens on all IPs (doesn’t it?) - do I need to set them explicitly?
Try setting them explicitly, so that you can route them explicitly.
I did add mhomed=1 on this setup - but the calls went a bit crazy (I didn’t manage to capture quite what was happening).
Unfortunately, without knowing the specific facts, it's hard to speculate.
Ok - did that and got the same error, though this time I looked at what it was; Im /var/log/messages I see - Nov 3 14:13:28 IS-56434 kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve xxx.xxx.xxx.xxx Nov 3 14:13:28 IS-56434 kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve xxx.xxx.xxx.xxx Nov 3 14:13:28 IS-56434 kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve xxx.xxx.xxx.xxx Nov 3 14:13:28 IS-56434 kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve xxx.xxx.xxx.xxx Nov 3 14:13:28 IS-56434 kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve xxx.xxx.xxx.xxx Nov 3 14:13:28 IS-56434 kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve xxx.xxx.xxx.xxx Nov 3 14:13:28 IS-56434 kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve xxx.xxx.xxx.xxx Nov 3 14:13:28 IS-56434 kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve xxx.xxx.xxx.xxx Nov 3 14:13:28 IS-56434 kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve xxx.xxx.xxx.xxx Nov 3 14:13:28 IS-56434 kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve xxx.xxx.xxx.xxx Nov 3 14:13:28 IS-56434 kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve xxx.xxx.xxx.xxx Nov 3 14:13:28 IS-56434 kamailio: WARNING: <core> [socket_info.c:1392]: fix_hostname(): could not rev. resolve xxx.xxx.xxx.xxx
Although the IP address’ are correct...
Are you sure the IP is correct?
On November 3, 2017 10:20:17 AM EDT, Oz Mortimer omortimer@gmail.com wrote:
-- Alex
-- Sent via mobile, please forgive typos and brevity.
Yeah 100%
So, I figured it might be something with DNS so I set auto_aliases=no but then get the following.
Nov 3 14:32:19 IS-56434 kamailio: INFO: <core> [tcp_main.c:4745]: init_tcp(): using epoll_lt as the io watch method (auto detected) Nov 3 14:32:19 IS-56434 /usr/sbin/kamailio[13015]: WARNING: tm [tm.c:845]: mod_init(): WARNING: mod_init: reparse_on_dns_failover is enabled on a multihomed host -- check the readme of tm module! Nov 3 14:32:19 IS-56434 /usr/sbin/kamailio[13015]: INFO: rr [../outbound/api.h:54]: ob_load_api(): Failed to import bind_ob Nov 3 14:32:19 IS-56434 /usr/sbin/kamailio[13015]: INFO: rr [rr_mod.c:160]: mod_init(): outbound module not available
Its worth noting all of the IPs are on the same adapter, i.e. eth0, eth0:0, eth0:1 and so on..
I would not be concerned about superficial errors.
I am more concerned that the system is attempting to "resolve" an IP address. This would only happen if its format is not deemed to be that if an IP address.
On November 3, 2017 10:38:41 AM EDT, Oz Mortimer omortimer@gmail.com wrote:
-- Alex
-- Sent via mobile, please forgive typos and brevity.
Ok,
So sort of progress..
With mhomed=0 the calls arrive at the media server from the IP the call was sent to, With mhomed=1 the calls arrive at the media server from the first registered IP address regardless of which IP the call was sent to.
So mhomed is doing the reverse of what I would expect…
That's probably because the mhomed test, as described in the docs, determines that this should be the outbound interface.
On November 3, 2017 10:51:06 AM EDT, Oz Mortimer omortimer@gmail.com wrote:
-- Alex
-- Sent via mobile, please forgive typos and brevity.
Also, to correct a previous statement: it does seem that Kamailio attempts to resolve the reverse DNS entries of its listeners on boot. That can be disabled via DNS core configuration parameters. It can also be ignored as it's of no concern to this scenario.
On November 3, 2017 11:06:57 AM EDT, Alex Balashov abalashov@evaristesys.com wrote:
-- Alex
-- Sent via mobile, please forgive typos and brevity.
Because it determines the proper route based on the method described in the 'mhomed' section of the docs.
Your choices are either to let Kamailio do that, or set mhomed=0 and choose the egress interface manually based on your own criteria. You can do this by setting $fs prior to t_relay(), e.g.
$fs = 'udp:x.x.x.x:5060';
Bear in mind that this combination of transport, listener and port must correspond exactly to one of the listeners.
It sounds like that's what you need to do.
-- Alex
-- Sent via mobile, please forgive typos and brevity.
-
Alex Balashov -
Oz Mortimer