Mitel LBG does not support DNS load balancing with Lync Server 2010

I discovered this last week when trying to get RCC to work between a Lync Server 2010 Enterprise Edition Front End pool and a Mitel Live Business Gateway (LBG). The environment consisted of a greenfield Lync deployment with a Lync Front End Enterprise Edition pool consisting of two Front End servers that utilises DNS load balancing.


A few problems were initially observed here in the Lync client when we attempted to make a call using RCC:

  1. Lync places the call and the Mitel handset goes off-hook and dials. However once the call is established, Lync session window does not reflect call duration and does not set presence to “In a Call”.
  2. If you hang up the call by setting the earpiece down on the Mitel handset, the Lync session window doesn’t close like it should. After a few seconds it generate an error and closes.
  3. If you try to end the call using the Lync session window, nothing happens and the call does not end.


So basically what is happening here is one way SIP traffic. Let me illustrate and explain what is causing this problem:

  1. Lync client sends a SIP INFO message that contains the CSTA command MakeCall to the Front End pool (which has a FQDN of
  2. One Front End server (in this case, FE1) in the pool passes this to the Mitel LBG to take the handset off-hook and dial the number.
  3. The LBG tells the 3300 ICP to dial the number.
  4. The LBG dynamically looks up the pool FQDN of that sent it the SIP traffic and because it can’t cache DNS records like the Lync client can, may receive the IP address of FE1 or FE2 to send return traffic to. If it sends traffic to FE2, this is where the problem begins.

When we run a trace on the Lync Front End Pool, we see the following SIP error message in response to the SIP INFO message the LBG sent FE2:
“ms-diagnostics: 1037;reason=”Previous hop client did not report diagnostic information”;Domain=””;PeerServer=”″;source=”FQDN of FE2″

Basically this is FE2 saying “hey LBG, you sent me traffic I didn’t generate, I don’t know what you’re talking about” and FE2 drops the return SIP messages. As a result, the Lync client never sees any return SIP messages to change presence to In a Call, show call duration, etc.


I found that there are a few ways around this problem that are scalable. Initially I created a manual entry in the local hosts file of the LBG for the FQDN of the pool to resolve to the IP address of one Front End server only, but once users registered on the second FE and started sending traffic to the LBG, this workaround no longer worked.

Use a load balancer

The only real solution to this is to load balance traffic on port 5060 (or whatever port you are using to communicate with the LBG with) to the Front End servers in the pool. This will mean the LBG only has one IP address to send its traffic to and the load balancer will take care of session stickiness.


Up until now, all my RCC deployments were either with hardware load balanced Front End pools or with Standard Edition servers so I’d never encountered this before. From this discovery I think we can safely conclude that other vendor CSTA gateways like Cisco Unified Presence Server (CUPS), Avaya’s AES, Nortel CS1000 NRS, Genesys GETS, etc that provide RCC functionality for Lync 2010 also do not support DNS load balancing.

So if you’re looking at deploying a Lync Server 2010 Front End Pool and you want to hook it up to your PBX for Remote Call Control, you will need a hardware load balancer of some kind. The Lync supported vendors/models are listed here.

Ok, I think I know too much about RCC now.. 🙂

5 thoughts on “Mitel LBG does not support DNS load balancing with Lync Server 2010

  1. Ross Allen

    Hi Justin,

    Firstly, I must again thank you for your highly informative blog posts and comment around Lync/Mitel RCC implementation.

    I am experiencing some similar issues to those described above, however, I do not have any load-balancing going on.

    I have a simple set up, one standard edition Lync FE and RCC using LBG 3.4 with a Mitel 3300.

    RCC seems to be working very well, calls are placed, hung up, etc. However, for some calls, after the handset is placed back on-hook at the end of a call, the Lync call window does not close and the user’s Lync status is not updated and remains “In a call”.

    Have you seen anything like this happening or have you any idea what might be causing it and where I should start looking?

    Thanks in advance…

    1. Justin Morris

      Hi Ross,

      Yes I have seen behaviour like this before. Best thing to do is take a SIP trace using the Lync Server Logging Tool on the FE. Capture S4 and SIPStack and start the logging, then reproduce the problem. If you search for “csta” in the SIP messages, you should be able to see which side (Lync or Mitel) isn’t sending the right BYE message.

    1. Justin Morris

      Really? Changing the transport type allows you to use a Mitel LBG with a DNS load balanced FE pool? I’d be keen to hear more about it Thibault.

  2. Pingback: DNS Load Balancing with Lync now supported in Mitel LBG 3.4 SP2 | Justin Morris on UC

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.