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

47 thoughts on “Configuring Lync Server 2010 for Remote Call Control with Mitel 3300

  1. Jason

    Hi Justin,

    Did you get caller ID working properly? I was told by Mitel to drop my E.164 notations in Lync and AD and just use the extension digits +xxxx for AD. and Tel:xxx for Lync and that did not work.

    Thanks,

    jason

    Reply
    1. Justin Morris

      Hi Jason,

      I’ve had mixed results with using E.164 with the LBG and the Mitel 3300 depending on the customer. It should be possible in the IDM and ODM tabs of the LBG so it presents E.164 to, and accepts E.164 from Lync so you can maintain E.164 number formatting in AD.

      Reply
  2. Jason

    Thanks Justin – I’ll keep hacking away at it. Mitel hasn’t been successful – hopefully they will update LBG soon.

    Reply
  3. Jeff

    Great writeup, more helpful than Mitel’s documentation dare I say. Do you know if there is a way to associate multiple lines with one Lync account? For certain users, I would like their Lync status to change to “In a call” if they pick up a line other than their prime number.

    Reply
    1. Justin Morris

      Hi Jeff, thanks for the kind comments. 🙂
      Unfortunately you can’t assign more than one line to a user in Lync. The Mitel LBG does a lookup on the user’s extension configured in AD and allows it to control the one endpoint.

      Reply
  4. David Carter

    Hi Justin,
    Firstly, thanks for the guide, helps a lot! 🙂 Secondly, my question is can you run the LBG from the same server as Lync, or does it need to be definately on a different server? If it can be on the same one, what do you need to do differently with the powershell cmdlets?

    Reply
    1. Justin Morris

      Hi David, it definitely needs to be a different server. This is because we’re communicating on a uniform SIP port of 5060.
      It might be possible to configure Lync to listen on one port and the LBG on another but I wouldn’t recommend this from a troubleshooting standpoint (i.e. if you can’t get it working, this would be the first thing to look at as the cause of the problem).

      Reply
  5. danny

    Hi Justin,
    Excellent write up.
    I have a question. How much work did u have to do on the Mitel PBX itself?
    I couldn’t find the configuration steps on Mitel PBX for this kind of setup.
    Thanks!

    Danny

    Reply
    1. Justin Morris

      Hi Danny, I’ve not had any experience configuring the actual 3300 ICP for RCC. My understanding is that CTI needs to be enabled at a very minimum, but I recommend you consult a Mitel specialist for this part of the deployment.

      Reply
  6. MK

    Hi Justin,

    Great article – I’ve used it with couple of clients who required RCC. But quick question. Do you have any ‘How to’ info about direct SIP integration between Mitel 3300 and Lync server 2010 ? I understand that it doesn’t require LBG.

    Thanks

    Reply
    1. Justin Morris

      Hi Murali,

      Thanks for the feedback. 🙂

      Re: Direct SIP with Mitel, no it doesn’t require the LBG. You need to configure your Lync Mediation Server to use the Mitel 3300 ICP as a PSTN gateway over SIP TCP.
      On the Mitel side, you need to configure a SIP trunk to Lync. I’m not a Mitel specialist so unfortunately can’t help with the Mitel side of the configuration.

      Reply
  7. Pingback: Configuring Lync Server 2010 for Remote Call Control with Mitel 3300 « ahandyblog

    1. Justin Morris

      Hi Chris, this integration scenario is very much dependent on the Mitel LBG. If the LBG works with the Mitel 5000 as well as the 3300, then this setup may work with it also.

      Reply
  8. B4Z

    Hello and thank you for the very helpful article. I have integrated a Mitel 3300 with Lync at my head office, however I have other Live Business Gateways at international sites. I want to add these gateways into Lync also. I was assuming I could repeat the above process with the exception of changing the -Identity of the LGB, the -ApplicationID to something unique and creating a unique route variable name, such as $tcproutenewyork. Can I ask if this is something you have attempted before? Any feedback would be great.

    Reply
    1. Justin Morris

      Hi there, yes I have attempted this before. You should make sure each LBG has a unique FQDN and create trusted application pools and routes for each e.g. nyclbg.domain.com, lonlbg.domain.com, etc

      Reply
  9. Peter

    The Mitel docs for LBG, at least for version 3.2, suggest to use port 5061 and TLS. I noticed above that in your configuration example you use only 5060 and TCP. This configuration is set on the Live Business Gateway tab. What exactly is being configured on this tab? The communication with Lync? What would issues might arise using TCP over 5060 rather than TLS over 5061?

    Reply
    1. Justin Morris

      The SIP listening port for the LBG is configured on this tab in the LBG UI. This is the port that Lync will connect to to send CSTA messages for RCC.

      The issue of using 5060 rather than 5061 is that 5060 TCP is unencrypted. TLS over 5061 is encrypted so all the CSTA messages in the SIP packets cannot be intercepted and inspected. Setting up TLS with an LBG is more challenging than just TCP unencrypted as it involves using the SSL tools that come with the LBG and doing a conversion of the certificate that you issue to it to a format the LBG can use.

      Unless you have a business requirement for all SIP traffic to be encrypted on your internal network, I recommend just using unencrypted TCP.

      Reply
  10. Ross

    Hi Justin,

    Firstly, many thanks for all of your blog and forum posts on the subjects of Lync and Mitel. Your words have been very helpful in my test deployment.

    I’m still having trouble with the caller ID – Lync pops up +xxxx when an internal caller calls (this is using RCC only)
    I’ve tried populating their AD account with +xxxx (e.g. in the Home number field) and tested the normalisation using abserver.exe but no joy.
    The user defined in LBG is a Domain Admin so no trouble querying AD from that perspective.
    Have you ever managed to get the Lync toasts to display the username rather than the number on incoming calls?

    Thanks again

    Reply
    1. Justin Morris

      Hi Ross,

      Thanks for the feedback – am glad my posts have been of use for you.

      Re: reverse number lookup, yes I have gotten Lync to display the user’s display name rather than the number. You need to ensure that the number listed for the user in the telephoneNumber field matches the number that the LBG is presenting on the IDM tab. So if the 3300 presents the calling number as just 56565 but it’s stored in AD as +12356565, you need to modify the digits on the LBG so it presents +12356565 to Lync.

      Reply
  11. Ross

    Justin,

    Thanks for your quick reply.
    I’ve found that the caller ID displayed by the Lync client on an incoming call seems to be the LineURI “tel:” part from the Lync User’s details.
    However, it still won’t resolve that back to a Lync user for me. 🙁
    e.g. Caller has Line URI: tel:+1234, Receiver’s Lync popup displays “+1234 calling”. Nothing in the LBG (IDM or otherwise) seems to make a difference to this… I’ll keep trying at it and thanks for your help.

    Reply
  12. Ronald

    Hi there. We have build a deployment with lync std server, mitel 3300 and lbg server with rcc deployed. All works well except caller id with internal users calling each other.

    users have 3 digit extensions. We’ve configured LBG (through IDM) so that when a Lync user receives a call it displays the number in E164 format. Users their line uri is as tel:+xxxxxxx900;ext=100

    When a user gets an external pstn call and the number is listed in an outlook contact the lync calling pop-up correctly displays the caller id (as name).

    But when an internal user calls another user the lync calling pop-up does not display the caller id name but just the number in E164 format. Even though it exists in the outlook contacts or GAL.

    Anybody know how to solve this? We’ve looked everywhere. Thanks in advance.

    Reply
  13. Ross

    Hi Justin,

    Just to feedback – I’ve finally managed to get caller ID working. It was a case of utilising the IDM tab and getting the normalisation rules working.

    Ronald – I have this working by way of a normalisation rule which converts the users’ Telephone Number field from AD into the format: tel:+xxxxx;ext=xxxx
    eg. Our AD phone number field is: 01234567890, then our normalisation rule changes this to tel:+441234567890;ext=7890
    My internal calls now resolve the caller ID.
    Hope this helps…

    Reply
  14. Ronald

    Hi Ross,

    Thanks for the info. Much appreciated and also good to know I’m not alone with this issue. The Mitel at the client was set up by a third party with some weird internal numbering configured. There are 2 types of external to internal numbering;

    external +3112345679xx converts to 1xx. So the 9xx gets converted to 1xx range.

    The other range is “normal” were +3112345675xx gets converted to 5xx.

    We managed to use normalization rules on the LBG so that Lync sees the full E164 number as incoming when a user calls another internal user. In AD the users have the exact same E164 number like for example +3112345679xx.

    So if I understand correctly the only thing we should do now is use the lync normalisation file so that;

    +3112345679xx gets converted to tel:+3112345679xx;ext=1xx
    and
    +3112345675xx gets converted to tel:+3112345675xx;ext=5xx

    right? unfortunately I’ve never used the normalization file or know how to build custom regex strings. could you give some more help?

    tel:+311234567989;ext=189

    Reply
  15. Ross

    Sure – for example, one of my normalisation strings is this (have sanitised the numbers!):
    ^01234567(\d\d\d)$
    +441234567$1;ext=3$1

    What this does is take an 11-digit number and “collects” the last three digits (that’s the \d\d\d bit.
    Then it converts it to the 11-digit number with +44 replacing the 0 and appends “;ext=3xxx”, where the xxx are the three digits it collected.

    Therefore 01234567890 gets normalised to: +441234567890;ext=3890

    This is a recognised E.164 format which Lync will display and use the “ext” part to identify the internal extension.

    There are plenty of blog posts out there about normalisation of numbers but the key thing for me was making sure that the normalisation rules appended the “;ext=xxxx” piece…

    You’re exactly right in your statement above – you need to use the Lync normalisation file to do this for you and your conversions are correct.

    The Normalisation file is in the ABFiles directory under the \share\1-WebServices-1 folder.

    Helpful info for regex stuff:
    http://www.regular-expressions.info/reference.html

    Helpful blog post on normalisation:
    http://ucken.blogspot.co.uk/2011/01/enterprise-voice-best-practices-in-lync.html

    Reply
  16. Ronald

    Hi Ross,

    Great! Thanks a lot for the great info and example. I’ll read through the contents of those links.

    One last question if I may though. At the customer the numbers in AD are already in E.164 format. Will the AB normalization accept matching E.164 numbers?

    I know that with voice routing you cannot normalize a number which is already in E.164 format. But I can’t find information if this also goes for AB normalization.

    Because if this is the case then I think the only solution is to let the customer first change all numbers in AD to non-E.164.

    Reply
  17. Ronald

    Hi Ross,

    Just an update to say we got it working thanks to your feedback. Thank you very much again!

    This is what we use in the AB file now;

    ## for the numbering where 9 goes to 1
    \+311234569(\d\d)$
    +311234569$1;ext=1$1

    ## for the normal numbering
    \+311234565(\d\d)$
    +311234565$1;ext=5$1

    Reply
    1. Justin Morris

      Hi Joseph, I don’t know the answer to your question. You might want to contact Mitel about this.

      Reply
  18. Jason

    Hi Justin, We do have a business requirement to use TLS. I need to change the certificate on the LBG server. Can you point me to some articles on how to change the cert to one from an internal CA. Also where are the SSL tools and any associated admin guides? I’m having an RCC error on my Front End server caused by the expired certificate on my mitel live business gateway. Thanks!

    Reply
  19. Dan Shephard

    Hi Justin,

    Thanks for the guide. I have followed it and the system is working, but when I try to dial an external number the phone tells me that I have dialled an incorrect number. Also, incoming phone calls all have a + in front of the number.

    I have tried dial plans and normalisation. Do you have any ideas, or has someone seen the same or similar elsewhere?

    Thanks
    Dan

    Reply
    1. Justin Morris

      Hi Dan,

      You need to fix these number issues using the incoming and outgoing digit modification (IDM and ODM tabs) in the LBG application.

      Reply
  20. Malli

    Hi Justin

    Thanks for the article.
    I have an issue when dialling from mitel phone. The Lync client popups a windows just showing the 4 numbers. Doesn’t show the complete dialled number.
    I have address book normalisation rules applied but doesn’t seem to be working when dialling from the desk phone. They only apply when using Lync client.
    I have setup ODM and IDM rules on the LBG but they don’t seem to make any difference.
    Any help is much appreciated.

    Thanks
    Malli

    Reply
  21. Karl

    Hi

    If anyone experiences the same issue as Malli above it is because the Mitel 3300/MCD is configured to send 4 digits before outpulsing in the ARS configuration, if you set this to the correct digit length for each of your MCD routes the full number will be displayed in the Lync client.

    Thanks

    Karl

    Reply
  22. Graeme

    Hi Justin,
    Thanks for the great article. Did you ever post anything on getting this working with TLS? (as you mentioned early in this one) It seems to be a requirement now with LBG 3.4 and also with Lync 2013.
    Many Thanks,
    Graeme

    Reply
      1. Graeme

        Hi Justin,

        I eventually got RCC working over TLS, and have done most of the migration to Lync 2013 still including RCC. An issue I have had for a long time is that the Live Business Gateway service often crashes out (terminates unexpectedly) and restarts. This leaves anyone who has already logged in to Lync “orphaned” – i.e. the Lync client has lost its connection to the telephone system but doesn’t know it. Our reseller’s support is worse than useless and Mitel won’t talk directly to us. Have you seen this issue in any of the RCC integrations that you have done?
        Thanks,
        Graeme

        Reply
  23. susie moise

    Nice commentary ! I Appreciate the info . Does someone know where my company would be able to get access to a blank GA Form 3300 document to work with ?

    Reply

Leave a Reply to Justin Morris Cancel 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.