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