Extension Dialing with Polycom SIP Phones

April 28, 2012 by · 36 Comments 

In the previous article “Lync Integration with Polycom SIP Phones” the ability for native Lync registration was introduced for many of the standard SIP handsets with the firmware release version 4.0.1.  Recently a new firmware version of 4.0.2B was released containing some minor updates and hotfixes.  Included in this release was the ability to support extension dialing when registered to Lync Server.

Previous Behavior

In the previous 4.0.1 version a preceding ‘+’ was automatically added to all dialed numbers when the call was sent to the Lync Server, thus only the full E.164 number could be manually dialed.  For example to call a Lync user with a Line URI value of “tel:+13125557501” the user would need to dial ‘13125557501’ and then the phone would automatically add the + before sending the call, in which the SIP INVITE would appear like this on the Lync Server:

Start-Line: INVITE sip:+13125557501@mslync.net;user=phone;transport=tls SIP/2.0
From: "vvx1500" <sip:vvx1500@mslync.net>;tag=244EA9C6-BF641E55;epid=0004f2be8eb4
To: <sip:+13125557501@mslync.net;user=phone>
CSeq: 1 INVITE

This basic SIP Phone behavior would prevent non-E164 dial strings from working as if a extension was dialed (e.g. 7501) the resulting SIP INVITE would be formatted as an invalid number:

Start-Line: INVITE sip:+7501@mslync.net;user=phone;transport=tls SIP/2.0
From: "vvx1500" <sip:vvx1500@mslync.net>;tag=3D51BA91-C61AB03A;epid=0004f2be8eb4
To: <sip:+7501@mslync.net;user=phone>
CSeq: 1 INVITE

When Lync Server receives an inbound call from an endpoint or gateway and the + is included in the dial string the translation engine assumes that the string as already globally unique and will not perform any server-side normalization of the digits.  This is a hardcoded behavior that has been in the product since Enterprise Voice was introduced in OCS 2007.

The following information comes from logging the TranslationApplication component in the Lync Server 2010 Logging Tool during a call and shows Lync Server identifying the number as ‘global’ and then passes it on as-is.

INVITE, reqUri=sip:+7501@mslync.net;user=phone;transport=tls newHostPart=NULL
Global number, no further processing. RequestUri=sip:+7501@mslync.net;user=phone;transport=tls
Retargeting [ReqUri=sip:+7501@mslync.net;user=phone;transport=tls]

Clearly this call would fail as the targeted user’s Line URI is not +7501, but +1312557501.

Updated Behavior

In the 4.0.2 release the ‘+’ is no longer added by default, yet omitting the plus alone is not enough to provide for successful call routing for partial digit strings.  The call will need to specify the desired Lync dial plan in the SIP INVITE so the server knows which set of normalization rules to apply to the call.  Some Lync deployments may only include these normalization rules in the default Global dial plan while other deployments may contain multiple dial plans for different pools, sites, or users.

For example, if the plus is left off the dialed string on an incoming call but a dial plan is not assigned then the call will fail to be completed since the retargeted URI will not match the user’s defined Line URI.

INVITE, reqUri=sip:7501@mslync.net;user=phone;transport=tls newHostPart=NULL
Missing phone-context, no further processing.  RequestUri=sip:7501@mslync.net;user=phone;transport=tls
Retargeting [ReqUri=sip:7501@mslync.net;user=phone;transport=tls]

Thus the desired dial plan needs to be included in the invitation so the Translation engine knows which normalization rules to apply the call’s digit string to.  In this example the URI has been properly formatted to tell the Lync Server to use the default dial plan’s normalization rules to the call, which includes a rule named “Extension Dialing” to translate 4-digit extensions starting with 75 or 77 into a full RFC3966-compliant number.

INVITE, reqUri=sip:7501;phone-context=defaultprofile@mslync.net;user=phone;transport=tls newHostPart=NULL
calledNumber=’7501′
added attribute DefaultProfile, key 0

