Configuring Exchange Server 2013 Unified Messaging With 3CX and Not AsteriskNOW

Posted on Posted in 2010, 2013, asterisk, asterisknow, exchange, pbx, unified messaging, voicemail, voip

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.

11 thoughts on “Configuring Exchange Server 2013 Unified Messaging With 3CX and Not AsteriskNOW

  1. I’ve tried setting up the same configuration with 3CX; however, I’m getting an error after the 302 redirect
    “[CM503014]: Call(C:8): No Known route from Extn: 1000 to target: “
    Did you receive anything similar in your setup?

  2. @Jeremy – yes I get the same, but I left the blog post as I suspect a later build of 3CX will work properly with the RTM version of Exchange 2013 (which was not available at the time of writing). 3CX will get the redirect to the IP address and fail with the Exchange 2013 Preview and the version of 3CX available at the time of writing. Once RTM is generally available and I have the time I will refresh my lab and ensure that 3CX works with redirecting from 5060 > 5062 > 5065/5067 as I expect it will do. AsteriskNOW will take much longer to get to this point I suspect, and being Open Source is prone to having the fix removed in a later build (as can be see with some of the additions to make Exchange 2007 work in Asterisk 1.6 are gone by the time AsteriskNOW (v 2.0) was available.

  3. ive had 3cx support in aus looking at this issue for 2 days and they are not very good. he has finaly esc to 3cx head office. .

    do you have a quick fix to make this work as a temp measure ? ive tried using 5062 and no luck

  4. @Anon – though I’ve not tried this and I do not recommend it long term – if you connect to both 5065 and 5067 on a single mailbox server then it should work.

    The reason is that no further redirect occur and the server you connect to will take the call, but all calls now go to one server regardless of mailbox location. Exchange 2013 is designed so that the mailbox server holding your active copy of your mailbox takes your call, and other servers take other calls. The CAS role on port 5060 redirects you to the mailbox on 5062 and 5062 redirects you to whichever port is active on that server at that time (it varies weekly between 5065 and 5067)

  5. I’m facing the same 302 moved temporarily issue here between 3cx and Exchange 2013. Having 3cx connect directly to port 5065 on my Exchange 2013 does resolve it for now. Hopefully there will be a fix from 3cx for this soon. I did try the cumulative update 1 package fir Exchange 2013 by the way but that doesn’t fix this.

  6. Hi Brian,

    Thank you for you blog. That helped me alot to find out the cause of our problem: the 302.
    It was al the time visible in the sip packets from Exchange, but i didn’t know why Ex2013 did this. Your blog was very helpfull! Thanks.

    Still i’ve an issue. I connect from Asterisk (1.6) to Ex2013 (one host = Mailbox and Client Access). Within the extensions file i do a Dial to 5065 and 5067. The tcpdump trace reports that Exchange accepts the call (i hear nothing at that time) and i see two RTP packets exchanging betweeen Exchange and Asterisk and RTCP reports from Exchange, but that’s it. No audio streams.

    Any idea how to debug this? Did a debug from Asterisk, but that give me no extra information.

    Best regards,

Leave a Reply

Your email address will not be published. Required fields are marked *