JASON NEUROHR

CMS as a CUCM Conference Bridge


Wednesday, November 15, 2017

A brief article detailing how to configure the Cisco Meeting Server (CMS) as a conference bridge resource in Cisco Unified Communications Manager (CUCM) for ad-hoc call escalation. OpenSSL is used only for example purposes, in production, a more appropriate certificate authority should be used for signing certificates in your production environments.

Create a Root CA using OpenSSL

Generate a key and the certificate to use for signing CSR requests as a root certificate authority. 

openssl genrsa -out root.key 2048
openssl req -x509 -new -nodes -key root.key -sha256 -days 1024 -out root.pem

Create a CMS CSR and Sign it using the Root CA

Using OpenSSL create a new certificate signing request (CSR) for CMS, which will be used for the webadmin and callbridge services.

openssl req -new -nodes -newkey rsa:2048 -sha256 -keyout cms1.key -out cms1.csr -subj “/C=AU/ST=NSW/L=Sydney/O=Lab/CN=cms1.assured.io”
openssl x509 -req -in cms1.csr -CA root.pem -CAkey root.key -CAcreateserial -out cms1.crt -days 500 -sha256 -extensions v3_req -extfile openssl-san.cnf

Note the file openssl-san.cnf is populated as follows.

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
extendedKeyUsage = serverAuth # CMS serverAuth

[ alt_names ]

DNS.1 = cms1.assured.io

SFTP the root.pem, cms1.key, and cms1.crt to the CMS server.

Create a CUCM CSR and Sign it using the Root CA

Log into the Cisco Unified OS Administration. Navigate to Security > Certificate Management. Click Generate CSR.

  • Change the Certificate Purpose to CallManager.
  • Download the CSR.
  • Using OpenSSL sign the certificate

openssl x509 -req -in CallManager.csr -CA root.pem -CAkey root.key -CAcreateserial -out CallManager.crt -days 500 -sha256 -extensions v3_req -extfile openssl-san.cnf

Note the openssl-san.cnf is populated as follows.

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
extendedKeyUsage = serverAuth,clientAuth,ipsecEndSystem # CUCM clientAuth, serverAuth, ipsecEndSystem

[ alt_names ]

DNS.1 = cucm.assured.io
DNS.2 = assured.io

  • Return to the CUCM Certificate Management page and click Upload Certificate/Certificate Chain.
  • Change the Certificate Purpose to CallManager-trust and upload the file root.pem.
  • Click Upload Certificate/Certificate Chain, change the Certificate Purpose to CallManager and upload the file CallManager.crt.

Configure CMS to Utilise the Signed Certificate

SSH to the CMS server and configure webadmin.

webadmin disable
webadmin certs cms1.key cms1.crt rooCA.pem
webadmin listen a 445
webadmin enable

Configure the callbridge.

callbridge certs cms1.key cms1.crt rooCA.pem
callbridge restart

Configure a Secure SIP Trunk in CUCM for the CMS

In testing, using a non-secure SIP trunk results in the conference bridge not registering, therefore you must use a secure SIP trunk.

Log in to Cisco Unified CM Administration. Navigate to System > Security > SIP Trunk Security Profile. Click Add New, and configure with:

  • Name - CMS_SecureTrunk
  • Device Security Mode - Encrypted
  • Incoming Transport Type - TLS
  • Outgoing Transport Type - TLS
  • X.509 Subject name - Configure as appropriate, in this case, cms1.assured.io
  • Incoming Port - 5061
  • Accept replaces header - Checked

Navigate to Device > Trunk. Click Add New:

  • Device Name - CMS01
  • Device Pool - Select as appropriate
  • SRTP Allowed - Checked
  • Inbound Calls > Calling Search Space - Select as appropriate
  • Outbound Calls > Calling Search Space - Select as appropriate
  • SIP Information > Destination Address - FQDN of the CMS Server, in this case cms1.assured.io
  • SIP Information > Destination Port - 5061
  • SIP Trunk Security Profile - CMS_SecureTrunk
  • SIP Profile - Standard SIP Profile For TelePresence Conferencing
  • Normalization Script - cisco-telepresence-conductor-interop

