3 Apr
2005
3 Apr
'05
11:52 a.m.
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(a)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(a)lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers