Friday, February 15, 2013

Demystify Lync Enterprise Voice Phone Numbers and Extension

Demystify Lync Enterprise Voice Phone Numbers and Extension

Download the article as PDF:
click here
Valid Phone Numbers based on RFC 3966
Lync Server 2013 and his related earlier products (Lync 2010 and OCS) fully depend and follow the given requirements of RFC 3966

With this, we know what the goals are we need to fulfill, in a short sentence, we need to get all numbers translated to an E.164 format. Simply said, E.164 represent an international number format, including the “+” sign at beginning.
Example E.164 Phone Numbers:
+498912345678 (e.g. Munich, Germany)
+6038383123 (e.g. Kuala Lumpur, Malaysia)
E.164 number a unique worldwide, therefor they are capable addressing a single connection point.
As we understood now, it is important to follow this requirements. Nevertheless, there are non-compliance changes local telephone companies apply. This we need to keep in mind, while we do planning’s for our Lync international connection points (Lync to PSTN handover, telephone providers or internal PBX). Those specific gateway configuration I will discuss in other blog articles. Especially, if you are having PBX systems, there are a lot of uncertainties to consider. So better be familiar with the ISDN Protocol, and make yourself fully capable reading and understanding this communication.
The following are valid RFC 3966 TEL URI examples:
Staying alive in Lync Server Enterprise Voice Deployment, keep in mind, Lync is a fully integrated Active Directory Application, therefor it’s necessary to ensure biunique phone numbers. Which means in other words, only one unique phone number per user each.
Valid Caller ID’s
A Caller ID is the Calling Party number displayed at the Called Party site. In other words, the phone number visible at the point, where call will be received.
E.g. if Bernd (Calling Party: +49891234567) is calling Peter (Called Party ID+603831234567), Bernd’s number will be displayed on Bernd’s Lync Client or normal PSTN based phone.
As given in the examples of valid and RFC conform TEL URI’s, we remember about the phone-context based numbers. If a user assigned with this format is allowed making outside calls, you will properly display the wrong and un-callable phone number for any PSTN/ PBX based user.
If you consider this phone number design, be aware about all the hassle you produce and how much effort you have to put into trouble shooting.
If you have chosen this format, truly you are able to configure other translation rules based on the gateway capability and make this design look nice. But it still has two sides, the outgoing call and also the incoming call, so how are you going to translate the provide Calling Party ID???
Others you have to consider in your design and planning, please keep you design decision consistent, so do not start mixing TEL URI formats!
Let demystify DID/ DDI (Direct inward Dialing, sometime also called Direct Dial-In) and Extensions.
I know is sometimes very confusing, you also see people’s business cards with several different number formats. Mostly this number formats are given wrongly and do not make your live easy.
We keep in mind, we have probably two different scenarios how make calls:
  1. We have to call an Auto Attendant/ Receptionist because a Called Party has no DID. He mostly has an EXTENSION, the AA or Receptionist is able to forward this call
  2. The DID is known and the Calling Party is able to directly call the Called Party
Some possible advantage are, if you have for example a Call Center, you don’t want the Agent DID presented, than you will have to choose the Extension way in presenting a valid E.164 number to the Called Party.
A useful Mixed Scenario:
If might be, you want to have a mixed scenario, where the users have DID assigned, but you want to ensure only the Main Desk Number (Receptionist/ AutoAttendant) should be presented, you are able to modify the Lync Voice Route and enable the SUPPRESS CALLER ID feature. Than for all outgoing calls, only and only this number is presented.
On more possible way is using Response Groups, here any Agent can make also call on behalf! I will once in a while also write more about RGS in Lync 2013.
As a best practice make sure to always provide a caller ID that can be called back when calling outside the enterprise. Specify a Line URI that contains a DID number.
Exchange Auto Attendant
Generally I’m taking about extension, Exchange Unified Messaging also make use of a Dial-Plan, called UM Dial Plan, a UM Dialpan establish as link from the telephone extension number of a user, who is enabled for Voice Mail with its associated UM-enabled mailbox. Therefor it’s another point where the extensions will play its role. To make Lync and Exchange work together, where Lync plays its role as seen from Exchange as a PBX. Which relates to an extension required from each UM-enabled Mailbox. Within this Dial-Plan, you have to define the extension digit length, properly matching the Lync assigned extension patterns. This is not a must, but best practice.
Why? If a call will be received by the Exchange AA and the caller want’s to connect his call to the user who is hosted on Lync, he needs to know his extension, if now he is aware only about the extension in Lync, he will not be able to redirect to this user. Sure, you could make use of the speech enabled features, but what’s happened if you can’t pronounce his name correctly?
In Exchange Auto Attendant Setup, you have the PilotIdentifierList, this list contains the extension the AA is responsible for. Via the CAS Server, where incoming call is identified it will be redirected to the Mailbox Server. (Exchange 2013).
In Exchange Dial-Plans, the URIType, NumberofDigitsInExtension and the VoIP connection security will be defined. Lync and Exchange interact with a SIP based Dial-Plan, but need its interfering extension and Phone Number.
As I have spoken about the DID and non-DID deployments, if the AA should be the general point of connection (Receptionist), in non-DID deployment, need to consider the next information:
 The Exchange Auto Attendant has some specialties when you are configuring an Enterprise Voice Setup without DID’s. Since the AA has need for any internal extension, we need to identify an EXT attribute.
