Inter Trunk Routing Deep Dive

In our previous three posts about understanding voice routing we investigated outbound dialing from both the Dialing Behavior, Routing & Authorization levels and In-Bound Routing. In this post we are going to explore Inter-Trunk routing or as Microsoft now refers to it as Basic Session Management.

PRE-POST-UPDATE: So good friend Ken Lasko has stolen a little of my thunder in his recent blog post.  Don’t want anyone thinking I just ripped off his content.  We will do much of the same work however we will dive a little deeper into the guts and see exactly what is happening here.

Scenario:

Unlike the other series we are going to have to setup a specific scenario that we want investigate in order to be able to fully understand what is happening here.  So I have created the following setup in my environment.

pic1

We have four phone numbers that I have carved out of my DID block to play with.  2820 to 2823.  A quick description of each of the gateways, trunks, etc.

  • Gateway 10.12.4.16 is an AudioCodes Gateway with PRI  (GW-PSTN)
  • Lync 2013 Mediation Server is within the (corp.com) domain. (Lync)
  • Gateway 10.12.34.26 is an I3 Call Center System (GW-CIC)
  • Gateway 10.12.17.166 is a Lync 2013 Standard Edition Server in a different Active Directory Forest (thelab.info domain). (GW-LAB)

My goal is to get four digit dialing from the PSTN (10.12.4.16) to the Lync 2013 Standard Edition Server (10.12.17.166).  Likewise, I want to be able to outbound dial from my Lync 2013 Standard Edition Server and reach CIC, the other Lync Server Domain and the PSTN.  I decided to use a Lync Server as my third “gateway” so I could use CLS/Snooper and output familiar looking logs.

For the purposes of this example I’ll refer to each component as the GW name listed above in red to make everything easy to keep track of.

Configuration – Inbound Routing from PSTN

We will start by looking first at the inbound routing process for inter-trunk routing.  You will discover this configuration can get confusing very quickly.

Topology Builder Changes

We need to ensure that PSTN Gateways exist in Lync for each of the three Gateways.  We do this via topology builder.  There is nothing special or unique about this configuration.  In all three of my gateways I have decided to use port 5060 and all gateways are configured as TCP to make tracing easier.

Control Panel Changes

This is where the most complicated part of the configuration must take place.  Inter-trunk routing is based on the idea that after going through the call flow process, we match another route and route the call down that path.  The trick becomes authorization.  For a normal Lync user this is done via the voice policy and PSTN usages.  For inter-trunk routing this is done via the Trunk Configuration and PSTN Usages.

So the first thing we must do is create routes for our calls.  So we know that we want 2821 to route to GW-CIC and 282[2-3] to route to GW-LAB.  That leads me to create these two routes:

pic2

NOTE: You can see my route to Test CIC has both 2820 and 2821.  I’m doing this on purpose to reinforce the routing process in Lync.  Remember, that 2820 is currently assigned to a user in my Lync environment.

The second item I need to do is create PSTN Usages that will contain these routes.  So I create two of those:

pic3

I have two usages, named Inter-Trunk Route to BLM Lab and Inter-Trunk Route to CIC.  You will also notice by the very blank space to the right that these PSTN usages are NOT assigned to any voice policies at this time.  For the purposes of in-bound routing there is absolutely no need to associate these PSTN usages to a voice policy.

The last step is authorization.  Remember, before I said that inter-trunk routing authorization is done at the trunk configuration level.  So I go to my Trunk Configuration for PSTN-GW (10.12.4.16).  If you do not have a trunk configuration for this gateway you must create a new pool-level trunk config and select this gateway.

pic4

That is it!  For the purposes of inbound routing there is absolutely no need to assign these PSTN usages to either of the GW-CIC or the GW-LAB trunks in Lync.  You might be asking yourself, why is this, well let’s go to the logs and see what we get.

1. We get the normal inbound four digit number.

pic5

2. We normalize our four digit number into E164

pic6

3. Now we get a new retargeting event

pic7

4. Then we get a new event of creating an outbound routing object.

pic8

5. Then we see it apply an inter-trunk rule

pic9

6. Now we see the trunk is selected

pic10

7. And lastly we see the route is selected.

pic11

So now that we see what is happening on the Lync Server, what do we get on the GW-LAB servers for incoming messaging?  If we do a quick trace there we can see this:

So the inbound call is coming in as E614.

pic20

This makes sense because we normalized the number to E164 back in Lync.  That number was determined to be used for inter-trunk routing because of our PSTN usage applied to the GW-PSTN.  But remember, our scenario needs us to send four digits to GW-LAB.  So in order to accomplish this, we need to go back to our Lync server and create a new PSTN Trunk for GW-LAB.

So here you can our new trunk and rules:

pic21

So we run the trace again:

pic22 pic23

And now we are sending the four digits to GW-LAB as we needed.  So although the documentation is a little thin around this (meaning there is next to none) it is very possible to front end all of your PSTN traffic with Lync.  We will do a part two on this for cover the other parts of the scenario, outbound routing and such.  But frankly, that part isn’t all that difficult.

 

16 comments on “Inter Trunk Routing Deep Dive”

  1. Ken Lasko Reply

    Sorry for stealing your thunder, Richard!

    One of the first places I looked for info on inter-trunk routing was your blog. Didn’t notice it was listed as “upcoming” until after I posted.

    Nice look at the details behind inter-trunk routing. It NOW makes sense that I would only apply the usages to the inbound trunk, rather than the outbound one. Not sure why I thought it was needed on the exiting trunk as well. Now, I gotta go update my post.

    Ken

  2. Richard Brynteson Reply

    Ken – no worries – I was kind of joking on the stealing the thunder part. Just wanted to make sure to reference/acknowledge you had your post.

  3. Austinite79 Reply

    When attempting to Troubleshoot dropped calls that passed thru an inter-trunk route; will the monitoring server show data or do you have to run trace until end users report more dropped calls?

  4. robson de carvalho Reply

    Thanks dear this good article.

    I have a doubt… how work for vice-versa from PBX to LYNC to PSTN ???

  5. Reynaldo Gildersleeve Reply

    Hi there would you mind letting me know which webhost you’re utilizing? I’ve loaded your blog in 3 completely different browsers and I must say this blog loads a lot quicker then most. Can you recommend a good hosting provider at a reasonable price? Kudos, I appreciate it!

  6. Pingback: Inter Trunk Routing Deep Dive

  7. Pingback: Understanding Voice Routing | Dialing Behaviors

  8. Pingback: Understanding Voice Routing | Routing & Authorization

  9. Pingback: Understanding Voice Routing | Inbound Routing | Mastering Lync

  10. Pingback: Транзитные звонки в Lync Server 2013 | ILYA Sazonov: ITPro

  11. MSmith Reply

    Hi. Excellent post – and yes, I’m just now finding this since it was posted 1.5 years ago. Was there ever a part 2 written? I’m interested in all of the call flows in your diagram and how they differ. Thanks.

  12. Lync Admin Reply

    Have you tested if there is a differences if the mediation server is standalone or consolidated?

  13. Aaron Reply

    Hi,

    Is it possible to get the call sent back out the same trunk it came in on?

    I have a bunch of DDI that mostly terminate on to Lync, but some still need to go to a Mitel system during the migration.

    I would like to send every thing to Lync, then any thing Lync does not pick up send back out the same trunk it was received on, where it will hit a SONUS SBC and get pushed to Mitel.

    This way I can reduce my rule from filtering specific numbers to saying “send all to Lync” .. “if not found send back to Sonus” … if coming from Lync and an internal extension send to Mitel. I know its not tidy but it will make the migration simpler. As basically were every the DDI is configured it will eventually reach it with out any policy changes.

    • Ken Lasko Reply

      Yes you can send calls back out the same trunk. I wondered this myself way back when, and it worked like a charm.

      Ken

  14. Luq Reply

    We faced an issue of looping calls coming from a number that is not added in Unassigned number range or to any object. Is this caused by inter trunk routing?

Leave A Reply

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