Why do you need SBC on the border
In this article we will try to collect and summarize the basic data and facts known to the wide and narrow public about why the Border Session Controller (SBC) is needed for operators and corporate customers. A banal query in search engines gives out not so much information and it does not always claim to be simple and accessible.
The growing interest in application virtualization and network functionality only adds to questions like "is it possible to deploy SBC in a virtual environment and not lose in functionality."
As the name implies, SBC (Session Border Controller, Session Border Controller) is an equipment (or software) installed at the edge of the networks and controlling something.
The control that SBC provides is primarily concerned with voice traffic (signal and media), whose volumes are growing due to the transition from TDM to IP, which is gaining momentum from day to day. Immediately, we note that this type of equipment has nothing in common with firewalls and security systems operating at the IP level in conventional SPD networks. Rather, on the contrary, it complements and covers those areas where even the most advanced firewall will not be able to control anything and, all the more, will not protect it.
')
To begin with, and in order to simplify the understanding of the tasks that SBC solves, I would like to remind readers that in the packet voice topic, information about the IP addresses of finite elements involved in establishing a connection is in several (different) places of the signaling message. Those. it is not only an IP address on the third level, but also on higher levels, and not in one place, and not only in the headers of packets and messages. From this it follows that the equipment controlling voice type of traffic should know, understand and analyze all the specifics of packet voice transmission at all levels, starting from the third (IP).
Let us proceed to the consideration of the main functional tasks of the SBC. After each voiced task I will give a brief explanation.
1. Hiding the internal topology of your network from the outside world.
Internal topology is any information about network settings (IP addresses), devices and software versions, voice traffic paths, the use of address translation (NAT), etc. To exclude questions and surprise, which is usually experienced by top-level operators and corporate customers, I paraphrase this way: yes, such delicate information about your internal network infrastructure, in part or in full, can be obtained quite easily by simply analyzing voice traffic using free channels traffic congestion. This is not a joke at all. Such information is easily collected bit by bit from different fields and headers of messages from the signal and media voice traffic. Some of the customer’s engineering services at this stage successfully parry: our network devices (CPE, routers, etc., etc.) use the ALG (Application Layer Gateway) functionality, which helps us with these problems. This is partly true, but only in a very small part. To complete the discussion of the various ALGs that, based on my many years of experience in batch voice, often only add problems in normal traffic transmission, I’ll give a simple comparison table for ALG and SBC.
It can be seen that the SBC performs a complete analysis of all information packets at any level and should be able to process voice traffic in such a way as to exclude the transfer of sensitive information out to any joints.
Now we will go further, discussing only SBC and deleting all sorts of ALGs from consideration.
2. Separation of trusted (internal) and untrusted (external) networks across different physical network interfaces (separation of networks at the physical level)
Protection of information transfer is not only setting up various filters, access sheets and other rules for processing and analyzing traffic. In most applications, physical separation of the internal and external networks is recommended by distributing the joints across different physical interfaces. Often the number of such interfaces exceeds two and is determined depending on the switching circuit. As a rule, it makes sense to at least talk about the separation of internal and external traffic, as well as management traffic, across different physical interfaces.
3. Network security
Hiding a topology is only one of many aspects that we have to talk about during the discussion of the topic of protecting voice networks. In most cases, if not always, the question of organizing the right security strategy comes up against a standard dilemma — protect the network and not harm the service / business. You can clamp into strict rules of processing and analysis of any traffic, the main thing is to ensure a reasonable and correct operation of all services and not allow the subscriber / customer to go to your competitor, who has set up his network more competently and provided an opportunity to use an expanded set of services. I mention this here because in practice quite often there are network administrators who do not observe such a balance either because of insufficient knowledge or because of insufficient attention to this issue. Yes, and we must honestly admit that there are not so many professionals in the field of voice transmission.
I will outline the main points that you should pay attention to when addressing protection issues.
a) Protection against hacking
This is the very first thing that comes to mind when discussing protection issues. I will list from simple to complex a few moments that are used very often during hacking.
Probably enough to understand the seriousness of the problem. Any normal SBC should know and be able to deal with the above and not only with this. And without a detailed analysis of voice traffic, such a struggle is meaningless. We must understand that the network administrator must know how to properly configure the SBC to work correctly. For this, in addition to knowledge, there should be all opportunities on the SBC to tune the masses of various criteria, for example, the number of unsuccessful registration attempts, the detection of suspicious traffic (not only the above points, but for example, analysis of the length of SIP messages) and much more.
b) DoS / DDoS VoIP attacks
You can easily unprotected voice equipment, you just need desire. And believe me, there are plenty of ways to do this, even if a super-duper date firewall is used. Again, the problem is that no SPD-shnoy equipment will not protect, for example, from the insane number of registrations sent on behalf of the correct and legitimate subscriber. Or from the incredible number of attempts to establish a call to a legitimate subscriber. And the whole thing is that any firewall MUST pass all this traffic without restrictions, because it is meant for an absolutely legitimate subscriber, and therefore must be processed.
Here are just a small part of the criteria that can be analyzed: the number of registration attempts per second, the number of conversations sent per second exceeded, simultaneous set calls per second, or call set-up attempts per second. Or, for example, less obvious things: the band occupied by a particular subscriber (counting and limiting a band by the number of simultaneous conversations has long ceased to be correct, especially with the advent of adaptive codecs that can change the occupied band during a conversation, without re-coordinating media information).
c) Invalid voice packets
By sending incorrect voice packets one can understand several different unpleasant moments, for example:
- sending a long packet and an alarm message;
- formation of long fields and values ​​of the headers of signaling messages;
- attempts to break in (and subsequently redirect traffic to the wrong place) in the established signaling session, replacing packets from a legitimate subscriber with third-party, but also legitimate packets;
- sending alarm messages in a modified order
I think it is not necessary to clarify that all these and some other troubles can be costly, because they can lead to unstable, incorrect operation of the voice service, or to a loss of performance at all.
d) Incorrect, but do not violate SIP messages
Again, with a regular firewall, such packets and messages should be freely missed, since they can be sent to the correct resolved addresses, and can be addressed to legitimate subscribers. However, it can cause harm and inconvenience to the operator, because it can affect the serviceability of the service.
e) Calls for unregistered subscribers
From the foregoing, it becomes clear that by banal selection and with allowed calls to unregistered users, it becomes easy for the operator to “drain” traffic at the expense of the operator. The comic situation is that there are quite a few decisions that claim to be serious and allow you to do such things. The tragedy of the situation is that many use such "solutions" in themselves, putting themselves at extreme risk.
f) Ability to set arbitrary rules for analysis and verification (traffic classification)
A normal SBC should be able and able to customize not only the patterned traffic analysis rules that are often used, but also any reasonable "want / checkers". As an example, by slightly exaggerating, I will give this “idiotic” verification rule: if an incoming INVITE contains more than two Via headers, and the third Via header contains an IP address of the form 172.x. 100, while the From field in the user part has set of letters XYZ, then allow (or deny) the processing of such traffic. I hope it is clear that this possibility adds flexibility when using SBC.
g) Dynamic black / white lists and access lists
Pretty standard functionality. The SBC must be able to analyze traffic and “automatically” determine its legitimacy. Any suspicious traffic that does not meet the specified criteria is blocked. Ideally, protection should be supported by custom criteria, for example, the number of unsuccessful registration attempts, the number of registration attempts per second, the number of packets sent per second is exceeded, the detection of suspicious traffic (for example, the length of SIP messages, attempts to fake SIP messages and wedging into previously active) SIP session)
h) Static black / white lists and access lists
Well, what about without it? Example: you have detected malignant traffic that is characteristic and harmful to your network. For example, because your administrator “forgot” or did not think to configure and set the behavior of the SBC for some scenario. For quick blocking, just close the evil stream, all at once, possibly with some of the useful traffic. And then you start thinking and creating the very rule that was missing.
Surely you can cite many more examples and tasks related to the topic of protection. We considered the most basic. For most situations, the SBC features described should suffice.
4. Manipulation with SIP headers, manipulation with SDP
The ability to modify messages going through SBC is important. As the simplest example describing the need, let us recall what we have already discussed above - hiding the internal network topology. Modification of the signaling messages at the SDP level allows you to remove from the headers information that does not need to shine out. Another example is the need to add or change information in signal messages, on which the serviceability of a service depends. Recall that in SIP there are such services that can technically work using various methods. And on the other side of your SIP trunk, the method may differ from what is used on your network. Therefore, the modification of the required fields allows you to ensure the performance of identical services that work differently.
In addition to the above, it remains to say that the functionality to modify signaling messages relates not only to the headers and contents of SIP messages, but also to the SDP parts of these messages. This is important because the correctness of the negotiation and the operability of the transmission of media traffic directly depend on SDP.
5. Normalization of SIP
Different SIP clients, the number of which is infinitely large, may have their own characteristics of work. Often these features lie in the fact that these clients use non-standard or incorrectly formed headers and parameters of SIP messages. Normalization of SIP messages when passing through SBC implies bringing the basic and mandatory SIP headers to a standard form. This means work stabilization when using different SIP clients.
6. Ensuring the work of subscribers for NAT (NAT Traversal)
This topic deserves special attention. Firstly, because the use and the prevalence of the services of so-called virtual PBXs has increased significantly. Secondly, in the overwhelming majority of cases, the provision of voice services to retail subscribers (individuals) occurs according to a scheme with the registration of subscribers in the core of the voice network. The core is the equipment that provides voice services (softswitches, SIP servers, IMS, etc.). Registration of SIP-clients in such inclusion schemes in the overwhelming majority of cases is performed from devices (routers, CPE, wifi access points, etc.), or because of devices that have the address translation function enabled, because the SIP client has private non-routable addresses like 192.168.xx and others. Thus, NAT in such schemes cannot be called a method that simplifies the provision of voice services. Because address translation occurs at the IP level, leaving addresses unchanged at higher levels. And the coordination and passage of SIP signaling from the final SIP client to the network core in such cases is subject to difficulties. And besides the signaling traffic, there is also a media one. And the IP addresses of the media traffic are transmitted where no NAT can replace them, and not every ALG can. This will result in media traffic being routed to non-routable addresses. The consequences are obvious and extremely undesirable - one-sided audibility at least, not to mention other, less obvious features and consequences of the work of NAT. Therefore, the ability of SBC to solve such problems is extremely important. And it is important that these problems are ideally solved automatically, without requiring an individual approach in the settings for each specific subscriber SIP connection.
7. Compatible with any third-party solutions.
This has already been mentioned above. Connections and interconnection with external networks are predicted to deal with SIP signaling negotiation. Well, if only because, despite the fact that SIP is called a standard, no one has legislatively canceled the free interpretation of RFC documents by different manufacturers. Well, remember that the very "varieties" of the SIP RFC now number more than eighty. Now it will surely become clearer what is meant by compatibility. Combining and the ability to pair equipment from different manufacturers often becomes difficult or impossible task. To cope with such tasks can not all SBC, but only the most advanced.
8. Interworking with networks with SS7 (support SIP-I / SIP-T)
Also an important topic. Especially now, when the possibility of organizing direct inter-operator connections using SIP is becoming increasingly available. Yes, and when connecting corporate clients, the topic also remains very relevant, since it requires the conversion of SIP-I into regular SIP.
Here we are talking about the ability to handle SIP traffic, in which the SSD-7 signaling context is transmitted in the SDP part, which can significantly affect the correctness of some services, such as transfers / forwards, or even the passage of the basic call at the border of two operators. To correctly solve these problems, it requires the possibility of modifying some fields in the SDP portion during a transit call, or the correct conversion of SIP-I into regular SIP. And this is exactly the functionality of professional SBC, especially if we recall the number of different options and ISUP signaling standards. And it is just about it that we are talking about when we talk about the transfer of the context of SS-7 through SIP.
9. SIPREC to interface with external traffic recording system
It seems like everything is simple. There are tasks when you need to record conversations. Immediately make a reservation that this is not SORM (although it can sometimes be used as a workaround for SORM). This is a record of conversations. And here we are talking about the interface with specialized systems and solutions that perform such a task. It is performed using the Session Recording Protocol (SIPREC). Details can be found here .
This topic is important for business tasks. The difficulty is that in the tasks of recording sessions there are unique requirements that are not solved in the existing specifications of the SIP protocol. We are talking about some technical features of the implementation of solutions, as well as security issues and the preservation of personal data. In addition, there is a requirement to notify the subscriber that his conversation is recorded. To solve all these questions, SIPREC was developed. Far from all.
10. Separation of traffic types on various interfaces.
Wrote a little about it. We formulate differently. Implementation options can be many. Separating external and internal traffic across different physical interfaces is only a part. Sometimes it is necessary that a different type of traffic be divided across different physical interfaces. For example, the alarm on one, the media on the other, control on the third. Or maybe you need to combine. In general, there are many options. Full support adds flexibility.
11. Ensuring IPv4 <-> IPv6 Interoperability
Everything seems to be simple, no special comments are required. The introduction of IPv6 is already there, the farther, the more. Since SBC is on the edge of voice networks, then it is its direct responsibility to perform the conversion.
12. Transcoding
The topic is big and actually very important. Much depends on this functionality. In most cases, transcoding means only the conversion of one voice codec to another. However, this is only the top of the iceberg. Under the water is hidden significantly more. If we talk about virtual solutions, then when discussing transcoding issues, you need to simultaneously discuss the performance of hardware servers.
a) TCP <-> UDP conversion, TCP <-> TLS, UDP <-> TLS, dynamic change of the transport layer protocol.
SIP does not support only UDP. There are other options. At the junction of networks, quite often there is a problem of such conversion. And of course, it’s convenient if it is performed not only in a fixed configuration, which is most often encountered when connecting a SIP trunk, but also dynamically. Well, imagine at least the subscribers that are registered on your voice platform. Some use UDP, others use TCP or even TLS. How do you understand in advance how to deal with a specific subscriber? Of course it is better to perform this task dynamically.
b) RTP <-> SRTP conversion
Here, too, is clear and quite common. Converting RTP to SRTP and vice versa is definitely needed.
c) T.38 Conversion <-> G.711
Classics of the genre. Long and long shouting all about the death of a facsimile. But this is far from reality. This type of communication has been used and continues to be used. Of course, modern systems already in most cases save paper and send a fax to e-mail as a file. But this does not change the fax transmission mechanism. The two most common transmission formats are incompatible with each other and a conversion is required if two subscribers send a fax to each other using different methods.
d) DTMF Transcoding (RFC2833 <-> inband <-> SIP INFO)
Also a classic problem. DTMF signals can be transmitted in different ways. It depends on the settings and capabilities / functionality of the specific subscriber equipment and voice solution that provides the final service. But the fact that DTMF should go from end to end. And what is the path and what method is used, this is a sore point. Conversion between different methods is crucial.
e) Codec Transcoding
The modern world of telecom is moving forward very quickly. Well, here is an example of some types of codecs that are quite common recently:
G.723; G.729; G.728; NETCODER; GSM-FR; GSM-EFR; AMR; EVRC-QCELP; G.727; ILBC; EVRC-B; AMR-WB; G.722; EG.711; MS_RTA; SILK; SPEEX; OPUS.
At the inter-operator interface, the issue of transcoding is mainly limited to G.711 and G.729 transcoding, although there are more exotic cases. But when connecting corporate customers or small operators, there is often a very difficult task related to the use of so-called “heavy” codecs that are used in specific services and services. The use of modern web services or some mobile applications also involves the use of codecs that are different from the standard ones.
f) Ptime transcoding.
It would be more correct to call it differently, since there is no actual transcoding here and as such. There is a change in the packetization time within the same codec. The answer to the question "why" is very simple - saving bandwidth in the channel. For some applications, this is a very important task and is solved in this way, allowing you to save bandwidth and computing power of the equipment.
13. REST support
Many do not need it and they do not even bother about this topic. However, support for the REST API makes it possible to solve many, many tasks in a flexible and very simple way. Integration with third-party solutions, management and painless system reconfiguration is carried out very quickly and does not cause difficulties. In NFV (Network Function Virtualization) technology, the REST protocol is used by the overwhelming majority of orchestrators for the control and management of NVF elements (Network Virtual Function element).
14. WebRTC and support for so-called web codecs (for example, OPUS)
WebRTC is also a separate topic, which allows the operator to add many new modern services and capture those niches that had not even been considered before. At its core, WebRTC is a free open-project technology for making calls, videos, chats, transferring files to the Internet without installing additional equipment or software (such as a flash player, plug-ins, etc.) directly from the browser of a personal computer, using the Javascript API . Appeal and applicability is obvious. The technical implementation requires the use of a WebRTC gateway, since it does not use SIP here.
The WebRTC gateway itself is the ability to terminate WebRTC traffic and convert it from WebSocket (replacing HTTP) into regular SIP. And the transmission of media traffic requires media proxying, since two subscribers behind symmetric NAT will not be able to talk to each other.But such a gateway does not fulfill the tasks of ensuring the security of such conversion, and also does not solve the tasks of protecting against DoS / DDoS attacks, applying different policies, Call Admission Control, accoutnting, billing, tracing, diagnosing, and much more. Therefore, this task falls on the shoulders of SBC. Those.the SBC itself must have the built-in functionality of the WebRTC gateway. Well, OPUS support, since this codec is primary for use in WebRTC. Of course, let's not forget G.711, it is also specified for use. But in practice it does not apply, because it does not provide any quality on the open Internet, it is too susceptible to packet loss and other parameters that determine voice quality.
15. Routing SIP traffic based on IP addresses, A and B numbers, time of day, equipment availability, cost of traffic minutes, etc. and so on
The need to perform flexible routing on the SBC can be talked about for a long time. It is needed, and the more flexible the possibilities, the greater the benefits for the operator, especially for those who use I-SBC for peering. For A-SBC, the flexible routing task is also important, especially in the case of virtual PBX services.
16. Possibility of rerouting traffic based on the response of the terminal equipment
This task was singled out separately; it is critical for I-SBC when peering.
17. QoS to prioritize traffic on a specific IP direction or for a specific user / client
Functionality also, in my opinion, does not require detailed description and discussion. Connected customers and operators have the right to care about quality and are often asked to provide it. And some, so generally require reports on the quality of transmitted traffic. As a result, the one who has the highest quality wins.
Ideally, of course, he wins, whose SBC is able to maintain statistics on the quality of any call that he processed. These parameters are jitter, packet loss, delay, echo, MOS, reasons for terminating a call, initiator for terminating a call, and much more. In other words, the SBC simultaneously acts as a traffic probe on the network.
18. Call Admission Control, restrictions on the number of sessions, bandwidth, and other parameters.
Well, this functionality very often borders on the task of saving money. Well, because it is necessary and important to control the resources of your solution, practically competently and efficiently limiting your customer or subscriber from “absorbing” all or most of the available resources, limiting and controlling the network core load (SIP server, softswitch, etc.)
19 Traffic balancing (load balancing)
Functionality is important when the complexity of the network allows you to organize and build flexible schemes for the processing of services and traffic. And working in both directions. Someone, for example, has backup channels and their use is welcome for organizing not only fault-tolerant schemes, but also for distributing the load on the network or distributing services among the core network elements.
20. Collecting and storing CDRs
Everything is clear too. SBC, as it stands on the edge of the network, can also be used as a billing point or a junction with the billing system. It is important to understand that the most preferred is the text format of CDR records.
21. The ability to provide simultaneous traffic processing for access modes (access with registration for services such as virtual PBX) and peering (providing interface over SIP trunks)
You can often find such a limitation when the SBC can work only in one mode. Or only peering, or only on access. Sometimes the use of only one of the modes is actually due to the scheme and the task of using SBC. But the ability to work in only one mode imposes significant restrictions on the planning and operation of services on the network, forcing to buy a second device to implement the full scheme for the simultaneous use of SIP trunks and subscriber traffic with the registration of subscribers on the SIP server. Therefore, the ability to work simultaneously in two modes is important.
Since at the very beginning of the article the trend towards virtualization is mentioned, let's immediately say that everything described in the article also applies to virtual solutions. Thus, the question of the ability of virtual SBCs to replace special hardware systems should disappear by itself. Of course, there are some subtle points in this question, I am planning a separate article on this subject.
The growing interest in application virtualization and network functionality only adds to questions like "is it possible to deploy SBC in a virtual environment and not lose in functionality."
As the name implies, SBC (Session Border Controller, Session Border Controller) is an equipment (or software) installed at the edge of the networks and controlling something.
The control that SBC provides is primarily concerned with voice traffic (signal and media), whose volumes are growing due to the transition from TDM to IP, which is gaining momentum from day to day. Immediately, we note that this type of equipment has nothing in common with firewalls and security systems operating at the IP level in conventional SPD networks. Rather, on the contrary, it complements and covers those areas where even the most advanced firewall will not be able to control anything and, all the more, will not protect it.
')
To begin with, and in order to simplify the understanding of the tasks that SBC solves, I would like to remind readers that in the packet voice topic, information about the IP addresses of finite elements involved in establishing a connection is in several (different) places of the signaling message. Those. it is not only an IP address on the third level, but also on higher levels, and not in one place, and not only in the headers of packets and messages. From this it follows that the equipment controlling voice type of traffic should know, understand and analyze all the specifics of packet voice transmission at all levels, starting from the third (IP).
Let us proceed to the consideration of the main functional tasks of the SBC. After each voiced task I will give a brief explanation.
1. Hiding the internal topology of your network from the outside world.
Internal topology is any information about network settings (IP addresses), devices and software versions, voice traffic paths, the use of address translation (NAT), etc. To exclude questions and surprise, which is usually experienced by top-level operators and corporate customers, I paraphrase this way: yes, such delicate information about your internal network infrastructure, in part or in full, can be obtained quite easily by simply analyzing voice traffic using free channels traffic congestion. This is not a joke at all. Such information is easily collected bit by bit from different fields and headers of messages from the signal and media voice traffic. Some of the customer’s engineering services at this stage successfully parry: our network devices (CPE, routers, etc., etc.) use the ALG (Application Layer Gateway) functionality, which helps us with these problems. This is partly true, but only in a very small part. To complete the discussion of the various ALGs that, based on my many years of experience in batch voice, often only add problems in normal traffic transmission, I’ll give a simple comparison table for ALG and SBC.
It can be seen that the SBC performs a complete analysis of all information packets at any level and should be able to process voice traffic in such a way as to exclude the transfer of sensitive information out to any joints.
Now we will go further, discussing only SBC and deleting all sorts of ALGs from consideration.
2. Separation of trusted (internal) and untrusted (external) networks across different physical network interfaces (separation of networks at the physical level)
Protection of information transfer is not only setting up various filters, access sheets and other rules for processing and analyzing traffic. In most applications, physical separation of the internal and external networks is recommended by distributing the joints across different physical interfaces. Often the number of such interfaces exceeds two and is determined depending on the switching circuit. As a rule, it makes sense to at least talk about the separation of internal and external traffic, as well as management traffic, across different physical interfaces.
3. Network security
Hiding a topology is only one of many aspects that we have to talk about during the discussion of the topic of protecting voice networks. In most cases, if not always, the question of organizing the right security strategy comes up against a standard dilemma — protect the network and not harm the service / business. You can clamp into strict rules of processing and analysis of any traffic, the main thing is to ensure a reasonable and correct operation of all services and not allow the subscriber / customer to go to your competitor, who has set up his network more competently and provided an opportunity to use an expanded set of services. I mention this here because in practice quite often there are network administrators who do not observe such a balance either because of insufficient knowledge or because of insufficient attention to this issue. Yes, and we must honestly admit that there are not so many professionals in the field of voice transmission.
I will outline the main points that you should pay attention to when addressing protection issues.
a) Protection against hacking
This is the very first thing that comes to mind when discussing protection issues. I will list from simple to complex a few moments that are used very often during hacking.
- Banal scanning of ports used, with specialized scanners of voice applications and solutions;
- check your equipment’s responses to standard signaling messages in order to find out details about your network (even minimal data is enough to determine the next step in cracking);
- identification of certain types of services (for example, call forwarding);
- selection of SIP usernames and passwords;
- network traffic scanning and packet analysis;
- call attempts on behalf of registered / unregistered subscribers;
- spoofing (disguise as a legitimate subscriber);
- replacing trusted packages and trying to get into an established legitimate session.
Probably enough to understand the seriousness of the problem. Any normal SBC should know and be able to deal with the above and not only with this. And without a detailed analysis of voice traffic, such a struggle is meaningless. We must understand that the network administrator must know how to properly configure the SBC to work correctly. For this, in addition to knowledge, there should be all opportunities on the SBC to tune the masses of various criteria, for example, the number of unsuccessful registration attempts, the detection of suspicious traffic (not only the above points, but for example, analysis of the length of SIP messages) and much more.
b) DoS / DDoS VoIP attacks
You can easily unprotected voice equipment, you just need desire. And believe me, there are plenty of ways to do this, even if a super-duper date firewall is used. Again, the problem is that no SPD-shnoy equipment will not protect, for example, from the insane number of registrations sent on behalf of the correct and legitimate subscriber. Or from the incredible number of attempts to establish a call to a legitimate subscriber. And the whole thing is that any firewall MUST pass all this traffic without restrictions, because it is meant for an absolutely legitimate subscriber, and therefore must be processed.
Here are just a small part of the criteria that can be analyzed: the number of registration attempts per second, the number of conversations sent per second exceeded, simultaneous set calls per second, or call set-up attempts per second. Or, for example, less obvious things: the band occupied by a particular subscriber (counting and limiting a band by the number of simultaneous conversations has long ceased to be correct, especially with the advent of adaptive codecs that can change the occupied band during a conversation, without re-coordinating media information).
c) Invalid voice packets
By sending incorrect voice packets one can understand several different unpleasant moments, for example:
- sending a long packet and an alarm message;
- formation of long fields and values ​​of the headers of signaling messages;
- attempts to break in (and subsequently redirect traffic to the wrong place) in the established signaling session, replacing packets from a legitimate subscriber with third-party, but also legitimate packets;
- sending alarm messages in a modified order
I think it is not necessary to clarify that all these and some other troubles can be costly, because they can lead to unstable, incorrect operation of the voice service, or to a loss of performance at all.
d) Incorrect, but do not violate SIP messages
Again, with a regular firewall, such packets and messages should be freely missed, since they can be sent to the correct resolved addresses, and can be addressed to legitimate subscribers. However, it can cause harm and inconvenience to the operator, because it can affect the serviceability of the service.
e) Calls for unregistered subscribers
From the foregoing, it becomes clear that by banal selection and with allowed calls to unregistered users, it becomes easy for the operator to “drain” traffic at the expense of the operator. The comic situation is that there are quite a few decisions that claim to be serious and allow you to do such things. The tragedy of the situation is that many use such "solutions" in themselves, putting themselves at extreme risk.
f) Ability to set arbitrary rules for analysis and verification (traffic classification)
A normal SBC should be able and able to customize not only the patterned traffic analysis rules that are often used, but also any reasonable "want / checkers". As an example, by slightly exaggerating, I will give this “idiotic” verification rule: if an incoming INVITE contains more than two Via headers, and the third Via header contains an IP address of the form 172.x. 100, while the From field in the user part has set of letters XYZ, then allow (or deny) the processing of such traffic. I hope it is clear that this possibility adds flexibility when using SBC.
g) Dynamic black / white lists and access lists
Pretty standard functionality. The SBC must be able to analyze traffic and “automatically” determine its legitimacy. Any suspicious traffic that does not meet the specified criteria is blocked. Ideally, protection should be supported by custom criteria, for example, the number of unsuccessful registration attempts, the number of registration attempts per second, the number of packets sent per second is exceeded, the detection of suspicious traffic (for example, the length of SIP messages, attempts to fake SIP messages and wedging into previously active) SIP session)
h) Static black / white lists and access lists
Well, what about without it? Example: you have detected malignant traffic that is characteristic and harmful to your network. For example, because your administrator “forgot” or did not think to configure and set the behavior of the SBC for some scenario. For quick blocking, just close the evil stream, all at once, possibly with some of the useful traffic. And then you start thinking and creating the very rule that was missing.
Surely you can cite many more examples and tasks related to the topic of protection. We considered the most basic. For most situations, the SBC features described should suffice.
4. Manipulation with SIP headers, manipulation with SDP
The ability to modify messages going through SBC is important. As the simplest example describing the need, let us recall what we have already discussed above - hiding the internal network topology. Modification of the signaling messages at the SDP level allows you to remove from the headers information that does not need to shine out. Another example is the need to add or change information in signal messages, on which the serviceability of a service depends. Recall that in SIP there are such services that can technically work using various methods. And on the other side of your SIP trunk, the method may differ from what is used on your network. Therefore, the modification of the required fields allows you to ensure the performance of identical services that work differently.
In addition to the above, it remains to say that the functionality to modify signaling messages relates not only to the headers and contents of SIP messages, but also to the SDP parts of these messages. This is important because the correctness of the negotiation and the operability of the transmission of media traffic directly depend on SDP.
5. Normalization of SIP
Different SIP clients, the number of which is infinitely large, may have their own characteristics of work. Often these features lie in the fact that these clients use non-standard or incorrectly formed headers and parameters of SIP messages. Normalization of SIP messages when passing through SBC implies bringing the basic and mandatory SIP headers to a standard form. This means work stabilization when using different SIP clients.
6. Ensuring the work of subscribers for NAT (NAT Traversal)
This topic deserves special attention. Firstly, because the use and the prevalence of the services of so-called virtual PBXs has increased significantly. Secondly, in the overwhelming majority of cases, the provision of voice services to retail subscribers (individuals) occurs according to a scheme with the registration of subscribers in the core of the voice network. The core is the equipment that provides voice services (softswitches, SIP servers, IMS, etc.). Registration of SIP-clients in such inclusion schemes in the overwhelming majority of cases is performed from devices (routers, CPE, wifi access points, etc.), or because of devices that have the address translation function enabled, because the SIP client has private non-routable addresses like 192.168.xx and others. Thus, NAT in such schemes cannot be called a method that simplifies the provision of voice services. Because address translation occurs at the IP level, leaving addresses unchanged at higher levels. And the coordination and passage of SIP signaling from the final SIP client to the network core in such cases is subject to difficulties. And besides the signaling traffic, there is also a media one. And the IP addresses of the media traffic are transmitted where no NAT can replace them, and not every ALG can. This will result in media traffic being routed to non-routable addresses. The consequences are obvious and extremely undesirable - one-sided audibility at least, not to mention other, less obvious features and consequences of the work of NAT. Therefore, the ability of SBC to solve such problems is extremely important. And it is important that these problems are ideally solved automatically, without requiring an individual approach in the settings for each specific subscriber SIP connection.
7. Compatible with any third-party solutions.
This has already been mentioned above. Connections and interconnection with external networks are predicted to deal with SIP signaling negotiation. Well, if only because, despite the fact that SIP is called a standard, no one has legislatively canceled the free interpretation of RFC documents by different manufacturers. Well, remember that the very "varieties" of the SIP RFC now number more than eighty. Now it will surely become clearer what is meant by compatibility. Combining and the ability to pair equipment from different manufacturers often becomes difficult or impossible task. To cope with such tasks can not all SBC, but only the most advanced.
8. Interworking with networks with SS7 (support SIP-I / SIP-T)
Also an important topic. Especially now, when the possibility of organizing direct inter-operator connections using SIP is becoming increasingly available. Yes, and when connecting corporate clients, the topic also remains very relevant, since it requires the conversion of SIP-I into regular SIP.
Here we are talking about the ability to handle SIP traffic, in which the SSD-7 signaling context is transmitted in the SDP part, which can significantly affect the correctness of some services, such as transfers / forwards, or even the passage of the basic call at the border of two operators. To correctly solve these problems, it requires the possibility of modifying some fields in the SDP portion during a transit call, or the correct conversion of SIP-I into regular SIP. And this is exactly the functionality of professional SBC, especially if we recall the number of different options and ISUP signaling standards. And it is just about it that we are talking about when we talk about the transfer of the context of SS-7 through SIP.
9. SIPREC to interface with external traffic recording system
It seems like everything is simple. There are tasks when you need to record conversations. Immediately make a reservation that this is not SORM (although it can sometimes be used as a workaround for SORM). This is a record of conversations. And here we are talking about the interface with specialized systems and solutions that perform such a task. It is performed using the Session Recording Protocol (SIPREC). Details can be found here .
This topic is important for business tasks. The difficulty is that in the tasks of recording sessions there are unique requirements that are not solved in the existing specifications of the SIP protocol. We are talking about some technical features of the implementation of solutions, as well as security issues and the preservation of personal data. In addition, there is a requirement to notify the subscriber that his conversation is recorded. To solve all these questions, SIPREC was developed. Far from all.
10. Separation of traffic types on various interfaces.
Wrote a little about it. We formulate differently. Implementation options can be many. Separating external and internal traffic across different physical interfaces is only a part. Sometimes it is necessary that a different type of traffic be divided across different physical interfaces. For example, the alarm on one, the media on the other, control on the third. Or maybe you need to combine. In general, there are many options. Full support adds flexibility.
11. Ensuring IPv4 <-> IPv6 Interoperability
Everything seems to be simple, no special comments are required. The introduction of IPv6 is already there, the farther, the more. Since SBC is on the edge of voice networks, then it is its direct responsibility to perform the conversion.
12. Transcoding
The topic is big and actually very important. Much depends on this functionality. In most cases, transcoding means only the conversion of one voice codec to another. However, this is only the top of the iceberg. Under the water is hidden significantly more. If we talk about virtual solutions, then when discussing transcoding issues, you need to simultaneously discuss the performance of hardware servers.
a) TCP <-> UDP conversion, TCP <-> TLS, UDP <-> TLS, dynamic change of the transport layer protocol.
SIP does not support only UDP. There are other options. At the junction of networks, quite often there is a problem of such conversion. And of course, it’s convenient if it is performed not only in a fixed configuration, which is most often encountered when connecting a SIP trunk, but also dynamically. Well, imagine at least the subscribers that are registered on your voice platform. Some use UDP, others use TCP or even TLS. How do you understand in advance how to deal with a specific subscriber? Of course it is better to perform this task dynamically.
b) RTP <-> SRTP conversion
Here, too, is clear and quite common. Converting RTP to SRTP and vice versa is definitely needed.
c) T.38 Conversion <-> G.711
Classics of the genre. Long and long shouting all about the death of a facsimile. But this is far from reality. This type of communication has been used and continues to be used. Of course, modern systems already in most cases save paper and send a fax to e-mail as a file. But this does not change the fax transmission mechanism. The two most common transmission formats are incompatible with each other and a conversion is required if two subscribers send a fax to each other using different methods.
d) DTMF Transcoding (RFC2833 <-> inband <-> SIP INFO)
Also a classic problem. DTMF signals can be transmitted in different ways. It depends on the settings and capabilities / functionality of the specific subscriber equipment and voice solution that provides the final service. But the fact that DTMF should go from end to end. And what is the path and what method is used, this is a sore point. Conversion between different methods is crucial.
e) Codec Transcoding
The modern world of telecom is moving forward very quickly. Well, here is an example of some types of codecs that are quite common recently:
G.723; G.729; G.728; NETCODER; GSM-FR; GSM-EFR; AMR; EVRC-QCELP; G.727; ILBC; EVRC-B; AMR-WB; G.722; EG.711; MS_RTA; SILK; SPEEX; OPUS.
At the inter-operator interface, the issue of transcoding is mainly limited to G.711 and G.729 transcoding, although there are more exotic cases. But when connecting corporate customers or small operators, there is often a very difficult task related to the use of so-called “heavy” codecs that are used in specific services and services. The use of modern web services or some mobile applications also involves the use of codecs that are different from the standard ones.
f) Ptime transcoding.
It would be more correct to call it differently, since there is no actual transcoding here and as such. There is a change in the packetization time within the same codec. The answer to the question "why" is very simple - saving bandwidth in the channel. For some applications, this is a very important task and is solved in this way, allowing you to save bandwidth and computing power of the equipment.
13. REST support
Many do not need it and they do not even bother about this topic. However, support for the REST API makes it possible to solve many, many tasks in a flexible and very simple way. Integration with third-party solutions, management and painless system reconfiguration is carried out very quickly and does not cause difficulties. In NFV (Network Function Virtualization) technology, the REST protocol is used by the overwhelming majority of orchestrators for the control and management of NVF elements (Network Virtual Function element).
14. WebRTC and support for so-called web codecs (for example, OPUS)
WebRTC is also a separate topic, which allows the operator to add many new modern services and capture those niches that had not even been considered before. At its core, WebRTC is a free open-project technology for making calls, videos, chats, transferring files to the Internet without installing additional equipment or software (such as a flash player, plug-ins, etc.) directly from the browser of a personal computer, using the Javascript API . Appeal and applicability is obvious. The technical implementation requires the use of a WebRTC gateway, since it does not use SIP here.
The WebRTC gateway itself is the ability to terminate WebRTC traffic and convert it from WebSocket (replacing HTTP) into regular SIP. And the transmission of media traffic requires media proxying, since two subscribers behind symmetric NAT will not be able to talk to each other.But such a gateway does not fulfill the tasks of ensuring the security of such conversion, and also does not solve the tasks of protecting against DoS / DDoS attacks, applying different policies, Call Admission Control, accoutnting, billing, tracing, diagnosing, and much more. Therefore, this task falls on the shoulders of SBC. Those.the SBC itself must have the built-in functionality of the WebRTC gateway. Well, OPUS support, since this codec is primary for use in WebRTC. Of course, let's not forget G.711, it is also specified for use. But in practice it does not apply, because it does not provide any quality on the open Internet, it is too susceptible to packet loss and other parameters that determine voice quality.
15. Routing SIP traffic based on IP addresses, A and B numbers, time of day, equipment availability, cost of traffic minutes, etc. and so on
The need to perform flexible routing on the SBC can be talked about for a long time. It is needed, and the more flexible the possibilities, the greater the benefits for the operator, especially for those who use I-SBC for peering. For A-SBC, the flexible routing task is also important, especially in the case of virtual PBX services.
16. Possibility of rerouting traffic based on the response of the terminal equipment
This task was singled out separately; it is critical for I-SBC when peering.
17. QoS to prioritize traffic on a specific IP direction or for a specific user / client
Functionality also, in my opinion, does not require detailed description and discussion. Connected customers and operators have the right to care about quality and are often asked to provide it. And some, so generally require reports on the quality of transmitted traffic. As a result, the one who has the highest quality wins.
Ideally, of course, he wins, whose SBC is able to maintain statistics on the quality of any call that he processed. These parameters are jitter, packet loss, delay, echo, MOS, reasons for terminating a call, initiator for terminating a call, and much more. In other words, the SBC simultaneously acts as a traffic probe on the network.
18. Call Admission Control, restrictions on the number of sessions, bandwidth, and other parameters.
Well, this functionality very often borders on the task of saving money. Well, because it is necessary and important to control the resources of your solution, practically competently and efficiently limiting your customer or subscriber from “absorbing” all or most of the available resources, limiting and controlling the network core load (SIP server, softswitch, etc.)
19 Traffic balancing (load balancing)
Functionality is important when the complexity of the network allows you to organize and build flexible schemes for the processing of services and traffic. And working in both directions. Someone, for example, has backup channels and their use is welcome for organizing not only fault-tolerant schemes, but also for distributing the load on the network or distributing services among the core network elements.
20. Collecting and storing CDRs
Everything is clear too. SBC, as it stands on the edge of the network, can also be used as a billing point or a junction with the billing system. It is important to understand that the most preferred is the text format of CDR records.
21. The ability to provide simultaneous traffic processing for access modes (access with registration for services such as virtual PBX) and peering (providing interface over SIP trunks)
You can often find such a limitation when the SBC can work only in one mode. Or only peering, or only on access. Sometimes the use of only one of the modes is actually due to the scheme and the task of using SBC. But the ability to work in only one mode imposes significant restrictions on the planning and operation of services on the network, forcing to buy a second device to implement the full scheme for the simultaneous use of SIP trunks and subscriber traffic with the registration of subscribers on the SIP server. Therefore, the ability to work simultaneously in two modes is important.
Since at the very beginning of the article the trend towards virtualization is mentioned, let's immediately say that everything described in the article also applies to virtual solutions. Thus, the question of the ability of virtual SBCs to replace special hardware systems should disappear by itself. Of course, there are some subtle points in this question, I am planning a separate article on this subject.
Source: https://habr.com/ru/post/335194/
All Articles