Say as an example, we have a base number defined as: tel:+49806190890 the AA would not has an assigned unique number. Therefor it is necessary to do some amendments.
You need to define the EXT attribute like this: tel:+49806190890;ext=1 once this is assigned, the RNL (Reverse Number Lookup) can work. Next would be the associated normalization for inbound calls to the AA.
So you need a normalization rule: ^(\+49806190890)$ -> $1;ext=1
We still have the second possibility, which is with assigned DIDs. This is straight forward as usual, so simply assign the AA: tel:+4980619089123;ext=123
Phone Number Extensions
As I described in the first chapter, phone numbers in Lync are based on RFC3966, this provide us with a guideline how extension will work and must be correctly assigned.
As in common scenarios we can have multiple customer scenarios based on historical/ classic telephony environments. Which leads us to three typical deployments:
  1. Classic DID based deployment
  2. DID based deployment in conjunction with extensions
  3. Deployment with internal extensions only
Regarding Lync, generally we must have extensions for several reasons, e.g. Dail-In Conferencing as and for authenticated users, as well as simplified login to UC Phones. If we do not provide any extensions, e.g. on an UC Phone, the user must use is full length assigned phone number.
As we remember, extension are necessary and making feel user more comfortable with Lync-
While you are migrating to Lync from a classic PBX system, you need to evaluate one of this typical Phone Number Assignment. It might here be necessary to change a number plan once after you finalized the migration. But remember it depends on the customer’s solution you have proposed and the technical supportability of your idea.
Lync 2013 has a new feature, which also leads you into some deployment discussion regarding phone number assignments. You are able to bridge e.g. PSTN-Lync-PBX or PBS-Lync-PBX.
This feature is called: Trunk & Route Management
Continue from here; in Lync, the phone number extension is identified with the EXT parameter.
It is not anything with is submitted in the SIP Call initiation, but in dialing and conferencing behaviors.
We need have a closer look into the SIP definition of its parameters (RFC3966*):
For mandatory additional parameters (section 5.4) and the 'phone-context' and 'extension' parameters defined in this document, the 'phone-context' parameter value is compared as a host name if it is a 'domainname' or digit by digit if it is 'global-number-digits'.  The latter is compared after removing all 'visual-separator' characters
As you have read at the beginning of this article, where examples of phone numbers were given, I dig now a bit deeper into the phone number itself:
Two types of phone numbers can exist, either a “local-number” or a “global-number”, whereby the type for global-numbers MUST contain a “+” sign in front.
This is not the only difference we need to know, far more for any type of “local-number” we have an additional mandatory parameter: “phone-context”. The “phone-context” could be compared as a “domain name”, or identifier. Take care that all and everything in SIP URIs is case sensitive, so too the phone-context. Best practice is: use always lower case characters!
Other to consider are the included hyphens “-“, which are allowed in SIP URIs. It makes it for humans more easily readable. (I personally don’t like hyphens in Lync deployments!)
Coming back to the phone numbers itself. As we identified the “ext” (“extension”) and “phone-context” parameter, the EXT is quite clear and understandable. It reflects the users internal phone extension, either in the DID or non-DID deployments. BUT the phone number must be in “global-number” format including the “+” sign.
More complex and in SIP URIs are the “local-number”, which goes along with the “phone-context” parameter. I repeat; it is the “domain name”, it is nothing usual in Lync deployments, but if you integrate Cisco CUCM or other SIP based telephony system, you might step over it. This parameter is define as a string too, same as the entire URI, due to is has no numeric characters. As a possibility, the phone-context is allowed to carry any “number” starting with a “+” sign, which is than associated as a phone prefix, like “+49-89-4444”. It will e.g. identify the global area in within the local-number assignment. As said this parameter is mandatory!
global-number = tel:+49894444123
global-number = tel:+49894444123;ext=123
next example describes a hybrid DID with non-DID compliant extension
global-number = tel:+49894444123;ext=9123
Lync Conferencing Dial-In behaviors
First and important for you to understand is, it is not possible to connect to a conference without any valid Conferencing ID. If you would try to connect to the simple URL, say, you will see an error taking about you have used a wrong URL. This is an expected behavior due to security reason. It is different if you use the Dial-In into the Conferencing Main Number:
If you dial into the conferencing number, regardless which region you chose, you will be prompted for a Numeric Conferencing ID. This ID is the reverse lookup if a valid conference is active or not.
Second here is, after you are permitted into the Conference General Room, it’s time to authenticate. Here we have two possibilities, either you are joining as a guest or you join as a corporate user. The difference is when you are a corporate user, you have several controlling options more. But this is not what we want to discuss here in the Enterprise Voice Extension discussion ;)
How it’s now possible for a corporate user to identify himself to a conference?
The optimal way here is the user’s extension and PIN. This is one of the reasons why we need to plan for Lync based phone number extensions. Truly the full phone number will work to, but if you assigned only non-DID number, you will definitely need an extension number as well.
I simplified the Dial-In behavior, since is not relevant to our scenario where we discuss about phone number extension.
If you are joining the conference with an authenticated Lync Client, via the Conference URL or your Mobile Phone, the process is different because this will do the Conferencing ID validation check automatically.
Lync Phone Edition behaviors
Microsoft has defined how a Lync compatible UC Phone should technically look like. Principally, a UC Phone first has to connect to the network, which is generally configured in DHCP (Check my Blog here), after the connection process (Device Connection Process) was successful, a user is able to login into the UC Phone.
Here is where the Lync Phone Number Extension comes into place, because the user has the need for authentication as well. Since a UC Phone do not provide the normal, well-known Domain\UserAccount login, we need another identifier. This identifier, which must be unique, can only be the users Phone Number Extension and a dedicated, secret PIN (Personal Identification Number).
Well here we are again and back for the need of our assigned extensions.
Let’s make an example:
With the first example, the user is able to login at the UC Phone, due to the user extension=123, followed by his PIN.
Set-CsWebServiceConfiguration -Identity Global -UsePinAuth $true
Set-CsClientPin -Identity "company\user" -Pin 18723834
Alternatively you can use another command sending a Welcome Email:
Set-CsPinSendCAWelcomeMail -UserUri -From
With the option –TemplatePath, you can use the CAWelcomeEmailTemplate.html which you can modify as your company requirements are.
ISDN Protocol and Gateway based normalization (Called Party vs. Calling Party) and Caller ID
Last but not least, I believe it’s the right place to talk about adjustments you have to make for Lync and the PSTN/PBX connections. First which is mostly confusing are the different terminology Lync carries vs. PSTN (Telephony world).
Generally in each call are logically only two parties involved. The one who is initiating the call and the other party receiving the call. This is always the same, in Lync, at PSTN or the PBX. The direction is also fixed, it is seen from where the call is initiated.
 How it’s called and seen on the PSTN Gateways:
