Not all deployments will require Outbound call settings; however for clustered Callbridge deployments, they are mandatory, because servers themselves use outbound SIP calling rules to place calls between Callbridge cluster nodes for the purposes of cascading calls. Outbound calls are also used when a client, such as CMA or endpoints with ActiveControl support, invite participants to a Space, as well as when calls are hair-pinned through CMS (in order to transcode between standards-based SIP and Microsoft SIP).
Regarding intra-cluster peer calls: if you recall, on the CMS Configuration > Cluster page, the Peer link SIP domain setting determines the domain portion for intra-cluster calls. If it is blank, as it is in your lab configuration, then the destination CMS's IP address is used (e.g. for CB_cms1a it is @10.0.102.51). If a peer link is configured, that domain must be routed exclusively to the CMS server node associated with that peer. This means that the domain is typically the FQDN of the destination Callbridge (e.g. for CB_cms1a it would be @cms1a.pod2.cms.lab). For this, an outbound rule must be configured in CMS with that domain/FQDN and indicate the destination of the call via the SIP Proxy setting. This SIP Proxy is usually an external call control, such as Expressway or Unified CM. This means that intracluster calls can be routed through an external call control agent as opposed to being sent directly between nodes.
You will need to add outbound routes for each of the 3 Call Bridges' IP addresses using the destination Call Bridge's IP address as the SIP Proxy to ensure those calls get sent directly to the respective node.
In addition to the intracluster calling rules, you will also add some rules that are specific to the call control integration. You will add the local Unified CM domain, pod2.cms.lab, as a standards-based SIP destination, but point it to the Expressway-C as the SIP Proxy. This will allow any outbound call or hairpinned call for that domain to be routed to the UCM cluster via Expressway-C. Finally, you will add a default, "catch-all", route. This rule allows clients (CMA and/or Jabber) to be able to invite participants using numeric numbers, not just URIs. When this type of call originates via Jabber, the domain of the Unified CM that the endpoint is registered to will be added when a number is dialed, therefore CMS needs to be able to reach the addresses of all UCM server nodes. The easiest way to do this is by configuring a default route from CMS.
Although you can perform these configuration tasks from the GUI (in the Configuration > Outbound calls section), we will show you how to use Postman to accomplish this task. Later you will verify the settings using the CMS admin GUI.
|Domain||SIP proxy to use||Behavior||Priority||Description||Postman Bulk Edit Data|
|Stop||Route to CMS1a's IP address. Used for intra-cluster call routing.||
domain:10.0.102.51 sipProxy:10.0.102.51 failureAction:stop priority:200
|Stop||Route to CMS1b's IP address. Used for intra-cluster call routing.||
domain:10.0.102.52 sipProxy:10.0.102.52 failureAction:stop priority:200
|Stop||Route to CMS1c's IP address. Used for intra-cluster call routing.||
domain:10.0.102.53 sipProxy:10.0.102.53 failureAction:stop priority:200
|Stop||Routes for UC domain to Expressway||
domain:pod2.cms.lab sipProxy:expc1a.pod2.cms.lab failureAction:stop priority:100
|<blank>||Stop||Default route to Expressway. Used for outbound numeric dialing capability||
domain: sipProxy:expc1a.pod2.cms.lab failureAction:stop priority:1
For this lab we will not configure any Dial Transform rules. Dial transform rules ONLY affect outbound calls and they do so prior to routing the calls using the Outbound calling rules. Note that for clustered deployments, Dial Transform rules must be configured via the API, not the Webadmin GUI.
This completes the CMS Dial Plan configuration. We now need to configure our external call control entities to route calls to CMS. Since our call flow will be Jabber → Unified CM → Expressway-C → CMS, we will begin with the Unified CM.