Help get this topic noticed by sharing it on Twitter, Facebook, or email.
I’m flag I finally updated

I upgraded to VN5 and you should too (my story)

I waited... and waited... and waited for the right time.. and finally VN5 was ready for us to go to production. Obviously anyone that's done any major update with VN knows that it definitely requires good technical support and service to complete the process and iron out any kinks.

Personally, we always hire 4psa engineers to perform our upgrades. Always best to have the source of the application development to facilitate the actual upgrade process. Especially when ti comes to ironing out kinks.

We had a ticket opened for 30 days prior to the upgrade actually being started.

There were consideration for elastic search and we have a incredibly huge CDR history that we maintain. So the upgrade had to be coordinated. Do not take it lightly!

Some bugs we're aware of;

VNP-61521 - you cannot get user level tokens from non-trusted apps created on organization or service provider level.

VNP-61513 - non-trusted apps become trusted if you edit them in the web interface. This can lead to the app not working and also potentially a security issue since when the app turns to "trusted" you only need the app key and secret to generate a token on the level where the app is created, no user credentials required.

On Friday we completed our full snapshots and began the upgrade process.

The process completed much sooner than expected (3) hours. We did a bunch of testing. had a few custom updates, like ivrdigit timeout, postfix email, displaying north american number format. Simple stuff.

We believed everything went well. Was able to successfully test pretty much everything. Verified extensions re-registered etc.

Come the morning the first support call explaining they were not able to make calls. upon packet inspection, the device couldn't get the security certificate from the server.

Took u a bit, but we confirmed the issue was firmware specific on some Polycom and Cisco devices. Meaning that firmware that worked before update, didn't work after update. So we had to roll back some firmware and update some other ones to be able to successfully register and make calls on TLS.

Once we were able to get the devices and firmware deployed thru provisioning

For the record, you need this with poly com for it to work with TLS..

This seems to be caused by an incorrect setting on the phone. We reproduced the issue on your server then corrected it by changing the SRTP settings. The working config was:

Message waiting indicator wasn't working system. but they fixed it.

"daily database error - log rotation" came and was also fixed quickly.

One big issue that was identified as a bug during this process which you should be aware of;

VNP-61620 The problem is caused by the organizationID, in fact by the last 2 digits of the organizationid combined with the extension separator because it matches an internal function from Hubgets called with 43*

When the API request is analyzed the 43* is matched and for this reason the extension is no longer passed to asterisk for making the call.

So this means that any account that has 43* is going to have problems with click2call using the API. But... they were also quick to update the dialplan on the server correcting the problem. Said to expect in next release.

What i can say about the update.

It was big.
It hand some kinks.
It hurt for a bit.
4psa was exceptional!
It worked out.
It's worth it.

Dot it.
Reply