O365 Exchange Online Unified Messaging with Cisco CUBE RTP/SRTP Interoperability - Lessons Learned

KEVIN DELANEY · ‎06-07-2017

I recently had an opportunity to observe and oversee a Microsoft O365/Exchange Online with Unified Messaging integration with a Cisco CUBE router. The CUBE router was being used for Voicemail Interoperability with Microsoft's cloud. In essence, we were creating a hybrid-cloud environment. The goal was to leave the Cisco Unified Communications Manager on prem, but the Voicemail portion would move to O365/Exchange Online as it made sense because the mailboxes were moving to O365. I'm putting this out here to help the community in case anyone ever needs to reproduce this. As we all know cloud and SaaS is here to stay and I'm sure more people will need to leverage this solution to allow their organizations to move to the cloud.

To provide some background, the issue we were facing is that while moving E-Mail, SharePoint and other data services off prem to O365 SaaS is desirable for many organizations, if you have Unified Messaging/Voicemail on prem today (which is obviously tied to an e-mail box) you certainly can't abandon it. A shortlist of options is:

Switch communication platforms altogether to one that has native dial-tone, voicemail and e-mail integration. This option will usually require you to buy all new handsets and brings a new learning curve for your employees.
Decouple your Voicemail and E-Mail Systems and install a Voicemail only system next to your IP PBX (which employees may not be too thrilled about losing the Unified Messaging experience)
Or perform some kind of interoperability (prem to cloud)

In this scenario, the environment was already using Microsoft Exchange Unified Messaging on-prem integrated to Cisco CUCM (Call Manager). So, we chose the latter option.

The CUBE in this environment was to operate as a session border controller. Its job would be to take standard G711 RTP streams from the CUCM; terminate them on one inbound interface and restarts them as SRTP (secure) TLS on the outgoing interface to O365.

This was quite a challenging scenario we went through to get this to work. So, I'd like to help the rest of you reading to avoid the same pitfalls. Let me first say that I didn't do all of the configurations. I stepped in to oversee when things weren't progressing at the pace I was comfortable with, and because I have a technical background from long ago I was able to get the right resources together to make it all work. So, you can look at this post more as guidance on how to accomplish this rather than a configuration walk-through. If you do some searching you will find many posts in the communities forum already covering those configuration walk-through scenarios.

The main configuration document for this solution can be found here: http://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise-networks/unified-access/cube-asr-release-10-0.pdf

Note while this document calls out an ASR1004, we have this working using an ISR 4321 using code:

isr4300-universalk9.03.17.03.S.156-1.S3-std.SPA.bin

There are also other people who have reported the configuration working on the forums with an ISR: 4331, 2851, 2901. The thing to realize about the older 28 & 29 series is that you will need to explicitly configure RTP/SRTP transcoding and you will need PVDMs in the router to do this. The 4300 series routers can do RTP/SRTP directly in CPU natively (although our router had a PVDM-128 module in it). Lastly, I am not saying this is best practice. Cisco has clearly tested the ASR 1004 for its robust processing power. In fact, if you do use an ISR you need to be aware of the calls per second your router can handle in its CPU and size it appropriately for the number of users you have. I believe this is the reason Cisco chose to validate the solution with the ASR. But if you are a smaller organization and can't afford an ASR there are options. Hopefully Cisco will officially validate more models for this solution in the future.

Here is the link for sizing the calls per second: http://www.cisco.com/c/en/us/products/collateral/unified-communications/tdm-gateways/data-sheet-c78-729824.html

Look under "VoIP Performance: (not exceeding 75-percent CPU)" to see the quantity of calls your router can handle per second.

To cut to the chase here are the lessons learned:

Pitfall #1: You can't use NAT on a firewall in this solution. Meaning your CUBE must have an interface with a public IP address on it. You can’t have your CUBE sitting behind the firewall and expect PAT/NAT to do the trick for you, it just won't work. The reason is that when the CUBE translates the RTP to SRTP using TLS encryption the SIP source IP header is encrypted by TLS before it hits the firewall to be NAT'ed. So, the firewall can’t see into and change the IP Address of the source header. The traffic will make it to Microsoft but when Microsoft decrypts the packet it will see your private IP address in the source header and drop the packet because you can't route Private IPs on the Internet.
Pitfall #2: Use a certificate from a provider that is on the supported list: http://help.outlook.com/en-AU/140/gg702672.aspx I can't stress this enough. This was the majority of our problem. We initially used a Comodo certificate. Which is on Microsoft's Unified Communications Certificate Partner list: https://support.microsoft.com/en-us/help/929395/unified-communications-c... However, that’s not the O365 supported list. I believe this link is for prem based systems. As soon as we used a GoDaddy cert and put them in the correct order along with the GoDaddy Root and the Baltimore CyberTrust Root, the solution just started working. I want to thank Steven Thurmbuchler at Cisco TAC in RTP for helping with this. When we were using the Comodo cert the TLS handshake wouldn't even complete. So, call signaling/RTP never made it to the UM Pilot in Microsoft's cloud as Microsoft was sending back a: TCP0: FIN processed message and closing the connection.
Pitfall #3: Installing the certs if you've never done this before. We downloaded the GoDaddy cert but its Root cert was concatenated with its Intermediates and you need to separate them out and install them individually. Knowing which one is which is a challenge. You will need to compare the subject and the issuer. The one that has the same exact contents in both the subject and issuer fields is the Root, again I credit Steven Thurmbuchler from TAC for his patience and diligence in helping us do this. Then if I'm not mistaken and remembering the correct order of procedure you need to:

Concatenate the Intermediate certificate with the CUBE certificate and install it as a trustpoint on the router. The Intermediate goes on top, then the CUBE cert in the concatenation order.
You need to install the GoDaddy root certificate as a trustpoint on the router
Lastly you need to install the Root Certificate that Microsoft uses as a trust point on the router (which was a bit tricky for us to find) but you can find it here: https://www.digicert.com/digicert-root-certificates.htm Use the Baltimore CyberTrust Root.

Pitfall #4: If you are configuring an auto-attendant the dial-peer configuration is not within the main document. The issue you will run into if you configure the dial-peer for the auto-attendant the same as the pilot number is you will not be able to transfer calls. The call transfer will fail in Microsoft's cloud. The reason is Microsoft doesn't support a URI type of SIPS (S being secure). They support: SIP URI, Telephone Ext, or E.164 only. So the dial-peer configuration for the Auto Attendant would look like this:

dial-peer voice 101 voip

description [AUTO_ATTENDANT_INCOMING]

session protocol sipv2

session transport tcp

incoming called-number 1234

voice-class codec 4 offer-all

dtmf-relay rtp-nte

no srtp

no vad

!

dial-peer voice 201 voip

description [AUTO_ATTENDANT_OUTGOING]

destination-pattern 1234

session protocol sipv2

session target dns:xxxxxxxxxxxxxxxxxxxxxxxxxxx.um.outlook.com

session transport tcp tls

voice-class codec 4 offer-all

voice-class sip call-route url

voice-class sip pass-thru headers unsupp

dtmf-relay rtp-nte

srtp

no vad

The command in bold above is nowhere to be found in the main document.

Also you should not configure these 2 commands under the auto-attendant dial-peer as well:

voice-class sip url sips <- this is the main command that causes the issue

voice-class sip profiles 1 <- we've noticed that even if you add the "headers unsupp" and remove the "url sips" cmds it still wont work if this is in there.

Once we did all of this, the published configuration (which we had on the router before I engaged TAC) worked flawlessly. Well.. that’s the long and the short of it. I hope this helps all of you who need to attempt this in the future.

Regards

Kevin Delaney