- Home
- /
- Article
In this articleGet your bearings with all of the information available about Webex Calling, whether you're a partner, an administrator, or a user. Use the links provided here to help you get started using all of the services and features available with Webex Calling.
Local Gateway Requirements for Webex Calling
General prerequisites
Before you configure a local gateway for Webex Calling, ensure that you:
-
Have a basic knowledge of VoIP principles
-
Have a basic working knowledge of Cisco IOS-XE and IOS-XE voice concepts
-
Have a basic understanding of the Session Initiation Protocol (SIP)
-
Have a basic understanding of Cisco Unified Communications Manager (Unified CM) if your deployment model includes Unified CM
See the Cisco Unified Border Element (CUBE) Enterprise Configuration Guide for details.
Hardware and Software Requirements for Local Gateway
Make sure your deployment has one or more of the local gateways (Cisco CUBE (for IP-based connectivity) or Cisco IOS Gateway (for TDM-based connectivity)) that are in Table 1 of the Local Gateway for Webex Calling Ordering Guide. Additionally, make sure the platform is running a supported IOS-XE release as per the Local Gateway Configuration Guide.
License Requirements for Local Gateways
CUBE calling licenses must be installed on the local gateway. For more information, see the Cisco Unified Border Element Configuration Guide.
Certificate and Security Requirements for Local Gateway
Webex Calling requires secure signaling and media. The local gateway performs the encryption, and a TLS connection must be established outbound to the cloud with the following steps:
-
The LGW must be updated with the CA root bundle from Cisco PKI
-
A set of SIP digest credentials from Control Hub’s Trunk configuration page are used to configure the LGW (the steps are part of the configuration that follows)
-
CA root bundle validates presented certificate
-
Prompted for credentials (SIP digest provided)
-
The cloud identifies which local gateway is securely registered
Firewall, NAT Traversal, and Media Path Optimization Requirements for Local Gateway
In most cases, the local gateway and endpoints can reside in the internal customer network, using private IP addresses with NAT. The enterprise firewall must allow outbound traffic (SIP, RTP/UDP, HTTP) to specific IP addresses/ports, covered in Port Reference Information.
If you want to utilize Media Path Optimization with ICE, the local gateway’s Webex Calling facing interface must have a direct network path to and from the Webex Calling endpoints. If the endpoints are in a different location and there is no direct network path between the endpoints and the local gateway’s Webex Calling facing interface, then the local gateway must have a public IP address assigned to the interface facing Webex Calling for calls between the local gateway and the endpoints to utilize media path optimization. Additionally, it must be running IOS-XE version 16.12.5.
The first step to get your Webex Calling services up and running is to complete the First Time Setup Wizard (FTSW). Once the FTSW is completed for your first location, it doesn’t need to be completed for additional locations.
| 1 |
Click the Getting Started link in the Welcome email you receive.
| ||
| 2 |
Review and accept the terms of service. | ||
| 3 |
Review your plan and then click Get Started.
| ||
| 4 |
Select the country that your data center should map to, and enter the customer contact and customer address information. | ||
| 5 |
Click Next: Default Location. | ||
| 6 |
Choose from the following options:
| ||
| 7 |
Make the following selections to apply to this location:
| ||
| 8 |
Click Next. | ||
| 9 |
Enter an available Cisco Webex SIP address and click Next and select Finish. |
Before you begin
To create a new location, prepare the following information:
-
Location address
-
Desired phone numbers (optional)
| 1 |
Log in to Control Hub at https://admin.webex.com, go to .
| ||||
| 2 |
Configure the settings of the location:
| ||||
| 3 |
Click Save and then choose Yes/ No to add numbers to the location now or later. | ||||
| 4 |
If you clicked Yes, choose one of the following options:
The choice of PSTN option is at each location level (each location has only one PSTN option). You can mix and match as many options as you’d like for your deployment, but each location will have one option. Once you’ve selected and provisioned a PSTN option, you can change it by clicking Manage in the location PSTN properties. Some options, such as Cisco PSTN, however, may not be available after another option has been assigned. Open a support case for guidance. | ||||
| 5 |
Choose whether you want to activate the numbers now or later. | ||||
| 6 |
If you selected non-integrated CCP or Premises-based PSTN, enter Phone Numbers as comma-separated values, and then click Validate. Numbers are added for the specific location. Valid entries move to the Validated Numbers field, and invalid entries remain in the Add Numbers field accompanied by an error message. Depending on the location's country, the numbers are formatted according to local dialing requirements. For example, if a country code is required, you can enter numbers with or without the code and the code is prepended. | ||||
| 7 |
Click Save. |
What to do next
After you create a location, you can enable emergency 911 services for that location. See RedSky Emergency 911 Service for Webex Calling for more information.
Before you begin
 | Get a list of the users and workspaces associated with a location: Go to and from the drop-down menu, select the location to be deleted. You must delete those users and workspaces before you delete the location. Keep in mind that any numbers associated with this location will be released back to your PSTN provider; you'll no longer own those numbers. |
| 1 |
Log in to Control Hub at https://admin.webex.com, go to . |
| 2 |
Click |
| 3 |
Choose Delete Location, and confirm that you want to delete that location. It typically takes a couple of minutes for the location to be permanently deleted, but it could take up to an hour. You can check the status by clicking |
beside the location name and selecting You can change your PSTN setup, the name, time zone, and language of a location after it's created. Keep in mind though that the new language only applies to new users and devices. Existing users and devices continue to use the old language.
| For existing locations, you can enable emergency 911 services. See RedSky Emergency 911 Service for Webex Calling for more information. |
| 1 |
Log in to Control Hub at https://admin.webex.com, go to . If you see a Caution symbol next to a location, it means that you haven't configured a telephone number for that location yet. You can't make or receive any calls until you configure that number. | ||||||
| 2 |
(Optional) Under PSTN Connection, select either Cloud Connected PSTN or Premises-based PSTN (local gateway), depending on which one you've already configured. Click Manage to change that configuration, and then acknowledge the associated risks by selecting Continue. Then, choose one of the following options and click Save:
| ||||||
| 3 |
Select the Main Number at which the location's main contact can be reached. | ||||||
| 4 |
(Optional) Under Emergency Calling, you can select Emergency Location Identifier to assign to this location.
| ||||||
| 5 |
Select the Voicemail Number that users can call to check their voicemail for this location. | ||||||
| 6 |
(Optional) Click the pencil icon at the top of the Location page to change the Location Name, Announcement Language, Email Language, Time Zone, or Address as needed, and then click Save.
|
These settings are for internal dialing and are also available in the first-time setup wizard. As you change your dial plan, the example numbers in the Control Hub update to show these changes.
 | You can configure outgoing calling permissions for a location. See these steps to configure outgoing calling permissions. |
| 1 |
Sign in to Control Hub, go to , and then scroll to Internal Dialing. | ||||||||
| 2 |
Configure the following optional dialing preferences, as needed:
| ||||||||
| 3 |
Specify internal dialing for specific locations. Go to , select a location from the list, and click Calling. Scroll to Dialing, and then change internal dialing as needed:
| ||||||||
| 4 |
Specify external dialing for specific locations. Go to , select a location from the list, and click Calling. Scroll to Dialing, and then change external dialing as needed:
Impact to users:
|
If you're a value added reseller, you can use these steps to start local gateway configuration in Control Hub. When this gateway is registered to the cloud, you can use it on one or more of your Webex Calling locations to provide routing toward an enterprise PSTN service provider.
 | A location that has a local gateway can't be deleted when the local gateway is being used for other locations. |
