Possible Bug? Multiple Lines on Cisco 7960 Not Allowed via GUI

I recently purchased a PBXact system and am in the process of getting phones to work with it, figuring out how everything works, and designing how our new phone system should be laid out where different than our existing Cisco Call Manager.

Management wants to keep costs down as much as possible while maintaining a quality system, so I ordered Sangoma phones for those people in our business who use the phone the most. For the rest, we would like to reuse our existing Cisco IP phones - we already own them & our users are used to them. After much fighting, I was able to get the 7960 model to work after flashing it to SIP. (Never was able to figure out how to make the native SCCP protocol work with PBXact, even though several sccp modules are shown as being available. I’ve given up on the 7912 and plan on maybe giving the 7940 another shot, but both of these models are being stubborn, even more-so than the 7960!)

The problem I’ve run into with the 7960 is that it appears PBXact will only provision a single line on it. In the Endpoint Manager, I created a brand (inventively named ‘cisco’) and then a template (creatively ‘cisco7960’) under it. Inside this template, I clicked on the CP7960 model and a window pops up showing what to use for the various line buttons on the side. Adding the first as a line button works fine, but no matter what I do to the subsequent buttons, they never come live on the phone. The extension has the correct template and model phone assigned to it.

To troubleshoot, I went into the console and manually edited the SIP.cnf file in the /tftpboot for one of these phones. I added in the second line, saved the file, and rebooted the phone. The second line button on the phone now showed line 2 and was usable. However, when I went into the extension in PBXact GUI and hit save, these changed I’d manually made to the configuration file to allow the second line button to work were wiped out; the lines in the text file for these line buttons are all set to “” rather than the actual values needed for the phone to work.

To me, this indicates a flaw in the software that generates the Cisco phone configuration files for the various lines defined in the template. Unless I’m missing something of course…

Does anyone know of a solution for this problem??? (My thought is to write a script that I could run after making changes to an extension which would run through the config files and add the values needed for line 2 to each of them, but having to run it after every time I make any change to an extension is going to be a pain in my rear going forward.)


You can make the appropriate edits to the template using the EPM Basefile editor:

1 Like

That would indeed be the flaw I discovered. Surprised it hasn’t been fixed yet - shows as being opened in January of 2017! :astonished: :frowning:

I tried using the Basefile Editor inside of the Endpoint Manager to always add Line 2 using the variables for Line 1 (which work). I can save it, but unfortunately, when I try to rebuild the configs, I get the following:

Whoops\Exception\ErrorException Undefined variable: prefix File:/var/www/html/admin/modules/endpoint/functions.inc/functions_common.php:2727 

Is there a file which I can directly edit using a console instead of the GUI that would accomplish this same task?

You can vote for this issue to be fixed.

It hasn’t been fixed as technically Cisco phones are unsupported and we only handle basic single line setup at best for support.

1 Like

@PitzKey Thank you. I’m very new at this and did not see the section to vote on it. Just voted & started watching it as well. :slightly_smiling_face:

@tonyclewis Cisco 7960 phones are unsupported??!?? I specifically asked the salesman I spoke with about these particular phones before purchasing the PBXact system and was told they would be. We bought the third party phone integration module (2 due to it being HA) based on this. Also, if this is true, the wiki should be updated to reflect this - I cannot yet post links, but this model is listed as supported. :confused:

I can certainly code my way around the issue in order to work around this flaw in the GUI, though it’ll be inconvenient to say the least going forward. I’m beginning to really question my decision to go with PBXact; this is the third bug I’ve run into & have only set it up in my office with 4 phones for testing so far - the system isn’t even put into use yet! :hushed: :anguished: (Might be a better idea than I initially thought to use it for only one store rather than jumping in with all of them…)

We do have this listed. https://wiki.freepbx.org/display/FPG/EPM-Supported+Devices

I did use a bad choice of words related to support and unsupported. I should of used they are not Certified as shown above.

You will see it clearly states

  • Basic Provisioning Support only to get the phone to register with the PBX and make and receive calls.

  • If a bug is found with the ability to use the device while using EPM to configure the device we will not offer free support to fix the issue nor can we guarantee its an issue that can be fixed.

  • No features generally added to EPM for these devices.

Sorry @tonyclewis - I was not aware of the ‘certified’ status of devices; I figured that if something was supported, it was supported.

Do you have any idea of how many support credits would it take in order to get this flaw in the cisco config file module fixed? (I honestly don’t know how much management is going to be willing to pay to fix a bug in the product, but we’ve already invested enough that they might actually go for it.) I should have those that we paid for with the systems.

I’m currently looking for the script which generates the XML config files. (I’ve not coded in PHP yet, but can program in whatever language I need to; it’s really only a matter of learning the specifics.) I really feel it shouldn’t be difficult to fix this bug. If I do, are you willing to accept a patch?

FYI, I just opened bug FREEPBX-18268 regarding the whoops error in the basefile editor. Turns out that trying to rebuild the configuration, even with the default settings, results in the same error.

For those who find this thread in the future, here is how I worked around this problem:

As noted in my previous post, I opened FreePBX issue 18268 regarding the WHOOPS error when trying to edit the basefile in the endpoint manager. Kapil directed me to upgrade the endpoint module to the edge release (probably the term used by FreePBX for their development snapshot???) and I did so by executing ‘fwconsole ma --edge upgrade endpoint’ at the command prompt of the console. This upgraded the Endpoint Manager on my system from to and made the whoops error when trying to rebuild the basefile configs disappear.

The first thing I wanted to accomplish was to add a second line with the same extension to the Cisco 7960 phones. I went into the Basefile Editor as Lorne suggested above and made the following changes:

line2_shortname: "Line 2"
line2_password: "__line1Pass__"
line2_name: "__line1Ext__"
line2_displayname: "Line 2"
line2_authname: "__line1Ext__"

After saving & rebuilding the configuration with these changes, I rebooted the Cisco phones and voila! - Line 2 appears and works like a charm. :smiley: Apparently, only the variables for the first line button you define in the template actually work when generating the XML.

This certainly does not fix root cause of the issue - the variables of the line keys as defined in the template are not honored when generating the XML config files for the phones (which is certainly a very easy & simple thing to do from a programming standpoint) - and it requires you to have a different template every time you want to have different line keys on different phones, but it provides a functioning workaround.

I’m now on to trying to figure out how to hard-code speed dials so people can have 1-touch access to paging, operator, etc. It’s a little crazy to expend so much effort to work around such a silly bug, but at least the ability exists. :slight_smile:

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.