Hi Marius,

Thanks for the reply. I found the patch in the 1.5 CVS branch.

By the way, the 1.5.5 source tarball in /pub/kamailio/1.5.5/src was created before this patch was written, so the patch is not in there. The tarball I created from the 1.5 branch did have it.

Thanks again,

Sean O'Donnell Senior Engineer uReach Technologies, Inc.

---- On Mon, 14 Feb 2011, marius zbihlei (marius.zbihlei@1and1.ro) wrote:

On 02/11/2011 09:14 PM, Sean O'Donnell wrote:

Hi all,

Hello Sean,

I checked the GIT repository and noticed that there was a patch in forward.c

for

this issue. Looks like it was done 11/4/2010. Two questions:

1. Is there any reason that patch didn't make it into Kamailio 3.1.2 ?

Indeed, there is no reason. Actually I have cherry-picked the patches into the 3.1 branch (commit_notice 3.1 3ec1e9 and 9ef0a1e). Thanks for noticing.

2. Any reason I shouldn't apply that patck to my 1.5.4 release?

The patch was already applied to the svn 1.5 branch (don't know if the latest 1.5.5 tar ball has it) but you can install it from svn and you can find it there (commit 6050)

Cheers Marius

Thanks, Sean O'Donnell Senior Engineer uReach Technologies, Inc.

---- On Thu, 10 Feb 2011, Sean O'Donnell (skodonnell@ureach.com) wrote:

Hi all,

I just started deploying Kamailio release 1.5.4, and I think there's an issue with how Kamailio identifies an outgoing interface when mhomed is enabled

under

Linux.

I use Kamailio as a call distributor/proxy between a soft-switch/SBC and a voicemail platform. It runs on a CentOS 5.3 (Linux 2.6 kernel) host with two network interfaces and

is

configured such that it listens on both interfaces. One interface (public interface) handles traffic with the SBC, the other (private interface) handles with the VM platform. The 'mhomed' option is enabled.

After upgrading from 1.5.3 to 1.5.4, I started noticing problems with UDP packets coming out of the public interface. After looking at some ngrep captures on that interface, I noticed that some packets had the source IP address of the private interface and also had Record-Route and Via headers for the private interface only - no headers for the public interface were there.

Usually when I see the wrong source IP in a UDP packet, it's an issue with how routes are set up on the host. However, I had our network engineer double

check

them, and they seem fine (no ambiguous routes). The fact that I captured

these

messages on the public interface also indicates to me that the kernel is

routing

the message correctly. The missing Record-Route and Via for the public interface, however, lead me to believe that the proxy didn't correctly

identify

the outgoing interface in the first place.

After looking at the ChangeLog for 1.5.4, I noticed that the some new logic

was

put in to improve performance when mhomed is enabled (r5971) in forward.c, and

I

think this is the issue.

As I understand it, prior to 1.5.4, when mhomed was enabled, Kamailio

determined

the outgoing interface by creating a temporary UDP socket, invoking connect()

on

the socket with the packet destination, then checking the source IP of the socket that the kernel assigned using getsockname(). After the source address was determined, the temp socket was closed closed. As of 1.5.4, this was modified to reuse the temporary socket and just re-invoking connect() with a

new

destination address.

The problem with the enhancement is that Linux (again, at least in the 2.6 kernels I'm using) doesn't seem to rebind a new source address to the socket when connect() is called more than once on a UDP socket. Instead, it keeps the original one, and thus the wrong

interface

is assumed.

I wrote a small program to confirm this - basically creates a UDP socket,

calls

connect()/getsockname() multiple times using different destination addresses. I ran it on several 2.6 kernels, including Centos4.x and Centos5. The result was always that the source address of the socket wasn't changed after the first connect(), regardless of the destination address. The only way I could get it work as required was to first do a connect() using a zero'd out AF_UNSPEC address

before

doing the connect() to the remote address. I also ran it on Solaris and it worked. Go figure.

I've downloaded the latest stable release (3.1.2) but I think the issue is

still

there, and I don't see anything in the user groups that addresses this.

Any help would be appreciated.

Thanks,

Sean

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users