[VoiceOps] Virtualized SBC

[Ryan Delgrosso]

I'm not sure I share your narrow view of what an SBC is and the role it 
plays in modern network architecture.

There is absolutely a subset of uses for an SBC that fit perfectly into 
the box you have outlined but in the broader sense it is a demarcation 
and control point between network segments where you can inject 
interworking and business logic.

For example:

  * Crypto offload  - softswitches spending cycles on media crypto is
    wasteful and occasionally not possible
  * Transcoding  - G711 is a anchor we wear around our necks, and the
    lack of a SINGLE clear successor means transcoding is a necessity, I
    wont even open the can of worms that is faxing but as im sure anyone
    who has had the displeasure of troubleshooting a T38 negotiation
    with a rogue media gateway 2 carrier hops from you can tell you,
    just being able to transcode and make both sides happy is the path
    to a long and serene life as a network operator.
    http://i.imgur.com/BB4T3RW.png
  * CALEA taps
  * IPV4/IPV6 interworking - to my knowledge most of the CPE and
    commercial elements havent fully gotten on the V6 bandwagon but
    anyone dealing with mobile voice knows this reality
  * Media control / monitoring - MOS monitoring / QOS enforcement
  * Security services - sanitizing SIP traffic so you dont spend
    softswitch cycles on answering free-floating internet hostility
  * Abstraction and load balancing
  * Fraud mitigation - I have written whole papers on this so Ill save
    the pontification on this topic


And that is beyond the massive subset of problems I have solved using 
the SBC as a swiss army knife to bludgeon success into scenarios that 
would otherwise be at an impasse because the elements on either side of 
it did not belong to me or were not able to have their native behavior 
altered for various rea$on$.

An SBC is the Thneed of the modern communications network 
https://www.youtube.com/watch?v=R7XA0h6HeOw



On 4/6/2016 7:16 PM, Alex Balashov wrote:
> That's just it. SBCs are a terrible example of "NFV" because SBCs do 
> not actually perform a "network function" of the sort that begs to be 
> decoupled and abstracted in the way that NFV and SDN envisions, like 
> software-defined switches and routers. The idea that the SBC is a kind 
> of "voice firewall" is a fiction pushed by the marketing departments 
> of SBC vendors.
>
> What is an SBC? It's a SIP B2BUA with some sort of provisioning and 
> management interface. If you're lucky, there are some ASICs or 
> kernel-mode crypto, transcoding and/or packet forwarding functions. 
> It's an application-layer construct, a giant softphone touted as a 
> condom that must go over innocent and vulnerable "softswitches". It's 
> not a "network" element, but it looks much better on Visio diagrams to 
> depict it as one.
>
> On 04/06/2016 09:58 PM, Ryan Delgrosso wrote:
>
>> They have more than a buzzword for this, its a whole movement.
>>
>> Realistically NFV encompasses more than just raw virtualization its also
>> elastic capacity and the orchestration layer to manage it. The only
>> problem is most vendors have only accomplished the virtualization part
>> and are still sorting out the orchestration while trumpeting NFV.
>>
>>
>>
>>
>> On 4/6/2016 6:45 PM, Alex Balashov wrote:
>>> So, it's news to the Bellhead world that most "SBCs" run on commodity
>>> pizza boxes & OSs that are branded by the vendor and resold at large
>>> markups, and that the software can be separated from the hardware and
>>> executed on other pizza boxes, and, indeed, inside VMs? And they have
>>> a whole buzzword for this?
>>>
>>
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20160406/33b7ada3/attachment-0001.html>