A recent update to the Polycom VVX firmware for Lync has introduced a strange bug.
If a phone running the affected version of firmware is used to log into a BRAND NEW new Lync account (i.e. a normal user account or a Common Area Phone), the phone appears to stamp some invalid call forwarding data into the user database and render the account permanently unable to be called. Whilst you’ll be able to call out FROM the affected phone and others will be able to see its presence, you won’t be able to make a call to it:
|Yes, it’s available…
|… until you try and call it.
Those who call the Common Area phone in my example (whether directly from a Lync client or externally via a PSTN Gateway) receive the the following: a SIP 480 and “The routing rules did not result in a final response and callee is not enabled for Unified Messaging”.
Start-Line: SIP/2.0 480 Temporarily Unavailable From: "Greig"<sip:firstname.lastname@example.org>;tag=339a428288;epid=e20f883a06 To: <sip:email@example.com>;tag=44C2BAF9E9062DB7FA948C36549A03BA Call-ID: 4dd4adb948414e69b8e6f605064ff2d2 CSeq: 1 INVITE Via: SIP/2.0/TLS 192.168.19.178:58866;ms-received-port=58866;ms-received-cid=15B4E00 Content-Length: 0 ms-diagnostics: 13014;reason="The routing rules did not result in a final response and callee is not enabled for Unified Messaging"; source="LYNC2013SE.contoso.com"; Callee="firstname.lastname@example.org"; appName="InboundRouting"
Once you’ve broken a Common Area account like this, the only fix appears to be to delete and rebuild it, performing the initial login with either a CX/LPE device, or a VVX running an unaffected version of firmware. Once the initial login has taken place the account will be immune to this problem and you can safely now use a VVX running an affected version of firmware.
For a normal user account you can get away with deleting it from Lync and re-adding, then initialise as above, maybe using the PC Client. (I tried bouncing to another pool and back, or toggling to a non-EV state and back, but none worked).
|All releases (?)
|Initial public release of 5.0.2
|Heartbleed fix version of 5.0.2
|Hotpatch for this bug
|Controlled 5.1 release
|Public 5.1.1 release
|Public 5.1.1 release
Thanks to Bill L, the MCM and MVP communities & Polycom Support for their collective help finding this bug and sharing the details of the fix.
[The table in this post has been edited since its initial publication to more accurately describe the different releases, and added in the 5.1.1 releases].