I was thinking about a load balancing scenario where the load balancer will replace the IP addresses. g-)
---- 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
Hi Greger, I enjoy reading your posts, thanks a lot for the great work you are doing for ser users!
I am going to consider that kind of scenario as well (load balancer returning Virtual IP address). I think for such configuration server side has to keep session information and always forward a call to the right server.
"Greger V. Teigre" greger@teigre.com wrote: I was thinking about a load balancing scenario where the load balancer will replace the IP addresses. g-)
---- 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
--------------------------------- Yahoo! Messenger Show us what our next emoticon should look like. Join the fun.
Hi Tina,
I enjoy reading your posts, thanks a lot for the great work you are doing for ser users!
Thanks :-)
I am going to consider that kind of scenario as well (load balancer returning Virtual IP address). I think for such configuration server side has to keep session information and always forward a call to the right server.
I believe the load balancer can be in front and transparantly translate addresses in the SIP messages: User agent always sees a.b.c.d | Load balancer with public IP a.b.c.d | | ser1 (10.0.0.2) ser2 (10.0.0.3)
Paul: You have a similar load-balancing solution, right? Do you use a commerical load balancer that you can reveal the name of? :-)
The load balancer need to understand SIP (sort of) and use something (ex. IP address of user agent) to select SER server to send to and rewrite incoming to 10.0.0.2 and 10.0.0.3 respectively and outgoing to a.b.c.d. ser1 and ser2 will happily believe they are alone and communicate directly with user agent using their own private addresses. Both should know about all users (usrloc). Paul just recently posted a small patch for a setup where they use two-way replication between two mysql servers and where each SER instance will save all REGISTERs it receives from user agents, but only save to memory those replicated from the other SER peer. Klaus pointed out that the same can be done by not doing mysql replication, but have one DB for each SER and just use t_replicate() and save_noreply() (for two servers, for more than two you need to use forward_tcp()).
I have heard complaints that this approach will generate too much network traffic. Also, t_replicate() does not guarantee delivery of the replication (forward_tcp is better, but not fool proof). So, the "best" solution would probably be to hope that Paul's recent TCP/UDP patch for network access to FIFO commands get included in the CVS. Then, a new replication module should use XMLRPC or whatever protocol the patch is using to forward (in a guaranteed mode) the usrloc information, which then would be injected directly into SER's memory, just like save() would, and of course in whatever db_mode you would like. The replicaton module would have to keep a queue (of course, flushed to a DB or something) in case of network problems, so that the replication would be done (sooner or later) regardless of problems. Of course, this is a major undertaking, so for most replication scenarioes, I would think the forward_tcp() + save_noreply() would work just fine.
g-)
"Greger V. Teigre" greger@teigre.com wrote: I was thinking about a load balancing scenario where the load balancer will replace the IP addresses. g-)
---- 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 t! he 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
Yahoo! Messenger Show us what our next emoticon should look like. Join the fun.
Hi,
Greger V. Teigre wrote:
Then, a new replication module should use XMLRPC or whatever protocol the patch is using to forward (in a guaranteed mode) the usrloc information
Apropos XMLRPC: my boss accepted the release of our XMLRPC-server under the GPL, so I'll post a link as soon as I get a chance to write some install notes for it.
It currently works as standalone daemon communicating with SER by FIFO commands via unix sockets. But now since Paul released a TCP/UDP-patch for the FIFO-system, maybe one could extract the xmlrpc parts into a SER module.
Andy
That's excellent news, Andreas! I'm not able to see immediately how the two can work nicely together, but I'm sure it should be possible to get SER's FIFO net-centric now ;-)
For some reason, however, I think an alternative to SIP-based replication is somewhere down the line. Paul relies on mysql two-way replication and I follow his reasoning that replication should be done at the DB layer (which we do as well, but using LDAP. The usrloc replication is still SIP-based...). However, the solution where forward_tcp() and save_memory() are used, you get both SIP replication traffic, as well as DB replication. If one has full TCP/UDP-based FIFO access, shouldn't it be easy to write a small module that will send a ul_add command to another server? I wonder why Paul and you haven't done that yet, but still rely on SIP-based updates?
g-)
Andreas Granig wrote:
Hi,
Greger V. Teigre wrote:
Then, a new replication module should use XMLRPC or whatever protocol the patch is using to forward (in a guaranteed mode) the usrloc information
Apropos XMLRPC: my boss accepted the release of our XMLRPC-server under the GPL, so I'll post a link as soon as I get a chance to write some install notes for it.
It currently works as standalone daemon communicating with SER by FIFO commands via unix sockets. But now since Paul released a TCP/UDP-patch for the FIFO-system, maybe one could extract the xmlrpc parts into a SER module.
Andy
See my inline comments.
Regards, Paul
On Apr 8, 2005 1:08 PM, Greger V. Teigre greger@teigre.com wrote:
Hi Tina,
I enjoy reading your posts, thanks a lot for the great work you are doing for ser users!
Thanks :-)
I am going to consider that kind of scenario as well (load balancer returning Virtual IP address). I think for such configuration server side has to keep session information and always forward a call to the right server.
I believe the load balancer can be in front and transparantly translate addresses in the SIP messages: User agent always sees a.b.c.d | Load balancer with public IP a.b.c.d | | ser1 (10.0.0.2 http://10.0.0.2) ser2 (10.0.0.3 http://10.0.0.3) Paul: You have a similar load-balancing solution, right? Do you use a commerical load balancer that you can reveal the name of? :-)
Our platform is 100% open source. Our load balancer is LVS. I have no idea how it actually works. One if our engineers from RedHat set all that networking stuff up and it's way beyond me.
The load balancer need to understand SIP (sort of) and use something (ex. IP
address of user agent) to select SER server to send to and rewrite incoming to 10.0.0.2 http://10.0.0.2 and 10.0.0.3 http://10.0.0.3 respectively and outgoing to a.b.c.d. ser1 and ser2 will happily believe they are alone and communicate directly with user agent using their own private addresses. Both should know about all users (usrloc). Paul just recently posted a small patch for a setup where they use two-way replication between two
That small patch will need a slight revision. We discovered through further testing that that patch only fixed attempts to INSERT into the location table. We didn't cover the UPDATE route, unfortunately. I believe Andrew has that patch done and is testing it. So I'll post it to serdev as soon as we know it works - possibly later today.
mysql servers and where each SER instance will save all REGISTERs it
receives from user agents, but only save to memory those replicated from the other SER peer. Klaus pointed out that the same can be done by not doing mysql replication, but have one DB for each SER and just use t_replicate() and save_noreply() (for two servers, for more than two you need to use forward_tcp()). I have heard complaints that this approach will generate too much network traffic. Also, t_replicate() does not guarantee delivery of the replication (forward_tcp is better, but not fool proof). So, the "best" solution would probably be to hope that Paul's
I fully agree. Replication at the sip proxy level, IMHO, is not a good idea.
From a purist point of view, replication is not a function of a SIP router -
nor should it be. It is a function of the database and we believe that the MySQL replication is a better approach from a speed and reliabilty point of view - not to mention that it simplifies the tasks of the sip router.
recent TCP/UDP patch for network access to FIFO commands get included in the
CVS. Then, a new replication module should use XMLRPC or whatever protocol the patch is using to forward (in a guaranteed mode) the usrloc information, which then would be injected directly into SER's memory, just like save() would, and of course in whatever db_mode you would like. The replicaton module would have to keep a queue (of course, flushed to a DB or something) in case of network problems, so that the replication would be done (sooner or later) regardless of problems. Of course, this is a major undertaking, so for most replication scenarioes, I would think the forward_tcp() + save_noreply() would work just fine. g-)
"Greger V. Teigre" greger@teigre.com wrote: I was thinking about a load balancing scenario where the load balancer will replace the IP addresses. g-)
---- 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 t! he 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 http://blah.netlogic.net) { add_rcv_param(); t_replicate("blah.netlogic.net http://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
Yahoo! Messenger Show us what our next emoticon should look like. Join the fun.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Paul, we are using LVS as well. It creates template connection according to source Ip (e.g. UAC) and forwards to one of the tunneled IP. I tested this a couple of weeks ago, ser was happy and inserted VIP into via header, the only issue is to route the calls into right server. I agree, there is no such thing as SIP-level clustering. However, how would you solve location problem by DB replication - 1) usrloc does not update from DB....2) even though, I am afraid it can become bottleneck and lock down users ...
KRs, Tina
Java Rockx javarockx@gmail.com wrote: See my inline comments.
Regards, Paul
On Apr 8, 2005 1:08 PM, Greger V. Teigre greger@teigre.com wrote:Hi Tina,
I enjoy reading your posts, thanks a lot for the great work you are doing for ser users!
Thanks :-)
I am going to consider that kind of scenario as well (load balancer returning Virtual IP address). I think for such configuration server side has to keep session information and always forward a call to the right server.
I believe the load balancer can be in front and transparantly translate addresses in the SIP messages: User agent always sees a.b.c.d | Load balancer with public IP a.b.c.d | | ser1 (10.0.0.2) ser2 (10.0.0.3)
Paul: You have a similar load-balancing solution, right? Do you use a commerical load balancer that you can reveal the name of? :-)
Our platform is 100% open source. Our load balancer is LVS. I have no idea how it actually works. One if our engineers from RedHat set all that networking stuff up and it's way beyond me.
The load balancer need to understand SIP (sort of) and use something (ex. IP address of user agent) to select SER server to send to and rewrite incoming to 10.0.0.2 and 10.0.0.3 respectively and outgoing to a.b.c.d. ser1 and ser2 will happily believe they are alone and communicate directly with user agent using their own private addresses. Both should know about all users (usrloc). Paul just recently posted a small patch for a setup where they use two-way replication between two
That small patch will need a slight revision. We discovered through further testing that that patch only fixed attempts to INSERT into the location table. We didn't cover the UPDATE route, unfortunately. I believe Andrew has that patch done and is testing it. So I'll post it to serdev as soon as we know it works - possibly later today.
mysql servers and where each SER instance will save all REGISTERs it receives from user agents, but only save to memory those replicated from the other SER peer. Klaus pointed out that the same can be done by not doing mysql replication, but have one DB for each SER and just use t_replicate() and save_noreply() (for two servers, for more than two you need to use forward_tcp()).
I have heard complaints that this approach will generate too much network traffic. Also, t_replicate() does not guarantee delivery of the replication (forward_tcp is better, but not fool proof). So, the "best" solution would probably be to hope that Paul's
I fully agree. Replication at the sip proxy level, IMHO, is not a good idea. From a purist point of view, replication is not a function of a SIP router - nor should it be. It is a function of the database and we believe that the MySQL replication is a better approach from a speed and reliabilty point of view - not to mention that it simplifies the tasks of the sip router.
recent TCP/UDP patch for network access to FIFO commands get included in the CVS. Then, a new replication module should use XMLRPC or whatever protocol the patch is using to forward (in a guaranteed mode) the usrloc information, which then would be injected directly into SER's memory, just like save() would, and of course in whatever db_mode you would like. The replicaton module would have to keep a queue (of course, flushed to a DB or something) in case of network problems, so that the replication would be done (sooner or later) regardless of problems. Of course, this is a major undertaking, so for most replication scenarioes, I would think the forward_tcp() + save_noreply() would work just fine.
g-)
"Greger V. Teigre" greger@teigre.com wrote: I was thinking about a load balancing scenario where the load balancer will replace the IP addresses. g-)
---- 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 t! he 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
Yahoo! Messenger Show us what our next emoticon should look like. Join the fun.
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
--------------------------------- Do you Yahoo!? Make Yahoo! your home page
Tina,
I really don't know how the LVS server is configured because our network guy that we acquired from RedHat set all that stuff up. I do know that we basically have this set up:
I hope the formatting goes well :-)
+-----------+ +----------+ +-------+ +---------+ +--------------------+ | internet |------| Cisco |------| LVS |-----| Cisco |----| Application | | cloud | | 3600 | | | | 3600 | | & DB Servers | +-----------+ +----------+ +--------+ +---------+ +--------------------+
So the "Application & DB Servers" box represents multiple servers (all are dedicated to their service). These include SER, MySQL, Apache, configuration management, monitoring, RTP proxies, etc.
MySQL is active-active so we have two-way replication. We only have 2 MySQL servers. And this is all we plan on ever having as MySQL is more than capable of handling anything ser can throw at it (given the right hardware).
Each ser server is 100% oblivious to other SER servers except for when handling REGISTER messages. Here is basically the ser.cfg for each SER server:
listen=10.3.0.221 http://10.3.0.221 # this will be 10.3.0.222http://10.3.0.222on the peer sip proxy modparam("usrloc", "db_mode", 1) # write-through
route { if (method=="REGISTER") { if (src_ip==10.3.0.221 http://10.3.0.221) { # ip of peer ser proxy save_memory("location"); break; } else { save("location"); t_replicate("10.3.0.222 http://10.3.0.222"); break; }; }; }
We have identifed a deficiency in the usrloc module urecord.c file whereby when using write-though mode the save_memory() function still attempt to update MySQL. This is a very bad thing because it causes a primary key violation on the location table.
Yesterday I posted a patch to serdev to fix this, but today we identified another case where save_memory() tried to insert in to the location table. I'll post a revised patch to serdev as soon as I get a chance.
So here is what happens. Assume I have two sip routers and two MySQL servers as:
sip-01 is 10.3.0.221 http://10.3.0.221 sip-02 is 10.3.0.222 http://10.3.0.222 db-01 is 10.2.0.21 http://10.2.0.21 db-02 is 10.2.0.22 http://10.2.0.22
Now let's just assume that sip-01 is connected to db-01 and sip-02 is connected to db-02.
When a SIP UA connects to a sip router (via LVS), assume sip-01 in this example and REGISTERs, sip-01 will call save("location") which updates/inserts to the location table. sip-01 then calls t_replicate to sip-02.
sip-02 recieves the REGISTER message and calls save_memory("location") to update its in-memory cache only. It should never hit db-02.
Now db-01 eventually (within a second or two) replicates to db-02 and now sip-02 is good to go, even in the event of a restart.
Our difficulties mostly surrounded the fact that ser was inserting the physical IP of eth0 on the server as the top VIA rather than the VIP as required. We solved this by using record_route_preset() and passing the VIP as the IP. We also had to bring up a dummy interface in order to get ser to honor the VIP.
Hope this helps.
Regards, Paul
On Apr 8, 2005 7:19 PM, Tina kramarv@yahoo.com wrote:
Paul, we are using LVS as well. It creates template connection according to source Ip (e.g. UAC) and forwards to one of the tunneled IP. I tested this a couple of weeks ago, ser was happy and inserted VIP into via header, the only issue is to route the calls into right server. I agree, there is no such thing as SIP-level clustering. However, how would you solve location problem by DB replication - 1) usrloc does not update from DB....2) even though, I am afraid it can become bottleneck and lock down users ... KRs, Tina
*Java Rockx javarockx@gmail.com* wrote:
See my inline comments.
Regards, Paul
On Apr 8, 2005 1:08 PM, Greger V. Teigre greger@teigre.com wrote:
Hi Tina,
I enjoy reading your posts, thanks a lot for the great work you are doing for ser users!
Thanks :-)
I am going to consider that kind of scenario as well (load balancer returning Virtual IP address). I think for such configuration server side has to keep session information and always forward a call to the right server.
I believe the load balancer can be in front and transparantly translate addresses in the SIP messages: User agent always sees a.b.c.d | Load balancer with public IP a.b.c.d | | ser1 (10.0.0.2 http://10.0.0.2/) ser2 (10.0.0.3 http://10.0.0.3/) Paul: You have a similar load-balancing solution, right? Do you use a commerical load balancer that you can reveal the name of? :-)
Our platform is 100% open source. Our load balancer is LVS. I have no idea how it actually works. One if our engineers from RedHat set all that networking stuff up and it's way beyond me.
The load balancer need to understand SIP (sort of) and use something (ex.
IP address of user agent) to select SER server to send to and rewrite incoming to 10.0.0.2 http://10.0.0.2/ and 10.0.0.3 http://10.0.0.3/respectively and outgoing to a.b.c.d. ser1 and ser2 will happily believe they are alone and communicate directly with user agent using their own private addresses. Both should know about all users (usrloc). Paul just recently posted a small patch for a setup where they use two-way replication between two
That small patch will need a slight revision. We discovered through further testing that that patch only fixed attempts to INSERT into the location table. We didn't cover the UPDATE route, unfortunately. I believe Andrew has that patch done and is testing it. So I'll post it to serdev as soon as we know it works - possibly later today.
mysql servers and where each SER instance will save all REGISTERs it
receives from user agents, but only save to memory those replicated from the other SER peer. Klaus pointed out that the same can be done by not doing mysql replication, but have one DB for each SER and just use t_replicate() and save_noreply() (for two servers, for more than two you need to use forward_tcp()). I have heard complaints that this approach will generate too much network traffic. Also, t_replicate() does not guarantee delivery of the replication (forward_tcp is better, but not fool proof). So, the "best" solution would probably be to hope that Paul's
I fully agree. Replication at the sip proxy level, IMHO, is not a good idea. From a purist point of view, replication is not a function of a SIP router - nor should it be. It is a function of the database and we believe that the MySQL replication is a better approach from a speed and reliabilty point of view - not to mention that it simplifies the tasks of the sip router.
recent TCP/UDP patch for network access to FIFO commands get included in
the CVS. Then, a new replication module should use XMLRPC or whatever protocol the patch is using to forward (in a guaranteed mode) the usrloc information, which then would be injected directly into SER's memory, just like save() would, and of course in whatever db_mode you would like. The replicaton module would have to keep a queue (of course, flushed to a DB or something) in case of network problems, so that the replication would be done (sooner or later) regardless of problems. Of course, this is a major undertaking, so for most replication scenarioes, I would think the forward_tcp() + save_noreply() would work just fine. g-)
"Greger V. Teigre" greger@teigre.com wrote: I was thinking about a load balancing scenario where the load balancer will replace the IP addresses. g-)
---- 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 t! he 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 http://blah.netlogic.net/) { add_rcv_param(); t_replicate("blah.netlogic.net http://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
Yahoo! Messenger Show us what our next emoticon should look like. Join the fun.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Do you Yahoo!? Make Yahoo! your home pagehttp://us.rd.yahoo.com/my/navbar/sethp/*http://www.yahoo.com/r/hs
Paul, thanks a lot, it helps a lot. The thing I do not understand - how you are going to solve call-id stickness (see my another post). Since we're also use LVS I had to find something proprietary, I am afraid this is not a best solution, but the only I have today. KRs, Tina
Java Rockx javarockx@gmail.com wrote: Tina,
I really don't know how the LVS server is configured because our network guy that we acquired from RedHat set all that stuff up. I do know that we basically have this set up:
I hope the formatting goes well :-)
+-----------+ +----------+ +-------+ +---------+ +--------------------+ | internet |------| Cisco |------| LVS |-----| Cisco |----| Application | | cloud | | 3600 | | | | 3600 | | & DB Servers | +-----------+ +----------+ +--------+ +---------+ +--------------------+
So the "Application & DB Servers" box represents multiple servers (all are dedicated to their service). These include SER, MySQL, Apache, configuration management, monitoring, RTP proxies, etc.
MySQL is active-active so we have two-way replication. We only have 2 MySQL servers. And this is all we plan on ever having as MySQL is more than capable of handling anything ser can throw at it (given the right hardware).
Each ser server is 100% oblivious to other SER servers except for when handling REGISTER messages. Here is basically the ser.cfg for each SER server:
listen=10.3.0.221 # this will be 10.3.0.222 on the peer sip proxy modparam("usrloc", "db_mode", 1) # write-through
route { if (method=="REGISTER") { if (src_ip==10.3.0.221) { # ip of peer ser proxy save_memory("location"); break; } else { save("location"); t_replicate("10.3.0.222"); break; }; }; }
We have identifed a deficiency in the usrloc module urecord.c file whereby when using write-though mode the save_memory() function still attempt to update MySQL. This is a very bad thing because it causes a primary key violation on the location table.
Yesterday I posted a patch to serdev to fix this, but today we identified another case where save_memory() tried to insert in to the location table. I'll post a revised patch to serdev as soon as I get a chance.
So here is what happens. Assume I have two sip routers and two MySQL servers as:
sip-01 is 10.3.0.221 sip-02 is 10.3.0.222 db-01 is 10.2.0.21 db-02 is 10.2.0.22
Now let's just assume that sip-01 is connected to db-01 and sip-02 is connected to db-02.
When a SIP UA connects to a sip router (via LVS), assume sip-01 in this example and REGISTERs, sip-01 will call save("location") which updates/inserts to the location table. sip-01 then calls t_replicate to sip-02.
sip-02 recieves the REGISTER message and calls save_memory("location") to update its in-memory cache only. It should never hit db-02.
Now db-01 eventually (within a second or two) replicates to db-02 and now sip-02 is good to go, even in the event of a restart.
Our difficulties mostly surrounded the fact that ser was inserting the physical IP of eth0 on the server as the top VIA rather than the VIP as required. We solved this by using record_route_preset() and passing the VIP as the IP. We also had to bring up a dummy interface in order to get ser to honor the VIP.
Hope this helps.
Regards, Paul
On Apr 8, 2005 7:19 PM, Tina kramarv@yahoo.com wrote:Paul, we are using LVS as well. It creates template connection according to source Ip (e.g. UAC) and forwards to one of the tunneled IP. I tested this a couple of weeks ago, ser was happy and inserted VIP into via header, the only issue is to route the calls into right server. I agree, there is no such thing as SIP-level clustering. However, how would you solve location problem by DB replication - 1) usrloc does not update from DB....2) even though, I am afraid it can become bottleneck and lock down users ...
KRs, Tina
Java Rockx javarockx@gmail.com wrote: See my inline comments.
Regards, Paul
On Apr 8, 2005 1:08 PM, Greger V. Teigre greger@teigre.com wrote: Hi Tina,
I enjoy reading your posts, thanks a lot for the great work you are doing for ser users!
Thanks :-)
I am going to consider that kind of scenario as well (load balancer returning Virtual IP address). I think for such configuration server side has to keep session information and always forward a call to the right server.
I believe the load balancer can be in front and transparantly translate addresses in the SIP messages: User agent always sees a.b.c.d | Load balancer with public IP a.b.c.d | | ser1 (10.0.0.2) ser2 (10.0.0.3)
Paul: You have a similar load-balancing solution, right? Do you use a commerical load balancer that you can reveal the name of? :-)
Our platform is 100% open source. Our load balancer is LVS. I have no idea how it actually works. One if our engineers from RedHat set all that networking stuff up and it's way beyond me.
The load balancer need to understand SIP (sort of) and use something (ex. IP address of user agent) to select SER server to send to and rewrite incoming to 10.0.0.2 and 10.0.0.3 respectively and outgoing to a.b.c.d. ser1 and ser2 will happily believe they are alone and communicate directly with user agent using their own private addresses. Both should know about all users (usrloc). Paul just recently posted a small patch for a setup where they use two-way replication between two
That small patch will need a slight revision. We discovered through further testing that that patch only fixed attempts to INSERT into the location table. We didn't cover the UPDATE route, unfortunately. I believe Andrew has that patch done and is testing it. So I'll post it to serdev as soon as we know it works - possibly later today.
mysql servers and where each SER instance will save all REGISTERs it receives from user agents, but only save to memory those replicated from the other SER peer. Klaus pointed out that the same can be done by not doing mysql replication, but have one DB for each SER and just use t_replicate() and save_noreply() (for two servers, for more than two you need to use forward_tcp()).
I have heard complaints that this approach will generate too much network traffic. Also, t_replicate() does not guarantee delivery of the replication (forward_tcp is better, but not fool proof). So, the "best" solution would probably be to hope that Paul's
I fully agree. Replication at the sip proxy level, IMHO, is not a good idea. From a purist point of view, replication is not a function of a SIP router - nor should it be. It is a function of the database and we believe that the MySQL replication is a better approach from a speed and reliabilty point of view - not to mention that it simplifies the tasks of the sip router.
recent TCP/UDP patch for network access to FIFO commands get included in the CVS. Then, a new replication module should use XMLRPC or whatever protocol the patch is using to forward (in a guaranteed mode) the usrloc information, which then would be injected directly into SER's memory, just like save() would, and of course in whatever db_mode you would like. The replicaton module would have to keep a queue (of course, flushed to a DB or something) in case of network problems, so that the replication would be done (sooner or later) regardless of problems. Of course, this is a major undertaking, so for most replication scenarioes, I would think the forward_tcp() + save_noreply() would work just fine.
g-)
"Greger V. Teigre" greger@teigre.com wrote: I was thinking about a load balancing scenario where the load balancer will replace the IP addresses. g-)
---- 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 t! he 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
Yahoo! Messenger Show us what our next emoticon should look like. Join the fun.
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
--------------------------------- Do you Yahoo!? Make Yahoo! your home page
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Greger, thanks a lot. The problem with load balancer is that replies goes to the wrong server due to rewriting outgoing a.b.c.d . BTW, as Paul pointed, if you define some dummy interface with Virtual IP (VIP), there is no need to rewrite outgoing messages (I tested this a little).
Why DNS approach is bad (except restricted NAT - let's say I am solving this)?
I guess, Paul utilizes load-balancer scenario you have described. Believe there are only proprietary solutions for "the-replies-problem". We tried Vovida call-id-persistence package, unfortunately it didn't work for us.
In my configuration I use shared remote DB cluster (with replication). Each ser see it as one-public-IP (exactly the approach you named for SIP). May be it's good idea to use local DB clusters, but if you have more than 2 servers your replication algorythm gonna be complex. Additional problem - it still doesn't solve usrloc synchronization - you still have to use t_replicate()...
With regard to t_replicate() - it doesn't work for more than 2 servers, so I used exactly forward_tcp() and save_noreply() (you're absolutely right - this works fine so far); all sers are happy. Of course, this causes additional traffic. Interesting whether Paul's FIFO patch reduces traffic between sers?
KRs, Tina, software engineer
"Greger V. Teigre" greger@teigre.com wrote: Hi Tina,
I enjoy reading your posts, thanks a lot for the great work you are doing for ser users!
Thanks :-)
I am going to consider that kind of scenario as well (load balancer returning Virtual IP address). I think for such configuration server side has to keep session information and always forward a call to the right server.
I believe the load balancer can be in front and transparantly translate addresses in the SIP messages: User agent always sees a.b.c.d | Load balancer with public IP a.b.c.d | | ser1 (10.0.0.2) ser2 (10.0.0.3)
Paul: You have a similar load-balancing solution, right? Do you use a commerical load balancer that you can reveal the name of? :-)
The load balancer need to understand SIP (sort of) and use something (ex. IP address of user agent) to select SER server to send to and rewrite incoming to 10.0.0.2 and 10.0.0.3 respectively and outgoing to a.b.c.d. ser1 and ser2 will happily believe they are alone and communicate directly with user agent using their own private addresses. Both should know about all users (usrloc). Paul just recently posted a small patch for a setup where they use two-way replication between two mysql servers and where each SER instance will save all REGISTERs it receives from user agents, but only save to memory those replicated from the other SER peer. Klaus pointed out that the same can be done by not doing mysql replication, but have one DB for each SER and just use t_replicate() and save_noreply() (for two servers, for more than two you need to use forward_tcp()).
I have heard complaints that this approach will generate too much network traffic. Also, t_replicate() does not guarantee delivery of the replication (forward_tcp is better, but not fool proof). So, the "best" solution would probably be to hope that Paul's recent TCP/UDP patch for network access to FIFO commands get included in the CVS. Then, a new replication module should use XMLRPC or whatever protocol the patch is using to forward (in a guaranteed mode) the usrloc information, which then would be injected directly into SER's memory, just like save() would, and of course in whatever db_mode you would like. The replicaton module would have to keep a queue (of course, flushed to a DB or something) in case of network problems, so that the replication would be done (sooner or later) regardless of problems. Of course, this is a major undertaking, so for most replication scenarioes, I would think the forward_tcp() + save_noreply() would work just fine.
g-)
"Greger V. Teigre" greger@teigre.com wrote: I was thinking about a load balancing scenario where the load balancer will replace the IP addresses. g-)
---- 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 t! he 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
Yahoo! Messenger Show us what our next emoticon should look like. Join the fun.
--------------------------------- Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard.
Greger, thanks a lot. The problem with load balancer is that replies goes to the wrong server due to rewriting outgoing a.b.c.d . BTW, as Paul pointed, if you define some dummy interface with Virtual IP (VIP), there is no need to rewrite outgoing messages (I tested this a little).
Yes, if you use LVS with direct routing or tunneling, that is what you experience. What I described was a "generic" SIP-aware load balancer where SIP messages would be rewritten and stickiness implemented based on ex. UA IP address (or call-id like vovida's load balancer).
Why DNS approach is bad (except restricted NAT - let's say I am solving this)?
Well, IMO, DNS SRV in itself is not bad. It's just that many user clients do not support DNS SRV yet. Except that, I like the concept and it will give you a geographical redundancy and load balancing.
I guess, Paul utilizes load-balancer scenario you have described. Believe there are only proprietary solutions for "the-replies-problem". We tried Vovida call-id-persistence package, unfortunately it didn't work for us.
Are you referring to the load balancer proxy? IMHO, the SIP-aware load balancer makes things a bit messy. It sounds to me that the LVS + tunneling/direct routing + virtual IP on dummy adapter is a better solution.
In my configuration I use shared remote DB cluster (with replication). Each ser see it as one-public-IP (exactly the approach you named for SIP). May be it's good idea to use local DB clusters, but if you have more than 2 servers your replication algorythm gonna be complex. Additional problem - it still doesn't solve usrloc synchronization - you still have to use t_replicate()...
I'm not sure if I understand. So, you have 2 servers at two location, each location with a shared DB and then replication across an IPsec tunnel?? IMHO, mysql 3.23.x two-way replication is quite shaky and dangerous to rely on. With no locking, you will easily get overwrites and you have to be very sure that your application doesn't mess up the DB. I haven't looked at mysql 4.1 clustering, but from the little I have seen, it looks good. Is that what you use?
With regard to t_replicate() - it doesn't work for more than 2 servers, so I used exactly forward_tcp() and save_noreply() (you're absolutely right - this works fine so far); all sers are happy. Of course, this causes additional traffic. Interesting whether Paul's FIFO patch reduces traffic between sers?
I believe Paul uses forward_tcp() and save_memory() to save the location to the replicated server's memory, while the save("location") on the primary server will store to the DB (which then replicates on the DB level). g-)
See inline.
On Apr 10, 2005 5:32 AM, Greger V. Teigre greger@teigre.com wrote:
Greger, thanks a lot. The problem with load balancer is that replies goes to the wrong server due to rewriting outgoing a.b.c.d . BTW, as Paul pointed, if you define some dummy interface with Virtual IP (VIP), there is no need to rewrite outgoing messages (I tested this a little).
Yes, if you use LVS with direct routing or tunneling, that is what you experience. What I described was a "generic" SIP-aware load balancer where SIP messages would be rewritten and stickiness implemented based on ex. UA IP address (or call-id like vovida's load balancer).
Why DNS approach is bad (except restricted NAT - let's say I am solving this)?
Well, IMO, DNS SRV in itself is not bad. It's just that many user clients do not support DNS SRV yet. Except that, I like the concept and it will give you a geographical redundancy and load balancing.
I guess, Paul utilizes load-balancer scenario you have described. Believe there are only proprietary solutions for "the-replies-problem". We tried Vovida call-id-persistence package, unfortunately it didn't work for us.
Are you referring to the load balancer proxy? IMHO, the SIP-aware load balancer makes things a bit messy. It sounds to me that the LVS + tunneling/direct routing + virtual IP on dummy adapter is a better solution.
In my configuration I use shared remote DB cluster (with replication). Each ser see it as one-public-IP (exactly the approach you named for SIP). May be it's good idea to use local DB clusters, but if you have more than 2 servers your replication algorythm gonna be complex. Additional problem - it still doesn't solve usrloc synchronization - you still have to use t_replicate()...
I'm not sure if I understand. So, you have 2 servers at two location, each location with a shared DB and then replication across an IPsec tunnel?? IMHO, mysql 3.23.x two-way replication is quite shaky and dangerous to rely on. With no locking, you will easily get overwrites and you have to be very sure that your application doesn't mess up the DB. I haven't looked at mysql 4.1 clustering, but from the little I have seen, it looks good. Is that what you use?
I agree. That is why we use MySQL 4.1.
With regard to t_replicate() - it doesn't work for more than 2
servers, so I used exactly forward_tcp() and save_noreply() (you're absolutely right - this works fine so far); all sers are happy. Of course, this causes additional traffic. Interesting whether Paul's FIFO patch reduces traffic between sers?
I believe Paul uses forward_tcp() and save_memory() to save the location to the replicated server's memory, while the save("location") on the primary server will store to the DB (which then replicates on the DB level).
My ser.cfg uses t_replicate() and save_memory() with our urecord.c patch applied. save_memory() does not work when the db_mode is write-through. What happens is save() is called from SIP-01 which does either an INSERT or UPDATE sql on the location table.
But save_memory() attempts to do the same thing on SIP-02 (only in write-through mode). So we had to patch usrloc's urecord.c file to have it honor a flag called FL_MEM because if I call save_memory("location") I demand that ser only save to memory - but it doesn't so this, IMHO is a bug.
I posted a patch for this last Thursday to serdev, but unfortunately we identified another related bug in ser, so a revised patch is needed, which I'll try to post tomorrow.
Regards, Paul
g-)
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Paul, I appreciate a lot this information, and am interested in your patch a lot. Tina
Java Rockx javarockx@gmail.com wrote: See inline.
On Apr 10, 2005 5:32 AM, Greger V. Teigre greger@teigre.com wrote:> Greger, thanks a lot.
The problem with load balancer is that replies goes to the wrong server due to rewriting outgoing a.b.c.d . BTW, as Paul pointed, if you define some dummy interface with Virtual IP (VIP), there is no need to rewrite outgoing messages (I tested this a little).
Yes, if you use LVS with direct routing or tunneling, that is what you experience. What I described was a "generic" SIP-aware load balancer where SIP messages would be rewritten and stickiness implemented based on ex. UA IP address (or call-id like vovida's load balancer).
Why DNS approach is bad (except restricted NAT - let's say I am solving this)?
Well, IMO, DNS SRV in itself is not bad. It's just that many user clients do not support DNS SRV yet. Except that, I like the concept and it will give you a geographical redundancy and load balancing.
I guess, Paul utilizes load-balancer scenario you have described. Believe there are only proprietary solutions for "the-replies-problem". We tried Vovida call-id-persistence package, unfortunately it didn't work for us.
Are you referring to the load balancer proxy? IMHO, the SIP-aware load balancer makes things a bit messy. It sounds to me that the LVS + tunneling/direct routing + virtual IP on dummy adapter is a better solution.
In my configuration I use shared remote DB cluster (with replication). Each ser see it as one-public-IP (exactly the approach you named for SIP). May be it's good idea to use local DB clusters, but if you have more than 2 servers your replication algorythm gonna be complex. Additional problem - it still doesn't solve usrloc synchronization - you still have to use t_replicate()...
I'm not sure if I understand. So, you have 2 servers at two location, each location with a shared DB and then replication across an IPsec tunnel?? IMHO, mysql 3.23.x two-way replication is quite shaky and dangerous to rely on. With no locking, you will easily get overwrites and you have to be very sure that your application doesn't mess up the DB. I haven't looked at mysql 4.1 clustering, but from the little I have seen, it looks good. Is that what you use?
I agree. That is why we use MySQL 4.1.
With regard to t_replicate() - it doesn't work for more than 2 servers, so I used exactly forward_tcp() and save_noreply() (you're absolutely right - this works fine so far); all sers are happy. Of course, this causes additional traffic. Interesting whether Paul's FIFO patch reduces traffic between sers?
I believe Paul uses forward_tcp() and save_memory() to save the location to the replicated server's memory, while the save("location") on the primary server will store to the DB (which then replicates on the DB level).
My ser.cfg uses t_replicate() and save_memory() with our urecord.c patch applied. save_memory() does not work when the db_mode is write-through. What happens is save() is called from SIP-01 which does either an INSERT or UPDATE sql on the location table.
But save_memory() attempts to do the same thing on SIP-02 (only in write-through mode). So we had to patch usrloc's urecord.c file to have it honor a flag called FL_MEM because if I call save_memory("location") I demand that ser only save to memory - but it doesn't so this, IMHO is a bug.
I posted a patch for this last Thursday to serdev, but unfortunately we identified another related bug in ser, so a revised patch is needed, which I'll try to post tomorrow.
Regards, Paul
g-)
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
--------------------------------- Do you Yahoo!? Yahoo! Small Business - Try our new resources site!
Well it's going on 1:30AM here in the US so when our Red Hat engineer gets in I'll have him give me the final patch for the save_memory() bug. I'll post it to serdev then. It should be about 12PM local time on the US east coast.
Regards, Paul
On Apr 10, 2005 11:10 PM, Tina kramarv@yahoo.com wrote:
Paul, I appreciate a lot this information, and am interested in your patch a lot. Tina
*Java Rockx javarockx@gmail.com* wrote:
See inline.
On Apr 10, 2005 5:32 AM, Greger V. Teigre greger@teigre.com wrote:
Greger, thanks a lot. The problem with load balancer is that replies goes to the wrong server due to rewriting outgoing a.b.c.d . BTW, as Paul pointed, if you define some dummy interface with Virtual IP (VIP), there is no need to rewrite outgoing messages (I tested this a little).
Yes, if you use LVS with direct routing or tunneling, that is what you experience. What I described was a "generic" SIP-aware load balancer where SIP messages would be rewritten and stickiness implemented based on ex. UA IP address (or call-id like vovida's load balancer).
Why DNS approach is bad (except restricted NAT - let's say I am solving this)?
Well, IMO, DNS SRV in itself is not bad. It's just that many user clients do not support DNS SRV yet. Except that, I like the concept and it will give you a geographical redundancy and load balancing.
I guess, Paul utilizes load-balancer scenario you have described. Believe there are only proprietary solutions for "the-replies-problem". We tried Vovida call-id-persistence package, unfortunately it didn't work for us.
Are you referring to the load balancer proxy? IMHO, the SIP-aware load balancer makes things a bit messy. It sounds to me that the LVS + tunneling/direct routing + virtual IP on dummy adapter is a better solution.
In my configuration I use shared remote DB cluster (with replication). Each ser see it as one-public-IP (exactly the approach you named for SIP). May be it's good idea to use local DB clusters, but if you have more than 2 servers your replication algorythm gonna be complex. Additional problem - it still doesn't solve usrloc synchronization - you still have to use t_replicate()...
I'm not sure if I understand. So, you have 2 servers at two location, each location with a shared DB and then replication across an IPsec tunnel??
IMHO, mysql 3.23.x two-way replication is quite shaky and dangerous to rely on. With no locking, you will easily get overwrites and you have to be very sure that your application doesn't mess up the DB. I haven't looked at mysql 4.1 clustering, but from the little I have seen, it looks good. Is that what you use?
I agree. That is why we use MySQL 4.1.
With regard to t_replicate() - it doesn't work for more than 2
servers, so I used exactly forward_tcp() and save_noreply() (you're absolutely right - this works fine so far); all sers are happy. Of course, this causes additional traffic. Interesting whether Paul's FIFO patch reduces traffic between sers?
I believe Paul uses forward_tcp() and save_memory() to save the location to the replicated server's memory, while the save("location") on the primary server will store to the DB (which then replicates on the DB level).
My ser.cfg uses t_replicate() and save_memory() with our urecord.c patch applied. save_memory() does not work when the db_mode is write-through. What happens is save() is called from SIP-01 which does either an INSERT or UPDATE sql on the location table.
But save_memory() attempts to do the same thing on SIP-02 (only in write-through mode). So we had to patch usrloc's urecord.c file to have it honor a flag called FL_MEM because if I call save_memory("location") I demand that ser only save to memory - but it doesn't so this, IMHO is a bug.
I posted a patch for this last Thursday to serdev, but unfortunately we identified another related bug in ser, so a revised patch is needed, which I'll try to post tomorrow.
Regards, Paul
g-)
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Do you Yahoo!? Yahoo! Small Business - Try our new resources site!http://us.rd.yahoo.com/evt=31637/*http://smallbusiness.yahoo.com/resources/
Thx!!!
Java Rockx javarockx@gmail.com wrote:Well it's going on 1:30AM here in the US so when our Red Hat engineer gets in I'll have him give me the final patch for the save_memory() bug. I'll post it to serdev then. It should be about 12PM local time on the US east coast.
Regards, Paul
On Apr 10, 2005 11:10 PM, Tina kramarv@yahoo.com wrote:Paul, I appreciate a lot this information, and am interested in your patch a lot. Tina
Java Rockx javarockx@gmail.com wrote:
See inline.
On Apr 10, 2005 5:32 AM, Greger V. Teigre greger@teigre.com wrote: > Greger, thanks a lot.
The problem with load balancer is that replies goes to the wrong server due to rewriting outgoing a.b.c.d . BTW, as Paul pointed, if you define some dummy interface with Virtual IP (VIP), there is no need to rewrite outgoing messages (I tested this a little).
Yes, if you use LVS with direct routing or tunneling, that is what you experience. What I described was a "generic" SIP-aware load balancer where SIP messages would be rewritten and stickiness implemented based on ex. UA IP address (or call-id like vovida's load balancer).
Why DNS approach is bad (except restricted NAT - let's say I am solving this)?
Well, IMO, DNS SRV in itself is not bad. It's just that many user clients do not support DNS SRV yet. Except that, I like the concept and it will give you a geographical redundancy and load balancing.
I guess, Paul utilizes load-balancer scenario you have described. Believe there are only proprietary solutions for "the-replies-problem". We tried Vovida call-id-persistence package, unfortunately it didn't work for us.
Are you referring to the load balancer proxy? IMHO, the SIP-aware load balancer makes things a bit messy. It sounds to me that the LVS + tunneling/direct routing + virtual IP on dummy adapter is a better solution.
In my configuration I use shared remote DB cluster (with replication). Each ser see it as one-public-IP (exactly the approach you named for SIP). May be it's good idea to use local DB clusters, but if you have more than 2 servers your replication algorythm gonna be complex. Additional problem - it still doesn't solve usrloc synchronization - you still have to use t_replicate()...
I'm not sure if I understand. So, you have 2 servers at two location, each location with a shared DB and then replication across an IPsec tunnel?? IMHO, mysql 3.23.x two-way replication is quite shaky and dangerous to rely on. With no locking, you will easily get overwrites and you have to be very sure that your application doesn't mess up the DB. I haven't looked at mysql 4.1 clustering, but from the little I have seen, it looks good. Is that what you use?
I agree. That is why we use MySQL 4.1.
With regard to t_replicate() - it doesn't work for more than 2 servers, so I used exactly forward_tcp() and save_noreply() (you're absolutely right - this works fine so far); all sers are happy. Of course, this causes additional traffic. Interesting whether Paul's FIFO patch reduces traffic between sers?
I believe Paul uses forward_tcp() and save_memory() to save the location to the replicated server's memory, while the save("location") on the primary server will store to the DB (which then replicates on the DB level).
My ser.cfg uses t_replicate() and save_memory() with our urecord.c patch applied. save_memory() does not work when the db_mode is write-through. What happens is save() is called from SIP-01 which does either an INSERT or UPDATE sql on the location table.
But save_memory() attempts to do the same thing on SIP-02 (only in write-through mode). So we had to patch usrloc's urecord.c file to have it honor a flag called FL_MEM because if I call save_memory("location") I demand that ser only save to memory - but it doesn't so this, IMHO is a bug.
I posted a patch for this last Thursday to serdev, but unfortunately we identified another related bug in ser, so a revised patch is needed, which I'll try to post tomorrow.
Regards, Paul
g-)
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
--------------------------------- Do you Yahoo!? Yahoo! Small Business - Try our new resources site!
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi sir, thanks a lot for the great work you are doing! I have a silly question... I need to keep some session information (to forward the call via "appropriate" server). Is it possible to obtain hostname from ser.cfg or I should implement some proprietary external coding...? Thanks in advance, Tina
"Greger V. Teigre" greger@teigre.com wrote: I was thinking about a load balancing scenario where the load balancer will replace the IP addresses. g-)
---- 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
--------------------------------- Do you Yahoo!? Better first dates. More second dates. Yahoo! Personals
Tina, 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."
Anyway, have you looked at the new LCR module? (for the HEAD CVS, but backported, you can find the backport at http://onsip.org) g-) ---- Original Message ---- From: Tina To: Greger V. Teigre Cc: serusers@lists.iptel.org Sent: Friday, April 08, 2005 02:11 AM Subject: Re: [Serusers] still no help - usrloc synchronization
Hi sir, thanks a lot for the great work you are doing! I have a silly question... I need to keep some session information (to forward the call via "appropriate" server). Is it possible to obtain hostname from ser.cfg or I should implement some proprietary external coding...? Thanks in advance, Tina
"Greger V. Teigre" greger@teigre.com wrote: I was thinking about a load balancing scenario where the load balancer will replace the IP addresses. g-)
---- 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 t! he 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
Do you Yahoo!? Better first dates. More second dates. Yahoo! Personals
Hi sir, thanks a lot for the great work you are doing! I have a silly question... I need to keep some session information (to forward the call via "appropriate" server). Is it possible to obtain hostname from ser.cfg or I should implement some proprietary external coding...? Thanks in advance, Tina
--- "Greger V. Teigre" greger@teigre.com wrote:
I was thinking about a load balancing scenario where the load balancer will replace the IP addresses. g-)
---- 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
__________________________________ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com
-
Andreas Granig -
Greger V. Teigre -
Java Rockx -
Tina