Understanding SBC User Classification
[Post is better viewed on the blog Website]
As I delve more into the nature of the SBC, I uncover additional layers of complexity that the SBC needs to address and solve. This returns me back to one of my earlier posts about the need for an SBC.
Taking a broader view makes me think about the role of standards, or more accurately, where their role ends and where the role of application specific implementation begins. This was taken to the extreme with WebRTC, something I touched upon in a post about WebRTC signaling and whether it should be standard or non-standard.
The reality is that also in “traditional” SIP communication there is a limited scope that standards can encompass. After all, the SBC wasn’t invented as a standard entity but rather as an entity that performs things in a different way than what the standards defined. It succeeded because it worked… it offered a solution for some of the major VoIP deployment roadblocks such as FW/NAT traversal. Real life experience proved that some things better stay in the application level, settling for only standardizing must-have functions, as was done correctly with WebRTC.
In this blog post I want to address one such application level functionality of the SBC. Basically, the question I wanted to answer was – “to what extent does an SBC need to take decisions based on who is the user participating in the session?”. The topic came up in one of my discussions with R&D and I decided that rather than enjoying this information by myself, I would share it on the blog.
To shed some more light on this topic, I turned to Ilan Avner. Ilan is SIP-SBC Group Leader and a VoIP Expert.
Q. To what level does the SBC take decisions based on personal user characteristics?
The identity of the user and the equipment from which he initiated the session are important factors in SBC decision process. There are SBCs that use layer 3 information for this process and don’t extend the analysis to the user level. We found this method of using a pre-defined profile based on IP address mapping to be insufficient for an enterprise environment where IP addresses of devices and users may change. Moreover, even though the analysis of the user and SIP message fields is far more complex, performing what we call “User Classification” is an indispensable part of the SBC decision process.
Q. You talked about the importance of User Classification. Can you shed some light on what exactly User Classification is and how it is used in the SBC decision process?
User Classification is a process in which users are grouped according to an array of parameters. When a SIP session is initiated and arrives at the SBC, on top of layer 3 classification there are 3 fundamental parameters of the session that help in the classification:
- The type of remote SIP server – IP-PBX, Gateway, SBC, Media Server, Proxy, etc.
- The device vendor – this is relevant both for clients and servers
- SIP user information – this is specific information about the user itself, not the device. It can be about the group of which he is part, or about the organization or related policy
Q. What are the SBC use cases of User Classifications and for what type of decisions does the SBC use this information?
Information collected and the resulting classification of the user further helps in SBC decisions such as:
- Routing and SIP message manipulations
- SLA Enforcement – Call Admission Control (CAC), QoE, bandwidth management
- Enforcing security policy
- Overcoming SIP signaling mismatches (SIP interoperability)
- Media functionality such as codec transcoding and FAX transcoding
Q. Can you give some specific examples of how user classification is implemented in the AudioCodes SBC?
The AudioCodes SBC has this classification ability built-in its basic SIP processing. Each dialog request goes through a built-in classification process, the dialog can be classified either by layer 3 parameters or by any SIP layer parameters (using a dedicated classification table), once the SIP traffic is classified the dialog is tagged as belonging to a specific SIP group, this group is then used as an input to all of the dialog processing (Routing, Manipulations, CAC, Security, SIP signaling functionality, Media functionality…).
As part of the classification process our SBC looks at various parts of the SIP message. Here are a few examples:
- Any SIP URI that appears in the SIP message (Request-URI\TO\FROM\P-Asserted\P-Preferred…)
- A list of supported codecs and capabilities (e.g. FAX support)
- Any vendor specific parameter (e.g. user agent or any X-Header)
In the above diagram we see 4 different types of SIP user agents and the classification parameters each received by the SBC. This is of course an example, the actual classification is more complex and involves additional SIP message fields. The end result of this process is the tagging of each session and users associated with it, thus allowing for different SDP negotiation and SIP message exchange manipulation.
SBCs are required to perform complex decision processes per session and should, therefore, use every piece of information available including user specific data. This logic can’t be part of the standard but rather the application and therefore is part of the differentiation between SBCs available on the market.