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