This article is an addendum to my blog series on configuring Exchange Server 2010 and Exchange Server 2013 with AsteriskNOW. AsteriskNOW is a easy to install version of Asterisk 1.8 in that it includes the underlying OS and the FreePBX software. The problem with Asterisk 1.8 is that it does not work well with the correct process of connecting to Exchange Server unified messaging servers.
Asterisk and Issues with Exchange Server and SIP Diversion
Exchange Server runs two unified messaging services, umservice.exe (on Exchange 2010 and Exchange Server 2013 Mailbox Servers) or Microsoft.Exchange.UM.CallRouter.exe (on Exchange Server 2013 Client Access Servers) that listens on TCP 5060 and UMWorkerProcess.exe (both versions of Exchange Server) that listens on TCP 5065 or TCP 5067. The correct process for connecting to Exchange Server unified messaging is to connect to TCP port 5060 and get back a SIP Redirect to either port TCP 5065 or TCP 5067. The reason for the redirect is that Exchange Server starts listening on 5065 and after a week starts a second process listening on 5067 and once the process on 5065 has finished all its call handling it will stop the process listening on 5065. This way Exchange Server manages the process, memory management, etc. without needing to restart the process if it goes bad – it just starts a process on the other port from the current process and directs all new calls at the new process.
The problem with Asterisk 1.8 is that is looses the caller ID during this redirect. Therefore all the posts you will see on the internet for Exchange and Asterisk use port 5065 directly and a few (very few) deal with the issue that this only works for a week before they need to change to port 5067 and so on.
On Exchange Server 2010, as both the umservice and the UMWorkerProcess are on the same machine, you can just connect to 5065&5067 at the same time and Asterisk will complete the call down the channel that answers.
Like Exchange Server 2010, the 2013 version allows you to direct voicemails at any unified messaging server and have them turn up in your inbox. You do not need to connect to that actual server your mailbox is located on – but ideally you would, as that will spread any load caused by voice across all the servers that store mailboxes. If you are connecting to a server in one location, your mailbox could be in another and so ideally you would connect to a mailbox server local to your mailbox, but as Asterisk does not manage the diversion correctly this will not happen.
On of the headline features of Exchange Server 2013 is the load-balancing without needing layer 7 hardware. This not going to work for Exchange Server 2013 and Asterisk as you will always get sent to the IP address of the trunk as configured in Asterisk and not the server your mailbox is located on.
The connectivity flow for Exchange UM is that the CAS role runs the Microsoft.Exchange.UM.CallRouter.exe process (port 5060) and the Mailbox role runs the umservice.exe (port 5062) and the UMWorkerProcess.exe (port 5065 or 5067)*. Therefore your PBX needs to talk to a CAS server on port 5060 (and can do this via a Layer 4 load balancer if they wish) and then the SIP call is redirected to the correct mailbox server for that user at that time. The following screenshot shows the error state in action:
From the above Asterisk console session you can see the following steps caused when the user at extension 8001 picks up the phone and calls the subscriber access number for the dialplan (8500):
- Called SIP/TrunkName/8500
- Got SIP response 302 “Moved Temporarily” back from CAS_Server_IP:5060
- Now forwarding SIP/Call-ID to ‘SIP/8500::::TCP@mailboxserver_fqdn:5062’ (thanks to SIP/TrunkName-CallID)
The connection has been routed from the CAS server to the Mailbox server that holds the users mailbox and to the umservice.exe on that mailbox server. It is this service that knows the current port the UMWorkerProcess is running on on (5065 or 5067). So the connection flow continues with:
- Got SIP response 302 “Moved Temporarily” back from mailbox_server_IP:5062
- Now forwarding SIP/Call-ID to ‘SIP/8500::::TCP@mailboxserver_fqdn:5065’ (thanks to SIP/mailbox_server_fqdn:5062-CallID)
- SIP/mailbox_server_fqdn:5065-CallID is ringing
- SIP/mailbox_server_fqdn:5065-CallID answered SIP/8001-CallID
Exchange then answers with “Sorry, the person you are trying to reach does not have a valid voice mailbox on our system. Goodbye”. This is because in all the diversions (SIP 302) Asterisk looses the From: header which shows which phone the user is calling from and replaces it with the subscriber access number. Configure Asterisk to connect directly to 5065&5067 on a mailbox server and it all works fine, but latency for offsite mailboxes is not catered for, nor is any degree of HA.
So, as Asterisk has issues doing an Exchange Server 2013 multi server deployment that it could do with Exchange 2010, I have added this article to the blog series to explain why this is so and the steps for another IP PBX to solve the issue. Therefore we will look at configuring 3CX instead as an example IPPBX. 3CX with Exchange Server support is a paid for product, but at the time of writing you get a 2 call demo licence when you register to get a download – and a two concurrent call licence is enough for a lab.
Configuring 3CX for Exchange Server 2013
As the process for installation of 3CX is well documented, all I am going to do here is call out the steps that you need to do to get the system working with Exchange Server.
- Download the free version
- You will get an email with a licence key for 2 concurrent calls
- Install the free version on a Windows Server, but not on any of the Exchange Server 2013 machines as both Exchange and 3CX will want to open port 5060.
- During installation I choose to go for IIS as the web server.
- Create two extensions during installation. I went for 5001 and 5002, one for each of my SIP phones. Note that if you configure your phones at the same time as you create the extensions they will not register with the server until after installation is complete.
- Ensure that you enable voicemail for the extension.
- Activate the software with the demo licence key you have (Settings > Activate Licence)
- Configure your VoIP Provider settings including an Outbound Rule for sending calls to this provider.
- Configure Exchange dialplan and UM gateway and UM enable mailboxes with the same extension number as used in 3CX
- On Settings > Advanced choose the Exchange Server tab and enter the IP address of your Exchange CAS Server or CAS server load-balanced virtual IP. Set the port to 5060 and tick the box to use voicemail on your Exchange Server
You should now be able to place calls between your handsets and have the call forwarded to Exchange for voicemail.
* Note that if you are using TLS protected SIP (SIP Secure) then the port numbers in the above article are incorrect and are all +1. Therefore Microsoft.Exchange.UM.CallRouter.exe listens on 5061, umservice.exe on 5063 and UMWorkerProcess.exe listens on 5066 or 5068.
Leave a Reply