Enjoy!
Two basic concepts need to be considered with the CUBE line-side feature. Access side and core side. We will continue those two concepts when we move to the follow-up posts on dial peers and SIP/RTP modifications.
Access side (aka line-side) is your connection between CUBE and the IP Phone. If your phones are already secured by another method then you could support the access side via SIP and RTP. If you’re bringing phones in from the Internet obviously you’ll want SIPS and SRTP. If you’ve ever used Wireshark to capture an RTP session it is extremely easy to listen to that voice call if the media is sent in the clear. In short – you want secure access side.
The core side is your connection between CUBE and Communications Manager. If based on your network architecture you have CUBE behind an external Internet facing firewall you may want to have a non-secure core side. Meaning SIP/RTP is sent in the clear back to CUCM and other devices internal to the network. If you have a mixed-mode cluster obviously you already have secure core and will require the “access-secure” within the phone proxy configuration.
Do you have a mixed mode cluster or a non-secure cluster? You need all of the certificates on CUBE regardless and I’ll go ahead to give some more information for LSC certificates and non-secure clusters. If you have a mixed mode cluster you’ll need to import the MIC Cisco_Manufacturing_CA, CAP-RTP-001 and CAP-RTP-002. The reason is you want valid trust points across the CUBE. If you have used USB keys or a signed CA you’ll obviously need to add those certificates to CUBE. The MIC certificates do not need to be in the CTL file. I may point this out several times but if you are doing secure core side back to CUCM you need to import the CUBE selfsigned certificate into CUCM nodes to support the SIPS/SRTP negotiation!
Similar to the ASA phone proxy in order for Cisco IP phones to download the LSC certificates, the Cisco CUBE permits the CAPF TLS connection. It does not proxy the CAPF connection. The Cisco CUBE requires the CAPF CA certificate, contained in the CTL file, for the Cisco IP phone to establish a TLS connection with the CAPF process running on the CUCM node. Once completed, Cisco IP phones can download the LSC over the CAPF TLS connection. To clarify, the USB tokens or CA certs in the CTL are not necessary because the Cisco CUBE is serving the CTL file and inserts the CAPF CA certificate, which the Cisco IP phone trusts, to establish the CAPF TLS connection. This is part of the phone proxy configuration when you do a service map for port 3804 the CAPF service on CUCM.
The phone can then dynamically update the LSC certificate from CUCM CAPF service and CUBE access line-side feature must import the CUCM CAPF certificate into the CTL to support this function.
So there are 2 purposes here to import the CAPF certificate from CUCM
#1 The phone must have this certificate in the CTL file to pass the authenticate during an LSC update
#2 CUBE would use this certificate to authenticate phone during the TLS connection.
To state the obvious for clarity – Regardless if you have a mixed-mode or non-secure cluster you obviously need to import the CAPF.pem to CUBE line-side from every CUCM node! IF you have a mixed-mode (secure) cluster you also need to import the CUBE self-signed certificate into CUCM to support the core side SIPS/SRTP negotiation. The CUBE self-signed must be imported to CUCM first. Multiple SAN certificate for the phone must be configured based on the phones security profile in CUCM. You have probably already dealt with this if you are running a mixed-mode cluster and performing SRTP with another CUBE possibly for PSTN access.
((I really want to call this out – More and more you’re going to be working with certificates across all of the Cisco Collaboration products. Do yourself a favor and have your Microsoft team spin up a Windows Server 2012 running SCEP/NDES. This way you can automatically enroll devices with a trusted CA and stop having to import/export trusted CA certificates everywhere. I’ve covered this in some older posts but it’s time to have a trusted CA across your internal corporate network.))
There is another interesting detail for CUBE on your ISR 29xx or 39xx series router. To do RTP to SRTP interworking you need DSP resources. Shocked? Don’t be. I’m getting to that configuration right now because this is super important when you pick a router for CUBE line-side. The most basic way to check if you’re already configured is via “show call active voice brief” and look for “SRTP: on” or “SRTP: off”. If you can make calls and you have NOT set up a SCCP based DSP transcoder your calls are in the clear! SRTP is controlled by your dial-peer and the “srtp” command. Setting “srtp fallback” will allow RTP media if the TLS/SRTP connection cannot be established.
Using DSP calculator I came up with this assuming G711 between IP Phone and everything else:
0-16 Sessions = PVDM3-16; 17-24 sessions = PVDM3-32; 25-48 sessions = PVDM3-64; 49-96 sessions = PVDM3-128; 97-144 sessions = PVDM3-192; 145-192 sessions = PVDM3-256. Some model routers obviously support more than one PVDM3. Use the Cisco DSP calculator for the best answer.
If you assume high complexity G729 a PVDM3-256 can only support 60 sessions!
SRTP-RTP internetworking is available with normal and universal transcoders. The transcoder on the CUBE is invoked using SCCP messaging between the SCCP server and the SCCP client. The SCCP messages carry the SRTP keys to the digital signal processor (DSP) farm at the SCCP client. The transcoder can be within the same router or can be located in a separate router. TLS should be disabled only when the transcoder is located in the same router. To disable TLS, configure the no form of the tls command in dsp farm profile configuration mode. Disabling TLS improves CPU performance since you are not needing to exchange keys within the same router. If bouncing the call off an external DSP farm you’ll need to keep TLS in the mix to ensure end-to-end secure connections.
REALLY IMPORTANT – Most companies have multiple CUCM servers for redundancy. If you want CUBE to have a redundant core side configuration you must also import the Callmanager.pem and CAPF.pem certificates from all nodes the CUBE will connect to. This is really where CUCM 10.5 can help out with multi-node multi-SAN certificates but you DON’T WANT TO USE 10.5 MULTI-SAN certificates for Callmanager.pem. I believe I was the first to find and create the SEV2 bug CSCup28852 and your phones will continually reboot due to CUCM sending group restarts to ALL phones. First fixed in 10.5(1.98000.77) but that release isn’t available yet for download.
GOT IT? GOOD!
Foggy Bytes 