Create a CMS API User for CUCM

SSH into the CMS server and enter.

user add cucm api

Create a CUCM Conference Bridge

Log in to Cisco Unified CM Administration, navigate to Media Resources > Conference Bridges. Click Add New

  • Conference Bridge Type - Cisco TelePresence Conductor
  • Conference Bridge Name - CFB_CMS01
  • SIP trunk - CMS01
  • Username - cucm
  • Password - Enter as appropriate
  • Use HTTPS - Checked
  • HTTP Port - 445

Conclusion

At this, point the SIP Trunk should be in Full Service and subsequently the conference bridge be Registered. It is worth noting, in CMS version 2.3 TLS 1.0 is being deprecated and the default minimum TLS version will move to 1.2. The CUCM Conference Bridge API connection uses TLS1.0, and as a result, TLS will fail to negotiate, and the Conference Bridge will never register. To get around this upgrade to CUCM 11.5(1)SU3+.

It’s also worth noting that I’ve experienced a situation where the conference bridge resource will not come up using TCP port 445. To get it registered

  • SSH to CMS and temporarily change webadmin to listen on port 443
  • Modify the CUCM Conference Bridge resource to use port 443 and Reset 
  • One the Registration comes up, revert the webadmin change moving it back to port 445
  • Rever the CUCM Conference Bridge resource to use port 445 and Reset

Update - July 2018

As mentioned above CMS version 2.3+ defaults to TLS 1.2, which is not supported on CUCM versions below 11.5(1)SU3+. Thankfully (for now) we can lower the minimum supported TLS version back to 1.0, where CUCM is not yet upgraded using the below commands:

cms01> tls webadmin min-tls-version 1.0
cms01> webadmin restart

Once the above has been run, perform a reset of the CMS conference bridge from within CUCM. Sample logs where this was implemented on the CMS, where .66 (CUCM) is trying to connect to the CMS before the TLS version was dropped.

Jul 9 08:32:06 user.info cms01 cucm-esc: INFO: Starting CUCM escalation script
Jul 9 08:32:06 user.info cms01 cucm-esc.CallClearingThread: INFO: No conferences, waiting until a new conference joins.
Jul 9 08:32:06 user.info cms01 cucm-esc: INFO: Listening on 127.0.0.1:8081
Jul 9 08:32:08 daemon.info cms01 webbridge-reverse-proxy[1]: 2018/07/08 22:32:08 http: TLS handshake error from 1.1.1.66:34378: tls: client offered an unsupported, maximum protocol version of 301
Jul 9 08:32:13 kern.info cms01 kernel: [ 2269.188329] docker0: port 1(veth1213a13) entered forwarding state
Jul 9 08:32:14 user.info cms01 authp: re-registration from server “cms01.vc.domain.com”
Jul 9 08:32:31 user.info cms01 cucm-esc.CodianToCms: INFO: Handling device.query
Jul 9 08:32:31 user.info cms01 cucm-esc.CmsApi: INFO: GET request to “http://127.0.0.1:8080/api/v1/system/status”, “{}”
Jul 9 08:32:31 user.info cms01 cucm-esc.CmsApi: INFO: Successful Response for GET request to http://127.0.0.1:8080/api/v1/system/status
Jul 9 08:32:31 user.info cms01 cucm-esc.CodianToCms: INFO: Response to device.query: {‘currentTime’:2018-07-08T22:26:37Z}.
Jul 9 08:32:31 user.info cms01 cucm-esc.CodianToCms: INFO: Handling device.query
Jul 9 08:32:31 user.info cms01 cucm-esc.CmsApi: INFO: GET request to “http://127.0.0.1:8080/api/v1/system/status”, “{}”
Jul 9 08:32:31 user.info cms01 cucm-esc.CmsApi: INFO: Successful Response for GET request to http://127.0.0.1:8080/api/v1/system/status
Jul 9 08:32:31 user.info cms01 cucm-esc.CodianToCms: INFO: Response to device.query: {‘currentTime’:2018-07-08T22:26:37Z}.

It is also worth noting that switching the WebAdmin port from 445 (or otherwise) to 443 and back, no longer appears to be necessary.