Call Parking - Blind Transfer Missing Announcement

FreePBX Applications / Modules
1

Starting separate post, although issue appears to be similar to Call PArk Malfunctions .

First off, our typical workflow when it comes to parking calls is that the desk phone user blind transfers them to our parking lot extension 70. The announcement plays which slot number the caller is parked on. Seeing we frequently rely on parking callers, many of them concurrently, being able to convey which slot number the caller is parked on (71-78) helps ensure the callers aren’t lost in the shuffle. Desk phones are setup simply, with just their extension line button, a park pickup key, and a VM key. No DSS buttons assigned to each parking slot number or anything like that.

With a recent FreePBX update that I applied, it seems that the slot number announcement doesn’t play. Neither party hears it. As I confirmed by making test calls with two different phones. Below is a listing of versions in place on our FreePBX v17 system. We do not pay for Parking Pro, just the standard Parking Lot module.

| core | 17.0.18.54 | Enabled | GPLv3+ | Sangoma |

| framework | 17.0.33 | Enabled | GPLv2+ | Sangoma |

| parking | 17.0.2.9 | Enabled | GPLv3+ | Sangoma |

| parkpro | 17.0.1.7 | Enabled | Commercial | Sangoma |

Asterisk 21.12.3 built by jenkins @ c836c89c424b on a x86_64 running Linux on 2026-06-30 05:10:18 UTC

