Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Collaboration, Voice and Video Blogs

9 Views
0 Comments

Hi

I have an agent who uses a JabberSDK to control his deskphone. He has has this issue:
He is able to log in, authenticate and select his device. The authentication process is quick, but JabberSDK takes about 50s to show the available devices.
In the JabberSDK logs, I found 10 events "telephonydeviceschange". The first 3 are quick (<1s) but the 4th arrives with a delay of 51s.

The rest of the login process is quick.I my development environment, I cannot reproduce the events.

Has anybody an idea what the problem could be? Thanks a lot.
--
JabberSDK version 11.8.1
Browser Internet Explorer

20 Views
0 Comments

I have uccx cert expiring soon and I need to find out the steps to regenerate/renew below certs. I already renew CUCM certs by using below steps, but not sure if I need to use same doc to regenerate UCCX certs?

> tomcat.pen

>ipsec.pem

>intelligencecenter-srvr.pem

>intelligencecenter-srvr.jms.pem

CUCM Versions 8.X > - Certificate Regeneration/Deletion

Note:
* When regenerating certificates, be advised that this action should be performed after hours due
to the requirement of restarting services and rebooting phones in the cluster.
** Monitoring Phone Registration via RTMT tool is highly recommended.
*** It is recommended that you reboot ALL phones prior to Certificate Regeneration in order for
all phones to have the latest ITL – and may help identify phones with current ITL issues.
Monitoring Endpoints
Real Time Monitoring Tool (RTMT)
 Login to the publisher using RTMT
o Select the Voice/Video Tab
o Select Device Summary
 Here you will see the total number of registered end-points and how many to each
node.
 Please monitor during endpoint resets to ensure registration prior to moving to next
certificate.
……….
Is your Cluster in Mixed Mode?
 System > Enterprise Parameters
