With version 60, we have introduced a new way to handle buttons. The new way now explicitly lists the available buttons, so that users don't have to guess which button numbers are used for which vendors and models. It also came with a redesigned drop down list that adapts to the selected model, so that modes which are not available for the vendor are not visible. This provides a "satisfaction guarantee" known mostly from proprietary systems now also for generic SIP phones. I am convinced that this is the way to go for the foreseeable future.
It does mean that we need to keep up with the available phone models in the market. As our inter-op partners and generally SIP VoIP phone manufacturers release new models, we need to catch up with those models and come up with updates that reflect those changes. If I could have a wish, it would be that the phone manufacturers come up with a file format that indicates what buttons are available and make it easy to detect and load it when the device gets provisioned. Until then, we need to do this manually. Another good reason to keep the PBX software update to date.
The main problem so far was migrating button profiles from older versions to the new release. The problem is that the button numbering was unstructured in the older versions and pretty much all over the place; sometimes even set up by the users themselves. Especially for Grandstream phones, it was almost impossible to predict where button setting would end up. However it was possible to export the old button profiles into a text format, which we took up in the new version. It was not included in the original 60.0 release, but we have added something to the web front end that allows editing the button configuration also in a text format.
When putting the settings for a specific phone next to each other it becomes obvious that they are not the same. However with human natural intelligence it is possible to modify the old format in such a way that it can be imported into the new format. We have done that now for a number of installations. It takes some time, but usually it takes only a few minutes per domain to get this step done. Once users see the new button configuration, the feedback was overall positive. There are a lot of good reasons to use the new button programming.
Such steps are usually also a good opportunity to review the current setup and improve it. The old button model was quite limited, and getting the new model provides a lot of features that at the end of the day improve productivity for users, so that the one-time migration effort pays back in terms of overall increased productivity.