To Collocate or not to Collocate – That is the Question
Considerations
One of the new capabilities in Microsoft Lync 2010 is the ability to collocate your Mediation Server onto the Front End Server(s). There are few situations to be cognizant about in regards to collocation of the Mediation Server.
1. Amount of Media Bypass calls vs. non-Media Bypass calls. For information on what Media Bypass is, refer to my article on Media Bypass here.
2. Dedicated Audio/Video Server(s) or Collocated Audio/Video Servers.
3. Utilizing Direct SIP vs. SIP Trunking vs. Voice Gateway.
Amount of Media Bypass calls vs. non-Media Bypass calls
As stated in the General Information section, please refer to my article on Media Bypass here. In environments with at least one branch site, these branch sites may or may not be utilizing Media Bypass. If not utilizing Media Bypass, the clients in a site where Media Bypass is not enabled will be utilizing the Mediation Server(s) at the main site for both Signaling as well as Media. The Mediation will receive RTAudio media from these clients and transcode it to G.711 and send it the gateway. This takes processing power to do. In an environment where there is a lot of heavy voice users, this media transcoding will take a toll on the Front End Pool and possibly overload it causing a possible degradation of voice quality.
Dedicated Audio/Video Server(s) or Collocated Audio/Video Servers
This one is fairly simple. The existing guidance, which may change at RTM, is if you have over 10,000 users, deploy a dedicated Audio/Video Conferencing Pool. The Lync Server 2010 Planning Tool will assist in determining the amount of dedicated Audio/Video Conferencing Pool Servers you require. If both the A/V and Mediation Server are on the Front End Server(s), you should ensure that there is at least 30% CPU available for just the processing of calls. If 30% is unavailable, the Mediation Server(s) should be split into a separate Mediation Server Pool.
Utilizing Direct SIP vs. SIP Trunking vs. Voice Gateway
All Front End Server(s) in a Pool are created equally. The Topology Document’s view of a Voice Peer is applied consistently across all servers in a Pool. If the Mediation Servers are collocated, each Front End/Mediation Server will need to talk to the Mediation Server’s Peers in the same fashion. Internet Telephony Service Provider’s (ITSP) SIP Trunk Peers and IP-PBX Direct SIP Peers have certain recommendations in regards to collocation while IP Gateways have separate recommendations. Let’s take a look at these recommendations and why these recommendations exist.
SIP Trunks and Direct SIP
If you are utilizing SIP Trunks or using Direct SIP, you will need a trunk going to each Mediation Server. The Peer will provide load balancing mechanisms to ensure that all traffic to a Mediation Server is load balanced.
When taking SIP Trunks with an ITSP, some ITSPs will charge on a per trunk basis. So for each Mediation Server used and connecting to a Session Border Controller (SBC) when utilizing a SIP Trunk, you will most likely be spending more money. If you have 10 Front End Servers with a SIP Trunk going to each, the costs can be high. Instead, it would make more sense to have dedicated Mediation Servers where only possibly 3 are required and now you are only paying for 3 trunks, you have dedicated processing for Mediation Traffic and you reduce hardware utilization on your Front End Server(s). The same issue occurs with Direct SIP to an on-site PBX. You don’t have the cost issue, but you may have the requirement to do application layer load balancing which is another reason why you want a Sip Trunk defined from each Mediation Server to each SBC/Direct SIP PBX.
IP Gateways
This is all different when utilizing Certified IP Gateways. Certified IP Gateways should support DNS Load Balancing to the Mediation Pool. The Certified IP Gateways can also receive traffic from any Mediation Server. Keep in mind, if not using DNS Load Balancing, you’ll still have to set up a SIP Trunk to each Mediation Server.
Standard Edition Front End Server with Collocated Mediation Server
This all becomes a moot point if you only have one Front End Server anyways since you don’t have to worry about any type of load balancing or extra costs associated with more than one SIP Trunks to an ISTP.
Do you mind if I quote a few of your posts as long
as I provide credit and sources back to your weblog? My website
is in the very same niche as yours and my visitors would really benefit from some of the information you provide here.
Please let me know if this okay with you. Regards!
My homepage: Warren
Thank you for asking. I don't mind just as long as you don't copy entire posts and just use snippets and provide credit and source back to my blog.
What a beautiful article. I am in like that too much, In the meantime I have read this whole article attentively. I think all of the people will like this post. You can just carry on……… I prayer for you…
Hey Elan,
I am facing Inbound calling issue with my Cisco ASA. I am using dedicated Mediation server two Network cards. One facing Internal Network without Gateway & other facing my DMZ network with gateway.
I have added required routes on mediation server for Internal network traffic.
I do not have any issue with Outbound calling but inbound calling fails intermediately.
Do you have suggestion on the same.
Thanks in advance.
I have seen a similar issue with inbound calls intermittingly not working but outbound calls working fine. What I ended up needing to do is disable RTCP.
With Cisco integration using a Cisco Voice Gateway or CUCM, it's required to disable RTCP.
Check out the following blog article from VoIPNorm: http://voipnorm.blogspot.co.uk/2011/05/important-…
Hi Elan,
Isnt it recommended to use a seperate Mediation server if you are configuring a SIP trunk? I want to know what would be the NIC setup for the mediation server in that case, 2 NIC? 1 NAT'ed to the firewal and 2nd connected to FE network? Will this work?
A huge portion of my entire article answers your first question. Refer to the section SIP Trunks and Direct SIP. If you have a dedicated Mediation Server, you can do 1 NIC or 2 NICs. In fact, the topology lets you choose either or. If you have 2 NICs on a Mediation, there is no NAT'ing going on. One talks to Voice network and one talks to Front End.
Refer to the following for the 2 NIC setup: http://msunified.net/2011/02/22/dedicated-lync-se…
Hey Elan, great article. Any info on best practices regarding FE's collocated with Mediation with a single NIC (not dual-homed)?
Thanks
I think most of the people I've ever talked to that collocate Mediation/FE always do single NIC. I don't think I've seen any best practices around it. I know there were some problems with dual-nic collocated FE/Mediation servers and mobility that were fixed so I would say make sure you're at the latest CU and that you've downloaded the latest Lync Mobility Update after Mobility installation via Windows Update.
Is it possible to collocate the AV server in the Mediation Pool? or vice versa?
Yes. You can have both collocated, one dedicated, or both dedicated.
Hi, I'm just new here so I can't say more about it but really your information will be very helpful for me. I hope you to post such informative posts in near future also.
Trying to put together a small-ish Lync setup for enterprise voice. Around 100 users, possibly growing as large as 200-250 in the future max. 30 concurrent calls, maybe double that in the future if we grow that much.
I currently have a FE server and an edge server set up (hyper-v guests, 4 cpus, 4 GB ram). Will bump up the ram as needed as we pilot.
We have 8 physical office sites that all tie into a central colocation facility via citrix published desktops. Thinking we'll load the Lync client directly on the local Win7 workstations (basically dumb terminals) and have everyone connect via Edge – this makes the network planning very simple, as there is no need for VPNs or routing configuration. All sites have T1 lines from the same colo company so latency from all sites to the colo is very low (4-15ms depending on the site).
I am thinking of doing a PSTN gateway at the colo (they offer pstn services) or a sip trunk if we want to stay even more flexible (able to move colos easily, etc). I guess I can't take advantage of media bypass – so would you recommend setting a dedicated hyper-v guest to be a mediation server instead of leaving it colocated for this kind of load?
Thanks!
Wes
For that many users, collocated will be fine.
Awesome, thanks Elan! Do you see any issues with just having all the sites connect in via the Edge server? It seems to be the simplest option from a network standpoint – no having to fuss with VPNs…
Trying to think of issues but not coming up with any. Haven't tried having internal users NAT out and back in through Edge though. I won't say it'll definitely work though. Let me know how it works out for you.
Not too concerned about that – since the infrastructure is hosted in a colo the only "internal" users will be on terminal servers, and telephony is disabled there (just IM/presence/desktop sharing) – and those connect directly to the FE server…
Even with a/v conferencing? I am concerned that our user base may go a bit heavy on the videoconferencing once they realize how easy it is to use…
As stated in the article, the general recommendations are to separate out the A/V role when you have over 10,000 concurrent users. Because of that, you'll require a lot of utilization to warrant the need to start splitting off roles, even for the Mediation Server. Keep in mind, the Planning Tool for Lync will help you determine scale.
Thanks Elan… I just wasn't sure because there seems to be a lot of conflicting info put out by Microsoft… i.e. the assumption that no more than 5% of users will be conferencing at any given time (which seems very low to me), as well as the fact that our entire environment will be virtualized…
Hmm don't seem to be able to find the RTM version of the planning tool… is still only the RC available?
Ya, still RC. The RTM will eventually come out. Hopefully soon.
That’s because most people communicate one on one. When you communicate with only 2 people (yourself and one other) this traffic is Peer to Peer and doesn’t go through the MCUs on the Front End Servers.
I am reakky curious about the media impact on the FE server. I hardly believe that a 8 virtual processor Quad-core server even notices if there are 30-40 concurrent calls happening.
I would love additional insight on handling mediation in a virtualized environment – as my testing has produced very inconsistent voice quality on mediation enabled calls on VMware vSphere. Leveraging Cisco IOS IP SLA I've seen anywhere from 1ms to 2000ms latency.
Also, in terms of the access edge role, additional clarification is needed on whether Media Bypass is supported if you have a Lync client coming in over the Internet. I suspect media would be terminated on the Access Edge in this case to support TLS encryption.
Elan,
In my opinion, from an infrastructure perspective, a major factor that needs to be considered includes the security risk. Many enterprises operate separate networks for telephony related traffic and these are usually segregated from data traffic using firewalls/ACLs. The logic is to enhance security through separation of vital telephony components from the data network that has a heterogeneous mix of traffic and is traditionally a riskier network. This case is not favorable towards a media bypass scenario.