Mitel phone crashes when Pickup during accessing Parking Apps

Kind of a strange scenario… but I think this is a bug, but not sure if this is a Mitel or FreePBX bug.

When using any 6800 series Mitel/Aastra phones configured with the Phone Apps module.
If an end user accesses the Parking App, and while on that screen showing the calls that are parked (or none parked), then the user presses a Line Key, or Pickup key (to select a new line), the phone then crashes and reboots.

In case anyone runs into this… it was a bug introduced in firmware 4.3.0.1052. I got my hands on some beta firmware and appears to be fixed in upcoming firmware 5.0.0.130.

Thanks for the update. This is a prime example of why we End of Life Phone Apps for 3rd party phones. We have tons of issues like this that we cant ever fix and it bombards the support and dev team.

I understand, but I’d also happily pay for that support. In this case, FreePBX support did the right thing by telling me to contact the hardware/phone manufacture. I opened a support case with them, and it eventually got fixed.

I don’t agree with taking away modules that are useful because too many support issues come up. Leave the option to sell it as-is and if I have to pay for support credits, it’s still worth it.

Right now, I’m having to figure out what to do if I have a client after Oct 2017 approach me for a 25+ user system… it fragments my sales pipeline and has my boss hesitating on new sales quotes. It used to be FreePBX w/ Phone Apps (+ EPM, SysAdmin Pro, etc) was an easy answer… the Phone Apps implementation are a superb selling point when I can easily demo and end-user train Parking, Conferencing, Voicemail, Call Flow Toggles, Contacts, etc. Especially when I’m competing against traditional PBXes like NEC, Avaya, Cisco, etc.

Now I feel like I’m forced into either getting Sangoma IP Phones, switch to similar implementations from far more expensive solutions like Broadsoft, or figuring out how to deal without the Phone Apps module.

1 Like

Thats the problem here. If we sell you a product that does not work we cant say buy support credits. Support Credits are for setup and configuration help not solving a bug. We spend hours and hours tracking down a problem like this only to find out its the phone manufacture not us and we cant charge for that after the fact when it could of been a bug on our side. It could also be something a phone manufacture has changed and not told anyone and now we have to work around it.

In the end we are spending way to much time and money on solving these issues then what we get in revenue so its a business case and whats best for our users and shareholders being balanced out and in the case here their is just not enough sales happening to justify the time anymore.

Ok instead of support credits, sell “bug fix”, “development”, or “extended support” credits. It’s working, I’d like it to stay working, and I’d like to still be able to implement it for future customers in the same working state it is today.
If something breaks later on, I’d at least I have the option to revert back to a previous working state.
For fixing whatever broke, I’d like to be able to pay for troubleshooting or development hours to get it back in a working state.

If the resource allocation is too high to solving these issues, devote less… but don’t eliminate all the resources. I’m ok with waiting longer on support… I waited three months for Mitel to work on this odd firmware issue with their XML API handling, and was prepared to wait longer because I could fall back to a working state… and it shouldn’t have even been a priority for them… I wasn’t even paying them for the support.