In part 1 we looked at the Regions, Sites and Subnet configuration that can be used across Media Bypass and CAC. This post I will take a closer look at how Media Bypass works and some of the things you will need to do to get it working.
Media Bypass is essential with Lync for two important reasons; firstly it increased the scalability of the Mediation Server which in turn lowered the need to have standalone Mediation Servers. In some circumstances you may still require a standalone mediation Server but in most cases it can now be collocated with the Front End or Stand Edition Servers. Secondly by having media bypass the Mediation Server you can now have a one to many gateways per Mediation Server. This in turn lowers the amount of mediation servers required. In OCS 2007 R2 it was a one to one relationship with media always flowing through the Mediation Server.
How it Works
Media Bypass is actually pretty simple. Its all about matching the bypass ID that is generated when you enable Media Bypass. A unique ID is generated per network Region and for all sites within the region that do not have CAC applied to them. For those sites with WAN links that are using CAC a unique ID is generated.
When a PSTN call is made the mediation server compares the Bypass ID of the clients subnet with that of the gateways subnet. If the two match you enable media bypass. If not, the media will flow through the mediation server. Now, if it is an inbound call the client will do the matching and if the ID’s match the media will flow directly from the gateway to the client. This has nothing to do with the subnet of the Mediation Server. Although it can play a role in the decision its own subnet doesn’t come into play.
There are two ways you can set media bypass. This is an extremely important concept. Always Bypass is used when you have no need to do CAC in your environment or you do not require or want to use RT Audio for PSTN calls through a gateway (even though RTAudio is transcoded to G.711 at the Mediation Server there are benefits to using it over you WAN etc.). This generates only one bypass ID for the deployment. A good example would be a single site deployment with no remote sites. Use Region and Site Information is used when either CAC or when controlled use of bypass is required.
Configuration
There are two main places that Media Bypass is called out and needs to be enabled. The first is the global setting under the network configuration. In my case I am going to use the sites and regions configuration.
The next screen shot shows the second area we need to enable, under the Trunk configuration in the voice routing section.
Scenarios
For my lab environment I have one region and two sites. For the sake of clarity I have configured Use site and region configuration with Call Admission Control (CAC) which means I now have a separate site bypass id for each site. This concept is critical to understanding the different scenarios. The mediation server is collocated with the Survivable Branch Appliance (SBA) and the pool which I tried to call out by boxing my mediation servers. Hopefully this all makes sense when you look at the diagram. I have also made the assumption that my gateways and IP-PBX support SIP/TLS. You can configure Media Bypass with gateways that don’t support TLS but I will leave that till the end of this post.
I have created 9 scenarios with and without the SBA. Had I selected Always Bypass my scenarios would have been much simpler but where is the fun in that? I think in reality organizations will choose to do Media Bypass unless they have a WAN connection that is bandwidth constrained. Similar to the way G.729 is used by most organizations. Only when required. I think Always Bypass will be rarely used however as it is not granular enough even if in most situations you will be doing media bypass anyway. Its those exception like wireless subnet where you may want to turn off Media Bypass in favor of RTAudio that control will desired that Always Bypass won’t allow.
With my two sites the main Lync Pool is located in Seattle with Frontends and a Backend with the mediation Server collocated. New York is my remote site with a remote PBX to show how interoperability could potentially work with a remote site. The scenarios are very high level as the configuration of the IP-PBX depending on the vendor will vary greatly. This is more a high level overview.
Scenario 1
PSTN call, client and gateway within same local (Seattle) site. Pretty easy really. SIP/TLS signaling traverses the pool and the Mediation Server. Media goes directly to the PSTN Gateway using G.711 as its codec.
Scenario 2
PSTN call, remote (New York) client and local (Seattle) gateway. Again the SIP/TLS signaling traverses the pool and the collocated mediation server at our Seattle site. The media this time travels across our WAN as RT Audio and is transcoded by the mediation server collocated on the pool. Then it passes to our gateway using G.711. This is a common scenario when enterprises are employing tail end hop off to save money on PTSN LD charges. In this case the bypass id between our client and mediation server where different due to the being in two different sites.
Scenario 3
PSTN call, remote client to remote Gateway without SBA. This may seem strange that I have called out the missing SBA but there is a reason. This still all makes sense as the gateway and client are in the same subnet and therefor the same bypass ID. This is the exact scenario that could play out if you are using Cisco gateways that doesn’t support the SBA and you choose to not locate any other resources at the remote site. Not that there is anything wrong with this scenario but it looks a little different with a SBA.
Scenario 4
PSTN call, remote client to remote gateway with SBA. The SBA is comprised of two basic components; a SIP registrar and a Mediation Server. I have blown out the mediation server component for clarity similar to my pool. It does not require a separate server. This really doesn’t change to much in this scenario but it does change things in other cases.
Scenario 5
Internal PBX call local client and gateway with SBA. Very similar to our first scenario except substituting the gateway for a PBX.
Scenario 6
Internal PBX call, local client remote PBX without SBA. In this case we once again have centralized our mediation server deployment and not deployed the SBA. Our media traverses the WAN as G.711. Not ideal but still a workable scenario if you have QoS and enough bandwidth. You do loose the ability to control bandwidth usage with CAC though so something to be aware of.
Scenario 7
Internal PBX call, Local client remote PBX with SBA. This time we have RTAudio traversing our WAN and G.711 from the SBA to the PBX. Like I mentioned earlier the SBA has mediation server functionality so it has the ability to define multiple gateways just like the mediation server in our pool. In this case we could use the IP-PBX as a gateway and maintain CAC.
Scenario 8
Internal PBX call, remote client and remote PBX without SBA. Really pretty straight forward and very similar to the situation with the gateway without the SBA.
Scenario 9
Internal PBX call, remote client and remote PBX with SBA. We have an SBA in place and there is somewhat different SIP flow but the media is pretty much the same as the previous scenario without the SBA.
Configuration with Gateway that Do Not Support SRTP
For gateways that do not support SRTP you will need make a configuration change in the Lync Client through PowerShell to help support Media Bypass. If you do not change the encryption setting all calls will pass through the mediation server. You will also need to select the correct encryption level in the Trunk Configuration.This will mean that all PSTN media flowing to the gateway will be unencrypted. Something to keep in mind.
set-csmediaconfiguration –identity global –encryptionlevel supportencryption
For more information on the client setting see here:
http://voipnorm.blogspot.com/2010/09/lync-client-2010-encryption-settings.html
Summary
This has been a really long post. My hope is that this post will help you plan not just for Media Bypass but also some insight into building out your remote sites with SBA/SBS (will cover these in more details in a later post). Getting the right resources in the right locations is critical to have media efficiencies. There are some great enhancements with the mediation server such as media bypass, translation patterns and collocation that when planned correctly can make a big difference in an enterprise environment. Although some enterprise won’t particular care about sending G.711 over the WAN others more bandwidth constrained will still want to use RTAudio. In the end it comes down to your requirements for WAN bandwidth and survivability in the branch.
Comments welcomed.
VoIPNorm
In Senerio 9, I thought the lync client in the New York site would signal to it's primary registrar which would be the SBA in this case verses going over the WAN?
ReplyDeleteThis is true if the focus of the conversation was on the SBA. I had a completely different answer here orignally based on the assumption that the SBA only allowed the registar functionality but infact this is not correct. So to answer your question this is true. This is assuming that the person in the branch has the SBA as the primary register.The SBA will also do call routing locally as well and should be an additional scenario I should add. Thanks
ReplyDeleteChris,
ReplyDeleteIn scenario 4, since Media bypass is turned on and client and pstn gateway are in same subnet wouldn't media flow directly to pstn gateway and sip controls to sba?
By the way great post...it makes help understand call flow easy.
Yes, seems I did it twice in the same post doh. If the client had the SBA as the primary registrar this would be true. But if I was from out of town and just visiting the office no. So it really depends. It seems I was caught out twice in this post:-)
ReplyDelete