The document describes what is required to configure and troubleshoot TelePresence Codec (TC)-based endpoint registration through the Mobile and Remote Access solution.
Cisco recommends that you have knowledge of these topics:
Mobile and Remote Access Solution
Video Communication Server (VCS) certificates
Expressway X8.1.1 or later
Cisco Unified Communication Manager (CUCM) Release 9.1.2 or later
CE8.x requires the encryption option key to enable "Edge" as a provisioning option
The information in this document is based on these software and hardware versions:
VCS X8.1.1 or later
CUCM Release 9.1(2)SU1 or later and IM & Presence 9.1(1) or later
TC 7.1 or later firmware (TC7.2 recommended)
VCS Control & Expressway/Expressway Core & Edge
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
These configuration steps assume that the administrator will configure the TC-based endpoint for secure device registration. Secure registration is NOT a requirement, however the overall Mobile and Remote Access solution guide gives the impression that it is since there are screen shots from the configuration that show secure device profiles on CUCM.
Step 1. Create a Secure Phone Profile on CUCM in FQDN Format (Optional).
In CUCM, select System > Security > Phone Security Profile.
Click Add New.
Select the TC-based endpoint type and configure these parameters:
Name - Secure-EX90.tbtp.local (FQDN Format Required)
SIP Profile - Standard SIP Profile or any custom profile previously created
Step 4. Add the Security Profile Name to the SAN of the Expressway-C/VCS-C Certificate (Optional).
In Expressway-C/VCS-C, navigate to Maintenance > Security Certificates > Server Certificate.
Click Generate CSR.
Fill out the Certificate Signing Request (CSR) fields and ensure that the Unified CM phone security profile name has the exact Phone Security Profile listed in Fully Qualified Domain Name (FQDN) format. For example, Secure-EX90.tbtp.local.
Note: The Unified CM phone security profile names are listed at the back of the Subject Alternate Name (SAN) field.
Send the CSR off to either an Internal or 3rd Party Certificate Authority (CA) to be signed.
Select Maintenance > Security Certificates > Server Certificate in order to upload the certificate to the Expressway-C/VCS-C.
Step 5. Add the UC Domain to the Expressway-E/VCS-E Certificate.
In Expressway-E/VCS-E, select Maintenance > Security Certificates > Server Certificate.
Click Generate CSR.
Fill out the CSR fields and ensure that "Unified CM registrations domains" contain the domain that the TC-based endpoint will make Collaboration Edge (collab-edge) requests to, in either the Domain Name Server (DNS) or Service Name (SRV) formats.
Send the CSR off to either an Internal or 3rd Party CA to be signed.
Select Maintenance > Security Certificates > Server Certificate in order to upload the certificate to the Expressway-E/VCS-E.
Step 6. Install the Proper Trusted CA Certificate to the TC-based Endpoint.
In the TC-based Endpoint, select Configuration > Security.
Select the CA tab and browse for the CA certificate that signed your Expressway-E/VCS-E certificate.
Click Add certificate authority.
Note: Once the certificate is successfully added you will see it listed in the Certificate list.
Note: TC 7.2 contains a pre-installed CAs list. If the CA that signed the Expressway-E certificate is contained within this list, the steps listed in this section are not required.
Note: The preinstalled CAs page contains a convenient "Configure provisioning now" button that takes you directly to the required configuration noted in step 2 in the next section.
Step 7. Set Up a TC-based Endpoint for Edge Provisioning
In the TC-based endpoint, select Configuration > Network and ensure these fields are properly filled in under the DNS section: Domain Name Server Address
In the TC-based endpoint, select Configuration > Provisioning and ensure these fields are properly filled in: LoginName - as defined in CUCM Mode - Edge Password - as defined in CUCM External Manager Address - Hostname of your Expressway-E/VCS-E Domain - Domain where your collab-edge record is present
Use this section to confirm that your configuration works properly.
In the web GUI, navigate to "Home". Look for the 'SIP Proxy 1" section for a "Registered" Status. The Proxy address is your Expressway-E/VCS-E.
From the CLI, enter xstatus //prov. If you are registered, you should see a Provisioning Status of "Provisioned".
In CUCM, select Device > Phone. Either scroll through the list or filter the list based on your endpoint. You should see a "Registered with %CUCM_IP%" message. The IP address to the right of this should be your Expressway-C/VCS-C which proxies the registration.
In Expressway-C/VCS-C, select Status > Unified Communications > View Provisioning sessions.
Filter by the IP address of your TC-based endpoint. An example of a Provisioned Session is shown in the image:
This section provides information you can use to troubleshoot your configuration.
Registration issues can be caused by numerous factors which include DNS, certificate issues, configuration, and so on. This section includes a comprehensive list of what you would typically see if you encounter a given problem and how to remediate it. If you run into issues outside of what has already been documented, feel free to include it.
For starters, be aware of the tools at your disposal.
Start extended logging (include a full packet capture)
These commands are most beneficial in order to troubleshoot in real-time:
log ctx HttpClient debug 9
log ctx PROV debug 9
log output on <-- Shows logging via console
An effective way to recreate the problem is to toggle the Provisioning Mode from "Edge" to "Off" and then back to "Edge" within the web GUI. You can also enter the xConfiguration Provisioning Mode: command in the CLI.
15975.90 PROV ProvisionRequest failed: 4 (Peer certificate cannot be authenticated with given CA certificates) 15975.90 PROV I: notify_http_done: Received 0 (Peer certificate cannot be authenticated with given CA certificates) on request https://RTP-TBTP-EXPRWY-E.tbtp.local:8443/dGJ0cC5jb20/get_edge_config/ 15975.90 PROV EDGEProvisionUser: start retry timer for 15 seconds
Verify if a 3rd Party CA is listed under the Security > CAs tab on the endpoint.
If the CA is listed, verify that it is correct.
Issue 3: Expressway-E Does Not Have the UC Domain Listed within the SAN
TC Endpoint Logs
82850.02 CertificateVerification ERROR: [verify_edge_domain_in_san]: Edge TLS verification failed: Edge domain 'tbtp.local' and corresponding SRVName '_collab-edge._tls.tbtp.local' not found in certificate SAN list 82850.02 HttpClient SSLv3, TLS alert, Server hello (2): 82850.02 HttpClient SSL certificate problem: application verification failure 82850.02 HttpClient Closing connection 113 82850.02 HttpClient HTTPClientCurl error (https://RTP-TBTP-EXPRWY-E.tbtp.local:8443/dGJ0cC5jb20/get_edge_config/): 'Peer certificate cannot be authenticated with given CA certificates'
X509v3 Subject Alternative Name: DNS:RTP-TBTP-EXPRWY-E.tbtp.local, SRV:_collab-edge._tls.tbtppppp.local
Regenerate Expressway-E CSR in order to include the UC Domain(s).
It is possible that on the TC endpoint the ExternalManager Domain parameter is not set to what the UC Domain is. If this is the case you must match it.
Issue 4: Username and/or Password Supplied in the TC Provisioning Profile Is Incorrect
TC Endpoint Logs
83716.67 HttpClient Server auth using Basic with user 'pstojano' 83716.67 HttpClient GET /dGJ0cC5jb20/get_edge_config/ HTTP/1.1 Authorization: xxxxxx Host: RTP-TBTP-EXPRWY-E.tbtp.local:8443 Cookie: JSESSIONIDSSO=34AFA4A6DEE1DDCE8B1D2694082A6D0A Content-Type: application/x-www-form-urlencoded Accept: text/xml User-Agent: Cisco/TC Accept-Charset: ISO-8859-1,utf-8 83716.89 HttpClient HTTP/1.1 401 Unauthorized 83716.89 HttpClient Authentication problem. Ignoring this. 83716.90 HttpClient WWW-Authenticate: Basic realm="Cisco-Edge" 83716.90 HttpClient Server CE_C ECS is not blacklisted 83716.90 HttpClient Server: CE_C ECS 83716.90 HttpClient Date: Thu, 25 Sep 2014 17:42:51 GMT 83716.90 HttpClient Age: 0 83716.90 HttpClient Transfer-Encoding: chunked 83716.91 HttpClient Connection: keep-alive 83716.91 HttpClient 83716.91 HttpClient 0 83716.91 HttpClient Connection #116 to host RTP-TBTP-EXPRWY-E.tbtp.local left intact 83716.91 HttpClient HTTPClientCurl received HTTP error 401
83716.91 PROV ProvisionRequest failed: 5 (HTTP code=401) 83716.91 PROV I: notify_http_done: Received 401 (HTTP code=401) on request https://RTP-TBTP-EXPRWY-E.tbtp.local:8443/dGJ0cC5jb20/get_edge_config/
08080021.043 |16:31:15.937 |AppInfo |SIPStationD(18400) - validTLSConnection:TLS InvalidX509NameInCertificate, Rcvd=RTP-TBTP-EXPRWY-C.tbtp.local, Expected=SEP00506006EAFE. Will check SAN the next 08080021.044 |16:31:15.937 |AppInfo |SIPStationD(18400) - validTLSConnection:TLS InvalidX509NameInCertificate Error , did not find matching SAN either, Rcvd=RTP-TBTP-EXPRWY-C.tbtp.local, Expected=Secure-EX90.tbtp.local 08080021.045 |16:31:15.937 |AppInfo |ConnectionFailure - Unified CM failed to open a TLS connection for the indicated device Device Name:SEP00506006EAFE IP Address:xx.xx.97.108 IPV6Address: Device type:584 Reason code:2 App ID:Cisco CallManager Cluster ID:StandAloneCluster Node ID:RTP-TBTP-CUCM9 08080021.046 |16:31:15.938 |AlarmErr |AlarmClass: CallManager, AlarmName: ConnectionFailure, AlarmSeverity: Error, AlarmMessage: , AlarmDescription: Unified CM failed to open a TLS connection for the indicated device, AlarmParameters: DeviceName:SEP00506006EAFE, IPAddress:xx.xx.97.108, IPV6Address:, DeviceType:584, Reason:2, AppID:Cisco CallManager, ClusterID:StandAloneCluster, NodeID:RTP-TBTP-CUCM9,
X509v3 Subject Alternative Name: DNS:RTP-TBTP-EXPRWY-C.tbtp.local, XMPP:conference-2-StandAloneCluster5ad9a.tbtp.local
In this specific log example it is clear that the Expressway-C/VCS-C does not contain the Phone Security Profile FQDN in the SAN. (Secure-EX90.tbtp.local). In the Transport Layer Security (TLS) Handshake, the CUCM inspects the Expressway-C/VCS-C's server certificate. Since it does not find it within the SAN it throws the error bolded and reports that it Expected the Phone Security Profile in FQDN format.
Verify that the Expressway-C/VCS-C contains the Phone Security Profile in FQDN format within the SAN of it's server certificate.
Verify that the device uses the correct security profile in CUCM if you use a secure profile in FQDN format.
This could also be caused by Cisco bug ID CSCuq86376. If this is the case check the Expressway-C/VCS-C SAN size and the position of the Phone Security Profile within the SAN.
Issue 6: TC-based Endpoint Provisioning Fails - No UDS server
This errror must be present Under Diagnostics > Troubleshooting :
Error: Provisioning Status Provisioning failed: XML didnt contain UDS server addres