Your SlideShare is downloading. ×
Demystify Lync Enterprise Voice Phone Numbers and ExtensionCopyright© and written 2013 by Thomas Pött, MVP Lync/ Unified C...
Valid Phone Numbers based on RFC 3966Lync Server 2013 and his related earlier products (Lync 2010 and OCS) fully depend an...
Valid Caller ID’sA Caller ID is the Calling Party number displayed at the Called Party site. In other words, the phonenumb...
As a best practice make sure to always provide a caller ID that can be called back when calling outside theenterprise. Spe...
Exchange Auto AttendantGenerally I’m taking about extension, Exchange Unified Messaging also make use of a Dial-Plan, call...
Phone Number ExtensionsAs I described in the first chapter, phone numbers in Lync are based on RFC3966, this provide us wi...
Other to consider are the included hyphens “-“, which are allowed in SIP URIs. It makes it for humansmore easily readable....
Lync Conferencing Dial-In behaviorsFirst and important for you to understand is, it is not possible to connect to a confer...
Lync Phone Edition behaviorsMicrosoft has defined how a Lync compatible UC Phone should technically look like. Principally...
ISDN Protocol and Gateway based normalization (Called Party vs. Calling Party)                                         and...
callp:    mux_isdn:0 (1) ISDN[1](1756)               <==   ISDNMSG:            CallControlId=1 callp:    mux_isdn:0 (1) IS...
callp:    344874: callp: scRead(930): socket=26 ret=383 callp:    344874: callp: scRead(930): socket=26 ret=704 callp:    ...
The outgoing normalization rules could have been simplified, due to easier support andunderstanding how the setup here was...
Other Terms and shortcutsCaller ID (caller identification, CID) = calling line identification (CLID)Calling number deliver...
Lync Dial PlanOnce more, Lync Enterprise Voice need properly E.164 formatted phone numbers. As per definition,E.164 number...
The is a specialty in the Dial-Plan called “External Access Prefix”, it’s a little bit tricky with this featurein Lync.Gen...
External Access Prefix    -   A prefix can be specified that signals an external number is being dialed    -   This prefix...
“Off-hook” / “On-Hook” DialingDialing behavior is much different if you use an UC Phone. As we know quite well from other ...
In Lync, user typically dials all desired digits then presses “call”         Normalization rules are then processed in ord...
Lync Voice Routes and PSTN Usage RecordsWithin the Lync Topology we have finalized the steps on how a call is placed and i...
Remember:PSTN Gateway and Mediation Server association is only defined with in the Topology!With this interlaced configura...
Lync 2013:
Lync 2010:
Lync Trunk Configuration (applied Normalization and Translation)Let’s understand and talk about the Lync “Trunk Configurat...
I will next concentrate describing and defining the Trunk Configuration Parameter.With Lync 2013 the improvements regardin...
There are many more option which can be configured on Trunk Configuration in Lync 2013, like the3ppc, Office 365 Online Vo...
Lync 2013
Lync 2010
Call Placing Hierarchy and WorkflowDuring my demystifying part about Phone Number Extension, I wrote a lot what extensions...
Upcoming SlideShare
Loading in...5
×

Demystify lync enterprise voice phone numbers and extension

4,181

Published on