regex: ^(7[5,7]\d{2})$
regex: ^(7[5,7]\d{2})$, prefix 7, num leading zeroes 0
added regex ^(7[5,7]\d{2})$ to list with prefixes
ruleName=’Extension Dialing’ matched Num=’7501′, txNum=’+13125557501′
MATCH: New request Uri=’sip:+13125557501@mslync.net;user=phone;transport=tls’
Retargeting [ReqUri=sip:+13125557501@mslync.net;user=phone;transport=tls]

Configuration

To provide the above dialing behavior to Polycom SIP phones running the 4.0.2B release an additional configuration parameter needs to be defined. This custom mapping rule will be used to send all digits dialed on the phone exactly as dialed along with the name of the desired Lync dial plan so that server-side normalization can be utilized.

Identify Lync Dial Plan

Because these phones are able to register to multiple SIP platforms at one time the default digit mapping behavior of the device should not modified specifically for Lync interoperability as that could impact dialing to an existing registration to other non-Microsoft SIP platforms.  Instead a line-specific parameter should be defined to be used specifically for the Lync Server registration.  But before the configuration parameter is added the desired Lync dial plan must be identified.

  • From the Lync Server Management Shell issue the Get-CsDialPlan cmdlet to list any and all defined dial plans in the topology.

PS C:\> Get-CsDialPlan

Identity                 : Global
Description              :
DialinConferencingRegion : Chicago
NormalizationRules       : {Description=;Pattern=^(7[5,7]\d{2})$;Translation=+1
                           312555$1;Name=Extension Dialing;IsInternalExtension=
                           False, Description=Prepend Area Code to 555 prefix;P
                           attern=^(555\d{4})$;Translation=+1312$1;Name=Prefix
                           Dialing;IsInternalExtension=False, Description=Norma
                           lize 10 and 11 digit number strings;Pattern=^\+?1?(\
                           d{10})$;Translation=+1$1;Name=Basic;IsInternalExtens
                           ion=False}
CountryCode              :
State                    :
City                     :
ExternalAccessPrefix     :
SimpleName               :
DefaultProfile
OptimizeDeviceDialing    : False

  • Alternatively the Lync Server Control Panel can also be used by navigating to the Voice Routing > Dial Plan section.

image

The result above show a single defined dial plan listed which happens to be the Global default dial plan.  The majority of deployment may still utilize this built-in dial plan.  Review the various NormalizationRules to identity the desired dial plan in the event that multiple dial plans are defined in the environment.

  • Once the desired dial plan is selected then identify the SimpleName attribute as this is the name which must be included as the phone-context value in the invite, not the common name shown as the Identity.  The default Global dial plan’s Simple name will always be DefaultProfile.

Identity : Global
SimpleName : DefaultProfile

image

Update Device Configuration

In this example a per-device configuration file which matches the guidance originally detailed in this previous article is used along with XML Notepad 2007 to facilitate easy manipulation of the XML-based configuration files.

  • Whether using FTP provisioning or manually importing configuration files into the devices locate the source configuration file (e.g. lync.cfg) and add an additional parameter in the format of dialplan.x.digitmap where x is the number of the line registered to the Lync server. (If unsure look at the number in the existing configuration file used in the reg.x.address parameter and use the same line number; typically it will just be line ‘1’.)

dialplan.1.digitmap

  • For the value of the new attribute the following string must be entered in identical to the example, paying close attention to character case as the digit mapping fields in the Polycom phones use uppercase characters to perform translation actions.  Only the Lync dial plan’s Simple Name should be altered in the event that the default dial plan is not desired; make sure to not omit the ‘R’ character at the end of the pattern.

x.TRR;phone-context=defaultprofileR

Basically this rule will send all dialed digits (x) to the phone without any manipulation and then append any characters located between the ‘RR’ and ‘R’ characters, which happens to be the string “;phone-context=<Dial Plan Simple Name>

Using either Notepad or an XML editor update the configuration file with the new parameter and import the new file or trigger FTP provisioned devices to update their configuration (or wait for an automatic refresh).

dialplan.1.digitmap="x.TRR;phone-context=defaultprofileR"

image

Notice

This approach of manually configuring the digit mapping parameter is specifically for the 4.0.2 release.  This will not be required in the next software release as client-side number normalization will be handled automatically and natively, displaying the same behavior as the Lync Phone Edition client currently does by consuming the normalization rules from the assigned dial plan via in-band provisioning of Lync policies.

