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
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
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
On Thursday 26 February 2004 06:28, Arnd Vehling wrote:
Nils Ohlmeier wrote:
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?
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.
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.
Hopefully you are aware that db synchronisation currently does not work with the user location db, because it is cached it memory.
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.
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?
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.
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:
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.
? I did set "usrloc" "db_mode" 1. So the usr locations should get committet imediatly. (Performance Issue, I know..)
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
On Thursday 26 February 2004 21:02, Arnd Vehling wrote:
Nils Ohlmeier wrote:
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.
? 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
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
On Thursday 26 February 2004 22:40, 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?!
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.
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.
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
Nils Ohlmeier wrote:
On Thursday 26 February 2004 22:40, 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?!
INVITE and subscriber table???
ARGH, NO :) I ment the "register" message.
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.
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 23:22, Arnd Vehling wrote:
Nils Ohlmeier wrote:
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?
Selective DB replication combined with t_replicate is possible.
NO
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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
----- Original Message ----- From: "Klaus Darilion" klaus.mailinglists@pernau.at To: "Arnd Vehling" av@nethead.de Cc: "Nils Ohlmeier" nils@iptel.org; serusers@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:
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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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
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
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@pernau.at To: "Nils Ohlmeier" nils@iptel.org Cc: serusers@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@pernau.at To: "Nils Ohlmeier" nils@iptel.org Cc: serusers@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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
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
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@iptel.org To: "Klaus Darilion" klaus.mailinglists@pernau.at; "Andres" andres@telesip.net Cc: "Nils Ohlmeier" nils@iptel.org; serusers@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
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
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.
NO
----- Original Message ----- From: "Nils Ohlmeier" nils@iptel.org To: serusers@lists.iptel.org Cc: "Arnd Vehling" av@nethead.de; "Andres" andres@telesip.net Sent: Thursday, February 26, 2004 3:57 PM Subject: Re: [Serusers] replication and rtpproxy
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.
Ours do it whenever they fail to contact their SIP Server.
NO
----- Original Message ----- From: "Arnd Vehling" av@nethead.de To: "Andres" andres@telesip.net Cc: "Klaus Darilion" klaus.mailinglists@pernau.at; "Nils Ohlmeier" nils@iptel.org; serusers@lists.iptel.org Sent: Thursday, February 26, 2004 3:11 PM Subject: Re: [Serusers] replication and rtpproxy
Andres wrote:
We use DNS updates.
So, whats the expire setting in your zonefile?
5 minutes
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.
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?!
Yes. But the DNS expire time is 5 minutes so I would go by the higher number.
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? We only support 3 UACs on our network. ATA, BT, SPA and it works on all 3.
best regards,
Arnd
On Thursday 26 February 2004 15:59, Klaus Darilion wrote:
Nils Ohlmeier wrote:
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.
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
-
Andres -
Arnd Vehling -
Jiri Kuthan -
Klaus Darilion -
Nils Ohlmeier