26 Feb
2004
26 Feb
'04
4:28 a.m.
Hello,
ive got a couple of question of the t_replicate feature of the tm module.
First, ive found the follwing note in modules/tm/README (8.0.12 CVS stable):
----
* 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).
----
Can someone comment on what may be the consequences of using
t_replicate which is "not done so cleanly" and where i may
get a copy of this "new replication" module? If its under open source
licence, that is.
Next question :) Is there any way that a failover server pickups the
neccessary port bindings for portaones rtpproxy or do will all
"rtpproxied" sessions fail when a failover server will take over
a primary server?
best regards,
Arnd
26 Feb
26 Feb
5:34 a.m.
On Thursday 26 February 2004 03:28, Arnd Vehling wrote:
Hello,
ive got a couple of question of the t_replicate feature of the tm module.
First, ive found the follwing note in modules/tm/README (8.0.12 CVS
stable): ----
* 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).
----
Can someone comment on what may be the consequences of using
t_replicate which is "not done so cleanly" and where i may
get a copy of this "new replication" module? If its under open source
licence, that is.
The new replication module is only available under commercial license. And as
you guess it is implemented much more cleaner ;) and more reliable.
t_replicate just forwards the request to another destination and consumes the
answer. And this dirty in many ways, but works for some simple scenarios.
Next question :) Is there any way that a failover
server pickups the
neccessary port bindings for portaones rtpproxy or do will all
"rtpproxied" sessions fail when a failover server will take over
a primary server?
As currently the rtp-proxy has to run on the same host as SER it does not make
much sence IMHO to think about taking over rtp-proxy sessions. Then you would
need some kind of rtp-proxy session replication, which should be easy when
the nathelper module and the rtp proxy ever uses IP protocol for
communication. But all this will only work if the backup server takes over
the IP of the failed server, and you are not using SRV backup servers for
example (except that a SRV backup can obviously also can takeover the IP).
Sounds like a nice and long-term HA project. But as RTP-proxying is (normaly)
only a fix for to many or broken NATs i think it would be a doubtfull
project.
Greetings
NO
7:28 a.m.
Hi,
Nils Ohlmeier wrote:
The new module is only available under commercial
license. And as
you guess it is implemented much more cleaner ;) and more reliable.
Guessed that ;)
t_replicate just forwards the request to another
destination and consumes the
answer. And this dirty in many ways, but works for some simple scenarios.
Mhh, i dont get that. It does only replicate the subscription, right?
Call transactions are not synced, right?
As currently the rtp-proxy has to run on the same host
as SER it does not make
much sence IMHO to think about taking over rtp-proxy sessions. Then you would
need some kind of rtp-proxy session replication,
that was what i was thinking about.
which should be easy when
the nathelper module and the rtp proxy ever uses IP protocol for
communication. But all this will only work if the backup server takes over
the IP of the failed server, and you are not using SRV backup servers for
example (except that a SRV backup can obviously also can takeover the IP).
Thats the case. I am working on a simple setup using linux-ha with
heartbeat, ip failover and native mysql db synchronisation.
Sounds like a nice and long-term HA project.
I dont hope so :) Actually ive never had any serious HW failures
on one of "my" 24/7 systems i managed over the years. Therefore i think
a simple linux HA solution should work well as long as youre not going
for "carrier class" services in terms of reliably and CPS.
But as RTP-proxying is (normaly)
only a fix for to many or broken NATs i think it would be a doubtfull
project.
Youre probaly right about that. IMO NAT traversal will not be a problem
anymore with the new devices like the new grandstream and motorola
routers with integrated SIP support and other forms of enhanced NAT
devices. Although it will take a while until all of those old nat
devices will cease to exist.
thanx,
Arnd
8:09 a.m.
On Thursday 26 February 2004 06:28, Arnd Vehling wrote:
Hopefully you are aware that db synchronisation currently does not work with
the user location db, because it is cached it memory.
Excatly. So why do you care about this (hopefully) few people who are talking
over your RTP proxy during your primary server fails (and this means hardware
failure, because if the SIP proxy fails, the RTP proxy should still run),
which probably will happen rarely?
It always a trade-off: calculate how many calls you really have to make over
your RTP-proxy (depends on your users behind NAT and how many calls will be
made) and multiply it with the probability that your server hardware will
fail. And then compare this number to the effort to build a HA-RTP-proxy
(which does not mean that your SIP proxy should be HA). I think nearly all
people will come to the conclusion that it is not worth the effort.
Greetings
NO
Nils Ohlmeier wrote:
The transaction state is not synched. t_replicate simply takes the request
inserts the Via of the proxy and then sends this request copy to one single
destination. This happens statefull (the request will be retransmitted until
answer or timeout happen), but any reply will be comsumed by t_replicate and
not send downstream.
t_replicate just forwards the request to another
destination and consumes
the answer. And this dirty in many ways, but works for some simple
scenarios.
Mhh, i dont get that. It does only replicate the subscription, right?
Call transactions are not synced, right? which should
be easy when
the nathelper module and the rtp proxy ever uses IP protocol for
communication. But all this will only work if the backup server takes
over the IP of the failed server, and you are not using SRV backup
servers for example (except that a SRV backup can obviously also can
takeover the IP).
Thats the case. I am working on a simple setup using linux-ha with
heartbeat, ip failover and native mysql db synchronisation. Sounds like a
nice and long-term HA project.
I dont hope so :) Actually ive never had any serious HW failures
on one of "my" 24/7 systems i managed over the years. Therefore i think
a simple linux HA solution should work well as long as youre not going
for "carrier class" services in terms of reliably and CPS. But as
RTP-proxying is (normaly)
only a fix for to many or broken NATs i think it would be a doubtfull
project.
Youre probaly right about that. IMO NAT traversal will not be a problem
anymore with the new devices like the new grandstream and motorola
routers with integrated SIP support and other forms of enhanced NAT
devices. Although it will take a while until all of those old nat
devices will cease to exist.
10:02 p.m.
Nils Ohlmeier wrote:
? I did set "usrloc" "db_mode" 1. So the usr locations should get
committet imediatly. (Performance Issue, I know..)
Thats the case.
I am working on a simple setup using linux-ha with
heartbeat, ip failover and native mysql db synchronisation.
Hopefully you are aware that db synchronisation currently does not work with
the user location db, because it is cached it memory. It always a trade-off: calculate how remany calls you
really have to make over
your RTP-proxy (depends on your users behind NAT and how many calls will be
made) and multiply it with the probability that your server hardware will
fail. And then compare this number to the effort to build a HA-RTP-proxy
(which does not mean that your SIP proxy should be HA). I think nearly all
people will come to the conclusion that it is not worth the effort.
Yupp, youre right about that.
best regards,
Arnd
10:56 p.m.
On Thursday 26 February 2004 21:02, Arnd Vehling wrote:
Nils Ohlmeier wrote:
? I did set "usrloc" "db_mode" 1. So the usr locations should get
committet imediatly. (Performance Issue, I know..)
Yes, comitted. But the replicated data will not be read in by the backup
server. Mode=1 only means that the server writes it immediately to the
database. But there is currently no mode available in which contact data is
read from the database for every lookup. The lookup table will be read in on
startup, but not updated from the DB. So you have to reastart SER on the
backup server after the failover happened.
NO
Thats the
case. I am working on a simple setup using linux-ha with
heartbeat, ip failover and native mysql db synchronisation.
Hopefully you are aware that db synchronisation currently does not work
with the user location db, because it is cached it memory.
11:40 p.m.
Nils Ohlmeier wrote:
Yes, comitted. But the replicated data will not be
read in by the backup
server.
Mhh, seems like i didnt really understood what t_replicate does.
I thought "t_replicate" will replicate all invites to a failover box
so the primary and secondary are synced in terms of subscribed
users?!
So, if the primary box fails it the secondary should will have an (maybe
minus ore or two records) identical database and an identical subscriber
base?!
Mode=1 only means that the server writes it
immediately to the
database. But there is currently no mode available in which contact data is
read from the database for every lookup.
I thought t_replicate will do this. But if not i either restart ser as
suggested or patch it so it will re-read the subsriber table if i send
it a SIGHUP or a something via the fifo.
best regards,
Arnd
11:59 p.m.
On Thursday 26 February 2004 22:40, Arnd Vehling wrote:
Nils Ohlmeier wrote:
INVITE and subscriber table???
You can for example call for every valid REGISTER request t_replicate. If the
destination box is up and running it will then update its databases (in
memory and the DB backend, so beware of additional DB replication). But if
the secondary is down (e.g. for maintenance) it will miss the update.
Yes, comitted. But the replicated data will not
be read in by the backup
server.
Mhh, seems like i didnt really understood what t_replicate does.
I thought "t_replicate" will replicate all invites to a failover box
so the primary and secondary are synced in terms of subscribed
users?! So, if the primary box fails it the secondary should
will have an (maybe
minus ore or two records) identical database and an identical subscriber
base?!
Two choices:
- either use DB replication and restart SER on failover to re-readin the
location table on startup
- t_replicate all successfull REGISTER and omit DB replication, but beware of
the possible drawbacks.
NO
Mode=1 only means that the server writes it
immediately to the
database. But there is currently no mode available in which contact data
is read from the database for every lookup.
I thought t_replicate will do this. But if not i either restart ser as
suggested or patch it so it will re-read the subsriber table if i send
it a SIGHUP or a something via the fifo.
27 Feb
27 Feb
12:22 a.m.
Nils Ohlmeier wrote:
How about i selectivly replicate the tables or configure the backup to
use different tables for the subscriber data?
I will setup a test system for this, make some experiments and read
docu and source.
-- Arnd
On Thursday 26 February 2004 22:40, Arnd Vehling
wrote:
ARGH, NO :) I ment the "register" message.
Nils Ohlmeier wrote:
INVITE and subscriber table??? Yes, comitted. But the replicated data will not be
read in by the backup
server.
Mhh, seems like i didnt really understood what t_replicate does.
I thought "t_replicate" will replicate all invites to a failover box
so the primary and secondary are synced in terms of subscribed
users?! I thought
t_replicate will do this. But if not i either restart ser as
suggested or patch it so it will re-read the subsriber table if i send
it a SIGHUP or a something via the fifo.
Two choices:
- either use DB replication and restart SER on failover to re-readin the
location table on startup
- t_replicate all successfull REGISTER and omit DB replication, but beware of
the possible drawbacks.
12:40 a.m.
On Thursday 26 February 2004 23:22, Arnd Vehling wrote:
Nils Ohlmeier wrote:
Selective DB replication combined with t_replicate is possible.
NO
Two choices:
- either use DB replication and restart SER on failover to re-readin the
location table on startup
- t_replicate all successfull REGISTER and omit DB replication, but
beware of the possible drawbacks.
How about i selectivly replicate the tables or configure the backup to
use different tables for the subscriber data? 
midnight
It all depends on the setup of the database at the back. If you have 2
mysql server, one for each ser, than you would like to automatically
synchronize the "statical tables" (subscriber, acc, aliases...) between
the 2 mysql servers, but not the user location table, as this is done by
the ser proxies and t_replicate.
Klaus
Arnd Vehling wrote:
Nils Ohlmeier wrote:
Yes, comitted. But the replicated data will not
be read in by the
backup server.
Mhh, seems like i didnt really understood what t_replicate does.
I thought "t_replicate" will replicate all invites to a failover box
so the primary and secondary are synced in terms of subscribed
users?!
So, if the primary box fails it the secondary should will have an (maybe
minus ore or two records) identical database and an identical subscriber
base?!
Mode=1 only means that the server writes it
immediately to the
database. But there is currently no mode available in which contact
data is read from the database for every lookup.
I thought t_replicate will do this. But if not i either restart ser as
suggested or patch it so it will re-read the subsriber table if i send
it a SIGHUP or a something via the fifo.
best regards,
Arnd
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
12:06 a.m.
Klaus Darilion wrote:
It all depends on the setup of the database at the
back. If you have 2
mysql server, one for each ser, than you would like to automatically
synchronize the "statical tables" (subscriber, acc, aliases...) between
the 2 mysql servers, but not the user location table, as this is done by
the ser proxies and t_replicate.
Ok, AFAIK it shouldnt be a problem to selectivly mirror tables. Ill be
testing this and will report back to the list. This may be end of next
week though.
-- Arnd
3:17 a.m.
----- Original Message -----
From: "Klaus Darilion" <klaus.mailinglists(a)pernau.at>
To: "Arnd Vehling" <av(a)nethead.de>
Cc: "Nils Ohlmeier" <nils(a)iptel.org>rg>; <serusers(a)lists.iptel.org>
Sent: Thursday, February 26, 2004 5:00 PM
Subject: Re: [Serusers] replication and rtpproxy
It all depends on the setup of the database at the
back. If you have 2
mysql server, one for each ser, than you would like to automatically
synchronize the "statical tables" (subscriber, acc, aliases...) between
the 2 mysql servers, but not the user location table, as this is done by
the ser proxies and t_replicate.
Exactly...This is what we do.
Klaus
Arnd Vehling wrote:
Nils Ohlmeier wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Yes, comitted. But the replicated data will not
be read in by the
backup server.
Mhh, seems like i didnt really understood what t_replicate does.
I thought "t_replicate" will replicate all invites to a failover box
so the primary and secondary are synced in terms of subscribed
users?!
So, if the primary box fails it the secondary should will have an (maybe
minus ore or two records) identical database and an identical subscriber
base?!
Mode=1 only means that the server writes it
immediately to the
database. But there is currently no mode available in which contact
data is read from the database for every lookup.
I thought t_replicate will do this. But if not i either restart ser as
suggested or patch it so it will re-read the subsriber table if i send
it a SIGHUP or a something via the fifo.
best regards,
Arnd
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
26 Feb
26 Feb
11 p.m.
Hi Arnd!
Thats the case. I am working on a simple setup using linux-ha with
heartbeat, ip failover and native mysql db synchronisation.
Have you success in using heartbeat? I also tried it some time ago but I
often had problems and needless failovers during cron jobs and other
(undetected) situations.
regards,
Klaus
4:59 p.m.
Nils Ohlmeier wrote:
On Thursday 26 February 2004 03:28, Arnd Vehling
wrote:
Is it yet possible to build redundancy on top of SRV? I tested some
clients (Xlite, Budgetone-100, Windows Messenger 4.7) wether they use
SRV records to locate the proxy and Messenger is the only one who uses it.
So, if I use these clients, is there any other failover solution than IP
takeover?
regards,
klaus
Next question :) Is there any way that a failover
server pickups the
neccessary port bindings for portaones rtpproxy or do will all
"rtpproxied" sessions fail when a failover server will take over
a primary server?
As currently the rtp-proxy has to run on the same host as SER it does not make
much sence IMHO to think about taking over rtp-proxy sessions. Then you would
need some kind of rtp-proxy session replication, which should be easy when
the nathelper module and the rtp proxy ever uses IP protocol for
communication. But all this will only work if the backup server takes over
the IP of the failed server, and you are not using SRV backup servers for
example (except that a SRV backup can obviously also can takeover the IP).
7:14 p.m.
Hi Klaus,
We use DNS updates. We have special scripts based on sipsak (Thanks Nils!),
that check all SIP servers every minute. If something is wrong, then we
update our DNS dynamically to point to another SIP Server. If the UAs are
unable to register then they redo their DNS query and find the new IP.
Works quite well in combination with replication since the backup server has
the exact duplicate location table.
Regards,
Andres
----- Original Message -----
From: "Klaus Darilion" <klaus.mailinglists(a)pernau.at>
To: "Nils Ohlmeier" <nils(a)iptel.org>
Cc: <serusers(a)lists.iptel.org>
Sent: Thursday, February 26, 2004 9:59 AM
Subject: Re: [Serusers] replication and rtpproxy
Nils Ohlmeier wrote:
> On Thursday 26 February 2004 03:28, Arnd Vehling wrote:
>>Next question :) Is there any way that a failover server pickups the
>>neccessary port bindings for portaones rtpproxy or do will all
>>"rtpproxied" sessions fail when a failover server will take over
>>a primary server?
>
>
> As currently the rtp-proxy has to run on the same host as SER it does
not
make
> much sence IMHO to think about taking over
rtp-proxy sessions. Then you
would
> need some kind of rtp-proxy session replication,
which should be easy
when
> the nathelper module and the rtp proxy ever uses
IP protocol for
> communication. But all this will only work if the backup server takes
over
> the IP of the failed server, and you are not
using SRV backup servers
for
> example (except that a SRV backup can obviously
also can takeover the
IP).
Is it yet possible to build redundancy on top of SRV? I tested some
clients (Xlite, Budgetone-100, Windows Messenger 4.7) wether they use
SRV records to locate the proxy and Messenger is the only one who uses it.
So, if I use these clients, is there any other failover solution than IP
takeover?
regards,
klaus
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7:54 p.m.
But this will work only if the client uses your DNS servers, because the
DNS entries are cached by the other nameservers - or do you have a very
short TTL configured?
I think also softclients will have problems as Windows XP by default
caches the DNS lookups.
regards,
klaus
Andres wrote:
Hi Klaus,
We use DNS updates. We have special scripts based on sipsak (Thanks Nils!),
that check all SIP servers every minute. If something is wrong, then we
update our DNS dynamically to point to another SIP Server. If the UAs are
unable to register then they redo their DNS query and find the new IP.
Works quite well in combination with replication since the backup server has
the exact duplicate location table.
Regards,
Andres
----- Original Message -----
From: "Klaus Darilion" <klaus.mailinglists(a)pernau.at>
To: "Nils Ohlmeier" <nils(a)iptel.org>
Cc: <serusers(a)lists.iptel.org>
Sent: Thursday, February 26, 2004 9:59 AM
Subject: Re: [Serusers] replication and rtpproxy
Nils Ohlmeier wrote:
>On Thursday 26 February 2004 03:28, Arnd Vehling wrote:
>
>>Next question :) Is there any way that a failover server pickups the
>>neccessary port bindings for portaones rtpproxy or do will all
>>"rtpproxied" sessions fail when a failover server will take over
>>a primary server?
>
>
>As currently the rtp-proxy has to run on the same host as SER it does
not make
>much sence IMHO to think about taking over
rtp-proxy sessions. Then you
would
>need some kind of rtp-proxy session
replication, which should be easy
when
>the nathelper module and the rtp proxy ever
uses IP protocol for
>communication. But all this will only work if the backup server takes
over
>the IP of the failed server, and you are not
using SRV backup servers
for
>example (except that a SRV backup can
obviously also can takeover the
IP).
Is it yet possible to build redundancy on top of
SRV? I tested some
clients (Xlite, Budgetone-100, Windows Messenger 4.7) wether they use
SRV records to locate the proxy and Messenger is the only one who uses it.
So, if I use these clients, is there any other failover solution than IP
takeover?
regards,
klaus
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
8:19 p.m.
At 06:54 PM 2/26/2004, Klaus Darilion wrote:
But this will work only if the client uses your DNS
servers, because the DNS entries are cached by the other nameservers - or do you have a
very short TTL configured?
I think also softclients will have problems as Windows XP by default caches the DNS
lookups.
I fear too that not every client is fine with it -- I guess quite many
feature the shortcoming of resolving registar address only on reboot :(
Hopefuly, this will change (maybe its changing already, we haven't
retested it for a while.)
-jiri
8:34 p.m.
I just tried Budgetone100: no DNS lookups before a call.
So, I think there is no other way than IP takeover with such phones.
regards,
Klaus
Jiri Kuthan wrote:
At 06:54 PM 2/26/2004, Klaus Darilion wrote:
But this will work only if the client uses your
DNS servers, because the DNS entries are cached by the other nameservers - or do you have
a very short TTL configured?
I think also softclients will have problems as Windows XP by default caches the DNS
lookups.
I fear too that not every client is fine with it -- I guess quite many
feature the shortcoming of resolving registar address only on reboot :(
Hopefuly, this will change (maybe its changing already, we haven't
retested it for a while.)
-jiri
27 Feb
27 Feb
3:09 a.m.
We only use 3 clients: ATA, Budgetone, and SPA2000. All redo their DNS
query upon a failure to contact the server. Works fine for us.
----- Original Message -----
From: "Jiri Kuthan" <jiri(a)iptel.org>
To: "Klaus Darilion" <klaus.mailinglists(a)pernau.at>at>; "Andres"
<andres(a)telesip.net>
Cc: "Nils Ohlmeier" <nils(a)iptel.org>rg>; <serusers(a)lists.iptel.org>
Sent: Thursday, February 26, 2004 1:19 PM
Subject: Re: [Serusers] replication and rtpproxy
At 06:54 PM 2/26/2004, Klaus Darilion wrote:
>But this will work only if the client uses your DNS servers, because the
DNS
entries are cached by the other nameservers - or do you have a very
short TTL configured?
>
>I think also softclients will have problems as Windows XP by default
caches the
DNS lookups.
I fear too that not every client is fine with it -- I guess quite many
feature the shortcoming of resolving registar address only on reboot :(
Hopefuly, this will change (maybe its changing already, we haven't
retested it for a while.)
-jiri
26 Feb
26 Feb
10:11 p.m.
Andres wrote:
We use DNS updates.
So, whats the expire setting in your zonefile? One issue here could be
that some large ISPs doesnt honor small expire settings in zone-files
and clients using such a dns resolver _wont_ get an updated ip-address
but get hung on the old one.
We have special scripts based on sipsak (Thanks
Nils!),
that check all SIP servers every minute.
So failover time is one minute?!
If something is wrong, then we
update our DNS dynamically to point to another SIP Server. If the UAs are
unable to register then they redo their DNS query
Youre _sure_ that every UAC will do this? With wich UACs did you test this?
best regards,
Arnd
10:57 p.m.
On Thursday 26 February 2004 21:11, Arnd Vehling wrote:
Andres wrote:
My last test are some time ago, but there were definately phones on the market
which lookup their registrar and outbound proxy IPs only one time at startup.
NO
If something is wrong, then we
update our DNS dynamically to point to another SIP Server. If the UAs
are unable to register then they redo their DNS query
Youre _sure_ that every UAC will do this? With wich UACs did you test this?
27 Feb
27 Feb
3:15 a.m.
----- Original Message -----
From: "Nils Ohlmeier" <nils(a)iptel.org
To: <serusers(a)lists.iptel.org
Cc: "Arnd Vehling" <av(a)nethead.de>de>; "Andres"
<andres(a)telesip.net Sent: Thursday,
February 26, 2004 3:57 PM
Subject: Re: [Serusers] replication and rtpproxy
Ours do it whenever they fail to contact their
SIP Server.
> NO
On Thursday 26 February 2004 21:11, Arnd Vehling
wrote:
> Andres wrote:
> > If something is wrong, then we
> > update our DNS dynamically to point to another SIP Server. If the UAs
> > are unable to register then they redo their DNS query
> Youre _sure_ that every UAC will do this?
With wich UACs did you test
this?
My last test are some time ago, but there were definately phones on the
market
which lookup their registrar and outbound proxy IPs
only one time at
startup.
3:14 a.m.
----- Original Message -----
From: "Arnd Vehling" <av(a)nethead.de>
To: "Andres" <andres(a)telesip.net>
Cc: "Klaus Darilion" <klaus.mailinglists(a)pernau.at>at>; "Nils
Ohlmeier"
<nils(a)iptel.org>rg>; <serusers(a)lists.iptel.org>
Sent: Thursday, February 26, 2004 3:11 PM
Subject: Re: [Serusers] replication and rtpproxy
Yes. But the DNS expire time is 5 minutes so I
would go by the higher
number.
this?
We only support 3 UACs on our network. ATA, BT, SPA and it works on all 3.
Andres wrote:
5 minutes
One issue here could be
We use DNS updates.
So, whats the expire setting in your zonefile? that some large ISPs doesnt honor small expire
settings in zone-files
and clients using such a dns resolver _wont_ get an updated ip-address
but get hung on the old one.
That is a possibility, But so far we have not encountered it and we have
clients in 10 countries. In any case if it works for only 95% of customers
then we will be quite happy. So far it has worked for 100% of our
customers.
We have
special scripts based on sipsak (Thanks Nils!),
that check all SIP servers every minute.
So failover time is one minute?!
> If something is wrong, then we
> update our DNS dynamically to point to another SIP Server. If the UAs
are
unable to
register then they redo their DNS query
Youre _sure_ that every UAC will do this? With wich UACs did you test
best regards,
Arnd
26 Feb
26 Feb
10:59 p.m.
On Thursday 26 February 2004 15:59, Klaus Darilion wrote:
Nils Ohlmeier wrote:
I never claimed that SRV failover will work with all clients :-)
But from the RFC clients are broken which do not support SRV and failover :-)
But for sure i'm aware that can not simply throw away such clients, even if i
would like to do so.
NO
As currently the rtp-proxy has to run on the same
host as SER it does not
make much sence IMHO to think about taking over rtp-proxy sessions. Then
you would need some kind of rtp-proxy session replication, which should
be easy when the nathelper module and the rtp proxy ever uses IP protocol
for communication. But all this will only work if the backup server takes
over the IP of the failed server, and you are not using SRV backup
servers for example (except that a SRV backup can obviously also can
takeover the IP).
Is it yet possible to build redundancy on top of SRV? I tested some
clients (Xlite, Budgetone-100, Windows Messenger 4.7) wether they use
SRV records to locate the proxy and Messenger is the only one who uses it.
7574
days inactive
7575
days old
24 comments
5 participants
participants (5)
-
Andres -
Arnd Vehling -
Jiri Kuthan -
Klaus Darilion -
Nils Ohlmeier