Incorrect PRI cause code treatment

I am running FreePBX 2.8.0.4 on Asterisk 1.6.2.1 on a pair of Ubuntu Lucid Lynx servers. Each server has 7 CPE side PRI trunks. When SIP user makes an outbound call to an invalid number the Network side of the outbound PRI trunk returns PRI cause code 1 (Unassigned Number). The SIP user is then played the message “All circuits are busy please try your call again later.” I believe it should actually receive something like “The number dialed is disconnected or no longer in service. Please check the number and try again.”

Searching turned up this bug, resolved in 2.6: http://www.freepbx.org/trac/ticket/3805

It seems like this was a known issue and resolved a year ago so I’m wondering what I might be doing wrong. Anyone have a suggestion?

This is the PRI disconnect messaging from the Network side PRI. It sends the disconnect with Cause 1.
09:27:09 ISDN.L2_FMT PRI 1 =====================================================
09:27:09 ISDN.L2_FMT PRI 1 Sent = Sapi:00 C/R:C Tei:00
09:27:09 ISDN.L2_FMT PRI 1 Ctl:INFO Ns:124 Nr:121
09:27:09 ISDN.L2_FMT PRI 1 Prot:08 CRL:2 CRV:8006
09:27:09 ISDN.L2_FMT PRI 1 M - 45 DISCONNECT
09:27:09 ISDN.L2_FMT PRI 1 IE - 08 CAUSE Len=2
09:27:09 ISDN.L2_FMT PRI 1 82 Location:LN
09:27:09 ISDN.L2_FMT PRI 1 81 Cause:1 (UNASSIGNED_NUMBER)
09:27:09 ISDN.L2_FMT PRI 1 =====================================================
09:27:09 ISDN.L2_FMT PRI 1 Recd = Sapi:00 C/R:R Tei:00
09:27:09 ISDN.L2_FMT PRI 1 Ctl:INFO Ns:121 Nr:125
09:27:09 ISDN.L2_FMT PRI 1 Prot:08 CRL:2 CRV:0006
09:27:09 ISDN.L2_FMT PRI 1 M - 4D RELEASE
09:27:09 ISDN.L2_FMT PRI 1 IE - 08 CAUSE Len=2
09:27:09 ISDN.L2_FMT PRI 1 81 Location:LPN
09:27:09 ISDN.L2_FMT PRI 1 81 Cause:1 (UNASSIGNED_NUMBER)

