<!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, I'm not sure if I understand: Which of the problems was born in your
thoughs? </DIV>
<DIV>An do I understand you correctly when you say that LVS-NAT is not a viable
solution (to which I agree).</DIV>
<DIV>g-)</DIV>
<DIV> </DIV>
<DIV>---- Original Message ----<BR>From: Tina<BR>To: Java Rockx<BR>Cc: Greger V.
Teigre ; serusers@lists.iptel.org<BR>Sent: Monday, April 11, 2005 06:37 PM<BR>Subject:
Re: [Serusers] still no help - usrloc synchronization<BR><BR>> Pretty good
news, Paul. I've only tested IP tunneling. It worked for<BR>> me. The problem
I described was born in my thoughts. I've also read<BR>> some complaints from
SIP-LVS users. The only configuration where<BR>> Call-Id stickness does not
necessary is LVS-NAT. Unfortunately, NAT<BR>> becomes bottleneck very
fast. <BR>> <BR>> <BR>> Java Rockx
<javarockx@gmail.com> wrote:<BR>> Tina,<BR>> <BR>> I wish I had
more information on that, but that LVS stuff is a black<BR>> art to me. One
of our engineers whipped up an LVS configuration that<BR>> seems quite happy
with the Call-ID "stickness" you described. All I<BR>> can say right now is
that it is apparently possible to do this with<BR>> 100% open source. (i'm
keeping my fingers crossed) :-) <BR>> <BR>>
Regards,<BR>> Paul<BR>> <BR>> <BR>> On Apr 10, 2005 11:03 PM, Tina
<kramarv@yahoo.com> wrote:<BR>> Paul,<BR>> thanks a lot, it helps a
lot. The thing I do not understand - how you<BR>> are going to solve call-id
stickness (see my another post). Since<BR>> we're also use LVS I had to find
something proprietary, I am afraid<BR>> this is not a best solution, but the
only I have today. <BR>> KRs,<BR>> Tina<BR>> <BR>> Java
Rockx <javarockx@gmail.com> wrote:<BR>> Tina,<BR>> <BR>> I really
don't know how the LVS server is configured because our<BR>> network guy that
we acquired from RedHat set all that stuff up. I do<BR>> know that we
basically have this set up: <BR>> <BR>> I hope the formatting goes
well :-)<BR>> <BR>> +-----------+
+----------+ +-------+
+---------+ <BR>> +--------------------+ <BR>>> internet |------|
Cisco |------| LVS |-----| Cisco |----|<BR>>>
Application | cloud
| | 3600
|
| |
|<BR>>> 3600 | | & DB Servers | <BR>>
+-----------+ +----------+
+--------+ +---------+ <BR>> +--------------------+
<BR>> <BR>> So! the "Application & DB Servers" box represents multiple
servers<BR>> (all are dedicated to their service). These include SER,
MySQL,<BR>> Apache, configuration management, monitoring, RTP proxies,
etc. <BR>> <BR>> MySQL is active-active so we have two-way
replication. We only have 2<BR>> MySQL servers. And this is all we plan on
ever having as MySQL is<BR>> more than capable of handling anything ser can
throw at it (given the<BR>> right hardware). <BR>> <BR>>
Each ser server is 100% oblivious to other SER servers except for<BR>> when
handling REGISTER messages. Here is basically the ser.cfg for<BR>> each SER
server: <BR>> <BR>> listen=10.3.0.221 # this will be 10.3.0.222 on
the peer sip proxy<BR>> modparam("usrloc", "db_mode", 1) #
write-through<BR>> <BR>> route
{<BR>> if (method=="REGISTER")
{<BR>>
if (src_ip==10.3.0.221) { # ip of peer ser
proxy<BR>>
save_memory("location");<BR>>
break;<BR>>
} else
{<BR>>
save("location");<BR>>
t_replicate("10.3.0.222");<BR>>
break;<BR>>
};<BR>> };<BR>> }<BR>>
<BR>> We have identifed a deficiency in the usrloc module urecord.c
file<BR>> whereby when using write-though mode the save_memory() function
still<BR>> attempt to update MySQL. This is a very bad thing because it
causes a<BR>> primary key violation on the location table.
<BR>> <BR>> Yesterday I posted a patch to serdev to fix this, but today
we<BR>> identified another case where save_memory() tried to insert in to
the<BR>> location table. I'll post a revised patch to serdev as soon as I
get<BR>> a chance. <BR>> <BR>> So here is what happens.
Assume I have two sip routers and two MySQL<BR>> servers as: <BR>>
<BR>> sip-01 is 10.3.0.221<BR>> sip-02 is 10.3.0.222<BR>> db-01 is
10.2.0.21<BR>> db-02 is 10.2.0.22<BR>> <BR>> Now let's just assume that
sip-01 is connected to db-01 and sip-02 is<BR>> connected to db-02. <BR>>
<BR>> When a SIP UA connects to a sip router (via LVS), assume sip-01
in<BR>> this example and REGISTERs, sip-01 will call save("location")
which<BR>> updates/inserts to the location table. sip-01 then calls
t_replicate<BR>> to sip-02. <BR>> <BR>> sip-02 recieves the
REGISTER message and calls<BR>> save_memory("location") to update its
in-memory cache only. It should<BR>> never hit db-02. <BR>> <BR>>
Now db-01 eventually (within a second or two) replicates to db-02 and<BR>>
now sip-02 is good to go, even in the event of a restart. <BR>> <BR>> Our
difficulties mostly surrounded the fact t! hat ser was inserting<BR>> the
physical IP of eth0 on the server as the top VIA rather than the<BR>> VIP as
required. We solved this by using record_route_preset() and<BR>> passing the
VIP as the IP. We also had to bring up a dummy interface<BR>> in order to get
ser to honor the VIP. <BR>> <BR>> Hope this
helps.<BR>> <BR>> Regards,<BR>> Paul<BR>> <BR>> <BR>> <BR>>
On Apr 8, 2005 7:19 PM, Tina <kramarv@yahoo.com> wrote:<BR>>
Paul,<BR>> we are using LVS as well. It creates template connection according
to<BR>> source Ip (e.g. UAC) and forwards to one of the tunneled IP. I
tested<BR>> this a couple of weeks ago, ser was happy and inserted VIP into
via<BR>> header, the only issue is to route the calls into right
server. <BR>> I agree, there is no such thing as SIP-level
clustering. However, how<BR>> would you solve location problem by DB
replication - 1) usrloc does<BR>> not update from DB....2) even though, I am
afraid it can become<BR>> bottleneck and lock down users ...
<BR>> <BR>> KRs,<BR>> Tina<BR>> <BR>> <BR>> Java Rockx
<javarockx@gmail.com> wrote:<BR>> See my inline comments.<BR>>
<BR>> Regards,<BR>> Paul<BR>> <BR>> <BR>> On Apr 8, 2005 1:08 PM,
Greger V. Teigre <greger@teigre.com> wrote:<BR>> Hi Tina,<BR>>
<BR>>> I enjoy reading your posts, thanks a lot for the great work you
are<BR>>> doing for ser users!<BR>> <BR>> Thanks :-)<BR>>
<BR>>> I am going to consider that kind of scenario as well (load
balancer<BR>>> returning Virtual IP address). I think for such
configuration server<BR>>> side has to keep session information and always
forward a call to the<BR>>> right server.<BR>> <BR>> I believe the
load balancer can be in front and transparantly<BR>> translate addresses in
the SIP messages: <BR>> User agent always sees
a.b.c.d<BR>>
|<BR>> Load balancer with public IP
a.b.c.d<BR>>
|
|<BR>> ser1 (10.0.0.2)
ser2 (10.0.0.3)<BR>> <BR>> Paul: You have a similar load-balancing
solution, right? Do you use a<BR>> commerical load balancer that you can
reveal the name of? :-) <BR>> <BR>> Our platform is 100% open source. Our
load balancer is LVS. I have no<BR>> idea how it actually works. One if our
engineers from RedHat set all<BR>> that networking stuff up and it's way
beyond me. <BR>> <BR>> <BR>> <BR>> The load balancer need to
understand SIP (sort of) and use something<BR>> (ex. IP address of user
agent) to select SER server to send to and<BR>> rewrite incoming to 10.0.0.2
and 10.0.0.3 respectively and outgoing<BR>> to a.b.c.d. ser1 and ser2
will happily believe they are alone and<BR>> communicate directly with user
agent using their own private<BR>> addresses. Both should know about
all users (usrloc). Paul just<BR>> recently posted a small patch for a
setup where they use two-way<BR>> replication between
two <BR>> <BR>> That small patch will
need a slight revision. We discovered through<BR>> further testing that that
patch only fixed attempts to INSERT into<BR>> the location table. We didn't
cover the UPDATE route, unfortunately.<BR>> I believe Andrew has that patch
done and is testing it. So I'll post<BR>> it to serdev as soon as we
know it works - possibly later today. <BR>> <BR>>
<BR>> <BR>> mysql servers and where each SER instance will save all
REGISTERs it<BR>> receives from user agents, but only save to memory those
replicated<BR>> from the other SER peer. Klaus pointed out that the same can
be done<BR>> by not doing mysql replication, but have one DB for each SER and
just<BR>> use t_replicate() and save_noreply() (for two servers, for more
than<BR>> two you need to use forward_tcp()).
<BR>> <BR>> I have heard complaints that this approach will generate too
much<BR>> network traffic. Also, t_replicate() does not guarantee delivery
of<BR>> the replication (forward_tcp is better, but not fool proof).
So, the<BR>> "best" solution would probably be to hope that
Paul's <BR>> <BR>> I fully agree. Replication at the sip proxy
level, IMHO, is not a<BR>> good idea. From a purist point of view,
replication is not a function<BR>> of a SIP router - nor should it be. It is
a function of the database<BR>> and we believe that the MySQL replication is
a better approach from a<BR>> speed and reliabilty point of view - not to
mention that it<BR>> simplifies the tasks of the sip
router. <BR>> <BR>> <BR>> <BR>> recent
TCP/UDP patch for network access to FIFO commands get included<BR>> in the
CVS. Then, a new replication module should use XMLRPC or<BR>> whatever
protocol the patch is using to forward (in a guaranteed<BR>> mode) the usrloc
information, which then would be injected directly<BR>> into SER's memory,
just like save() would, and of course in whatever<BR>> db_mode you would
like. The replicaton module would have to keep a<BR>> queue (of course,
flushed to a DB or something) in case of network<BR>> problems, so that the
replication would be done (sooner or later)<BR>> regardless of
problems.
<BR>> Of course, this is a major undertaking, so for
most replication<BR>> scenarioes, I would think the forward_tcp() +
save_noreply() would<BR>> work just fine. <BR>> <BR>> g-)<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<BR>>>> are 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 h! as registered<BR>>>>
with server B: If UA2 wants to call UA1 and UA is behind an IP<BR>>>>
restricted NAT, server A is stored in the NAT table of the NAT
in<BR>>>> front of UA1. If server B sends an INVITE to UA1, the INVITE
will<BR>>>> be refused by 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<BR>>> the <BR>>>> server side, but on the
client side. The NAT will in many<BR>>>> situations stop incoming
UDP packets if the originating ip:port is<BR>>>> not already stored in
the NAT table. The Via header does not<BR>>>> matter for the NAT.
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<BR>>>>> is 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<BR>>>>>>>
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>>> Yahoo!
Messenger<BR>>> Show us what our next emoticon should look like. Join the
fun.<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>> <BR>> <BR>> Do you Yahoo!?<BR>> Make Yahoo!
your home page<BR>> <BR>> <BR>>
__________________________________________________<BR>> Do You
Yahoo!?<BR>> Tired of spam? Yahoo! Mail has the best spam protection
around<BR>> http://mail.yahoo.com<BR>> <BR>> <BR>>
__________________________________________________<BR>> Do You
Yahoo!?<BR>> Tired of spam? Yahoo! Mail has the best spam protection
around<BR>> http://mail.yahoo.com</DIV></BODY></HTML>