Calling Party (ME – from whom), in Lync Voice Routes also named in (Caller ID)
in SIP messages it’s called From:
Called Party (YOU – to whom)
in SIP messages it’s called To:
If we analyze the Lync initiated call to a phone number, we have to have a look into the SIP INVITE message:
Start-Line: INVITE sip:+;user=phone SIP/2.0
From: <>;tag=4bdaa6a338;epid=fe5337abb5
To: <;user=phone>
Analog to Lync, we need to have a look into the ISDN related message:
callp: mux_isdn:0 (1) ISDN[1](1756): APP : 11 calling_name ="PThomas"-->"Pött Thomas"
 callp: mux_isdn:0 (1) ISDN[1](1756): APP : 0 called_name =""-->""
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNCMD::CCA_RELEASE_CONF;0049806190891234;;15000492324554746;;CCAPI_CIP_ANALOG_SPEECH;1.a/B19/S2M/2xG704IDT_E1;0;0;8;19;510;1;Pött Thomas;;0;;
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:              event=CCA_RELEASE_CONF
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:callingPartyNumber1=0049806190891234
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:callingPartyNumber2=
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:  calledPartyNumber=15000492324554746
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:  redirectingNumber=
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:                cip=CCAPI_CIP_ANALOG_SPEECH
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:  bChannelInterface=1.a/B19/S2M/2xG704IDT_E1
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:              error=0
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:              cause=0
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:                 pi=8
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:           bChannel=19
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:          ChannelId=510
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:      CallControlId=1
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:        callingName=
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:         calledName=
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:               ulaw=0
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:         userToUser=
 callp: mux_isdn:0 (1) ISDN[1](1756) <== ISDNMSG:             charge=
If you are connected to SIP Trunk Provider, it’s the same as Lync is initiating a call, due to it’s still SIP.
Let’s now have a look how the ISDN -> LYNC Call works:
INVITE sip:+ 492324554746@;transport=tcp SIP/2.0
FROM: "+4917221711145" <sip:+4912221711145@>;tag=5502-1360660857
TO: "+492324554746" <sip:+ 492324554746@>
Analog to Lync, we need to have a look into the ISDN related message:
callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNCMD::CCA_RELEASE_RESP;012221711145;;7946#;746;CCAPI_CIP_ANALOG_SPEECH;1.a/B30/S2M/2xG704IDT_E1;0;0;0;30;5538;1;;;0;;;
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:              event=CCA_RELEASE_RESP
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:callingPartyNumber1=012221711145
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:callingPartyNumber2=
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:  calledPartyNumber=7946#
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:  redirectingNumber=746
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:                cip=CCAPI_CIP_ANALOG_SPEECH
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:  bChannelInterface=1.a/B30/S2M/2xG704IDT_E1
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:              error=0
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:              cause=0
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:                 pi=0
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:           bChannel=30
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:          ChannelId=5538
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:      CallControlId=1
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:        callingName=
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:         calledName=
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:               ulaw=0
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:         userToUser=
 callp: mux_isdn:0 (1) ISDN[1](1756) ==> ISDNMSG:             charge=
 callp: 344874: callp: launch: exit Launch:24849
 callp: 344874: callp: scRead(930): socket=26 ret=383
 callp: 344874: callp: scRead(930): socket=26 ret=704
 callp: mux_sip:0 (1) calledPartyNumber="+492324554746"
 callp: mux_sip:0 (1) callingPartyNumber="+49012221711145"
 callp: mux_sip:0 (1) task="sip_isdn:sip_isdn-5540-1360661018"
 callp: mux_sip:0 (1) send to "sip_isdn:sip_isdn-5540-1360661018"
 callp: mux_sip:0 (1) calledPartyNumber="+492324554746"
 callp: mux_sip:0 (1) callingPartyNumber="+49012221711145"
 callp: mux_sip:0 (1) task="sip_isdn:sip_isdn-5540-1360661018"
 callp: mux_sip:0 (1) send to "sip_isdn:sip_isdn-5540-1360661018"
 callp: mux_sip:0 (1) calledPartyNumber="+492324554746"
 callp: mux_sip:0 (1) callingPartyNumber="+49012221711145"
 callp: mux_sip:0 (1) task="sip_isdn:sip_isdn-5540-1360661018"
 callp: mux_sip:0 (1) send to "sip_isdn:sip_isdn-5540-1360661018"
 callp: mux_isdn:0 (1) ISDN[1](1756): APP : calling_name =""
 callp: mux_isdn:0 (1) ISDN[1](1756): APP : called_name =""
