Office 365 Exchange Online can provide Unified Messaging (UM) functionality such as voicemail for on-premises telephony systems. Configuring integration between Exchange Online UM and Lync is a straightforward process assuming you already have Enterprise Voice and a Lync Edge server in place. There is TechNet documentation for Lync 2013 and Lync 2010 or an older Office 365 Checklist.
Things get a lot more complicated when you want to use a different telephony system, for example Cisco Unified Communications Manager (CUCM). Exchange Online does not support direct connection from an IP-PBX, it requires an SBC (Session Border Controller) to provide interoperability between the on-premises solution and Office 365. The SBC typically has two SIP interfaces – one at the network edge and one connected to the telephony part of the network. The SBC acts as a gateway and firewall for SIP traffic and can also provide translation between different protocols and encryption levels.
The Microsoft supported Session Border Controllers for Office 365 are listed at Configuration Notes for Supported Session Border Controllers. This list contains 4 vendors:
- Acme Packet
- Sonus (NET is included but was purchased by Sonus in 2012)
For a customer doing an Exchange 2010 to Office 365 migration recently I had to use the Acme Packet Net-Net Enterprise Session Director Virtual Machine Edition Enterprise SBC. Acme Packet were purchased by Oracle earlier this year and the Acme Packet site with all the information is redirecting to Oracle. This SBC now falls under the Oracle Enterprise Session Border Controller brand although most of the documentation seems to have disappeared. The Net-Net ESD VME is a virtual appliance that runs on VMWare or Hyper-V and is essentially a scaled down version of the Net-Net 3820 on the Microsoft support list.
Acme have a configuration guide that is linked to from the Microsoft SBC page, however this is not available any more due to the Oracle redirect. The guide ‘Acme_Packet_Net-Net_SBC_Config_Note_for_Office_365_Exchange_UM.pdf’ was updated in 2012 and I’m sure it is floating about on a Google cached search. However this is not one of the better guides I have ever come across. It is filled conflicting examples and configuration snippets that do not match the rest of the configuration.
Which brings me to the purpose of this blog. There are two very important things to know if you want Office 365 UM to work with the Acme Packet SBC in general and two specific to the Virtual Machine version. Two are not in the guide at all, one is set in one part of the configuration but not another and the fourth is a software update.
As a high level overview, we were using CUCM 7 with connectivity over unencrypted SIP and RTP to the SBC. The Office 365 side requires SIP TLS and SRTP to ensure signalling and media are both securely encrypted over the public Internet. This means a public certificate matching the SBC hostname (case sensitive apparently) is required from one of the providers on this list Get a Certificate for Exchange UM Online
TLS Negotiation to Office 365
The first issue I faced was general TLS negotiation. The Virtual SBC came with version ‘ACME Net-Net OSVM Firmware ECZ6.4.0’ and required an upgrade to Maintenance Release 1 ‘ACME Net-Net OSVM Firmware ECZ6.4.0 MR-1 GA (Build 267)’. We subsequently moved to Maintenance Release 2 ‘MR-2 GA (Build 322)’ to get away from the USB key license requirement.
Another issue we faced using Acme Packet High Availability is related specifically to VMWare. HA for the Acme Packet is performed using its own cluster synchronisation between two VMs. A virtual MAC address is specified for each SIP Interface and the active owner of the cluster takes over the virtual MAC address. However VMWare in a locked down environment does not allow virtual MAC addresses. We had to enable two settings on the Distributed Port Group on the Distributed vSwitch under the ‘Security’ tab to make this work:
- ‘MAC Address Changes’ to Accept
- ‘Forged Transmits’ to Accept
The third issue was that the SDES profile did not have SRTP auth enabled. I later found it was mentioned in one part of the configuration guide but not the part I was looking at. This is an example of a working configuration.
Without SRTP auth set the SBC was sending an SDP candidate like this:
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:0IYvn6An/4ghZuEH3WqmRoCGB3an5wJ1s5oqQwcA UNAUTHENTICATED_SRTP
and Office 365 was responding with:
SIP/2.0 488 Not Acceptable Here
A successful call’s SDP crypto setting looks like this:
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:4YYdCjqva/4KYV7BhJl1rHhxu5HA0t79QUgM4V3N
TLS and SSL Negotiation From Office 365
This one was frustrating. Once we got calls going to Office 365 I could leave a voicemail and retrieve voicemail from my phone, but if I tried to call the voicemail pilot number from any other phone I would just get dead air after entering the extension number. The cause of this was the TLS profile. By default it is set to ‘tlsv1’. When entering the extension number, the Office 365 SBC was trying to send a re-invite and initiate a connection to the SBC. The Office 365 SBC begins by trying to connect with an SSLv2 Client Hello as you can see in this Wireshark trace
The SBC was not even responding to this connection request because of the TLS profile setting. The fix was to drop this down to ‘compatibility’ mode as can be seen below.
Without this setting MWI notifications to turn on the red light when a voicemail is received would not work along with many broken call scenarios such as Play on Phone and UM Call Answering Rules. This is not even mentioned in the Acme Packet guide which is disappointing. I have no idea why Microsoft initiates connectivity using SSLv2 either. They require devices connecting to them to use TLSv1. The only reference I could find to this requirement was a forum post comment which pointed me in the right direction:
‘When Exchange Online SBC acts as UAC, it will always send out SSLv2 client hello message for the TLS connection. Normally, if the UAS does not support SSLv2, it will respond with higher version and negotiate from that point. Unfortunately, some of the UAS implementations are really strict about the SSL version. They will simply close the connection, and are not trying the “negotiate” at all.
So your outgoing TLS version, TLSv1, is okay, but I highly recommend that your incoming TLS version should be configured as ‘any’ protocol for accepting Client Hello.’
We got everything working in the end, but I think a configuration requirement like this should be in all of the official Microsoft SBC guides and checklists as it is not Acme Packet SBC specific.
For reference, the CLI settings for the SDES profile and TLS profile are below.
sdes-profile name sdes1 crypto-list AES_CM_128_HMAC_SHA1_80 srtp-auth enabled srtp-encrypt enabled srtcp-encrypt enabled mki disabled egress-offer-format simultaneous-best-effort use-ingress-session-params srtp-encrypt options key salt last-modified-by [email protected] last-modified-date 2013-10-30 11:19:01 tls-profile name ToOffice365 end-entity-certificate External-Digicert trusted-ca-certificates BaltimoreCybertrustCA DigicertHighAssuranceCA3Int DigicertHighAssuranceEVRoot GTECyberTrust cipher-list ALL verify-depth 10 mutual-authenticate enabled tls-version compatibility options cert-status-check disabled cert-status-profile-list ignore-dead-responder disabled last-modified-by [email protected] last-modified-date 2013-11-01 11:46:39