To regenerate expiring or expired certificates please follow the procedures below.
Tomcat Certificate:
Identify if you are using a third party certificates.
1) Log into Cisco Unified OS Administration Page
a. Security
b. Certificate Management
c. Find
i. Observe from Description column if tomcat states “Self-signed certificate generated by system”. If Tomcat is third-party signed, follow the link provided and perform those steps after the Tomcat regeneration.
ii. Third Party Signed - https://supportforums.Cisco.com/docs/DOC-6119
2) Open a GUI for each server in your cluster starting with the publisher, then each subscriber/TFTP in line and navigate to Cisco Unified OS Administration > Security > Certificate Management
3) On all of the GUI pages beginning with the publisher Click “Find” showing all the certificates.
a) Click on the “tomcat.pem” Certificate.
b) Once open Click “Regenerate” Wait until you see “Success” then close pop-up or go back to “Find/List”.
4) Continue with subsequent Subscribers; following the same procedure in step 2 thru 3 and complete on all subscribers in your cluster
5) After all Nodes have regenerated the tomcat certificate, restart the tomcat service on all the nodes beginning with the publisher then followed by the subscribers.
a) To restart tomcat you will need to open a CLI to each node and enter the following command, "utils service restart Cisco Tomcat".
IPSEC Certificate:
Note:
IPSEC certificates will affect the DRF master and local which deals with backup and restore.
1) Open a GUI for each server in your cluster starting with the publisher, then each subscriber/TFTP in
line and navigate to Cisco Unified OS Administration > Security > Certificate Management
2) On all of the GUI pages beginning with the publisher Click “Find” showing all the certificates.
a) Click on the “IPSEC.pem” Certificate.
b) Once open Click “Regenerate” Wait until you see “Success” then close pop-up or go back to
“Find/List”.
3) Continue with subsequent Subscribers; following the same procedure in step 2 and complete on all
subscribers in your cluster
4) After all Nodes have regenerated the IPSEC certificate, The following services will need to be
restarted in the following order:
a) Log into Publisher’s Cisco Unified Serviceability
i) Cisco Unified Serviceability > Tools > Control Center - Network Services
ii) On the Publisher only, restart Cisco DRF Master Service.
iii) Once the service restart completes, restart Cisco DRF Local Service on the Publisher.
iv) Continuing with the subscribers, restart Cisco DRF Local Service.
CAPF Certificate:
Note:
Is Cluster in Mixed Mode
Ensure that the cluster is not in a secure cluster mode.
1) Navigate to the Cisco Unified CM Administration > System > Enterprise Parameters.
a) Section “Security Parameters” Check Cluster Security Mode and identify if it is set to “0” or “1”
for Cluster Secure Mode. If the value if 0, the cluster is not in mixed-mode. If it is “1”, the cluster
is in mixed-mode and you will need to update the CTL file. Ensure you complete this section
before the Call Manager certificate due to needing to update the CTL in next section.
b) Open a GUI for each server in your cluster starting with the publisher, then each
subscriber/TFTP in line and navigate to Cisco Unified OS Administration > Security > Certificate
Management
2) On all of the GUI pages beginning with the publisher Click “Find” showing all the certificates.
a) Click on the “CAPF.pem” Certificate.
b) Once open Click “Regenerate” Wait until you see “Success” then close pop-up or go back to
“Find/List”.
3) Continue with subsequent Subscribers; following the same procedure in step 3 and complete on all
subscribers in your cluster
4) After all Nodes have regenerated the CAPF certificate, The following services will need to be
restarted in the following order:
a) Log into Publisher’s Cisco Unified Serviceability
i) Cisco Unified Serviceability > Tools > Control Center - Feature Services
ii) Beginning with the Publisher, restart Cisco Certificate Authority Proxy Function Service ONLY
where running.
iii) Cisco Unified Serviceability > Tools > Control Center - Network Services
iv) Beginning with the Publisher then continuing with the subscribers, restart Cisco Trust
Verification Service (TVS).
v) Cisco Unified Serviceability > Tools > Control Center - Feature Services
vi) Beginning with the Publisher then continuing with the subscribers, restart Cisco Tftp Service
only where running.
vii) Reboot ALL Phones
(1) Cisco Unified CM Administration > System > Enterprise Parameters
(a) “Reset” you will see a pop-up warning “You are about to reset all devices in the
system. This action cannot be undone. Continue?” Click OK, then click “Reset”
Phones will now upload new ITL during their reset.
CallManager Certificate:
Warning:
DO NOT regenerate CallManager.PEM and TVS.PEM certificates at the same time. This will cause
an unrecoverable mismatch to the installed ITL on the phone to the newly generated ITL in CUCM
causing the need to remove the ITL from ALL phones in the cluster. At the end of this section, a
reboot of ALL phone will be required.
1) Open a GUI for each server in your cluster starting with the publisher, then each subscriber/TFTP in
line and navigate to Cisco Unified OS Administration > Security > Certificate Management
2) On all of the GUI pages beginning with the publisher Click “Find” showing all the certificates.
a) Click on the “CallManager.pem” Certificate.
b) Once open Click “Regenerate” Wait until you see “Success” then close pop-up or go back to
“Find/List” (Different depending on your Call Manager Version).
3) Continue with subsequent Subscribers; following the same procedure in step 2 and complete on all
subscribers in your cluster
4) After all Nodes have regenerated the CallManager certificate, The following services will need to be
restarted in the following order:
a) If you are in Mixed Mode Only and have already regenerated the CAPF – Update the CTL
before proceeding Token - Tokenless
b) Log into Publisher’s Cisco Unified Serviceability
i) Cisco Unified Serviceability > Tools > Control Center - Feature Services
ii) Beginning with the Publisher then continuing with the subscribers, restart Cisco
CallManager Service where running.
iii) Cisco Unified Serviceability > Tools > Control Center - Feature Services
iv) Beginning with the Publisher then continuing with the subscribers, restart Cisco CTIManager
Service only where running.
v) Cisco Unified Serviceability > Tools > Control Center - Network Services
vi) Beginning with the Publisher then continuing with the subscribers, restart Cisco Trust
Verification Service (TVS).
vii) Cisco Unified Serviceability > Tools > Control Center - Feature Services
viii) Beginning with the Publisher then continuing with the subscribers, restart Cisco Tftp Service
only where running.
ix) Reboot ALL Phones
(1) Cisco Unified CM Administration > System > Enterprise Parameters
(a) “Reset” you will see a pop-up warning “You are about to reset all devices in the
system. This action cannot be undone. Continue?” Click OK, then click “Reset”
(2) Phones will now upload new updated ITL during their reset.
TVS Certificate:
Note:
DO NOT regenerate CallManager.PEM and TVS.PEM certificates at the same time. This will cause
an unrecoverable mismatch to the installed ITL on the phone to the newly generated ITL in CUCM
causing the need to remove the ITL from ALL phones in the cluster.
1) Open a GUI for each server in your cluster starting with the publisher, then each subscriber/TFTP in
line and navigate to Cisco Unified OS Administration > Security > Certificate Management
2) On all of the GUI pages beginning with the publisher Click “Find” showing all the certificates.
a) Click on the “TVS.pem” Certificate.
b) Once open Click “Regenerate” Wait until you see “Success” then close pop-up or go back to
“Find/List”.
3) Continue with subsequent Subscribers; following the same procedure in step 2 and complete on all
subscribers in your cluster
4) After all Nodes have regenerated the TVS certificate, The following services will need to be restarted
in the following order:
a) Log into Publisher’s Cisco Unified Serviceability
i) Cisco Unified Serviceability > Tools > Control Center - Network Services
ii) On the Publisher only, restart Cisco Trust Verification Service.
iii) Once the service restart completes, continuing with the subscribers and restart Cisco Trust
Verification Service.
iv) Beginning with the Publisher then continuing with the subscribers, restart Cisco Tftp Service
only where running.
v) Reboot ALL Phones
(1) Cisco Unified CM Administration > System > Enterprise Parameters
(a) “Reset” you will see a pop-up warning “You are about to reset all devices in the
system. This action cannot be undone. Continue?” Click OK, then click “Reset”
vi) Phones will now upload new ITL during their reset.
Deleting Expired Trust Certificates
Note:
Identify the expired or certificates no longer required for your system. Base Certificates cannot be
deleted (i.e. CallMananger, IPSEC, Tomcat, CAPF, TVS). Any trust certificate can be deleted. Follow
procedures below.
1) Log into Call Manager Publisher – Cisco Unified Serviceability page
a. Tools > Control Center – Network Services
i. From the drop down select the CUCM Publisher
ii. Stop Certificate Change Notification
iii. Repeat for every Call Manager node in your cluster
iv. If you have an Instant Message and Presence (IMP/CUPS) Server
v. Stop Platform Administration Web Services
2) Open a GUI to each sever and log into Unified OS Administration page (ALL Servers Same Time)
a. Navigate to Security - Certificate management – All Servers
b. Find the expired *-trust certificates. (10.0 and higher you can filter by Expiration. Below
10.0 you will need to identify the specific certificates manually – or via the RTMT alerts if
received)
c. You may see the same trust certificate in multiple nodes. It must be deleted individually
from each node.
d. Select the trust certificate to be deleted (depending on your version you will either get a
pop-up or you will be navigated to the certificate on same page)
i. Select Delete (you will get a pop-up that begins with “you are about to
permanently delete this certificate…”
ii. Select OK – The pop-up will go away, and the GUI will refresh
iii. Repeat the process for every trust certificate to be deleted
3) Upon Completion of deleting the trust certificates, you will need to restart services per the
certificates deleted – you do not need to reboot phones in this section.
a. Tomcat-trust: restart Tomcat Service via command line (See Tomcat Section)
b. CAPF-trust: restart Cisco Certificate Authority Proxy Function (see CAPF Section)
c. CallManager-trust: CallManager Service/CTIManager (See CallManager Section)
d. IPSEC-trust: DRF Master/DRF Local (See IPSEC Section)
4) Restart Services Previously Stopped
a. Tools > Control Center – Network Services
b. From the drop down select the CUCM Publisher
c. Start Certificate Change Notification
d. Repeat for every Call Manager node in your cluster
e. If you have an Instant Message and Presence (IMP/CUPS) Server
f. Start Platform Administration Web Services

