2.4. ABC SBC Networking Concepts

This section provides an overview of the main concepts and terms of the ABC SBC. It shows the overall model of SBC-managed networks, how the SBC connects to the individual networks using “Interfaces”, models SIP devices as “Call Agents”, and groups these in “Realms”. Eventually A-B-C rules are described that define how the ABC SBC manages SIP traffic as it passes through it.

2.4.1. Network Topology

As depicted in the Figure ABC SBC Concepts Overview, the ABC SBC communicates with VoIP phones, media servers and other entities that act as SIP user agent. We call these entities Call Agents (CA) and group them into so called Realms. The ABC SBC associates rules with Call Agents and Realms. These rules fully describe how every single session traversing the ABC SBC from one CA/Realm to another is processed.

The rule processing occurs in three steps. When receiving a SIP message from a Call Agent, the ABC SBC will first execute inbound rules (“A-Rules”) associated with the Call Agent and the Realm it belongs to. These rules typically implement all kinds of admission control. Once the message is accepted the ABC SBC applies routing rules (“B-Rules”) to determine the Call Agent where to send the message to. Before actually forwarding the message to the destination, the ABC SBC executes its outbound “C-rules”. The C-Rules are typically used to transform the SIP messages to conform to practices used by the destination, such as local specific dialing conventions.

_images/10000201000008470000020C2522F873.png

Figure 1: ABC SBC Concepts Overview

2.4.2. SBC Interfaces

SBC Interfaces define how the ABC SBC connects to the adjacent IP networks. They are are an abstraction layer on top of the network interfaces. Specifically, the SBC Interfaces define through which IP addresses, port numbers and network interfaces the ABC SBC offers its services.

There are the following types of SBC interfaces:

  • Internal management (IMI): used in high availability (HA) and cluster setups as the communication channel between the SBC node servers.
  • External management (XMI): used for maintenance access (graphical user interface, ABC Monitor access, etc...)
  • Media (MI): used for receiving and sending media payload.
  • Signalling (SI): used for receiving and sending SIP signalling messages.
  • Websocket Signaling (WS): used for receving and sending SIP over websocket from and to WebRTC clients.

Each of the SBC interfaces is mapped to a physical or system network interface that is used for the actual sending and receiving of the data. Multiple SBC interfaces can be mapped to the same network interface. If VLANs are used, they are administered under management of physical interfaces and remain otherwise transparent to the rest of the system.

Administration of the SBC interfaces is described in the Section Interface Configuration.

2.4.3. Call Agents

Call Agents (CA) are the smallest type of peering entities the ABC SBC can differentiate. They represent logical end-points. They can be defined based on several addressing mechanisms:

  • IP address and port
  • Host name and port
  • IP network and mask

Additionally, a Call Agent is assigned to a signalling and a media interface. These interfaces are used whenever SIP signalling or media packets are sent to or received from a Call Agent.

For security reasons, the SBC communicates by default only with well-known and defined Call Agents. When an incoming SIP request cannot be attributed to a Call Agent, it is rejected.

To determine the source Call Agent, the SBC uses the source IP address and port of the request to search among the configured Call Agents. If the definitions of Call Agents are overlapping (for example when some Call Agents are defined with an IP address which belongs to a subnet used to define another Call Agent), the following descending order is used to determine the Call Agent:

  • Call Agents with matching IP address and port.
  • Call Agents with matching IP address but a port equal to 0.
  • Call Agents with matching IP network (including mask) in descending order of mask length

Please note that Call Agents defined by host name and port are not considered while searching for a source call agent.

Routing rules determine the target Call Agent. In this case, the interface used to send the SIP signalling is the one assigned to the target Call Agent. In case media relay is used, the media interface assigned to this target Call Agent is also used accordingly. The target Call Agent is used to determine the set of applicable rules on the outbound side as well. Note that Call Agents specified by subnet address cannot be used for routing.

2.4.4. Realms

Every Call Agent belongs to one Realm. Realms are the logical groupings of one or more Call Agents. They allow multiple Call Agents to share the same SIP processing logic without defining it individually multiple times.