Before you begin
-
Once a location is added, and before configuring premises-based PSTN for a location, you must create a trunk.
-
Create any locations and specific settings and numbers to each one. Locations must exist before you can add a premises-based PSTN.
-
Understand the Premises-based PSTN (local gateway) requirements for Webex Calling.
-
You can't choose more than one trunk for a location with premises-based PSTN, but you can choose the same trunk for multiple locations.
| 1 |
Log in to Control Hub at https://admin.webex.com, go to , and select Add Trunk. | ||
| 2 |
Select a location. | ||
| 3 |
Name the trunk and click Save.
|
What to do next
Trunk information appears on the screen Register Domain, Trunk Group OTG/DTG, Line/Port, and Outbound Proxy Address.
We recommend that you copy this information from Control Hub and paste it into a local text file or document so you can refer to it when you're ready to configure the premises-based PSTN.
If you lose the credentials, you must generate them from the trunk information screen in Control Hub. Click Retrieve Username and Reset Password to generate a new set of authentication credentials to use on the trunk.
| 1 |
Log in to Control Hub at https://admin.webex.com, go to . | ||
| 2 |
Select a location to modify and click Manage. | ||
| 3 |
Select Premises-based PSTN and click Next. | ||
| 4 |
Choose a trunk from the drop-down menu.
| ||
| 5 |
Click the confirmation notice, then click Save. |
What to do next
You must take the configuration information that Control Hub generated and map the parameters into the local gateway (for example, on a Cisco CUBE that sits on the premises). This article walks you through this process. As a reference, see the following diagram for an example of how the Control Hub configuration information (on the left) maps onto parameters in the CUBE (on the right):
After you successfully complete the configuration on the gateway itself, you can return to in Control Hub and the gateway that you created will be listed in the location card that you assigned it to with a green dot to the left of the name. This status indicates that the gateway is securely registered to the calling cloud and is serving as the active PSTN gateway for the location.
You can easily view, activate, remove and add phone numbers for your organization in Control Hub. For more information, see Manage phone numbers in Control Hub.
If you're trying out Webex services and you'd like to convert your trial to a paid subscription, you can submit an email request to your partner.
| 1 |
Log in to Control Hub at https://admin.webex.com, select the building icon |
| 2 |
Select the Subscriptions tab, and then click Purchase Now. An email is sent to your partner letting them know that you're interested in converting to a paid subscription. |
You can use Control Hub to set the priority of available calling options that users see in Webex App. You can also enable them for single click-to-call. For more information, see: Set calling options for Webex App users.
You can control what calling application opens when users make calls. You can configure the calling client settings, including mixed-mode deployment for organizations with users entitled with Unified CM or Webex Calling and users without paid calling services from Cisco. For more information, see: Set up calling behavior.
Overview
Webex Calling currently supports two versions of Local Gateway:
-
Local Gateway
-
Local Gateway for Webex for Government
-
Before you begin, understand the premises-based Public Switched Telephone Network (PSTN) and Local Gateway (LGW) requirements for Webex Calling. See Cisco Preferred Architecture for Webex Calling for more information.
-
This article assumes that a dedicated Local Gateway platform is in place with no existing voice configuration. If you modify an existing PSTN gateway or CUBE Enterprise deployment to use as the Local Gateway function for Webex Calling, then pay careful attention to the configuration. Ensure that you don't interrupt the existing call flows and functionality because of the changes that you make.
| The procedures contain links to command reference documentation where you can learn more about the individual command options. All command reference links go to the Webex Managed Gateways Command Reference unless stated otherwise (in which case, the command links go to Cisco IOS Voice Command Reference). You can access all these guides at Cisco Unified Border Element Command References. For information on the supported third-party SBCs, refer to the respective product reference documentation. |
There are two options to configure the Local Gateway for your Webex Calling trunk:
-
Registration-based trunk
-
Certificate-based trunk
Use the task flow either under the Registration-based Local Gateway or Certificate-based Local Gateway to configure Local Gateway for your Webex Calling trunk.
See Get started with Local Gateway for more information on different trunk types. Perform the following steps on the Local Gateway itself, using the Command Line Interface (CLI). We use Session Initiation Protocol (SIP) and Transport Layer Security (TLS) transport to secure the trunk and Secure Real Time Protocol (SRTP) to secure the media between the Local Gateway and Webex Calling.
-
Select CUBE as your Local Gateway. Webex for Government doesn’t currently support any third-party Session Border Controllers (SBCs). To review the latest list, see Get started with Local Gateway.
- Install Cisco IOS XE Dublin 17.12.1a or later versions for all Webex for Government Local Gateways.
-
To review the list of root Certificate Authorities (CAs) that Webex for Government support, see Root certificate authorities for Webex for Government.
-
For details on the external port ranges for Local Gateway in Webex for Government, see Network requirements for Webex for Government (FedRAMP).
Local Gateway for Webex for Government doesn’t support the following:
-
STUN/ICE-Lite for media path optimization
-
Fax (T.38)
To configure Local Gateway for your Webex Calling trunk in Webex for Government, use the following option:
-
Certificate-based trunk
Use the task flow under the Certificate-based Local Gateway to configure the Local Gateway for your Webex Calling trunk. For more details on how to configure a certificate-based Local Gateway, see Configure Webex Calling certificate-based trunk.
It’s mandatory to configure FIPS-compliant GCM ciphers to support Local Gateway for Webex for Government. If not, the call setup fails. For configuration details, see Configure Webex Calling certificate-based trunk.
| Webex for Government doesn’t support registration-based Local Gateway. |
This section describes how to configure a Cisco Unified Border Element (CUBE) as a Local Gateway for Webex Calling, using a registering SIP trunk. The first part of this document illustrates how to configure a simple PSTN gateway. In this case, all calls from the PSTN are routed to Webex Calling and all calls from Webex Calling are routed to the PSTN. The image below highlights this solution and the high-level call routing configuration that will be followed.
In this design, the following principal configurations are used:
-
voice class tenants: Used to create trunk specific configurations.
-
voice class uri: Used to classify SIP messages for the selection of an inbound dial-peer.
-
inbound dial-peer: Provides treatment for inbound SIP messages and determines the outbound route with a dial-peer group.
-
dial-peer group: Defines the outbound dial-peers used for onward call routing.
-
outbound dial-peer: Provides treatment for outbound SIP messages and routes them to the required target.
When connecting an on-premises Cisco Unified Communications Manager solution with Webex Calling, you can use the simple PSTN gateway configuration as a baseline for building the solution illustrated in the following diagram. In this case, Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls.
Throughout this document, the host names, IP addresses, and interfaces illustrated in the following image are used.
Use the configuration guidance in the rest of this document to complete your Local Gateway configuration as follows:
-
Step 1: Configure router baseline connectivity and security
-
Step 2: Configure Webex Calling Trunk
Depending on your required architecture, follow either:
-
Step 3: Configure Local Gateway with SIP PSTN trunk
-
Step 4: Configure Local Gateway with existing Unified CM environment
Or:
-
Step 3: Configure Local Gateway with TDM PSTN trunk
Baseline configuration
The first step in preparing your Cisco router as a Local Gateway for Webex Calling is to build a baseline configuration that secures your platform and establishes connectivity.
-
All registration-based Local Gateway deployments require Cisco IOS XE 17.6.1a or later versions. For the recommended versions, see the Cisco Software Research page. Search for the platform and select one of the suggested releases.
-
ISR4000 series routers must be configured with both Unified Communications and Security technology licenses.
-
Catalyst Edge 8000 series routers fitted with voice cards or DSPs require DNA Advantage licensing. Routers without voice cards or DSPs require a minimum of DNA Essentials licensing.
-
-
Build a baseline configuration for your platform that follows your business policies. In particular, configure the following and verify the working:
-
NTP
-
ACLs
-
User authentication and remote access
-
DNS
-
IP routing
-
IP addresses
-
-
The network toward Webex Calling must use an IPv4 address.
-
Upload the Cisco root CA bundle to the Local Gateway.
Configuration
| 1 |
Ensure that you assign valid and routable IP addresses to any Layer 3 interfaces, for example:
| ||
| 2 |
Protect registration and STUN credentials on the router using symmetric encryption. Configure the primary encryption key and encryption type as follows:
| ||
| 3 |
Create a placeholder PKI trustpoint.
| ||
| 4 |
Enable TLS1.2 exclusivity and specify the default trustpoint using the following configuration commands. Transport parameters should also be updated to ensure a reliable secure connection for registration:
| ||
| 5 |
Install the Cisco root CA bundle, which includes the DigiCert CA certificate used by Webex Calling. Use the crypto pki trustpool import clean url command to download the root CA bundle from the specified URL, and to clear the current CA trustpool, then install the new bundle of certificates:
|
| 1 |
Create a registration based PSTN trunk for an existing location in Control Hub. Make a note of the trunk information that is provided once the trunk has been created. These details, as highlighted in the following illustration, will be used in the configuration steps in this guide. For more information, see Configure trunks, route groups, and dial plans for Webex Calling. | ||||
| 2 |
Enter the following commands to configure CUBE as a Webex Calling Local Gateway: Here's an explanation of the fields for the configuration:
Enables Cisco Unified Border Element (CUBE) features on the platform. media statisticsEnables media monitoring on the Local Gateway. media bulk-statsEnables the control plane to poll the data plane for bulk call statistics. For more information on these commands, see Media. allow-connections sip to sipEnable CUBE basic SIP back-to-back user agent functionality. For more information, see Allow connections.
Enables STUN (Session Traversal of UDP through NAT) globally.
For more information, see stun flowdata agent-id and stun flowdata shared-secret. asymmetric payload fullConfigures SIP asymmetric payload support for both DTMF and dynamic codec payloads. For more information on this command, see asymmetric payload. early-offer forcedForces the Local Gateway to send SDP information in the initial INVITE message instead of waiting for acknowledgment from the neighboring peer. For more information on this command, see early-offer. | ||||
| 3 |
Configure voice class codec 100 filter for the trunk. In this example, the same codec filter is used for all trunks. You can configure filters for each trunk for precise control. Here's an explanation of the fields for the configuration: voice class codec 100Used to only allow preferred codecs for calls through SIP trunks. For more information, see voice class codec.
| ||||
| 4 |
Configure voice class stun-usage 100 to enable ICE on the Webex Calling trunk. Here's an explanation of the fields for the configuration: stun usage ice liteUsed to enable ICE-Lite for all Webex Calling facing dial-peers to allow media-optimization whenever possible. For more information, see voice class stun usage and stun usage ice lite.
| ||||
| 5 |
Configure the media encryption policy for Webex traffic. Here's an explanation of the fields for the configuration: voice class srtp-crypto 100Specifies SHA1_80 as the only SRTP cipher-suite CUBE offers in the SDP in offer and answer messages. Webex Calling only supports SHA1_80. For more information, see voice class srtp-crypto. | ||||
| 6 |
Configure a pattern to uniquely identify calls to a Local Gateway trunk based on its destination trunk parameter: Here's an explanation of the fields for the configuration: voice class uri 100 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use dtg= followed by the Trunk OTG/DTG value provided in Control Hub when the trunk was created. For more information, see voice class uri. | ||||
| 7 |
Configure sip profile 100, which will be used to modify SIP messages before they are sent to Webex Calling.
Here's an explanation of the fields for the configuration:
| ||||
| 8 |
Configure Webex Calling trunk:
|
After you define tenant 100 and configure a SIP VoIP dial-peer, the gateway initiates a TLS connection toward Webex Calling. At this point the access SBC presents its certificate to the Local Gateway. The Local Gateway validates the Webex Calling access SBC certificate using the CA root bundle that was updated earlier. If the certificate is recognised, a persistent TLS session is established between the Local Gateway and Webex Calling access SBC. The Local Gateway is then able to use this secure connection to register with the Webex access SBC. When the registration is challenged for authentication:
-
The username, password, and realm parameters from the credentials configuration is used in the response.
-
The modification rules in sip profile 100 are used to convert SIPS URL back to SIP.
Registration is successful when a 200 OK is received from the access SBC.
Having built a trunk towards Webex Calling above, use the following configuration to create a non-encrypted trunk towards a SIP based PSTN provider:
| If your Service Provider offers a secure PSTN trunk, you may follow a similar configuration as detailed above for the Webex Calling trunk. Secure to secure call routing is supported by CUBE. |
| To configure TDM interfaces for PSTN call legs on the Cisco TDM-SIP Gateways, see Configuring ISDN PRI. |
| 1 |
Configure the following voice class uri to identify inbound calls from the PSTN trunk: Here's an explanation of the fields for the configuration: voice class uri 200 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use the IP address of you IP PSTN gateway. For more information, see voice class uri. |
| 2 |
Configure the following IP PSTN dial-peer: Here's an explanation of the fields for the configuration: Defines a VoIP dial-peer with a tag of 200 and gives a meaningful description for ease of management and troubleshooting. For more information, see dial-peer voice. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). session protocol sipv2Specifies that dial-peer 200 handles SIP call legs. For more information, see session protocol (dial peer). session target ipv4:192.168.80.13Indicates the destination’s target IPv4 address to send the call leg. The session target here is ITSP’s IP address. For more information, see session target (VoIP dial peer). incoming uri via 200Defines a match criterion for the VIA header with the IP PSTN’s IP address. Matches all incoming IP PSTN call legs on the Local Gateway with dial-peer 200. For more information, see incoming url. bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent to PSTN. For more information, see bind. voice-class codec 100Configures the dial-peer to use the common codec filter list 100. For more information, see voice-class codec. dtmf-relay rtp-nteDefines RTP-NTE (RFC2833) as the DTMF capability expected on the call leg. For more information, see DTMF Relay (Voice over IP). no vadDisables voice activity detection. For more information, see vad (dial peer). |
| 3 |
If you are configuring your Local Gateway to only route calls between Webex Calling and the PSTN, add the following call routing configuration. If you are configuring your Local Gateway with a Unified Communications Manager platform, skip to the next section. |
The PSTN-Webex Calling configuration in the previous sections may be modified to include additional trunks to a Cisco Unified Communications Manager (UCM) cluster. In this case, all calls are routed via Unified CM. Calls from UCM on port 5060 are routed to the PSTN and calls from port 5065 are routed to Webex Calling. The following incremental configurations may be added to include this calling scenario.
| When creating the Webex Calling trunk in Unified CM, ensure that you configure the incoming port in the SIP Trunk Security Profile settings to 5065. This allows incoming messages on port 5065 and populate the VIA header with this value when sending messages to the Local Gateway. |
| 1 |
Configure the following voice class URIs: | ||
| 2 |
Configure the following DNS records to specify SRV routing to Unified CM hosts:
Here's an explanation of the fields for the configuration: The following command creates a DNS SRV resource record. Create a record for each UCM host and trunk: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: SRV resource record name 2: The SRV resource record priority 1: The SRV resource record weight 5060: The port number to use for the target host in this resource record ucmsub5.mydomain.com: The resource record target host To resolve the resource record target host names, create local DNS A records. For example: ip host ucmsub5.mydomain.com 192.168.80.65 ip host: Creates a record in the local IOS XE database. ucmsub5.mydomain.com: The A record host name. 192.168.80.65: The host IP address. Create the SRV resource records and A records to reflect your UCM environment and preferred call distribution strategy. | ||
| 3 |
Configure the following dial-peers: | ||
| 4 |
Add call routing using the following configurations: |
Diagnostic Signatures (DS) proactively detects commonly observed issues in the IOS XE-based Local Gateway and generates email, syslog, or terminal message notification of the event. You can also install the DS to automate diagnostics data collection and transfer-collected data to the Cisco TAC case to accelerate resolution time.
Diagnostic Signatures (DS) are XML files that contain information about problem trigger events and actions to be taken to inform, troubleshoot, and remediate the issue. You can define the problem detection logic using syslog messages, SNMP events and through periodic monitoring of specific show command outputs.
The action types include collecting show command outputs:
-
Generating a consolidated log file
-
Uploading the file to a user-provided network location such as HTTPS, SCP, FTP server.
TAC engineers author the DS files and digitally sign it for integrity protection. Each DS file has a unique numerical ID assigned by the system. Diagnostic Signatures Lookup Tool (DSLT) is a single source to find applicable signatures for monitoring and troubleshooting various problems.
Before you begin:
-
Do not edit the DS file that you download from DSLT. The files that you modify fail installation due to the integrity check error.
-
A Simple Mail Transfer Protocol (SMTP) server you require for the Local Gateway to send out email notifications.
-
Ensure that the Local Gateway is running IOS XE 17.6.1 or higher if you wish to use the secure SMTP server for email notifications.
Prerequisites
Local Gateway running IOS XE 17.6.1a or higher
-
Diagnostic Signatures is enabled by default.
-
Configure the secure email server to be used to send proactive notification if the device is running Cisco IOS XE 17.6.1a or higher.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end -
Configure the environment variable ds_email with the email address of the administrator to notify you.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
The following shows an example configuration of a Local Gateway running on Cisco IOS XE 17.6.1a or higher to send the proactive notifications to tacfaststart@gmail.com using Gmail as the secure SMTP server:
| We recommend you to use the Cisco IOS XE Bengaluru 17.6.x or later versions. |
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com" | A Local Gateway running on Cisco IOS XE Software is not a typical web-based Gmail client that supports OAuth, so we must configure a specific Gmail account setting and provide specific permission to have the email from the device processed correctly: |
-
Go to and turn on the Less secure app access setting.
-
Answer “Yes, it was me” when you receive an email from Gmail stating “Google prevented someone from signing into your account using a non-Google app.”
Install diagnostic signatures for proactive monitoring
Monitoring high CPU utilization
This DS tracks CPU utilization for five seconds using the SNMP OID 1.3.6.1.4.1.9.2.1.56. When the utilization reaches 75% or more, it disables all debugs and uninstalls all diagnostic signatures that are installed in the Local Gateway. Use these steps below to install the signature.
-
Use the show snmp command to enable SNMP. If you do not enable, then configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled -
Download DS 64224 using the following drop-down options in Diagnostic Signatures Lookup Tool:
Field Name
Field Value
Platform
Cisco 4300, 4400 ISR Series or Cisco CSR 1000V Series
Product
CUBE Enterprise in Webex Calling Solution
Problem Scope
Performance
Problem Type
High CPU Utilization with Email Notification.
-
Copy the DS XML file to the Local Gateway flash.
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:The following example shows copying the file from an FTP server to the Local Gateway.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec) -
Install the DS XML file in the Local Gateway.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success -
Use the show call-home diagnostic-signature command to verify that the signature is successfully installed. The status column should have a “registered” value.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.comDownload DSes:
DS ID
DS Name
Revision
Status
Last Update (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Registered
2020-11-07 22:05:33
When triggered, this signature uninstalls all running DSs including itself. If necessary, reinstall DS 64224 to continue monitoring high CPU utilization on the Local Gateway.
Monitoring SIP trunk registration
This DS checks for unregistration of a Local Gateway SIP Trunk with Webex Calling cloud every 60 seconds. Once the unregistration event is detected, it generates an email and syslog notification and uninstalls itself after two unregistration occurrences. Use the steps below to install the signature:
-
Download DS 64117 using the following drop-down options in Diagnostic Signatures Lookup Tool:
Field Name
Field Value
Platform
Cisco 4300, 4400 ISR Series or Cisco CSR 1000V Series
Product
CUBE Enterprise in Webex Calling Solution
Problem Scope
SIP-SIP
Problem Type
SIP Trunk Unregistration with Email Notification.
-
Copy the DS XML file to the Local Gateway.
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash: -
Install the DS XML file in the Local Gateway.
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway# -
Use the show call-home diagnostic-signature command to verify that the signature is successfully installed. The status column must have a “registered” value.
Monitoring abnormal call disconnects
This DS uses SNMP polling every 10 minutes to detect abnormal call disconnect with SIP errors 403, 488 and 503. If the error count increment is greater than or equal to 5 from the last poll, it generates a syslog and email notification. Please use the steps below to install the signature.
-
Use the show snmp command to check whether SNMP is enabled. If it is not enabled, configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled -
Download DS 65221 using the following options in Diagnostic Signatures Lookup Tool:
Field Name
Field Value
Platform
Cisco 4300, 4400 ISR Series or Cisco CSR 1000V Series
Product
CUBE Enterprise in Webex Calling Solution
Problem Scope
Performance
Problem Type
SIP abnormal call disconnect detection with Email and Syslog Notification.
-
Copy the DS XML file to the Local Gateway.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash: -
Install the DS XML file in the Local Gateway.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success -
Use the show call-home diagnostic-signature command to verify that the signature is successfully installed. The status column must have a “registered” value.
Install diagnostic signatures to troubleshoot a problem
Use Diagnostic Signatures (DS) to resolve issues quickly. Cisco TAC engineers have authored several signatures that enable the necessary debugs that are required to troubleshoot a given problem, detect the problem occurrence, collect the right set of diagnostic data and transfer the data automatically to the Cisco TAC case. Diagnostic Signatures (DS) eliminate the need to manually check for the problem occurrence and makes troubleshooting of intermittent and transient issues a lot easier.
You can use the Diagnostic Signatures Lookup Tool to find the applicable signatures and install them to self-solve a given issue or you can install the signature that is recommended by the TAC engineer as part of the support engagement.
Here is an example of how to find and install a DS to detect the occurrence “%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0" syslog and automate diagnostic data collection using the following steps:
-
Configure an additional DS environment variable ds_fsurl_prefix which is the Cisco TAC file server path (cxd.cisco.com) to which the collected diagnostics data are uploaded. The username in the file path is the case number and the password is the file upload token which can be retrieved from Support Case Manager in the following command. The file upload token can be generated in the Attachments section of the Support Case Manager, as needed.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" endExample:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com" -
Ensure that SNMP is enabled using the show snmp command. If it is not enabled, configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end -
Ensure to install the High CPU monitoring DS 64224 as a proactive measure to disable all debugs and diagnostics signatures during the time of high CPU utilization. Download DS 64224 using the following options in Diagnostic Signatures Lookup Tool:
Field Name
Field Value
Platform
Cisco 4300, 4400 ISR Series or Cisco CSR 1000V Series
Product
CUBE Enterprise in Webex Calling Solution
Problem Scope
Performance
Problem Type
High CPU Utilization with Email Notification.
-
Download DS 65095 using the following options in Diagnostic Signatures Lookup Tool:
Field Name
Field Value
Platform
Cisco 4300, 4400 ISR Series or Cisco CSR 1000V Series
Product
CUBE Enterprise in Webex Calling Solution
Problem Scope
Syslogs
Problem Type
Syslog - %VOICE_IEC-3-GW: CCAPI: Internal Error (Call spike threshold): IEC=1.1.181.1.29.0
-
Copy the DS XML files to the Local Gateway.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash: -
Install the High CPU monitoring DS 64224 and then DS 65095 XML file in the Local Gateway.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success -
Verify that the signature is successfully installed using the show call-home diagnostic-signature command. The status column must have a “registered” value.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comDownloaded DSes:
DS ID
DS Name
Revision
Status
Last Update (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Registered
2020-11-08
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Registered
2020-11-08
Verify diagnostic signatures execution
In the following command, the “Status” column of the show call-home diagnostic-signature command changes to “running” while the Local Gateway executes the action defined within the signature. The output of show call-home diagnostic-signature statistics is the best way to verify whether a diagnostic signature detects an event of interest and executes the action. The “Triggered/Max/Deinstall” column indicates the number of times the given signature has triggered an event, the maximum number of times it is defined to detect an event and whether the signature deinstalls itself after detecting the maximum number of triggered events.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Downloaded DSes:
|
DS ID |
DS Name |
Revision |
Status |
Last Update (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Registered |
2020-11-08 00:07:45 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Running |
2020-11-08 00:12:53 |
show call-home diagnostic-signature statistics
|
DS ID |
DS Name |
Triggered/Max/Deinstall |
Average Run Time (seconds) |
Max Run Time (seconds) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/Y |
23.053 |
23.053 |
The notification email that is sent during diagnostic signature execution contains key information such as issue type, device details, software version, running configuration, and show command outputs that are relevant to troubleshoot the given problem.
Uninstall diagnostic signatures
Use Diagnostic signatures for troubleshooting purposes are typically defined to uninstall after detection of some problem occurrences. If you want to uninstall a signature manually, retrieve the DS ID from the output of the show call-home diagnostic-signature command and run the following command:
call-home diagnostic-signature deinstall <DS ID>
Example:
call-home diagnostic-signature deinstall 64224
| New signatures are added to Diagnostics Signatures Lookup Tool periodically, based on issues that are commonly observed in deployments. TAC currently doesn’t support requests to create new custom signatures. |
For better management of Cisco IOS XE Gateways, we recommend that you enroll and manage the gateways through the Control Hub. It is an optional configuration. When enrolled, you can use the configuration validation option in the Control Hub to validate your Local Gateway configuration and identify any configuration issues. Currently, only registration-based trunks support this functionality.
For more information, refer the following:
This section describes how to configure a Cisco Unified Border Element (CUBE) as a Local Gateway for Webex Calling, using certificate-based mutual TLS (mTLS) SIP trunk. The first part of this document illustrates how to configure a simple PSTN gateway. In this case, all calls from the PSTN are routed to Webex Calling and all calls from Webex Calling are routed to the PSTN. The following image highlights this solution and the high-level call routing configuration that will be followed.
In this design, the following principal configurations are used:
-
voice class tenants: Used to create trunk specific configurations.
-
voice class uri: Used to classify SIP messages for the selection of an inbound dial-peer.
-
inbound dial-peer: Provides treatment for inbound SIP messages and determines the outbound route with a dial-peer group.
-
dial-peer group: Defines the outbound dial-peers used for onward call routing.
-
outbound dial-peer: Provides treatment for outbound SIP messages and routes them to the required target.
When connecting an on-premises Cisco Unified Communications Manager solution with Webex Calling, you can use the simple PSTN gateway configuration as a baseline for building the solution illustrated in the following diagram. In this case, Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls.
Throughout this document, the host names, IP addresses, and interfaces illustrated in the following image are used. Options are provided for public or private (behind NAT) addressing. SRV DNS records are optional, unless load balancing across multiple CUBE instances.
Use the configuration guidance in the rest of this document to complete your Local Gateway configuration as follows:
-
Step 1: Configure router baseline connectivity and security
-
Step 2: Configure Webex Calling Trunk
Depending on your required architecture, follow either:
-
Step 3: Configure Local Gateway with SIP PSTN trunk
-
Step 4: Configure Local Gateway with existing Unified CM environment
Or:
-
Step 3: Configure Local Gateway with TDM PSTN trunk
Baseline configuration
The first step in preparing your Cisco router as a Local Gateway for Webex Calling is to build a baseline configuration that secures your platform and establishes connectivity.
-
All certificate-based Local Gateway deployments require Cisco IOS XE 17.9.1a or later versions. For the recommended versions, see the Cisco Software Research page. Search for the platform and select one of the suggested releases.
-
ISR4000 series routers must be configured with both Unified Communications and Security technology licenses.
-
Catalyst Edge 8000 series routers fitted with voice cards or DSPs require DNA Essentials licensing. Routers without voice cards or DSPs require a minimum of DNA Essentials licensing.
-
For high-capacity requirements, you may also require a High Security (HSEC) license and additional throughput entitlement.
Refer to Authorization Codes for further details.
-
-
Build a baseline configuration for your platform that follows your business policies. In particular, configure the following and verify the working:
-
NTP
-
ACLs
-
User authentication and remote access
-
DNS
-
IP routing
-
IP addresses
-
-
The network toward Webex Calling must use a IPv4 address. Local Gateway Fully Qualified Domain Names (FQDN) or Service Record (SRV) addresses must resolve to a public IPv4 address on the internet.
-
All SIP and media ports on the Local Gateway interface facing Webex must be accessible from the internet, either directly or via static NAT. Ensure that you update your firewall accordingly.
-
Install a signed certificate on the Local Gateway (the following provides detailed configuration steps).
-
A public Certificate Authority (CA) as detailed in What Root Certificate Authorities are Supported for Calls to Cisco Webex Audio and Video Platforms? must sign the device certificate.
-
The FQDN configured in the Control Hub when creating a trunk must be the Common Name (CN) or Subject Alternate Name (SAN) certificate of the router. For example:
-
If a configured trunk in the Control Hub of your organization has cube1.lgw.com:5061 as FQDN of the Local Gateway, then the CN or SAN in the router certificate must contain cube1.lgw.com.
-
If a configured trunk in the Control Hub of your organization has lgws.lgw.com as the SRV address of the Local Gateway(s) reachable from the trunk, then the CN or SAN in the router certificate must contain lgws.lgw.com. The records that the SRV address resolves to (CNAME, A Record, or IP Address) are optional in SAN.
-
Whether you use an FQDN or SRV for the trunk, the contact address for all new SIP dialogs from your Local Gateway uses the name configured in the Control Hub.
-
-
-
Ensure that certificates are signed for client and server usage.
-
Upload the Cisco root CA bundle to the Local Gateway.
Configuration
| 1 |
Ensure that you assign valid and routable IP addresses to any Layer 3 interfaces, for example:
| ||
| 2 |
Protect STUN credentials on the router using symmetric encryption. Configure the primary encryption key and encryption type as follows: | ||
| 3 |
Create an encryption trustpoint with a certificate signed by your preferred Certificate Authority (CA). | ||
| 4 |
Authenticate your new certificate using your intermediate (or root) CA certificate, then import the certificate (Step 4). Enter the following exec or configuration command:
| ||
| 5 |
Import a signed host certificate using the following exec or configuration command:
| ||
| 6 |
Enable TLS1.2 exclusivity and specify the default trustpoint using the following configuration commands:
| ||
| 7 |
Install the Cisco root CA bundle, which includes the DigiCert CA certificate used by Webex Calling. Use the crypto pki trustpool import clean url command to download the root CA bundle from the specified URL, and to clear the current CA trustpool, then install the new bundle of certificates:
|
| 1 |
Create a CUBE certificate-based PSTN trunk for an existing location in Control Hub. For more information, see Configure trunks, route groups, and dial plans for Webex Calling.
| ||||
| 2 |
Enter the following commands to configure CUBE as a Webex Calling Local Gateway: Here's an explanation of the fields for the configuration:
Enables Cisco Unified Border Element (CUBE) features on the platform. allow-connections sip to sipEnable CUBE basic SIP back to back user agent functionality. For more information, see Allow connections.
Enables STUN (Session Traversal of UDP through NAT) globally.
For more information, see stun flowdata agent-id and stun flowdata shared-secret. asymmetric payload fullConfigures SIP asymmetric payload support for both DTMF and dynamic codec payloads. For more information on this command, see asymmetric payload. early-offer forcedForces the Local Gateway to send SDP information in the initial INVITE message instead of waiting for acknowledgment from the neighboring peer. For more information on this command, see early-offer. sip-profiles inboundEnables CUBE to use SIP profiles to modify messages as they are received. Profiles are applied via dial-peers or tenants. | ||||
| 3 |
Configure voice class codec 100 codec filter for the trunk. In this example, the same codec filter is used for all trunks. You can configure filters for each trunk for precise control. Here's an explanation of the fields for the configuration: voice class codec 100Used to only allow preferred codecs for calls through SIP trunks. For more information, see voice class codec.
| ||||
| 4 |
Configure voice class stun-usage 100 to enable ICE on the Webex Calling trunk. (This step is not applicable for Webex for Government) Here's an explanation of the fields for the configuration: stun usage ice liteUsed to enable ICE-Lite for all Webex Calling facing dial-peers to allow media-optimization whenever possible. For more information, see voice class stun usage and stun usage ice lite.
| ||||
| 5 |
Configure the media encryption policy for Webex traffic. (This step is not applicable for Webex for Government) Here's an explanation of the fields for the configuration: voice class srtp-crypto 100Specifies SHA1_80 as the only SRTP cipher-suite CUBE offers in the SDP in offer and answer messages. Webex Calling only supports SHA1_80. For more information, see voice class srtp-crypto. | ||||
| 6 |
Configure FIPS-compliant GCM ciphers (This step is applicable only for Webex for Government). Here's an explanation of the fields for the configuration: voice class srtp-crypto 100Specifies GCM as the cipher-suite that CUBE offers. It is mandatory to configure GCM ciphers for Local Gateway for Webex for Government. | ||||
| 7 |
Configure a pattern to uniquely identify calls to a Local Gateway trunk based on its destination FQDN or SRV: Here's an explanation of the fields for the configuration: voice class uri 100 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use LGW FQDN or SRV configured in Control Hub while creating a trunk. | ||||
| 8 |
Configure SIP message manipulation profiles. If your gateway is configured with a public IP address, configure a profile as follows or skip to the next step if you are using NAT. In this example, cube1.lgw.com is the FQDN configured for the Local Gateway and "198.51.100.1" is the public IP address of the Local Gateway interface facing Webex Calling: Here's an explanation of the fields for the configuration: rules 10 and 20To allow Webex to authenticate messages from your local gateway, the 'Contact' header in SIP request and responses messages must contain the value provisioned for the trunk in Control Hub. This will either be the FQDN of a single host, or the SRV domain name used for a cluster of devices.
| ||||
| 9 |
If your gateway is configured with a private IP address behind static NAT, configure inbound and outbound SIP profiles as follows. In this example, cube1.lgw.com is the FQDN configured for the Local Gateway, "10.80.13.12" is the interface IP address facing Webex Calling and "192.65.79.20" is the NAT public IP address.
SIP profiles for outbound messages to Webex
Calling
Here's an explanation of the fields for the configuration: rules 10 and 20To allow Webex to authenticate messages from your local gateway, the 'Contact' header in SIP request and responses messages must contain the value provisioned for the trunk in Control Hub. This will either be the FQDN of a single host, or the SRV domain name used for a cluster of devices. rules 30 to 81Convert private address references to the external public address for the site, allowing Webex to correctly interpret and route subsequent messages. SIP profile for inbound messages from Webex CallingHere's an explanation of the fields for the configuration: rules 10 to 80Convert public address references to the configured private address, allowing messages from Webex to be correctly processed by CUBE. For more information, see voice class sip-profiles. | ||||
| 10 |
Configure a SIP Options keepalive with header modification profile. Here's an explanation of the fields for the configuration: voice class sip-options-keepalive 100Configures a keepalive profile and enters voice class configuration mode. You can configure the time (in seconds) at which an SIP Out of Dialog Options Ping is sent to the dial-target when the heartbeat connection to the endpoint is in UP or Down status. This keepalive profile is triggered from the dial-peer configured towards Webex. To ensure that the contact headers include the SBC fully qualified domain name, SIP profile 115 is used. Rules 30, 40, and 50 are required only when the SBC is configured behind static NAT. In this example, cube1.lgw.com is the FQDN selected for the Local Gateway and if static NAT is used, "10.80.13.12" is the SBC interface IP address towards Webex Calling and "192.65.79.20" is the NAT public IP address. | ||||
| 11 |
Configure Webex Calling trunk:
|
Having built a trunk towards Webex Calling above, use the following configuration to create a non-encrypted trunk towards a SIP based PSTN provider:
| If your Service Provider offers a secure PSTN trunk, you may follow a similar configuration as detailed above for the Webex Calling trunk. Secure to secure call routing is supported by CUBE. |
| To configure TDM interfaces for PSTN call legs on the Cisco TDM-SIP Gateways, see Configuring ISDN PRI. |
| 1 |
Configure the following voice class uri to identify inbound calls from the PSTN trunk: Here's an explanation of the fields for the configuration: voice class uri 200 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use the IP address of you IP PSTN gateway. For more information, see voice class uri. |
| 2 |
Configure the following IP PSTN dial-peer: Here's an explanation of the fields for the configuration: Defines a VoIP dial-peer with a tag of 200 and gives a meaningful description for ease of management and troubleshooting. For more information, see dial-peer voice. destination-pattern BAD.BADA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). session protocol sipv2Specifies that dial-peer 200 handles SIP call legs. For more information, see session protocol (dial peer). session target ipv4:192.168.80.13Indicates the destination’s target IPv4 address to send the call leg. The session target here is ITSP’s IP address. For more information, see session target (VoIP dial peer). incoming uri via 200Defines a match criterion for the VIA header with the IP PSTN’s IP address. Matches all incoming IP PSTN call legs on the Local Gateway with dial-peer 200. For more information, see incoming url. bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent to PSTN. For more information, see bind. voice-class codec 100Configures the dial-peer to use the common codec filter list 100. For more information, see voice-class codec. dtmf-relay rtp-nteDefines RTP-NTE (RFC2833) as the DTMF capability expected on the call leg. For more information, see DTMF Relay (Voice over IP). no vadDisables voice activity detection. For more information, see vad (dial peer). |
| 3 |
If you are configuring your Local Gateway to only route calls between Webex Calling and the PSTN, add the following call routing configuration. If you are configuring your Local Gateway with a Unified Communications Manager platform, skip to the next section. |
The PSTN-Webex Calling configuration in the previous sections may be modified to include additional trunks to a Cisco Unified Communications Manager (UCM) cluster. In this case, all calls are routed via Unified CM. Calls from UCM on port 5060 are routed to the PSTN and calls from port 5065 are routed to Webex Calling. The following incremental configurations may be added to include this calling scenario.
| 1 |
Configure the following voice class URIs: | ||
| 2 |
Configure the following DNS records to specify SRV routing to Unified CM hosts:
Here's an explanation of the fields for the configuration: The following command creates a DNS SRV resource record. Create a record for each UCM host and trunk: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: SRV resource record name 2: The SRV resource record priority 1: The SRV resource record weight 5060: The port number to use for the target host in this resource record ucmsub5.mydomain.com: The resource record target host To resolve the resource record target host names, create local DNS A records. For example: ip host ucmsub5.mydomain.com 192.168.80.65 ip host: Creates a record in the local IOS XE database. ucmsub5.mydomain.com: The A record host name. 192.168.80.65: The host IP address. Create the SRV resource records and A records to reflect your UCM environment and preferred call distribution strategy. | ||
| 3 |
Configure the following dial-peers: | ||
| 4 |
Add call routing using the following configurations: |
Diagnostic Signatures (DS) proactively detects commonly observed issues in the Cisco IOS XE-based Local Gateway and generates email, syslog, or terminal message notification of the event. You can also install the DS to automate diagnostics data collection and transfer collected data to the Cisco TAC case to accelerate resolution time.
Diagnostic Signatures (DS) are XML files that contain information about problem trigger events and actions to inform, troubleshoot, and remediate the issue. Use syslog messages, SNMP events and through periodic monitoring of specific show command outputs to define the problem detection logic. The action types include:
-
Collecting show command outputs
-
Generating a consolidated log file
-
Uploading the file to a user provided network location such as HTTPS, SCP, FTP server
TAC engineers author DS files and digitally sign it for integrity protection. Each DS file has the unique numerical ID assigned by the system. Diagnostic Signatures Lookup Tool (DSLT) is a single source to find applicable signatures for monitoring and troubleshooting various problems.
Before you begin:
-
Do not edit the DS file that you download from DSLT. The files that you modify fail installation due to the integrity check error.
-
A Simple Mail Transfer Protocol (SMTP) server you require for the Local Gateway to send out email notifications.
-
Ensure that the Local Gateway is running IOS XE 17.6.1 or higher if you wish to use the secure SMTP server for email notifications.
Prerequisites
Local Gateway running IOS XE 17.6.1 or higher
-
Diagnostic Signatures is enabled by default.
-
Configure the secure email server that you use to send proactive notification if the device is running IOS XE 17.6.1 or higher.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end -
Configure the environment variable ds_email with the email address of the administrator to you notify.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
Install diagnostic signatures for proactive monitoring
Monitoring high CPU utilization
This DS tracks 5-seconds CPU utilization using the SNMP OID 1.3.6.1.4.1.9.2.1.56. When the utilization reaches 75% or more, it disables all debugs and uninstalls all diagnostic signatures that you install in the Local Gateway. Use these steps below to install the signature.
-
Ensure that you enabled SNMP using the command show snmp. If SNMP is not enabled, then configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled Download DS 64224 using the following drop-down options in Diagnostic Signatures Lookup Tool:
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:Field Name
Field Value
Platform
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
Product
CUBE Enterprise in Webex Calling solution
Problem Scope
Performance
Problem Type
High CPU Utilization with Email Notification
-
Copy the DS XML file to the Local Gateway flash.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:The following example shows copying the file from an FTP server to the Local Gateway.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec) -
Install the DS XML file in the Local Gateway.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success -
Use the show call-home diagnostic-signature command to verify that the signature is successfully installed. The status column must have a “registered” value.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.comDownload DSes:
DS ID
DS Name
Revision
Status
Last Update (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Registered
2020-11-07 22:05:33
When triggered, this signature uninstalls all running DSs including itself. If necessary, please reinstall DS 64224 to continue monitoring high CPU utilization on the Local Gateway.
Monitoring abnormal call disconnects
This DS uses SNMP polling every 10 minutes to detect abnormal call disconnect with SIP errors 403, 488 and 503. If the error count increment is greater than or equal to 5 from the last poll, it generates a syslog and email notification. Please use the steps below to install the signature.
-
Ensure that SNMP is enabled using the command show snmp. If SNMP is not enabled, configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled -
Download DS 65221 using the following options in Diagnostic Signatures Lookup Tool:
Field Name
Field Value
Platform
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
Product
CUBE Enterprise in Webex Calling Solution
Problem Scope
Performance
Problem Type
SIP abnormal call disconnect detection with Email and Syslog Notification.
-
Copy the DS XML file to the Local Gateway.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash: -
Install the DS XML file in the Local Gateway.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success -
Use the command show call-home diagnostic-signature to verify that the signature is successfully installed. The status column should have a “registered” value.
Install diagnostic signatures to troubleshoot a problem
You can also use Diagnostic Signatures (DS) to resolve issues quickly. Cisco TAC engineers have authored several signatures that enable the necessary debugs that are required to troubleshoot a given problem, detect the problem occurrence, collect the right set of diagnostic data and transfer the data automatically to the Cisco TAC case. This eliminates the need to manually check for the problem occurrence and makes troubleshooting of intermittent and transient issues a lot easier.
You can use the Diagnostic Signatures Lookup Tool to find the applicable signatures and install them to selfsolve a given issue or you can install the signature that is recommended by the TAC engineer as part of the support engagement.
Here is an example of how to find and install a DS to detect the occurrence “%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0" syslog and automate diagnostic data collection using the following steps:
Configure another DS environment variable ds_fsurl_prefix as the Cisco TAC file server path (cxd.cisco.com) to upload the diagnostics data. The username in the file path is the case number and the password is the file upload token which can be retrieved from Support Case Manager as shown in the following. The file upload token can be generated in the Attachments section of the Support Case Manager, as required.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" endExample:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"-
Ensure that SNMP is enabled using the command show snmp. If SNMP not enabled, configure the snmp-server manager command.
show snmp %SNMP agent not enabled config t snmp-server manager end -
We recommend installing the High CPU monitoring DS 64224 as a proactive measure to disable all debugs and diagnostics signatures during the time of high CPU utilization. Download DS 64224 using the following options in Diagnostic Signatures Lookup Tool:
Field Name
Field Value
Platform
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
Product
CUBE Enterprise in Webex Calling Solution
Problem Scope
Performance
Problem Type
High CPU Utilization with Email Notification.
-
Download DS 65095 using the following options in Diagnostic Signatures Lookup Tool:
Field Name
Field Value
Platform
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
Product
CUBE Enterprise in Webex Calling Solution
Problem Scope
Syslogs
Problem Type
Syslog - %VOICE_IEC-3-GW: CCAPI: Internal Error (Call spike threshold): IEC=1.1.181.1.29.0
-
Copy the DS XML files to the Local Gateway.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash: -
Install the high CPU monitoring DS 64224 and then DS 65095 XML file in the Local Gateway.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success -
Verify that the signature is successfully installed using show call-home diagnostic-signature. The status column should have a “registered” value.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comDownloaded DSes:
DS ID
DS Name
Revision
Status
Last Update (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Registered
2020-11-08:00:07:45
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Registered
2020-11-08:00:12:53
Verify diagnostic signatures execution
In the following command, the “Status” column of the command show call-home diagnostic-signature changes to “running” while the Local Gateway executes the action defined within the signature. The output of show call-home diagnostic-signature statistics is the best way to verify whether a diagnostic signature detects an event of interest and executed the action. The “Triggered/Max/Deinstall” column indicates the number of times the given signature has triggered an event, the maximum number of times it is defined to detect an event and whether the signature deinstalls itself after detecting the maximum number of triggered events.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Downloaded DSes:
|
DS ID |
DS Name |
Revision |
Status |
Last Update (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Registered |
2020-11-08 00:07:45 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Running |
2020-11-08 00:12:53 |
show call-home diagnostic-signature statistics
|
DS ID |
DS Name |
Triggered/Max/Deinstall |
Average Run Time (seconds) |
Max Run Time (seconds) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/Y |
23.053 |
23.053 |
The notification email that is sent during Diagnostic Signature execution contains key information such as issue type, device details, software version, running configuration and show command outputs that are relevant to troubleshoot the given problem.
Uninstall diagnostic signatures
Use the diagnostic signatures for troubleshooting purposes are typically defined to uninstall after detection of some problem occurrences. If you wish to uninstall a signature manually, retrieve the DS ID from the output of show call-home diagnostic-signature and run the following command:
call-home diagnostic-signature deinstall <DS ID> Example:
call-home diagnostic-signature deinstall 64224
| New signatures are added to the Diagnostics Signatures Lookup Tool periodically, based on issues that are observed in deployments. TAC currently doesn’t support requests to create new custom signatures. |
Fundamentals
Prerequisites
Before you deploy CUBE HA as a local gateway for Webex Calling, make sure you have an in-depth understanding of the following concepts:
-
Layer 2 box-to-box redundancy with CUBE Enterprise for stateful call preservation
The configuration guidelines provided in this article assume a dedicated local gateway platform with no existing voice configuration. If an existing CUBE enterprise deployment is being modified to also utilize the local gateway function for Cisco Webex Calling, pay close attention to the configuration applied to ensure existing call flows and functionalities are not interrupted and make sure you're adhering to CUBE HA design requirements.
Hardware and Software Components
CUBE HA as local gateway requires IOS-XE version 16.12.2 or later and a platform on which both CUBE HA and LGW functions are supported.
| The show commands and logs in this article are based on minimum software release of Cisco IOS-XE 16.12.2 implemented on a vCUBE (CSR1000v). |
Reference Material
Here are some detailed CUBE HA configuration guides for various platforms:
-
ISR 4K series— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
-
CSR 1000v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
-
Cisco Preferred Architecture for Cisco Webex Calling— https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Calling Solution Overview
Cisco Webex Calling is a collaboration offering that provides a multi-tenant cloud-based alternative to on-premise PBX phone service with multiple PSTN options for customers.
The Local Gateway deployment (represented below) is the focus of this article. Local gateway (Premises-based PSTN) trunk in Webex Calling allows connectivity to a customer-owned PSTN service. It also provides connectivity to an on-premises IP PBX deployment such as Cisco Unified CM. All communication to and from the cloud is secured using TLS transport for SIP and SRTP for media.
The figure below displays a Webex Calling deployment without any existing IP PBX and is applicable to a single or a multi-site deployment. Configuration outlined in this article is based on this deployment.
Layer 2 Box-to-Box Redundancy
CUBE HA layer 2 box-to-box redundancy uses the Redundancy Group (RG) infrastructure protocol to form an active/standby pair of routers. This pair share the same virtual IP address (VIP) across their respective interfaces and continually exchange status messages. CUBE session information is check-pointed across the pair of routers enabling the standby router to take all CUBE call processing responsibilities over immediately if the active router goes out of service, resulting in stateful preservation of signaling and media.
| Check pointing is limited to connected calls with media packets. Calls in transit are not check pointed (for example, a trying or ringing state). In this article, CUBE HA will refer to CUBE High Availability (HA) Layer 2 Box-to-box (B2B) redundancy for stateful call preservation |
As of IOS-XE 16.12.2, CUBE HA can be deployed as a Local Gateway for Cisco Webex Calling trunk (Premises-based PSTN) deployments and we’ll cover design considerations and configurations in this article. This figure displays a typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment.
Redundancy Group Infra Component
The Redundancy Group (RG) Infra component provides the box-to-box communication infrastructure support between the two CUBEs and negotiates the final stable redundancy state. This component also provides:
-
An HSRP-like protocol that negotiates the final redundancy state for each router by exchanging keepalive and hello messages between the two CUBEs (via the control interface)—GigabitEthernet3 in the figure above.
-
A transport mechanism for checkpointing the signaling and media state for each call from the active to the standby router (via the data interface)—GigabitEthernet3 in the figure above.
-
Configuration and management of the Virtual IP (VIP) interface for the traffic interfaces (multiple traffic interfaces can be configured using the same RG group) – GigabitEthernet 1 and 2 are considered traffic interfaces.
This RG component has to be specifically configured to support voice B2B HA.
Virtual IP (VIP) Address Management for Both Signaling and Media
B2B HA relies on VIP to achieve redundancy. The VIP and associated physical interfaces on both CUBEs in the CUBE HA pair must reside on the same LAN subnet. Configuration of the VIP and binding of the VIP interface to a particular voice application (SIP) are mandatory for voice B2B HA support. External devices such as Unified CM, Webex Calling access SBC, service provider, or proxy, use VIP as the destination IP address for the calls traversing through the CUBE HA routers. Hence, from a Webex Calling point of view, the CUBE HA pairs acts as a single local gateway.
The call signaling and RTP session information of established calls are checkpointed from the active router to the standby router. When the Active router goes down, the Standby router takes over, and continues to forward the RTP stream that was previously routed by the first router.
Calls in a transient state at the time of failover will not be preserved post-switchover. For example, calls that aren't fully established yet or are in the process of being modified with a transfer or hold function. Established calls may be disconnected post-switchover.
The following requirements exist for using CUBE HA as a local gateway for stateful failover of calls:
-
CUBE HA cannot have TDM or analog interfaces co-located
-
Gig1 and Gig2 are referred to as traffic (SIP/RTP) interfaces and Gig3 is Redundancy Group (RG) Control/data interface
-
No more than 2 CUBE HA pairs can be placed in the same layer 2 domain, one with group id 1 and the other with group id 2. If configuring 2 HA pairs with the same group id, RG Control/Data interfaces needs to belong to different layer 2 domains (vlan, separate switch)
-
Port channel is supported for both RG Control/data and traffic interfaces
-
All signaling/media is sourced from/to the Virtual IP Address
-
Anytime a platform is reloaded in a CUBE-HA relationship, it always boots up as Standby
-
Lower address for all the interfaces (Gig1, Gig2, Gig3) should be on the same platform
-
Redundancy Interface Identifier, rii should be unique to a pair/interface combination on the same Layer 2
-
Configuration on both the CUBEs must be identical including physical configuration and must be running on the same type of platform and IOS-XE version
-
Loopback interfaces cannot be used as bind as they are always up
-
Multiple traffic (SIP/RTP) interfaces (Gig1, Gig2) require interface tracking to be configured
-
CUBE-HA is not supported over a crossover cable connection for the RG-control/data link (Gig3)
-
Both platforms must be identical and be connected via a physical Switch across all likewise interfaces for CUBE HA to work, i.e. GE0/0/0 of CUBE-1 and CUBE-2 must terminate on the same switch and so on.
-
Cannot have WAN terminated on CUBEs directly or Data HA on either side
-
Both Active/Standby must be in the same data center
-
It is mandatory to use separate L3 interface for redundancy (RG Control/data, Gig3). i.e interface used for traffic cannot be used for HA keepalives and checkpointing
-
Upon failover, the previously active CUBE goes through a reload by design, preserving signaling and media
Configure Redundancy on Both CUBEs
You must configure layer 2 box-to-box redundancy on both CUBEs intended to be used in an HA pair to bring up virtual IPs.
| 1 |
Configure interface tracking at a global level to track the status of the interface.
Track CLI is used in RG to track the voice traffic interface state so that the active route will quite its active role after the traffic interface is down. | ||||||
| 2 |
Configure an RG for use with VoIP HA under the application redundancy sub-mode.
Here's an explanation of the fields used in this configuration:
| ||||||
| 3 |
Enable box-to-box redundancy for the CUBE application. Configure the RG from the previous step under
redundancy-group 1—Adding and removing this command requires a reload for the updated configuration to take effect. We'll reload the platforms after all the configuration has been applied. | ||||||
| 4 |
Configure the Gig1 and Gig2 interfaces with their respective virtual IPs as shown below and apply the redundancy interface identifier (rii)
Here's an explanation of the fields used in this configuration:
| ||||||
| 5 |
Save the configuration of the first CUBE and reload it. The platform to reload last is always the Standby.
After VCUBE-1 boots up completely, save the configuration of VCUBE-2 and reload it.
| ||||||
| 6 |
Verify that the box-to-box configuration is working as expected. Relevant output is highlighted in bold. We reloaded VCUBE-2 last and as per the design considerations; the platform to reload last will always be Standby. |
Configure a Local Gateway on Both CUBEs
In our example configuration, we’re using the following trunk information from Control Hub to build the Local Gateway configuration on both the platforms, VCUBE-1 and VCUBE-2. The username and password for this setup are as follows:
-
Username: Hussain1076_LGU
-
Password: lOV12MEaZx
| 1 |
Ensure that a configuration key is created for the password, with the commands shown below, before it can be used in the credentials or shared secrets. Type 6 passwords are encrypted using AES cipher and this user-defined configuration key.
Here is the Local Gateway configuration that will apply to both platforms based on the Control Hub parameters displayed above, save and reload. SIP Digest credentials from Control Hub are highlighted in bold.
To display the show command output, we've reloaded VCUBE-2 followed by VCUBE-1, making VCUBE-1 the standby CUBE and VCUBE-2 the active CUBE |
| 2 |
At any given time, only one platform will maintain an active registration as the Local Gateway with the Webex Calling access SBC. Take a look at the output of the following show commands. show redundancy application group 1 show sip-ua register status
From the output above, you can see that VCUBE-2 is the active LGW maintaining the registration with Webex Calling access SBC, whereas the output of the “show sip-ua register status” is blank in VCUBE-1 |
| 3 |
Now enable the following debugs on VCUBE-1
|
| 4 |
Simulate failover by issuing the following command on the active LGW, VCUBE-2 in this case.
Switchover from the ACTIVE to the STANDBY LGW occurs in the following scenario as well besides the CLI listed above
|
| 5 |
Check to see if VCUBE-1 has registered with Webex Calling access SBC. VCUBE-2 would have reloaded by now.
VCUBE-1 is now the active LGW. |
| 6 |
Look at the relevant debug log on VCUBE-1 sending a SIP REGISTER to Webex Calling VIA the virtual IP and receiving a 200 OK.
|
Configure SIP Trunk Security Profile for Trunk to Local Gateway
In cases where Local Gateway and PSTN gateway reside on the same device, Unified CM must be enabled to differentiate between two different traffic types (calls from Webex and from the PSTN) that are originating from the same device and apply differentiated class of service to these call types. This differentiated call treatment is achieved by provisioning two trunks between Unified CM and the combined local gateway and PSTN gateway device which requires different SIP listening ports for the two trunks.
|
Create a dedicated SIP Trunk Security Profile for the Local Gateway trunk with the following settings:
| ||||||||||
Configure SIP Profile for the Local Gateway Trunk
|
Create a dedicated SIP Profile for the Local Gateway trunk with the following settings:
| ||||||||||
Create a Calling Search Space for Calls From Webex
|
Create a calling search space for calls originating from Webex with the following settings:
| ||||||||||||
Configure a SIP Trunk To and From Webex
|
Create a SIP trunk for the calls to and from Webex via the Local Gateway with the following settings:
| ||||||||||||||||||||||||||
Configure Route Group for Webex
|
Create a route group with the following settings:
| ||||||||
Configure Route List for Webex
|
Create a route list with the following settings:
| ||||||||||||||
Create a Partition for Webex Destinations
|
Create a partition for the Webex destinations with the following settings:
| ||||||||
What to do next
Make sure to add this partition to all calling search spaces that should have access to Webex destinations. You must add this partition specifically to the calling search space that is used as the inbound calling search space on PSTN trunks, so that calls from the PSTN to Webex can be routed.
Configure Route Patterns for Webex Destinations
|
Configure route patterns for each DID range on Webex with the following settings:
| ||||||||||||
Configure Abbreviated Intersite Dialing Normalization for Webex
|
If abbreviated inter-site dialing is required to Webex, then configure dialing normalization patterns for each ESN range on Webex with the following settings:
| ||||||||||||||||||
Set up a hunt group
Hunt groups route incoming calls to a group of users or workspaces. You can even configure a pattern to route to a whole group.
For more information on how to set up a hunt group, see Hunt Groups in Cisco Webex Control Hub.
Create a call queue
You can set up a call queue so that when customers' calls can't be answered, they're provided with an automated answer, comfort messages, and music on hold until someone can answer their call.
For more information on how to set up and manage a call queue, see Manage Call Queues in Cisco Webex Control Hub.
Create a receptionist client
Help support the needs of your front-office personnel. You can set up users as telephone attendants so they can screen incoming calls to certain people within your organization.
For information about how to set up and view your receptionist clients, see Receptionist Clients in Cisco Webex Control Hub.
Create and manage auto attendants
You can add greetings, set up menus, and route calls to an answering service, a hunt group, a voicemail box, or a real person. Create a 24-hour schedule or provide different options when your business is open or closed.
For information about how to create and manage auto attendants, see Manage Auto Attendants in Cisco Webex Control Hub.
Configure a paging group
Group paging allows a user to place a one-way call or group page to up to 75 target users and workspaces by dialing a number or extension assigned to a specific paging group.
For information about how to set up and edit paging groups, see Configure a Paging Group in Cisco Webex Control Hub.
Set up call pickup
Enhance teamwork and collaboration by creating a call pickup group so users can answer each others calls. When you add users to a call pickup group and a group member is away or busy, another member can answer their calls.
For information about how to set up a call pickup group, see Call Pickup in Cisco Webex Control Hub.
Set up call park
Call park allows a defined group of users to park calls against other available members of a call park group. Parked calls can be picked up by other members of the group on their phone.
For more information about how to set up call park, see Call Park in Cisco Webex Control Hub.
Enable barge-in for users
| 1 |
From the customer view in https://admin.webex.com, go to . |
| 2 |
Select a user and click Calling. |
| 3 |
Go to the Between-user permissions section, and then select Barge in. |
| 4 |
Turn on the toggle to allow other users to add themselves to this user's ongoing call. |
| 5 |
Check Play a tone when this user Barges In on a call if you want to play a tone to others when this user barges in on their call. |
| 6 |
Click Save. |
Enable privacy for a user
| 1 |
Sign in to Control Hub, and go to . | ||
| 2 |
Choose a user and click Calling. | ||
| 3 |
Go to the Between-user Permissions area and then choose Privacy. | ||
| 4 |
Choose the appropriate Auto Attendant Privacy settings for this user.
| ||
| 5 |
Check the Enable Privacy check box. You can then decide to block everyone by not choosing members from the drop-down list. Alternatively, you can choose the users, workspaces, and virtual lines that can monitor the line status of this user. If you're a location administrator, only the users, workspaces, and virtual lines pertaining to your assigned locations appear in the drop-down list. Uncheck the Enable Privacy check box to allow everyone to monitor the line status. | ||
| 6 |
Check the Enforce privacy for directed call pickup and barge-in check box to enable privacy for directed call pickup and barge-in.
| ||
| 7 |
From Add member by name, choose the users, workspaces, and virtual lines that can monitor the phone line status and invoke directed call pickup and barge-in. | ||
| 8 |
To filter the members that you select, use the filter by name, number or ext field. | ||
| 9 |
Click Remove All to remove all the selected members.
| ||
| 10 |
Click Save. |
Configure monitoring
The maximum number of monitored lines for a user is 50. However, while configuring the monitoring list, consider the number of messages that impact the bandwidth between Webex Calling and your network. Also, determine the maximum monitored lines by the number of line buttons on the user's phone.
| 1 |
From the customer view in https://admin.webex.com, go to Management and then click Users. | ||||
| 2 |
Select the user you want to modify and click Calling. | ||||
| 3 |
Go to Between-user Permissions section, and select Monitoring. | ||||
| 4 |
Choose from the following:
You can include a virtual line in the Add Monitored Line list for user monitoring. | ||||
| 5 |
Choose if you wish to notify this user about parked calls, search for the person or call park extension to be monitored, and then click Save.
|
Enable call bridge warning tone for users
Before you begin
| 1 |
Sign in to Control Hub, and go to . | ||
| 2 |
Select a user and click the Calling tab. | ||
| 3 |
Go to Between-user Permissions, and click Call Bridging Warning Tone. | ||
| 4 |
Turn on Call Bridging Warning Tone, and then click Save.
For more information on call bridging on an MPP shared line, see Shared lines on your multiplatform desk phone. For more information on call bridging on a Webex App shared line, see Shared line appearance for WebexApp. |
Turn on hoteling for a user
| 1 |
From the customer view in https://admin.webex.com, go to Management and select Users. | ||
| 2 |
Select a user and click the Calling tab. | ||
| 3 |
Go to the Between-user Permissions section, and select Hoteling and turn on the toggle. | ||
| 4 |
Enter the name or number of the hoteling host in the Hoteling Location search field and choose the hoteling host that you want to assign to the user. Only one hoteling host can be selected. If you choose another hoteling host, the first one gets deleted.
| ||
| 5 |
To limit the time a user can be associated to the hoteling host, choose the number of hours that the user can use the hoteling host from the Limit Association Period drop-down. The user will be logged out automatically after the chosen time.
| ||
| 6 |
Click Save.
|
View calling reports
You can use the Analytics page in Control Hub to gain insight into how people are using Webex Calling and the Webex app (engagement), and the quaility of their call media experience. To access Webex Calling analytics, sign in to Control Hub, then go to Analytics and select the Calling tab.
| 1 |
For detailed call history reports, sign in to Control Hub, then go to . |
| 2 |
Select Detailed Call History. For information about calls using Dedicated Instance, see Dedicated Instance Analytics. |
| 3 |
To access media quality data, sign in to Control Hub, then go to Analytics and then select Calling. For more information, see Analytics for Your Cloud Collaboration Portfolio.
|
Run the CScan tool
CScan is a network readiness tool designed to test your network connection to Webex Calling.
|
For more information, see Use CScan to Test Webex Calling Network Quality. |