Since you now carefully analyze both calls, you will find that the calledPartyNumber and the callingPartyNumber has changed. This is as described, because of the Call Direction.
Additionally in the incoming call, I marked two lines in green, this is a specialty in this customer deployment. We have to have a redirect (redirectingNumber) of the incoming phone number.
What happened here is, it is a hybrid deployment where Lync exist parallel to a PBX. On the PBX the users extension is: 746, but in Lync the extension is: 7946. That’s why we had to redirect the call and forwarded to the “other” calledPartyNumber. In this deployment, users who only want to use Lync, have to forward there PBX based desk phone to the Lync extension.
Don’t get confused here, it’s straight forward.
Nothing here works, if you would not have defined ISDN incoming and outgoing normalization rules on the gateway itself. (PSTN normalization)
I post our setup for ISDN incoming calls:
I post our setup for ISDN outgoing calls:
The outgoing normalization rules could have been simplified, due to easier support and understanding how the setup here was done, we have decided to do a more granular definition instead of complex Gateway Normalization.
Other Terms and shortcuts
 Caller ID (caller identification, CID) = calling line identification (CLID)
Calling number delivery (CND)
Calling number identification (CNID) = calling line identification presentation (CLIP)
Reverse Number Lookup (RNL) – number to SIP resolution
Lync Dial Plan
Once more, Lync Enterprise Voice need properly E.164 formatted phone numbers. As per definition, E.164 numbers a unique worldwide. Every number is a sum of it identifier:
+<country code> <area code> <region code> <subscriber number>
The “region code” is normally an identifier within an area, ahead of the subscriber number. Say we have the city of Munich, the area code of Munich is: 089, now our region code depends on the location with in the 089 area, since also suburban areas, as for example a city call Germering have the Munich area code. E.g. this region is identified as <842>.
Regardless of this principals, we do not need to care about this, maybe in USA or Malaysia it’s different, but since Europe has the phone number portability, we only care about the <area code>.
What Lync plays for a role in this principals?
As we need to make sure Lync has a proper setup for Enterprise Voice with complete E.164 numbers, we have the principal need for a mechanism who takes care that whatever a user is dialing it will be transformed into an E.164 number. This is where the Lync Dial-Plan comes into the game.
The Dial-Plan a simple table providing more or less complex normalization rules based on the users dialing behavior.
Say a user is familiar with, e.g. an 3-digit extension for internal user calls, but Lync only knows the E.164 number as it should, our Dial-Plan takes care and normalize this 3-digit number into a full blown identifier. Same, if the user makes a call with in the area where her is located in, normally, say he is based in Munich, will only dial 44441234, our Dial-Plan will handle this and normalize the call to +498944441234.
The is a specialty in the Dial-Plan called “External Access Prefix”, it’s a little bit tricky with this feature in Lync.
Generally this is to identify and change the dialing behavior once more as it is identified as an EXTERNAL CALL.
We know this from our classic desk phone, where we either need to dial a “0” or “9” as a common pattern, if we want to make an outside call to other ISDN numbers.
In Lync we have two different devices:
  • UC Phone
  • Lync Client
This both clients have different dailing behaviors, see the next chapter “off-hook/ on-hook” dialing
Especially with UC Phones, we need to take care about this differences. For our external calls, we need the External Access Prefix.
But what this special number or number are doing to the Dial-Plan?
Once a user starts dialing a number for any outside call, the Dial-Plan will capture this number prefix and cut this number of the dialed string for the next processing steps.
External Access Prefix
  • A prefix can be specified that signals an external number is being dialed
  • This prefix will not need to be in the normalization rules
  • Internal Extension check box in the normalization rule works with the External Access Prefix to make the below client logic work
If number dialed begins with the prefix, then:
Client removes the prefix. Attempts to find match among the normalization rules that are for external numbers (not marked as internal)
If no match, client keeps the prefix. Attempts to match all the normalization rules that are for internal numbers
If no match, client keeps the prefix. Attempts to match all the normalization rules that are for external numbers
“Off-hook” / “On-Hook” Dialing
Dialing behavior is much different if you use an UC Phone. As we know quite well from other normal Desk Phones (also from home), soon we start dialing the number sequence, the phone starts dialing.
Let’s make an example what happened:
Say we want to place a call to a Munich phone number, e.g. +498984212345, as usual, if you are within the area of Munich, you start dialing with 842xxxx, but if you for example have internal extension starting with an 8, strange things will be happened. Soon you dialed 842, the UC Phone will initiate the call to the internal extension, assume we have a user in US who has the internal extension ext=842.
The Lync Client acts totally different, because only after your dialed the entire number, you have to press the “CALL” button.
But even before you are able to place this call, Lync has normalized the dialed phone number as you see in the picture below. Well, the Dial-Plan with its normalization rules have done their work for us, since the normalization rules are downloaded into the client.
This different behavior is called: On-Hook/ Off-Hook dialing. With the UC Phone, you properly dial off-hook, which means you have taken off the hook and the dial patter will be initiated via dial-tones immediately, this is call “OFF-HOOK”.
On the Lync Client itself, after you have finished typing the phone number and you press the call button, which simulate/ initiates the call is called “ON-HOOK”, dialing with the hook hanged on.
Now you can fetch this behavior with the “External Access Prefix”, or you fallback into the programmed dialing delays programmed into the clients, which works like the following
  • In Lync, user typically dials all desired digits then presses “call”
  • Normalization rules are then processed in order to find a match.
  • When dialing from a device “off-hook,” an inter-digit dialing delay is used to determine when to place the call
    • 1.5 second inter-digit dialing delay
  • If a matching rule is found, the number will be dialed
    • 10 second final time-out
  • If no matching rule is found, the dialstring is sent to the FE
    • Excluding patterns from the device is not supported
