… Configure dispatching SBC?

The dispatching SBC is used for these scenarios:

1. In site-redundant PortaSwitch for:
   • Zero-downtime updates;
   • Load-balancing between sites.
2. In Dual Version PortaSwitch for uninterrupted service.
3. In Dual Version PortaSwitch with site-redundant systems. The dispatching SBC performs the functions described in items 1 and 2.
4. For DID distribution across billing environments and incoming call delivery to those DIDs.

• The dispatching SBC requires a public IP address to serve as the point of entry to your network.
• The dispatching SBC uses the LogServer for logging. Verify that the dispatching SBC has access to the LogServer. For example, servers must reside within the same private network. If the servers are configured on public IPs, firewall rules may not restrict their communication. Contact support@portaone.com for assistance.
• In Dual Version PortaSwitch, the dispatching SBC uses the Cassandra database to detect which billing environment to dispatch a call to. For example, servers must reside in the same private network. If the servers are configured on public IPs, firewall rules may not restrict their communication. Contact support@portaone.com for assistance.

• For high availability, we recommend that you deploy the dispatching SBC on dedicated physical servers. There must be a minimum of two dispatching SBC instances per site. Though all dispatching SBC instances share a virtual IP address, only one instance is active at a time.
• When a call is routed out via DSBC, additional “Via” and “Record-Route” headers are added to the outgoing INVITE message. This may increase the message size, thereby exceeding the MTU (Maximum Transmission Unit) limit for an IP packet. SIP protocol does not support message fragmentation at the SIP protocol layer, so if a SIP message does not fit into a single packet, this may cause issues with calls. We highly recommend verifying this scenario during the test deployment of DSBC with the PortaOne support team to evaluate possible challenges and recommendations.

To configure a dispatching SBC, follow the general configuration guidelines and then adjust the configuration per required scenario.

1. Add the dispatching SBC servers as described in the Add servers chapter.
2. On the Servers page, select the server to run the dispatching SBC on and click   Change server configuration.
3. On the Network tab, click Add, then choose the IP address and add it to serve as the service IP for the dispatching SBC instance.

   

4. Repeat steps 2-3 to add IP addresses to all the dispatching SBC servers.
5. Go to the Configurations tab and clone the existing configuration.
6. From the Configurations tree, select ClusterSuite > PortaSIP Cluster > <your_sip-cluster>
7. Click the   Instance create button.
8. Fill in the Instance create details:
   • Type – select Dispatching SBC;
   • Server – select the dispatching SBC server you have added;
   • Service IP – select the server’s IP address;
   • Click Save.

   

9. Repeat step 8 to create a dispatching SBC instance on the second server.
10. Select the DispatchingSBC group and specify the virtual IP address in the vipaddr field.
11. Click Verify to verify the configuration.
12. Click Check/Apply to apply the configuration.

To provide high availability for your site-redundant PortaSwitch, deploy the dispatching SBC on both the main and secondary sites. Then even if the main site is down or unavailable, services continue to run, uninterrupted.

You can assign the same virtual IP address for the dispatching SBC on both sites. In this case, you must configure the IP routing to the dispatching SBC’s virtual IP address on both sites to make it reachable in PortaSwitch (e.g., using such technologies as BGP/EGP, LISP protocols, Tinc tunneling, policy-based routing, etc.) This way, even a dummy endpoint can continue to work without re-registering on another IP.

If there is no way to share the virtual IP address between sites (e.g.,  your hosting service provider does not support such a network configuration), you can assign different IP addresses for the dispatching SBC on both 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.

Select the relevant option depending on your network configuration.

1. Perform the general configuration of the dispatching SBC on every site.
2. On the Configurations tab, clone the existing configuration.
3. From the Configurations tree, select ClusterSuite > PortaSIP Cluster.
4. Select the DispatchingSBC group and select one of the following for the vip_redundancy_policy option:
   • Unique VIPA per cluster within one env means that on every site, the dispatching SBC has a different IP address.
   • Same VIPA for all clusters within one env means the dispatching SBC on both sites has the same IP address.

   

