HELP Total Mystery: No outgoing calls - cause 41

So, everything run perfect (well almost) for about a year, when we had a network problem and were forced to change the modem/router. Freepbx worked fine for about half a day, when suddenly none of the extensions can make outgoing calls, except one (1), for a reason that doesn’t make sense. Checked logs for the extension that works, versus extensions that don’t work and everything is fine (and the same) except hangup - cause 41. Log:

[2020-08-18 22:00:49] VERBOSE[21016][C-00000004] pbx.c: Executing [[email protected]:5] While(“DAHDI/i1/1234567890-4”, “0”) in new stack
[2020-08-18 22:00:49] VERBOSE[21016][C-00000004] pbx.c: Executing [[email protected]:14] Return(“DAHDI/i1/1234567890-4”, “”) in new stack
[2020-08-18 22:00:49] VERBOSE[21016][C-00000004] app_stack.c: Spawn extension (from-digital, 01234567890, 1) exited non-zero on ‘DAHDI/i1/1234567890-4’
[2020-08-18 22:00:49] VERBOSE[21016][C-00000004] app_stack.c: DAHDI/i1/1234567890-4 Internal Gosub(func-apply-sipheaders,s,1(1)) complete GOSUB_RETVAL=
[2020-08-18 22:00:49] VERBOSE[21016][C-00000004] sig_pri.c: Requested transfer capability: 0x00 - SPEECH
[2020-08-18 22:00:49] VERBOSE[21016][C-00000004] app_dial.c: Called DAHDI/g0/1234567890
[2020-08-18 22:00:49] VERBOSE[9165][C-00000004] sig_pri.c: Span 1: Channel 0/1 got hangup, cause 41
[2020-08-18 22:00:49] VERBOSE[21016][C-00000004] app_dial.c: DAHDI/i1/1234567890-4 is circuit-busy
[2020-08-18 22:00:49] VERBOSE[21016][C-00000004] chan_dahdi.c: Hungup ‘DAHDI/i1/1234567890-4’
[2020-08-18 22:00:49] VERBOSE[21016][C-00000004] app_dial.c: Everyone is busy/congested at this time (1:0/1/0)
[2020-08-18 22:00:49] VERBOSE[21016][C-00000004] pbx.c: Executing [[email protected]:35] NoOp(“PJSIP/999-00000003”, “Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 41”) in new stack
[2020-08-18 22:00:49] VERBOSE[21016][C-00000004] pbx.c: Executing [[email protected]:36] GotoIf(“PJSIP/999-00000003”, “0?continue,1:s-CONGESTION,1”) in new stack
[2020-08-18 22:00:49] VERBOSE[21016][C-00000004] pbx_builtins.c: Goto (macro-dialout-trunk,s-CONGESTION,1)
[2020-08-18 22:00:49] VERBOSE[21016][C-00000004] pbx.c: Executing [[email protected]:1] Set(“PJSIP/999-00000003”, “RC=41”) in new stack
[2020-08-18 22:00:49] VERBOSE[21016][C-00000004] pbx.c: Executing [[email protected]:2] Goto(“PJSIP/999-00000003”, “41,1”) in new stack

Also, I did upgrade to the last version before the problem started…

I assume that with extensions on the LAN and a PRI trunk, normal calls don’t depend on the internet at all. While the modem/router could be supplying a supporting function (DHCP, DNS, etc.) that changed, I suspect that the trouble lies elsewhere.

Do you see any difference in the extension that’s working? If the outbound caller ID is different, temporarily change Outbound CID for a failing extension to that value and test. Or, does the working extension access a different Outbound Route, which might have a failover trunk, etc? If so, try changing the restrictions on a failing extension to match.

You could also enable debugging for DAHDI and PRI. If that shows that the carrier is rejecting the call for no apparent reason, perhaps a ticket with them is in order.

OH MAN!! Found it, after 10 hours of searching… For some reason when I remove the CID from the trunk, everything works fine! WHY??

Many carriers will only accept CID within the ‘common block(s)’ of numbers assigned to the PRI

I’m guessing that the trunk CID was not in the format the carrier wants, or not a number part of your block. The working extension had a proper Outbound CID that overrode the trunk CID.

IMO, the trunk should have a valid properly formatted CID, probably your main company number. Then, set up extensions and/or outbound routes to specify other CIDs as needed.

The Carrier is the same as before. They didn’t change something because I spoke with them on the phone. So what gives? By the way, 24h later, everything works smoothly without the CID…

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