[VoiceOps] Load balancing

[John Todd]

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