CMS Outbound Call Settings

CMS Outbound Call Settings

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.

NOTE Everything you have done so far is independent of the primary call control that CMS will be integrated with. That is about to change. For this lab, since we intend to use CMS for Microsoft interop via external gateway calls, as well as on-prem Microsoft S4B services, you will use Expressway as the primary call control. You will later optionally add direct Unified CM integration, but for the purposes of the lab, you will only use this for ad-hoc conferences. Keep in mind the design decisions that must be considered. If only standards-based SIP needs to be supported in the environment, or only on-prem Microsoft AV, then integrating with Unified CM directly makes perfect sense and can simplify other dial plan considerations.

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.

  1. Launch Postman and change the verb type to POST
  2. Change the URL field to https://cms1a.pod2.cms.lab:8443/api/v1/outboundDialPlanRules
  3. Click on the Body tab below the URL and select x-www-form-urlencoded
  4. Verify Bulk Edit entry mode is selected, so that you can paste the "Postman Bulk Edit Data" information into the window, press Send, and look for a 200 OK response.

    5. Domain SIP proxy to use Behavior Priority Description Postman Bulk Edit Data
    10.0.102.51 10.0.102.51 Stop 200 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
    10.0.102.52 10.0.102.52 Stop 200 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
    10.0.102.53 10.0.102.53 Stop 200 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
    pod2.cms.lab expc1a.pod2.cms.lab Stop 100 Routes for UC domain to Expressway
    domain:pod2.cms.lab sipProxy:expc1a.pod2.cms.lab failureAction:stop priority:100
    <blank> expc1a.pod2.cms.lab Stop 1 Default route to Expressway. Used for outbound numeric dialing capability
    domain: sipProxy:expc1a.pod2.cms.lab failureAction:stop priority:1
  5. Verify the configuration by logging into the CMS admin: https://cms1a.pod2.cms.lab:8443 (Username admin and Password c1sco123) and access the Configuration > Outbound calls section.

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.