Home » Archive » Connecting Sonus SBC 1000 to Exchange Online UM

Connecting Sonus SBC 1000 to Exchange Online UM

In my latest venture, I have been tasked with connecting a customer’s Cisco CUCM deployment with Exchange Online UM provided by Office 365. In order to achieve this, and because Office 365 does not support direct SIP trunks between itself and CUCM, we had to deploy a Session Border Controller (SBC) in the middle.

The model chosen was a Sonus SBC 1000 3-DSP SIP:SIP licensable SBC for its ease of configuration and support with Microsoft technologies.

Now, Sonus have provided a relatively high level document on configuring this process, and although the document was designed using software version 2.2, it is still relevant in the latest 4.2.1 release.

I am not going to rewrite the document here, but rather fill in some blanks that it does not actually stipulate. For reference the document in question can be found here: http://www.sonus.net/sites/default/files/sonussbc1k2kconfigo365.pdf

On to the points that are not covered by this document.

Exchange Online / Office 365 Configuration & Requirements

  1. When adding in the Sonus SBC as a UM IP Gateway to Exchange Online, you must use a FQDN, not IP address. The domain element of this FQDN MUST be an accepted domain in Exchange Online and so proven on your Office 365 tenant that you own it.
  2. If you are running Exchange Hybrid to this tenant, when creating the UM Dial Plan you must configure the UM policy on both on premises Exchange and Exchange Online to include the Source Forest Policy Names. This is for migration of UM enabled mailboxes, when they migrate, they migrate and change voice policies accordingly without intervention. The PowerShell command is
    Set-UMMailboxPolicy -identity "Office365VoicePolicy" -SourceForestPolicyNames "OnPremiseVoicePolicy"
  3. It seems that Exchange Online will only trust a certificate that possesses the UM IP Gateway FQDN as the subject name and subject alternative name on the certificate used. Simply adding additional aliases as a subject alternative name does not work. Therefore you are limited to one Office 365 tenant connection per physical SBC. The reason for this is that Sonus SBC 1000 allows only one certificate to be installed for its use.
  4. Another caveat, is that you must purchase a trusted SSL certificate that has been signed by one of the following trusted root certificate authorities:
    DigiCert (http://www.digicert.com/)
    Entrust (http://www.entrust.com/)
    Geotrust (http://www.geotrust.com/)
    GoDaddy (http://www.godaddy.com/)
    GTE CyberTrust from Verizon Security Services (http://www.verizonbusiness.com/Products/security/identity/ssl/)
    RSA Security (http://www.rsa.com/)
    Thawte (http://www.thawte.com/)
    Verisign (http://www.verisign.com/)Any other certificate will not work at all!

Sonus SBC Configuration and Requirements

  1. You must install the Microsoft trusted root certificate to the trusted CA root store on the SBC. This is the Baltimore Cybertrust Root Certificate that can be found on any Microsoft device under the local machine\trusted root stores. Export this and install to the SBC. You can run this PowerShell command to export the required certificate
Get-ChildItem -Path "cert:\currentuser\root\" | where {$_.FriendlyName -like "Baltimore*"} | Export-Certificate -FilePath "C:\baltimore.cer"
  1. You will also require the GTE Cybertrust Root certificate to be installed on the SBC. You can obtain the certificate here: https://www.instantssl.it/pagina.asp?id=127
  2. After installing certificates, you will need to reboot the SBC

CUCM Configuration

To connect the SBC to CUCM is relatively straightforward if you are connecting using TCP. If you are connecting using TLS, then you must also install the CUCM certificates of each CUCM node in the server table to the trusted root CA store. Similarly, on CUCM you will need to install the root and intermediate certificate from your trusted SSL provider that has signed your SBC FQDN. One thing I found needed to be changed on the SBC was the SIP profile assigned to the CUCM trunk. You can follow the same guide as connecting the SBC to Office 365, but under SIP profile ensure that you have FQDN in Contact Header set to Enabled. Without this setting you may experience call drops with CUCM declaring 481 call does not exist. What is happening here is, once the call is setup, CUCM sends SIP UPDATE messages to the SBC’s external interface and gets a TCP reset packet. After trying for 20 seconds, CUCM drops the call. When the SBC requests an UPDATE from CUCM, CUCM responds with no call found because the call has been torn down. Enabling the above setting ensures that the path is picked up from the original SIP messages and the calls flow accordingly.

I have not yet mastered how to get SRTP working between CUCM and the SBC, so that’s my next step. In order to get SRTP working between CUCM and Sonus SBC, ensure your media crypto profile key length is set to 0 when using media bypass.


  1. Nice post! Always good to see UM getting some love. Although considering how out of date the Exchange Telephony Advisor is it would be really useful if MS provided some clarity on their direction with PBX support for UM as from my point of view it definitely appears not to be an area of interest for them anymore, with more focus and emphasis on O365/SfB/Exchange Online (UM) integration.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: