I have 3 clients, each with their own independent FreePBX system. Distros were installed less than a month ago…
All 3 clients report that from time to time 2 independently parked callers end up in the same slot and are talking to each other.
Any ideas or fixes ???
if yes, it is easy to reproduce this.
Sorry I didn’t provide that info in my original post… but no, nit Yealink phones… They are ALL using Cisco SPA508G phones.
Asterisk version please.
Parking is, at the base level, an application written by Asterisk. Two people talking to each other at the same time makes me think they were transferred into a conference, thats the only way this could happen aside from a bug or if the destination timeout also routes to a conference, such as a misconfiguration.
well, I am giving the FACTS. Transfer to 70, announcement says Parked on 71 (2 users do this)… Dial 71 and both callers are on the line and can talk to each other and the person that picked up 71. It’s certainly not a one time thing, happens often and in several installations, all of which are simple, out of the box configurations, no fancy file manipulations etc…
Asterisk (Ver. 11.8.1)
I understand you are giving the facts. No need to get upset. My point being that this is a direct Asterisk application is due to the fact that if this is a bug it can’t be filed here and would need to be filed with Asterisk so I am trying to get as much information out of you as possible and next I would need to see a call trace of when that happens. Especially if you can force it to happen regularly.
gotcha, thx… I am unable to force the condition… And I have standing orders into all 3 clients to document date and time when they experience this, and contact me ASAP. That’s been the biggest problem. Thanks again, and sorry if I came off as upset, didn’t mean to.
I guess I was hoping that someone else had experienced this same condition and maybe there was already a solution. I will post to Asterisk as well.
I checked with a few Asterisk developers and they have never heard of this issue. So when it happens get the logs and I can send it to them for review.
will do… thanks.
I had something along the same lines and tracked down an issue in Park Pro here: http://www.freepbx.org/forum/distro-discussion-help/park-slot-jumps-to-a-lower-number-72-moves-to-71-etc
While perhaps “related” this is in fact a completely different issue. Your issue resulted in the wrong “number” being announced but not multiple people talking at the same time to each other and if you look further and follow all of the links you wind up at a ticket about a syntax error from the dialplan which would break dialplan logic. As I previously stated. Being Parked avoids dialplan logic, there is none, you say/tell the call to “Park” and then Asterisk takes care of the details, you get the call back into the dialplan on a timeout or a pickup but there is really nothing FreePBX could do with the call in the middle of a park in terms of people talking to each other.
Any ideas on this issue. I have two systems that randomly do this. they are FreePBX ver 2.11. I realize it might be an asterisk issue. Not that I have enough to do right now sigh…
I just had a report from my users that this has happened twice today. FreePBX 5.211.65-19, asterisk 11.13.00.
Digium phones.
The user receives a call, presses the “park” softkey and the call is parked. Another user does the same thing and the calls get connected and dropped from the phone system.
Anyone have any knowledge of a cause or fix?
There’s nothing that would be specific to Digium’s phones there. The Park softkey is only performing a blind transfer directly into the extension defined for parking for the phone. It’s the same as doing an actual transfer directly into 700. The phone isn’t selecting the lot to put the caller into, Asterisk is.
If anything it’s an asterisk bug because asterisk handles the “park”-ing functionality. Really can’t be a FreePBX issue (the code/dialplan for parking is in C not dialplan)
Unless the user transfers a call to a parking slot as opposed to a parking lot.