After you configure Webex Calling for your organization, you can configure a trunk to connect your Local Gateway to Webex Calling. SIP TLS transport secures the trunk between the Local Gateway and the Webex cloud. The media between the Local Gateway and Webex Calling uses SRTP.
Local Gateway configuration task flow
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.
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 Local Gateway 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.
-
Create a trunk in the Control Hub and assign it to the location. See Configure trunks, route groups, and dial plans for Webex Calling for more information.
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 third-party SBCs, refer to the respective product reference documentation. |
To configure TDM interfaces for PSTN call legs on the Cisco TDM-SIP Gateways, see Configuring ISDN PRI. |
Before you begin
-
Ensure that the following baseline platform configuration that you configure are set up according to policies and procedures of your organization:
-
NTPs
-
ACLs
-
Enable passwords
-
Primary password
-
IP routing
-
IP Addresses, and so on
-
-
You require a minimum supported release of Cisco IOS XE 16.12 or IOS-XE 17.3 for all Local Gateway deployments.
Only CUBE supports the registration-based Local Gateway; no other SBCs from third-parties are supported. |
1 |
Ensure that you assign any Layer 3 interfaces have valid and routable IP addresses:
|
2 |
Preconfigure a primary key for the password using the following commands, before you use in the credentials and shared secrets. You encrypt the Type 6 passwords using AES cipher and user-defined primary key.
|
3 |
Configure IP name server to enable DNS lookup and ping to ensure that server is reachable. The Local Gateway uses DNS to resolve Webex Calling proxy addresses:
|
4 |
Enable TLS 1.2 Exclusivity and a default placeholder trustpoint:
|
5 |
Update the Local Gateway trust Pool: The default trustpool bundle doesn't include the "DigiCert Root CA" or "IdenTrust Commercial" certificates that you need for validating the server-side certificate during TLS connection establishment to Webex Calling. Download the latest “Cisco Trusted Core Root Bundle” from http://www.cisco.com/security/pki/ to update the trustpool bundle. |
Before you begin
1 |
Enter the following commands to turn on the Local Gateway application, see Port Reference Information for Cisco Webex Calling for the latest IP subnets that you must add to the trust list:
Here's an explanation of the fields for the configuration: Toll-fraud prevention
Media
SIP-to-SIP basic functionality
Supplementary services
Disables REFER and replaces the dialog ID in the replaces header with the peer dialog ID. For more information, see Supplementary service sip. Fax protocol
Enables T.38 for fax transport, though the fax traffic won't be encrypted. For more information on this command, see fax protocol t38 (voice-service). Enable global stun
For more information, see stun flowdata agent-id and stun flowdata shared-secret. G729
Allows all variants of G729. For more information, see g729 annexb-all. SIP
Forces the Local Gateway to send the 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. |
||||||
2 |
Configure “SIP Profile 200.”
Here's an explanation of the fields for the configuration:
|
||||||
3 |
Configure codec profile, stun definition, and SRTP Crypto suite.
Here's an explanation of the fields for the configuration:
|
||||||
4 |
Map Control Hub parameters to Local Gateway configuration. Add Webex Calling as a tenant within the Local Gateway. You require configuration to register the Local Gateway under voice class tenant 200 . You must obtain the elements of that configuration from the Trunk Info page from Control Hub as shown in the following image. The following example displays what are the fields that map to the respective Local Gateway CLI. Apply tenant 200 to all the Webex Calling facing dial-peers (2xx tag) within the Local Gateway configuration. The voice class tenant feature allows to group and to configure SIP trunk parameters that are otherwise done under voice service VoIP and sip-ua. When you configure a tenant and apply it under a dial-peer, then the following order of preference applies to Local Gateway configurations:
|
||||||
5 |
Configure voice class tenant 200 to enable trunk registration from Local Gateway to Webex Calling based on the parameters you've obtained from Control Hub:
Here's an explanation of the fields for the configuration: voice class tenant 200Enables specific global configurations for multiple tenants on SIP trunks that allow differentiated services for tenants. For more information, see voice class tenant. registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tlsRegistrar server for the Local Gateway with the registration set to refresh every two minutes (50% of 240 seconds). For more information, see registrar. credentials number Hussain6346_LGU username Hussain2572_LGU password 0 meX71]~)Vmf realm BroadWorksCredentials for trunk registration challenge. For more information, see credentials (SIP UA). authentication username Hussain6346_LGU password 0 meX71]~)Vmf realm BroadWorksauthentication username Hussain6346_LGU password 0 meX71]~)Vmf realm 40462196.cisco-bcld.com
Authentication challenge for calls. For more information, see authentication (dial-peer). no remote-party-idDisable SIP Remote-Party-ID (RPID) header as Webex Calling supports PAI, which is enabled using CIO asserted-id pai . For more information, see remote-party-id. connection-reuseUses the same persistent connection for registration and call processing. For more information, see connection-reuse. srtp-crypto 200Defines voice class srtp-crypto 200 to specify SHA1_80 (specified in step 3). For more information, see voice class srtp-crypto. session transport tcp tlsSets transport to TLS. For more information, see session-transport. url sipsSRV query must be SIPs as supported by the access SBC; all other messages are changed to SIP by sip-profile 200. error-passthruSpecifies SIP error response pass-thru functionality. For more information, see error-passthru. asserted-id paiTurns on PAI processing in Local Gateway. For more information, see asserted-id. bind control source-interface GigabitEthernet0/0/1Configures a source IP address for signaling the source interface facing Webex Calling. bind media source-interface GigabitEthernet0/0/1Configures a source IP address for the media source interface facing Webex Calling. For more information on the bind commands, see bind. no pass-thru content custom-sdpDefault command under tenant. For more information on this command, see pass-thru content. sip-profiles 200Changes SIPs to SIP and modify Line/Port for INVITE and REGISTER messages as defined in sip-profiles 200 . For more information, see voice class sip-profiles. outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.comWebex Calling access SBC. For more information, see outbound-proxy. privacy-policy passthruTransparently pass across privacy header values from the incoming to the outgoing leg. For more information, see privacy-policy. |
After you define tenant 200 within the Local Gateway and configure a SIP VoIP dial-peer, the gateway then initiates a TLS connection toward Webex Calling, at which 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 is updated earlier. Establishes a persistent TLS session between the Local Gateway and Webex Calling access SBC. The Local Gateway then sends a REGISTER to the access SBC that is challenged. Registration AOR is number@domain. The number is taken from credentials “number” parameter and domain from the “registrar dns:<fqdn>.” When the registration is challenged:
-
Use the username, password, and realm parameters from the credentials to build the header and sip-profile 200.
-
Converts SIPS url back to SIP.
Registration is successful when you receive 200 OK from the access SBC.
This deployment requires the following configuration on the Local Gateway:
-
Voice class tenants—You create other tenants for dial-peers facing ITSP similar to tenant 200 that you create for Webex Calling facing dial-peers.
-
Voice class URIs—You define patterns for host IP addresses/ports for various trunks terminating on Local Gateway:
-
Webex Calling to LGW
-
PSTN SIP trunk termination on LGW
-
-
Outbound dial-peers—You can route outbound call legs from LGW to ITSP SIP trunk and Webex Calling.
-
Voice class DPG—You can invoke to target the outbound dial-peers from an inbound dial-peer.
-
Inbound dial-peers—You can accept inbound call legs from ITSP and Webex Calling.
Use the configurations either for partner-hosted Local Gateway setup, or customer site gateway, as shown in the following image.
1 |
Configure the following voice class tenants: |
2 |
Configure the following voice class uri: |
3 |
Configure the following outbound dial peers: |
4 |
Configure the following dial-peer groups (dpg): |
5 |
Configure the following inbound dial-peers: |
PSTN to Webex Calling
Match all incoming IP PSTN call legs on the Local Gateway with dial-peer 100 to define a match criterion for the VIA header with the IP PSTN’s IP address. DPG 200 invokes outgoing dial-peer 200201, that has the Webex Calling server as a target destination.
Webex Calling to PSTN
Match all incoming Webex Calling call legs on the Local Gateway with dial-peer 200201 to define the match criterion for the REQUEST URI header pattern with the trunk group OTG/DTG parameter, unique to this Local Gateway deployment. DPG 100 invokes the outgoing dial-peer 101, that has the IP PSTN IP address as a target destination.
This deployment requires the following configuration on the Local Gateway:
-
Voice class tenants—You create more tenants for dial-peers facing Unified CM and ITSP, similar to tenant 200 that you create for Webex Calling facing dial-peers.
-
Voice class URIs—You define a pattern for host IP addresses/ports for various trunks terminating on the LGW from:
-
Unified CM to LGW for PSTN destinations
-
Unified CM to LGW for Webex Calling destinations
-
Webex Calling to LGW destinations
-
PSTN SIP trunk termination on LGW
-
-
Voice class server-group—You can target IP addresses/ports for outbound trunks from:
-
LGW to Unified CM
-
LGW to Webex Calling
-
LGW to PSTN SIP trunk
-
-
Outbound dial-peers—You can route outbound call legs from:
-
LGW to Unified CM
-
ITSP SIP trunk
-
Webex Calling
-
-
Voice class DPG—You can invoke to target outbound dial-peers from an inbound dial-peer.
-
Inbound dial-peers—You can accept inbound call legs from Unified CM, ITSP, and Webex Calling.
1 |
Configure the following voice class tenants: |
2 |
Configure the following voice class uri: |
3 |
Configure the following voice class server-groups: |
4 |
Configure the following outbound dial-peers: |
5 |
Configure the following DPG: |
6 |
Configure the following inbound dial-peers: |
IP PSTN to Unified CM PSTN trunk
Webex Calling platform to Unified CM Webex Calling trunk
Unified CM PSTN trunk to IP PSTN
Unified CM Webex Calling trunk to Webex Calling platform
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.3.2 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.3.2 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
Local Gateway running 16.11.1 or higher
-
Diagnostic signatures are enabled by default
-
Configure the email server to be used to send proactive notifications if the device is running a version earlier than 17.3.2.
configure terminal call-home mail-server <email server> priority 1 end
-
Configure the environment variable ds_email with the email address of the administrator to be notified.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
Local Gateway running 16.9.x version
-
Enter the following commands to enable diagnostic signatures.
configure terminal call-home reporting contact-email-addr sch-smart-licensing@cisco.com end
-
Configure the email server to be used to send proactive notifications if the device is running a version earlier than 17.3.2.
configure terminal call-home mail-server <email server> priority 1 end
-
Configure the environment variable ds_email with the email address of the administrator to be notified.
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.3.2 to send the proactive notifications to tacfaststart@gmail.com using Gmail as the secure SMTP server:
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 Less secure app access setting.
and turn on -
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 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 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.com
Download 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 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. Please 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 using . 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) 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 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" end
Example:
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.com
Downloaded 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 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:
Before you begin
-
Ensure that the following baseline platform configuration that you configure are set up according to your organization's policies and procedures:
-
NTPs
-
ACLs
-
enable passwords
-
primary password
-
IP routing
-
IP Addresses, and so on
-
-
You require a minimum supported release of IOS XE 17.6 for all Local Gateway deployments.
1 |
Ensure that you assign valid and routable IP addresses to any Layer 3 interfaces:
|
||||
2 |
Preconfigure a primary key for the password with the following commands before it is used as a credential and shared secrets. Type 6 passwords are encrypted using AES cipher and user-defined primary key.
|
||||
3 |
Configure IP Name Server to enable DNS lookup. Ping the IP Name Server and ensure that the server is reachable. Local Gateway must resolve Webex Calling proxy addresses using this DNS:
|
||||
4 |
Enable TLS 1.2 exclusivity and a default placeholder Trustpoint:
|
||||
5 |
If the root certificate has an intermediate CA, then execute the following commands:
|
||||
6 |
Create a trustpoint to hold the root certificate. Execute the following commands, if there is no intermediate CA:
|
||||
7 |
Configure SIP-UA to use the trustpoint you created.
|
Before you begin
-
The network toward Webex Calling must use a public IPv4 address. Fully Qualified Domain Names (FQDN) or Service Record (SRV) addresses must resolve to a public IPv4 address on the internet.
-
Install a signed certificate on the Local Gateway.
-
Certificate Authority (CA) must sign the certificate as mentioned in What Root Certificate Authorities are Supported for Calls to Cisco Webex Audio and Video Platforms?.
-
The FQDN selected from the Control Hub must be the Common Name (CN) or Subject Alternate Name (SAN) of the certificate. For example:
-
If a trunk configured from your organization’s Control Hub has london.lgw.cisco.com:5061 as FQDN of the Local Gateway, then CN or SAN must contain london.lgw.cisco.com in the certificate.
-
If a trunk configured from your organization’s Control Hub has london.lgw.cisco.com as the SRV address of the Local Gateway, then CN or SAN must contain london.lgw.cisco.com in the certificate. The records that the SRV address resolves to (CNAME, A Record, or IP Address) are optional in SAN.
-
In the FQDN or SRV example that you use for trunk, the contact address for all new SIP dialogs from your Local Gateway must have london.lgw.cisco.com in the host portion of the SIP address. See, Step 5 for configuration.
-
-
-
Ensure that certificates are signed for client and server usage.
-
Upload the trust bundle to the Local Gateway as mentioned in What Root Certificate Authorities are Supported for Calls to Cisco Webex Audio and Video Platforms?.
1 |
Enter the following commands to turn on the Local Gateway application. (Refer to Port Reference Information for Cisco Webex Calling for the latest IP subnets to add as a trust list):
Here's an explanation of the fields for the configuration: Toll-fraud prevention
SIP-to-SIP basic functionality
Fax protocol
Enables T.38 for fax transport, though the fax traffic isn't be encrypted. For more information on this command, see fax protocol t38 (voice-service). SIP
Forces the Local Gateway to send the 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.
Configures Session Initiation Protocol (SIP) asymmetric payload support for both DTMF and dynamic codec payloads. For more information on this command, see asymmetric payload. |
||
2 |
Configure "voice class codec 100."
Here's an explanation of the fields for the configuration: voice class codec 100 Allows opus and both g711 (mu and a-law) codecs for sessions. Applies the preferred codec to all the dial-peers. For more information, see voice class codec. |
||
3 |
Configure voice class stun-usage 100 to enable ICE.
Here's an explanation of the fields for the configuration: voice class stun-usage 100 Defines stun usage. Applies stun to all Webex Calling facing dial-peers to avoid no way audio when a Unified CM phone forwards the call to another Webex Calling phone. For more information, see voice class stun usage and stun usage ice lite.
|
||
4 |
Configure the command to limit the crypto supported.
Here's an explanation of the fields for the configuration: voice class srtp-crypto 100Specifies SHA1_80 as the only SRTP cipher-suite a Local Gateway offers in the SDP in offer and answer. Webex Calling only
supports SHA1_80.
For more information, see voice class srtp-crypto.
|
||
5 |
(For SBC with public IP addresses follows this step.) Configure “SIP Profiles 100”. In the example, cube1.abc.lgwtrunking.com is the FQDN selected for the Local Gateway and "192.65.79.21" is the public IP address of the Local Gateway interface that is toward Webex Calling:
Here's an explanation of the fields for the configuration: rule 10, and rule 20 Ensures that you replace the Local Gateway IP address with FQDN in the ‘Contact’ header of request and response messages. This is a requirement for authentication of your Local Gateway to use as a trunk in a given Webex Calling location for your organization.
|
||
6 |
(Follow this step for SBC behind Static NAT.) Configure SBC for Static NAT (Optional). In this example, cube1.abc.lgwtrunking.com is the FQDN selected for the Local Gateway and "10.80.13.12" is the SBC interface IP address towards Webex Calling and "192.65.79.20" is the NAT public IP address. If the SBC is deployed with static NAT, then the below inbound and outbound SIP profile configurations are required to modify the private IP address to the NAT public IP address in the SIP request and response. SIP profiles for outbound messages to Webex Calling
SIP profiles for inbound messages from Webex Calling
For more information, see voice class sip-profiles. For more information, see rule (voice translation-rule). |
||
7 |
Configure the following outbound dial-peer: |
||
8 |
Create a dial-peer group based on the dial-peer toward Webex Calling in the active or inactive model.
Here's an explanation of the fields for the configuration:
Associates an outbound dial-peer with dial-peer group 100 and configure dial-peer 101 with the same preference. For more information, see dial-peer voice. |
||
9 |
Configure inbound dial-peer from Webex Calling. Incoming match is based on the URI request.
Here's an explanation of the fields for the configuration: voice class uri 120 sip
Defines the match pattern for an incoming call from Webex Calling. For more information, see voice class uri sip preference. session transport tcp tls
Sets transport to TLS. For more information, see session-transport . destination dpg 300
Specifies a dial-peer group 120 to select an outbound dial-peer. For more information on dial-peer groups, see voice-class dpg. incoming uri request 120
Matches all incoming traffic from Webex Calling to Local Gateway based on the hostname in the request URI, uniquely identifying a Local Gateway site within an enterprise and in the Webex Calling ecosystem. For more information, see incoming uri. voice-class sip profile 100
By default, the basic template sip-profile 100 is used. If SBC is configured with static NAT, then we recommend that you map inbound sip-profile 201. For more information, see voice class sip-profiles. voice-class srtp-crypto 100
Configures the preferred cipher-suites for the SRTP call leg (connection). For more information, see voice class srtp-crypto. bind control source-interface GigabitEthernet0/0/1
Configures a source IP address for signaling the source interface facing Webex Calling. For more information, see bind. bind media source-interface GigabitEthernet0/0/1
Configures a source IP address for the media source interface facing Webex Calling. |
This deployment requires the following configuration on the Local Gateway:
-
Voice class URIs—You can define host IP addresses/ports patterns for various trunks terminating on Local Gateway:
-
Webex Calling to LGW
-
PSTN SIP trunk termination on LGW
-
-
Outbound dial-peers—You can route outbound call legs from an LGW to Internet telephony service provider (ITSP) SIP trunk and Webex Calling.
-
Voice class DPG—You can invoke to target outbound dial-peers from an inbound dial-peer.
-
Inbound dial-peers—You can accept inbound call legs from ITSP and Webex Calling.
Use the configuration either for a partner-hosted Local Gateway setup, or local customer site gateway. See the following:
1 |
Configure the following voice class uri: |
2 |
Configure the following outbound dial-peers: |
3 |
Configure the following Dial-peer Group (DPG): |
4 |
Configure the following inbound dial-peers: |
PSTN to Webex Calling:
Match all incoming IP PSTN call legs on the Local Gateway with dial-peer 122 to define a match criterion for the VIA header with the IP PSTN’s IP address. DPG 100 invokes outgoing dial-peer 101, 102, 103, 104, that has the Webex Calling server as a target destination.
Webex Calling to PSTN:
Match all incoming Webex Calling call legs on the Local Gateway with dial-peer 110 to define the match criterion for the REQUEST URI header pattern with the Local Gateway hostname, unique to the Local Gateway deployment. DPG 120 invokes outgoing dial-peer 121, that has the IP PSTN IP address as a target destination.
This deployment requires the following configuration on the Local Gateway:
-
Voice class URIs—You can define patterns of host IP addresses/ports for various trunks terminating on the LGW from:
-
Unified CM to LGW for PSTN destinations
-
Unified CM to LGW for Webex Calling destinations
-
Webex Calling to LGW destinations
-
PSTN SIP trunk termination on LGW destinations
-
-
Voice class server-group—You can target IP addresses or ports for outbound trunks from:
-
LGW to Unified CM
-
LGW to Webex Calling
-
LGW to PSTN SIP trunk
-
-
Outbound dial-peers—You can route outbound call legs from:
-
LGW to Unified CM
-
Internet Telephony Service Provider (ITSP) SIP trunk
-
Webex Calling
-
-
Voice class dpg—You can target to invoke outbound dial-peers from an inbound dial-peer.
-
Inbound dial-peers—You can accept inbound call legs from Unified CM, ITSP, and Webex Calling.
1 |
Configure the following voice class URIs: |
2 |
Configure the following voice class server-groups: |
3 |
Configure the following outbound dial-peers: |
4 |
Configure the following dial-peer group (DPG) for calls towards Webex Calling: |
5 |
Configure the following inbound dial-peers: |
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
Local Gateway running 17.6.1 version
-
Enter the following commands to enable Diagnostic Signatures.
configure terminal call-home reporting contact-email-addr sch-smart-licensing@cisco.com end
-
Configure the email server to send proactive notifications if the device is running a version earlier than 17.6.1.
configure terminal call-home mail-server <email server> priority 1 end
-
Configure the environment variable ds_email with the email address of the administrator that you notify.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
The following shows an example configuration of a Local Gateway running on Cisco IOS XE 17.6.1 to send the proactive notifications to tacfaststart@gmail.com using Gmail as the secure SMTP server:
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com"
Local Gateway running on Cisco IOS XE software is not a typical web-based Gmail client that supports OAuth. We must configure a specific Gmail account setting and provide specific permission to have the email from the device processed correctly: |
-
Go to Less secure app access setting.
and turn on -
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 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 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.
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.com
Download 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 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 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" end
Example:
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 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 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.com
Downloaded 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. |