extension name does not update

It is "sort of by design". If I remember correctly we only provision device when user extension is created and not on updates. The reason is that tools -> autoprovisioning is a more complete way to manage a device (MAC) - i.e. add LINES, BLFs, SPEEDIALS to buttons so allowing "partial" update through the user extension would be messy.

That said, updating when the user extension is updated is more intuitive in simple cases and is probably what people expect - perhaps we should look at what we can do.

From my standpoint, changing a name should be one of the most simple operations. It is one of the operations that the customer should be able to perform for themselves. Requiring the customer to know anything about "Auto-Provisioning" is un-user friendly.

Currently it looks like the name needs to be changed in three places:

1) User Extensions
2) Auto-Provisioning - Description
3) Auto-Provisioning - Label

I realize one solution is to not put the names in position 2 and 3. Is this what other people are doing? What is expected to be put in 2 and 3?

We like to put a general description in 2 & 3.

-Matt

why would you not use extension # for #3? The description is irrelevant and has no bearing on production. Changing a name on an extension does not require any change to auto-provisioning. Only if someone needed to change the extension that a phone registers as or adjust the BLF fields would an admin have to go into auto-provisioning, and they would have no choice but to become familiar with the auto-provisioning screen if they had to change those.

Auto-provisioning cannot be tied into changes to user extension because they only partially relate to each other. When creating an extension, it is true that you can put in a MAC to initially setup a phone device. However, after this stage, many things can change about the device. Additional buttons can be setup so that 1 phone actually registers as multiple user extensions; BLF keys can be configured to monitor the status of other extensions. So trying to retroactively re-label the LABEL field on a device would cause a great deal of damage to many phones with extra configuration. The Device object is as unique as the Extension object, so their relationship to each other is only a small subset of what they control and configure.

I think an optimization for the use case of changing the name on an extension is in order.
That must be the most common change to an extension/device, and currently the method that must be used is unnecessarily use is less than optimal.

eeman, I agree that it would be an easy fix to simply use extension for #3. That way, if a customer wants to update a name, they can simply go to user extensions, update the name, and be done with it. However, the bulk generator puts the name, not the extension, in #3, so this method would prohibit using the bulk generator.

Solution #1 (preferred):

Change the functionality when updating a user extension to also update the phone provisioning file.
We prefer this because customers have expressed that they like to see the name on the phone lcd.

Solution #2:

Change the bulk generator so that it does not provision the name on to the phone and instead uses the extension as the label.

This is one of the most common support tickets our clients submit as well. They are more then capable in changing the Name, but they have always had the persons name appear on the phone display, primarily Aastra shop. This would be a great improvement.

then modify your AASTRA templates not to include the name on the display. In polycom templates its

reg.${LINE}.label="${EXTENSION}"

notice that it isn't LABEL or DISPLAY_NAME, in fact the only way a DISPLAY_NAME even shows up on polycom is if the two phones managed to do an ip-to-ip connection and circumvent asterisk all togeather.

This is, in my opinion, a choice. I've explained why there can be no means to update devices after they have been created without destroying other changes to those devices. You have total control over phone templates and what actually shows up on the display. If you want to change something, petition that the default aastra_line.cfg not use DISPLAY_NAME variable for the screen name. It doesn't HAVE to show the name on the display.. that's a choice that some template person made. I mean seriously, Bob Buddy doesn't know that that's his phone sitting next to him? He is so damn stupid that if it just said 115 instead of Bob Buddy <115> that he would just be clueless and unable to use the phone? I suggest for your MTE templates not putting names on the devices.. because apparently your customer employee turnover is so high that its amounting to the majority of the tickets you have to handle.

We still operate with the 'customer is always right', and while we do tend to try and bend the customer to our will, this is just not worth hearing how their Nortel/Mitel/Avaya could show the name.

If the system, post update of an extension, updated the matching device in devices.txt and then triggered provision of the match device(s) than the provisioning script takes care of the name change.

Even simpler, have the system not worry about changing the "description" in devices and simply match the device to modified extension and provision.

We still operate with the 'customer is always right', and while we do tend to try and bend the customer to our will, this is just not worth hearing how their Nortel/Mitel/Avaya could show the name.

then make the change manually and you can continue to appease the customer, nothing is stopping you from doing that, or from granting your customer the access to auto-provisioning (though that has a potential for mistakes). The extension is not bound to ANY device. There's no record anywhere in users.txt or sip.conf In fact, it's the other way around. One device could be bound to THREE (or Twenty) extensions.

Device A line 1 extension 100
Device A line 2 extension 110
Device A line 3 extension 121

extension 121 changes the name... there is no trigger that says extension 121 needs to go find MAC 000342cb12fg and update its settings. In fact by doing what you and k3leland ask would actually result in changing the name on line 1 not line 3 because the wrong basic assumptions were used. And simply looking through _every_ device for any sort of mention of 121 (speed dial, BLF) would also destroy what every custom label you had defined for that BLF (maybe it was labeled 'Billing' on someones speed dial). Unlike those other platforms you mention, they do not have the depth of the flexibility that this provisioning system does. Lets see an avaya system provision 16 different manufacturers phones with 4 - 6 models per manufacturer AND on top of that provide a single interface for doing it AND still allow the flexibility to have multiple buttons register as different extensions, have BLF keys, AND after all that still allow for customizing the display information instead of locking them into a single choice.

For the record Nortel/Mitel/Avaya do not have a multi-tenant hosted option. Sell them STE and make even MORE money off them if they want to compare an apple to an orange. Ive used Cisco Call Manager, and besides its interface flat out sucking; you have to tear down the phone device, the user profile, and the mailbox completely then re-build it all from ground up to avoid this same issue. If they run STE they can screw up auto-provisioning to their hearts content and you don't have to worry about impacting another customer.

I understand the MTE has more complex requirements and also that some would rather not see this happen. But I would like to see an optional feature that will match the "account_0" or 1 or 2 to a changed extension and cause the phones provisioning files to update. That avoids all the blf issues.

Obviously not a perfect fit for those using MTE, and probably something I could script with the triggers, but it would be worth know if it could be done.

A closely related topic is the company directory. When you update a name it doesn't update the company directory. Is this also by design? Why are there so many different places to update a name? This violates the rule of "Don't Repeat Yourself." I can just see it now, every time a name is updated one of these places is forgotten.

We have already been forced to choose between two poor choices on the phone provisioning issue. Namely:
1) Do not put the name's on the phones.
2) Update the name in the phone provisioning page AND the user extension page everytime you make a change.

Is it possible for the directory to be updated automatically?