What is SBC (Session Border Controller) and why is it needed
The market of session border controllers is gaining momentum every year, while for many in the field of VoIP this device remains a kind of question - why is it needed and where to use it correctly. Actually, I would like to describe the functions and tasks that this equipment performs and why the installation of this device, if not necessary, then certainly highly desirable on a VoIP network.
Let's go from simple to complex. First, we define the very three functions that SBC performs on the customer’s network.
1. Security
2. Compatibility
3. Quality Assurance and Control
In most cases, for many, a lot of questions immediately arise, since it would seem that there is a Firewall that copes with the security function perfectly and why additionally protect the VoIP network. Why ensure compatibility if there is an RFC3261 standard and everyone works according to this standard. And quality - there is an opinion that VoIP quality depends more on the quality of the network, and not on any device. Now we’ll take a closer look at what the security of the VoIP network actually is, and why RFC3261 (SIP v2) compatibility is not enough, what exactly does the Session Border Controller provide in terms of quality.
1. Security
First, we need to figure out what we want to protect against and what can an attacker do? The very first and painful thing an attacker can do is steal traffic. An attacker gains access to make it possible for you to call a telecom operator on your behalf and then makes rather expensive calls somewhere to sunny Cuba through your system. What this threatens, probably, everyone understands - a big bill from the side of the telecom operator.
How does theft happen and what are the mechanisms to prevent it?
As always, everything should begin with the most primitive. Moreover, this primitive will protect you quite strongly. In most cases, attackers simply start by checking all IP addresses by responding to the SIP port (UDP 5060). For example, sending an OPTIONS message to a given port sequentially to all IP addresses. So he is just looking for another victim. Then the following happens: as soon as they receive an answer, the attacker immediately receives a lot of information about you. Namely - he knows that your SIP is accessible via the Internet and in 99% of cases he knows the type of your IP-PBX. How exactly does he do it? Easy. When IP-PBX answers a SIP request, it gives a response where the User-Agent field with the name and version of the device is indicated. For example: user-agent: Asterisk 1.2.3. I just want to apologize to all Asterisk lovers, I’ll mention her, since it is the most popular system for hacking. What SBC does in this case: on the recommendation, it uses a port other than 5060 and easily replaces the value of the User-Agent field. Here we immediately put the attacker in a more complicated situation - firstly, his system does not always determine that you are using SIP, since in most cases you simply do not respond to his requests; secondly, even after receiving an answer, he will not know what your station is and what side to approach it. Why the second is also very important. And everything is simple. For example: an attacker determined that you had Asterisk version 1.2.3, which had a bug that allowed you to call an extension number and then use DTMF dialing to set the forwarding of this extension number. And then he calls this internal number, where there is a call forwarding to the number he needs.
And if we talk about call forwarding, then it is one of the thinnest, from the point of view of security in VoIP. Since in most cases no one thinks how and where to transfer the number, who made the call, but he is simply replaced without options by the number who redirected the call. This is also important and you need to verify that the SBC does the same. This article will not go into the subject of call forwarding.
Another important issue is management and access to management. SBC initially has many interfaces and VLAN configuration options, which allows the management interface to be moved to a separate secure subnet, which makes accessing it very difficult.
From a security point of view, it is worth paying special attention to call routing and SIP packet inspection. It is important that any package is as trusted as possible. For this, SBC has a lot of tools. Firstly, it is a check on various fields. For example, you know that a message always comes from the operator, with the User-Agent: ITSP_SIP field and adds something else. Or, when you connect your phone to the IP PBX via the Internet, you must always verify that registration is from the telephone that is allowed on your network. Also, it is required to determine as correctly as possible the routes to which you can call, from which you can call. It also allows the SBC to provide the right level of security.
Another very important point that ensures the SBC security of your IP-PBX is the differentiation of VoIP traffic on your network. It allows you to select a separate subnet for your IP-PBX and make access to it only from another physical interface, thereby ensuring access to your VoIP network only through the Session Border Controller.
And then, this is a set of standard things, such as a regular Firewall, which is also located on SBC.
Actually, it is these tools on SBC that allow you to provide security against an attempt to hack into a system to steal traffic or some other actions. Of course, SBC has other protection methods and methods, but here I have described rather the most popular and important actions to protect your VoIP network:
a. There are also DoS / DDoS attacks. On the one hand, they are more harmless, since they just turn off the telephony service, but there is another side to this problem:
b. Here you need to clearly understand that if the IP-PBX is turned off, then all telephony disappears, which in itself is not pleasant and can affect the business process.
c. Also not unimportant factor is that most often these attacks are done in order to select user passwords with further actions of this user. Including theft of traffic.
SBC has a built-in Firewall, which works on two principles - static and dynamic. The first option is understandable and there is probably no point in describing it. The second option works as follows. If you allow the possibility of registering SIP subscribers from the Internet, then theoretically it can be registered from any source and statically filtering is simply impossible. For example, if your employees flew somewhere to China and want to connect to your IP-PBX, you will need to open full access, or at least to all Chinese IP addresses. The only way to secure your IP telephony network is through dynamic access control lists, when SBC closes only those IP addresses at the network level from which abnormal traffic is coming. Moreover, you set the degree of anomaly yourself.
There is still the issue of eavesdropping and the only way around this is encryption. But, since in our country the security services treat this topic very carefully, I will leave this topic unattended. Moreover, in Russia no one provides encryption for the same reasons.
2. Compatibility
The second question that confronts the SBC is compatibility. Everyone talks about the fact that they support SIP v2 (aka RFC 3261) and everything will work like that. But as practice shows, this is not sucking that way, or rather not at all. I would say that the compatibility issue is the most complex and complex in a VoIP network. Why is that? And why are IP PBXs and unified communications systems made? No matter how everyone says that they strive for standardization, in fact the priority is the main one in another and it completely contradicts the very idea of doing everything according to the standard. The task of PBX manufacturers is to provide the most interesting and complete range of services, and if someone suddenly came up with a new service, then they have no option but to do it their own way. (Well, then make a new RFC and tell everyone - support). Moreover, the drain of information in our world works well (but not excellent). And if a competitor finds out that someone is making a new feature, naturally he does the same, though in his own way he standardizes his version of the implementation of this function and naturally standardizes it. As a result, the world receives two excellent stations with the same function, which work differently, while according to the standard, but are not compatible with each other. And if no one has problems with the basic call, then there are always plenty of questions with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. A station usually supports no more than 20, our SBC supports more than 80. And if you require that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case. And if a competitor finds out that someone is making a new feature, naturally he does the same, though in his own way he standardizes his version of the implementation of this function and naturally standardizes it. As a result, the world receives two excellent stations with the same function, which work differently, while according to the standard, but are not compatible with each other. And if no one has problems with the basic call, then there are always plenty of questions with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. A station usually supports no more than 20, our SBC supports more than 80. And if you require that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case. And if a competitor finds out that someone is making a new feature, naturally he does the same, though in his own way he standardizes his version of the implementation of this function and naturally standardizes it. As a result, the world receives two excellent stations with the same function, which work differently, while according to the standard, but are not compatible with each other. And if no one has problems with the basic call, then there are always plenty of questions with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. A station usually supports no more than 20, our SBC supports more than 80. And if you require that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case. In its own way, it standardizes its version of the implementation of this function and, naturally, standardizes it. As a result, the world receives two excellent stations with the same function, which work differently, while according to the standard, but are not compatible with each other. And if no one has problems with the basic call, then there are always plenty of questions with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. A station usually supports no more than 20, our SBC supports more than 80. And if you require that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case. In its own way, it standardizes its version of the implementation of this function and, naturally, standardizes it. As a result, the world receives two excellent stations with the same function, which work differently, while according to the standard, but are not compatible with each other. And if no one has problems with the basic call, then there are always plenty of questions with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. A station usually supports no more than 20, our SBC supports more than 80. And if you require that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case. And if no one has problems with the basic call, then there are always plenty of questions with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. A station usually supports no more than 20, our SBC supports more than 80. And if you require that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case. And if no one has problems with the basic call, then there are always plenty of questions with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. A station usually supports no more than 20, our SBC supports more than 80. And if you require that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case.
And compatibility is affected by that same security. And not your safety, but the safety of a telecom operator. As a rule, an operator has its own SBC and in most cases it has clear and understandable message / field / function filters when working with a client. I will give two simple and clear examples:
a. The IP PBX uses SIP Refer to transfer the call (this is when the station tells the higher station that you are transferring the call to an external subscriber, and let the higher station connect to each other. Everything is fine, but here's the point - who should be billed. The operator in this case should close the call between the two non-subscribers. The bill must be billed to you, but there wasn’t a call with you. For this reason, the operator simply blocks this functionality (and does it right). SBC in this case takes care of the call switching and working off from REFER messages and for the operator two calls are displayed (incoming and outgoing), and everything works fine.
b. Call Forwarding For example: Subscriber A called subscriber B, who is forwarding to subscriber B. And here the call goes from subscriber B to subscriber B, while the number A is displayed as the number of the caller. And this is correct, since the calling number is number A, not the one that redirects. This is the telephone standard. And if in ISDN (E1) all this is clearly described, since there is a Redirect number field, then in SIP number B for correct identification can be transmitted using History-Info, Referred-By, Diversion. And on this basis, operators simply like to block such numbers, referring to the fact that their billing does not work correctly. That is, the carrier’s billing is contrary to the SIP standard or the operator simply does not want to accept forwarded calls according to the standard.
The remaining examples are not so common, but no less important, since the less often they occur, the more difficult it is to solve them using standard telephone exchange methods. Separately, I want to talk about compatibility issues and adaptation of voice codecs. The time has passed when everyone supported the G.711 and G.729 codecs, and that’s enough. There are a lot of reasons for this, and most importantly, PBX manufacturers are striving to improve the quality of communication using their own codecs or specialized codecs, such as SILK / OPUS / MS-RTA. Here the reason is simple (especially if we are talking about a unified communications system) - now all companies are striving to make telephony not only on an IP phone (which can be allocated in a separate VLAN and give traffic priority), but also to make telephony everywhere - on tablets, laptops, smartphones via WiFi, public Internet.
This is where SBC helps you use the codec that is required on your network, and connect to the operator using the one that it supports.
Separately, there is the issue of DTMF and faxes, which no one canceled in the VoIP environment. I do not want to delve into this topic, I can only say that we currently support all transmission options for both DTMF and faxes.
In fact, you can write about compatibility for a long time and you can even make separate articles on how to solve a particular problem using our SBC. But in any case, even if your operator says that he will achieve full compatibility with you, the operator does not always achieve this and the timing for setting this compatibility is always long. SBC allows you to reduce risks and reduce connection costs.
3. Assurance and quality control
Well, in conclusion, I’ll write a little about quality assurance and quality control:
a. Quality assurance - first of all, it is work with voice codecs.
b. Quality Control - SBC monitors all calls for a variety of parameters, such as Echo / Delay / Packet Loss / Jitter / MoS, and when you have a problem, you immediately clearly and quickly understand which side and for what reason communication deterioration occurred, thereby reducing deadlines for correcting problems. SBC also allows you to independently re-route if there is a drop in the quality of communication with one operator. This will save call quality without external intervention.
Also, an important factor in terms of quality assurance is the correct routing setup with the ability to balance and reserve routes. Including, if you have a backup junction with the Internet, then it should be included, including for VoIP, regardless of the network equipment settings.
I can’t say that these are all the functions and tasks that the Session Border Controller (SBC) performs, especially since everything is extremely difficult to list. I would even say that, from the point of view of safety, compatibility and quality, there are simply no universal recipes and sometimes each connection is unique and special. Our task here is to provide the maximum number of possibilities so that your use of VoIP meets all your business requirements for an IP telephony system.
Let's go from simple to complex. First, we define the very three functions that SBC performs on the customer’s network.
1. Security
2. Compatibility
3. Quality Assurance and Control
In most cases, for many, a lot of questions immediately arise, since it would seem that there is a Firewall that copes with the security function perfectly and why additionally protect the VoIP network. Why ensure compatibility if there is an RFC3261 standard and everyone works according to this standard. And quality - there is an opinion that VoIP quality depends more on the quality of the network, and not on any device. Now we’ll take a closer look at what the security of the VoIP network actually is, and why RFC3261 (SIP v2) compatibility is not enough, what exactly does the Session Border Controller provide in terms of quality.
1. Security
First, we need to figure out what we want to protect against and what can an attacker do? The very first and painful thing an attacker can do is steal traffic. An attacker gains access to make it possible for you to call a telecom operator on your behalf and then makes rather expensive calls somewhere to sunny Cuba through your system. What this threatens, probably, everyone understands - a big bill from the side of the telecom operator.
How does theft happen and what are the mechanisms to prevent it?
As always, everything should begin with the most primitive. Moreover, this primitive will protect you quite strongly. In most cases, attackers simply start by checking all IP addresses by responding to the SIP port (UDP 5060). For example, sending an OPTIONS message to a given port sequentially to all IP addresses. So he is just looking for another victim. Then the following happens: as soon as they receive an answer, the attacker immediately receives a lot of information about you. Namely - he knows that your SIP is accessible via the Internet and in 99% of cases he knows the type of your IP-PBX. How exactly does he do it? Easy. When IP-PBX answers a SIP request, it gives a response where the User-Agent field with the name and version of the device is indicated. For example: user-agent: Asterisk 1.2.3. I just want to apologize to all Asterisk lovers, I’ll mention her, since it is the most popular system for hacking. What SBC does in this case: on the recommendation, it uses a port other than 5060 and easily replaces the value of the User-Agent field. Here we immediately put the attacker in a more complicated situation - firstly, his system does not always determine that you are using SIP, since in most cases you simply do not respond to his requests; secondly, even after receiving an answer, he will not know what your station is and what side to approach it. Why the second is also very important. And everything is simple. For example: an attacker determined that you had Asterisk version 1.2.3, which had a bug that allowed you to call an extension number and then use DTMF dialing to set the forwarding of this extension number. And then he calls this internal number, where there is a call forwarding to the number he needs.
And if we talk about call forwarding, then it is one of the thinnest, from the point of view of security in VoIP. Since in most cases no one thinks how and where to transfer the number, who made the call, but he is simply replaced without options by the number who redirected the call. This is also important and you need to verify that the SBC does the same. This article will not go into the subject of call forwarding.
Another important issue is management and access to management. SBC initially has many interfaces and VLAN configuration options, which allows the management interface to be moved to a separate secure subnet, which makes accessing it very difficult.
From a security point of view, it is worth paying special attention to call routing and SIP packet inspection. It is important that any package is as trusted as possible. For this, SBC has a lot of tools. Firstly, it is a check on various fields. For example, you know that a message always comes from the operator, with the User-Agent: ITSP_SIP field and adds something else. Or, when you connect your phone to the IP PBX via the Internet, you must always verify that registration is from the telephone that is allowed on your network. Also, it is required to determine as correctly as possible the routes to which you can call, from which you can call. It also allows the SBC to provide the right level of security.
Another very important point that ensures the SBC security of your IP-PBX is the differentiation of VoIP traffic on your network. It allows you to select a separate subnet for your IP-PBX and make access to it only from another physical interface, thereby ensuring access to your VoIP network only through the Session Border Controller.
And then, this is a set of standard things, such as a regular Firewall, which is also located on SBC.
Actually, it is these tools on SBC that allow you to provide security against an attempt to hack into a system to steal traffic or some other actions. Of course, SBC has other protection methods and methods, but here I have described rather the most popular and important actions to protect your VoIP network:
a. There are also DoS / DDoS attacks. On the one hand, they are more harmless, since they just turn off the telephony service, but there is another side to this problem:
b. Here you need to clearly understand that if the IP-PBX is turned off, then all telephony disappears, which in itself is not pleasant and can affect the business process.
c. Also not unimportant factor is that most often these attacks are done in order to select user passwords with further actions of this user. Including theft of traffic.
SBC has a built-in Firewall, which works on two principles - static and dynamic. The first option is understandable and there is probably no point in describing it. The second option works as follows. If you allow the possibility of registering SIP subscribers from the Internet, then theoretically it can be registered from any source and statically filtering is simply impossible. For example, if your employees flew somewhere to China and want to connect to your IP-PBX, you will need to open full access, or at least to all Chinese IP addresses. The only way to secure your IP telephony network is through dynamic access control lists, when SBC closes only those IP addresses at the network level from which abnormal traffic is coming. Moreover, you set the degree of anomaly yourself.
There is still the issue of eavesdropping and the only way around this is encryption. But, since in our country the security services treat this topic very carefully, I will leave this topic unattended. Moreover, in Russia no one provides encryption for the same reasons.
2. Compatibility
The second question that confronts the SBC is compatibility. Everyone talks about the fact that they support SIP v2 (aka RFC 3261) and everything will work like that. But as practice shows, this is not sucking that way, or rather not at all. I would say that the compatibility issue is the most complex and complex in a VoIP network. Why is that? And why are IP PBXs and unified communications systems made? No matter how everyone says that they strive for standardization, in fact the priority is the main one in another and it completely contradicts the very idea of doing everything according to the standard. The task of PBX manufacturers is to provide the most interesting and complete range of services, and if someone suddenly came up with a new service, then they have no option but to do it their own way. (Well, then make a new RFC and tell everyone - support). Moreover, the drain of information in our world works well (but not excellent). And if a competitor finds out that someone is making a new feature, naturally he does the same, though in his own way he standardizes his version of the implementation of this function and naturally standardizes it. As a result, the world receives two excellent stations with the same function, which work differently, while according to the standard, but are not compatible with each other. And if no one has problems with the basic call, then there are always plenty of questions with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. A station usually supports no more than 20, our SBC supports more than 80. And if you require that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case. And if a competitor finds out that someone is making a new feature, naturally he does the same, though in his own way he standardizes his version of the implementation of this function and naturally standardizes it. As a result, the world receives two excellent stations with the same function, which work differently, while according to the standard, but are not compatible with each other. And if no one has problems with the basic call, then there are always plenty of questions with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. A station usually supports no more than 20, our SBC supports more than 80. And if you require that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case. And if a competitor finds out that someone is making a new feature, naturally he does the same, though in his own way he standardizes his version of the implementation of this function and naturally standardizes it. As a result, the world receives two excellent stations with the same function, which work differently, while according to the standard, but are not compatible with each other. And if no one has problems with the basic call, then there are always plenty of questions with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. A station usually supports no more than 20, our SBC supports more than 80. And if you require that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case. In its own way, it standardizes its version of the implementation of this function and, naturally, standardizes it. As a result, the world receives two excellent stations with the same function, which work differently, while according to the standard, but are not compatible with each other. And if no one has problems with the basic call, then there are always plenty of questions with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. A station usually supports no more than 20, our SBC supports more than 80. And if you require that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case. In its own way, it standardizes its version of the implementation of this function and, naturally, standardizes it. As a result, the world receives two excellent stations with the same function, which work differently, while according to the standard, but are not compatible with each other. And if no one has problems with the basic call, then there are always plenty of questions with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. A station usually supports no more than 20, our SBC supports more than 80. And if you require that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case. And if no one has problems with the basic call, then there are always plenty of questions with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. A station usually supports no more than 20, our SBC supports more than 80. And if you require that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case. And if no one has problems with the basic call, then there are always plenty of questions with SIP extensions. For statistics, there are currently over 100 RFC extensions for SIP in the world. A station usually supports no more than 20, our SBC supports more than 80. And if you require that you can use all your functionality when working with a telecom operator, then SBC is simply necessary in this case.
And compatibility is affected by that same security. And not your safety, but the safety of a telecom operator. As a rule, an operator has its own SBC and in most cases it has clear and understandable message / field / function filters when working with a client. I will give two simple and clear examples:
a. The IP PBX uses SIP Refer to transfer the call (this is when the station tells the higher station that you are transferring the call to an external subscriber, and let the higher station connect to each other. Everything is fine, but here's the point - who should be billed. The operator in this case should close the call between the two non-subscribers. The bill must be billed to you, but there wasn’t a call with you. For this reason, the operator simply blocks this functionality (and does it right). SBC in this case takes care of the call switching and working off from REFER messages and for the operator two calls are displayed (incoming and outgoing), and everything works fine.
b. Call Forwarding For example: Subscriber A called subscriber B, who is forwarding to subscriber B. And here the call goes from subscriber B to subscriber B, while the number A is displayed as the number of the caller. And this is correct, since the calling number is number A, not the one that redirects. This is the telephone standard. And if in ISDN (E1) all this is clearly described, since there is a Redirect number field, then in SIP number B for correct identification can be transmitted using History-Info, Referred-By, Diversion. And on this basis, operators simply like to block such numbers, referring to the fact that their billing does not work correctly. That is, the carrier’s billing is contrary to the SIP standard or the operator simply does not want to accept forwarded calls according to the standard.
The remaining examples are not so common, but no less important, since the less often they occur, the more difficult it is to solve them using standard telephone exchange methods. Separately, I want to talk about compatibility issues and adaptation of voice codecs. The time has passed when everyone supported the G.711 and G.729 codecs, and that’s enough. There are a lot of reasons for this, and most importantly, PBX manufacturers are striving to improve the quality of communication using their own codecs or specialized codecs, such as SILK / OPUS / MS-RTA. Here the reason is simple (especially if we are talking about a unified communications system) - now all companies are striving to make telephony not only on an IP phone (which can be allocated in a separate VLAN and give traffic priority), but also to make telephony everywhere - on tablets, laptops, smartphones via WiFi, public Internet.
This is where SBC helps you use the codec that is required on your network, and connect to the operator using the one that it supports.
Separately, there is the issue of DTMF and faxes, which no one canceled in the VoIP environment. I do not want to delve into this topic, I can only say that we currently support all transmission options for both DTMF and faxes.
In fact, you can write about compatibility for a long time and you can even make separate articles on how to solve a particular problem using our SBC. But in any case, even if your operator says that he will achieve full compatibility with you, the operator does not always achieve this and the timing for setting this compatibility is always long. SBC allows you to reduce risks and reduce connection costs.
3. Assurance and quality control
Well, in conclusion, I’ll write a little about quality assurance and quality control:
a. Quality assurance - first of all, it is work with voice codecs.
b. Quality Control - SBC monitors all calls for a variety of parameters, such as Echo / Delay / Packet Loss / Jitter / MoS, and when you have a problem, you immediately clearly and quickly understand which side and for what reason communication deterioration occurred, thereby reducing deadlines for correcting problems. SBC also allows you to independently re-route if there is a drop in the quality of communication with one operator. This will save call quality without external intervention.
Also, an important factor in terms of quality assurance is the correct routing setup with the ability to balance and reserve routes. Including, if you have a backup junction with the Internet, then it should be included, including for VoIP, regardless of the network equipment settings.
I can’t say that these are all the functions and tasks that the Session Border Controller (SBC) performs, especially since everything is extremely difficult to list. I would even say that, from the point of view of safety, compatibility and quality, there are simply no universal recipes and sometimes each connection is unique and special. Our task here is to provide the maximum number of possibilities so that your use of VoIP meets all your business requirements for an IP telephony system.