The primary protocol for VoIP is the Session Initiation Protocol (SIP). This is what enables the connection between two points on the network. Company telecom bills can be reduced by seventy five percent (75%) with SIP Trunking, Trunking consolidation, and moving to VoIP.
Other functions are involved when it comes to making VoIP calls work in situations where they normally wouldn’t. The SBC makes VoIP services work better, especially in conjunction with a variety of services (i.e. Voice, Video, Screen Sharing, Messaging, etc.).
SIP Trunking allows a shared data connection to handle voice and related traffic for an enterprise or service provider instead of having to rely on more expensive, dedicated voice lines – saving money. The SBC can also provide security to SIP Trunking services. By incorporating an SBC, an enterprise can maintain security and save money at the same time.
Session Initiation Protocol or SIP is what makes the connection between two end points and then disconnects the call when finished. In laymen’s terms, VoIP is the same as a dial tone. In order to use different network connections, SIP must be used in order for communication.
SIP falls under the Internet Engineering Task Force (IETF). But, the standard is basically recommendations or suggestions on how SIP should be used. The actual usage of SIP is up to the individual engineer or vendor which in the end is technically in compliance with published SIP standards by not necessarily in compliance with each other.
There are instances where two systems are connecting to each other while using SIP and they are speaking different languages. This happens because of all the different variations. Even though the basics are the same, they differ when it comes to syntax and dialects in the common language. But this shouldn’t cause much confusion.
Being able to speak different languages of SIP and automatically translate is what an SBC should do.
Translating or changing codecs as sessions pass through a network is the SBC’s job.
Being able to know which codecs are supported on each side of network border and using a combination of software and special purpose digital signal processors (DSPs) is what the SBC should know. Then it is able to decode and the re-encode the voice or video signal crossing the network.
Codecs are in use in various VoIP and Unified Communications (UC) systems. They are able to encode or decode algorithms that compress voice and other signals.
The beyond the voice alternative of VoIP is UC. This means that videoconferencing, screen sharing, and instant messages are delivered using the VoIP network platform.
Being designed to work differently, low and high bandwidth video and voice codecs work on many different devices. Some of the devices are:
- Computer and tablet devices
- Dedicated VoIP phones
- Mobile devices such as smartphones and iPhones
Support codecs always have different jobs in a VoIP call. For example, when a few important customers call in using a different codec than your company’s private branch exchange or PBX, which supports only one specific codec, the SBC will be able to understand both codecs and modify the codec when the call passes through it.
There are still some codecs that unfortunately cannot be implemented on a device for a variety of reasons. It could be because of developers haven’t gotten around to it yet, software licensing expense, or the device has a slow CPU and can’t handle the codec. In two specific instances, transcoding comes into effect frequently, HD Voice and Bandwidth restrictions.
With VoIP and mobile causing a motion away from traditional landline phone, sound quality of voice calls has come into question. However, High Definition (HD) Voice has been developed to combat this issue. The goal is to reproduce a wider range of frequencies at higher clarity instead of traditional narrow-band codecs, resulting in a voice call that’s easier on the ears and you are able to tell who is talking.
An example would be going from and AM radio to CD. But there is a downside to HD Voice. No one implementation of the service and no one single codec in use by every HD Voice capable system. By having an appropriate SBC in the middle of the call, you solve the problem. Being able to transcode, the SBC keeps the call HD.
You can’t always have limitless bandwidth available to you. There are times when the person called is connected to a mobile network outside of not only 4G but also BG coverage. There are also times when a person called is in a home office with a dial-up connection or to someone using an unreliable hotel Wi-Fi connection. When it comes to an entire network portion of an SIP call, videoconferencing or screen sharing session, bandwidth cannot be taken for granted. Codecs are available that trade loyalty and audio/video quality for greater compression with the end result of using less bandwidth.
Not wanting to blemish low-fidelity codecs all the time, they are necessary with at least part of the calls path. Sitting between network segments, an SBC can recognize this problem and be able to transcode it to and from lower bandwidth codecs when the need arises, making it greater than relying on VoIP clients themselves. There is no need for the clients do this kind of calculation outright since not all clients support all codecs.
SBC - Localized Policy Control
Depending on preconfigured policies, VoIP networks are like any other network. These policies are able to take control of how calls are prioritized and handled and also what to do when something strange happens. This could be calls from known spammers, to many calls at once, etc.
Operating telephone switchboards, policy need to be in place for these operators to be able to perform their job. They have a set of rules with regards to incoming and outgoing phone calls and how they are handled.
Policies that take control of network decisions:
- Call admission control
- Bandwidth utilization and rate limiting
- Least cost routing
- Media paths and routing
Policies that you have set for your network can be locally administered with an SBC. This is at the border of an enterprises network or a service provider’s network. Reduction in response time and inactivity in the network is what you will have when these policies are controlled at a local level. This is made possible because there is no need for policy decisions to refer back to a remote server that is located elsewhere to be implemented. With being less expensive to initiate in the beginning, local policy enforcement has no need for any additional equipment.
SBC - Centralized Policy Management
With a number of SBCs being installed at different network borders in larger organizations, having to individually configure policies on all SBCs can be monotonous and costly. Further centralization by using a master policy server that can reproduce a single set of policy rules, and any policy changes, to each SBC on the network without the need for an expensive IT professional to have to manually configure each one is an alternate to localized policy control. With costs being a little more and a small amount of inactivity into the network, this concept will save you some money in the end. It will also allow the network administrators to be able to administer policies based on network utilization quickly.
Being able to guarantee that policies are regularly administered throughout the network for policy changes are automatically distributed to all the SBCs. Escalating your network to an abundance of sites and SBCs, centralized management is the way to go.
Please consult the experts at BroadConnect when determining which key requirements your network requires to deliver the optimum results.