About Jeff Schertz
Site Administrator

Comments

36 Responses to “Extension Dialing with Polycom SIP Phones”
  1. Bill D says:

    This still doesnt work for me but I dont know what is causing my issue. I just get a busy tone no matter what number I dial from the Spectralink.

    It could be a number of issues but Lync calls work fine and people can dial to me I just can't dial out. I have looked in the digit map on the handset web interface and its setup for US calling, do I need to alter this as well or is this ignored in a Lync setup? Everything else works, presence, Lync calls, incoming calls….just not outgoing 🙁

    When is 4.0.3 coming to fix this mess!

    • jeffschertz says:

      Try capturing both a trace of both the SIPstack and TranslationApplication components to see what the dialstring actually looks like. Also make sure you are NOT using any uppercase characters in the dial plan name!!! I cannot stress this enough as I've seen this mistake multiple times already. Do not use 'DialPlanName' but instead use 'dialplanname' in the configuration setting. The case does not have to match what the Lync Dial Plan names shows, but the phone will recognize uppercase characters in the dialplan string as triggers for mapping actions.

      • Bill D says:

        This is interesting. I am getting the following error dialling a local number (my house in fact!): "The user is not authorized to call the specified number", in the dialplan.1.digitmap field I have specified x.TRR;phone-context=mainR as the dialplan as you detailed above. Still no joy, there are two dialplan on the server but my account is set against the one used in the dialplan field as mentioned above the other one has no normalisation rules and is not used, that is global.

        I have done a quick Google and various posts mention normalizing by hand i.e. dialplan.1.digitmap="RR+R[2-9]11|0T|RR+R011xxx.T|RR+R[0-1][2-9]xxxxxxxxx|RR+1R[2-9]xxxxxxxxx|RR+R[2-9]xxxT|RR+1702777R6xxx" but this goes against this blog entry. What is the best way forward with this error?

        • jeffschertz says:

          Bill, the other directions you are seeing is a way to revert the 4.0.2 release's behavior back to the previous 4.0.1 behavior in terms of '+' inclusion. If you use that sample digitmap instead then the phone will place calls in the same way it did in 4.0.1, requiring the user to enter the full number. The phone will then add the + and the call should work through Lync without any server-side normalization. But if you want to support extension dialing then the approach in this article is preferred. This have nto been widely tested and is only provided as a short-term workaround prior to the next release which will address all this in-band.

  2. willi says:

    Just discovered a limitation in dial plan naming used. If the simple name of the dial plan contains dots (mycustomdialplan.local) the digit map doesn't aplly and the invite is send out like there is no such setting:

    INVITE sip:01234567@customer.com;user=phone;transport=tls SIP/2.0

    The workaround is to use a simple name without dot separators.

    • jeffschertz says:

      Correct, any characters used in the Dial Plan name other than loewrcase letters can cause undesired results as the device will see those characters are mapping triggers and not part of the dial plan name. You can try using the short name (e.g. dialplanxyz) instead of the FQDN (e.g. dialplanxyz.domain.com)

      • willi says:

        tested adding dialplan without dot. no success Lync TranslationApllication states Profile='customer' not found (or invalid) and rejects the call. looking forward to next release where this going to be solved hopefully.

        • jeffschertz says:

          You may need to rename the Simple Names of the dialplan for compatibility in 4.0.2. Either way, as I stated, this is moot in the upcoming release as the device will natively use the normalization patterns handed down by the Lync server during in-band provisioning.

  3. bradley says:

    Received the following error using Polycom SPIP550 with 4.0.2b:
    Request:INVITEResponse:403
    Diagnostic ID:12004Category:Expected
    Component:VoIP Outbound Routing: Front End Server
    Reason:
    The user is not authorized to call the specified number.
    Description:
    Administrators should check the user's voice policy and add a route with a usage that matches the dialed number.

    When we changed the SPIP550 configuration file to point to the Lync 'defaultprofile' in the dialplan.1.digitmap the phone routed properly to the audiocodes outbound to the PSTN.

  4. willi says:

    Hi Jeff, some time ago you stated the issue will be adressed the phone doesn't send it's PreferredIdentity in a right way. Even with the 4.02B firmware I don't see correct value like they comes from Lync client: P-Preferred-Identity: <sip:givenname.sn@customer.com>, <tel:+12345678910>. A there some news on it? Thank you.

    • jeffschertz says:

      Willi, I was referring to a major release. The additional functionality provided by 4.0.2 was not a resolution but more of a workaround based on changes (removal of the +) performed on the release in general. All Lync-specific development has gone into the upcoming release and this workaround will be completely unnecessary.

  5. bueschu says:

    Hi Jeff
    Thanks for your support. Without I could not configure the polycom spectra link handset 8450 with lync.
    I apprecaite your blogs.
    Best regard – bueschu

  6. Rob says:

    I've applied this workaround and everything works except calls to my AutoAttendant or System Attendant – it looks as though the call has connected, but I hear no audio… the only thing i can find in my phone log is: 0619095322|net |4|03|rtosNetwork: netwTask() – Can't find associated CCB.

    Any ideas?

  7. Faisal says:

    Hi Jeff,

    Your solution worked f orme, hpowever the phone shows "To 1112;phone-context=defaultprofile
    Ïnsted of showing the user name it shows ""extension and phone-context=defaultprofile""

    • jeffschertz says:

      This is normal; the next software release will address this and show the caller's name instead.

  8. Shahim says:

    hi Jeff

    i gone through and modified , now i can make call from endpoint but number is showing our borad number , i can recive my same directline , second thing i cannot make call inside extension , i have to dial full number other ways will not work .the phone shows “To 1112;phone-context=defaultprofile

    Ïnsted of showing the user name it shows “”extension and phone-context=defaultprofile””

    By

    Shahim

    • jeffschertz says:

      This workaround does not address all dialing solution, but the upcoming release should work as it will use the same process that Lync Phone Edition uses for normalization.

  9. Tobi says:

    Hi Jeff,
    you are talking about an upcoming software release in few articles / posts. Is there a date for the release of this major update? We are looking forward to this update for our 30 spectralinks 8440 in our lync-only environment. 🙂
    Best regards – Tobi.

    • jeffschertz says:

      Tobi, the release date has not been publicly announced yet, but it won't be much longer. I can say I've been walking around my house with an 8450 running pre-release code, registered to our corporate Edge Server and using it for my day-to-day Lync Enterprise Voice calls. The sound quality is incredible on these devices 🙂

  10. Robert G says:

    Jeff,

    Do you know if there is anyway on the vvx500s running 4.0.2 code to change the transfer button to do a cold transfer and not a consultive transfer. I was thinking about giving them to my front desk since the CX600s are so slow at dealing with Response group calls but they only do blind transfers.

    Thanks

  11. hi Jeff Long Lief to You Brother.most of time my Searches about Polycom and most of UC Searches Come to your Website.i'v started to Notify our Blog as a Reference for UC and i'm Sure other Guys are taking So much Benefits on these Guides you Provide.
    this Guide really helped me to Find out the Flow of One way dialing Issue by Polycom Sound Point.but i am not able to resolve it completely.
    the Problem is i have Cross Servies Like Asterisk and CUCM and thos Numbers don't go to Standard Format.for Example range of CUCM extensions are 4xx and just added to dial plan as they are then Routed to CUCM trunk.same for Asterisk .and so the problem here comes.when the Default Behaviour of sound point with 4.0.1 is addition of '+' .so i want to knwo is there any way to change the Default behaviour or i have to Upgrade 100 Phones ? the other thin i am dealing with is the Pattern i want to use when i want to call PSTn numbers. we have 4,5,6,7 and 8 digit PSTn numbers and for now i have configured these Patterns one by one with number of X that needed for every Pattern.is there any Pattern that matches 4 and more of this type ?
    Regards

    • jeffschertz says:

      The upcoming software release will address this by performing number normalization in the same way that Lync clients do.

  12. Andrew Shotton says:

    Jeff polycom release firmware 4.0.3 on October 11th.

    I have applied it to my IP5000, the line registers, I can call the extension, I can call people on my buddy list, but I can use 4 or 10 digit dialing I just get a busy signal.

    Can you confirm if the fixed the Digimap setting for Lync in this version of the firmware?

    • jeffschertz says:

      Andrew, the 4.0.3 software is only a maintenance release with hotfixes for the 4.0 version, most of which (if not all) are not Lync related. The upcoming Lync Qualified release is actually 4.1 and that version will address the dialing issues by using the in-band dial plans automatically.

      • Andrew Shotton says:

        Thanks for the update, so for 4.0.3 should we be using the same Digimap solution provided in this article or has it changed again.

        I am at a lost to get the polycom SIP phones working with Lync, I guess the simplest solution would be to wait until 4.1 comes out, do you know an approximate ETA on this?

        • jeffschertz says:

          Yes, the 4.0 was not meant for production deployments against Lync, while the Qualified 4.1 release is. It should be generally available very soon.

  13. Philip Messina says:

    Jeff – first off, your blogs have been a huge help in our migration to Lync Enterprise Voice. Cannot thank you enough. We are nearly complete, 911 rules and our conference room phones are the last hurdles. We are using Polycom Soundstation IP 6000's with 4.0.3 UC. Test calls from Lync clients and external are working great. However, I am getting a fast busy when trying to dial a 4 digit internal extension. I think the phone is using the config digitmap fine, but not Lync server normalization rules (if it even can). dialplan.1.digitmap="RR+R[2-9]11|0T|RR+R011xxx.T|RR+R[0-1][2-9]xxxxxxxxx|RR+R[2-9]xxxxxxxxx|RR+R[2-9]xxxT". Any help would be appreciated. Thank you.

    • jeffschertz says:

      Philip, the SoundStation IP 6000 is not a Lync-supported device. Although the 4.0.3 software does allow you to connect to Lync as it shares the same code as other supported devices we have not tested, nor support the 6000/7000 conference phones. You need to use either the newer 5000 or Duo with the newer, qualified 4.1 release to provide native digitmap integration with the Lync Dial Plan Normalization Rules.

  14. Philip Messina says:

    Thanks Jeff. We did get the 6000 model to work and making internal and outbound calls. The issue was the server dial plan name at an _ in it. Now the phone is using the correct lync server dial plan. Next problem is the Lync conference bridge. It connects to the bridge as a 'leader' but no audio, and then disconnects after 10 seconds or so. I saw a mention somewhere from polycom that the lync bridge is an issue for polycom. Do you know of any workarounds or if the other models work ok with Lync conference bridge (5000 or Duo)?

    • jeffschertz says:

      The SSIP 5000 and Duo handsets support the qualified 4.1.x builds so these scenarios will work with all the qualified devices. The SSIP 6000/7000 firmware does not contains any of these updates.

  15. Philip Messina says:

    You're the man, thanks Jeff.

  16. Thoyne says:

    jeff i really appreciate you my Polycom standpoint 321 is still displaying sip after following your documentation. what can i do to make the phones communicate

  17. Bill says:

    Jeff,
    We are currently running 4.1.0I on our IP 321s. I get them registered to Lync 2013, but if I use the digitmap as you explained above I cannot dial out from the phone. If I use the following "[1-9][1-8]xx|0T|011xxx.T|[0-1][2-9]xxxxxxxxx|[2-9]xxxxxxxxx|[1-9]xxxT" I can dial any lync client with their 4 digit extension as well as any PSTN device. I cannot however receive any calls to the IP321. I see the following error on the logs for the 321
    0717122711|ice |4|03|ICE Bandwidth check result: insufficient bandwidth for the call reported
    0717122711|so |4|03|SoMediaSessEvLclAnswerSdpAvailable in Offering state – call disconnect due to failed ICE bandwidth check
    Also please note that we are in coexistence with OCS 2007 R2.

    • jeffschertz says:

      Bill, this guidance is for 4.0.x firmware only. In the newer 4.1.x releases this is no longer applicable as the dial plan is handled differently, and more correctly in the Lync Qualified versions.

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!