Using FreePBX 13.0.192.16 with Polycom phones (a lot of IP331) and EPM.
Recently I’ve been getting reports of users trying to make a call and the call wouldn’t go through, apparently because no line was available.
Our SIP provider set us up with several trunks, each of them having 4 SIP channels.
I’ve been checking the peek of active calls during the day (both incoming and outgoing) and we’re very far from the capacity.
I double checked my outgoing routes and all trunks are made available.
So I’m trying to troubleshoot this.
First I’m not trying to reproduce it.
The only thing I know to do this is to fire up the CLI with asterisk -vvvvvr
But this is really hard to follow for such a problem to troubleshoot, which - again - I cannot reproduce.
So I’m here, asking to see if there’s a way to monitor call flow and see the whole process…
User X places a call => Which dialplan rules are triggered ? => Which outbound route is used ? => Which trunk is used ?
Etc.
Is there a way to do that?
Also is there a way to see which calls failed and have info why?
Is there a tool which would help me monitor all this?
Finally, very important question: I see a lot of BUSY in the CDR report.
Is it possible that BUSY doesn’t always mean that the recipient of the call is BUSY?
Can it also mean that there’s no line to process the call?
Calls from a device are sent to the from-internal context. The Outbound Routes are checked in top-down order, the first match wins. The trunk that is used is the trunk set in the Outbound Routes.
And yeah BUSY means the user was busy, not that the call didn’t complete.
@BlazeStudios - excellent short-form version. Of course, as with most short answers about complicated questions, it’s a little more complicated by that, and part of that is through interactions provided in the Outbound Routes (which select the Trunks) and the Trunk rules. For example, you can turn on a setting on your route that says “If this route doesn’t work, try the next one.”
In addition, there are selectors that allow certain extensions to be routed through certain outbound routes and hence trunks.
Finally, as if the choices weren’t complicated enough, there are commercial packages that can make your choice of outbound route and trunk EVEN MORE convoluted.
On the busy thing: the recipient of the phone call sets the code (when you’re working with SIP) that determines what the call outcome is. Some remote endpoints aren’t particularly “forthcoming” when it comes to actual reasons why calls fail. For example, if a remote phone is unreachable (off-line, for example), a good provider will send “Nope - the code is something specific to the reason your call failed” but others will send “Busy” back for everything. I know it sounds a little bit “Wild West”, but the reason codes you are getting are what’s getting reported in your CDR report.
I was able to reproduce the problem today while a few people were on the phone.
Using the dialplan that catches local calls, I have an Outbound route that’s called “LOCAL” and has 2 trunks set up in it.
For a reason that I don’t understand, once the first trunk is congested, it will not go to the next trunk.
== Using SIP RTP CoS mark 5
-- Called SIP/Sortant 1/XXX
-- SIP/Sortant 1-0000075f redirecting info has changed, passing it to SIP/943-0000075e
-- SIP/Sortant 1-0000075f is busy
== Everyone is busy/congested at this time (1:1/0/0)
The trunk is called “Sortant 1” which is French for “Outgoing 1”.
I don’t understand why it doesn’t try the second trunk which is called “Sortant 2” and has 10 channels… this is my Outgoing route configuration:
I’ve also changed to change the order, and the same problem occurs: once the trunk “Sortant 2” (now in first position) doesn’t have any SIP channel left, it will not go to the next trunk “Sortant 1”
Well, well if I catcher your problem, for “Trunk Sequences for Matched Routes” you need to set on each sip providers “Maximum Channels” parameters.
If so how about to change the parameters of Maximum Channels?
Maximum Channels
Controls the maximum number of outbound channels (simultaneous calls) that can be used on this trunk. To count inbound calls against this maximum, use the auto-generated context: from-trunk-[trunkname] as the inbound trunk’s context (see extensions_additional.conf). Leave blank to specify no maximum.
Continue if Busy
Normally the next trunk is only tried upon a trunk being ‘Congested’ in some form, or unavailable. Checking this box will force a failed call to always continue to the next configured trunk or destination even when the channel reports BUSY or INVALID NUMBER. This should normally be unchecked
