Acme Packet SBC for Office 365 UM with CUCM

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
• AudioCodes
• Ingate
• Sonus (NET is included but was purchased by Sonus in 2012)

Acme Packet

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.

Overview

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.

VMWare Configuration

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

SDES Profile

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.’

Taken from http://community.office365.com/en-us/forums/158/p/52560/185459.aspx?ss=a5d3b01e-58c7-420a-8b16-3969f488dd0d#185459

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.

CLI Configuration

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                  web@
        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                  web@
        last-modified-date                2013-11-01 11:46:39