Media Bypass is an excellent new feature in Lync 2010, the successor to Office Communications Server (OCS) 2007 R2. Currently, when an OCS Endpoint such as Communicator or Tanjay utilize Enterprise Voice, they must utilize RTAudio which an OCS Mediation Server must then transcode to G.711 which is the codec utilized on the Public Switched Telephone Network (PSTN). This obviously adds an extra hop in your call increasing the chance for added latency and needless transcoding which can cause reduced call quality. It can even help reduce WAN traffic as a remote branch user can interact with their telephony equipment directly without having to traverse their WAN to communicate with the Mediation Server.
The big thing to keep in mind here, is that there are several things required to support Media Bypass. These include:
- Supported Telephony Equipment (Voice Gateway, IP-PBX, Session Border Gateway at the Internet Telephony Service Provider (ITSP) for SIP Trunking
- Mediation Server Peer must be able to handle communication directly from clients. Many ITSP’s support communication with its direct peer only (Mediaion Server). Contact ITSP for more information.
- Clients must be able to route to the Telephony equipment it will be doing G.711 with.
Many of you will ask, “Well, if all my telephony equipment supports Media Bypass, can I just get rid of all my Mediation Servers?” The answer to this, is… NO! In OCS 2007 R1 and OCS 2007 R2, both the signaling and media flow went through a Mediation Server. Now, the signaling still goes through the Mediation Server but the media will not when using Media Relay in the given location that has Media Relay enabled. So again, the signaling will still appear from the Mediation Server.
OCS 2007 R2 Topology
So in this case, let’s say you have one branch office and one main datacenter. Both the main datacenter and the branch office have users in them. Let’s take a look at what a possible architecture would look like in OCS 2007 R2.
In OCS 2007 R2, let’s say we had HA requirements. We’ve deployed the following:
- 2 Front End Servers
- 2 Mediation Servers (cannot put them on the Front End Servers)
- 2 Voice Gateways since Mediation Servers and Voice Gateways have a 1:1 relationship
Now in the above architecture, we see the users have to contact the mediation server(s) directly. As stated earlier, this is because both Media and Signaling must flow through Mediation Servers. Clients will communicate using Secure Real Time Protocol (SRTP) utilizing the RTAudio codec to the Mediation Server. The Mediation Server will then transcode that to G.711 and then send G.711 to the Voice Gateways. For the client in the branch site, they must traverse the WAN to utilize the Mediation Servers in the Primary Site. This is a big CON as you’re traversing the WAN making you prone to latency issues, quality issues, and network issues.
Lync Topology Improvements
Now let’s take the same topology and redo it with Lync topology improvements. Let’s take a look at both a voice non-resilient architecture and voice resilient architecture both utilizing Media Bypass.
Non-Resilient Voice Architecture using Media Bypass
The non-resilient voice architecture by itself looks much simpler. The following are benefits of this architecture:
- Mediation Servers co-located on Front End Servers meaning less software/hardware procurement costs. Keep in mind, having the Mediation Servers on the Front End is optional and in some cases, you may want dedicated Mediation Servers. More on this in a future article for which I will provide a link here.
- Primary Site clients talking to voice gateways using G.711 meaning less voice latency and enhanced call quality due to the lack of need for transcoding from RTAudio to G.711
- Branch Site clients talking to a local voice gateway using G.711 meaning less voice latency, enhanced call quality, no need to traverse WAN, less chance for network failures in the WAN, and enhanced call quality due to the lack of need for transcoding from RTAudio to G.711. Again, don’t forget, signaling still occurs through the Mediation Server in the Primary Site. There is no Voice Resilience in this architecture and if the WAN link goes offline, the signaling is dropped and the call is disconnected.
This is most definitely a much better architecture than anything OCS 2007 R2 provides.
Voice Resilient Architecture using Media Bypass
As Lync is becoming a full fledged PBX (subjective statement, I know), Microsoft most definitely needed to provide Voice Resiliency. Lync does indeed provide Voice Resiliency using any of the following:
- Survivable Branch Appliance (SBA) – Host between 25 and 1000 users at your branch site, and if the return on investment does not support a full deployment or where local administrative support is unavailable
- Survivable Branch Server (SBS) – Host between 1000 and 5000 users at your branch site, lack a resilient WAN connection, and have trained Lync Server admins available
- Full Fledged Deployment – If you have more than 5,000 users.
In the following Visio, we will be using an SBA.
We get the same benefits as the non-resilient voice architecture. But in addition to that, we now have registrar pools for each location. For a user located in the Primary Site, their Primary Registrar Pool will be the Registrar Pool belonging to the Primary Site. This user will not have a backup registrar configured as an SBA/SBS cannot act as a Backup Registrar (known as Branch Site Resilience) whereas a Front End Standard Edition Server or Enterprise Edition Pool can act as a Backup Registrar (known as Central Site Resilience which I talk more about here). For a Branch Site User, their Primary Registrar Pool will located in the Branch Site and their Secondary Registar Pool will be located in the Primary Site. Keep in mind, these Registrar Pools are voice only. A Branch Site user will still utilize the Lync Architecture (Front Ends, Directors, Etc.) located in the Primary Site for things like Instant Messaging, Web/Video Conferencing, presence, call forwarding settings, etc.
This SBA appliance contains a Mediation Server, a Registar, and a Voice Gateway. This will allow you to do your signaling, media, and PSTN connectivity all from the Branch Site. Should this SBA fail or something happen to internet connectivity, the client can begin using the Registrar Pool on the Primary Site. The user knows about this site through information provided in in-band provisioning from their SIP connection to their Front End Servers.
The capabilities you do or don’t have will depend on the equipment you are using. For example, this resilient voice architecture will allow for outbound call connectivity. But it will be up to the carriers to support inbound call failover. Another example, is unless you have a full scale deployment in the Branch Site, other features will be unavailable such as:
- IM, Web and A/V conferencing
- Presence and DND-based routing
- Updating call forwarding settings
- Response Group Service and Call Park
- Provisioning new phones and clients