Hi Ryan No is the direct answer but I can lend some wider perspective which might be helpful.
Can you run media at scale in VMs? Assuming we’re talking hypervisor virtualisation and a proper enterprise grade hypervisor like vSphere, rather than public cloud, then yes you can with caveats. There used to be concerns around CPU scheduling and the introduction of jitter but recent versions have dramatically improved that. There is jitter just by virtue of using a shared resource but how much depends on contention levels; on a platform that is not oversubscribed it is perfectly acceptable and not dissimilar to natural jitter levels over typical end-user connectivity. VMWare did some testing and research on this at various levels of subscription a few years ago which you might find useful: http://www.vmware.com/files/pdf/techpaper/latency-sensitive-perf-vsphere55.pdf Most of our media is handled in hardware but where it is handled in software that is still on bare-metal with a few exceptions. Those exceptions are, for example, fax servers and even our office PBX. Performance from both is indistinguishable to bare-metal for practical purposes, albeit at much lower volume. Would I buy an SBC? No, unless I had specific transport changes (where I didn’t understand one of them!) or to give certified compatibility with something non-standard such as Lync. For SIP-to-SIP I firmly believe a properly configured open-source stack to be superior in _almost_ every way. The only two selling points for a single box SBC over an open source stack that I see are: - ticking the procurement box of a clean point of demarcation deployable right on the edge. This is trivial to do on open-source on commodity hardware but you can’t give a procurement bod a spec sheet, and to do it properly it won’t be a single box solution. - hardware DSPs. You can obviously get hardware DSPs on a PCI card (we use them quite successfully where we can’t bypass media directly to hardware) but it is greatly preferable to handle it truly in hardware which an SBC does and they do it well. Do either of those selling points apply to a vSBC? No! By definition it will not be sitting on the edge, it’ll be sitting quite deeply inside the network and rather than being a clean point of demarcation, it’ll be dependent on hypervisor security and any trunking (or God forbid overlay network) used to reach the virtual NIC. Similarly, there is no hardware DSP as there is no hardware. All transcoding (and for that matter encryption) will be done in software, in shared resource with additional layers underneath. Now, having said all of that I have in moments of weakness looked at these and quizzed vendor SEs. I believe if you feel you need an SBC they can do the job, just with the two compromises I mention above. Where I do struggle is on the performance claims particularly in terms of concurrent calls. The performance stats I’ve seen for similar things (e.g. 50k concurrent!) are trivial to achieve in SIP but in terms of media handling feel far closer to basic media proxy than a full B2BUA performing encryption and transcoding (all in software). Thus before committing I’d be wanting to test with real-world traffic and would fully expect throughput to be a fraction of the datasheet figure. If that transpires anything like other virtual versions of hardware appliances we’ve looked at in other fields I expect you’ll conclude the hardware version to be preferable! Hope that helps! Simon > On 7 Apr 2016, at 02:12, Ryan Finnesey <[email protected]> wrote: > > Has any more worked with products similar to > http://www.sonus.net/products/session-border-controllers/virtualized-sbc-swe > > What has your experience been? > > Cheers > Ryan > >
