Norman/Bogdan,
I went and implemented three location tables in MySQL and pointed each OpenSER to a different one. I think this is going to have problems...
Say a phone registers with proxy1, and proxy1 updates location table location_proxy1. I see two problems here:
a) Based on the expiry in location_proxy1, proxy1 removes the phone from it's location table location_proxy1. At about the same time, the phone re-registers, and this time registers with proxy2 (our phones use DNS SRV). For some small amount of time, the phone could be present in TWO location tables. This is bad.
b) The phone re-registers before the expiry in location_proxy1 occurs, lets say because it's been rebooted. When the phone comes back up and re-registers, it regisers with proxy2 this time (again because of DNS SRV). For possibly a very LONG time, the phone will be current in two location tables on 2 proxy servers. If the phone was rebooted again, it could be present in the location table on THREE proxy servers. This is also bad.
-----Original Message----- From: Norman Brandinger [mailto:norm@goes.com] Sent: Tuesday, March 28, 2006 12:41 PM To: Douglas Garstang Cc: Bogdan-Andrei Iancu; users@openser.org Subject: Re: [Users] OpenSER MySQL Updates - Weird
Douglas,
Below is Bogdan's previous response to you:
<snip> all db_mods from 0 to 2 use mem cache - the difference is when the DB is updated with changes from cache. in mod 1 the changes from cache are immediately written into DB.
the only non-cache db mod is 3, but this is available only in the devel branch - read carefully the docs to understand the implications of this mod.
</snip>
As you can see, he didn't say that db mode 3 is required in your situation. He was just briefly explaining the option and steering you to the docs for more detailed information. I don't think that the devel CVS branch is called OpenSER 1.1 but that's just a matter of semantics.
Anyway, getting back to your question:
If you google "multiple SER site:mail.iptel.org" you will find a discussion of your problem along with suggested solutions.
A thread along these lines is, for example: http://mail.iptel.org/pipermail/serusers/2003-November/003847.html
<from the above thread> We have multiple SER servers all accesing the same database. We had to introduce a new "location" table for each instance of SER. So for example we have a main SER server which acceses the standard "location" table and we have another SER as RTPProxy which uses a table called "location_proxy". We just created that custom table using the structure of the regular "location" table.
Has been working great for us for several months. </from the above thread>
I have found that searching mail.iptel.org will often provide answers to many questions. Note that the above example thread was posted back in 2003.
Regards, Norm
Douglas Garstang wrote:
So, are you saying, based on the email you sent (which I
just found) that Openser 1.1 and db_mode 3 are REQUIRED in order to support multiple OpenSER systems accessing a common MySQL database?
-----Original Message----- From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] Sent: Tuesday, March 28, 2006 9:06 AM To: Douglas Garstang Cc: users@openser.org Subject: Re: [Users] OpenSER MySQL Updates - Weird
Doug,
first of all, if you do not get a reply, do not repost ...no one owes replies to no body.
second...you got a reply..check carefully your emails.
bogdan
Douglas Garstang wrote:
Posted this yesterday. Didn't get a reply...
Bogdan, thanks for the reply. I'm don't quite understand. I'm using db_mode 1, which the docs say writes all updates immediately to the database. A 'openserctl ul show' still shows cached entries though. Why? Is db_mode 1 supposed to cache at all? Which db_mode should I use so that I can have two or more OpenSER systems safely accessing the same database?
Douglas.
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Douglas Garstang wrote:
I went and implemented three location tables in MySQL and pointed each OpenSER to a different one. I think this is going to have problems...
<snip>
We use http://www.mysql.com/products/database/cluster/ in combination with cacheless usrloc in order to cope with this issue. This allows the proxies to keep a consistent location table. Works great for us, so maybe you should give it a try...
Just my 2 cents, Andy