The Mediation Server role sits under the radar in most organizations running Microsoft Lync Server 2013, but it could be considered one of the most important of the Lync server roles. Administrators tend to focus on the Front End Server, Back End Server, Monitoring Server, or Persistent Chat Server roles, as they are all important in their own right. However, a Mediation Server is required in Lync deployments that take advantage of such features as dial-in conferencing and Enterprise Voice.
The Mediation Server role was introduced in Microsoft Office Communications Server (OCS) 2007. It has pretty much stayed the same since then, except for few enhancements. Let’s take a look at two key areas surrounding the Mediation Server role in Lync Server 2013:
- Mediation Server architecture
- Mediation Server topologies
Mediation Server Architecture
The Mediation Server is considered the last point of contact for the Lync environment before communicating to the telephony world for audio communication, whether its ingress or egress VoIP calls to the Public Switched Telephone Network (PSTN) world. The Mediation Server is required for leveraging for inbound calls, outbound calls, and dial-in conferencing in a Lync 2013 environment.
The Mediation Server listens for calls from both the server and the gateway. To listen for calls from the server, it uses Session Initiation Protocol (SIP) listening ports. Typically, port 5070 is used for Transport Layer Security (TLS) traffic coming from the Lync server. To listen for calls from the gateway, it uses port 5067 for IP and PSTN traffic.
The Mediation Server is considered a Back-to-Back User Agent (B2BUA), which is responsible for handling communication between two endpoints in a SIP call. All SIP signaling will traverse through the Front End Server and Mediation Server when in route to a PSTN gateway. Only when media bypass is enabled will calls bypass the Mediation Server, which means that the calls go from the Lync 2013 client straight to the PSTN gateway. When there's a PSTN gateway device local to where the call is being made, organizations will typically enable the Lync environment for media bypass to avoid having the media traverse the WAN to make a call. This improves call quality because it reduces the chance for latency, jitter, and packet loss, which naturally occurs when a VoIP call travels through multiple hop points before the call reaches the endpoint receiving the call.
Some of the Mediation Server's key functions include:
- Encrypting and decrypting Secure Real-Time Transport Protocol (SRTP) data on the Lync server side
- Translating SIP over TCP to SIP over mutual TLS (MTLS)
- Translating media streams between the Lync server and the gateway peer of the Mediation Server
The Mediation Server's gateway listening capabilities allow the Lync environment to connect to a Session Border Controller (SBC), PBX, IP-PBX, or PSTN gateway. When a Lync client is communicating with the PSTN world, the Mediation Server must translate Microsoft’s Real Time Audio (RTA) codec (which is a native Lync protocol for audio traffic) to the industry standard codec of G7.11, as Figure 1 shows.
Besides being responsible for translating codecs, the Mediation Server is responsible for making sure that calls are always possible. The connectivity to the PSTN gateway is important, as it enables end users to make calls and lets administrators know when calls aren't possible in a particular route.
Connectivity to next-hop gateways is maintained by using:
- SIP OPTIONS requests. The Mediation Server sends out SIP OPTIONS requests continuously to try to communicate with its next hop. For example, in Figure 1, the next hop would be the IP-PBX gateway. In the event that the next hop isn't available, the Mediation Server will signal back to the Front End Server that the next hop is no longer accepting requests.
- Routing timeouts. After the Front End Server learns that a Mediation Server isn't able to connect successfully to the next hop (e.g., the IP-PBX gateway in Figure 1), the Front End Server marks that Mediation Server as unavailable for routing calls. At this point, the Front End Server will choose an alternative path based on the appropriate dial plan to which the user belongs.
Mediation Server Topologies
The Mediation Server can be deployed using a collocated or standalone approach. A collocated Mediation Server can handle up to 150 calls, whereas a standalone Mediation Server can handle up to 1,100 calls.
By default, the Mediation Server role and other roles (e.g., Archiving, Monitoring) are collocated on the Front End Server if you enable them during the deployment process. With this deployment, you need to take into consideration the extra load that the call processing for Enterprise Voice users will have on the Front End Server. CPU is important with this deployment approach and shouldn’t be overlooked or skimped on.
With the standalone deployment approach, the Mediation Server is located on separate servers (physical or virtual). This approach isn't the default, so you need to choose the standalone option during configuration. Afterward, you need to define a pool that contains the logical names of the mediation servers to which the possible SIP Trunks will connect. DNS load balancing or routing traffic equally to all Mediation Servers will required for the mediation pool.
A Crucial Role
The Mediation Server isn't misunderstood—it's just not talked about enough in the unified communications (UC) community. With each Lync edition becoming more prevalent as a PBX replacement, the ability for users to make and receive phone calls with their Lync clients and call into Lync conferences from PSTN devices such as cell phones is becoming almost a necessity in organizations today. The Mediation Server in Lync 2013 plays a crucial role in the day-to-day operations of a Lync environment and the way users interact as a whole.