AFAIK, there should be no problems as long as you never need the VIP to be re-routed outside your server (ex. by your load balancer). I think SER will check all aliases against DNS and own interfaces and ignore (and probably complain about) aliases that cannot be resolved to itself. Of course, you could also use drop myself alltogether and use the domain.so functions is_from_local() (for From:) and is_uri_host_local() (for ruri) and store your IP addresses in the DB. I don't think the domain module does the same sanity check on the aliases. g-)

Java Rockx wrote:

Yes. 10.3.0.221 is an alias.

I have a fix (or perhaps a hack) but I can't say if this is really the proper way to do things. This whole problem surfaced on our platform that uses a virtual IP address (aka, VIP) and multiple SER proxies behind firewall/load balancers.

We added a dummy interface to the sip proxy server with the interface IP of the VIP. This seems to make ser happy, however we also tried adding an alias with the VIP, but that didn't help.

Is there any downside to this?

Regards, Paul

On Apr 2, 2005 3:02 AM, Greger V. Teigre greger@teigre.com wrote:

...

I would say that for some reason your ser.cfg manipulated the ruri into SER's IP address. AFAIK, t_relay() will always send to the current ruri (and branches). BTW, do you have 10.3.0.221 as an alias? g-)

Java Rockx wrote:

...

Hi All.

If I have the following INVITE message, the message is sent to 10.3.0.221:5060.

How does t_relay() determine this? Is it because that is the IP in the R-URI?

I have a very odd situation where the INVITE is sent to an IP that is the same as the SER proxy, but the R-URI is a SIP phone on the public internet.

This causes SER to send the message to iteself, which then causes (uri==myself) to be FALSE and I just t_relay() it again in my default handling.

Does anyone know why ser might attempt to send a message to an IP that is __not__ the R-URI? In this example I do have "sip.mycompany.com" defined as an alias so I'm not sure what could be causing this loop.

U 2005/04/01 11:15:09.620910 66.90.46.29:33697 -> 10.3.0.221:5060 INVITE sip:3212514239@sip.mycompany.com;user=phone SIP/2.0. Via: SIP/2.0/UDP 172.31.130.83:33697;branch=z9hG4bK02b13d3f9557e284.

U 2005/04/01 11:15:09.633247 10.3.0.221:5060 -> 66.90.46.29:33697 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 172.31.130.83:33697;branch=z9hG4bK02b13d3f9557e284;rport=33697;received=66.90.46.29.

U 2005/04/01 11:15:09.633687 10.3.0.221:5060 -> 10.3.0.221:5060 INVITE sip:3212514239@172.31.130.110;user=phone SIP/2.0. Record-Route: sip:3212514239@10.3.0.221:5060;nat=yes;ftag=946f5da2c0d8a21c;lr. Via: SIP/2.0/UDP 10.3.0.221;branch=z9hG4bK8ca2.b43bda21.0. Via: SIP/2.0/UDP 172.31.130.83:33697;rport=33697;received=66.90.46.29;branch=z9hG4bK02b13d3f9557e284.

Regards, Paul

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers