Archive for the 'Remote Call Control' Category

27 MarDNS Load Balancing with Lync now supported in Mitel LBG 3.4 SP2

Good news! Mitel recently reached out to me to tell me that my post back in 2012 is now wrong, and that in the latest release of their Live Business Gateway (LBG), they now support DNS load balancing for both Lync Server 2010 and Lync Server 2013 with Remote Call Control (RCC).

We all know we’re seeing less and less RCC with Lync out there these days, with both customers realising that the disadvantages outweigh the positives of RCC and the PBX vendors pushing their client plugins more, but there is still a significant legacy install base of RCC configurations and this news may relieve some pain for those organisations.

To receive the LBG 3.4 SP2 software and documentation, speak to your Mitel provider.

16 AprMitel 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.

Problem

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.

Cause

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 pool01.contoso.com).
  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 pool01.contoso.com 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=”contoso.com”;PeerServer=”10.0.10.10″;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.

Solution

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.

Conclusion

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.. 🙂

15 AugConfiguring Lync Server 2010 for Remote Call Control with Mitel 3300

Remote Call Control on Lync is still a bit of a dark area. Everything in the server product remains in terms of configuring RCC, but getting it going is a bit of a different story. There is very little PBX vendor advice around regarding support of RCC in Lync with their PBXs (although Cisco updated their interoperability statement recently).

Plus there are some shortcomings on the client side that will make or break your RCC deployment. One of the biggest pain points is the complete lack of any video capability when Remote Call Control is configured. This will cause dramas for lots of organisations looking to leverage the desktop video capabilities in Lync. More on this from Jason Sloan.

I’m going to dive straight into the thick of it here and concentrate on getting RCC working with a Mitel 3300 ICP PBX and what vendor specific things you need to do in Lync. I will touch on the PowerShell cmdlets to get RCC going in Lync, but for more generic details on how RCC is configured in Lync, check out these other blog posts.

Infrastructure Requirements

At a high level, here are the basic bits and pieces you’ll need to get this running.

  1. Active Directory.
  2. A functioning Lync Server 2010 Environment consisting of at least one Standard Edition Server or an Enterprise Edition Front End Pool and Lync clients.
  3. A Mitel 3300 ICP (IP Communications Platform) and Mitel handsets.
  4. A Mitel Live Business Gateway.
When approaching this kind of integration, you should have an engineer on hand familiar with the Mitel PBX so they can configure the 3300 ICP to work with the LBG and outbound/inbound digit modification on the LBG.

Configuring the Mitel Live Business Gateway

Now let’s take a look at the somewhat tricky part – configuring the LBG. Here’s where you’ll want to have your Mitel man at the ready to give you a hand, mainly in the configuration of the ICP side of things.

Firstly, open up Mitel Business Gateway from Control Panel. This tab will display the IP address of the machine and the SIP port the LBG will use. Unless you have a strict business requirement to encrypt internal communications, don’t select TLS (this is a big headache, involves lots of stress with certificate, something I’ll cover in another post).

Mitel Live Business Gateway

Next, click the ICP tab. Here’s where you specify the Mitel 3300 PBX nodes (aka ICPs) that the LBG will talk to.

Mitel Live Business Gateway - ICP

Specify the IP address of the ICP and the Remote CC URI (this is what will become your Line Server URI in Lync – should be something like lbg@hostname.domain.com) to use. Next, specify the username and password to connect to the Mitel 3300 and hit Add.

Next click the Licensing tab. Here you need to put in your Service Link ID from Mitel to license your users for RCC using the LBG.

Now click the Active Directory tab. You need to configure the LBG to talk to AD so it can check if users are setup with phone numbers that they are attempting to remotely control with Lync.

Mitel Live Business Gateway - Active Directory

Specify the FQDN of a domain controller, then the username you want to use to query AD and the password and click Add To List. You can add additional DCs for redundancy.

Under the ODM and IDM tabs, you can configure how numbers are modified on outbound and inbound calls (so you can normalise incoming numbers from, for example only 4 digit extensions to full E.164 so they match to AD user accounts).

Mitel Live Business Gateway - ODM

Mitel Live Business Gateway - IDM

Finally, on the Log tab, you can setup the log level that will be captured for diagnosis purposes.

Once you’re all done, return to the Live Business Gateway tab and click the button at the button labelled Start.

Configure Lync Server for Remote Call Control

As I mentioned above, configuring the Lync server infrastructure for RCC is a bit different from previous versions. Everything is done in Powershell now, so those familiar with Routing and Authorised Hosts tabs in the OCS 2007 R2 GUI will need to pay attention here.

