Skip navigation
Lync Server 2013
<p>Lync Server 2013</p>

What Happens When Exchange Server and Lync Server Aren't Integrated

Understanding the call flow when there's unified messaging with no Lync integration

In "Unified Messaging Architecture in Exchange Server 2013," I discussed the integration between Microsoft Lync Server 2013 and Microsoft Exchange Server 2013. Now I want to talk about what happens when you have both Exchange 2013 and Lync Server 2013, but they aren't integrated. I'll also show you the call flow when there's unified messaging with no Lync integration.

Before I begin, though, it's important to mention that this discussion is only relevant to Exchange 2013 because Microsoft made an important architectural change regarding the Unified Messaging role in that version. In Exchange Server 2010 and Exchange Server 2007, there's a separate Exchange Unified Messaging server role. In Exchange 2013, the Unified Messaging service doesn't exist as a separate role. Instead, it's split between the Client Access and Mailbox server roles. I've been spreading the word to anyone who will listen about how this architectural change will impact an existing telephony and messaging infrastructure that's running Exchange 2010 or Exchange 2007.

The Case for Not Integrating Exchange 2013 and Lync Server 2013

One of the first questions that might come to mind is, "Why wouldn't someone have Exchange and Lync integrated with each other?" I ask that question when I review an organization's deployment and see that it has both Lync and Exchange, but they're not associated with one another. The fact remains that, before Lync was deployed in lots of environments, some organizations had Exchange Unified Messaging already in place and working fine as their existing voicemail platform. In these organizations, Enterprise Voice hasn't been rolled out yet, which means that users can only use Lync to make PC-to-PC calls. However, routing all calls through Lync to leverage its voicemail capability isn't a strong enough reason for these organizations to integrate Exchange and Lync. They would rather save that implementation step for when they deploy Enterprise Voice.

Unified Messaging with No Lync Integration

The Exchange 2013 call flow is unique in that calls directed to the Unified Messaging service now travel through the Client Access server to the user's Mailbox server. Figure 1 shows a scenario in which a call comes into an organization to a user who is setup with an Exchange voicemail box. Lync is deployed in the organization, but it isn't integrated with Exchange from a voicemail point of view. The Direct Inward Dialing (DID) service resides on the user's existing handset and not on the Lync client.

Figure 1: Call Flow When Exchange 2013 and Lync Server 2013 Aren't Integrated
Figure 1: Call Flow When Exchange 2013 and Lync Server 2013 Aren't Integrated

Here are the six steps in the call flow for this scenario:

  1. The external call traveling inbound to the organization is routed through the Public Switched Telephone Network (PSTN) to the PBX that's in place. In the event that a direct Session Initiation Protocol (SIP) connection isn't supported to the PBX's next hop (which is the Client Access server), a PSTN gateway (e.g., a Dialogic or AudioCodes gateway) would be required to transmit the media signal. Because the DID service resides on the PBX and not the Lync client, the user's phone extension is on the PBX. Therefore, the PBX performs a lookup and finds the correct extension to ring.
  2. The PBX notifies the user's extension about the incoming call, then the user's handset rings.
  3. If the user isn't available to receive the call, the PBX's Ring-No-Answer feature specifies what to do or where to go. In this situation, the PBX will route a Ring-No-Answer response to the pilot number that has been created in the Exchange environment—specifically in the Exchange dial plan located in the hunt group that was created. (A hunt group is a group of extensions organized to process specific calls.)
  4. The PBX sends an SIP invite to the Client Access server in order to establish a media session later between the PBX and the Mailbox server.
  5. The Microsoft Exchange Unified Messaging Call Router service performs a redirect to the end user's targeted Mailbox server because the Client Access server isn't responsible for the media. The Client Access server is only responsible for the SIP signaling when voicemails are left. The PBX, gateway device, or Session Border Controller (SBC) establishes a media connection to the Mailbox server through either a Real-Time Protocol (RTP) or Secure Real-Time Transport Protocol (SRTP) session.
  6. Upon retrieval of the media connection from the Exchange Client Access server, the Unified Messaging service on the Mailbox server allows the caller to leave a message by providing that user's mailbox greeting. After the caller leaves a voicemail message for the user, it's sent to the user's inbox by means of the Hub Transport process.

Change in Voicemail Routing for the Better

With the new Exchange 2013 server role architecture, voicemail infrastructure changes are inevitable. Although administrators might be apprehensive at first, I think it'll be a moot point going forward because they'll see that the simplification of the server roles in Exchange 2013 is a good change, especially for organizations with telephony deployments. The decision about which Exchange role to point to when integrating with telephony equipment for Exchange Unified Messaging is now an easy one, as there are only two options: the Client Access server and the Mailbox server. Because there isn't an Exchange Unified Messaging role anymore, all traffic needs to point to the Client Access server, which is responsible for sending media traffic to the Exchange Mailbox server.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.