[Jan 13 09:27:32] VERBOSE[29732] app_dial.c: – Called g6/3038357330
[Jan 13 09:27:32] VERBOSE[29732] app_dial.c: – DAHDI/121-1 is proceeding passing it to SIP/9985-00000009
[Jan 13 09:27:36] VERBOSE[28006] chan_dahdi.c: – Channel 0/1, span 6 got hangup request, cause 1
[Jan 13 09:27:36] VERBOSE[29732] chan_dahdi.c: – Hungup ‘DAHDI/121-1’
[Jan 13 09:27:36] VERBOSE[29732] app_dial.c: == Everyone is busy/congested at this time (1:0/0/1)
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s@macro-dialout-trunk:20] e[1;36mNoOpe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35mDial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 1e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s@macro-dialout-trunk:21] e[1;36mGotoe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35ms-CHANUNAVAIL,1e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Goto (macro-dialout-trunk,s-CHANUNAVAIL,1)
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s-CHANUNAVAIL@macro-dialout-trunk:1] e[1;36mSete[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35mRC=1e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s-CHANUNAVAIL@macro-dialout-trunk:2] e[1;36mGotoe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35m1,1e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Goto (macro-dialout-trunk,1,1)
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [1@macro-dialout-trunk:1] e[1;36mGotoe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35mcontinue,1e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Goto (macro-dialout-trunk,continue,1)
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [continue@macro-dialout-trunk:1] e[1;36mGotoIfe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35m1?noreporte[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Goto (macro-dialout-trunk,continue,3)
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [continue@macro-dialout-trunk:3] e[1;36mNoOpe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35mTRUNK Dial failed due to CHANUNAVAIL HANGUPCAUSE: 1 - failing through to other trunkse[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [continue@macro-dialout-trunk:4] e[1;36mSete[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35mCALLERID(number)=9985e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [*063038357330@from-internal:7] e[1;36mMacroe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35moutisbusy,e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s@macro-outisbusy:1] e[1;36mProgresse[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35me[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s@macro-outisbusy:2] e[1;36mGotoIfe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35m0?emergency,1e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s@macro-outisbusy:3] e[1;36mGotoIfe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35m0?intracompany,1e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s@macro-outisbusy:4] e[1;36mPlaybacke[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35mall-circuits-busy-now&pls-try-call-later, noanswere[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] file.c: – <SIP/9985-00000009> Playing ‘all-circuits-busy-now.ulaw’ (language ‘en’)
[Jan 13 09:27:38] VERBOSE[29732] file.c: – <SIP/9985-00000009> Playing ‘pls-try-call-later.ulaw’ (language ‘en’)
[Jan 13 09:27:39] VERBOSE[29732] app_macro.c: == Spawn extension (macro-outisbusy, s, 4) exited non-zero on ‘SIP/9985-00000009’ in macro ‘outisbusy’

[Jan 13 09:27:32] VERBOSE[29732] app_dial.c: – Called g6/3038357330
[Jan 13 09:27:32] VERBOSE[29732] app_dial.c: – DAHDI/121-1 is proceeding passing it to SIP/9985-00000009
[Jan 13 09:27:36] VERBOSE[28006] chan_dahdi.c: – Channel 0/1, span 6 got hangup request, cause 1
[Jan 13 09:27:36] VERBOSE[29732] chan_dahdi.c: – Hungup ‘DAHDI/121-1’
[Jan 13 09:27:36] VERBOSE[29732] app_dial.c: == Everyone is busy/congested at this time (1:0/0/1)
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s@macro-dialout-trunk:20] e[1;36mNoOpe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35mDial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 1e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s@macro-dialout-trunk:21] e[1;36mGotoe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35ms-CHANUNAVAIL,1e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Goto (macro-dialout-trunk,s-CHANUNAVAIL,1)
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s-CHANUNAVAIL@macro-dialout-trunk:1] e[1;36mSete[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35mRC=1e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s-CHANUNAVAIL@macro-dialout-trunk:2] e[1;36mGotoe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35m1,1e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Goto (macro-dialout-trunk,1,1)
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [1@macro-dialout-trunk:1] e[1;36mGotoe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35mcontinue,1e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Goto (macro-dialout-trunk,continue,1)
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [continue@macro-dialout-trunk:1] e[1;36mGotoIfe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35m1?noreporte[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Goto (macro-dialout-trunk,continue,3)
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [continue@macro-dialout-trunk:3] e[1;36mNoOpe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35mTRUNK Dial failed due to CHANUNAVAIL HANGUPCAUSE: 1 - failing through to other trunkse[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [continue@macro-dialout-trunk:4] e[1;36mSete[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35mCALLERID(number)=9985e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [*063038357330@from-internal:7] e[1;36mMacroe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35moutisbusy,e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s@macro-outisbusy:1] e[1;36mProgresse[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35me[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s@macro-outisbusy:2] e[1;36mGotoIfe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35m0?emergency,1e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s@macro-outisbusy:3] e[1;36mGotoIfe[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35m0?intracompany,1e[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] pbx.c: – Executing [s@macro-outisbusy:4] e[1;36mPlaybacke[0m(“e[1;35mSIP/9985-00000009e[0m”, “e[1;35mall-circuits-busy-now&pls-try-call-later, noanswere[0m”) in new stack
[Jan 13 09:27:36] VERBOSE[29732] file.c: – <SIP/9985-00000009> Playing ‘all-circuits-busy-now.ulaw’ (language ‘en’)
[Jan 13 09:27:38] VERBOSE[29732] file.c: – <SIP/9985-00000009> Playing ‘pls-try-call-later.ulaw’ (language ‘en’)
[Jan 13 09:27:39] VERBOSE[29732] app_macro.c: == Spawn extension (macro-outisbusy, s, 4) exited non-zero on ‘SIP/9985-00000009’ in macro ‘outisbusy’

The chan_dahdi_custom.conf section for this trunk (g6):
group = 6
signalling = pri_cpe
switchtype = national
resetinterval = 3600
echocancel = yes
context = from-internal
usecallerid = yes
callerid = asreceived
threewaycalling = yes
channel => 121-143

P.S. these servers are used in a lab environment and not to carry customer call traffic so suggestions that could cause outages are welcome.

I still haven’t been able to resolve this. Can anyone help? Thanks!

I had the same problem, drove me slightly nuts because the failing system is identical to one that works - PRI, Asterisk, Sangoma, same config.

What I found was that cause code 1, unassigned number, means that the PRI service provider is not letting you place calls using a CLID that is not one of the TNs assigned to that PRI. So before you place the outbound call, do this:

exten => whatever,n,Set(CALLERID(num)=NPANXXXXXX)

where NPANXXXXXX is one of your assigned numbers, eg 2125551212

(P.S. the bug fix you reference is not related to this situation - it’s what happens when you dial a number that does not exist. This current problem is what happens when your outbound caller ID is not one of your assigned numbers)