(* described at Technet or the TechEd EXL318 pptx)
Lync Voice Routes and PSTN Usage Records
Within the Lync Topology we have finalized the steps on how a call is placed and initiated. We have an E.164 normalized number string which can finally being used for routing to the associated ISDN Gateway/ Median Server, if the call was not made for any internal recipient.
Check the over next chapter “Call Placing Hierarchy” how, when and where the call is running through.
Voice Routes are used in two different scenarios:
  • User associated Call Placing to Gateways
  • Generic Call Routing (Session Management)
We want to identify the User associated Call Placing only.
When you configure a user for Enterprise Voice, there are several parameter you must take care about. One for those is the Voice Policy, which has the necessary PSTN Usage Record reconfigured.
While in the Voice Policy is defined, what the call features are, it also contains the PSTN Usage Record.
What’s all this about?
Voice Route: Contains Matching Pattern, the PSTN Gateway, Associated PSTN Usage Record
Voice Policy: Contains Call Features, Associated PSTN Usage Record
PSTN Usage Record: is ASSOCIATED with -> Voice Policy and Voice Routes 
PSTN Gateway and Mediation Server association is only defined with in the Topology! 
With this interlaced configuration, a very granular routing and call placing behavior can be controlled in the Enterprise Voice setup.
Let’s describe the process for an active user with an assigned Voice Policy:
After the normalized call will be taken care by Lync Enterprise Voice, it will be now passed through the Voice Policy, so the Call Feature checking can be accomplished before the routing will be initiated. Assume the call shall be routed now, the PSTN Usage Record comes into the game.
As the Voice Route is always associated with the PSTN Usage Record, Lync knows where to go with this call. It is sub-sequential how the PSTN Usage Record will processed. It starts with its first Voice Route. Within in the Voice Route, the matching pattern must be checked and only if it fits to the dialing string it will be processed, else the next PSTN Usage Record will be checked until the call is placed or a “Call Could not be routed” messages is provided back to the calling client.
We assume a matching route was found and the next steps regarding call processing could be started. During our Topology Design we have defined the PstnGateways/ SIP Trunk Provider IP’s, where the call now will be handed over to. Also here are multiple Gateways possible to be addressed. It is a round robin procedure how Lync place the call to the gateways.
Here Lync 2013 is with it actual version supporting M:N Mediation Server and Gateway association. In our Voice Route, we only have to define the PstnGateway object, due to a Mediation Server is only part of the Topology, but not involved as an object in Voice Routing! 
Difference between Lync 2010 and Lync 2013 is the naming for Associated Gateway vs. Associated Trunks.
This is simply said the same in the Set-CsVoiceRoute command, for both Lync Server Versions 2010/2013 it is the –PstnGatewayList parameter.
Lync 2013:
Lync 2010:

Lync Trunk Configuration (applied Normalization and Translation)
Let’s understand and talk about the Lync “Trunk Configuration”. Perhaps it confusing for some people what the difference is between a SIP Trunk and the Trunk Configuration. Well, this are two different kind of technology services. Principally, truly both are Trunk related, which means in other words Point-to-Point connections.
Just to remember, if you have SIP Trunk, which is the Telephony Connection from Lync to a Telephony Provider via the SIP protocol. We have the technical requirement for supported SIP Trunk provider listed below. This are the technical connectivity settings which you have to define in Lync Topology as it is the Media Gateway:
  • Ports: TCP 5060 (TLS 5061) and UDP 60.000-64.000
  • Valid Certificate if TLS is used
  • G.711 a-law (used primarily outside North America)
  • G.711 µ-law (used in North America)