144 Views
0 Comments

My aim is to connect my CUBE to a remote CUBE (G711u) with SIP-TLS control (SIPs) and encrypted the RTP payload (SRTP)

Between my CUBE and my CME (G729), I want only SIP and RTP.

 

 

 

archi.PNG

source: https://www.cisco.com/en/US/docs/ios-xml/ios/voice/cube_proto/configuration/15-2mt/voi-srtp-rtp-int.html

 

LICENCE:

Even if cme-srst and cube licence are activated, I need also to activate the technology-package securityK9 in order to have access to all srtp commands.

 

CONTROL:

The Cisco Unified Border Element supports SIP To SIP calls with TLS. CUBE can be configured at both the global and dial-peer levels for allowing TLS to establish secure sessions between two CUBE.

In order to check the feature information for SIP TLS support on CUBE please refer to this cisco documentation:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-sip-tls.pdf

 

On my plateform I've got one CA (Windows 2012R2) and I use SCEP protocol in order to certified my CUBE with the CA.

SCEP documentation: https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/116167-technote-scep-00.html

 

Step 1:

Generate on CUBE the rsa key:

crypto key generate rsa general-keys label CUBE modulus 2048

 

Step 2:

Create the pki trustpoint-CA on CUBE

crypto pki trustpoint ca-server

 enrollment mode ra

 enrollment url http://@ip-SRV-CA:80/certsrv/mscep/mscep.dll

 serial-number

 revocation-check none

 rsakeypair CUBE

 

Step 3:

Collect the Root CA certificate in the CUBE's flash memory:

crypto pki authenticate ca-server

 

Step 4:

Check the receipt of the Root CA certificate thanks to the serial number in comparaison with the CA server.

sh crypto pki certificates verbose ca-server

CUBE-A#sh crypto pki certificates verbose ca-server

CA Certificate

  Status: Available

  Version: 3

  Certificate Serial Number (hex): 1B8EEAF0AFFE78A94C54BAAA45A13329

  Certificate Usage: Signature

[.......]

 

Step 5:

Enroll the CUBE:

crypto pki enroll ca-server

 

Step 6:

The CUBE is waiting for a challenge. Then, on your CA server go to:

http://localhost/certsrv/mscep_admin/ (You will need Domain Administrator account)

