On Nov 7, 2009, at 12:36 AM, Simon Woodhead wrote:
RTP failover is a different story and different vendors do it different ways. JT, I don't agree with you (for once!) that there is a massive amount of data to sync; all a slave system needs to know is the RTP ports on which it can expect to receive traffic and bridge details. The commercial solutions we've looked at work on mac address assumption (not IP address) and a slave can be a slave for many masters as it is not actually handling full RTP for the master. It isn't in FreeSwitch but I wouldn't expect it to be the challenge it is perceived as being if someone has the motivation to tackle it. I agree though, the VM based FT solutions are packet-by-packet mirrors so there would be a lot to sync but who would run media on a VM anyway?!
All the best, Simon
Simon - Perhaps if all you're talking about is a load balancing system for RTP which doesn't terminate or transcode, then possibly RTP failover is "easier". And I can see how that could be done - it's fairly complex, but not implausible. So I suppose I'm wrong in saying it's that difficult in reference to the original question, which was (I believe) for a really simple load balancing solution for RTP. Maybe even "mediaproxy" (or mediaproxy 2.0) could get an extension that supported this type of synchronization; it seems to be the lightest- weight solution out there currently. In my world (the B2BUA/application server world) the state of media needs to be kept, since things like RTP sequence numbers, jitterbuffer, RTCP stats, RFC2833 sequence status, and all of the "ugly details" need to be recorded do a truly fault-tolerant replication. This doesn't even touch the other things like application state, database calls for upper-layer call handling, CDR synchronization, and other stuff higher up the model. Lots of people run media on a VM. Twilio, for example, bases its business on that architecture. Almost every voice app that runs on cloud computing infrastructure will be terminating RTP on a VM - it doesn't make sense just to relay media _through_ a VM when it's far more efficient to do point-to-point RTP. So that kind of narrows down the audience using VMs as people who are probably using them to terminate/originate RTP. You're thinking "service provider/ITSP" and I'm talking about "application provider." Application providers or even transcoders require a lot more state-keeping to minimize the transition disruption between two physical systems in the event of a failure - it's difficult. The problem is that there are constantly blurring layers unless you're doing strictly transport. JT