Setting up routes and trusted applications

To configure remote call control with Mitel, the following Powershell cmdlets will be run using Lync Server Management Shell on the Lync Front End server. Replace server FQDNs and IP addresses with your own.

  1. Create a new Trusted Application Pool for the Mitel LBG.
    New-CsTrustedApplicationPool -Identity mitel-lbg.justin-morris.net -Registrar lyncfe.justin-morris.net -Site 1 -TreatAsAuthenticated $true -ThrottleAsServer $true -RequiresReplication $false
  2. Create a new Trusted Application which is bound to the Application Pool created in the previous step.
    New-CsTrustedApplication -ApplicationId RCC -TrustedApplicationPoolFqdn mitel-lbg.justin-morris.net -Port 5060 –EnableTcp
  3. Create a variable called $tcpRoute that defines the static route to the IP address of the Mitel LBG when the Server URI is matched.
    $tcpRoute = New-CsStaticRoute -TCPRoute -Destination 10.1.10.50 -Port 5060 -MatchUri mitel-lbg.justin-morris.net
  4. Configure the Lync Static Routing Configuration with the new route specified in the previous step.
    Set-CsStaticRoutingConfiguration -Route @{Add=$tcpRoute}
  5. Enable the modified Lync Server Topology.
    Enable-CsTopology
  6. The topology will then need to be exported to XML and a manual workaround applied specific to integration with Mitel. Note that this is NOT RECOMMENDED by Microsoft to EVER manually modify the topology document, but it is required to get RCC working with Mitel in Lync. Test this in an isolated environment before making changes to your production environment.
    Run the following command to export the topology to XML:
    Get-CsTopology -AsXml | Out-File c:\rcc.xml
  7. Open the rcc.xml document and find the line that refers to the Mitel LBG e.g.
    <Cluster Fqdn=”mitel-lbg.justin-morris.net” RequiresReplication=”false” RequiresSetup=”true”>
    <ClusterId SiteId=”1″ Number=”3″ /> <Machine OrdinalInCluster=”1″ Fqdn=”mitel-lbg.justin-morris.net”>
    <NetInterface InterfaceSide=”Primary” InterfaceNumber=”1″ IPAddress=”0
    .0.0.0” />
    </Machine> </Cluster>
  8. Modify the IPAddress field from 0.0.0.0 to the actual IP address of the Mitel LBG e.g. 10.1.10.50.
  9. Save the file and exit.
  10. Next, publish the modified Lync Server Topology to the CMS.
    Publish-CsTopology -FileName c:\rcc.xml

User Configuration

For each user you want to setup for RCC, go into their account details in the Lync Server Control Panel. From the Telephony drop-down menu, select Remote Call Control.

Configure them with a LineURI that looks like this:
tel:+441632456765;ext=6765

And a Line Server URI that looks like this:
sip:lbg@mitel-lbg.justin-morris.net

So in the GUI, it should look like this once configured:

RCC user configuration in Lync Server Control Panel

Once you’ve filled this in, hit Commit.

Additionally, each user needs to have the extension field (e.g. 6765) somewhere in their AD account (in a Telephone field for example) so the Mitel LBG can see that the users is setup for that phone number.

Configuring each Lync Front End Server to listen on Port 5060

Finally, we need to configure our Lync Front End Server to listen on port 5060 for SIP TCP so it can receive traffic from the Mitel LBG. We do this by running the following cmdlet from Lync Server Management Shell:

Set-CsRegistrar “Registrar:lyncfe.justin-morris.net” -SipServerTcpPort 5060

Hat tip to Tom Pacyk’s blog post for this one (again, the guy comes up with the goods).

Troubleshooting connectivity on the LBG

If RCC doesn’t work straight off the bat for you, you can troubleshoot connectivity by opening the Log Viewer application on the LBG. Navigate to C:\Program Files (x86)\Mitel Networks\Live Business Gateway\Tools and open MSPlogs.exe

First, click File then click Connect to MSPLog File…

Mitel LBG Log Viewer

Next, navigate to the Logs directory under …\Mitel Networks\Live Business Gateway\Logs and select appgw.log and click Open.

Mitel LBG Log Viewer

All logs of connections to the LBG are now available for viewing. Interpreting what they mean is a topic for a whole other blog post. 🙂

Mitel LBG Log Viewer

Conclusion

Obviously this is a pretty full-on piece of integration, and this goes into a bit of detail but doesn’t cover everything. You’ll see less and less support of RCC these days and not as many people deploying it, but hopefully this helps those of you out there still wanting to get RCC going with your Mitel 3300 and Lync Server 2010.