Then you can copy the challenge (password's lifetime=60 minutes)

SCEP.PNG

 

Step 7:

CUBE configuration:

voice service voip

 allow-connections sip to sip

 no supplementary-service sip handle-replaces

 fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

 sip

  bind control source-interface Loopback0

  bind media source-interface Loopback0

  session transport tcp tls ***** global configuration or on dial-peer *****

  registrar server expires max 600 min 60

[…….]

sip-ua

 crypto signaling default trustpoint ca-server ecdsa-cipher

 transport tcp tls v1.2

[…….]

 

On the dial-peer with the remote CUBE enter:

voice-class sip url sips

 

On my plateform the remote CUBE has got the same configuration. The same CA server is used. If you want to test with two differents CA server don't forget to put the Root CA certificate of the Remote CA server by creating another pki trustpoint:

crypto pki trustpoint Remote-CUBE
 enrollment url http://@ip-Remote-CUBE:80
 revocation-check none

 

 

 SRTP:

 

You need first to configure the dspfarm profil in security mode:

dspfarm profile 1 transcode security

 codec g729abr8

 codec g729ar8

 codec g711alaw

 codec g711ulaw

 codec g729r8

 maximum sessions 5

 associate application CUBE

 

With LTI method we don't need to register the Secure Universal Transcoder to the CUBE, with SCCP method you need it, refer to the cisco documentation:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_proto/configuration/12-4t/cube-proto-12-4t-book/voi-srtp-rtp-int.pdf

 

Then, we have to configure the dial-peers on our CUBE:

Dial-peer between CUBE and my local CME:

[.......]

dial-peer voice 29702 voip

 description DP-INBOUND-FROM-LOCAL-CME

 incoming called-number 2970.$

srtp fallback

 no vad

[.......]

dial-peer voice 29710 voip

 description DP-OUTBOUND-TO-LOCAL-CME

 destination-pattern 2971.$

 session protocol sipv2

 session target ipv4:10.10.10.10

 srtp pass-thru

 no vad

[.......]

 

Dial-peer between CUBE and Remote CUBE:

[.......]

dial-peer voice 2970 voip

 description DP-OUTBOUND-TO-REMOTE-CUBE

 destination-pattern 2970.$

 session protocol sipv2

 session target ipv4:30.30.30.30

 srtp

 codec g711ulaw

 no vad

[.......]

dial-peer voice 2971 voip

 description DP-INBOUND-FROM-REMOTE-CUBE

 incoming called-number 2971.$

 srtp

 codec g711ulaw

 no vad

[.......]

 

On the voice service voip menu:

voice service voip

 mode border-element license capacity 100

 srtp fallback

 allow-connections sip to sip

 fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

 sip

  bind control source-interface Loopback0

  bind media source-interface Loopback0

  srtp-auth sha1-80 (SHA-32 by default).

 

We can also configured srtp-auth on the dial-peer:

voice-class sip srtp-auth sha1-80

 

 

TEST:

With CAIN ou Wireshark you can check the SIP-TLS connection and if the RTP is well encrypted between the two CUBE.

 

On your CUBE:

#show call active voice brief

194 Views
0 Comments

The ILS - Intercluster Lookup Service feature enables different CUCM Cluster to exchange directory URI with other clusters in an ILS network. URI Replication provides support for intercluster URI dialing. ILS runs as a service on the Publisher node of a cluster. 

 

We can call ILS - Intercluster Lookup Service as Voice Routing Protocol because it behaves like dynamic routing protocol. Just like advertising the local route from one router to another, ILS will advertise the URIs between different CUCM cluster.

 

Each CUCM cluster node advertises its URIs and “SIP route string” to its neighbor’s (or Hubs). CUCM cluster later creates a table with URIs and associated SIP route string. Finally, SIP route strings are routed through SIP route patterns.Intercluster Lookup Service Configuration.jpg

Contents

1. ILS Configuration using Password Authentication

2. ILS Configuration using TLS Certificate Authentication

3. ILS Configuration using TLS Certificate Authentication - Common CA Signed

 

There are two types of clusters in ILS.

Hub Cluster:

  • Each ILS network must have at least one hub cluster and they are the backbone of an ILS network.
  • Hub clusters exchange ILS updates with the other hub clusters in the ILS network and then relay that information to and from their spoke clusters.
  • You can connect a hub cluster to multiple other hub clusters, or you might configure a hub cluster as the only hub cluster in the network.
  • In addition, you can connect a hub cluster to multiple spoke clusters, or you might configure the hub cluster with no spokes clusters. 

Spoke Cluster

  • A spoke cluster in an ILS network relies on the hub cluster that it is connected to in order to relay ILS updates to and from the rest of the ILS network.
  • A spoke cluster can have only one hub cluster.

 

In this document, we are going to see the step by step configurations for ILS - Intercluster Lookup Service with password authentication as well as TLS (Certificate) authentication.

 

Topology

I have 2 CUCM clusters here in the ILS network.

  • 10.106.79.71 - HQ Cluster
  • 10.106.79.83 - BR Cluster

topology.png

 

1. ILS Configurations Using Password Authentication

  • ILS password authentication configuration is pretty easy and straightforward. The HUB and SPOKE clusters will exchange some unique password to establish ILS connection.

Let's have a look at the configuration window.

Step 1.1: Activate Intercluster Lookup Service on all the CUCM Publisher

Go to Service Ability > Tools > Service Activation > Select 'Intercluster Lookup Service' and save.

 

0.png

Step1.2: Set Cluster ID for the CUCM Clusters

Cluster ID is a unique identifier for the cluster.

Go to CUCM Administration Page > System > Enterprise Parameter > Cluster ID

 

1.png

 

Note: Make sure you configure unique cluster ID for all the nodes in the ILS network.Moreover, we need to restart all services for the parameter change to take effect.

Step 1.3: HUB Cluster ILS Configuration

I'm planning 10.102.79.71 as my ILS HUB Cluster.

Go to Advanced Features > ILS Configuration > and configure as follows.


AA1.png

 

> Save

Route String: This will be a unique string that will be advertised to the other clusters. Other ILS peers use Route String to route the call.

 

Above configuration uses 'Password' based ILS authentication and synchronize the clusters every 1 minute.

 

Note: When you configure the Advertise Route String, make sure it is less complex. Sometimes the URI Call fails if we have more "-" and "Letters" in the Route String. Bug: CSCtz63687

 

The moment you click Save, it will ask for ILS Registrar Server. Since I do not have any other HUB cluster, we can leave blank and click OK

 

4.png

 

Step 1.4: Spoke Cluster ILS Configuration

10.106.79.83 is our SPOKE cluster.

Go to Advanced Features > ILS Configuration > and configure as follows.


A2.png

 

When you click Save, enter the Registrar server as the HUB cluster 10.106.79.71.

 

6.png

 

Step 1.5: Refresh the ILS Configuration 

Now refresh the ILS configuration to see the updated status.

 

A3.png

 

Step 1.6: Configure URIs for the End Users

Go to User Management > End User > and select the user you want to enable URI.

For LDAP user, make sure the URI is synced from LDAP server. For the local users, you can set a URI as shown below.CUCM End User URI Configuration.png

 

Now go to the Controlled Devices section in the same page and assign the user's desk phone as the controlled device. Also, configure the primary extension.Primary extension for URI dialing.png

 

Note: Primary extension maps the URI with the Directory number, hence it is mandatory to configure primary extension on the user page. Also, note that all the URIs will be in the 'Directory URI' partition by default.

 

Now go ahead and check the Directory number (e.g. 1002), you will be able to see the URI field.Direcory URI configuration CUCM.png

 

Similarly, you configure another URI for a test user in another cluster.

Step 1.7: Verify the Learned Directory URIs

Go to Call Routing > Global Dial Plan Replication > Learned Directory URIs9.png

 

A4.png

 

Note: Any of the URI learned via ILS will be having 2 unique values. One is the Route String and another one is Cluster ID. Route String is used to route the call back to the respective cluster via a separate SIP trunk.

 

ILS will only take care of advertising the URIs between clusters. They do not participate in call routing. For dialing the URI from one cluster to another, we need to have a separate SIP trunk.

Step 1.8: Create a SIP Trunk in Hub & Spoke Cluster and Point each other

  • Create a SIP Trunk in Hub Cluster CUCM and point the destinations to the Subscriber servers (CUCM Nodes which runs CCM Service) of the Spoke cluster.

 

  • Create a SIP Trunk in Spoke Cluster CUCM and point the destinations to the Subscriber servers (CUCM Nodes which runs CCM Service) of the Hub cluster.

11.png

  • Since configuring SIP Trunk is out the scope of this article, I have just provided above screenshot. Feel free to comment here any queries regarding the SIP trunk.

Note: By default, all the URIs will be assigned with 'Directory URI' partition. Hence you must have a CSS with Directory URI partition that is assigned as Inbound CSS at the SIP Trunks.

 

A5.png

 

A6.png

 

Step 1.9: Configure SIP Route Pattern

  • The Advertise String of other ILS node will be the SIP Route Pattern. We need to create SIP Pattern at the HQ cluster as well as BR Cluster.

Go to Call Routing > SIP Route Pattern > Add New and Point the SIP Trunk.

 

A7.png


A81.png

 

Step 1.10: LAB Testing

  • I have configured a speed dial as a URI which points to the other cluster. Calls are working fine in both directions.

URI Speed Dial in CUCM.png

 

A9.png

 

Warning: The above method is the simplest way of getting the ILS up and running. In order to read further on this article (other ways of configuring ILS), you need to have a better understanding of CUCM Certificates and Multi SAN Certificates 

2. ILS Configurations Using TLS (Certificate) Authentication (Certificate Cross Import Method)

  • To use Transport Layer Security (TLS) authentication between clusters, you must exchange Tomcat certificates between the publisher node of each cluster in the ILS network.
  • From HUB Cluster Cisco Unified Operating System Administration, download the Cisco Tomcat Certificate.
  • Upload the same as Tomcat Trust in the SPOKE cluster.
  • Similarly, download Cisco Tomcat certificate from SPOKE cluster and upload to HUB as Tomcat Trust.
  • Service activation (Step 1.1) and Cluster ID configuration (Step 1.2) are same in this section as well. Hence I haven't added those screenshots.

Step 2.1: Downloading Tomcat Certificate from HUB Cluster

  • Go to OS Administration Page of HUB Cluster Publisher Server.

Security > Certificate Management > and the search for 'Tomcat'

 

Cisco Tomcat Certificate Management.png

 

Note: In my example, I have a CA-signed Certificate, but the procedure is pretty same for Self Signed certificate as well.

  • Click on the certificate and Download it (Save in a proper place).Download CUCm Tomcat Certificate.png

     

Step 2.2: Upload the HUB Certificate to the SOPKE as Tomcat-Trust

Login to SPOKE cluster publisher OS Administration > Security > Certificate Management > Upload Certificate/Certificate chain.CUCM Upload CertificateCertificate chain.png

 

  • Now browse the certificate downloaded in Step 2.1 and then click 'Upload' button.

ILS Upload CertificateCertificate chain.png

 

Note: The system will tell you to restart Cisco Tomcat Service but it is actually not required! :)

