Understanding Voice Routing | Dialing Behaviors

It has been a little over a year since I first saw this PowerPoint slide presented by Doug Lawty and on that day my “Lync life” changed completely.  Seeing this slide made everything click in terms of Lync routing and I’ve become obsessed with understanding exactly how the routing engine works, how to trace calls and understanding exactly what is going on under the hood.

voice1_thumb

Slide from TechEd 2012 – http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/EXL318

Why post this now?  Over the past few weeks I’ve been trolling the Microsoft Forums for Lync 2010 and Lync 2013 and there have been a large number of questions on how routing of calls works.  So I starting doing some searching and couldn’t find any that really broke down the routing process in great detail so I figured this would be a good time to do that.  Over the course of the next few blog posts I’m going to break down each of these items in terms of routing, what components to use to trace the call path and what that would look like.

Before we start breaking down the call flow there is one important thing to note about the diagram above.  The flow starts in the upper right-corner with User Initiates Call but this call flow is exactly the same for both outbound and inbound dialing.  So for this first post we will focus on the Dialing Behaviors portion (top half) of an Outbound Call from the Lync.  Here are the posts we will see in detail:

Outbound Call – User Initiates Call

The first box is where the magic starts.  The user dials a phone number in the Lync Client and we have to make the very first decision – is this a SIP URI or anything else.  If the number is a SIP URI (anything@anything) the client will immediately give you the option to dial that number.  When the number is dialed it will add a ;user=phone to the end of the dialed number.

voice7

Here we can see the client will attempt to call notarealname@masteringlync.com bypassing all call routing of the diagram and immediately search for that SIP URI within the system.  If the SIP URI is an internal SIP Address, it will search it’s local database for a match and route and if the SIP URI is external, the call will be routed to the edge server.

To see what happens I will ensure that tracing is enabled within my Lync client open the log file that is created in the C:UsersRichardAppDataLocalMicrosoftOffice15.0LyncTracing folder.  When I open up the log I find this message:

voice3

Here you can see from my work domain it is attempting to do a lookup for the masteringlync.com domain (on the edge) and because I don’t have any DNS records published for that domain, it returns a 404 Not Found:

voice4

So now we understand how the SIP URI lookup works let’s look at the other leg of this call.  Let’s pretend the user dials 952-555-1111 for the number.  In this case the call isn’t a valid SIP URI so we would route to the next step.

Emergency Call

In this step we are going to investigate if this is an emergency call.  This is done based on the location profile assigned to the user and the emergency numbers defined within that location policy.

When a user logs into Lync, via in-band provisioning, the details of the location policy are passed to the client.  So again using snooper and looking at the same log file we see these settings passed to the workstation.  First we have a subscribe message:

voice5

And then the response:

voice6

So here we can see that an emergency number is considered to be 911 or by the Emergency Dial Mask 911 or 211.  If the number we had dialed was either 911 or 211 we would jump directly to the PSTN Usage – in this case 911 Emergency.

However in this case we are dialing 952-555-1111 so this would not be an emergency number and therefore we must move onto the next step.

Global

This step is very easy but incredibly critical in the routing process.   As shown above in the call flow if a number is considered global it bypasses all dial plans and goes directly to Reverse Number Lookup (RNL).  A number that is global is one that starts with a +.  This simple check can cause all sorts of problems with a deployment as is evidence based on the number of posts and questions I’ve seen about it.  Have you ever wondered why your dial plans are ignored on inbound normalization when the upstream PBX/IP Gateway sends you a number with a + preprend to it?  It is because the number is considered “global” and we have bypassed all of your dial plans.

So when a user dials a number from their Lync client it will automatically normalize the number based on rules assigned in the dial plan.  (This is also true if I were to click-to-call someone from my Lync client as well.)

 

voice7

So when the call is made the front-end server will determine the number as “global” and no additional processing will be done.  This can be seen if you do a trace that includes the TranslationApplication component.

voice8_thumb

If you are using CLS Logging in Lync 2013 this is included in the IncomingAndOutgoingCall scenario or you can select TranslationApplciation from OCS Logger.  If you are going to use OCS Logger and Lync 2013 make sure to read my good friend Jon McKinney’s blog post otherwise you won’t see anything in Snooper.

http://blog.lyncdialog.com/2013/03/inboundrouting-and-outboundrouting-does.html

So in this case the call is considered “global” and we move onto the next step.

Reverse Number Lookup

In this step we determine if we are going to route the call using Inbound or Outbound routing.  Inbound routing means that RNL matched an users LineURI exactly and we must route the call to an internal end-point.  Outbound routing means that no user information was matched and we must route out of Lync.

I’ve never found a really good logging process to determine if a number matches RNL other than looking at the log files.  For example, the first picture below is my dialing the phone number of an internal Lync user:

voice9

And the second is a call to an external user:

voice10

You can see in the first picture that the internal call will start down the InboundRouting competent from Snooper and the PSTN call appears under OutboundRouting.  This is the best way I’ve found to determine if RNL was matched or not.

So at this point in time our call has been made and arrived at RNL and needs to be forwarded to the next step Vacant Number Lookup but we will save that for our next blog post.  But you might be asking yourself, what about that section of the call flow that included the Dial Plan, Normalization Rules and more (the upper left side of the slide).  We are going to detail this specifically in the inbound call scenario as that is the most frequent place you see those used however that is not to say they will not ever be used in an outbound call.  Most devices (Lync Client, Aries Phones, others) download the normalization rules to the local device and because we normalize everything to E164 (with the plus) we will most likely skip over these items in many of our outbound calls.

Questions or comments are always welcome.

Share

15 comments on “Understanding Voice Routing | Dialing Behaviors”

  1. Pingback: Understanding Voice Routing | Dialing Behaviors

  2. Pingback: Understanding Voice Routing | Routing & Authorization

  3. Pingback: NeWay Technologies – Weekly Newsletter #38 – April 11, 2013NeWay | NeWay

  4. Logan Reply

    Excellent work. I have been waiting for some information to demystify the internal workings of the Lync call routing. These articles are perfect!!

    Thanks!

  5. Jason Reply

    I’m looking for details on exactly how and when the Edge server is involved when making outbound calls.

    • Richard Brynteson Reply

      Jason – the edge server will be involved in all calls regardless if it’s Lync to Lync, Lync to Conference Services or Lync to PSTN. This is because the client will allocate ports on the edge server. So as long as edge is associated to a front-end server, expect the edge server to allocate ports, even if the traffic never actually goes out the edge.

      • soder Reply

        There is a way you can force to deactivate this symptom: from the lync client policy you can disable the lync client to utilize ICE negotiation. This effectively blocks any Edge communication from the Lync client. The sideffect is that the Lync client cannot anymore do communication with any other Lync users who are outside of the directa reachability from the original Lync user.

  6. Pingback: Inter Trunk Routing Deep Dive

  7. Pingback: Understanding Voice Routing | Inbound Routing

  8. Pingback: Understanding Voice Routing | Routing & Authorization

  9. Pingback: UnifiedMe Lync Outbound Routing (OBR), SIP Options & Voice Failover

  10. Pingback: Understanding Voice Routing | Inbound Routing

  11. Pingback: Inter Trunk Routing Deep Dive | Mastering Lync

Leave a Reply

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