It has nothing to do with the definition what could and how could it be delivered to those endpoint.
Here the Trunk Configuration comes into the game, we need a possibility to control the flow settings of those Point-to-Point connections to PSTN Gateway, IP-PBX or SBC (Session Border Controller). As it’s now clear, a Trunk Configuration is the flow control setting and cannot only be used between SIP Trunk Provider and Lync, it also can be used inside Lync Environment to control the SIP Flow to other types of Telephony connection points.
I’m not describing how to setup a Network Topology in Lync with Policy Profiles, Regions, Sites, Subnets, Region Links and Site Routes, which all are required to make a Trunk Configuration work.
If all this is the case, why I’m talk in the Phone Number Extension Blog about the Trunk Configuration. In Trunk Configuration we can define once more Translation Rules, which will modify the transmitted phone numbers. We need to take care and consider if and what we have to translate on Trunk Configuration.
I will next concentrate describing and defining the Trunk Configuration Parameter.
With Lync 2013 the improvements regarding Enterprise Voice were driven more towards an Enterprise capable system. Therefor it’s not surprising we see some differences in Trunk Configurations too. I focus now only on the features visible in the Lync Control Panel (CSCP).
Behind the bold written parameter, L10 stands for Lync 2010 and L13 for Lync 2013.
First we need to determine what type of Trunk Configuration we need: Pool or Site(L10/L13)
·         Pool (Site): assigned to a Lync Site defined in the Topology
·         Site (Service): a service, like PstnGateway object defined in the Topology
Maximum early dialog supported (L10/L13): maximum count of INVITE dialog (* see detailed description)
Encryption support level (L10/L13): (SRTPMode) – define if media traffic is encrypted or not
Enable Media Bypass (L10/L13): define if the Mediation Server can be bypassed by the PSTN connection point and the client
Centralized media processing (L10/L13): if the Gateway object supports an unique IP for signaling and media traffic
Enable refer support (L10/L13): SIP REFER command support for Call Transfer (RFC3515)
Associated Translation Rules (L10):
at this point of configurations, we are able to modify the last time the transmitted Phone Number into a valid format for Site or Pool (Gateway Object), e.g. a SIP Trunk Provider do not support any E.164 format, or requires an identifier, this is the point where to configure this last translation (in other words, similar like a normalization) – As in Lync 2010 it is only the Calling number
Enable RTP latching (L13): This parameter will enabled Media Bypass option for Client (RTP/ RTCP) located behind NAT or Firewall. The SBC must support latching.
Enable forward call history (L13): Call history data can be forward to the trunk.
Enable forward P-Asserted-Identity data (L13): (P-Asserted-Identity (PAI) header can be forwarded along the call to provide a way the caller can be identified.
Enable outbound routing failover timer (L13): If call were not answered from the associated gateways after 10 sec, the call will be forwarded to the next available trunk, else if no additional trunks, a call drop occurs.
Associated PSTN Usage (L13): As described while I explained the Voice Route, PSTN Usage records are required to be configured with this Trunk too.
Associated translation rules: Translations rules modifying the outgoing call
                Calling number translation rules (L13): Will modify the calling number (person who called)
                Called number translation rules (L13): modify the called number (person being called)
*) See the chapter above for detailed explanation for calling vs. called
There are many more option which can be configured on Trunk Configuration in Lync 2013, like the 3ppc, Office 365 Online Voice, E-9-1-1 (Presence Information Data Format Location Object : PIDF-LO) and much more. This will be part in one of my next Blogs, when I’m talking about Deep-Inside Enterprise Voice.
*) Early Dialogs:

RFC 3261: A dialog contains certain pieces of state needed for further message transmissions within the dialog.  This state consists of the dialog ID, a local sequence number (used to order requests from the UA to its peer), a remote sequence number (used to order requests from its peer to the UA), a local URI, a remote URI, remote target, a boolean flag called "secure", and a route set, which is an ordered list of URIs.  The route set is the list of servers that need to be traversed to send a request to the peer.  A dialog can also be in the "early" state, which occurs when it is created with a provisional response, and then transition to the "confirmed" state when a 2xx final response arrives.  For other responses, or if no response arrives at all on that dialog, the early dialog terminates.
In other words, SIP Messages are part of a communication (dialogs), e.g. in our Trunk Configuration negotiation about the inside protocols. We define here how many INVITES can be negotiated. Some of the SIP Trunk Provider support less than the default setting in Lync, we need therefor a Trunk Configuration to support the SBC requirements given to us.
Lync 2013

