Ringing call from queue gets connected to parked call if user picks up parked call when queued call rings

Is there a way to stop this from occuring? Read on…

I have an issue where inbound queued ringing calls get connected to a parked call if the user tries to pickup a previously parked call while his handset is ringing as part of said queue. Happens on all handsets. End result, one inbound caller ends up talking with another inbound caller whilst there is no evidence that either call exist on handset.

User parks a call by pressing the corresponding button in queue. Pick up (same call) from queue by pressing same park button.

Handsets are Aastra 6737i.
Parking is default setup on server. Parking Lot 70 with 9 slots 71-79.
Parking buttons on phones are setup as BLF 71 to BLF 79 using softkeys.
Free PBX version
Asterisk version 16.4.1
Using PJSip for extensions and trunks.

You need to show this. Full verbose call output that replicates this issue.

We’ve had this reported with ring groups as well, FWIW.

Our phones have an ignore button when an incoming call is present on a handset. The work around is to press the ignore button prior to pulling a call from park.

The underlying problem was that direct access to park slots also allows parks slots to conference multiple calls inbound calls. It’s been an issue for many pbx users for years so I figure it’s a feature, not an issue.

Are you sure about that? Unlike Park and Queues that have their own applications and methods of doing things Ring Groups is just a way of doing something. All it does is create a Dial() string (for ringall as an example) that has multiple devices in the Dial().

I have a client that uses Ring Groups and Parking heavily. The calls hit an RG with three members then hit a second RG with 12 members (including the original three). They each BLF not only 17 devices but 10 Parking Slot so that’s 27 BLFs. Not once in the almost 4 years I’ve had them have they ever complained or has there been an known instance of a call in the parking slot either being picked up and rung back to the parker where it has conferenced a call ringing their phone and the parked call being picked/rung back to them.

So again I’m going to ask, where is the verbose debug output of this because while this could be an actual issue you realize that phones do conferencing locally within themselves, right? This might not actually be an Asterisk/FreePBX issue but the phones conferencing the two calls together at the phone level which could refer calls together.

Yes, I’m sure. Parking a call while the extension is ringing as part of a ring group sometimes connects the two calls together, unsupervised.

I don’t have logs. It’s intermittent and seems to be very timing sensitive.

Those two things said, it’s going to be nearly impossible for Sangoma to catch this. There are also variables that we don’t have (like it could be related to a phone thing) that are going to make this a real challenge.

Understood. I’m not sure how to get logs on something that happens a couple times a day on a system that get hundreds of calls a day. If you can aim me, I’d happily do.
That said, my post wasn’t intended as a “Fix this, Sangoma” thing. It was to point out that this isn’t an issue with just one installation.
Thanks, Dave.

OK now explain the process being used. How many line appearances do they have? How are they Parking the call? Again this could be happening at the phone level. Describing the process used for how they park calls would be very help as they may be inadvertently be picking up a line while transferring to park and instead of parking the call they just completed the transfer to the wrong destination.

1 Like

So i have 10 users in Q610. Q610 passes back to itself until someone picks up (rare - usually answered by the second ring).

Park 71-79 as parking.

I have Aastra 6737i handsets with latest firmware. I have park slots set up as xfer/BLF soft keys at top of display. Each park slot is directed to its own park slot (ie: 71, 72, 73, etc). The handsets can hold a call locally but that is of no use in this environment so nobody uses that feature.

For this example, we’ll assume there is a call already parked in slot 71.

Handset in Q610 is ringing with an inbound call. User picks up handset and tries to pull the call from park. The inbound call has now been answered to this handset as he picked it up, though when he presses the park slot for 71, the answered call is then sent to the park slot with the previously parked call. The call is now in unattended conference mode whilst the handset’s park slot 71 appears to be free again. We know this what happens as caller calls again and explains that he has talked to another inbound caller.

I haven’t caught it happen in verbose mode as dozens of calls come in on the regular, all day long. It’s a wrecking yard autoparts hotline number.

For now, I have instructed the lads to either hit ignore before picking up a parked call, or pressing the park slot to be picked up prior to lifting the handset.

You still didn’t answer how many line appearances are on the phone for the actual extension account. If there is just one that means every call is being sent to that line and you have to rotate through calls if you hold them or more then one comes in at a time.

However, regardless of if there is a call parked or not or if they are trying to pick up a parked call. If the line is ringing the moment the handset is picked up or the speakphone button is pressed the ringing line is going to be seized and answered. Even if you were just trying to make an outbound call.

Here is the other thing, Parking Slots can only hold a single call at a time per slot so the call from the ringing line is not being sent to the Parking Slot because Asterisk would return an error saying the slot was in use and prompt you to use another slot. So my guess is that they are picking up the ringing line, hitting the BLF for the parking slot to get the call they originally attended to get and the two calls are being bridged together at the phone level. OR the two local channels are being bridged at the PBX.

Now as I said before I have numerous clients with this type of setup and this isn’t an issue for them so this is starting to sound more like a user training issue that may have exposed a bug in Asterisk/FreePBX for this but this is more likely related to the users not understanding how things work and flow together.

Consider this thought experiment:

  1. Inbound ringing call on your phone, don’t answer, press BLF button. What happens? The ringing call is blind transferred to the BLF destination as expected
  2. Your phone is idle, BLF button is flashing indicating that the BLF destination device is ringing. Press the flashing BLF what happens? You seize the call that was ringing at the BLF destination.
  3. Assuming the above is correct, then what is the logical outcome when you combine the two cases? That is your phone is ringing, and you press a flashing blf without answering? The incoming ringing call is blind transferred to the caller attempting to reach the BLF destination.

You must configure the phone to either not blind transfer inbound ringing calls when you press a BLF or you must configure the phone not to seize a ringing call when you press a flashing BLF. How this is done depends on the phone and how you provision them.

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