Dial Plans and Manipulations for Lync Inbound Enterprise Voice

So after you get outbound calls working, you turn your attention to inbound dialing. So you logically dial a number assigned to your inbound line and hear a response from your phone telling you that the number you have dialed is out of service.

Well, that sucks.

So you look all over your PSTN Gateway and try a few things and you still get the message. You do notice that the call is actually reaching your gateway. You may actually something like the following show up in the gateways logs as the calls come in:

(      lgr_flow)(172       ) !! [ERROR] TlsTransportObject#528- CSocket::HandleSocketEvent socket error received, error: Broken pipe(32)  [Time: 02-20-2013@19:30:16]

(      lgr_flow)(171       ) !! [ERROR] TlsTransportObject#529- CSocket::HandleSocketEvent socket error received, error: Broken pipe(32)  [Time: 02-20-2013@19:28:56]

Well, those don’t tell you anything. Really, they don’t! So finally you decide to fire up Lync logging to see if Lync has anything to say about the calls. And boy, Lync sure does have something to say:

Your eyes should instantly jump to the red lines – No matching rule has been found in the dial (plan for the called number). That pretty much spells it out. The dialed call does not match anything in the Site dial plan to which this server belongs.

One of the key reasons for this is to look at the “To” number here – it’s just 4 numbers: 6101. Quite often your telephony provider will just pass the last 4 digits of the destination number instead of the whole DID. So it is up to us to convert this number to something Lync expects to see.

The change can happen in one of two places – the Site dial plan to which this server is assigned or on the gateway itself. As a rule, I prefer to do all conversions on Lync. However, if you are on a large network with many gateways, you are probably better off performing this on the gateway itself.

The reason is for doing it on the gateway is to avoid overlap. With only 4 digits being sent from the telephony provider it is very possible that you will run into overlapping number ranges. At that point, you are kind of hosed.

Doing it on the gateway alleviates the possibility of an overlap. To manipulate the number on an AudioCodes gateway, go to the VoIP/GW and IP to IP/Manipulations/Dets Number Tel->IP menu and add an entry. In the image below, we are adding a prefix of 1555123 to each inbound call:

So now when the call gets forwarded to Lync, it will show up as 15551236101 and now Lync can probably do something with this.

Now, why didn’t I add a ‘+’ to make it a full e.164 address? I certainly could do that. However, when Lync sees any number coming in that starts with a + it never runs it through the normalization routine.  There is nothing wrong with this. However, I want to leave open the possibility that in the future I may need to manipulate this number in Lync somehow. By leaving the ‘+’ off on the gateway side I am making life potentially easier for me down the road.

Now keep in mind that Lync needs to have a normalization rule to add the ‘+’ to this call to make it a proper e.164 number. This is easily covered for the US by the default dial plan normalization added by Lync whenever you create a new dial plan normalization – ^(d{11})$

So why do you have to assign this normalization to the Site dial plan? According to the Lync documentation here: If a user dial plan is not assigned, the Registrar pool dial plan is applied. If there is no Registrar pool dial plan, the site dial plan is applied. Finally, if there is no other dial plan applicable to the user, the global dial plan is applied.

OK, I do stand slightly corrected – you could create a pool dial plan and I am sure there are valid reasons to create them. I’ve just never had to create one. But ultimately, the reason you cannot use a User dial plan is because your gateway is not a user! As such, you cannot assign a plan to the gateway so Lync keeps going up the hierarchy until it finds a dial plan to apply.