---- Original Message ----
From: Tina
To: Greger V. Teigre
Sent: Wednesday, April 06, 2005 09:45 PM
Subject: Re: [Serusers] still no help - usrloc synchronization

> Thank you for givingme the scenario with "restricted IP" NAT, I am
> starting to find some acceptable solution.
> Unfortunately, "one-public-IP" approach is not free from problems
> also. If your SIP router inserts this "one-public-IP" into the VIA
> header, the reply routing goes via wrong SIP server...
> If your SIP server inserts its real-IP-address - the scenario
> mentioned above is still not resolved.
> Any comments?
> Tina
>
> "Greger V. Teigre" <greger@teigre.com> wrote:
> See inline.
>
>> If you use DNS server for load balancing... the client receives one
>> of your domain IP addresses according to SRV. I don't see the problem
>> with a call here, cause UAC asks the address only once (before
>> sending INVITE). UAC already has the IP for BYE/reINVITEs. So why
>> would you replicate INVITEs?
>
> I would never replicate INVITEs, I would just make sure that they are
> proxied through the correct SER server (i.e. IP).
>
> The problems depends on your setup. If you have SERs with different
> IPs, ex UA1 has registered with server A and UA2 has registered with
> server B: If UA2 wants to call UA1 and UA is behind an IP restricted
> NAT, server A is stored in the NAT table of the NAT in front of UA1.
> If server B sends an INVITE to UA1, the INVITE will be refused by
> UA1's NAT.
> This is why a "one public IP" in front of a load balancing
> cluster probably is a good way to go.
>
>> If you use IPVS/LVS... I believe you can force SER to insert it's
>> public IP into VIA, so there is no problem with replies. With regard
>> to another requests, I believe load balancer keeps connection
>> template, then when another request comes it would be forwarded to
>> the same ser.
>
> Yes. There are different "keys" to use to load balance SIP messages.
> One good way from a NAT point of view is to use originating IP
> address. What you must remember is that the problem is not on the
> server side, but on the client side. The NAT will in many situations
> stop incoming UDP packets if the originating ip:port is not already
> stored in the NAT table. The Via header does not matter for the NAT.
> g-)
>
>> Any comments?
>>
>> "Greger V. Teigre" <greger@teigre.com> wrote:
>> Yes, I believe that is so. But still you get a problem if the NAT is
>> restricted, port-restricted or symmetric... The best would be to load
>> balance and always make sure that a given client is handled through a
>> given
>> SER (REGISTER and INVITEs). That includes forwarding INVITEs from one
>> SER to
>> another... OR you must load balance in front of your servers with one
>> common
>> public IP.
>> g-)
>>
>> Matt Schulte wrote:
>>> Ack, I didn't even think about NAT. Would these be added before it
>>> gets sent off to the second proxy? ie:
>>>
>>> if (!src_ip==blah.netlogic.net) {
>>> add_rcv_param();
>>> t_replicate("blah.netlogic.net", "999");
>>> };
>>>
>>> -----Original Message-----
>>> From: Greger V. Teigre [mailto:greger@teigre.com]
>>> Sent: Tuesday, April 05, 2005 7:49 AM
>>> To: Matt Schulte; kramarv@yahoo.com
>>> ! ; Cc: serusers@lists.iptel.org
>>> Subject: Re: [Serusers] still no help - usrloc synchronization
>>>
>>>
>>> Well, you still have the NAT issues unless you do load balancing and
>>> your
>>> SER servers have the same public IP.
>>> Have you looked at 0.9.0 nathelper function add_rcv_param() ? It
>>> will add received info to the contact header for the other SER to
>>> process. Haven't really tried yet...
>>> g-)
>>>
>>> Matt Schulte wrote:
>>>> I'm starting to lean this direction, using t_replicate and all. I
>>>> could never get usrloc (db mode) to function properly.. t_replicate
>>>> is
>>>
>>>> a dirty but very effective workaround.
>>>>
>>>> -----Original Message-----
>>>> From: Greger V. Teigre [mailto:greger@teigre.com]
>>>> Sent: Saturday, April 02, 2005 1:33 AM
>>>> To: kramarv@yahoo.com
>>>> Cc: serusers@lists.iptel.org
>>>> Subject: Re: [Serusers] still ! no help - usrloc synchronization
>>>>
>>>>
>>>> Have a look at this thread:
>>>> http://lists.iptel.org/pipermail/serusers/2005-January/014669.html
>>>> g-)
>>>>
>>>> Java Rockx wrote:
>>>>> Tina,
>>>>>
>>>>> I thought I saw you post the other day that you did not want to
>>>>> use t_replicate(), however, this is probably your best bet to
>>>>> getting this
>>>>
>>>>> to work, IMHO.
>>>>>
>>>>> Regards,
>>>>> Paul
>>>>>
>>>>> On Apr 1, 2005 4:08 PM, Tina wrote:
>>>> ! >>
>>>>>> Hi, please help me, I'm stuck with it!!!!!
>>>>>> I am trying to set up several sers with a shared MySQL database
>>>>>> for location service.
>>>>>>
>>>>>> I set in each ser.cfg:
>>>>>>
>>>>>> modparam("usrloc", "db_mode", 2)
>>>>>> modparam("usrloc",
>>>>>> "db_url","sql://ser:heslo@192.168.25.163/ser")
>>>>>>
>>>>>> and the servers are not synchronized.
>>>>>> The I set
>>>>>> modparam("usrloc", "db_mode", 2)
>>>>>>
>>>>>>
>>>>>> made UAC (Xlite) register to one of the servers.
>>>>>> I see it via usrloc, but there is no record in "location" mySQL
>>>>>> table....So others do not see the client and I'm unable to make
>>>>>> calls....
>>>>>>
>>>>>>
>>>>>> Please help how to work with usrloc and mySQL...
>>>>>>
>>>>>> Tina,
>>>>>> software engineer
>>>>>>
>>>>>> ________________________________
>>>>>> Do you Yahoo!?
>>>>>> Better first dates. More second dates. Yahoo! Personals
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Serusers mailing list
>>>>>> serusers@lists.iptel.org
>>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Serusers mailing list
>>>>> serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
>>>>
>>>> _______________________________________________
>>>> Serusers mailing list
>>>> serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
>>
>>
>> Yahoo! Messenger
>> Show us what our next emoticon should look like. Join the fun.
>
>
> Do you Yahoo!?
> Better first dates. More second dates. Yahoo! Personals