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