cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10244
Views
30
Helpful
38
Replies

Cisco Meeting Server as Adhoc conference for CUCM

silverfank
Level 1
Level 1

I tried to register cms as conference bridge to CUCM but it doesn't register. my security sip trunk to CMS is up which i can see ping interval time.
I got this message from document

"1. Set up an incoming dial plan on the Meeting Server see the Cisco Meeting Server
Deployment Guide. For adhoc calls the rule should match against spaces."

Is it needed to configure dial plan on CMS? if so how to configure it?

38 Replies 38

You might have to export the certificates a different way or convert them to the right format, Google is your friend here.

Thanks

The information about the certificate requirements for CUCM conference bridge shared in this post are not entirely accurate.  CUCM needs to trust the certificate that is being used for the Web Admin, not call bridge.  If your CUCM and CMS are both signed by the same CA, and CUCM trusts the issuer, then the communicates will progress past any cert related issues.  If CUCM does not trust the CA that signed your webadmin certificate, then upload the Root CA cert chain or the web admin certificate to the CUCM CallManager-Trust store only.  You DO NOT need to upload anything to the Tomcat-Trust.

 

 

Hi!

Is it absolutely necessary to have a secure trunk between CUCM and CMS for ad hoc conferencing to work?
It is not necessary to have a secure SIP Trunk.
Is it possible to use a non-secure SIP trunk and still have ad hoc conferencing work?
Yes
Is this the key to making a non-secure trunk work for non-secure SIP trunks to CMS from CUCM (see quote below)?...so, just be sure to upload those certs from CMS to the CUCM and it will work with a non-secure SIP trunk between CUCM and CMS? I ask because it would make my life so much easier if I cna use a non-secure SIP trunk between CUCM/CMS.
Yes that’s the key, but let me explain. There’s no need to use a secure SIP trunk between CMS and CM. However, you still need an HTTPS secure connection between CM and CMS to communicate to allow CM to use Conferencing resources. As that communication is secured, then you need to generate an appropriate certificate for CMS, an upload to CM the CA root certificate that signed CMS cert in order to make CM trust the cert. There are several certificates that you might generate for CMS depending on what you will use. You should check de CMS deploy guide, there is an special guide dedicated to certificates.
Regards,
Martin



Ok, thank you.  Regarding the certs we need for CMS, we have a working example in another region but they already have server certificates issues for the CUCM servers and so on because they integrate with LDAP, but the CUCM cluster I manage never integrated with LDAP so we only use the default certificates on CUCM.  My hope is that I can keep it as simple as possible by not needing to get a server certificate issued for each CUCM server, etc.  So that's my interest in using a non-secure SIP trunk to CMS.

Anyway, I have one followup question for you.  Are you saying I only need to upload the root CA root certificate that also was responsible for signing the CMS server certificate?  If so, I have that and I assume you're saying on CUCM when I upload that root CA certificate, for the 'certificate purpose' I would select CallManager-trust?... and I don't need the whole chain, just the root CA certificate that has a file extension of .cer?  If I expand the p7b file which is the chain I downloaded, I see an issuing CA cer file type and a root CA cer file type.

You don't need a new CUCM server certificate, but you do need to trust any intermediate/chain certificates *if* that's what the organisation uses (some CA's issue certs directly from root, some use an intermediate CA). Upload the root and any intermidiate CA certificates to both "Callmanager-trust" and "Tomcat-trust" on each CUCM server, then restart Callmanager and Tomcat services (noting that phones will re-register when you restart the service).

Ok, thanks again.  I'll be sure to talk to the person in our group that knows much more about the certificates we use to be sure I upload the correct certs.

silverfank
Level 1
Level 1

Whoooo i got the answer. It need to configure FQDN on trunk pointing to CMS, CUCM and CMS need to trust each other's certificate. The certificate's CN of CMS should be the same as FQDN.

Forgot to mention that in both certificates (for CMS and CUCM) the fields "SSL Client" and "SSL Server" were set to "Yes", as prescribed by the docs.

So, the certificates seem to be fine.

System -> Security -> SIP Trunk Security Profile 

Have you enter CMS' CN certificate in X.509 Subject Name?

Yes, see the screenshot.

Docs tell us to indicate CN of the CMS ("X.509 Subject Name = enter the CN of the Call Bridge certificate."), so in this case I have cms.test.lab

Then I chose this profile while creating the secure SIP trunk that I used in the CFB configuration.

Well, the reason turned out to be very trivial - I issued a certificate for webadmin with CN=test.lab rather than cms.test.lab. I focused on callbridge certificates which were issued with correct CN and forgot to check out certs for webadmin.

Hello silverfank, thanks a lot for your info, but was the trunk up before you fixed certificates? I have set the secure trunk up, it seems to be fine:

Time In Full Service: 0 day 0 hour 7 minutes

I provided FQDN (cms.test.lab) rather than IP address for CMS in the trunk settings. Also I uploaded both CUCM and root CA certificates to the CUCM. I issued the certificate for CMS with CN=cms.test.lab and applied it to Callbridge in the CMS.

So, the trunk seems to be operational, but the conference bridge still not registering. How did you fix this problem, if did?

Hello Tieken,

If the SIP Trunk is up but the Conference Bridge is yet not registered, most likely it's because CUCM doesn't trust the WebAdmin of the CMS.

What did you put in the field HTTP Interface Info ? Was it the IP address or the FQDN of CMS ?

CUCM needs to trust CMS Web Server so it needs to contact it with its correct Subject Name.

In our case, since we didn't want to use DNS for CUCM (so putting the FQDN in the HTTP Interface Info is not an option), we tweaked again the certificate and put the IP address of CMS as Subject Alternative Name. After that, the CUCM trusts WebAdmin only with its IP address.

Here's our final working certificate.

In fact, you can notice that it's still a certificate issue by doing a packet capture on CMS with the command "pcap a" and open it with Wireshark, you would notice a SSL handshake error in the beginning of the trace.

Hello Mohamed, thanks a lot for your feedback, the problem was incorrect CN for webadmin cert, indeed. See my answer above in the thread.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: