Call PArk Malfunctions

PBXAct17:

Recently noticed an issue where Parking Space keys (DSS Keys) on P370 phones no longer work, the call is just dropped, and the outside party hears “I’m sorry, there is no call parked on that extension”

The predefined “Park” button in the call processing section at the top of the screen works, but even using that method, the outside party hears the recording that the internal user is supposed to hear “7001”.

When I first noticed the issue, I checked and there were a number of available module updates that I applied. This did not resolve the issue.

I was paying close attention to previous versions as opposed to newer versions of the modules I updated. I referred back to those notes and provide the notes related to the two parking module updates here, as it seemed most likely to be related to these modules.

Those modules were:

                     Previous Version                  Update Version

Parking Pro 17.0.1.6 17.0.1.7
Parking Lot 17.0.2.7 17.0.2.9

After those updates failed to resolve the issues, I began searching and found an article stating the information:

_____________________________________________________________________________

"Both of these symptoms point directly to an issue introduced in recent updates to the FreePBX/PBXact 17 Parking Module (v17.0.2.7+) running alongside Asterisk 20/21, which fundamentally altered how PJSIP blind transfers interact with direct-slot parking. [1]

When your Sangoma P370 phones invoke the predefined “Park” button or press a DSS key assigned to a specific parking slot, they send a PJSIP Blind Transfer. Due to the recent regression, Asterisk treats this blind transfer poorly, executing the announcement to the outside caller channel instead of the internal device, and completely dropping/disconnecting calls targeted at explicit DSS slot extensions. [1, 2]

How to Fix It

1. The Immediate Remediation (Rollback Core/Parking Module)

Because this behavior stems from a recent upstream module regression, rolling back to a stable module version immediately restores the old operational dialplan logic. [1]

Log into your PBXact SSH terminal and execute the following commands to rollback the Core/Parking modules to stable baselines: [1]

bash

fwconsole ma downloadinstall core --version 17.0.18.49
fwconsole ma downloadinstall parking --version 17.0.2.5
fwconsole reload
______________________________________________________________________________

I tried this after first trying the updates mentioned above, and it also did not resolve the issue. And now, the Parking Pro moduleis currently at 17.0.1.6, and the issues remain.


You’re saying that on 17.0.2.9 you’re having these issues? 17.0.2.8 was supposed to fix a parking issue. [bug]: Regression in core 17.0.18.51 (FREEI-2850) breaks direct-to-slot Parking on transfer · Issue #1068 · FreePBX/issue-tracker · GitHub

The description you are giving is exactly what happened with this bug.

So we have Parking Lot 17.0.2.9 in place on our system. With Core 17.0.18.54. Our receptionists are reporting back when they are blind transferring callers to park them (i.e. - ##70# for our feature code), the park slot number used to be read back to them. Now it’s not. While we do have Flash Operator Panel 2 for our receptionists, I suppose they can just look at the web app to see the park slot number. But we also have other staff who park callers manually on the desk phone and who do not use this FOP2 web app. So they have no idea where to tell staff where the call is parked.

Unfortunately, our business model involves parking and picking up a lot of external customer calls. Concurrently, so there are multiple callers sitting in park slots. So this gap is impactful. Any suggestions?

Here is a PasteBin call example of this → https://pastebin.com/w9FaghRS. I SIP registered my cell phone, and called it from my other cell phone. Performed the standard blind transfer call park using our ##70# feature code. Having both cell phones in hand I didn’t hear the announcement with the park slot number play on either side. Parked the call again just to verify I couldn’t hear anything. Just the test caller hearing our hold music.

I really recommend using ChatGPT’s desktop app and the work feature. If you have SSH pubkey authentication set up, it can dig around the log files and tell you possible fixes. That’s how I got mine fixed so quickly. But for me being on the newer core and the unreleased parking fixed the issue, so I’m confused as to what is going on on your side.

What Parking Lot version is that? As for the Asterisk version, that appears to be 21.12.3 on our system.

For now, rather than employ the blind transfer, the desk phone user can just perform an attended transfer. In our setup, this would be dialing *2 with the caller on the line. Then dialing 70# to transfer to the next available parking slot number. And finally hanging up. The announcement plays as expected.

You know what would be helpful. Logs. They would shed some serious light

That wasn’t what was in the PasteBin link I supplied? I already ran that through ChatGPT and it shows the announcement for the park slot number didn’t play. Which I already could see by initially scanning the contents. And making test calls with two phones. All fine. We can just remind staff not to blind transfer for parking calls. They can perform the attended transfer so they can hear which park slot number the caller is in.

Thanks to everyone who responded. THis error was related to recent updates the Core, ParkPro, and Parking modules. Tech Support instructed me to roll back to the following versions of those modules and that resolved the issue:

parkpro version 17.0.1.7

parking v 17.0.2.8

core v 17.0.18.51

You’re not the OP that was asking about this. But I can look.

Was there mention if a bug report has been created, and if there is anything in the dev pipeline for this being fixed in a future release?

Show the configs in res_parking_additional.conf

[default]

parkext=70

parkpos=71-78

context=parkedcalls

parkingtime=90

comebacktoorigin=no

parkedplay=both

courtesytone=beep

parkedcalltransfers=caller

parkedcallreparking=caller

parkedmusicclass=default

findslot=first

In my reply notifying them that this resolved the issue, I asked what I should expect, because I typically install updates as they are available. And, because this was a rollback, updates are now available again.

I found this in an online search: "Both of these symptoms point directly to an issue introduced in recent updates to the FreePBX/PBXact 17 Parking Module (v17.0.2.7+) running alongside Asterisk 20/21, which fundamentally altered how PJSIP blind transfers interact with direct-slot parking.

This is all that tech support said in the original response:

Hi,

Thank you for contacting to Sangoma Support.

Our dev team has confirmed that parking issue is addressed with below module versions as mentioned below :

parkpro version 17.0.1.7

parking v 17.0.2.8

core v 17.0.18.51

Please upgrade your PBX module versions and let us know the updates.

Best regards,

Adarsh Tripathi

Technical Support Engineer

Phone: 1 855 280 0020

At the time, 17.0.2.9 was available, but not through the repository, but it resolved the issue.