27 Jan
2011
27 Jan
'11
11:21 a.m.
Hello my friends,
I wonder if someone has done this before? i would like to implement 2
Kamailio servers with redundancy, something like the following:
SERVER_A is working as the primary sip proxy (virtual IP as the sip
signaling), if it fails, the other server (sleeping) should UP the virtual
IP and takes all the traffic....i guess there is many Linux implementations
thah can do this, but i would like to know if there is someone that has done
this before and hear some recomendations...
I've read some difficulty in the synchronisation of registrations because
Kamailio works best when it stores registrations in memory and registrations
are constantly changing - they expire and are renewed, as well as new ones
joining and old ones leaving. To make the failover solution function
seamlessly, it is necessary to synchronise the in-memory registrations
between the primary and the backup server . This can be done by forking a
copy of the registration request to the backup server, but there are some
practical problems in doing this, has anyone do something with this?
Thanks in advance!
27 Jan
27 Jan
12:46 p.m.
Am 27.01.2011 11:21, schrieb Danny Dias:
Hello my friends,
I wonder if someone has done this before? i would like to implement 2
Kamailio servers with redundancy, something like the following:
SERVER_A is working as the primary sip proxy (virtual IP as the sip
signaling), if it fails, the other server (sleeping) should UP the virtual
IP and takes all the traffic....i guess there is many Linux implementations
thah can do this, but i would like to know if there is someone that has done
this before and hear some recomendations...
I've read some difficulty in the synchronisation of registrations because
Kamailio works best when it stores registrations in memory and registrations
are constantly changing - they expire and are renewed, as well as new ones
joining and old ones leaving. To make the failover solution function
seamlessly, it is necessary to synchronise the in-memory registrations
between the primary and the backup server . This can be done by forking a
copy of the registration request to the backup server, but there are some
practical problems in doing this, has anyone do something with this?
Yes - the problem with SIP based replication is that both proxies must
be running. This is a problem as Kamailio binds to the virtual IP at
start up - thus adding the virtual IP address to the backup server does
not make Backup-Kamailio listening to the new IP address - you would
have to restart the backup Kamailio.
I think most people either have a database (which is highly-available by
itself) which is used by both proxies, or every proxy has a local
database and the synchronization is on DB level (e.g. master-slave
replication, btw: does somebody know if usrloc DB queries are suitable
for master-master replication?)
regards
klaus
1:05 p.m.
On Thursday 27 January 2011, Klaus Darilion wrote:
Am 27.01.2011 11:21, schrieb Danny Dias:
> I've read some difficulty in the synchronisation of registrations because
> Kamailio works best when it stores registrations in memory and
> registrations are constantly changing - they expire and are renewed, as
> well as new ones joining and old ones leaving. To make the failover
> solution function seamlessly, it is necessary to synchronise the
> in-memory registrations between the primary and the backup server . This
> can be done by forking a copy of the registration request to the backup
> server, but there are some practical problems in doing this, has anyone
> do something with this?
What problems are you referring to? I use this for some years now without any
problems.
Yes - the problem with SIP based replication is that
both proxies must
be running. This is a problem as Kamailio binds to the virtual IP at
start up - thus adding the virtual IP address to the backup server does
not make Backup-Kamailio listening to the new IP address - you would
have to restart the backup Kamailio.
Just bind kamailio to the HA IP on both servers and do REGISTER replication
between the two (on SIP level). Then if the IP migrates to the other server,
it will take over the rgistrar function with no loss of records. No restart
needed.
I think most people either have a database (which is
highly-available by
itself) which is used by both proxies, or every proxy has a local
database and the synchronization is on DB level (e.g. master-slave
replication, btw: does somebody know if usrloc DB queries are suitable
for master-master replication?)
Last time i tried, they are not, at least not in writeback mode. One proxy is
expiring records from the DB which the other proxy is trying to update. Maybe
DB-only mode will work, but that has some practical (performcance) problems.
--
Greetings,
Alex Hermann
3:15 p.m.
Thanks Alex...
2011/1/27 Alex Hermann <alex(a)speakup.nl>
Do you mean that both Kamailio-1 and Kamailio-2 will be as primary server?
and the clients will register in the 2 machines? and also they will bind to
the ip of the HA? sorry my friend but i do not understand very well, i'm
quite new with redundant systems, could you please explain a little?
--
Ing. Danny Dias
www.DannTEL.net
On Thursday 27 January 2011, Klaus Darilion wrote:
I checked for some problems here:
http://www.smartvox.co.uk/astfaq_ha_failover_ideas.htm
Am 27.01.2011 11:21, schrieb Danny Dias:
> I've read some difficulty in the synchronisation of registrations
because
> Kamailio works best when it stores
registrations in memory and
> registrations are constantly changing - they expire and are renewed, as
> well as new ones joining and old ones leaving. To make the failover
> solution function seamlessly, it is necessary to synchronise the
> in-memory registrations between the primary and the backup server .
This
> can be done by forking a copy of the
registration request to the backup
> server, but there are some practical problems in doing this, has anyone
> do something with this?
What problems are you referring to? I use this for some years now without
any
problems.
Yes - the
problem with SIP based replication is that both proxies must
be running. This is a problem as Kamailio binds to the virtual IP at
start up - thus adding the virtual IP address to the backup server does
not make Backup-Kamailio listening to the new IP address - you would
have to restart the backup Kamailio.
Just bind kamailio to the HA IP on both servers and do REGISTER replication
between the two (on SIP level). Then if the IP migrates to the other
server,
it will take over the rgistrar function with no loss of records. No restart
needed.
I think most people either have a database (which
is highly-available by
itself) which is used by both proxies, or every proxy has a local
database and the synchronization is on DB level (e.g. master-slave
replication, btw: does somebody know if usrloc DB queries are suitable
for master-master replication?)
Last time i tried, they are not, at least not in writeback mode. One proxy
is
expiring records from the DB which the other proxy is trying to update.
Maybe
DB-only mode will work, but that has some practical (performcance)
problems.
--
Greetings,
Alex Hermann
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3:24 p.m.
On 01/27/2011 04:15 PM, Danny Dias wrote:
Thanks Alex...
2011/1/27 Alex Hermann <alex(a)speakup.nl <mailto:alex@speakup.nl>>
On Thursday 27 January 2011, Klaus Darilion wrote:
Hello
This week, I have added the p_usrloc module to K master branch, that
allows partitioned user location service for Kamailio. This has the
benefits of redundancy, failover and load balancing to user location
service for K. Along with Henning Westerholt, we will also present some
strategies for partioned user location to the upcoming FOSDEM meeting in
Brussels.(more info here
http://www.fosdem.org/2011/schedule/event/kamailiolocationservices)
You can check the README of the module (master branch
modules_k/p_usrloc) for some strategies for partitioned user location.
Marius
Am 27.01.2011 11:21, schrieb Danny Dias:
> I've read some difficulty in the synchronisation of
registrations
because
> Kamailio works best when it stores
registrations in memory and
> registrations are constantly changing - they expire and are
renewed, as
> well as new ones joining and old ones
leaving. To make the
failover
> solution function seamlessly, it is
necessary to synchronise the
> in-memory registrations between the primary and the backup
server . This
> can be done by forking a copy of the
registration request to
the backup
> server, but there are some practical
problems in doing this,
has anyone
> do something with this?
What problems are you referring to? I use this for some years now
without any
problems.
I checked for some problems here:
http://www.smartvox.co.uk/astfaq_ha_failover_ideas.htm
Yes - the problem with SIP based replication is
that both
proxies must
be running. This is a problem as Kamailio binds
to the virtual IP at
start up - thus adding the virtual IP address to the backup
server does
not make Backup-Kamailio listening to the new IP
address - you would
have to restart the backup Kamailio.
Just bind kamailio to the HA IP on both servers and do REGISTER
replication
between the two (on SIP level). Then if the IP migrates to the
other server,
it will take over the rgistrar function with no loss of records.
No restart
needed.
Do you mean that both Kamailio-1 and Kamailio-2 will be as primary
server? and the clients will register in the 2 machines? and also they
will bind to the ip of the HA? sorry my friend but i do not understand
very well, i'm quite new with redundant systems, could you please
explain a little? I think most people either have a database (which
is
highly-available by
itself) which is used by both proxies, or every
proxy has a local
database and the synchronization is on DB level (e.g. master-slave
replication, btw: does somebody know if usrloc DB queries are
suitable
for master-master replication?)
Last time i tried, they are not, at least not in writeback mode.
One proxy is
expiring records from the DB which the other proxy is trying to
update. Maybe
DB-only mode will work, but that has some practical (performcance)
problems.
--
Greetings,
Alex Hermann
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Ing. Danny Dias
www.DannTEL.net <http://www.DannTEL.net>
3:18 p.m.
Am 27.01.2011 13:05, schrieb Alex Hermann:
Is it possible to bind Kamailio to an IP address which is not active?
(e.g. start Kamailio on the backup server)
klaus
> Yes - the
problem with SIP based replication is that both proxies must
> be running. This is a problem as Kamailio binds to the virtual IP at
> start up - thus adding the virtual IP address to the backup server does
> not make Backup-Kamailio listening to the new IP address - you would
> have to restart the backup Kamailio.
Just bind kamailio to the HA IP on both
servers and do REGISTER replication
between the two (on SIP level). Then if the IP migrates to the other server,
it will take over the rgistrar function with no loss of records. No restart
needed. 
3:19 p.m.
Try to set this option to bind to an non existing ip:
net.ipv4.ip_nonlocal_bind = 1
does work for SSH and thefore should also work with kamailio
-----Ursprüngliche Nachricht-----
Von: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org]
Im Auftrag von Klaus Darilion
Gesendet: Donnerstag, 27. Januar 2011 15:18
An: Alex Hermann
Cc: sr-users(a)lists.sip-router.org
Betreff: Re: [SR-Users] Redundancy between 2 Kamailio servers
Am 27.01.2011 13:05, schrieb Alex Hermann:
Is it possible to bind Kamailio to an IP address which is not active?
(e.g. start Kamailio on the backup server)
klaus
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> Yes - the
problem with SIP based replication is that both proxies must
> be running. This is a problem as Kamailio binds to the virtual IP at
> start up - thus adding the virtual IP address to the backup server does
> not make Backup-Kamailio listening to the new IP address - you would
> have to restart the backup Kamailio.
Just bind kamailio to the HA IP on both
servers and do REGISTER replication
between the two (on SIP level). Then if the IP migrates to the other server,
it will take over the rgistrar function with no loss of records. No restart
needed. 
7:50 p.m.
2011/1/27 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
Is it possible to bind Kamailio to an IP address which
is not active?
(e.g. start Kamailio on the backup server)
Yes, it depends on a sysctl option of the kernel (I don't remember the
name, sorry). With such option set you can make a server to listen in
a IP which doesn't exist in the server.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3:35 p.m.
Am 27.01.2011 13:05, schrieb Alex Hermann:
On Thursday 27 January 2011, Klaus Darilion wrote:
Alex, do you also do NAT keep-alive from the proxies? If yes, are you
sending them from both servers at the same time?
regards
klaus
> Am 27.01.2011 11:21, schrieb Danny Dias:
> > > I've read some difficulty in the synchronisation of registrations
because
> > > Kamailio works best when it stores registrations in memory and
> > > registrations are constantly changing - they expire and are renewed, as
> > > well as new ones joining and old ones leaving. To make the failover
> > > solution function seamlessly, it is necessary to synchronise the
> > > in-memory registrations between the primary and the backup server . This
> > > can be done by forking a copy of the registration request to the backup
> > > server, but there are some practical problems in doing this, has anyone
> > > do something with this?
What problems are you referring to? I use
this for some years now without any
problems.
4:03 p.m.
On Thursday 27 January 2011, Klaus Darilion wrote:
Alex, do you also do NAT keep-alive from the proxies?
If yes, are you
sending them from both servers at the same time?
No, we require clients to sent nat-keepalives. It is much more efficient. In
addition, the registrars are not directly accessible by clients, they go via
load-balancers. Clients keep the NAT binding with the balancer, not the
registrar.
--
Greetings,
Alex Hermann
5:18 p.m.
Do you mean that both Kamailio-1 and Kamailio-2 will be as primary server?
and the clients will register in the 2 machines? and also they will bind to
the ip of the HA? sorry my friend but i do not understand very well, i'm
quite new with redundant systems, could you please explain a little please?
2011/1/27 Alex Hermann <alex(a)speakup.nl>
On Thursday 27 January 2011, Klaus Darilion wrote:
Alex, do you also do NAT keep-alive from the
proxies? If yes, are you
sending them from both servers at the same time?
No, we require clients to sent nat-keepalives. It is much more efficient.
In
addition, the registrars are not directly accessible by clients, they go
via
load-balancers. Clients keep the NAT binding with the balancer, not the
registrar.
--
Greetings,
Alex Hermann
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
6:17 p.m.
On Thursday 27 January 2011 17:18:22 Danny Dias wrote:
Do you mean that both Kamailio-1 and Kamailio-2 will
be as primary server?
and the clients will register in the 2 machines? and also they will bind to
the ip of the HA? sorry my friend but i do not understand very well, i'm
quite new with redundant systems, could you please explain a little please?
Clients will register to the HA ip. The registrars are bound to the HA ip and
to another IP on which the REGISTERs will be replicated between the
registrars. Outbound request are forced through the right socket to the HA ip
so they follow the NAT binding of the client.
--
Alex Hermann
7:55 p.m.
2011/1/27 Danny Dias <ing.diasdanny(a)gmail.com>om>:
Do you mean that both Kamailio-1 and Kamailio-2 will
be as primary server?
and the clients will register in the 2 machines? and also they will bind to
the ip of the HA? sorry my friend but i do not understand very well, i'm
quite new with redundant systems, could you please explain a little please?
Two Kamailios in a HeartBeat cluster which manages the kamailio
service along with a virtual IP in which kamailios are supposed to
listen. Just one kamailio is running (HA manages them).
Regsitration can be done in a shared database with db_mode=3 (or 2) so
no locations are lost when HA stops the running instance of kamailio
(or the server is down) and starts kamailio in the other cluster node.
Another option without using realtime DB storage is replicating the
REGISTER from one Kamailio to the other (t_replicate method) but it
requires both kamailios being running at the same time (so
net.ipv4.ip_nonlocal_bind must be 1) and kamailios must NOT be managed
by HA. Also it requires some other considerations.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
10:25 p.m.
Thanks Iñaki,
2011/1/27 Iñaki Baz Castillo <ibc(a)aliax.net>
2011/1/27 Danny Dias <ing.diasdanny(a)gmail.com>om>:
So, the heartbeat cluster shall manage that both are ok and also check that
the virtual ip and the kamailio service in the primary server is OK....if
something fails it will activate the virtual IP address and the kamailio
process in the other server? so this heartbeat cluster is installed in both
kamailio servers?
which HA software do you recommend?
Do you mean that both Kamailio-1 and Kamailio-2
will be as primary
server?
and the clients will register in the 2 machines?
and also they will bind
to
the ip of the HA? sorry my friend but i do not
understand very well, i'm
quite new with redundant systems, could you please explain a little
please?
Two Kamailios in a HeartBeat cluster which manages the kamailio
service along with a virtual IP in which kamailios are supposed to
listen. Just one kamailio is running (HA manages them).
Regsitration can be done in a shared database with
db_mode=3 (or 2) so
no locations are lost when HA stops the running instance of kamailio
(or the server is down) and starts kamailio in the other cluster node.
So, the database of the kamailios should be dedicated and externalised
server?
Another option without using realtime DB storage is
replicating the
REGISTER from one Kamailio to the other (t_replicate method) but it
requires both kamailios being running at the same time (so
net.ipv4.ip_nonlocal_bind must be 1) and kamailios must NOT be managed
by HA. Also it requires some other considerations.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
--
Ing. Danny Dias
www.DannTEL.net
11:17 p.m.
2011/1/27 Danny Dias <ing.diasdanny(a)gmail.com>om>:
As I said at the top of my previous mail: HeartBeat (as it is the only
I'm used to).
Could be, or not. It doesn't matter too much.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Two Kamailios
in a HeartBeat cluster which manages the kamailio
service along with a virtual IP in which kamailios are supposed to
listen. Just one kamailio is running (HA manages them).
So, the heartbeat cluster shall manage that both are ok and also check that
the virtual ip and the kamailio service in the primary server is OK....if
something fails it will activate the virtual IP address and the kamailio
process in the other server? so this heartbeat cluster is installed in both
kamailio servers?
which HA software do you recommend? Regsitration
can be done in a shared database with db_mode=3 (or 2) so
no locations are lost when HA stops the running instance of kamailio
(or the server is down) and starts kamailio in the other cluster node.
So, the database of the kamailios should be dedicated and externalised
server?
2 Feb
2 Feb
11:20 a.m.
Hello,
I was thinking that if i store the contacts that are registered into my
proxy in a database, like this:
.
.
# ----- usrloc params -----
modparam("usrloc", "db_mode", 3)
.
.
if (is_method("REGISTER"))
{
if (!save("location"))
sl_reply_error();
exit;
}
.
.
This way i would store the contacts in table "location", and then i could
make a backup of the DB and restore on the other server...is that ok? or i'm
missing something?
Thanks in advance for your help!
2011/1/27 Iñaki Baz Castillo <ibc(a)aliax.net>
2011/1/27 Danny Dias <ing.diasdanny(a)gmail.com>om>:
that
Could be, or not. It doesn't matter too much.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Two
Kamailios in a HeartBeat cluster which manages the kamailio
service along with a virtual IP in which kamailios are supposed to
listen. Just one kamailio is running (HA manages them).
So, the heartbeat cluster shall manage that both are ok and also check the virtual ip and the kamailio service in the
primary server is OK....if
something fails it will activate the virtual IP address and the kamailio
process in the other server? so this heartbeat cluster is installed in
both
kamailio servers?
which HA software do you recommend?
As I said at the top of my previous mail: HeartBeat (as it is the only
I'm used to).
Regsitration can be done in a shared database with db_mode=3 (or 2) so
no locations are lost when HA stops the running instance of kamailio
(or the server is down) and starts kamailio in the other cluster node.
So, the database of the kamailios should be dedicated and externalised
server?
11:21 a.m.
Would be possible.
Have a look at DRBD!
Von: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org]
Im Auftrag von Danny Dias
Gesendet: Mittwoch, 2. Februar 2011 11:20
An: kamailio
Betreff: Re: [SR-Users] Redundancy between 2 Kamailio servers
Hello,
I was thinking that if i store the contacts that are registered into my proxy in a
database, like this:
.
.
# ----- usrloc params -----
modparam("usrloc", "db_mode", 3)
.
.
if (is_method("REGISTER"))
{
if (!save("location"))
sl_reply_error();
exit;
}
.
.
This way i would store the contacts in table "location", and then i could make a
backup of the DB and restore on the other server...is that ok? or i'm missing
something?
Thanks in advance for your help!
2011/1/27 Iñaki Baz Castillo <ibc(a)aliax.net>
2011/1/27 Danny Dias <ing.diasdanny(a)gmail.com>om>:
As I said at the top of my previous mail:
HeartBeat (as it is the only
I'm used to).
Could be, or not. It doesn't matter too much.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Two Kamailios
in a HeartBeat cluster which manages the kamailio
service along with a virtual IP in which kamailios are supposed to
listen. Just one kamailio is running (HA manages them).
So, the heartbeat cluster shall manage that both are ok and also check that
the virtual ip and the kamailio service in the primary server is OK....if
something fails it will activate the virtual IP address and the kamailio
process in the other server? so this heartbeat cluster is installed in both
kamailio servers?
which HA software do you recommend? Regsitration
can be done in a shared database with db_mode=3 (or 2) so
no locations are lost when HA stops the running instance of kamailio
(or the server is down) and starts kamailio in the other cluster node.
So, the database of the kamailios should be dedicated and externalised
server?
11:24 a.m.
On 02/02/2011 12:20 PM, Danny Dias wrote:
Hello,
I was thinking that if i store the contacts that are registered into
my proxy in a database, like this:
.
.
# ----- usrloc params -----
modparam("usrloc", "db_mode", 3)
.
.
if (is_method("REGISTER"))
{
if (!save("location"))
sl_reply_error();
exit;
}
.
.
This way i would store the contacts in table "location", and then i
could make a backup of the DB and restore on the other server...is
that ok? or i'm missing something?
Or you can use the p_usrloc module that does automatically the db
replication and failover + data partitioning (or you can combine them to
suite your needs). New in master branch (</shameless advertisement>)
But seriously, we might want to give it a try. The config syntax remains
the same as above you just need to load p_usrloc instead of usrloc and
setup the databases.
Marius
Thanks in advance for your help!
2011/1/27 Iñaki Baz Castillo <ibc(a)aliax.net <mailto:ibc@aliax.net>>
2011/1/27 Danny Dias <ing.diasdanny(a)gmail.com
<mailto:ing.diasdanny@gmail.com>>:
check that
So, the database of the kamailios should be dedicated and externalised
Two
Kamailios in a HeartBeat cluster which manages the kamailio
service along with a virtual IP in which kamailios are supposed to
listen. Just one kamailio is running (HA manages them).
So, the heartbeat cluster shall manage that both are ok and also the virtual ip and the kamailio service in the
primary server is
OK....if
something fails it will activate the virtual IP
address and the
kamailio
process in the other server? so this heartbeat
cluster is
installed in both
kamailio servers?
which HA software do you recommend?
As I said at the top of my previous mail: HeartBeat (as it is the only
I'm used to).
> Regsitration can be done in a shared database
with db_mode=3
(or 2) so
> no locations are lost when HA stops the
running instance of
kamailio
> (or the server is down) and starts kamailio
in the other
cluster node.
server?
Could be, or not. It doesn't matter too much.
--
Iñaki Baz Castillo
<ibc(a)aliax.net <mailto:ibc@aliax.net>>
2:09 p.m.
Am 27.01.2011 13:05, schrieb Alex Hermann:
On Thursday 27 January 2011, Klaus Darilion wrote:
Alex, what happens if one server is down. There will be lots of
"replication transactions" which will timeout. Can this cause any
problems if there are too many open transactions (retransmissions ...)?
btw: I just found in tm readme:
* t_replicate should be done more cleanly--Vias, Routes, etc.
should be removed from a message prior to replicating it (well,
does not matter any longer so much as there is a new replication
module).
Is there really a dedicated replication module somewhere?
klaus
Am 27.01.2011 11:21, schrieb Danny Dias:
> I've read some difficulty in the synchronisation of registrations because
> Kamailio works best when it stores registrations in memory and
> registrations are constantly changing - they expire and are renewed, as
> well as new ones joining and old ones leaving. To make the failover
> solution function seamlessly, it is necessary to synchronise the
> in-memory registrations between the primary and the backup server . This
> can be done by forking a copy of the registration request to the backup
> server, but there are some practical problems in doing this, has anyone
> do something with this?
What problems are you referring to? I use this for some years now without any
problems.
3:24 p.m.
On Wednesday 02 February 2011, you wrote:
Am 27.01.2011 13:05, schrieb Alex Hermann:
I just forward() them.
On Thursday 27 January 2011, Klaus Darilion
wrote:
Alex, what happens if one server is down. There will be lots of
"replication transactions" which will timeout. Can this cause any
problems if there are too many open transactions (retransmissions ...)? Am 27.01.2011 11:21, schrieb Danny Dias:
> I've read some difficulty in the synchronisation of registrations
> because Kamailio works best when it stores registrations in memory
> and registrations are constantly changing - they expire and are
> renewed, as well as new ones joining and old ones leaving. To make
> the failover solution function seamlessly, it is necessary to
> synchronise the in-memory registrations between the primary and the
> backup server . This can be done by forking a copy of the
> registration request to the backup server, but there are some
> practical problems in doing this, has anyone do something with this?
What problems are you referring to? I use this for some years now
without any problems. btw: I just found in tm readme:
* t_replicate should be done more cleanly--Vias, Routes, etc.
should be removed from a message prior to replicating it (well,
does not matter any longer so much as there is a new replication
module).
Is there really a dedicated replication module somewhere?
Never seen one.
--
Alex Hermann
3:38 p.m.
Am 02.02.2011 15:24, schrieb Alex Hermann:
On Wednesday 02 February 2011, you wrote:
Interesting.
So, do you have some logic to drop the response from the "backup"
registrar? Or will the client receive 2 responses? Or will the "backup"
server not response at all?
I guess the last option would be the simplest one...
regards
klaus
Am 27.01.2011 13:05, schrieb Alex Hermann:
I just forward() them. On Thursday 27 January 2011, Klaus Darilion
wrote:
Alex, what happens if one server is down. There will be lots of
"replication transactions" which will timeout. Can this cause any
problems if there are too many open transactions (retransmissions ...)? Am 27.01.2011 11:21, schrieb Danny Dias:
> I've read some difficulty in the synchronisation of registrations
> because Kamailio works best when it stores registrations in memory
> and registrations are constantly changing - they expire and are
> renewed, as well as new ones joining and old ones leaving. To make
> the failover solution function seamlessly, it is necessary to
> synchronise the in-memory registrations between the primary and the
> backup server . This can be done by forking a copy of the
> registration request to the backup server, but there are some
> practical problems in doing this, has anyone do something with this?
What problems are you referring to? I use this for some years now
without any problems.
4:52 p.m.
On Wednesday 02 February 2011, Klaus Darilion wrote:
Am 02.02.2011 15:24, schrieb Alex Hermann:
The "backup" server does not respond at all. The first does all the
authentication and verification, the backup just stores it in usrloc.
--
Alex Hermann
On Wednesday 02 February 2011, you wrote:
Interesting.
So, do you have some logic to drop the response from the "backup"
registrar? Or will the client receive 2 responses? Or will the "backup"
server not response at all?
I guess the last option would be the simplest one... Alex, what happens if one server is down. There
will be lots of
"replication transactions" which will timeout. Can this cause any
problems if there are too many open transactions (retransmissions
...)?
I just forward() them.
4840
days inactive
4846
days old
21 comments
6 participants
participants (6)
-
Alex Hermann -
Bernhard Suttner -
Danny Dias -
Iñaki Baz Castillo -
Klaus Darilion -
marius zbihlei