General Overview
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
play minecraft free says
My spouse and I stumbled over here by a different website and thought I might as well check things out.
I like what I see so now i am following you. Look forward to finding
out about your web page for a second time.
sharecash Downloader says
It’s a pity you don’t have a donate button! I’d definitely donate to this brilliant blog! I guess for now i’ll
settle for bookmarking and adding your RSS feed to my
Google account. I look forward to fresh updates and will share this site with my Facebook group.
Chat soon!
dinocaputo says
Hi Elan – I just noticed your diagram is showing a user in the Primary site having their backup registrar set to the SBA in the Branch site. My understanding is that Lync SBA's do not support acting as backup registrars for other pools and can only act as Primary registrars. That being said, perhaps the intent is to show the SBA acting as a backup route to the primary site for least cost routing?
Elan Shudnow says
You are very correct. I created this when Lync had first come out and I had not yet known that little detail.
Suhas says
Elan, needed your help in deciding the server configuration for SBS at Branch site with 30 users and media gateway present at that site.
How do i decide on the CPU and RAM here as per Microsoft mediation server should have " 64-bit dual processor, quad-core, 2.0 gigahertz (GHz) or higher
• 64-bit 4-way processor, dual-core, 2.0 GHz or higher", what we have is Single Core processor, 8GB RAM.
I believe this is sufficient for 30 Users.
Elan Shudnow says
There's no real guidance. An SBS handles up to 5,000 users in a branch and I would say that the guidance has you deploying the same hardware that you would for a typical Front End. Since you're only using 30 users, I would say a couple cores and 4-8GB of memory would suffice.
John says
I think there is an error: " For a user located in the Primary Site, their Primary Registrar Pool will be the Registrar Pool belonging to the Primary Site. Their Backup Registrar Pool will be located in the Branch Site. "
SBS & SBA can not act as a backup registrar for users.
Elan Shudnow says
Hey, thanks for the comment. You're correct. I wrote the article before I knew that. I'll get it updated. It's only another pool that can act as a backup registrar for another pool.
Animesh says
Thanks Elan for the wonderful explanation of Branch Office Survivability. Been looking for some documentation around, and yours is the cleanest.
Elan Shudnow says
You're welcome. And thanks for posting.
jessica says
Very clear explaination. Thank you!:)
Aviv says
Just wondering if there is an error in the Legend on both Lync call flow diagrams? Shouldn't the red arrows in the legend depict G.711 instead of RTAudio?
Pashmeen says
Great Post !
Wish you keep posting lots of these :-)
Ryan says
I agree with what you said, Erik. So many times you see information like this that gets sliced up and is very confusing. By the time you are through reading it you might as well tried something yourself. Also, the pictures really help to connect everything. Thanks for the great post.
Erik H says
This post was very helpful- thanks for the clear overview! I didn't really understand how branch resiliency was supposed to work in Lync server before this.