26 Sep
2004
26 Sep
'04
10:04 a.m.
Let's say I have 2 SER servers (ser1 and ser2). Both save to the same MySQL
location table and both use t_replicate to let each other know about new
REGISTER's. Lets say ser1 gets a REGISTER from a client and then calls
t_replicate to send it over to ser2 and both call save("location").
Doesn't
that cause ser1 and ser2 to write the same record at about the same time to
MySQL? Is there any way to prevent doubling the number of database writes?
Does anyone know what the replicate column is for in the location table?
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
26 Sep
26 Sep
10:27 a.m.
Michael Shuler wrote:
Let's say I have 2 SER servers (ser1 and ser2).
Both save to the same MySQL
location table and both use t_replicate to let each other know about new
REGISTER's. Lets say ser1 gets a REGISTER from a client and then calls
t_replicate to send it over to ser2 and both call save("location").
Doesn't
that cause ser1 and ser2 to write the same record at about the same time to
MySQL? Is there any way to prevent doubling the number of database writes?
You can configure one of the ser's to do not use database at all for
storing contacts, which will do what you want - contacts will be saved
by the another ser, while t_replicate() will ensure that both of them
have a whole set at any moment of time.
-Maxim
Does anyone know what the replicate column is for in the location table?
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
8:56 p.m.
I figured that's what people would say :( thanks though.
I thought of that but the problem is that it takes up to the max time of my
longest REGISTER client timer before its back in sync with the one that runs
off the DB. It would be nice if there was a 3rd option i.e.
modparam("usrloc", "db_mode", 3) that would make it read only at
startup to
"seed" the memory database. The reason I need this is because I have a few
SER servers behind a Foundry ServerIron XL layer 4 switch. When I bring the
failed server back online the Foundry automatically recognizes that port
5060 is alive again and immediately starts sending it traffic. If the RAM
based location table hasn't been fully populated by the time this happens
then we have a bunch of failed calls until it syncs up which in my case is
up to 5 min. I can get around this manually by removing it from the cluster
config in the Foundry but that takes away from the automation of the whole
thing.
Andrei/Jiri, what do you guys think of adding that as an option? It seems
to me that it would be the most logical way to go about doing it and should
be very easy to do since all it is combining parts of mode 0 and 1/2. I
have little experience doing any programming in SER otherwise I would just
write it and submit it as a patch. Most of my time gets sucked up into
Asterisk patches (see http://svn.asteriskdocs.org/res_data/ for MySQL
dynamic config files, this is a must for carriers... Well at least for me :)
), but if you 2 don't have time or don't think its worth while then I guess
I will have find time. Please let me know what you guys think of this as
soon as you get a chance.
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
-----Original Message-----
From: Maxim Sobolev [mailto:sobomax@portaone.com]
Sent: Sunday, September 26, 2004 3:28 AM
To: Michael Shuler
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Location table issues
Michael Shuler wrote:
Let's say I have 2 SER servers (ser1 and
ser2). Both save
to the same MySQL
location table and both use t_replicate to let
each other
know about new
REGISTER's. Lets say ser1 gets a REGISTER
from a client
and then calls
t_replicate to send it over to ser2 and both call
save("location"). Doesn't
that cause ser1 and ser2 to write the same record
at about
the same time to
MySQL? Is there any way to prevent doubling the
number of
database writes?
You can configure one of the ser's to do not use database at all for
storing contacts, which will do what you want - contacts will
be saved
by the another ser, while t_replicate() will ensure that both of them
have a whole set at any moment of time.
-Maxim
Does anyone know what the replicate column is for in the
location table?
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
9:20 p.m.
Michael,
I think your idea for a db_mode 3 is a good idea especially considering that
I'll soon be in the same position as you with respect to ser.
On an Asterisk note you mentioned patches at
http://svn.asteriskdocs.org/res_data/. Do these patches allow Asterisk to store
user and server configuration data in a MySQL database rather than in .conf
files? If not, could you elaborate a bit on what these patches fix or features
that they provide?
Best Regards,
Paul
--- Michael Shuler <mike(a)bwsys.net> wrote:
I figured that's what people would say :( thanks
though.
I thought of that but the problem is that it takes up to the max time of my
longest REGISTER client timer before its back in sync with the one that runs
off the DB. It would be nice if there was a 3rd option i.e.
modparam("usrloc", "db_mode", 3) that would make it read only at
startup to
"seed" the memory database. The reason I need this is because I have a few
SER servers behind a Foundry ServerIron XL layer 4 switch. When I bring the
failed server back online the Foundry automatically recognizes that port
5060 is alive again and immediately starts sending it traffic. If the RAM
based location table hasn't been fully populated by the time this happens
then we have a bunch of failed calls until it syncs up which in my case is
up to 5 min. I can get around this manually by removing it from the cluster
config in the Foundry but that takes away from the automation of the whole
thing.
Andrei/Jiri, what do you guys think of adding that as an option? It seems
to me that it would be the most logical way to go about doing it and should
be very easy to do since all it is combining parts of mode 0 and 1/2. I
have little experience doing any programming in SER otherwise I would just
write it and submit it as a patch. Most of my time gets sucked up into
Asterisk patches (see http://svn.asteriskdocs.org/res_data/ for MySQL
dynamic config files, this is a must for carriers... Well at least for me :)
), but if you 2 don't have time or don't think its worth while then I guess
I will have find time. Please let me know what you guys think of this as
soon as you get a chance.
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
-----Original Message-----
From: Maxim Sobolev [mailto:sobomax@portaone.com]
Sent: Sunday, September 26, 2004 3:28 AM
To: Michael Shuler
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Location table issues
Michael Shuler wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Let's say I have 2 SER servers (ser1 and
ser2). Both save
to the same MySQL
location table and both use t_replicate to let
each other
know about new
REGISTER's. Lets say ser1 gets a REGISTER
from a client
and then calls
t_replicate to send it over to ser2 and both call
save("location"). Doesn't
that cause ser1 and ser2 to write the same record
at about
the same time to
MySQL? Is there any way to prevent doubling the
number of
database writes?
You can configure one of the ser's to do not use database at all for
storing contacts, which will do what you want - contacts will
be saved
by the another ser, while t_replicate() will ensure that both of them
have a whole set at any moment of time.
-Maxim
Does anyone know what the replicate column is for in the
location table?
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
9:34 p.m.
Yup, that's exactly what they do. We put the full LERG in there which is
about 350,000 routes and it doesn't even bother it thanks to MySQL's ability
to search records lightning fast.
We also use it to provision our customers and their routing live via some
PHP scripts which simply write to the MySQL tables appropriately. No more
restarting or reloading Asterisk :)
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
-----Original Message-----
From: Java Rockx [mailto:javarockx@yahoo.com]
Sent: Sunday, September 26, 2004 2:21 PM
To: Michael Shuler; serusers(a)lists.iptel.org
Subject: RE: [Serusers] Location table issues
Michael,
I think your idea for a db_mode 3 is a good idea especially
considering that
I'll soon be in the same position as you with respect to ser.
On an Asterisk note you mentioned patches at
http://svn.asteriskdocs.org/res_data/. Do these patches allow
Asterisk to store
user and server configuration data in a MySQL database rather
than in .conf
files? If not, could you elaborate a bit on what these
patches fix or features
that they provide?
Best Regards,
Paul
--- Michael Shuler <mike(a)bwsys.net> wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
I figured that's what people would say :(
thanks though.
I thought of that but the problem is that it takes up to
the max time of my
longest REGISTER client timer before its back in
sync with
the one that runs
off the DB. It would be nice if there was a 3rd
option i.e.
modparam("usrloc", "db_mode", 3) that would make it read
only
at startup to
"seed" the memory database. The reason
I need this is
because I have a few
SER servers behind a Foundry ServerIron XL layer
4 switch.
When I bring the
failed server back online the Foundry
automatically
recognizes that port
5060 is alive again and immediately starts
sending it
traffic. If the RAM
based location table hasn't been fully
populated by the
time this happens
then we have a bunch of failed calls until it
syncs up
which in my case is
up to 5 min. I can get around this manually by
removing it
from the cluster
config in the Foundry but that takes away from
the
automation of the whole
thing.
Andrei/Jiri, what do you guys think of adding that as an
option? It seems
to me that it would be the most logical way to go
about
doing it and should
be very easy to do since all it is combining
parts of mode
0 and 1/2. I
have little experience doing any programming in
SER
otherwise I would just
write it and submit it as a patch. Most of my
time gets
sucked up into
Asterisk patches (see
http://svn.asteriskdocs.org/res_data/
for MySQL
dynamic config files, this is a must for
carriers... Well
at least for me :)
), but if you 2 don't have time or don't
think its worth
while then I guess
I will have find time. Please let me know what
you guys
think of this as
soon as you get a chance.
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
> -----Original Message-----
> From: Maxim Sobolev [mailto:sobomax@portaone.com]
> Sent: Sunday, September 26, 2004 3:28 AM
> To: Michael Shuler
> Cc: serusers(a)lists.iptel.org
> Subject: Re: [Serusers] Location table issues
>
>
> Michael Shuler wrote:
>
> > Let's say I have 2 SER servers (ser1 and ser2). Both save
> to the same MySQL
> > location table and both use t_replicate to let each other
> know about new
> > REGISTER's. Lets say ser1 gets a REGISTER from a client
> and then calls
> > t_replicate to send it over to ser2 and both call
> save("location"). Doesn't
> > that cause ser1 and ser2 to write the same record at about
> the same time to
> > MySQL? Is there any way to prevent doubling the number of
> database writes?
>
> You can configure one of the ser's to do not use database
at all for
> storing contacts, which will do what you
want - contacts will
> be saved
> by the another ser, while t_replicate() will ensure that
both of them
> have a whole set at any moment of time.
>
> -Maxim
>
> >
> > Does anyone know what the replicate column is for in the
> location table?
> >
> > ----------------------------------------
> >
> > Michael Shuler, C.E.O.
> > BitWise Communications, Inc. (CLEC) And BitWise
Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
9:42 p.m.
Oh yeah, one more REALLY important feature. It allows you to have a cluster
of Asterisk servers all run off a live common config. No more having to
mess around with NFS or trying to sync config files :) Mark Spencer has
said he plans on putting this patch in Asterisk 1.1 or 1.2 but since 1.0.0
JUST came out you can bet it will be a while.
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Michael Shuler
Sent: Sunday, September 26, 2004 2:35 PM
To: 'Java Rockx'; serusers(a)lists.iptel.org
Subject: RE: [Serusers] Location table issues
Yup, that's exactly what they do. We put the full LERG in
there which is
about 350,000 routes and it doesn't even bother it thanks to
MySQL's ability
to search records lightning fast.
We also use it to provision our customers and their routing
live via some
PHP scripts which simply write to the MySQL tables
appropriately. No more
restarting or reloading Asterisk :)
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
-----Original Message-----
From: Java Rockx [mailto:javarockx@yahoo.com]
Sent: Sunday, September 26, 2004 2:21 PM
To: Michael Shuler; serusers(a)lists.iptel.org
Subject: RE: [Serusers] Location table issues
Michael,
I think your idea for a db_mode 3 is a good idea especially
considering that
I'll soon be in the same position as you with respect to ser.
On an Asterisk note you mentioned patches at
http://svn.asteriskdocs.org/res_data/. Do these patches allow
Asterisk to store
user and server configuration data in a MySQL database rather
than in .conf
files? If not, could you elaborate a bit on what these
patches fix or features
that they provide?
Best Regards,
Paul
--- Michael Shuler <mike(a)bwsys.net> wrote:
Inc. (ISP)
I figured that's what people would say :(
thanks though.
I thought of that but the problem is that it takes up to
the max time of my
longest REGISTER client timer before its back in
sync with
the one that runs
off the DB. It would be nice if there was a 3rd
option i.e.
modparam("usrloc", "db_mode", 3) that would make it read
only
at startup to
"seed" the memory database. The reason
I need this is
because I have a few
SER servers behind a Foundry ServerIron XL layer
4 switch.
When I bring the
failed server back online the Foundry
automatically
recognizes that port
5060 is alive again and immediately starts
sending it
traffic. If the RAM
based location table hasn't been fully
populated by the
time this happens
then we have a bunch of failed calls until it
syncs up
which in my case is
up to 5 min. I can get around this manually by
removing it
from the cluster
config in the Foundry but that takes away from
the
automation of the whole
thing.
Andrei/Jiri, what do you guys think of adding that as an
option? It seems
to me that it would be the most logical way to go
about
doing it and should
be very easy to do since all it is combining
parts of mode
0 and 1/2. I
have little experience doing any programming in
SER
otherwise I would just
write it and submit it as a patch. Most of my
time gets
sucked up into
Asterisk patches (see
http://svn.asteriskdocs.org/res_data/
for MySQL
dynamic config files, this is a must for
carriers... Well
at least for me :)
), but if you 2 don't have time or don't
think its worth
while then I guess
I will have find time. Please let me know what
you guys
think of this as
> soon as you get a chance.
>
> ----------------------------------------
>
> Michael Shuler, C.E.O.
> BitWise Communications, Inc. (CLEC) And BitWise Systems, 682 High
Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
> -----Original Message-----
> From: Maxim Sobolev [mailto:sobomax@portaone.com]
> Sent: Sunday, September 26, 2004 3:28 AM
> To: Michael Shuler
> Cc: serusers(a)lists.iptel.org
> Subject: Re: [Serusers] Location table issues
>
>
> Michael Shuler wrote:
>
> > Let's say I have 2 SER servers (ser1 and ser2). Both save
> to the same MySQL
> > location table and both use t_replicate to let each other
> know about new
> > REGISTER's. Lets say ser1 gets a REGISTER from a client
> and then calls
> > t_replicate to send it over to ser2 and both call
> save("location"). Doesn't
> > that cause ser1 and ser2 to write the same record at about
> the same time to
> > MySQL? Is there any way to prevent doubling the number of
> database writes?
>
> You can configure one of the ser's to do not use database
at all for
> storing contacts, which will do what you
want - contacts will
> be saved
> by the another ser, while t_replicate() will ensure that
both of them
> have a whole set at any moment of time.
>
> -Maxim
>
> >
> > Does anyone know what the replicate column is for in the
> location table?
> >
> > ----------------------------------------
> >
> > Michael Shuler, C.E.O.
> > BitWise Communications, Inc. (CLEC) And BitWise
Systems, Inc. (ISP)
> 682
High Point Lane
> East Peoria, IL 61611
> Office: (217) 585-0357
> Cell: (309) 657-6365
> Fax: (309) 213-3500
> E-Mail: mike(a)bwsys.net
> Customer Service: (877) 976-0711
>
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
11:27 p.m.
This is really great news for me! Thanks.
One more question. Do these patches let Asterisk store recorded voice mail
messages in MySQL or are they still stored under /var/spool/asterisk/voicemail?
The reason I ask is the former allows for an asterisk server to go offline and
not affect the customers ability to get their messages.
Regards,
Paul
--- Michael Shuler <mike(a)bwsys.net> wrote:
Oh yeah, one more REALLY important feature. It allows
you to have a cluster
of Asterisk servers all run off a live common config. No more having to
mess around with NFS or trying to sync config files :) Mark Spencer has
said he plans on putting this patch in Asterisk 1.1 or 1.2 but since 1.0.0
JUST came out you can bet it will be a while.
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
=== message
truncated ===
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Michael Shuler
Sent: Sunday, September 26, 2004 2:35 PM
To: 'Java Rockx'; serusers(a)lists.iptel.org
Subject: RE: [Serusers] Location table issues
Yup, that's exactly what they do. We put the full LERG in
there which is
about 350,000 routes and it doesn't even bother it thanks to
MySQL's ability
to search records lightning fast.
We also use it to provision our customers and their routing
live via some
PHP scripts which simply write to the MySQL tables
appropriately. No more
restarting or reloading Asterisk :)
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
-----Original Message-----
From: Java Rockx [mailto:javarockx@yahoo.com]
Sent: Sunday, September 26, 2004 2:21 PM
To: Michael Shuler; serusers(a)lists.iptel.org
Subject: RE: [Serusers] Location table issues
Michael,
I think your idea for a db_mode 3 is a good idea especially
considering that
I'll soon be in the same position as you with respect to ser.
On an Asterisk note you mentioned patches at
http://svn.asteriskdocs.org/res_data/. Do these patches allow
Asterisk to store
user and server configuration data in a MySQL database rather
than in .conf
files? If not, could you elaborate a bit on what these
patches fix or features
that they provide?
Best Regards,
Paul
--- Michael Shuler <mike(a)bwsys.net> wrote:
Inc. (ISP)
> > 682 High Point Lane
> > East Peoria, IL 61611
> > Office: (217) 585-0357
> > Cell: (309) 657-6365
> > Fax: (309) 213-3500
> > E-Mail: mike(a)bwsys.net
> > Customer Service: (877) 976-0711
> >
> >
> >
> > > -----Original Message-----
> > > From: Maxim Sobolev [mailto:sobomax@portaone.com]
> > > Sent: Sunday, September 26, 2004 3:28 AM
> > > To: Michael Shuler
> > > Cc: serusers(a)lists.iptel.org
> > > Subject: Re: [Serusers] Location table issues
> > >
> > >
> > > Michael Shuler wrote:
> > >
> > > > Let's say I have 2 SER servers (ser1 and ser2). Both save
> > > to the same MySQL
> > > > location table and both use t_replicate to let each other
> > > know about new
> > > > REGISTER's. Lets say ser1 gets a REGISTER from a client
> > > and then calls
> > > > t_replicate to send it over to ser2 and both call
> > > save("location"). Doesn't
> > > > that cause ser1 and ser2 to write the same record at about
> > > the same time to
> > > > MySQL? Is there any way to prevent doubling the number of
> > > database writes?
> > >
> > > You can configure one of the ser's to do not use database
> at all for
> > > storing contacts, which will do what you want - contacts will
> > > be saved
> > > by the another ser, while t_replicate() will ensure that
> both of them
> > > have a whole set at any moment of time.
> > >
> > > -Maxim
> > >
> > > >
> > > > Does anyone know what the replicate column is for in the
> > > location table?
> > > >
> > > > ----------------------------------------
> > > >
> > > > Michael Shuler, C.E.O.
> > > > BitWise Communications, Inc. (CLEC) And BitWise
> Systems, Inc. (ISP)
> > > > 682 High Point Lane
> > > > East Peoria, IL 61611
> > > > Office: (217) 585-0357
> > > > Cell: (309) 657-6365
> > > > Fax: (309) 213-3500
> > > > E-Mail: mike(a)bwsys.net
> > > > Customer Service: (877) 976-0711
> > > >
> > > > _______________________________________________
> > > > Serusers mailing list
> > > > serusers(a)lists.iptel.org
> > > > http://lists.iptel.org/mailman/listinfo/serusers
> > > >
> > > >
> > >
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers(a)lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers I figured that's what people would say :(
thanks though.
I thought of that but the problem is that it takes up to
the max time of my
longest REGISTER client timer before its back in
sync with
the one that runs
off the DB. It would be nice if there was a 3rd
option i.e.
modparam("usrloc", "db_mode", 3) that would make it read
only
at startup to
"seed" the memory database. The reason
I need this is
because I have a few
SER servers behind a Foundry ServerIron XL layer
4 switch.
When I bring the
failed server back online the Foundry
automatically
recognizes that port
5060 is alive again and immediately starts
sending it
traffic. If the RAM
based location table hasn't been fully
populated by the
time this happens
then we have a bunch of failed calls until it
syncs up
which in my case is
up to 5 min. I can get around this manually by
removing it
from the cluster
config in the Foundry but that takes away from
the
automation of the whole
thing.
Andrei/Jiri, what do you guys think of adding that as an
option? It seems
to me that it would be the most logical way to go
about
doing it and should
be very easy to do since all it is combining
parts of mode
0 and 1/2. I
have little experience doing any programming in
SER
otherwise I would just
write it and submit it as a patch. Most of my
time gets
sucked up into
Asterisk patches (see
http://svn.asteriskdocs.org/res_data/
for MySQL
dynamic config files, this is a must for
carriers... Well
at least for me :)
), but if you 2 don't have time or don't
think its worth
while then I guess
I will have find time. Please let me know what
you guys
think of this as
> soon as you get a chance.
>
> ----------------------------------------
>
> Michael Shuler, C.E.O.
> BitWise Communications, Inc. (CLEC) And BitWise Systems,
11:37 p.m.
Ahhh grasshopper, you see the master plan :)
That is about the only part that hasn't been finished yet and is what I am
working on now unless I have to stop and take care of the SER location
issue.. Hopefully one of the SER developers will take care of that so I can
finish my work on the Asterisk patches.
Actually what I am building is a system that would not only handle the VM
files but ANY audio files including music on hold, announcements, etc.
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
-----Original Message-----
From: Java Rockx [mailto:javarockx@yahoo.com]
Sent: Sunday, September 26, 2004 4:28 PM
To: Michael Shuler; serusers(a)lists.iptel.org
Subject: RE: [Serusers] Location table issues
This is really great news for me! Thanks.
One more question. Do these patches let Asterisk store
recorded voice mail
messages in MySQL or are they still stored under
/var/spool/asterisk/voicemail?
The reason I ask is the former allows for an asterisk server
to go offline and
not affect the customers ability to get their messages.
Regards,
Paul
--- Michael Shuler <mike(a)bwsys.net> wrote:
=== message
truncated ===
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Oh yeah, one more REALLY important feature. It
allows you
to have a cluster
of Asterisk servers all run off a live common
config. No
more having to
mess around with NFS or trying to sync config
files :)
Mark Spencer has
said he plans on putting this patch in Asterisk
1.1 or 1.2
but since 1.0.0
JUST came out you can bet it will be a while.
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
> -----Original Message-----
> From: serusers-bounces(a)lists.iptel.org
> [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Michael Shuler
> Sent: Sunday, September 26, 2004 2:35 PM
> To: 'Java Rockx'; serusers(a)lists.iptel.org
> Subject: RE: [Serusers] Location table issues
>
>
> Yup, that's exactly what they do. We put the full LERG in
> there which is
> about 350,000 routes and it doesn't even bother it thanks to
> MySQL's ability
> to search records lightning fast.
>
> We also use it to provision our customers and their routing
> live via some
> PHP scripts which simply write to the MySQL tables
> appropriately. No more
> restarting or reloading Asterisk :)
>
> ----------------------------------------
>
> Michael Shuler, C.E.O.
> BitWise Communications, Inc. (CLEC) And BitWise Systems,
Inc. (ISP)
> 682 High Point Lane
> East Peoria, IL 61611
> Office: (217) 585-0357
> Cell: (309) 657-6365
> Fax: (309) 213-3500
> E-Mail: mike(a)bwsys.net
> Customer Service: (877) 976-0711
>
> > -----Original Message-----
> > From: Java Rockx [mailto:javarockx@yahoo.com]
> > Sent: Sunday, September 26, 2004 2:21 PM
> > To: Michael Shuler; serusers(a)lists.iptel.org
> > Subject: RE: [Serusers] Location table issues
> >
> >
> > Michael,
> >
> > I think your idea for a db_mode 3 is a good idea especially
> > considering that
> > I'll soon be in the same position as you with respect to ser.
> >
> > On an Asterisk note you mentioned patches at
> > http://svn.asteriskdocs.org/res_data/. Do these patches allow
> > Asterisk to store
> > user and server configuration data in a MySQL database rather
> > than in .conf
> > files? If not, could you elaborate a bit on what these
> > patches fix or features
> > that they provide?
> >
> > Best Regards,
> > Paul
> >
> > --- Michael Shuler <mike(a)bwsys.net> wrote:
> >
> > > I figured that's what people would say :( thanks though.
> > >
> > > I thought of that but the problem is that it takes up to
> > the max time of my
> > > longest REGISTER client timer before its back in sync with
> > the one that runs
> > > off the DB. It would be nice if there was a 3rd option i.e.
> > > modparam("usrloc", "db_mode", 3) that would make it
read
> > only at startup to
> > > "seed" the memory database. The reason I need this is
> > because I have a few
> > > SER servers behind a Foundry ServerIron XL layer 4 switch.
> > When I bring the
> > > failed server back online the Foundry automatically
> > recognizes that port
> > > 5060 is alive again and immediately starts sending it
> > traffic. If the RAM
> > > based location table hasn't been fully populated by the
> > time this happens
> > > then we have a bunch of failed calls until it syncs up
> > which in my case is
> > > up to 5 min. I can get around this manually by removing it
> > from the cluster
> > > config in the Foundry but that takes away from the
> > automation of the whole
> > > thing.
> > >
> > > Andrei/Jiri, what do you guys think of adding that as an
> > option? It seems
> > > to me that it would be the most logical way to go about
> > doing it and should
> > > be very easy to do since all it is combining parts of mode
> > 0 and 1/2. I
> > > have little experience doing any programming in SER
> > otherwise I would just
> > > write it and submit it as a patch. Most of my time gets
> > sucked up into
> > > Asterisk patches (see http://svn.asteriskdocs.org/res_data/
> > for MySQL
> > > dynamic config files, this is a must for carriers... Well
> > at least for me :)
> > > ), but if you 2 don't have time or don't think its worth
> > while then I guess
> > > I will have find time. Please let me know what you guys
> > think of this as
> > > soon as you get a chance.
> > >
> > > ----------------------------------------
> > >
> > > Michael Shuler, C.E.O.
> > > BitWise Communications, Inc. (CLEC) And BitWise Systems,
> Inc. (ISP)
> > > 682 High Point Lane
> > > East Peoria, IL 61611
> > > Office: (217) 585-0357
> > > Cell: (309) 657-6365
> > > Fax: (309) 213-3500
> > > E-Mail: mike(a)bwsys.net
> > > Customer Service: (877) 976-0711
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Maxim Sobolev [mailto:sobomax@portaone.com]
> > > > Sent: Sunday, September 26, 2004 3:28 AM
> > > > To: Michael Shuler
> > > > Cc: serusers(a)lists.iptel.org
> > > > Subject: Re: [Serusers] Location table issues
> > > >
> > > >
> > > > Michael Shuler wrote:
> > > >
> > > > > Let's say I have 2 SER servers (ser1 and ser2).
Both save
> > > > to the same MySQL
> > > > > location table and both use t_replicate to let each other
> > > > know about new
> > > > > REGISTER's. Lets say ser1 gets a REGISTER from a client
> > > > and then calls
> > > > > t_replicate to send it over to ser2 and both call
> > > > save("location"). Doesn't
> > > > > that cause ser1 and ser2 to write the same record
at
about
> > > > the same time to
> > > > > MySQL? Is there any way to prevent doubling the
number
of
> > > > database writes?
> > > >
> > > > You can configure one of the ser's to do not use database
> > at all for
> > > > storing contacts, which will do what you want -
contacts will
> >
> be saved
> > > by the another ser, while t_replicate() will ensure that
> both of them
> > > have a whole set at any moment of time.
> > >
> > > -Maxim
> > >
> > > >
> > > > Does anyone know what the replicate column is for in the
> > > location table?
> > > >
> > > > ----------------------------------------
> > > >
> > > > Michael Shuler, C.E.O.
> > > > BitWise Communications, Inc. (CLEC) And BitWise
> Systems, Inc. (ISP)
> > > > 682 High Point Lane
> > > > East Peoria, IL 61611
> > > > Office: (217) 585-0357
> > > > Cell: (309) 657-6365
> > > > Fax: (309) 213-3500
> > > > E-Mail: mike(a)bwsys.net
> > > > Customer Service: (877) 976-0711
> > > >
> > > > _______________________________________________
> > > > Serusers mailing list
> > > > serusers(a)lists.iptel.org
> > > > http://lists.iptel.org/mailman/listinfo/serusers
> > > >
> > > >
> > >
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers(a)lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
9:39 p.m.
Actually if you want to be really cool you can also config SER to read
Asterisk's sipfriends table so they can share a common auth/user lookup
system. My setup uses several SER servers acting as load balancing
proxies/auth servers which then proxy the calls evenly across a cluster of
Asterisk servers that all read a common config from MySQL. This basically
gives you infinite scalability for both clusters. If I get some free time I
was going to post my config files up on www.voip-info.org but I have never
done Wiki editing before, but if you have then maybe we can get it up there
together.
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
-----Original Message-----
From: Java Rockx [mailto:javarockx@yahoo.com]
Sent: Sunday, September 26, 2004 2:21 PM
To: Michael Shuler; serusers(a)lists.iptel.org
Subject: RE: [Serusers] Location table issues
Michael,
I think your idea for a db_mode 3 is a good idea especially
considering that
I'll soon be in the same position as you with respect to ser.
On an Asterisk note you mentioned patches at
http://svn.asteriskdocs.org/res_data/. Do these patches allow
Asterisk to store
user and server configuration data in a MySQL database rather
than in .conf
files? If not, could you elaborate a bit on what these
patches fix or features
that they provide?
Best Regards,
Paul
--- Michael Shuler <mike(a)bwsys.net> wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
I figured that's what people would say :(
thanks though.
I thought of that but the problem is that it takes up to
the max time of my
longest REGISTER client timer before its back in
sync with
the one that runs
off the DB. It would be nice if there was a 3rd
option i.e.
modparam("usrloc", "db_mode", 3) that would make it read
only
at startup to
"seed" the memory database. The reason
I need this is
because I have a few
SER servers behind a Foundry ServerIron XL layer
4 switch.
When I bring the
failed server back online the Foundry
automatically
recognizes that port
5060 is alive again and immediately starts
sending it
traffic. If the RAM
based location table hasn't been fully
populated by the
time this happens
then we have a bunch of failed calls until it
syncs up
which in my case is
up to 5 min. I can get around this manually by
removing it
from the cluster
config in the Foundry but that takes away from
the
automation of the whole
thing.
Andrei/Jiri, what do you guys think of adding that as an
option? It seems
to me that it would be the most logical way to go
about
doing it and should
be very easy to do since all it is combining
parts of mode
0 and 1/2. I
have little experience doing any programming in
SER
otherwise I would just
write it and submit it as a patch. Most of my
time gets
sucked up into
Asterisk patches (see
http://svn.asteriskdocs.org/res_data/
for MySQL
dynamic config files, this is a must for
carriers... Well
at least for me :)
), but if you 2 don't have time or don't
think its worth
while then I guess
I will have find time. Please let me know what
you guys
think of this as
soon as you get a chance.
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
> -----Original Message-----
> From: Maxim Sobolev [mailto:sobomax@portaone.com]
> Sent: Sunday, September 26, 2004 3:28 AM
> To: Michael Shuler
> Cc: serusers(a)lists.iptel.org
> Subject: Re: [Serusers] Location table issues
>
>
> Michael Shuler wrote:
>
> > Let's say I have 2 SER servers (ser1 and ser2). Both save
> to the same MySQL
> > location table and both use t_replicate to let each other
> know about new
> > REGISTER's. Lets say ser1 gets a REGISTER from a client
> and then calls
> > t_replicate to send it over to ser2 and both call
> save("location"). Doesn't
> > that cause ser1 and ser2 to write the same record at about
> the same time to
> > MySQL? Is there any way to prevent doubling the number of
> database writes?
>
> You can configure one of the ser's to do not use database
at all for
> storing contacts, which will do what you
want - contacts will
> be saved
> by the another ser, while t_replicate() will ensure that
both of them
> have a whole set at any moment of time.
>
> -Maxim
>
> >
> > Does anyone know what the replicate column is for in the
> location table?
> >
> > ----------------------------------------
> >
> > Michael Shuler, C.E.O.
> > BitWise Communications, Inc. (CLEC) And BitWise
Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
27 Sep
27 Sep
12:53 a.m.
Michael,
I've not done any Wiki editing either but I'll do the work if you guide me
along with the technical content.
This could be a really good thing for the ser and Asterisk communities because
I suspect many people are either attempting this type of clustering now or will
need to shortly.
I know I personally need a carrier-grade solution for my needs and I'm
searching for ways to achieve the golden five-nines of availability. But even
if I didn't need 99.999% uptime, I'd still strive for it even if I was just
replacing an office PBX for a ser/Asterisk solution because of typical customer
care requirements that most companies face.
Cheers from soggy Orlando.
Paul
--- Michael Shuler <mike(a)bwsys.net> wrote:
Actually if you want to be really cool you can also
config SER to read
Asterisk's sipfriends table so they can share a common auth/user lookup
system. My setup uses several SER servers acting as load balancing
proxies/auth servers which then proxy the calls evenly across a cluster of
Asterisk servers that all read a common config from MySQL. This basically
gives you infinite scalability for both clusters. If I get some free time I
was going to post my config files up on www.voip-info.org but I have never
done Wiki editing before, but if you have then maybe we can get it up there
together.
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-----Original Message-----
From: Java Rockx [mailto:javarockx@yahoo.com]
Sent: Sunday, September 26, 2004 2:21 PM
To: Michael Shuler; serusers(a)lists.iptel.org
Subject: RE: [Serusers] Location table issues
Michael,
I think your idea for a db_mode 3 is a good idea especially
considering that
I'll soon be in the same position as you with respect to ser.
On an Asterisk note you mentioned patches at
http://svn.asteriskdocs.org/res_data/. Do these patches allow
Asterisk to store
user and server configuration data in a MySQL database rather
than in .conf
files? If not, could you elaborate a bit on what these
patches fix or features
that they provide?
Best Regards,
Paul
--- Michael Shuler <mike(a)bwsys.net> wrote:
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
I figured that's what people would say :(
thanks though.
I thought of that but the problem is that it takes up to
the max time of my
longest REGISTER client timer before its back in
sync with
the one that runs
off the DB. It would be nice if there was a 3rd
option i.e.
modparam("usrloc", "db_mode", 3) that would make it read
only
at startup to
"seed" the memory database. The reason
I need this is
because I have a few
SER servers behind a Foundry ServerIron XL layer
4 switch.
When I bring the
failed server back online the Foundry
automatically
recognizes that port
5060 is alive again and immediately starts
sending it
traffic. If the RAM
based location table hasn't been fully
populated by the
time this happens
then we have a bunch of failed calls until it
syncs up
which in my case is
up to 5 min. I can get around this manually by
removing it
from the cluster
config in the Foundry but that takes away from
the
automation of the whole
thing.
Andrei/Jiri, what do you guys think of adding that as an
option? It seems
to me that it would be the most logical way to go
about
doing it and should
be very easy to do since all it is combining
parts of mode
0 and 1/2. I
have little experience doing any programming in
SER
otherwise I would just
write it and submit it as a patch. Most of my
time gets
sucked up into
Asterisk patches (see
http://svn.asteriskdocs.org/res_data/
for MySQL
dynamic config files, this is a must for
carriers... Well
at least for me :)
), but if you 2 don't have time or don't
think its worth
while then I guess
I will have find time. Please let me know what
you guys
think of this as
soon as you get a chance.
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
> -----Original Message-----
> From: Maxim Sobolev [mailto:sobomax@portaone.com]
> Sent: Sunday, September 26, 2004 3:28 AM
> To: Michael Shuler
> Cc: serusers(a)lists.iptel.org
> Subject: Re: [Serusers] Location table issues
>
>
> Michael Shuler wrote:
>
> > Let's say I have 2 SER servers (ser1 and ser2). Both save
> to the same MySQL
> > location table and both use t_replicate to let each other
> know about new
> > REGISTER's. Lets say ser1 gets a REGISTER from a client
> and then calls
> > t_replicate to send it over to ser2 and both call
> save("location"). Doesn't
> > that cause ser1 and ser2 to write the same record at about
> the same time to
> > MySQL? Is there any way to prevent doubling the number of
> database writes?
>
> You can configure one of the ser's to do not use database
at all for
> storing contacts, which will do what you
want - contacts will
> be saved
> by the another ser, while t_replicate() will ensure that
both of them
> have a whole set at any moment of time.
>
> -Maxim
>
> >
> > Does anyone know what the replicate column is for in the
> location table?
> >
> > ----------------------------------------
> >
> > Michael Shuler, C.E.O.
> > BitWise Communications, Inc. (CLEC) And BitWise
Systems, Inc. (ISP)
> 682
High Point Lane
> East Peoria, IL 61611
> Office: (217) 585-0357
> Cell: (309) 657-6365
> Fax: (309) 213-3500
> E-Mail: mike(a)bwsys.net
> Customer Service: (877) 976-0711
>
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
26 Sep
26 Sep
10:44 p.m.
On Sep 26, 2004, at 1:56 PM, Michael Shuler wrote:
I figured that's what people would say :( thanks
though.
I thought of that but the problem is that it takes up to the max time
of my
longest REGISTER client timer before its back in sync with the one
that runs
off the DB. It would be nice if there was a 3rd option i.e.
modparam("usrloc", "db_mode", 3) that would make it read only at
startup to
"seed" the memory database. The reason I need this is because I have
a few
SER servers behind a Foundry ServerIron XL layer 4 switch. When I
bring the
failed server back online the Foundry automatically recognizes that
port
5060 is alive again and immediately starts sending it traffic. If the
RAM
based location table hasn't been fully populated by the time this
happens
then we have a bunch of failed calls until it syncs up which in my
case is
up to 5 min. I can get around this manually by removing it from the
cluster
config in the Foundry but that takes away from the automation of the
whole
thing.
I've suggested a similar idea in the past. I'd like to see the
database queried
every time a request comes in, or, any time a request comes in and the
'ram'
database doesn't have a result. That way you could run more than one
ser process on a single database instance.
-g
Andrei/Jiri, what do you guys think of adding that as an option? It
seems
to me that it would be the most logical way to go about doing it and
should
be very easy to do since all it is combining parts of mode 0 and 1/2.
I
have little experience doing any programming in SER otherwise I would
just
write it and submit it as a patch. Most of my time gets sucked up into
Asterisk patches (see http://svn.asteriskdocs.org/res_data/ for MySQL
dynamic config files, this is a must for carriers... Well at least for
me :)
), but if you 2 don't have time or don't think its worth while then I
guess
I will have find time. Please let me know what you guys think of this
as
soon as you get a chance.
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
Greg Fausak
www.AddaBrand.com
(US) 469-546-1265
-----Original Message-----
From: Maxim Sobolev [mailto:sobomax@portaone.com]
Sent: Sunday, September 26, 2004 3:28 AM
To: Michael Shuler
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Location table issues
Michael Shuler wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Let's say I have 2 SER servers (ser1 and
ser2). Both save
to the same MySQL
location table and both use t_replicate to let
each other
know about new
REGISTER's. Lets say ser1 gets a REGISTER
from a client
and then calls
t_replicate to send it over to ser2 and both call
save("location"). Doesn't
that cause ser1 and ser2 to write the same record
at about
the same time to
MySQL? Is there any way to prevent doubling the
number of
database writes?
You can configure one of the ser's to do not use database at all for
storing contacts, which will do what you want - contacts will
be saved
by the another ser, while t_replicate() will ensure that both of them
have a whole set at any moment of time.
-Maxim
Does anyone know what the replicate column is for in the
location table?
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
28 Sep
28 Sep
12:51 p.m.
On Sep 26, 2004 at 13:56, Michael Shuler <mike(a)bwsys.net> wrote:
I figured that's what people would say :( thanks
though.
I thought of that but the problem is that it takes up to the max time of my
longest REGISTER client timer before its back in sync with the one that runs
off the DB. It would be nice if there was a 3rd option i.e.
modparam("usrloc", "db_mode", 3) that would make it read only at
startup to
"seed" the memory database. The reason I need this is because I have a few
SER servers behind a Foundry ServerIron XL layer 4 switch. When I bring the
failed server back online the Foundry automatically recognizes that port
5060 is alive again and immediately starts sending it traffic. If the RAM
based location table hasn't been fully populated by the time this happens
then we have a bunch of failed calls until it syncs up which in my case is
up to 5 min. I can get around this manually by removing it from the cluster
config in the Foundry but that takes away from the automation of the whole
thing.
Andrei/Jiri, what do you guys think of adding that as an option? It seems
to me that it would be the most logical way to go about doing it and should
be very easy to do since all it is combining parts of mode 0 and 1/2.
Yes, it would be trivial to add it and I like the ideea.
Let's see what Jan has to say about it (he is usrloc and registrar
maintainer/author).
Andrei
4 Oct
4 Oct
3:03 a.m.
On 28-09 12:51, Andrei Pelinescu-Onciul wrote:
On Sep 26, 2004 at 13:56, Michael Shuler
<mike(a)bwsys.net> wrote:
I have a separate function for that called save_memory. That function
updates memory cache only, it does not update the database.
The solution then would be:
if (srcip == other_ser_ip) {
/* Replicated request, update memory only */
save_memory("location");
} else {
save("location");
};
I will commit the function into the public CVS if it is not there yet.
Please expect some delay, I am currently travelling.
Jan.
I figured that's what people would say :(
thanks though.
I thought of that but the problem is that it takes up to the max time of my
longest REGISTER client timer before its back in sync with the one that runs
off the DB. It would be nice if there was a 3rd option i.e.
modparam("usrloc", "db_mode", 3) that would make it read only at
startup to
"seed" the memory database. The reason I need this is because I have a few
SER servers behind a Foundry ServerIron XL layer 4 switch. When I bring the
failed server back online the Foundry automatically recognizes that port
5060 is alive again and immediately starts sending it traffic. If the RAM
based location table hasn't been fully populated by the time this happens
then we have a bunch of failed calls until it syncs up which in my case is
up to 5 min. I can get around this manually by removing it from the cluster
config in the Foundry but that takes away from the automation of the whole
thing.
Andrei/Jiri, what do you guys think of adding that as an option? It seems
to me that it would be the most logical way to go about doing it and should
be very easy to do since all it is combining parts of mode 0 and 1/2.
Yes, it would be trivial to add it and I like the ideea.
Let's see what Jan has to say about it (he is usrloc and registrar
maintainer/author).
7150
days inactive
7158
days old
12 comments
6 participants
participants (6)
-
Andrei Pelinescu-Onciul -
Greg Fausak -
Jan Janak -
Java Rockx -
Maxim Sobolev -
Michael Shuler