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:

• 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 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:

 example: tel:+49806190890;ext=123

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 "company\user" -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_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=

 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.

 

 

Author: Thomas Pött Managing Consultant Microsoft UC