This is intermittent but seems to happen more when the phones are ringing more. Sometimes there will be no audio in either direction for a few seconds (not a consistent amount of time). Trying to find the problem but not getting to the root. I saw massive spikes in CPU usage and disabling sangoma connect and the CRM modules helped there, but that’s not what was causing the issue.
Something I’m wondering is where all can concurrent RTP streams be limited? Could a call still be connected and just not pass any audio until enough other streams end? The router was changed recently so I’m trying to get the IT guys involved but this didnt start right away after the router swap.
There are a dozen phones ringing and most of them monitoring the other phones so there is a ton of stuff in the logs. Initially I was seeing that someone would say they answered the call and saw the timer running but couldnt hear anything but in the CDRs I’d see that someone else had answered it. Now I’m seeing that only one person answers and the audio eventually connects.
I have seen network congestion in the case of 20 phones in a ring group for incoming calls, and each phone had BLFs for all of the other phones. So on an incoming call it would flood the network with all of the SIP signaling and take a while to answer the call, but that wasn’t RTP only being delayed so if it looks like the phone answered the call it may be a different issue.
There hasnt been any complaints today yet other than one “all circuits busy” message but it turned out that it was a misdial. Just disabled that module to be safe. So far it’s been a quiter day than yesterday though, will have to wait until it gets busy.
Another thing I’ve seen for a long time (long before the router swap) is that when it gets busy the server says it has way too many concurrent calls going. Like 15-25, when in reality is more like 3-5. Those two spikes on the right side of the chart say 10 and 11 concurrent channels (I turned off follow me as a test as well).
When dialling happens all of the outgoing channels, and the incoming channel, are all handled in the same thread in Asterisk. When a channel is answered all the other dialled channels are hung up and then any hangup logic is executed on the channels that didn’t answer. Since this happens in the same thread the logic is executed on each channel one after another and only after this is done is the incoming channel talking to the answered outgoing channel. Normally this all happens quickly and you don’t know, but in the case of the missed call module it can take a period of time to send the missed call notification on all the outgoing channels that were hung up - and this adds up resulting in the incoming channel and the answered channel not talking.
I have an issue open on the Asterisk side to see if we can improve this, and FreePBX has one that I’ll mention this on as another report and see about moving it up in priority.
This is why the module was never an official FreePBX module and for other technical reasons. It was a community contributed module and not something during my reign we were willing to put into the mirror servers.
So far today everything has been fine. The last problem was reported shortly before 3pm yesterday, and the last thing I changed was uninstalling the CRM module (not that it was in use but I saw a lot of mentions of it in the asterisk log). Uninstalling CRM dropped the CPU spikes a fair amount and today disabling the missed call module further dropped thos spikes. If everything stays quiet I’ll update in a week to confirm that it’s really fixed.
Hmmm When I worked on this dev on Misscall, I had this kind of problem and I tried to find another logic to solve it. But another dev worked on it after.
But it seems there is a problem with the code and the dial plan. There is no RTP audio for a few seconds. Because if I remember correctly (In March 2023), the system is trying to find who is calling and it takes some time to process.