Step 2.3 & 2.4: Upload SPOKE Certificate as Trust in HUB

Follow the same process and get the certificate from Spoke cluster and upload to HUB as Tomcat Trust.

Step 2.5: Configure ILS on the HUB & SPOKE Clusters with TLS Certificate Authentication

Go to Advanced Features > ILS Configuration > and configure as follows.ILS Configuration based on TLS Authentication.png

 

Note: When we click Save on the HUB, it will ask for the registrar server, please Skip that. But when you click Save on the SPOKE, please provide HUB IP address to the registrar server.

 

  • Also, note that we have selected 'Use TLS Certificates' as the ILS authentication mechanism.

 

Register Spoke cluster to ILS Hub.png

 

  • Refresh the configuration after few minutes.

ILS Connection established using TLS Certificates.png

 

  • ILS connection has been established. The remaining configurations like adding URIs, creating SIP Route Pattern, SIP Trunk and Speed dials (Step 1.6 to Step 1.10) is same as discussed above.

3. ILS Configurations Using TLS (Certificate) Authentication (Common CA-signed Method)

  • In the multi-cluster environment (more than 20+ clusters for example), exchanging (cross importing) certificate between all the clusters are not practical (or time-consuming).
  • When the certificate expires, you will have to cross import the certificates again.
  • In that scenario, we can use the Common CA-signed certificates to on every cluster.
  • Once we have HUB and SPOKE tomcat certificates are signed by same CA, we do not need to cross import the certificates each other.
  • But in this case, we need to use Password Authentication first and once it establishes the ILS connection, switch back to TLS.

Note: In CUCM Version 10.5, you can either select Password Authentication or TLS Authentication but not both. Whereas in CUCM Version 11.5, we can select both.

Summary:

  • Use common CA to sign the tomcat certificate of HUB and SPOKE
  • Establish ILS with Password authentication only
  • Switch the ILS authentication to TLS only.

ILS Connection comparison.png

 

Step 3.1: Download HUB and SPOKE Tomcat Certificates

There are different methods to check the Tomcat certificate. The easiest way would be opening the HUB CUCM-PUB URL on Internet Explorer and click the Security Report lock button > View Certificate.

 

View CUCM Tomcat Certificate from Internet expolorer.png

 

Go to the Details tab and click Copy to File....Cisco Tomcat Certificate details.png

 

Click Next from the Certificate export wizard window.CUCM Certificate export wizard.png

 

Select DER encoded binary X.509 (.CER)DER encoded binary X.509.png

 

Enter the directory path to Save the CUCM certificate and proceed.

 

Managing CUCM Certificates.png

 

Click Finish button to complete the certificate download process. You will be getting Export Successful message.Exporting CUCM certificate.png

 07.png

 

Repeat the same steps for downloading SPOKE CUCM-PUB tomcat certificate.

Step 3.2: Verify the HUB and SPOKE Tomcat Certificates

Once you have the HUB and SPOKE certificates downloaded, open those in side by side and compare the following. We have to perform a number of checks.

 

Check 1: Issued by

Go to the General tab of the Certificate and check the 'Issues by' field. This should be same in the HUB and SPOKE certificates. For this example, the certificate is issued by 'UCCOLLAB-CA'

 

CUCM certificate requirement for ILS configuration.png

 

Check 2: Enhanced Key Usage 

Go to the Details tab of the certificate and check the 'Enhanced Key Usage' field. There should be 'Server Authentication' and 'Client Authentication'

 

Enhanced Key Usage in CUCM Certificate.png

 

Check 3: Certification Path

Go to 'Certification Path' and check the hierarchy. It should be similar on HUB and SPOKE. 

 

CUCM Tomcat Certification Path.png

 

Note: if there is an intermediate CA, you can see that is on the path. Make sure both HUB and SPOKE follows same certification path.

Step 3.3: Check the HUB Hostname & Certificate Common Name

Check 4: Server name and Common Name of HUB

Login to the HUB cluster Publisher CLI and check the Common name of the Publisher using 'show network cluster' command.ILS Hub show network cluster.png

 

  • Here the Publisher name is 01-01-CUCM01-PUB.uccollab1.com
  • You have to see the same name on the HUB Publisher certificate Subject Name field CN.
  • Open the Certificate and go to Details tab > Subject and check the CN - Common Name.
  • In our case, it is matching to the above CLI output 01-01-CUCM01-PUB.uccollab1.com

 

