SBC Controversy

Controversy

The concept of SBC is controversial to proponents of end-to-end systems and peer-to-peer networking because:

• SBCs can extend the length of the media path (the way of media packets through the network) significantly. A long media path is undesirable, as it increases the delay of voice packets and the probability of packet loss. Both effects deteriorate the voice/video quality. However, many times there are obstacles to communication such as firewalls between the call parties, and in these cases SBCs offer an efficient method to guide media streams towards an acceptable path between caller and callee; without the SBC the call media would be blocked. Some SBCs can detect if the ends of the call are in the same subnetwork and release control of the media enabling it to flow directly between the clients, this is anti-tromboning or media release. Also, some SBCs can create a media path where none would otherwise be allowed to exist (by virtue of various firewalls and other security apparatus between the two endpoints). Lastly, for specific VoIP network models where the service provider owns the network, SBCs can actually decrease the media path by shortcut routing approaches. For example, a service provider that provides trunking services to several enterprises would usually allocate each enterprise a VPN. It is often desirable to have the option to interconnect the VPN through SBCs. A VPN-aware SBC may perform this function at the edge of the VPN network, rather than sending all the traffic to the core.
• SBCs historically had the potential to restrict the flow of information between call endpoints, restricting end-to-end transparency. VoIP phones may not be able to use new protocol features unless they are understood by the SBC. However, the more modern and flexible SBCs are able to cope with the majority of new, and unanticipated protocol features.
• Sometimes End-to-End encryption can't be used if the SBC does not have the key, although some portions of the information stream in an encrypted call are not encrypted, and those portions can be used and influenced by the SBC. However, the new generations of SBCs, armed with sufficient computing capacity, are able to offload this encryption function from other elements in the network by terminating SIP-TLS, IPsec, and/or SRTP. Furthermore, SBCs can actually make calls and other SIP scenarios work when they couldn't have before, by performing specific protocol "normalization" or "fix-up".
• In most cases, far-end or hosted NAT traversal can be done without SBCs if the VoIP phones support protocols like STUN, TURN, ICE, or Universal Plug and Play (UPnP).

Most of the controversy surrounding SBCs pertains to whether call control should remain solely with the two endpoints in a call (in service to their owners), or should rather be shared with other network elements owned by the organizations managing various networks involved in connecting the two call endpoints. For example, should call control remain with Alice and Bob (two callers), or should call control be shared with the operators of all the IP networks involved in connecting Alice and Bob's VoIP phones together. The debate of this point is vigorous, almost religious, in nature. Those who want unfettered control in the endpoints only, are greatly frustrated by the various realities of today's networks, such as firewalls, filtering/throttling, and the lack of adoption of a universal VoIP equivalent to the phone number. Those who provide the infrastructure used to connect the call end-points, are typically concerned about overall network performance/quality and want to ensure it is secure against the new series of threats that come with an IP based packet infrastructure. So far, these views have not proven to be reconcilable. Note that it may be required for a third call control element such as an SBC to be inserted in between the two endpoints in order to satisfy local lawful interception regulations.

Posted in: