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.

• Investigating Dialing – Dialing Behaviors
• Investigating Dialing – Routing & Authorization
• Investigating Dialing – Dialing Behaviors of an Inbound Call
• Investigating Dialing – Inter Trunk Dialing – This Post

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.

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:

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:

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.

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.

2. We normalize our four digit number into E164

3. Now we get a new retargeting event

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

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

6. Now we see the trunk is selected

7. And lastly we see the route is selected.

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.

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:

So we run the trace again:

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.