HELP Total Mystery: No outgoing calls - cause 41

FreePBX Providers
1

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

2

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

3

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.

4

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

5

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

6

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.

7

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…

8

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