PortaSIP dispatching SBC (DSBC)

The dispatching SBC is the dedicated PortaSIP node that operates as the high-level inter-system/inter-site proxy. The dispatching SBC accepts call initiation requests and dispatches them across systems. It operates in high-availability mode and presents a single point of entry both to your termination partners and to your wholesale, SIP trunking, residential and other customers. It works with the Dual Version PortaSwitch solution and with the Zero-downtime update (ZDU) technology.

The dispatching SBC performs the following functions:

• accepts call initiation requests for accounts in either system/site, e.g., in site-redundant PortaSwitch or Dual Version PortaSwitch;
• creates the NAT tunnel between the IP device and PortaSwitch and performs NAT traversal;
• matches the destination number from an incoming call request against account IDs and/or DID numbers from the database;
• finds the billing environment that the matched account belongs to; and
• dispatches the call request to the respective PortaSIP for further processing.

Since the dispatching SBC accepts only first dialog initiation requests (e.g., REGISTER, NOTIFY, INVITE), this results in call traffic processing of up to 1000 CPS. For high-availability, the dispatching SBC can be scaled up by adding more instances. In this case, all instances share a virtual IP address, though only one instance remains active.

You can configure several entry points for the dispatching SBC by adding additional IP addresses as aliases to its virtual IP address. In so doing you can smoothly migrate customers registered with legacy PortaSIP environments or multiple sites to a single entry point of your site-redundant and/or Dual Version PortaSwitch.

When user IP phones re-register, the dispatching SBC starts processing their registration and call initiation requests. Requests sent to the IP aliases and to the main (virtual) IP address of the dispatching SBC are processed in the same way.

One of the key advantages of site-redundant PortaSwitch is the ability to perform zero-downtime updates (ZDU). (Please refer to the PortaSwitch Architecture and Concepts Guide for more information about zero-downtime system updates.)

During ZDU, the dispatching SBC mediates both call and registration requests from users’ devices and dispatches them to the active site for processing. Thus, users may enjoy their services without interruptions and not have to wait for their devices to re-register on the secondary site.

As soon as the update procedure begins on the main site, all services are switched to the secondary site. If a user’s device from the main site sends the REGISTER request, the dispatching SBC routes it to the secondary site. The secondary site’s PortaSIP updates the device’s contact information and the dispatching SBC delivers it to the device.

If a user’s device has not yet re-registered with the new site during the update, the dispatching SBC keeps the NAT tunnel to this device open. Thus, if there is an incoming call to this user, the dispatching SBC sends the call request to the secondary site. Upon successful call authorization and processing, the dispatching SBC delivers the call to the user.

As soon as the main site is updated and services are switched to it again, the dispatching SBC sends all the requests from the user’s devices to the main PortaSIP for processing.

Note that secondary sites do not synchronize data with each other when operating in standalone mode. Therefore, the device can re-register on different sites during the main site’s update.

The dispatching SBC smoothens the system update in the site-redundant PortaSwitch architecture and ensures uninterrupted service availability for users, regardless of their locations within the system.

Load balancing within sites using the dispatching SBC

You can define the ratio by which the dispatching SBC will distribute requests across the sites of your geo-redundant PortaSwitch. This helps you gain advanced flexibility in balancing the load within your network.

To do this, define the percentage of requests to be delivered to a particular PortaSIP in the load_distribution option on the Configuration server.

The default value “auto” means that the dispatching SBC will distribute requests equally among sites (e.g., the main and three secondary sites will each handle 25% of all requests).

During a system update, all requests are evenly distributed among the remaining active sites.

Let’s say the main site of your installation handles 50% of all requests and secondary sites A and B handle 30% and 20% of requests, respectively. When the main site is being updated the dispatching SBC will deliver 55% of requests to secondary site A and 45% of all requests to secondary site B. When secondary site A is being maintained, the request distribution is the following: the main site processes 65% of the requests while 35% of them go to secondary site B.

This enables your administrators to utilize system capacity in the most efficient way.

If you provide hosting services to your customers (e.g., a customer operates in a separate billing environment), you can distribute the pool of DIDs across your own billing environments and allow customers to provision them on-demand. When a call is made to a DID number, the dispatching SBC detects the billing environment from which it is provisioned to the account and delivers the call to the callee.

By default, incoming calls to customers arrive to the dispatching SBC, which routes them to PortaSIP for processing. If there is a call to a customer’s endpoint registered in your network, it is sent from the dispatching SBC. If there is a call to an external SIP URI or to the static IP of a PBX, it is sent directly from PortaSIP. Calls to vendors are also sent directly from PortaSIP. Thus, your wholesale/SIP trunking customers and vendors must adjust their configuration (e.g., firewall rules) to accept requests from a different IP.

To save them from reconfiguring their network, you can send calls to SIP URI, static IP addresses and vendors via the dispatching SBC, too.

Activate the force_route_through_dsbc attribute in the service policy and to: assign this service policy

• outgoing connections for required vendors,
• the SIP-UA connection to send calls to static IPs of PBXs, and
• the SIP-URI connection to forward call to external SIP URIs.