Here is a log snippet from an example where the SIP phone blind transfers to the Parking Lot extension 70 → Blind Transfer Call Park Example - Pastebin.com . And here is a log snippet where the SIP phone blind transfers to the specific Parking Slot 71 → [2026-09-14 07:25:39] VERBOSE[1054597][C-0000051d] pbx.c: Executing [+1614923951 - Pastebin.com . Neither test call results in the parking slot announcement playing for either party.

Below is what our res_parking_additional.conf looks like:

[default]

parkext=70

parkpos=71-78

context=parkedcalls

parkingtime=90

comebacktoorigin=no

parkedplay=both

courtesytone=beep

parkedcalltransfers=caller

parkedcallreparking=caller

parkedmusicclass=default

findslot=first

For now, if our users park callers via attended transfer (i.e. - for us, employing the *270# feature code and then hangup), then the park slot number announcement plays for them. So there is a workaround. Just wondering if this is a known issue that’s logged in bug reports, as well as what the general status of a bug fix is on the dev roadmap. Seeing I believe we are on the latest versions of these modules, I felt this was worth bringing up.

2

Just out of curiosity, have you tried a blind transfer that doesn’t involve using DTMF?

3

I have not. Although for another test I could try that. For this scenario would I program a key on the desk phone to perform that function?

4

Correct. You would program a key on the phone. Most phones support blind transfer for BLF keys depending on the state/mode. We use parking for quite a lot of customers, most just need 4-5 slots so they have 4-5 lines keys that are there for this. Need to park a call, press Line 1 and it parks it to the first slot. Everyone else sees there’s a parked call and they just press Line 1 to pick it up. This uses proper SIP headers to tell Asterisk to initiate a blind transfer.

5

Ahh I gotcha. For us, if it was just our receptionist desk phone at each site location, that would be easy enough. Unfortunately, all desk phones at all sites frequently park and pickup calls. Maybe 100+ phones, mostly newer Yealink. We don’t use Endpoint Manager, as I just have an internal FTP directory with the phone config files. A fair amount of manual editing to get those BLF keys added for the desk phones. :upside_down_face:

Use cases for the call park and pickup are due to customers calling into the main DID, asking to speak to a salesperson, so the receptionist parks the caller and notifies the staff to pickup the call. Let’s say a salesperson picks up the call but then either needs to relocate to a different area, or the caller needs to speak with someone else. Caller is parked again. Seeing we have multiple sites and multiple parked callers (yeah I know, we don’t have Parking Pro and it would make sense to purchase it), knowing who is parked where is important.

For now the assisted transfer method to park these folks is “good enough.” As long as we know the slot number all is well in the world.

6

I did take @BlazeStudios 's recommendation about hard-coding the BLF buttons for park slots, at least for our receptionist desk phones. Seeing they park calls the most. Seeing our receptionists also utilize the Flash Operator Panel 2 web app, they also have visibility into who is parked where via that as well.

For now, the other majority of the desk phones can just employ the attended transfer to park callers.

7

Are they getting the slot played back with that method?

8

No, the park slot announcement did not appear to have played. But seeing the user manually parked in a specific slot via the BLF button from a functionality/practicality standpoint, this works.

9

As opposed to a test call I just made from my one cell phone to my other SIP registered cell phone. Using the attended transfer option for our Parking Extension 70 to park the caller, the available parking slot number 71 announcement played for me. Which appears in the logs → Call Park Attended Xfer - FreePBX Pastebin .

10

I’ll be honest with you. With or without FreePBX, I’ve never had the slot played back with a blind transfer with any real consistency because of how a blind transfer works. So if you’ve been getting the slot read back that could be a race condition issue and not the expected behavior.

When A blind transfers B to C, a blind transfer will remove A from the dialog and replace it with B’s SIP data. In other words, C thinks B is calling them directly. User A has been removed from the call. So why would User A get a playback? They’re gone, Bye Felicia.

With an Attended Transfer A calls C and B sits on hold. A talks to C and then completes the transfer to C. When A calls C it is a A to C call then A drops out and merges B to C.

So in this case C is the parking lot. So with a blind transfer, the parker is removed from the call before the slot would be played back and since the Parker isn’t on the call it’s not played back. With an attended transfer, A is still there when transferring to C so when C answers is just says “701” instead of hello then you complete the transfer.

I’m not sure how FreePBX code is going to solve this problem. It has nothing to do with FreePBX and everything to do with Asterisk. FreePBX doesn’t handle ## DTMF, Asterisk does. FreePBX doesn’t handle the blind transfer, Asterisk SIP stack does. FreePBX doesn’t handle any of the transfer features.

I’m not sure how the FreePBX developers think they can make a playback happen for a channel that no longer exists. If they can they are dark wizards.

11

I had a shutdown FreePBX v16 AWS EC2 instance that I fired back up to pull some logs. Below is a snippet where one of our site receptionists parked a caller using the blind transfer function (i.e. - ##70# to put the caller into a parking slot). The receptionist had the 71 digits read back to them.

[2026-06-12 10:07:10] VERBOSE[23404][C-00001bf3] bridge_basic.c: Channel PJSIP/110-000042a8: Started DTMF blind transfer.
[2026-06-12 10:07:10] VERBOSE[23404][C-00001bf3] file.c: <PJSIP/110-000042a8> Playing 'pbx-transfer.ulaw' (language 'en')
[2026-06-12 10:07:10] VERBOSE[23390][C-00001bf3] res_musiconhold.c: Started music on hold, class 'sawmill', on channel 'PJSIP/Twilio_Trunking-000042a7'
[2026-06-12 10:07:11] VERBOSE[23390][C-00001bf3] res_musiconhold.c: Stopped music on hold on PJSIP/Twilio_Trunking-000042a7
[2026-06-12 10:07:11] VERBOSE[23390][C-00001bf3] bridge_channel.c: Channel PJSIP/Twilio_Trunking-000042a7 left 'simple_bridge' basic-bridge <2e787851-46f1-4398-bb39-ec9cba89b403>
[2026-06-12 10:07:11] VERBOSE[23390][C-00001bf3] parking/parking_bridge.c: Parking 'PJSIP/Twilio_Trunking-000042a7' in 'default' at space 71
[2026-06-12 10:07:11] VERBOSE[23390][C-00001bf3] bridge_channel.c: Channel PJSIP/Twilio_Trunking-000042a7 joined 'holding_bridge' parking-bridge <d0038391-8d8d-4341-9ab0-c52aeeac0678>
[2026-06-12 10:07:11] VERBOSE[23390][C-00001bf3] res_musiconhold.c: Started music on hold, class 'sawmill', on channel 'PJSIP/Twilio_Trunking-000042a7'
[2026-06-12 10:07:11] VERBOSE[23404][C-00001bf3] file.c: <PJSIP/110-000042a8> Playing 'digits/7.ulaw' (language 'en')
[2026-06-12 10:07:12] VERBOSE[23404][C-00001bf3] file.c: <PJSIP/110-000042a8> Playing 'digits/1.ulaw' (language 'en')
[2026-06-12 10:07:12] VERBOSE[23404][C-00001bf3] bridge_channel.c: Channel PJSIP/110-000042a8 left 'simple_bridge' basic-bridge <2e787851-46f1-4398-bb39-ec9cba89b403>
[2026-06-12 10:07:12] VERBOSE[23404][C-00001bf3] app_stack.c: PJSIP/110-000042a8 Internal Gosub(crm-hangup,s,1) start
12

Notice the difference between the two. In the older version, PJSIP/110 stays in the basic-bridge while the Twilio channel gets removed and placed in the parking-bridge. The PJSIP/110 channel should also be removed from the basic-bridge but since it’s not, the playback happens.

Notice what your pasting as part of the issue. Both channels are leaving the basic-bridge with the Twilio channel properly going into the parking-bridge.

[2026-09-14 07:25:41] VERBOSE[1054601][C-0000051d] bridge_channel.c: Channel PJSIP/515-00000be4 joined 'simple_bridge' basic-bridge <9ad84b2a-225d-453f-a90b-58fbcea6f752>
[2026-09-14 07:25:41] VERBOSE[1054597][C-0000051d] bridge_channel.c: Channel PJSIP/Twilio_Trunking-00000be3 joined 'simple_bridge' basic-bridge <9ad84b2a-225d-453f-a90b-58fbcea6f752>
[2026-09-14 07:25:46] VERBOSE[1054601][C-0000051d] bridge_basic.c: Channel PJSIP/515-00000be4: Started DTMF blind transfer.
[2026-09-14 07:25:46] VERBOSE[1054597][C-0000051d] res_musiconhold.c: Started music on hold, class 'sawmill', on channel 'PJSIP/Twilio_Trunking-00000be3'
[2026-09-14 07:25:46] VERBOSE[1054601][C-0000051d] file.c: <PJSIP/515-00000be4> Playing 'pbx-transfer.ulaw' (language 'en')
[2026-09-14 07:25:47] VERBOSE[1054597][C-0000051d] res_musiconhold.c: Stopped music on hold on PJSIP/Twilio_Trunking-00000be3
[2026-09-14 07:25:47] VERBOSE[1054601][C-0000051d] bridge_channel.c: Channel PJSIP/515-00000be4 left 'simple_bridge' basic-bridge <9ad84b2a-225d-453f-a90b-58fbcea6f752>
[2026-09-14 07:25:47] VERBOSE[1054597][C-0000051d] bridge_channel.c: Channel PJSIP/Twilio_Trunking-00000be3 left 'simple_bridge' basic-bridge <9ad84b2a-225d-453f-a90b-58fbcea6f752>
[2026-09-14 07:25:47] VERBOSE[1054597][C-0000051d] parking/parking_bridge.c: Parking 'PJSIP/Twilio_Trunking-00000be3' in 'default' at space 71
[2026-09-14 07:25:47] VERBOSE[1054597][C-0000051d] bridge_channel.c: Channel PJSIP/Twilio_Trunking-00000be3 joined 'holding_bridge' parking-bridge <1a260fbe-ac0a-4059-84b4-4920e9bf81fb>
[2026-09-14 07:25:47] VERBOSE[1054597][C-0000051d] res_musiconhold.c: Started music on hold, class 'sawmill', on channel 'PJSIP/Twilio_Trunking-00000be3'

This is important because what you are experiencing is related to how Asterisk handles bridging. Between Asterisk v20 (the most current FreePBX v16 supported) and Asterisk v22 there are multiple changes in regards to the bridge/channel/transfer life cycles. So any one or more of those fixes could have impacted DTMF or REFER based blind transfers and how long they stay in the basic-bridge.

As I said before, the playing back of the slot on a blind transfer shouldn’t be happening and it was probably a race condition or other factor that was addressed in updates in Asterisk.

13

Yes, this all makes perfect sense. Not as much as a regression bug as fixing a previously-existing bridging quirk. Seeing I started implementing FreePBX for our site locations going back to v15, the associated Asterisk versions perpetuated the behavior. All the way through v17 actually, up until a recent update I installed a week or two ago. We’ve had v17 in place starting back in June, and even then I didn’t have reports of this situation.

Guess it’s interesting that our business practices we trained users on for WRT call parking were based on a quirk. :grinning_face:

14

Don’t conflate your FreePBX version with your Asterisk version. FreePBX v17 supports Asterisk v18 to Asterisk v23. Being on FreePBX v17 with Asterisk v20 or lower means you can use chan_sip still. Being on FreePBX v17 with Asterisk v21 or higher means you can’t use chan_sip.

So you can have two FreePBX v17 systems, all updated with current modules but one with Asterisk v20 might playback the slot on a blind transfer but Asterisk v22 or v23, with the bridge fixes, won’t. Two FreePBX v17 “exactly” the same expect for Asterisk version and thus have two different outcomes for the same thing such as blind transfers to parking slots.