5. Click Verify to verify the configuration.
6. Click Check/Apply to apply the configuration.

You can define which portion of traffic the dispatching SBC sends to which site in your site-redundant PortaSwitch.

1. Perform the general configuration of the dispatching SBC.
2. On the Configurations tab, clone the existing configuration.
3. From the Configurations tree, select ClusterSuite > PortaSIP Cluster > <your_sip-cluster>.
4. Select the DispatchingSBC group.
5. In the load_distribution option, specify the percentage of requests to be sent to this PortaSIP within a range of 0 to 100, where:
   • 0 means no requests will be sent to this PortaSIP;
   • 100 means all requests will be sent to this PortaSIP;
   • auto means all requests will be evenly distributed among all PortaSIPs deployed in your installation.

   

6. Click Verify to verify the configuration.
7. Click Check/Apply to apply the configuration.

Zero-downtime update technology enables you to perform software upgrades at any time without any noticeable impact on service availability for end users. When the main site is switched to maintenance mode, the dispatching SBC redirects new call and registration requests to the secondary site for processing. After the main site is updated, data is synchronized and the update procedure begins on the secondary site, the dispatching SBC sends all requests to the main site. This ensures service continuity for users during maintenance.

To perform ZDU with the dispatching SBC, these requirements must be met:

• The secondary site must include PortaSIP, billing instances and database servers to operate in standalone mode
• The dispatching SBC must be deployed on two dedicated servers, at least one on the main and one on the secondary sites. Follow the steps from the general configuration section.
  We recommend that you deploy two dispatching SBC instances on the main site and at least one on the secondary site.
• The dispatching SBC instances must share the same virtual IP address to automate the ZDU process. Follow the steps from the High-availability for the dispatching SBC in site-redundant PortaSwitch section.

The dispatching SBC in Dual Version PortaSwitch accepts all calls and registration requests and dispatches them to the system where the account currently resides. This enables you to perform gradual customer migration and ensure that users enjoy the services uninterrupted while being migrated.

In Dual Version PortaSwitch, the dispatching SBC must be deployed on dedicated servers that belong to the target system.

1. Perform the general configuration of the dispatching SBC.
2. Specify the list of endpoints (in the SIP-URI format) where a call/registration request is to be dispatched on the source system. Select the ForwardingRegistry group and for the foreign_forwarding_list option, specify endpoint records using these mandatory parameters:
   • scheme is the address definition scheme for the SIP protocol. Possible values are sip and sips (SIP secure).
   • host  is the PortaSIP virtual IP address associated with a particular billing environment on the source system. If a billing environment includes several sites and therefore several PortaSIPs, specify each as a separate record.
   • ienv is the internal identifier of the billing environment where requests are dispatched.

   The parameters below are optional:

   • port is the port on PortaSIP that accepts requests. The default value is 5060 for the sip scheme and 5061 for the sips scheme.
   • transport is the communication protocol with endpoints. The values are: TCP, UDP and TLS. UDP transport is the default for the sip scheme. TLS is required for the sips scheme.
   • site is the name of the site that PortaSIP  belongs to. The default site is the main site.

   The examples of records are:

   sip:217.182.15.104:5601?ienv=3;
   sip:217.182.15.111:5603;transport=tcp?ienv=3&site=Barcelona

   

3. Click Verify to verify the configuration.
4. Click Check/Apply to apply the configuration.

To share the DID pool across several billing environments within your installation, do the following:

1. Perform the general configuration of the dispatching SBC.
2. On the Configurations tab, clone the existing configuration.
3. From the Configurations tree, select ClusterSuite > PortaSIP Cluster > <your_sip-cluster>.
4. Select the ForwardingRegistry group and define the billing environments from which the DIDs will be provisioned to in the domestic_forwarding_list option.
5. Click Verify to verify the configuration.
6. Click Check/Apply to apply the configuration.