Demystify Lync Enterprise Voice Phone Numbers and ExtensionDownload the article as PDF:click hereValid Phone Numbers based on RFC 3966Lync Server 2013and his related earlier products (Lync 2010 and OCS) fully depend and follow the given requirements ofRFC3966

With this, we know what the goals are we need to fulfill, in a short sentence, we need to get all numbers translated to anE.164format. 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 plannings 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 its necessary to ensurebiuniquephone numbers. Which means in other words, only one unique phone number per user each.Valid Caller IDsACaller IDis theCalling Partynumber displayed at theCalled Partysite. 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), Bernds number will be displayed on Bernds Lync Client or normal PSTN based phone.As given in the examples of valid and RFC conform TEL URIs, 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 peoples 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 callexample:tel:+49806190890;ext=1232. The DID is known and the Calling Party is able to directly call the Called Partyexample:tel:+4980619089123ortel:+4980619089123;ext=123Some possible advantage are, if you have for example a Call Center, you dont 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 theSUPPRESS CALLER IDfeature. 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 abest practicemake 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 AttendantGenerally Im 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 its 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 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 acall will be received by the Exchange AA and the caller wants 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 whats happened if you cant pronounce his name correctly?In Exchange Auto Attendant Setup, you have thePilotIdentifierList, 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, theURIType,NumberofDigitsInExtensionand 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 DIDs. Since the AA has need for any internal extension, we need to identify anEXTattribute.Say as an example, we have a base number defined as:tel:+49806190890the AA would not has an assigned unique number. Therefor it is necessary to do some amendments.You need to define theEXTattribute like this:tel:+49806190890;ext=1once 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=1We still have the second possibility, which is with assigned DIDs. This is straight forward as usual, so simply assign the AA:tel:+4980619089123;ext=123Phone Number ExtensionsAs 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 deployment2. DID based deployment in conjunction with extensions3. Deployment with internal extensions onlyRegarding 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 customers 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 ManagementContinue from here; in Lync, the phone number extension is identified with theEXTparameter.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' charactersAs 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 inSIP URIs is case sensitive, so too the phone-context.Best practice is:use always lower case characters!Other to consider are the includedhyphens -, which are allowed in SIP URIs. It makes it for humans more easily readable. (I personally dont like hyphens in Lync deployments!)Coming back to the phone numbers itself. As we identified the ext (extension) and phone-context parameter, theEXTis 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=+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=9123Lync Conferencing Dial-In behaviorsFirst 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 theDial-In into the Conferencing Main Number:If you dial into the conferencing number, regardless which region you chose, you will be prompted for aNumeric Conferencing ID. This ID is the reverse lookup if a valid conference is active or not.Second here is, after you are permitted into theConference General Room, its time to authenticate. Here we have two possibilities, either you are joining as aguestor you join as acorporateuser. 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 its now possible for a corporate user to identify himself to a conference?The optimal way here is the users 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 behaviorsMicrosoft 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.Lets make an example:example:tel:+49806190890;ext=123example: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 "company\user" -Pin 18723834Alternatively you can use another command sending a Welcome Email:Set-CsPinSendCAWelcomeMail -UserUri user@company.com -From conferencing@contoso.comWith the optionTemplatePath, you can use theCAWelcomeEmailTemplate.htmlwhich you can modify as your company requirements are.ISDN Protocol and Gateway based normalization (Called Party vs. Calling Party) and Caller IDLast but not least, I believe its 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 its called and seen on the PSTN Gateways:Calling Party (ME from whom),in LyncVoice Routesalso named in(Caller ID)in SIP messages its calledFrom:andCalled Party (YOU to whom)in SIP messages its calledTo: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=phoneSIP/2.0From: ;tag=4bdaa6a338;epid=fe5337abb5To: Analog to Lync, we need to have a look into the ISDN related message:callp: mux_isdn:0 (1) ISDN[1](1756): APP : 11 calling_name ="PThomas"-->"Ptt Thomas"callp: mux_isdn:0 (1) ISDN[1](1756): APP : 0 called_name =""-->""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:24849callp: 344874: callp: scRead(930): socket=26 ret=383callp: 344874: callp: scRead(930): socket=26 ret=704callp: 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 thecalledPartyNumberand thecallingPartyNumberhas changed. This is as described, because of the Call Direction.Additionally in the incoming call, I marked two lines ingreen, 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. Thats why we had to redirect the call and forwarded to the othercalledPartyNumber. In this deployment, users who only want to use Lync, have to forward there PBX based desk phone to the Lync extension.Dont get confused here, its 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 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 resolutionLync 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:+ The region code is normally an identifier within an area, ahead of thesubscriber number. Say we have the city of Munich, the area code of Munich is: 089, now ourregion codedepends 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 .Regardless of this principals, we do not need to care about this, maybe in USA or Malaysia its different, but since Europe has the phone number portability, we only care about the.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, its 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 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, we need theExternal 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 Aprefixcan be specified that signals an external number is being dialed Thisprefixwill not need to be in the normalization rules Internal Extension check box in the normalization rule works with theExternal Access Prefixto 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 numbersOff-hook / On-Hook DialingDialing 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.Lets 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 RecordsWithin 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.Whats all this about?Voice Route:ContainsMatching Pattern, thePSTN Gateway, AssociatedPSTN Usage RecordVoice Policy:ContainsCall Features, AssociatedPSTN Usage RecordPSTN Usage Record: isASSOCIATEDwith ->Voice PolicyandVoice RoutesRemember: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.Lets 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 theVoice Policy, so the Call Feature checking can be accomplished before the routing will be initiated. Assume the call shall be routed now, thePSTN Usage Recordcomes into the game.As theVoice Routeis always associated with thePSTN Usage Record, Lync knows where to go with this call. It is sub-sequential how thePSTN Usage Recordwill processed. It starts with its firstVoice Route. Within in theVoice Route, the matching pattern must be checked and only if it fits to the dialing string it will be processed, else the nextPSTN Usage Recordwill 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 IPs, where the call now will be handed over to. Also here are multipleGatewayspossible to be addressed. It is around robin procedurehow Lync place the call to the gateways.Here Lync 2013 is with it actual version supportingM:N Mediation Server and Gateway association. In ourVoice Route, we only have to define thePstnGatewayobject, 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 forAssociatedGatewayvs.Associated Trunks.This is simply said the same in theSet-CsVoiceRoutecommand, for both Lync Server Versions 2010/2013 it is thePstnGatewayListparameter.Lync 2013:

Lync 2010:

Lync Trunk Configuration (applied Normalization and Translation)Lets understand and talk about the Lync Trunk Configuration. Perhaps it confusing for some people what the difference is between aSIP Trunkand theTrunk 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 theTrunk Configurationcomes 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 its now clear, aTrunk Configurationis 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.Im not describing how to setup a Network Topology in Lync withPolicy Profiles, Regions, Sites, Subnets, Region LinksandSite Routes, which all are required to make aTrunk Configurationwork.

If all this is the case, why Im 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 its 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 ofTrunk Configurationwe need:Pool or Site(L10/L13)Pool (Site): assigned to aLync Sitedefined in the TopologySite (Service): a service, likePstnGatewayobject defined in the TopologyMaximum 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 notEnable Media Bypass (L10/L13): define if the Mediation Server can be bypassed by the PSTN connection point and the clientCentralized media processing (L10/L13): if the Gateway object supports an unique IP for signaling and 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 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 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 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 callCalling 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. calledThere 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 Im talking aboutDeep-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 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 means the Work Flow what it happened during an initiated Lync Call.We differentiate between theDialing Behaviors, theRouting 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 users phone number associated with an AD user. Sure its 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.