Demystify Lync Enterprise Voice Phone Numbers and Extension
Copyright© and written 2013 by Thomas Pött, MVP Lync/ Unified Communication
Blog: http://lyncuc.blogspot.de/2013/02/demystify-lync-enterprise-voice-phone.html
Email: Thomas.Poett@live.de
About the Author:
Thomas Pött, Microsoft MVP LYNC and MCITP Lync
Extensive experience in business and market development. Specialized in intercultural and
business relationship in Asia. Successful in providing leadership on new topics and complex
global projects that require interfacing with internal/external teams and ecosystems. Early adaptor
of visionary technologies.
• 20+ year career within different companies in the areas software development,
telecommunication, IT, mobility and hosted/cloud services.
• Strong technical and business background – was member of Microsoft´s German Inner Circle.
• Organized, logical, rationale thinker and problem solver with superb communication and
collaboration skills.
• Business Management skill in strategic and organized developing German SME subsidiaries in
Asia
Specialties: Management:
Start up companies, Business Relation Management, Partner Relation Management, Enterprise
Business Sales Skills, strong team leader and motivator, perfect Asian business and human
behavior understandings, excellent financial cash flow management
Technical:
Microsoft Office 365, Public and Private Cloud Computing, specialized in Hybrid Cloud
integration, Unified Communication (LYNC, OCS, Exchange), Security (PKI, ForeFront), Active
Directory, German efficiency in consulting
I’m living in Bad Wiessee, Germany near Munich and work for ACP IT Solutions AG. Beside the
technical interests, I enjoy paragliding and para-motor.
This article will part of my new book I’m working on, since Lync Enterprise Voice is a more and
more complex environment, where it’s difficult to get the right information.
Any suggestion what areas of EV are from interest, I would be glad to be inspired.

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:
 tel:+498988884444.
 tel:+4980619089123;ext=123 : the extension is part of the phone number.
 tel:+60383830160;ext=123 : the extension is not part of the phone number.
 tel:123;phone-context=HeadQuater. Never put a “+” in front!! (internal “extension” only)
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.
Warning:
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.
example: tel:+49806190890;ext=123
2. The DID is known and the Calling Party is able to directly call the Called Party
example: tel:+4980619089123 or tel:+4980619089123;ext=123
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!
Simple example is:
local-number = tel:123;phone-context=+49894444
local-number = tel:4444123;phone-context=+4989
local-number = tel:9123;phone-context=lync.company.com
local-number = tel:7123;phone-context=Singapore
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 meet.company.com, 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
DomainUserAccount 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:
1. example: tel:+49806190890;ext=123
2. example: tel:+4980619089123
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 "companyuser" -Pin 18723834
Alternatively you can use another command sending a Welcome Email:
Set-CsPinSendCAWelcomeMail -UserUri user@company.com -From
"conferencing@contoso.com"
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:
and
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:+ 492324554746@company.de;user=phone SIP/2.0
From: <sip:thomas.poett@company.de>;tag=4bdaa6a338;epid=fe5337abb5
To: <sip:+492324554746@acp.de;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 ="P�Thomas"--
>"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_AN
ALOG_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=
callp: CCA_RELEASE_CONF
Remember:
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@172.28.11.222:5068;transport=tcp SIP/2.0
FROM: "+4917221711145" <sip:+4912221711145@172.28.11.223:5066>;tag=5502-1360660857
TO: "+492324554746" <sip:+ 492324554746@172.28.11.222>
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

Remember:
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.
Initiated LyncCall
SIP URI User=phone Dial Plan
Normalization Rule
NO NO Normalization Rule
E-9-1-1? Global?
Normalization Rule
YES YES
404: No
Call Park Orbit Range
matching rule
Dialing
Reverse Number Lookup behavior
Routing &
MATCH NO MATCH Authorization
Location Policy Routes 3.Voice Policy
PSTN Usage Route 1. Vacant Number Range
PSTN Usage
Route
Route PSTN Usage
PSTN Usage 2. Call Park Orbit
Route
Mediation Server and Trunk
Configuration 403: No Route Announcement or
found Call Park Application
Inbound Routing Gateway / IP-PBX / SIP Trunk
Lync Endpoint Receives Call External Endpoint Receives Call