In EPM templates for Cisco SPA-series phones i.e. SPAnnn such as SPA508G, the provision server address is not working when authentication is enabled.
When you have HTTP(s) Authentication enabled under SysAdmin>Provisioning protocols, the phone must download config using those credentials.
Currently when HTTP(s) auth is enabled and ProvisionServerProtocol is set as HTTP for Cisco SPA series templates, EPM is setting the __provisionAddress__ in <Profile_Rule ua="na">__provisionAddress__</Profile_Rule> as: https://user:[email protected]:4434 Cisco phones do NOT accept the format of https://user:[email protected]:4434 (they will ignore everything after @).
The only format that Cisco phones will accept for profile rule with HTTP(s) config download that uses user/pass authentication is the following: [--uid user --pwd pass] http://1.2.3.4:4434/spa$MA.xml (the spa$MA.xml is dependent on the phone model, but everything before it is the same for all Cisco SPA/7800MPP/8800MPP series phones)
Also, Cisco SPA phones all support HTTPS provisioning, which is the ideal method for provisioning remote phones since the config details are all encrypted instead of being transmitted in plaintext, so there should also be an option for “HTTPS” as Provision Server Protocol in the EPM template setting.
And since configuration of Cisco 7800 and 8800 series MPP phones is identical to SPA series, can you please add a model for these (or let me know how I can do it), or simply allow adding 2 more buttons to the current SPA508G template (I can contribute the code for that too), that way it can be easier to program the full 10 buttons of Cisco 8800 series MPP phones (otherwise you need to just add a few lines of custom config to the basefile - I have documented this all here on the wiki). The way I have been provisioning them ATM is by using the SPA508G template which works fine. Except that won’t work for option66 since Cisco 7800/8800 series phones require /$PSN.cfg (file naming different) as the profile rule instead of /spa$MA.xml, but if you are using Cisco’s CDA zero touch provision services then you don’t have to touch the phone to have it fetch the /spa$MA.xml file if you’re building on the SPA series templates in EPM.
I am supposed to pay for EPM license and expect no improvements or bug fixes?
OSS doesn’t work on PBXact (and if you try to make it work then Sangoma support blames all issues with your PBXact on the unsupported modules you installed such as OSS) so I have no choice but to use EPM commercial.
My goal of the post was to have Sangoma take action on the bug AND give heads up to anyone trying to configure these phones with HTTP(s) if they use EPM; the temp. workaround is to modify the <Profile_Rule ua=“na”> parameter in the basefile.
Since I made such a detailed post about the bug here, anyone from Sangoma should take action on logging this bug
Whilst the work around might be helpful for others, posting here won’t get a proper fix. Sangoma doesn’t work that way, there is a proper procedure to follow for fixes. Sangoma developers are not always monitoring the forums and with many posts they can’t follow everything. That’s what the support system is for!
No you raise a support ticket here https://support.sangoma.com/ If they can confirm the issue is a bug then it will be escalated to the dev team internally.
It should be worth noting that all SPA series are EOL from Cisco and have been for 2 years or more. On top of that, the last update for the SPA 30X/50X/51X series was in 2020 and it updates the SSL library it uses to openssl-0.9.8zh which had its last minor version release in 2015.
This would mean the SPA series phones don’t have support for TLS 1.2 as it wasn’t added to the OpenSSL library until 2016. That would mean these phones are unable to use any certs issued within the last year or so as anything less than TLS 1.2 has been removed from things and is no longer supported.
In other words, you would have to install an older version of OpenSSL to enable TLS1.0 or lower (which the SPAs can support) and TLS1.0 is considered insecure with a list of known vulnerabilities that anyone can get past now because those issues aren’t getting fixed.
Honestly, legacy/EOL phones that can’t support modern/current TLS or other features let alone get zero support from the manufacturer should only live so long in the EPM before being removed as Sangoma can’t guarantee support, fixes or updates for them as they have no support from manufacturers.
The provisioning templates for Cisco’s 7800/8800 series Multiplatform phones that replaced the EOL SPA series use IDENTICAL provisioning file format as the SPA so it makes no sense to remove SPA template from EPM and my main point of this post was to fix the bugs so people can continue provisioning their 7800/8800 series phones, which are not EOL and are very popular.
Cisco’s SPA/MPP phones are some of the easiest to provision since they only require one xml file and everything is readable/logical without need for coded 1’s and 0’s and mysterious P-codes for provisioning values like with other phones (Grandstream, polycom…) so the fix is the easiest to apply. It’s literally fixing a few lines of code and please don’t defend leaving the bugs as-is.
Also - keep in mind that there are still many people who use SPA phones. Over 50% of templates on EPM are for phones that are EOL and there’s no reason to completely neglect anything…
Whilst it might be identical, I missed the bit where you were requesting to add the 7800/8800 series. Again this isn’t how EPM works, devices are only added if the Vendor pays to have them added.