Lync Enterprise Voice, how Phone Number Extension are working. How is the terminology for Calling Party vs. Called Party. ISDN Protocol understanding and related normalization rules. You will fully understand how and when you have to make use of the TEL: and EXT expression.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
4,181
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
148
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Demystify lync enterprise voice phone numbers and extension"

  1. 1. Demystify Lync Enterprise Voice Phone Numbers and ExtensionCopyright© and written 2013 by Thomas Pött, MVP Lync/ Unified CommunicationBlog: http://lyncuc.blogspot.de/2013/02/demystify-lync-enterprise-voice-phone.htmlEmail: Thomas.Poett@live.deAbout the Author:Thomas Pött, Microsoft MVP LYNC and MCITP LyncExtensive experience in business and market development. Specialized in intercultural andbusiness relationship in Asia. Successful in providing leadership on new topics and complexglobal projects that require interfacing with internal/external teams and ecosystems. Early adaptorof 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 andcollaboration skills.• Business Management skill in strategic and organized developing German SME subsidiaries inAsiaSpecialties: Management:Start up companies, Business Relation Management, Partner Relation Management, EnterpriseBusiness Sales Skills, strong team leader and motivator, perfect Asian business and humanbehavior understandings, excellent financial cash flow managementTechnical:Microsoft Office 365, Public and Private Cloud Computing, specialized in Hybrid Cloudintegration, Unified Communication (LYNC, OCS, Exchange), Security (PKI, ForeFront), ActiveDirectory, German efficiency in consultingI’m living in Bad Wiessee, Germany near Munich and work for ACP IT Solutions AG. Beside thetechnical 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 andmore 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.
  2. 2. Valid Phone Numbers based on RFC 3966Lync Server 2013 and his related earlier products (Lync 2010 and OCS) fully depend and follow the givenrequirements of RFC 3966.With this, we know what the goals are we need to fulfill, in a short sentence, we need to get all numberstranslated 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 doplanning’s for our Lync international connection points (Lync to PSTN handover, telephone providers orinternal PBX). Those specific gateway configuration I will discuss in other blog articles. Especially, if youare having PBX systems, there are a lot of uncertainties to consider. So better be familiar with the ISDNProtocol, 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 ActiveDirectory Application, therefor it’s necessary to ensure biunique phone numbers. Which means in otherwords, only one unique phone number per user each.
  3. 3. Valid Caller ID’sA Caller ID is the Calling Party number displayed at the Called Party site. In other words, the phonenumber visible at the point, where call will be received.E.g. if Bernd (Calling Party: +49891234567) is calling Peter (Called Party ID+603831234567), Bernd’snumber 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-contextbased numbers. If a user assigned with this format is allowed making outside calls, you will properlydisplay 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 mucheffort you have to put into trouble shooting.If you have chosen this format, truly you are able to configure other translation rules based on thegateway capability and make this design look nice. But it still has two sides, the outgoing call and also theincoming 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, sodo 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 numberformats. 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=123Some possible advantage are, if you have for example a Call Center, you don’t want the Agent DIDpresented, than you will have to choose the Extension way in presenting a valid E.164 number to theCalled Party.A useful Mixed Scenario:If might be, you want to have a mixed scenario, where the users have DID assigned, but you want toensure only the Main Desk Number (Receptionist/ AutoAttendant) should be presented, you are able tomodify the Lync Voice Route and enable the SUPPRESS CALLER ID feature. Than for all outgoing calls, onlyand only this number is presented.On more possible way is using Response Groups, here any Agent can make also call on behalf! I will oncein a while also write more about RGS in Lync 2013.
  4. 4. As a best practice make sure to always provide a caller ID that can be called back when calling outside theenterprise. Specify a Line URI that contains a DID number.
  5. 5. Exchange Auto AttendantGenerally I’m taking about extension, Exchange Unified Messaging also make use of a Dial-Plan, called UMDial Plan, a UM Dialpan establish as link from the telephone extension number of a user, who is enabledfor Voice Mail with its associated UM-enabled mailbox. Therefor it’s another point where the extensionswill play its role. To make Lync and Exchange work together, where Lync plays its role as seen fromExchange as a PBX. Which relates to an extension required from each UM-enabled Mailbox. Within thisDial-Plan, you have to define the extension digit length, properly matching the Lync assigned extensionpatterns. 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 whois hosted on Lync, he needs to know his extension, if now he is aware only about the extension in Lync, hewill not be able to redirect to this user. Sure, you could make use of the speech enabled features, butwhat’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 AAis responsible for. Via the CAS Server, where incoming call is identified it will be redirected to the MailboxServer. (Exchange 2013).In Exchange Dial-Plans, the URIType, NumberofDigitsInExtension and the VoIP connection security will bedefined. Lync and Exchange interact with a SIP based Dial-Plan, but need its interfering extension andPhone Number.As I have spoken about the DID and non-DID deployments, if the AA should be the general point ofconnection (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 Setupwithout 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 anassigned 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 theAA.So you need a normalization rule: ^(+49806190890)$ -> $1;ext=1We still have the second possibility, which is with assigned DIDs. This is straight forward as usual, sosimply assign the AA: tel:+4980619089123;ext=123
  6. 6. Phone Number ExtensionsAs I described in the first chapter, phone numbers in Lync are based on RFC3966, this provide us with aguideline how extension will work and must be correctly assigned.As in common scenarios we can have multiple customer scenarios based on historical/ classic telephonyenvironments. 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 onlyRegarding Lync, generally we must have extensions for several reasons, e.g. Dail-In Conferencing as andfor 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 PhoneNumber Assignment. It might here be necessary to change a number plan once after you finalized themigration. But remember it depends on the customer’s solution you have proposed and the technicalsupportability of your idea.Lync 2013 has a new feature, which also leads you into some deployment discussion regarding phonenumber assignments. You are able to bridge e.g. PSTN-Lync-PBX or PBS-Lync-PBX.This feature is called: Trunk & Route ManagementContinue 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, thephone-context parameter value is compared as a host name if it isa domainname or digit by digit if it is global-number-digits.The latter is compared after removing all visual-separatorcharactersAs you have read at the beginning of this article, where examples of phone numbers were given, I dignow 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 anadditional mandatory parameter: “phone-context”. The “phone-context” could be compared asa “domain name”, or identifier. Take care that all and everything in SIP URIs is case sensitive, so toothe phone-context. Best practice is: use always lower case characters!
  7. 7. Other to consider are the included hyphens “-“, which are allowed in SIP URIs. It makes it for humansmore 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 phoneextension, 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, butif you integrate Cisco CUCM or other SIP based telephony system, you might step over it. Thisparameter is define as a string too, same as the entire URI, due to is has no numeric characters. As apossibility, the phone-context is allowed to carry any “number” starting with a “+” sign, which is thanassociated as a phone prefix, like “+49-89-4444”. It will e.g. identify the global area in within thelocal-number assignment. As said this parameter is mandatory!Simple example is:local-number = tel:123;phone-context=+49894444local-number = tel:4444123;phone-context=+4989local-number = tel:9123;phone-context=lync.company.comlocal-number = tel:7123;phone-context=Singaporeglobal-number = tel:+49894444123global-number = tel:+49894444123;ext=123next example describes a hybrid DID with non-DID compliant extensionglobal-number = tel:+49894444123;ext=9123
  8. 8. Lync Conferencing Dial-In behaviorsFirst and important for you to understand is, it is not possible to connect to a conference without anyvalid Conferencing ID. If you would try to connect to the simple URL, say meet.company.com, youwill see an error taking about you have used a wrong URL. This is an expected behavior due tosecurity 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 promptedfor 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. Thedifference is when you are a corporate user, you have several controlling options more. But this isnot 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 planfor Lync based phone number extensions. Truly the full phone number will work to, but if youassigned 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 phonenumber extension.If you are joining the conference with an authenticated Lync Client, via the Conference URL or yourMobile Phone, the process is different because this will do the Conferencing ID validation checkautomatically.
  9. 9. Lync Phone Edition behaviorsMicrosoft has defined how a Lync compatible UC Phone should technically look like. Principally, a UCPhone first has to connect to the network, which is generally configured in DHCP (Check my Bloghere), after the connection process (Device Connection Process) was successful, a user is able to logininto the UC Phone.Here is where the Lync Phone Number Extension comes into place, because the user has the need forauthentication as well. Since a UC Phone do not provide the normal, well-knownDomainUserAccount login, we need another identifier. This identifier, which must be unique, canonly be the users Phone Number Extension and a dedicated, secret PIN (Personal IdentificationNumber).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:+4980619089123With 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 $trueSet-CsClientPin -Identity "companyuser" -Pin 18723834Alternatively 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 canmodify as your company requirements are.
  10. 10. ISDN Protocol and Gateway based normalization (Called Party vs. Calling Party) and Caller IDLast but not least, I believe it’s the right place to talk about adjustments you have to make for Lyncand the PSTN/PBX connections. First which is mostly confusing are the different terminology Lynccarries vs. PSTN (Telephony world).Generally in each call are logically only two parties involved. The one who is initiating the call and theother party receiving the call. This is always the same, in Lync, at PSTN or the PBX. The direction isalso 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:andCalled 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 INVITEmessage:Start-Line: INVITE sip:+ 492324554746@company.de;user=phone SIP/2.0From: <sip:thomas.poett@company.de>;tag=4bdaa6a338;epid=fe5337abb5To: <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
  11. 11. 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_CONFRemember: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.0FROM: "+4917221711145" <sip:+4912221711145@172.28.11.223:5066>;tag=5502-1360660857TO: "+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
  12. 12. 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 thecallingPartyNumber 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 customerdeployment. 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 theusers extension is: 746, but in Lync the extension is: 7946. That’s why we had to redirect the call andforwarded 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 ruleson the gateway itself. (PSTN normalization)I post our setup for ISDN incoming calls:I post our setup for ISDN outgoing calls:
  13. 13. The outgoing normalization rules could have been simplified, due to easier support andunderstanding how the setup here was done, we have decided to do a more granular definitioninstead of complex Gateway Normalization.
  14. 14. Other Terms and shortcutsCaller 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
  15. 15. Lync Dial PlanOnce 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 subscribernumber. Say we have the city of Munich, the area code of Munich is: 089, now our region codedepends on the location with in the 089 area, since also suburban areas, as for example a city callGermering 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’sdifferent, but since Europe has the phone number portability, we only care about the <areacode>.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 betransformed 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 usersdialing behavior.Say a user is familiar with, e.g. an 3-digit extension for internal user calls, but Lync only knows theE.164 number as it should, our Dial-Plan takes care and normalize this 3-digit number into a fullblown identifier. Same, if the user makes a call with in the area where her is located in, normally, sayhe is based in Munich, will only dial 44441234, our Dial-Plan will handle this and normalize the call to+498944441234.
  16. 16. The is a specialty in the Dial-Plan called “External Access Prefix”, it’s a little bit tricky with this featurein Lync.Generally this is to identify and change the dialing behavior once more as it is identified as anEXTERNAL CALL.We know this from our classic desk phone, where we either need to dial a “0” or “9” as a commonpattern, if we want to make an outside call to other ISDN numbers.In Lync we have two different devices: - UC Phone - Lync ClientThis both clients have different dailing behaviors, see the next chapter “off-hook/ on-hook” dialingEspecially with UC Phones, we need to take care about this differences. For our external calls, weneed 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 prefixand cut this number of the dialed string for the next processing steps.
  17. 17. 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 workIf number dialed begins with the prefix, then:Client removes the prefix. Attempts to find match among the normalization rules that are forexternal numbers (not marked as internal)If no match, client keeps the prefix. Attempts to match all the normalization rules that are forinternal numbersIf no match, client keeps the prefix. Attempts to match all the normalization rules that are forexternal numbers
  18. 18. “Off-hook” / “On-Hook” DialingDialing behavior is much different if you use an UC Phone. As we know quite well from other normalDesk 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 arewithin the area of Munich, you start dialing with 842xxxx, but if you for example have internalextension starting with an 8, strange things will be happened. Soon you dialed 842, the UC Phone willinitiate the call to the internal extension, assume we have a user in US who has the internalextension ext=842.The Lync Client acts totally different, because only after your dialed the entire number, you have topress the “CALL” button.But even before you are able to place this call, Lync has normalized the dialed phone number as yousee 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 dialoff-hook, which means you have taken off the hook and the dial patter will be initiated via dial-tonesimmediately, this is call “OFF-HOOK”.On the Lync Client itself, after you have finished typing the phone number and you press the callbutton, 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 theprogrammed dialing delays programmed into the clients, which works like the following
  19. 19. 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)
  20. 20. Lync Voice Routes and PSTN Usage RecordsWithin the Lync Topology we have finalized the steps on how a call is placed and initiated. We havean E.164 normalized number string which can finally being used for routing to the associated ISDNGateway/ 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 runningthrough.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 careabout. 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 UsageRecord.What’s all this about?Voice Route: Contains Matching Pattern, the PSTN Gateway, Associated PSTN Usage RecordVoice Policy: Contains Call Features, Associated PSTN Usage RecordPSTN Usage Record: is ASSOCIATED with -> Voice Policy and Voice Routes
  21. 21. 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 controlledin 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 throughthe Voice Policy, so the Call Feature checking can be accomplished before the routing will beinitiated. 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 withthis call. It is sub-sequential how the PSTN Usage Record will processed. It starts with its first VoiceRoute. Within in the Voice Route, the matching pattern must be checked and only if it fits to thedialing string it will be processed, else the next PSTN Usage Record will be checked until the call isplaced 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 bestarted. 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 beaddressed. 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 onlypart 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 Versions2010/2013 it is the –PstnGatewayList parameter.
  22. 22. Lync 2013:
  23. 23. Lync 2010:
  24. 24. Lync Trunk Configuration (applied Normalization and Translation)Let’s understand and talk about the Lync “Trunk Configuration”. Perhaps it confusing for somepeople what the difference is between a SIP Trunk and the Trunk Configuration. Well, this are twodifferent kind of technology services. Principally, truly both are Trunk related, which means in otherwords Point-to-Point connections.Just to remember, if you have SIP Trunk, which is the Telephony Connection from Lync to aTelephony Provider via the SIP protocol. We have the technical requirement for supported SIP Trunkprovider listed below. This are the technical connectivity settings which you have to define in LyncTopology 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 settingsof those Point-to-Point connections to PSTN Gateway, IP-PBX or SBC (Session Border Controller). Asit’s now clear, a Trunk Configuration is the flow control setting and cannot only be used between SIPTrunk Provider and Lync, it also can be used inside Lync Environment to control the SIP Flow to othertypes 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 transmittedphone numbers. We need to take care and consider if and what we have to translate on TrunkConfiguration.
  25. 25. I will next concentrate describing and defining the Trunk Configuration Parameter.With Lync 2013 the improvements regarding Enterprise Voice were driven more towards anEnterprise capable system. Therefor it’s not surprising we see some differences in TrunkConfigurations 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 TopologyMaximum early dialog supported (L10/L13): maximum count of INVITE dialog (* see detaileddescription)Encryption support level (L10/L13): (SRTPMode) – define if media traffic is encrypted or notEnable Media Bypass (L10/L13): define if the Mediation Server can be bypassed by the PSTNconnection point and the clientCentralized media processing (L10/L13): if the Gateway object supports an unique IP for signalingand media trafficEnable 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 intoa valid format for Site or Pool (Gateway Object), e.g. a SIP Trunk Provider do not support any E.164format, or requires an identifier, this is the point where to configure this last translation (in otherwords, similar like a normalization) – As in Lync 2010 it is only the Calling numberEnable 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 forwardedalong the call to provide a way the caller can be identified.Enable outbound routing failover timer (L13): If call were not answered from the associatedgateways after 10 sec, the call will be forwarded to the next available trunk, else if no additionaltrunks, a call drop occurs.Associated PSTN Usage (L13): As described while I explained the Voice Route, PSTN Usage recordsare 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
  26. 26. There are many more option which can be configured on Trunk Configuration in Lync 2013, like the3ppc, 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-InsideEnterprise Voice.*) Early Dialogs:RFC 3261: A dialog contains certain pieces of state needed for furthermessage transmissions within the dialog. This state consists of the dialogID, a local sequence number (used to order requests from the UA to itspeer), a remote sequence number (used to order requests from its peer tothe 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 setis the list of servers that need to be traversed to send a request to thepeer. A dialog can also be in the "early" state, which occurs when it iscreated with a provisional response, and then transition to the "confirmed"state when a 2xx final response arrives. For other responses, or if noresponse 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 Configurationnegotiation about the inside protocols. We define here how many INVITES can be negotiated. Someof the SIP Trunk Provider support less than the default setting in Lync, we need therefor a TrunkConfiguration to support the SBC requirements given to us.
  27. 27. Lync 2013
  28. 28. Lync 2010
  29. 29. Call Placing Hierarchy and WorkflowDuring 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 meansthe Work Flow what it happened during an initiated Lync Call.We differentiate between the Dialing Behaviors, the Routing and CallAuthorization. An important part of the process cannot be biunique identified to either one ofthe sites. This is the RNL (Reverse Number Lookup), the process, where a dialed number will bebackward associated with a Voice Enabled Lync User. You can easily verify this process by typing anumber of a well-known internal Lync user. After the Dial-Plan are were processed, the RNL does itswork and have a look into Active Directory to verify if a user’s phone number associated with an ADuser. Sure it’s not directly AD, since AD queries are too slow for Lync (VoIP), Lync did its work muchearlier and stored the User (SIP address) and Phone Number in its own database, where the RNL willbe 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

×