Unified Messaging Architecture in Exchange Server 2013
Changes have had a ripple effect in Lync Server 2013's voicemail routing process
May 21, 2014
The landscape has changed with the integration of Microsoft Lync Server 2013 and Microsoft Exchange Server 2013. Gone are the days when you could point Lync to a specific Unified Messaging server, Public Switched Telephone Network (PSTN) gateway, or PBX and say "answer all calls that are directed to voicemail." With each new version of Exchange, the Unified Messaging architecture has evolved. The changes in the Unified Messaging architecture in Exchange 2013 have had a ripple effect in the voicemail routing process in Lync 2013.
The topic of Unified Messaging in Exchange 2013 is a daunting one. So, for the sake of brevity, I'll focus on the following areas in this topic:
Exchange 2013 Unified Messaging architecture
Lync 2013 and Exchange 2013 call flow
Exchange 2013 Unified Messaging Architecture
Exchange 2013 changed the way it handles Unified Messaging services compared to previous versions. The days of having the five separate server roles of Client Access, Hub Transport, Unified Messaging, Mailbox, and Edge Transport are gone. In Exchange 2013, Microsoft has slimmed down the number of server roles from five to two: Client Access server and Mailbox server.
The key thing to keep in mind is that the functions essential to Exchange 2013 Unified Messaging are still in place—they're just installed on different servers. The essential functions for Unified Messaging are the:
Microsoft Exchange Unified Messaging Call Router service
Microsoft Exchange Unified Messaging service
Microsoft Exchange Unified Messaging Worker Process
The Client Access server runs the Unified Messaging Call Router service. It's responsible for accepting the initiating Session Initiation Protocol (SIP) traffic from the Lync server when a voicemail message is left destined for the Unified Messaging service.
The Mailbox server runs the Unified Messaging service and the Unified Messaging Worker Process. The Mailbox server is responsible for accepting media traffic—that is, Real-Time Protocol (RTP) and Secure Real-Time Transport Protocol (SRTP) traffic—from a VoIP gateway, Session Border Controller (SBC), or PBX.
Because the Exchange 2013 Client Access server isn't capable of receiving media traffic from a VoIP gateway, SBC, PBX, or even a Lync server (a Mediation server can be collocated on the Front End server), the Client Access server redirects all media traffic to the end user's Mailbox server. The Mailbox server will then receive traffic directly from the VoIP gateway, SBC, PBX, or Lync server.
Lync 2013 and Exchange 2013 Call Flow
The Lync 2013 and Exchange 2013 call flow is unique in that calls to the Unified Messaging service now travel through the Exchange Client Access server. There are four steps:
The call is routed inbound through the PSTN to the Lync Mediation server, then to the Lync Front End server.
The inbound call travels to the Lync Front End server (the Mediation server is collocated on the Front End server) and makes its way through the Lync Front End call routing process, which is referred to as the inbound routing logic, and rings the Lync client.
If the Lync end user doesn't answer the call after a certain number of rings, the voicemail routing logic on the Lync Front End server will determine whether the Lync user has a Unified Messaging mailbox. If so, Lync will route the call to the Client Access server. Note that the process of Lync routing an unanswered call to voicemail is equivalent to a Ring-No-Answer or Cover path in some telephony PBXs.
When the Client Access server receives the SIP invite from the Lync Front End server, the Unified Messaging Call Router service redirects the incoming call to the Exchange Mailbox server. The traffic that's sent to the user's Mailbox server is media (RTP and SRTP) traffic.
Figure 1 illustrates this call flow.
Figure 1: Lync 2013 and Exchange 2013 Call Flow
Change in Routing Keeps Things Fresh
When some people encounter change, they cringe because they feel the previous process was never broken in the first place. The change in the voicemail routing process might initially bring about the same feeling in those administrators who believe that the process wasn't broken. However, bringing about change doesn't necessarily mean something is broken. In some cases, change makes things more optimal. I for one feel that the change in the voicemail routing process is intriguing. The process wasn't broken. Rather, the change was needed due to a ripple effect. Because the number of server roles was reduced in Exchange 2013, the way Lync routes calls to voicemail when Lync and Exchange are integrated had to also change. As best-selling author Paul Hawken stated, "All is connected . . . No one thing can change by itself."
About the Author
You May Also Like