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