CUCM Certificate Subject Name.png

 

Check 5: Server name and Common Name of SPOKE

Login to the SPOKE cluster Publisher CLI and check the Common name of the Publisher using 'show network cluster' command.ILS Spoke show network cluster.png

 

  • Here the SPOKE Publisher name is 01-13-CUCM01-PUB
  • Open the Certificate and go to Details tab > Subject and check the CN - Common Name.
  • In our case, it is matching to the above CLI output, that is 01-13-CUCM01-PUB

ILS CUCM Certificate Subject Name.png

 

Note: I do not have DSN server configured for SPOKE cluster. Hence we have only the hostname in the 'show network cluster' and in the 'Certificate'. If I would have configured DNS, this could have been an FQDN (refer the HUB certificate where I have DNS configured).

Step 3.4:  Establish ILS Connection with Password Only and Populate the Peer-vector

Go to Advanced Features > ILS Configuration > and establish the ILS connection between HUB and SPOKE using password authentication method (already explained in Step 1.3, Step 1.4)

 

ILS Password Peer.png

 

Once we have the ILS connection established, the Peer-vector table will populate automatically. Log in to the CLI of each publisher and issue 'utils ils showpeerinfo'. Make sure you have all the ILS peers in the output.

 

utils ils showpeerinfo.png

Step 3.5: Compare Peer-Vector Table with Subject Common Name

  • Basically, we establish ILS initially with Password Authentication and then switch back to TLS only.
  • Behind the scene, when we use the password to establish the ILS connection, the ILS node will update the peer-vector table, which is a DB Table that contains all the ILS peers information.
  • Use 'utils ils showpeerinfo' CLI command to see the ILS peer table.
  • Once we switch to TLS only (after establishing the ILS with password), the HUB will check the Common name of the Publisher in the Certificate to matches with peer-vector table Clustername.
  • The peer-vector table was already populated with all peers when we used password authentication.

Check 6: Peer-vector Vs Common Name

Go to HUB cluster Publisher CLI and issue this command 'utils ils showpeerinfo' and check the 'Clustername' of SPOKE. This should match the Subject CN of SOPKE's certificate.

ILS Peer info Certificate common name.png

 

Go to SPOKE cluster Publisher CLI and issue this command 'utils ils showpeerinfo' and check the 'Clustername' of HUB. This should match the Subject CN of HUB's certificate.

ILS Configuration with Certificate authentication common name.png

 

Step 3.6: Switch Back to TLS Authentication

Once the peer-vector table is updated, we can remove the password authentication and use TLS authentication only.

Go to Advanced Features > ILS Configuration > Change the authentication back to 'Use TLS Certificate'

 

ILS Connection established using TLS Certificates CA Signed.png

 

  • We noticed that the ILS connection is remains established even after removing the Password Authentication. 
  • The 6 number of Checks are mandatory to have a successful ILS connection
  • The remaining configurations like adding URIs, creating SIP Route Pattern, SIP Trunk and Speed dials (Step 1.6 to Step 1.10) is same as discussed above.

 

Note: Any time if the ILS connection is broken and if you want to re-establish, we need to do the same process again (first password and then TLS)

 

 

Comments to the Readers:

We have successfully done all possible ways of configuring ILS. If you are able to follow all the process explained above, there won't be any issues while configuring and troubleshooting ILS. I will be publishing a detailed ILS troubleshooting (with ILS traces and logs) article soon. Please rate this article if helped. Feel free to ask doubts.

 

Few of my other Support forum Documents:

You may also interested to take a look at my other articles in the support forum.

 

Regards,

Abdul Jaseem

 

49 Views
0 Comments

I have a customer that wants to migrate from expensive analog FXS lines to a SIP Provider/ITSP.  After getting multiple quotes, it seemed like Nextiva was the best fit for this small office environment.  Once we signed up for Nextiva, I was less than impressed with the amount of support they offer to get customer's SIP trunks operational.  Their Tier 4 support can basically only tell you if your connected to them or not.  They'll tell you to install a free soft phone and if your soft phone registers, they say they've proven their side is good and it's up to you to figure out your PBX configurations.  They have no example configs or recommendations for Cisco CME/CUBE/VGRs connecting to Nextiva.  I was given my Username, Password, and the domain bt.voipdnsservers.com

 

So, after hours of analyzing packet captures, debugs, and working with TAC, I was able to get a working configuration between Cisco CME/CUBE and Nextiva.  I'm posting the relevant configurations to hopefully save everyone a huge headache and a ton of time, if you choose Nextiva as a SIP trunk provider ITSP.

 

My environment includes a CME/CUBE, with all SIP traffic bound to loopback 0.  I'm using private IP space on the LAN and NAT'ing all networks at my firewall that connects to the ISP.

 

First things first, ensure that the IP of the CME/CUBE Loopback 0 is included in your NAT at the firewall and that your firewall has the proper routes to the CME/CUBE Loopback 0 address on the inside.  I did not perform any PAT inbound to the CME and I did not add ACLs permiting SIP or anything inbound.

 

Nextiva needs the SIP messages to come in a certain way.  We will be creating a SIP Profile to modify the SIP header as it is sent out.  I will include a generic dial-peer showing the SIP Profile applied.  By default, any existing pots dial-peer will try to register with the SIP Registrar, so i will include a pots dial-peer command that stops that.  Since the Nextiva IP's are not specifically configured as a SIP destination, inbound calls will be denied by default when coming from an unknown IP.  We will add ip address trusted list commands to the CUBE configuration to allow the IP's in. You can modify this to the exact IP's of the ITSP.

 

voice service voip
ip address trusted list
 ipv4 0.0.0.0 0.0.0.0
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
supplementary-service h450.12
no supplementary-service sip refer
fax protocol pass-through g711ulaw
h323
sip
 bind control source-interface Loopback0
 bind media source-interface Loopback0
 no call service stop

!
voice class codec 1
 codec preference 1 g711ulaw
 codec preference 2 g729r8
