On Fri, Nov 6, 2009 at 4:42 PM, RJ Auburn <rj at voxeo.com> wrote:

I have seen F5's really mess up SIP signaling on a few deployments. They have some basic SIP features but if the NAT stuff gets complex they were not always rewriting all the headers. When pressed it seemed like their support had only done a few SIP deployments and it was pretty limited.

Good to know. It's not why we purchased them, but figured I would give it a shot. You could probably overcome most of that with custom irules, but who wants to spend weeks coding that... Linux-HA won't give you stateful failover, that you seem to have to pay through the nose for. If you can deal with the possibility of a few second outage, and ongoing calls dropping, then it is a viable option. We use Linux based cluster services to a large extent because it is cheap, and the liability is low for us. It all depends on the SLA and how much you want to spend. -Jonathan

On Nov 6, 2009, at 5:42 PM, Jonathan Thurman wrote:

...

On Fri, Nov 6, 2009 at 2:58 PM, anorexicpoodle <anorexicpoodle at gmail.com> wrote:

...

I have pretty much ruled out OpenSER/OpenSIPS/Kamilio because it isn't stateful in HA failover. Passing it through an Acme is ridiculously costly for the need i have, and most hardware based load balancers I am finding just aren't sip-aware, so I don't see them doing much better than OpenSER in a fail-over scenario, it would just be a different kind of ugliness.

F5s are SIP aware, but also expensive. ?We just got some LTM 1600s, but I haven't configured them for SIP yet. ?Everything else I have used them for they have been rock solid, so I am optimistic.

-Jonathan _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

anorexicpoodle wrote:

Session state, so in the event the load balancers experience a failover, new messages within existing sessions (re-invite, refer, bye etc) are still routed appropriately. Obviously if the elements being load balanced across experience a failure, sessions on the failed element are gone, so I am not worried about that, just more about making the middle as invisible as possible.

If you are referring to sequential, in-dialog messages such as re-INVITEs, BYEs, etc., these are routed on the basis of SIP protocol semantics and not state. At least, not in the case of a proxy, which may keep transactional state but not dialog or session state. In-dialog requests are identified as such by the presence of a From and To tag parameter and a Route: header, not by the maintenance of any additional state. When Kamailio or OpenSIPS routes such a request now, it does not refer to any dialog state it keeps internally; the only state it maintains is on transactions, and all of those requests constitute new transactions. In conclusion, I believe you are mistaken. It is quite possible to open a dialog with a successful INVITE transaction on one proxy, experience host failover and initialise a new proxy instance, and correctly route a re-INVITE, BYE, etc. UAs keep dialog and/or session state. Proxies do not. If you use a proxy as a load-balancer, it will meet the requirement. I suppose the only caveat with stateful forwarding is if failover occurs in the middle of a pending transaction that has not yet received a final positive or negative reply; however, in that case, routing should fall back on Via headers if no transactional state is present. Kamailio and OpenSIPS would do the job quite nicely here. <shameless plug>This is what we do at Evariste. Contact me if off-list if you are interested in having someone do this implementation. Otherwise, I will be happy to answer any other questions you may have.</shameless plug> -- Alex -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671

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