Channel stucked in Confbridge and channel list is empty


Strange confbridge problem. Have a conference (defined with FreePBX 14) on Asterisk 16.9.0. It worked for some time, and now, after entering the PIN, it simply gets silent.
in CLI “confbridge list” lists is as active with 1 channel. When invoking “confbridge list 718”, it shows as if there are no channels on it. Now, if I invoke again “confbridge list”, I get an empty list. Only after closing and reopenning the CLI it will show the active bridges again. Looks like some corruption.

Any way to totaly kill a conference?

No, there is nothing to do such a thing. Conferences are driven by the channels in them. I’m not aware of any filed issues or recent issues in the ConfBridge area that are like this. Does the channel show in “core show channels”?

There was another post Single ConfBridge stuck on large server but I don’t remember seeing an issue get filed with info.

I have 1500 active channels. How can I know if one of them is inside the confBridge?
The post you refered me to, seems the exact same problem, only I have 3 such conferences. Should I open a case?

I’m the OP of the other mentioned thread. Yes this is exactly my issue as well. Confbridge list will show the conference with users in it, but attempting any manipulation of that conference via the CLI will crash the CLI.

I didn’t file a JIRA issue, because although this issue is happening frequently, I can’t reproduce it at will or obtain any useful information in a trace. Asterisk is definitely not crashed… It still processes calls. Just that one conference (it could be different every time) will stop responding.

The only piece of useful information I got from the marked user, is that right before this happens he hears what sounds like an audio loop - he hears himself talking and the echo keeps getting louder and faster and then the conference goes dead.

I have 1500 active channels.

The active channel list is totally messed up when this happens. Every channel that attempts to log into the conference will generate a zombied channel to that conference that will get stuck indefinitely.

Try ‘core show channels verbose’ and search for your confbridge number - you’ll see how many users are thought to be logged into that conference. Those channels are in fact dead.

You are right, have 59 zombies on that conference. Do you have any way of handling with this problem?

I’m sorry to say, but the only thing that worked for me was restarting Asterisk.

fwconsole restart

I’m also finding interesting that you’re running on FPBX14. I have multiple servers, some running vanilla Asterisk, some running FPBX15, and 1 running FPBX14, and the only one affected is the FPBX14 server. I didn’t think that was a factor until now, since all my dialplan is custom, I’m only using FPBX for UCP management of the conference.

This is interesting. I have another server with FreePBX, I will port all the confbridges to it, and see if that changes anything.

I think I figured out a majority of the issues I was having with conferencing, and I’m wondering if anyone has any ideas how to stop this…

Users in the conference are, intentionally or unintentionally, making a 3 way call on their own devices back into the conference, creating a loop. As long as the channels are muted, noone can tell the difference. Once mute goes off, the loop crashes that ConfBridge if the marked user doesn’t mute right away or hangup and kick the rest of the participants. @eyalhasson - can you verify if this is what’s happening to you?

So the question is - how in the world can I block entrance to a caller that is already in the conference?

I’ll try to ask our users if anyone have done such a thing, but we have many users so I am not sure we can get a distinctive answer.
Why does this loop crashes the confBridge?
As to ideas, maybe you can look at the caller ID’s of the already participent channels?

I’ll try to ask our users if anyone have done such a thing

None of my users knew they were doing this. Another private conversation I had with @jcolp clued me in to this, and after pouring over log files for 2 hours I realized that the same number was in the conference twice and they had called the DID only 30 seconds before the problem began. The only way I see this as being possible is that a 3 way call is being made by the end user. I can’t imagine it’s intentional - I suspect that there’s an audio hiccup and they think the call dropped, so they “redial” the number and press “send” on their cell - bridging the conferenece back into itself.

Restricting with caller ID may be my only option but it will impede on access of the system by any MLTS.

But why this situation crashes a bridge? What is it different from a pary making a 3 way call with another party?

I think we may need a definition of “crash”. There are two problems this could cause:

  1. howl round, because the audio output is being fed back in;

  2. locked up channels, because the bridge is keeping both ends up.

Is there some other definition of crashed?

Well, in our case the “crash” is more then this:
First, the bridge stops functioning. When you call it, after entring the PIN it gets silent - not asking to record the user’s name, and not connecting the parties into a conference.
Second, in the CLI, when trying to list the channels of this bridge, the CLI crashes - meaning it completely stops responding.

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