[SR-Users] ACK sent to wrong socket IP in mhomed scenario

Ronald Voermans r.voermans at global-datacenter.nl
Thu Dec 12 22:20:38 CET 2013


Thank you for your answer. Configured the following (with mhomed=yes):

if ($(route_uri{uri.host}) == VIP_PROXY) {
} else if ($(route_uri{uri.host}) == VIP_PROXY_PUB) {
} else if ($(route_uri{uri.host}) == THIS_PROXY) {
} else if ($(route_uri{uri.host}) == THIS_PROXY_PUB) {

This solves the issue when using the VIP_PROXY(_PUB). However, the ACK always has two route headers when using the THIS_PROXY as ip address. In this case, the top route header is VIP_PROXY; the second one is THIS_PROXY. Hence, the solution above doesn't work, because the force_send_socket uses the top route header (which is VIP_PROXY).

Why is this different behavior when compared to mhomed=no?


Dear list,

I'm having an issue with our Kamailio setup.

I've installed two Kamailio servers with Corosync/Pacemaker. Kamailio1 has ip, Kamailio2 has ip The VIP is All is working well; clients can sent request to the VIP, and all traffic is sent via, and not the real ipI've configured the listen addressess:

mhomed = no
listen = udp:
listen = udp:

I'm now trying to configure the server as a multihomed one. Both Kamailio have two NIC's. Kamailio1 also has ip X1, Kamailio2 has ip X2. The VIP is Y. Configuration is done as:

mhomed = yes
listen = udp:
listen = udp:
listen = udp:Y:5060
listen = udp:X1:5060

When a UA sends an INVITE to for example, all responses (back) to UA are being sent with source address (VIP), except for the ACK (and BYE). The ACK is sent via the real ip I can resolve this by issuing a force_send_socket before t_relay in the config; but since it's multihomed, I have to build a lot of checks to find out the outgoing socket. Besides that, I want it to be possible to use both the real IP and the VIP as IP-address for the UA (for testing purposes). This won't work with force_send_socket.

Does anyone from the list know how I can solve this?




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20131212/4b745456/attachment.html>

More information about the sr-users mailing list