Tuesday, June 4, 2013

Inter-trunk Routing in Lync 2013

Introduction - What is Inter-trunk Routing?

Inter-trunk routing is a new feature in Lync 2013 that allows Lync Server to be the central call processor for a multi-PBX deployment.  In previous versions, Lync was only capable of being the final destination for phone calls.  If an inbound phone call couldn't be matched to a Lync user, the call would fail.  There was no way to have Lync forward calls on to another PBX, which limited the configuration options available to administrators.

Inter-trunk routing gives Lync administrators the ability to take calls in from a variety of sources and forward them on to other non-Lync destinations if there isn't a matching Lync user with the target phone number. 

The Problem

Recently, I had to deploy inter-trunk routing for a Lync deployment that had calls coming in from a variety of sources to a centralized Lync Server 2013 Enterprise Edition deployment:
  • a Lync-certified SIP trunk
  • a Canada-based T1 line connected to a PSTN gateway
  • two US-based Mitel PBXs. 
The inter-trunk routing requirements were very specific: forward four phone numbers entering Lync from the SIP trunk to one of the US-based PBXs.  The four phone numbers were +1 (289) 555-3926, +1 (289) 555-6733, +1 (289) 555-6734 and +1 (289) 555-6780.

The Solution

Having never done Lync inter-trunk routing, I turned to the trusty Internet for answers.  I found lots of information on WHAT Lync inter-trunk routing was all about, but almost nothing on exactly HOW to configure inter-trunk routing in Lync.  I saw references to assigning PSTN usages to trunks, and saw the place in the Lync Control Panel to add it, but nothing but vague allusions to the process of actually implementing it.

UPDATE 10-June-2013: Richard Brynteson posted a more knowledgable deep-dive into inter-trunk routing mere days after I posted this. I made a slight adjustment to my process based on what I read in his blog, so its definitely worth reading.

As usual, when I come across such a situation, I assume that it must be so simple to configure that it didn't occur to anyone to actually document the HOW.  I then assume I must be a complete idiot for not knowing something so plainly obvious to every other Lync administrator on the planet. So, after much flailing around, I figured out a solution that works using inter-trunk routing.

Since I wanted to route only four specific phone numbers between trunks, I needed to make sure that I enabled inter-trunk routing for those numbers and no others.  If I allowed inter-trunk routing for too wide a range of phone numbers, we could get into a situation where calls could enter Lync, pass onto the target PBX and route back into Lync, causing a call loop.  Rather than leave it to the target PBX to ensure a call loop doesn't happen, I figured it best to ensure Lync only pass the specific numbers to the PBX.

I started by editing the site-level voice policy attached to the Lync site where the incoming SIP trunk calls came into Lync.  I created a dedicated PSTN usage/route combination for those four numbers.  The PSTN usage was called NA-ON-Cooksville-289555-MitelForward to keep with the naming convention used by the Lync Dialing Rule Optimizer.  The route was called NA-ON-Cooksville-289555-MitelForward with a route pattern of ^\+1289555(3926|67(33|34|80))$ pointing to the PBX at 1.1.1.1. 

The PSTN usage was placed at the very top of each voice policy's PSTN usage list to ensure that any Lync user that tries to dial those numbers will forward the calls to the desired PBX. For good measure, I also added the PSTN usage to the Global voice policy, although I'm not sure this is necessary.

Next, I assigned the new PSTN usage to the incoming SIP trunk under Trunk Configuration.  If the trunk doesn't exist, add it as a new pool trunk.  I then added a trunk for the PBX and added trunk translation rules to strip the number down to 5 digits, which is what the target PBX is expecting.

Once done, I committed the changes and waited a few minutes for the changes to bake to a nice golden brown.

The moment of truth came when I was able to call one of those four numbers and listen as Lync seamlessly passed the calls onto the Mitel PBX.  Great success!

Conclusion

I'd like to say it was my deep, Yoda-like knowledge of how call routing works in Lync that allowed me to think through the process of determining how inter-trunk routing works. Unfortunately, the truth is that I tried random combinations of things until I stumbled blindly onto the solution.  There's a reason why I chose that picture of the Hoff looking vacant and stunned at the same time as my avatar....it's how I look and feel much of the time.

To summarize the process:
  1. Create a PSTN usage/route combination that is specific to the phone numbers required to be forwarded to the PBX.
  2. Place the PSTN usage at the top of all voice policies to ensure that both inbound calls from the PSTN and calls made by internal Lync users are routed to the proper destination.
  3. Assign the PSTN usage to the incoming trunk.
When complete, the whole call process should function as follows:
  1. Inbound call comes into Lync via SIP trunk.
  2. Lync normalizes the number into an E.164 phone number
  3. Lync does a reverse number lookup to check for a Lync user with the same number
  4. If no match in Lync, then it looks for a matching usage/route assigned to a trunk
  5. When found, applies any outbound normalization rules and sends the call to the next hop
For a more detailed description on how the call flow will proceed, check out the Mastering Lync blog.  Richard Brynteson did a series on the nitty gritty details behind dialing behaviours in Lync. His post on Inter-trunk dialing is a deep-dive into the details that I don't get into here.

If there's anyone else out there trying to figure out how to implement Lync inter-trunk routing, I hope this helps figure things out.  As always, if you have any questions or can correct any misunderstanding I might have on the process, just leave a comment.

7 comments:

  1. Great article. This is almost a trivial exercise on a regular PBX. Somewhat flummoxed as to why there is so little info in the public domain or on Technet on how to configure Lync as a tandem switch. Doubt il come across this scenario too often but great to know configure Inter Trunk Routing.

    ReplyDelete
  2. I'm curious if you've gotten the Unassigned Number treatment to work when calls come in from the PSTN? Lync 2013 is routing my unassigned numbers right back out to the carrier. :-/ Seems like the reverse number lookup would also reference the unassigned number table (where I've tried inserting the number both as it comes from the gateway (10 digits) and in E.164 format). Inter-trunk routing is great - but not when the numbers egress where you don't want them too! I see the inbound, unassigned number come in - I see it get normalized, and then... I see it get sent out. I've seen a workaround online where folks talk about assigning a trunk with no PSTN usages - presuming this makes the call fail 'into' Lync where it may then get the unassigned number treatment? but I can't get this to work either. Kind of thinking I have an underlying issue - seems like the unassigned number treatment should work for all calls, regardless of inbound/outbound, right? meh...

    ReplyDelete
    Replies
    1. I believe that the inter-trunk routing happens before it gets to things like unassigned number routing. What you should do is ensure your PSTN usage you create for inter-trunk routing excludes any unassigned number range.

      Ken

      Delete
  3. Hi Ken,

    Is it mandatory to have the numbers like +1 (289) 555-3926, +1 (289) 555-6733, +1 (289) 555-6734 and +1 (289) 555-6780 should be assigned OR can be free?

    Lync is giving error that cannot find the number.

    Thanks,
    Perwaiz Ahmed

    ReplyDelete
    Replies
    1. It might not be Lync giving you the error. It might be passing it properly to your PBX, but isn't formatted properly, so the PBX sends back the error. You might need to do some outbound trunk number manipulation.

      Delete