When PortaSIP tries this route, it sends the outgoing INVITE request to the dispatching SBC. The dispatching SBC then sends the request to the destination.

Sending outgoing requests via the dispatching SBC imposes additional load to it. Therefore, only assign a service policy to a connection when required.

Your Dual Version PortaSwitch has the following configuration:

• The IP address of the dispatching SBC is 1.1.1.1.
• The IP address of PortaSIP on the source system is 2.2.2.2.
• The IP address of PortaSIP on the target system is 3.3.3.3.

MegaTrunk is your SIP trunking customer that is already moved to the target system.

MegaTrunk’s PBX does not support digest authentication but it has the static IP address 4.4.4.4. To route calls to the PBX address directly, your administrator configures the SIP contact as 4.4.4.4:5060 for MegaTrunk’s account in PortaBilling.

1. There is a call to MegaTrunk’s main phone number 120655578960 from external caller John Doe. The call arrives to the dispatching SBC.
2. The dispatching SBC looks up the account ID (IP: 4.4.4.4) in the database and detects that it is in the target system. The dispatching SBC sends the call to PortaSIP on the target system (IP: 3.3.3.3).
3. PortaSIP authorizes the call with PortaBilling and receives the routing list. It includes the SIP-UA connection and the service policy associated with it.
4. PortaSIP checks the service policy configuration and detects that the call must go via the dispatching SBC. Then PortaSIP adds the IP address of the dispatching SBC to the outgoing INVITE request and sends it to the dispatching SBC.
5. The dispatching SBC receives this INVITE request and sends it to the SIP contact of the PBX.The call flow is the same whether a call is forwarded to an external SIP URI or sent to a vendor.

The call flow is the same whether a call is forwarded to an external SIP URI or sent to a vendor.

Note that calls between source and target systems are routed directly, bypassing the dispatching SBC.

In site-redundant PortaSwitch, the dispatching SBC dispatches calls across sites according to their load-balancing configurations. Then the calls are processed as described above.

For normal operation, we recommend that the dispatching SBC be deployed on a separate physical server per PortaSIP cluster. For testing purposes, however, you can deploy it on one of your SIP servers within the existing site. For either type of deployment, consider the following specifics:

• The dispatching SBC is assigned a virtual IP address. Since it is the point of entry to your network, the virtual IP address must be public.
• For normal operation, deploy a dispatching SBC on a separate physical server. Refer to the Dispatching SBC deployment requirements and recommendations section for more details.
• For high-availability, deploy several dispatching SBC instances. They can reside either on dedicated servers or in the cloud. Though all dispatching SBC instances share a virtual IP address, only one instance is active.
• In Dual Version PortaSwitch, the dispatching SBC is configured on the target system.
• Provision the dispatching SBC virtual IP address in both systems.
• The DIDs used in your network must be unique for both systems to ensure proper call delivery.
• Accounts that exist in both systems (moved from one to the other) are only active in one of them.

Although the dispatching SBC operates in the high-availability mode serving all users of your site-redundant PortaSwitch, you may still want to ensure that services are uninterrupted even in case of the main site’s outage.

A solution to that is to add the dispatching SBC instance on the fully-redundant secondary site. There are two ways how to do it.

In this configuration, the dispatching SBC instance on the secondary site has the same virtual IP address assigned as that on the main site.

In the normal mode of operations, only the main site’s dispatching SBC is active and therefore it handles all requests. When there is an outage at the main site, the virtual IP address switches to the secondary site. This site’s dispatching SBC becomes active and accepts registration and call initiation requests from all end user devices.

Thus, the communication flow with PortaSwitch for user devices and vendor equipment remains unchanged. This simplifies service configuration and system management.

To ensure that the dispatching SBC is reachable in PortaSwitch, configure the IP routing to the dispatching SBC’s virtual IP address on both sites (e.g., using such technologies as BGP/EGP, LISP protocols, Tinc tunneling, policy-based routing, etc.).

If you cannot use the same virtual IP address for the dispatching SBC because you or your hosting service provider does not provide such a network configuration, there is another way. Assign different virtual IP addresses for the dispatching SBC on the main and secondary sites.

Such a configuration presents two points of entry to your network; therefore, vendor and user equipment must be able to send requests to both of them. Configure the domain name for the dispatching SBC on the DNS server so that it resolves on two virtual IP addresses, and then provision it to vendors and user phones.

Vendor and user equipment must be configured to send all requests to the dispatching SBC on the main site within the normal mode of operation. When the main site is down or unavailable, registration and call initiation requests are sent to the dispatching SBC on the secondary site. User phones, however, can accept incoming calls only after they re-register with the IP address of the secondary site’s dispatching SBC.

If you wish to balance the load on dispatching SBC instances and prioritize the traffic flow, configure DNS SRV records.

This configuration makes you independent from your hosting service provider and any network limitations they might have. Thereby you can deploy PortaSwitch sites in geographically dispersed locations (e.g., in New York and Singapore) and also ensure uninterrupted service provisioning for your users.