• ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
  • ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
Guidelines
The HP Community is where owners of HP products, like you, volunteer to help each other find solutions.
HP Recommended

*sigh* ... I think I just ran into another major show-stopper bug in recent UC software.  I just wrote the following, intending to submit it to my reseller to in turn open yet another ticket with Polycom, but on the off-chance that there is a known workaround to these issues OR that I have been misusing/abusing this feature all along and it just happened to work the way I want it to work in older versions of the UC software, I'm throwing this out here to see if anybody can tell me what I might be doing wrong:

 

---

 

As of UC 4.0.4, there appear to be some serious regressions related to the User Profiles feature (the one described in Feature Profile 60688: http://support.polycom.com/global/documents/support/technical/products/voice/Making_Phone_Settings_P...).  We have been using this feature quite successfully with UC 4.0.2B, but after we upgraded our phones to 4.0.5, many of our phones encountered issues with this feature.  We then tried downgrading one software version at a time, and found that UC 4.0.3F worked correctly, and 4.0.4 behaved the same way that 4.0.5 does, so it would appear that the problems were introduced in 4.0.4.

Here is a description of our environment and how we are using this feature:

We have a mix of SoundPoint IP 335, 450, and 650 phones.  They all connect to an Asterisk PBX (running version 1.8.15.0), and are provisioned via HTTP.  The provisioning files are generated from templates dynamically at run-time by Asterisk's res_phoneprov module.  The HTTP server built into res_phoneprov does not support the HTTP PUT verb, so the phones are unable to upload configuration and directory changes back to the provisioning server, but we actually prefer to centrally control the configuration and directories anyway, so this is not a problem for us.

Asterisk's res_phoneprov publishes a global directory to be pushed to all phones by regenerating 000000000000-directory.xml for us whenever an extension on the system is added, deleted, or changed.  Because we want the directory published by the PBX to be authoritative, we have enabled both "dir.local.volatile" and "dir.local.readonly" (both set to "1") in the phone configuration.  We realize that this means that the directory will only be updated on a phone-by-phone basis whenever a phone is rebooted, but this is sufficient for our needs.

In addition, every phone in the organization has user profiles enabled, and it is mandatory that people log into their phones in order to use them ("prov.login.enabled", "prov.login.required" both set to "1").  Many people within the organization have their own phone at their own desk and do not move around, so for their convenience, we also have persistent login across reboots enabled ("prov.login.persistent" set to "1").  The global configuration that is pushed to each phone specifies a common "reg.1.address" that the phones all register themselves to Asterisk with before a user has logged into their own profile, and this "common" account allows for emergency calls (911) only.  The user profile configuration file overrides the reg.1.address with that user's particular SIP username upon successful login to their profile, and the phone re-registers to Asterisk as the correct user.

Here is how the file layout looks on the provisioning server from the perspective of the phones:

000000000000.cfg -- global configuration file: contains all common phone configuration options, including the "emergency calls only" SIP account registration details ('reg.1.address' et al.), the directory configuration details mentioned previously ('dir.local.volatile="1"', 'dir.local.readonly="1"'), the options to enable user profiles ('prov.login.enabled="1"', 'prov.login.required="1"', 'prov.login.persistent="1"'), among others.

<user>.cfg -- the per-user user profile configuration files, where <user> is the username for a given user profile.  These contain ONLY the "prov.login.localPassword" option in them, to set the login password for that particular user.

<user>-phone.cfg -- the per-user user-specific settings files, where <user> is the username for a given user profile.  We stuffed the SIP account registration details ('reg.1.address', 'reg.1.auth.password', etc.) for each user into these files.

Now for descriptions of the problems:

Strangely enough, so far this appears to only affect our SoundPoint 335 phones...the 450 and 650 phones still work fine.  But as of 4.0.4, if any of our 335s are rebooted while they are at the User Login screen, then there are two issues we see, and it wouldn't surprise me if they are related somehow at the code level:

PROBLEM #1: Reboot loop
---

When the phone boots up, it will reach the login screen, and then shortly afterward, reboot itself.  It will then get stuck in a reboot loop where every time it boots back up and reaches the login screen, it will continue to reboot itself, over and over again.  If you happen to have fast enough fingers and try to log into the phone before the reboot happens, the login attempt will fail.  This appears to be because the phone does not have network connectivity yet (hasn't gotten an IP via DHCP, or whatever).  A split second after the network comes up on the phone is when the reboot happens, so once it finally is reachable on the network, you won't have enough time to try another login attempt again.

If you configure logging to syslog in the bootROM and watch the logs that get written to your syslog server by the phone, you will see this every time, just before it reboots:

    Dir|CfgDirectoryC: Read-only contact directory has been changed.
    Manual Restart


And that, presumably, is the reason that the phone decides to restart itself.  And sure enough, if I remove 'dir.local.readonly="1"' from the global configuration profile, the reboot loop on the phone stops.  But this was never a problem before on older versions of the firmware.

There is a second way to break the reboot loop while leaving 'dir.local.readonly="1"' in the config: when you power the phone up, interrupt the application loading process and wait for the network to come up while the phone has yet to progress past the bootROM.  If the network comes up before the sip.ld application loads and runs, then the phone will not reboot itself.  Instead, this is the last thing that gets logged to syslog, and the phone happily sits at the User Login screen, waiting for input:

    uBLFCompressed: File /rfs0/local/local-directory_xml.zzz does not exist or is empty


PROBLEM #2: Incomplete user profile applied
---

If you power down the phone when it is not logged in (and thus "prov.login.persistent" does not apply), power it back up, and manage to get past the reboot looping problem described above with either method (forcing network to initialize in the bootROM, before application load; or setting "dir.local.readonly" to "0"), you will still encounter another issue: when you log into a user profile, the phone will tell you that the login credentials were valid, and bring you to the main phone screen, BUT none of the settings from your user profile (which we store in <user>-phone.cfg) will be applied!  Instead of showing you your own extension on the line keys ("reg.1.label"), it instead shows you the label for the general, emergency-only extension that is defined in the global configuration (000000000000.cfg).

But it's even worse than that: the phone acts like even though you have passed authentication and successfully logged into a user profile on the one hand by allowing you to bypass the User Login screen, on the other hand, it also acts like you haven't fulfilled the login requirement ('prov.login.required="1"'): there are NO soft-button labels displayed at the bottom of the screen.  Pressing the soft buttons gets you nowhere as they are non-responsive.  You cannot make a call: making the handset go off-hook, hitting the speakerphone button, and pressing the headset button are all ignored.  In our case, pressing the line keys simply results in the message "URL call is disabled" because we have 'feature.urlDialing.enabled="0"' set.  In fact, it would appear that the phone is not even registered to the PBX/SIP server, which I was able to confirm by querying Asterisk directly.

In fact, it turns out that even before you try logging in, while the phone is at the User Login screen, IT DOES NOT REGISTER TO THE PBX using the credentials for the "emergency" extension supplied in the global config.  So while the phone is in a logged-off state, it is not possible to make an emergency call.

There is a (inconvenient) workaround: once you manage to bypass the reboot loop, and log into the phone, if you have "prov.login.persistent" enabled/set to "1", and if you reboot the phone without logging off, then when it boots back up, you will discover that you are properly logged into the profile that you tried logging into before the reboot.  In fact, at this point, you can log off of that user profile and log back into that same user profile or a different user profile, and everything will work just fine, the way you would expect it to.  Even better, when you log off the phone, when it is at the User Login screen, it will actually be correctly registered to the PBX using the credentials supplied to it in the global config.  If you reboot the phone after logging off, though, or if you clear the cached login credentials (Menu -> 3 -> 2 -> 1 -> 5 -> 6) and then reboot, then you will experience all of these same problems all over again: the phone won't register itself to the PBX when it is not logged in, and logging in will pass authentication but will not apply the user profile settings to the phone.

The expected behavior, of course, is that if the phone is rebooted when it is logged off, and boots up without any cached login credentials stored in memory, then while it is sitting at the User Login screen, it should be registered to the PBX using the credentials supplied in the global config, should allow users to make an emergency call in this state, and once a user has successfully logged in, should apply all of the settings from user profile in question to the phone during that session and register to the PBX using the credentials supplied in the user profile config.  This works as expected in 4.0.2B and 4.0.3F.

 

-- Nathan

1 ACCEPTED SOLUTION

Accepted Solutions
HP Recommended

I am pleased to announce that this issue has been completely resolved in the UC 4.0.7 software released today (issue #s VOIP-93136 and VOIP-93137).

 

My thanks to Polycom for delivering a fix.

 

-- Nathan

View solution in original post

5 REPLIES 5
HP Recommended

Hello Nathan,

UCS 4.0.6 is just around the corner so you may want to hold back with any tickets as if this was broken and had been reported to Polycom support may be already fixed.

 

In regards of using a local directory please verify the comment from the UCS admin Guide:

 

Polycom provides a local contact directory template file named 00000000000-directory~.xml that you can edit and use as a contact directory. This template file is loaded to the provisioning server the first time you boot the phones with the UC Software. On each consecutive reboot, the phone will look for its own <MACaddress>-directory.xml.

 

The above is as is as far as I can remember back supporting these phones,

 

A better design for a central phonebook would be LDAP which no longer requires a license and is easy to keep up to date.


Your post is quite detailed but would require complete set of logs and wireshark traces for our support team to be looked at.


Best Regards

Steffen Baier

Polycom Global Services

------------------------------------------------
Notice: I am an HP Poly employee but all replies within the community are done as a volunteer outside of my day role. This community forum is not an official HP Poly support resource, thus responses from HP Poly employees, partners, and customers alike are best-effort in attempts to share learned knowledge.
If you need immediate and/or official assistance for former Poly\Plantronics\Polycom please open a service ticket through your support channels
For HP products please check HP Support.

Please also ensure you always check the General VoIP , Video Endpoint , UC Platform (Microsoft) , PSTN
HP Recommended

Steffen,

 

I already stumbled across 4.0.6.0711 which you guys have already published...there is a link to download it from the VVX software matrix page, but not, for some reason, from either the SoundPoint IP software matrix or the UC software release page, even though the download bundles linked to from the VVX page clearly include application images for the currently supported SoundPoint IP model range.

 

Unfortunately, 4.0.6.0711 doesn't fix either this user profile bug, or the BLF memory leak bug.  I just finished testing both scenarios.  So it looks like we are going to have to wait -- at a minimum -- for another entire software release cycle to complete before our problems will be fixed.

 

As far as your comments about the local directory go, first, I agree that LDAP would be a superior solution, and now that it is license-free we are aiming to eventually implement it, but right now the solution we have been using works fine for us since our organization (and thus our phone extensions) does not change all that often, and frankly we have bigger fish to fry first.  What we have been doing has worked perfectly fine for us up until UC 4.0.4, and even works in UC 4.0.4 as long as you jump through all of the hoops I describe...you just need to make sure that you never, ever, ever reboot a SPIP335 phone while it's logged off.

 

And as far as your quote from the UC admin guide goes, it is accurate, unless you specify 'dir.local.volatile="1"' in your config, in which case the phones will re-download the global 000000000000-directory.xml on every boot, and not just the first one.  This is what we are doing.  (Interestingly, I note that no version of the UC admin guide references the "dir.local.volatile" option.  I am not sure how I became aware of it, though I have been using it successfully on UC 4.0.x for months.)

 

I understand that despite the detailed nature of my report that Polycom Support would still require logs and such.  I have actually gone the extra mile, and have put together a VMware image that holds an entire self-contained lab environment consisting of Asterisk, a provisioning server and complete set of configuration files that mimic our production environment, and some test scripts.  This way, you guys can see for yourself exactly what I'm talking about and reproduce it on your own phones with minimal fuss, inside of a few minutes.  You boot it up, plug a virgin phone into the same network, and off you go.  I initially put it together to demonstrate the BLF memory leak bug and offered it to Polycom at that time, but the rep assigned to our case has yet to let us know how he would like us to get the image to you guys.

 

Thanks,

 

-- Nathan

HP Recommended

Ticket #1-504543471.

 

-- Nathan

HP Recommended

Ticket has been escalated to Tier 3.

 

-- Nathan

HP Recommended

I am pleased to announce that this issue has been completely resolved in the UC 4.0.7 software released today (issue #s VOIP-93136 and VOIP-93137).

 

My thanks to Polycom for delivering a fix.

 

-- Nathan

† The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the <a href="https://www8.hp.com/us/en/terms-of-use.html" class="udrlinesmall">Terms of Use</a> and <a href="/t5/custom/page/page-id/hp.rulespage" class="udrlinesmall"> Rules of Participation</a>.