Lync 2010
Call Placing Hierarchy and Workflow
During my demystifying part about Phone Number Extension, I wrote a lot what extensions are, where and how they are used. Finally it is time to present the entire Routing Process, which means the Work Flow what it happened during an initiated Lync Call.
We differentiate between the Dialing Behaviors, the Routing and Call Authorization. An important part of the process cannot be biunique identified to either one of the sites. This is the RNL (Reverse Number Lookup), the process, where a dialed number will be backward associated with a Voice Enabled Lync User. You can easily verify this process by typing a number of a well-known internal Lync user. After the Dial-Plan are were processed, the RNL does its work and have a look into Active Directory to verify if a user’s phone number associated with an AD user. Sure it’s not directly AD, since AD queries are too slow for Lync (VoIP), Lync did its work much earlier and stored the User (SIP address) and Phone Number in its own database, where the RNL will be cross-check it.


  1. Hi Thomas,

    I like your post and I am looking forward your next blog for the Deep Dive in Enterprise Voice.
    I have seen many blogs, however, none of them actually explain the Dial plan in step by step process. It would be great if someone just explain the 1) Dial plan with DID and Extension for at-least 4 sites 2) Routing to external numbers from the above 4 locations
    Such that everything in step by hiding....

    N Patel

  2. Hi Patel,

    this sounds necessary. Let me see what I can do.
    It than more likely consulting basics, but I try to explain some procedures how the planning of EXT and DID will work, especially if you have different locations involved.

    Just give me some time

  3. Awesome post!

    I'm in a bit of a pickle myself. How did you happen to deal with incoming caller ID of international calls?

    I have a rule for German mobile numbers

    Unfortunately, this also happens to match the US format:


    For the range of 15xxxxxxxxx, these numbers will always match the rule above, which happens to format them to +491510xxxxxxx.

    Fortunately, I am able to break off the 16xxx and 17xxx patterns as they have only 10 digits.

    The bad news is that the telephone company does not send me a +, so I cannot distinguish between a Germany mobile number or a US number in this area code.

    Any thoughts would be appreciated. However, I think I am out of luck unless the telephone company can send me the incoming +.

    1. Hi Jason,

      depends on what Lync version you have. In 2013 you can also play with incoming number formats on trunks.

      But I totally prefer if we actually modify the numbers correctly into the E.164 format on the ISDN interface site. This is best practice.
      Else, if you have SIP Trunks, you need to work on the trunk itself.

    2. Thanks Thomas, I checked my logs again.

      I don't think there's a way around my issue. The telco doesn't send me a + or the leading 0 on the ISDN, so I have no way of filtering these on the way in. 15101231234 can be a German or US number at this point...

      I did take your advise and move my caller ID normalization to the gateway instead. I believe there will be a greater match overall, instead of having lync trying to figure it out.

  4. Hi Thomas,
    Thank you for your post. It's really a lot of useful information.
    I've been looking for a long time to answer my question regarding extension.
    Is it possible for someone from outside the organization to dial the AA , and type in the extension number, and get transfered to the proper user? (Without having to have the extension part of the user's DID) , example: +15143331111 and extension 123? if it is possible, I guess lync has to know where to redirect it, and thus specify some translation rules for each extension to a DID?
    Thank you.

    1. Yes, it is.
      Just some more words:
      You can also use a Response Group, but you cannot make use of AA like call transfer.

      So truly you need Exchange UM. The configuration is absolute identically for Exchange 2010 and Exchange 2013.
      Once you configured the AA correctly, make sure, the LYNC and EXCHANGE UM Extension is the SAME!

      Than, if a caller calls into the AA, he is able beside Voice control using the ton-dial and type extension for a call transfer.

      Hope this helps

  5. QUESTION: IS someone interested in understanding the DID and Pilot Number approach in several countries?
    I would write an additional blog entry

  6. issue is when I call lync to lync and they have simult or call forward on we get the line uri. If they call unified message on exchange 2013 and dial the extension and person still has call forwarding on it give the call forwarding number instead of the line uri specified in lync is there a way to change so that it will always call the line uri number.

    1. Hi Ricky,
      this depends on your dialplans, you need to modify them according to your needs. Than you will have a unique user experience.

  7. Hi Thomas,

    we have a problem with hyperlink. We can not see the telephone numbers on lync contact card as hyperlink.

    any idea?

    1. Hi Burka, I need knowing with version of Lync and outlook you are using

  8. Hi Thomas,
    Thank you for your great article, we configure EV with most of your recommendation, but we face some issues wish you help me in solving it.
    - the user number is "tel:DID;ext=XXXX" with ext is four digit
    - we have normalization rules to change xxxx -> did;ext=xxxx
    - we have PBX integrated with Lync through SIP trunk with users have same 4 digit extensions with adding prefix.
    - we configure simultaneous ringing from Lync side to enable dual-forking.
    - when user call from PBX to external or lync user the calling ID is normilzaed to did;ext=xxxx.
    - it appear in lync client (soft, mobile, handset) and also in CDR report as DID number only without ;ext section.
    - we could solve it for CX handsets and lync client as below URI
    - but for CDR or lync mobile client didn't work do you know how to enable it also on

    1. Hi Hamed,
      thanx for your reply. What you first have to do is, after a call is ended, the Client will send a SIP message containing the CDR information to the monitoring SQL server. You need analyzing those information and see what the client is submitting. based on this information you are able to adjust the normalization or the user tel configuration. maybe you post the result here from your SIP log

    2. Hi Thomas,
      thanx for your interest, i have see the log of the client but no message sent i have uploaded the log file in below URI to check it.
      call from 1148 to 9200.

    3. Hi Hamed,

      the call process is 100% fine: invite, until prack (early media). the termination is now send from the SIP trunk. (gateway)
      meaning here:
      a) internal Lync user is not configured and didn't have the tel:9200 (ext=xx not important) that's why its going to your gateway
      b) the PBX don't know what to do with this call. so maybe no user assigned with 9200.

      I recommend you first using E.164 format within Lync and normalize on the gateway again to format your PBX requires !!

  9. Hi Thomas, Nice article helped to understand the dialing plan, trunk but I am more intrested in Truoubleshooting via SIP logs, can u help

    1. Hi San, you are welcome.
      Please contact me via the contact form on my blog. So we get in touch.
      We chat what you need and I will blog soon about troubleshooting enterprise voice.

  10. Hi Thomas,

    Nice article, thanks for that. Helped with our migration from Lync 2010 to 2013.

    Wondering if may be able to assist with the issue we are having.
    We have an ISDN line and Dialogic gateway. We are in Australia.
    International calls connect to certain countries (Philippines, Ukraine), however fail almost immediately to other countries (US and New Zealand for example).

    Analysing SIP trunks, I noticed different responses from the ISDN, which in case of US and NZ cause the Lync drop the call immediately.

    The very short bit of each case. where ISDN sends a different response:

    Succesfull call:

    580:40.240 [Tel-1 ] Code (45738e8) eSTATE_OUTBOUND_PROCEEDING from eSTATE_OUTBOUND_PENDING
    580:42.400 [Tel-1 ] Code ISDN Task(0) eISDN_MSG_TIMEOUT
    580:42.400 [Tel-1 ] Code (45738e8) eISDN_MSG_TIMEOUT in eSTATE_OUTBOUND_PROCEEDING
    580:42.400 [Tel-1 ] Code _condIsTransferReroute: NO
    580:42.400 [Tel-1 ] Code (45738e8) remaining in eSTATE_OUTBOUND_PROCEEDING
    580:48.048 [teldrv-1 ] Prot [ 1] NLS<-ALERT: 08 02 80 01 01 9D 32 01 80
    580:48.048 [Tel-1 ] Event l4_appl N_ALERT_IN connid:20 cause[00:00] datalen:0
    580:48.048 [Tel-1 ] Code isdnLiAppOnAlerting(20)
    580:48.048 [Tel-1 ] Code ISDN Task(0) eISDN_MSG_IND_ALERTING
    580:48.048 [Tel-1 ] Code (45738e8) eISDN_MSG_IND_ALERTING in eSTATE_OUTBOUND_PROCEEDING
    580:48.048 [Tel-1 ] Code _actSetCallAlerting
    580:48.048 [Tel-1 ] Code isdnGccChangeCallStateMedia: 45738e8 ALERTING 0
    580:48.048 [Tel ] Code (45738e8) Connection has new timeout -1
    580:48.048 [Tel-1 ] Code _entryAlertingState
    580:48.048 [Tel-1 ] Code (45738e8) eSTATE_OUTBOUND_ALERTING from eSTATE_OUTBOUND_PROCEEDING
    580:48.048 [VoIP ] Prot <----SIP/2.0 180 Ringing

    The call then connects OK

    Failing call:

    581:50.144 [Tel-1 ] Code (4574208) eSTATE_OUTBOUND_PROCEEDING from eSTATE_OUTBOUND_PENDING
    581:50.864 [teldrv-1 ] Prot [ 1] NLS<-PROG: 08 02 80 01 03 1E 02 80 88
    581:50.880 [Tel-1 ] Event l4_appl N_PROG_IN connid:21 cause[08:00] datalen:0
    581:50.880 [Tel-1 ] Event PROGRESS = In-band info or appropriate pattern is now available
    581:50.880 [Tel-1 ] Code isdnLiAppOnProgressInband(21)
    581:50.880 [Tel-1 ] Code isdnLiAppOnProgress(21)
    581:50.880 [Tel-1 ] Code ISDN Task(0) eISDN_MSG_IND_PROGRESS_INBAND
    581:50.880 [Tel-1 ] Code (4574208) eISDN_MSG_IND_PROGRESS_INBAND in eSTATE_OUTBOUND_PROCEEDING
    581:50.880 [Tel-1 ] Code _actSetupVoiceDetection
    581:50.880 [Tel-1 ] Code _actEnableCallProgress
    581:50.880 [Tel-1 ] Code (4574208) remaining in eSTATE_OUTBOUND_PROCEEDING
    581:50.880 [Tel-1 ] Code ISDN Task(0) eISDN_MSG_IND_PROGRESS
    581:50.880 [Tel-1 ] Code (4574208) eISDN_MSG_IND_PROGRESS in eSTATE_OUTBOUND_PROCEEDING
    581:50.880 [Tel-1 ] Code (4574208) remaining in eSTATE_OUTBOUND_PROCEEDING
    581:50.880 [VoIP ] Prot <----SIP/2.0 183 Session Progress

    The call is then dropped

    Thanks in advance,

    1. Hi Andrew, sure, I can support you, since some info/traces are missing, I urge you contacting me via the "Questions, Inqueries and more" section above. You will reach me personally on my email there.

  11. Hi Thomas,
    You have written an amazing deep drive article.
    i need your help to find a solution for below problem. Logically we have single Lync Site as HQ. Inside that we have two Lync FE Pools running in two different Datacenter. Where Lync users are evenly distributed between these pools. Each pool has its one sip trunk associated. Everything is working fine for users in Pool A with his associated CUCM Sip Trunk A. Also users in Pool B are able to make calls using CUCM Sip Trunk A. But CUCM Sip Trunk B call is routed and when call is attended we are recieving NO AUDIO. This is same for Pool A and Pool B users both. Concept is if GW in any pool goes, calls must be working from second pool associated gateway,

    1. well not so simple to say. But this is a TRUNK-MEDIATIONSERVER-SIPGW configuration issue.
      You have trunks associated and assigned to GW. Here with Lync 2013 and Skype for Business you can build a N:M solution. this is you main goal. or you have 1:1 and build a backup configuration for each other. But care about the mediation server, if its down, the trunk goes down too.

      In you case where you don't have audio, there is either a codec issue. G.729 is not supported with Skype/Lync. or your firewall bocks traffic. and and and. So check, the SIP Signaling look working, and you should us ClsLogingService tracing the Mediation and SIP component, where the audio got lost.

  12. Hi Thomas,

    assume all PSTN incoming calls reach to Auto Attendant and from there redirected to internal Extension, will be the caller ID Visible in the called Party , because i see it is appearing like anonymous caller ???

    1. Sure, the callee is visible once it leave the AA. if not, you need tracing Exchange SIP message, and see where it got lost.

  13. Great article and useful information. As always, well done. I am curious though, how would you handle routing to a gateway with more than one SIP trunk associated with it. You can only point to one gateway IP, so assuming each SIP trunk had a different block of DID's associated with it would your routing configuration be any different than it is for a gateway with only one SIP trunk?

    1. This is a very good question and is becoming more popular.
      In sum: You treat the gateway with multiple SIP Trunk Provides as a single target for outgoing calls. Incoming is "say transparent" no action necessary. Outgoing you need to build you voice route per SIP Trunk Provider. The gateway has its own set of rules taking this call to Provider A or B. in SfB/ Lync, you simple "combine" the both provides from the internal view.