!

!

!***Note that the ALL_CAPS portions require your information*******

!

!
voice class sip-profiles 200
request ANY sip-header From modify "YOUR_LOOPBACK_IP_ADDRESS" "bt.voipdnsservers.com"
request ANY sip-header From modify "sip:(.*)@" "sip:NEXTIVA_USERNAME/PHONE_NUMBER@"
request INVITE sip-header SIP-Req-URI modify "bt.voipdnsservers.com:5060" "bt.voipdnsservers.com"
!
!

!

!

!

dial-peer voice 100 pots
 no sip-register

!

dial-peer voice 200 voip
description Incoming_Calls_From_ITSP
session protocol sipv2
incoming called-number YOUR PHONE NUMBER FROM ITSP
voice-class codec 1
dtmf-relay rtp-nte sip-notify
no vad
supplementary-service h450.12

!

dial-peer voice 201 voip

description Outbound_Calls_To_ITSP
destination-pattern ..........
session protocol sipv2
session target dns:bt.voipdnsservers.com
voice-class sip profiles 200
dtmf-relay rtp-nte sip-notify
voice-class codec 1
no vad
!

 

!

!

sip-ua
 credentials username YOUR_USER_NAME password YOUR_PASSWORD realm bt.voipdnsservers.com
 credentials username YOUR_USER_NAME password YOUR_PASSWORD realm nextiva.com
 authentication username YOUR_USER_NAME password YOUR_PASSWORD realm bt.voipdnsservers.com
 authentication username YOUR_USER_NAME password YOUR_PASSWORD realm nextiva.com
 no remote-party-id
 retry invite 10
 retry register 10
 retry subscribe 3
 registrar dns:bt.voipdnsservers.com expires 3600
 sip-server dns:bt.voipdnsservers.com
 host-registrar
!

 

 

To verify your registration, run the following command:

 

show sip-ua register status

 

You should see the phone number/username showing "yes" for registerd.  It may take a few test calls before calls for the ITSP to begin routing calls.

 

I hope this helps!

414 Views
1 Comment

Hello guys!

 

I am not an expert but I read and try to make it happen. This might be simple, however, I was not able to find it in many tutorials. So I said I would share it with you guys. Because I have learned a lot from you guys. So I am trying to keep passing knowledge here. Please follow the scenario and you will find the answer.   

Recently I was working on changing the Wallpaper of 8841 and 8865. I was kinda stuck on not having the new images that I uploaded. When I go to settings > wallpapers. I can only see the old images or the default images. Even though my sizes images were perfect and the directory was OK! no syntax errors in my List.xml everything was smoothly restarted my TFTP servers couple times no changes. I was like whats going on until I found the solution is by deleting a file named List.xml.sgn !!! and restarted the TFTP servers and worked! List.xml.sgn was generated again after the restart.  

 

Thank you!

 

// Moe

190 Views
0 Comments

We have struggled with an issue for more than a year related to HA over WAN. Even a brief network outage (1-2 seconds) between data centers would cause the master role to switch from the publisher to the subscriber. Mastership changed any time the nodes went into island mode. We finally found the root cause after numerous TAC cases, and I think it's worth sharing since changing the hostnames is supported.

The logic to elect the master node when recovering from island mode is:

Step 1. Check the service status of the nodes. If node 1 is IN_SERVICE and node 2 is in PARTIAL_SERVICE, node 1 becomes the master. If the states are the same (IN_SERVICE or PARTIAL_SERVICE), go to step 2.

Step 2. The hardware specification of both nodes will be checked. The server with the better specification will be handed the mastership. If the hardware specifications are the same, go to step 3.

Step 3. The publisher (i.e. node 1) will become the master if the hostname matches the PrimaryEngineComputerName in the ClusterSpecificConfig. If there is no match, go to step 4.

Step 4. Make the subscriber master.

Alright, now let's back up about 18 months. We decided to build a new cluster to migrate from version 9.0 to 10.6. The intent was to simplify the transition from CAD to Finesse. We built a new cluster on 9.0, restored from backup, changed the hostnames and IPs, and then upgraded to 10.6.  

Back to the present (now on version 11.6), we finally lucked out with a TAC engineer that explained the island mode recovery process above. The engineer used the CET (Configuration Editor Tool) to check the ClusterSpecificConfig file where we discovered the primaryEngineComputerName was the hostname of our 9.0 publisher. So now we know step 3 above always fails and the subscriber is elected master as a result.

PrimaryEngineComputerName.png

 

TAC advised this value is populated at the time of install and cannot be changed (even with root access). The 9.0 cluster had been offline for over a year. Therefore, the best solution was to rename the 11.6 publisher to match the primaryEngineComputerName.

In conclusion, changing the hostname is supported, but it will cause issues with HA. Ideally, the set network hostname command should be updated to also change the primaryEngineComputerName. I asked to have a caveat added to the appropriate section of the admin guide. It's unclear if this request reached the technical writing team – I never received confirmation.

83 Views
0 Comments

Hi folks

Recently I made a python script to aid on configuring streaming URL for a customer.

Pretty simple but pretty helpful, it saved me hours.

Cheers

 

https://gitlab.com/aocbrasil/cms-streamer.git

 

154 Views
0 Comments

Screenshot_2.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

no permite cargar los codec

Screenshot_3.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

esta si permite cargar los codec desde el cucdm

 

 

322 Views
0 Comments

Long time integrator of Cisco technologies and I was told there is an API that provides an interface to query real-time or near realtime QoS data from the actual endpoint device. If you are aware of such a mechanism can you point me to where I can read about it.

 

Information from TP and Meeting Server logs are just rolled up summary of the session. I Am looking for more time-based granularity.  Or is the only option using SNMP? 

Read more...

112 Views
0 Comments

To look at media resources and the allocated MRGs, use the sql query

 

run sql select mrg.name as mrg,d.name as resource from mediaresourcegroup mrg inner join mediaresourcegroupmember mgm on mgm.fkmediaresourcegroup=mrg.pkid   inner join device d on mgm.fkdevice=d.pkid

 

