Firmware 1.0.20.17 for UCM6202/6204/6208/6510 is released as official

firmware-release

#1

Dear Grandstream Customers,

Firmware 1.0.20.17 for UCM6204/6204/6208/6510 is released as official. Here is the link for the release notes:
http://firmware.grandstream.com/Release_Note_UCM6xxx_1.0.20.17.pdf

The firmware information and release notes can be downloaded from:
http://www.grandstream.com/support/firmware

Please contact us should you have any issues. Thank you for your support for Grandstream products.

Technical Support
Grandstream Networks, Inc.


#2

#3

Love the ability to have multiple inbound mode options now.


#4

I appreciate it too, it remains in my opinion to make the same service on the BLF buttons for multiple mode, to date only red/green.


#5

While there are some lovely new features I found it broke numerous things on my boxes and I had to roll back. LDAP sync between peered UCM’s just went sideways and no amount of fiddling with settings would make it work again. I also hit a very weird “dead air” issue with calls between peered UCM’s when calls made to an unregistered extension (one one UCM only, a 6208). Hoping to get these issues sorted out as I really like a number of the new features.


#6

Also had clients complaining of call dropouts today. Any body else have this?


#7

I’m increasingly convinced that there are serious problems on 20


#8

The “dead air” issue that I mentioned is NOT, repeat NOT caused by this F/W release! I had a bad configuration. Sorry if I mislead anyone with my comments.


#9

I am having issues when upgrading to 1.0.20.17 on my UCM6510. It appears that all of my pcodes on my 2170 model templates disappear after I save a 2170 model template, exit and go back to the template.

I have reported this issue already, but was not certain if anyone else had this issue too ?


#10

Firmware broke OpenVPN client connection from UCM. UCM connects fine on firmware 19 but once I upgraded to 20 it will no longer connect. Downgraded back to 19 and VPN connects again.


#11

Having a major breaking issue with 1.0.20.17; none of my Grandstream IP phones can receive a zero configuration profile when the UCM is running his new firmware. As a result, they all slowly fall off of the network as they try to renew their zero config profiles.

Had to revert to the 1.0.19.x series (and restore last weeks backup) to get the system up and running again.

Any ideas for ways to troubleshoot this?


#12

The answer may be a yes. It depends. In my instances (yes, numerous), I have lost the pcode settings for a given model. It usually starts as an edit to a model template and then you do a save. The initial save message is success in green at the top of the screen immediately followed by a red error message.

When this occurs, you can usually go to the operation log and you will see an entry of delete all custom configurations for template X. If you then look at the template following the loss, you may see a -1 in place of the VPMK name function type (line, forward, call park, BLF, etc.).

if you have the same issue(s) as described above, then DO NOT MAKE ANY EDITS TO ANY OTHER TEMPLATES. These will likely also become compromised.

I have reported this 4 different times to no avail and no response as to how it occurred, how might I have caused it and what can I do to prevent it and more to the point, where is the delete all custom config button so clearly listed in the op log as I certainly don’t want to press that again.

The claim is that the config database is corrupted and the only way to recover is a full factory reset and restore or manual rebuild. When it first occurred, I did not recognize it for what it was and the kicker is that if you do backups on a scheduled basis, the issue may be in the backup. Only as I had a few more UCMs do this did I become wiser about the situation.

I have since given up on a resolution and no answers or suggestions were forthcoming…sorry to say as I kept submitting tickets and not getting anywhere. Some of the systems were quite new, so I do not believe it should have been a non-volatile memory issue, but maybe.


#13

Do you happen to have any special characters in the pcodes you have defined? There was a bug in a previous ucm firmware that wasn’t parsing the pcode values properly, and caused use some major headaches.