Polycom VVX gives SIP480 – Can’t be Called

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.
VVX-Available VVX-Unavailable-crop


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:greig@contoso.com>;tag=339a428288;epid=e20f883a06 
To: <sip:testc@contoso.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="testc@contoso.com"; 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).

Version Number Description Affected?
5.0.1.x All releases (?) No
5.0.2.2185 Initial public release of 5.0.2 Yes
5.0.2.2756 Heartbleed fix version of 5.0.2 Yes
5.0.2.2964 Hotpatch for this bug No
5.1.0.15902 Controlled 5.1 release Yes
5.1.1.2320 Public 5.1.1 release No
5.1.1.2986 Public 5.1.1 release No

 
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.

 

– G.

[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].

Leave a Reply

Your email address will not be published. Required fields are marked *

... and please just confirm for me that you're not a bot first: Time limit is exhausted. Please reload the CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.