To filter specific site

 

run sql select mrg.name as mrg,d.name as resource from mediaresourcegroup mrg inner join mediaresourcegroupmember mgm on mgm.fkmediaresourcegroup=mrg.pkid   inner join device d on mgm.fkdevice=d.pkid where d.name like '%AD1%' or mrg.name like '%A01%'

 

Use this CLI command to find media resources in the default MRG (no assigned to any created MRG).

admin:run sql select d.name as resource from device as d full outer join mediaresourcegroupmember as mgm on mgm.fkdevice=d.pkid where and mgm.pkid is NULL

resource  

===========

AD1MTP-G711 

AD1XCODER

 

 

You look for specific device type such as MTP

 

admin:run sql select d.name as resource from device as d full outer join mediaresourcegroupmember as mgm on mgm.fkdevice=d.pkid where d.name like '%MTP%' and mgm.pkid is NULL

resource  

===========

AD1MTP-G711

473 Views
0 Comments

Well I am new here and not a high level professional  if anything wrong please correct me this blog is all about my own experience and challenges faces after  migration from Cisco  Agent Desktop 8.5 to Cisco Finesse Agent Desktop 11.5.

Recommendation:

I strongly recommend that you guys created a isolated environment during migration and test each and everything thing before migration in comparison  with older one.

Challenges Faced After Migration:

We had created an isolated environment and thinking wow we are up the mark and everything will work smoothly but the story began after migration we had tested prompts, scripts all other thing perfectly but when we login to Cisco Finesse Agent we shocked it's a simple gadget without Chat and other things everything is customized able. We had researched a lot and doesn't found any chat gadget up to the mark so we requested client and used Cisco Jabber instead of Cisco IP Communicator. Well Story not ended yet when we login to Cisco Finesse Supervisor and in the newer version Cisco Supervisor is not able to see Agent incoming/outgoing call status as per previous Cisco Agent Desktop again we had researched on it and doesn't found any gadget as it required customization at CTI level which will impact our reputation badly towards Client. It is requested all of you guys who is doing migration first time please keep in mind that Cisco Finesse is limited gadgets as compare to Cisco Agent Desktop(CAD). Hopefully Cisco is working on this and will create new gadgets to overcome these type of problems.

Thanks,

114 Views
0 Comments

Приветствую, коллеги. 

Есть задача заставить совершаться звонки с Jabber на внешние адреса и по SIP и по h323.

Имеем схему "Cisco Jabber - CUCM - Expressway C - ExpressWay E - внешние абоненты."

Конспективно решение выглядит следующим образом:

1. На "CUCM" (Call Routing -> SIP Route Pattern) создается маршрут используя "Domain Routing" с указанием домена на который требуется вызов и транка на "ExpressWay C".


2. На обоих серверах "ExpressWay C" и "ExpressWay E" (Configuration -> Protocols ->h323 или SIP) проверяем, что включены оба протокола SIP и H323. А также включена функция "Interworking" (Configuration -> Protocols -> Interworking) "H.323 <-> SIP interworking mode" в состоянии "On".


3. На "ExpressWay E" (Configuration -> Authentication -> Devices -> Local database) создается пользователь для аутентификации создаваемой далее зоны между "ExpressWay С" и "ExpressWay E".


4. На "ExpressWay E" (Configuration -> Zones -> Zones) создается зона с указанием: тип зоны "Traversal server", ранее созданные Логин/пароль для аутентификации, порты для протоколов SIP и H323.


5. На "ExpressWay C" (Configuration -> Zones -> Zones) создается зона с указанием: тип зоны "Traversal client", ранее созданные Логин/пароль для аутентификации, ранее указанные порты для протоколов SIP и H323, в поле "Peer 1 address" адрес "ExpressWay E". Внутренний, если у вас используется Dual Network конфигурация.


6. Проверяем, что статус зоны на обоих серверах "ExpressWay C" и "ExpressWay E" по обоим протоколам, SIP и H323, в состоянии "Active".


7. На "ExpressWay C" (Configuration -> Dial Plan -> Search rules) создается правило по маршрутизации поступившего с "CUCM" вызова на требуемый домен: оставляя структуру вызова как она была, отправлять на ранее созданную зону "ExpressWay E".


8. На "ExpressWay E" (Configuration -> Zones -> Zones) создается DNS зона, где включаются оба протокола, выбирается транспортный протокол (TSP/UDP/TLS) и самое главное в разделе "Advanced" в поле "Include address record" ставим "On"! Включение данного параметра позволяет собственно разрешать имена в адреса при помощи DNS. 


9. На "ExpressWay E" (Configuration -> Dial Plan -> Search rules) создается создается правило по маршрутизации поступившего с "ExpressWay C" вызова на требуемый домен и оставляя структуру вызова как она была отправлять на только что созданную DNS зону.


10. На "ExpressWay E" (Configuration -> Dial Plan -> Configuration) в поле "Calls to unknown IP addresses" установить параметр "Direct".


11. Проверяем работоспособность.

763 Views
0 Comments

Hello colleagues

After a difficult deployment in South Korea, I want to share with you the complete Dial Plan and Dial Peer configuration for Cisco CUBE and SIP trunking.

As some of you might have experienced, trying to find the complete dial plan for South Korea is practically impossible if you don't speak Korean (which I don't, just for the record).

South Korea uses a non standard dial plan with different length numbers, area codes and public services; preceeding zeros an local dialing within it's different provinces. In my case, I implemented this for an office in Seoul

In order to implement this dial plan, it was necessary to investigate all the possible dial patterns and transform the dialing to a fully E164 compliant dialing (Service Provider requirement).

I used a Cisco 4331 router with Cisco IOS XE Software, Version 03.16.05.S. UCk9 and CUBE licenses,

I'm also attaching the Excel file with the different patterns for CUCM and Cisco IOS Router.

Hope this is useful for anybody and a big thanks to my coworker Tae who helped me with the translation of the Excel

Best

Allan Mancera