[Serusers] How does t_relay() determine the IP/port to send amessage to?

Greger V. Teigre greger at teigre.com
Sun Apr 3 10:52:28 CEST 2005


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 at 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 at 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 at 172.31.130.110;user=phone SIP/2.0.
>>> Record-Route:
>>> <sip:3212514239 at 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 at lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers 




More information about the sr-users mailing list