In a classical context where the SBC is placed on the border of an internal network, it is common to define one Realm for the outside world, and one for the internal network. This way, all the restrictive rules to protect the internal network are defined for the outside Realm, while the internal one can be safely trusted.

In a peering use case, usually one Realm per peering partner is defined.

2.4.5. A-B-C rules

The ABC SBC is fundamentally rules driven. This means that almost all features can be activated based on certain conditions evaluated at run-time, based on parts of the signalling messages or media payload.

All rules are constructed using the same pattern. They consist of a set of one or more conditions. If all conditions apply (logical conjunction), a set of one or more actions is executed.

It is important to understand that rules are generally applied only on dialog-initiating requests or out-of-dialog requests. However, some actions have a scope that goes beyond these dialog-initiating requests or out-of-dialog requests. For example, header filters apply to all requests exchanged, including in-dialog requests. Action descriptions include their scopes where applicable.

There are three types of rules that are always executed in the same order: A, B, and C. A-rules describe how incoming traffic for a Call Agent/Realm is handled, B-rules determine destination for the SIP request, and C-rules describe SIP processing behaviour specific to that chosen destination.

A and C rules are associated with Call Agents and/or Realms. The realm rules allow to have shared logic for all Call Agents that are to be handled the same way, while CA rules are suitable for individual logic. Often, rules are associated with both Realms and Call Agents. The Realm rules are executed first, and their results can be overridden by more specific Call Agent Rules.

B rules are different in that they are global. They are not associated with a specific realm or call agent. When processing of A-rules completes, the B-rules determine the next hop. That’s is the only action the B-rules can perform. Then Realm and Call Agent specific C-rules are processed.

The FRAFOS ABC SBC handles calls according to the schema shown in the figure Call handling algorithm.

_images/10000201000002E500000398BB09D079b.png

Figure 2: Call handling algorithm

It is a good practice to place rules in realms rather than in Call Agents, unless they are clearly specific to Call Agents. Rules in realms don’t have to be repeated Call Agent by Call Agent and don’t expose administrator to Copy-and-Paste administrative errors.

2.4.5.1. Conditions and Actions

_images/100002010000026D000004302EFEC91A.png

Figure 3: Rule evaluation sequence

Every A/B/C rule may have one or multiple conditions. The conditions can check incoming message content (method, R-URI, headers, codecs), source (IP, port, realm), values stored in call variables etc.

Rules have zero or more actions. If all its conditions are satisfied (‘AND’ combination), the actions of a rule are executed in the order in which they are defined. In case a rule does not contain any conditions, the rule’s actions are always applied.

Actions can have parameters depending on the action type. For example, the action “Add Header” that appends a SIP header to an outgoing message takes two parameters - a header name and a header value.

Within a rule set (Realm A or C rules; Call Agent A or C rules), the SBC evaluates each rule by evaluating the condition set first. If all conditions match, the set of actions is executed. As part of the rule definition a “continue flag” is defined. If the “continue flag” is checked, the next rule is evaluated. Otherwise, the rule evaluation within this block stops. Irrespectively of the state of the “continue flag”, the rule evaluation continues with the next block. This means that if the “continue flag” is not checked in a Realm A rule where the conditions match, the Call Agent A rule will still be executed, see Rule evaluation sequence.

2.4.5.2. Routing rules

Routing rules have the same set of conditions as A & C rules, but only one possible action: route the request to a target Call Agent.

_images/1000020100000130000002A89AE3BBF0.png

Figure 4: B-Rule evaluation

The essential role of B rules is to determine to which target Call Agent the processed request will be sent to. This also influences the outbound signalling and media interface used to send out the forwarded request.

To determine a target Call Agent, the SBC will evaluate the conditions for each routing (B) rule. Once a match is found, the Call Agent associated with the routing rule is determined as the target Call Agent. Then, the processing continues with the C rules assigned to the target Call Agent.

As depicted in Figure B-Rule evaluation, all active B rules are traversed and evaluated sequentially. In case all conditions of a rule are satisfied, the destination call agent and routing method are successfully determined. In case that the conditions of a rule are not satisfied, processing continues with the next rule. If no matching routing rule can be found, then the call is refused with a 404 Not Found error code and an error event type is produced.