All circuits are busy - to a certain number.

hinzinho

Joined
Sep 18, 2009
Messages
461
Likes
0
Points
0
#1
I am trying to make a call to 800.547.2325 (a conference number) and I am getting "all circuits are busy now". We are still able to make outgoing calls to different 800 numbers, just not to that one. I called our telco provider and they did a trap call. They said the call never got to their side and show no such attempt of calling the number. They suggested the issue is on my PBX. Is this the case?

I am using a PRI circuit and using G0 as the trunk name.

My outbound route has this as the dialing rules:
Code:
311
411
911
011.
1800NXXXXXX
1866NXXXXXX
1877NXXXXXX
1888NXXXXXX
1NXXNXXXXXX
NXXNXXXXXX
NXXXXXX
Entries from the log file.
Code:
Feb 3 09:47:00  	VERBOSE  	[32239] logger.c:  	-- Executing [s@macro-dialout-trunk:18] GotoIf("SIP/5034-ac08e480", "0?customtrunk") in new stack
Feb 3 09:47:00 	DEBUG 	[32239] app_macro.c: 	Executed application: GotoIf
Feb 3 09:47:00 	VERBOSE 	[32239] logger.c: 	-- Executing [s@macro-dialout-trunk:19] Dial("SIP/5034-ac08e480", "DAHDI/G0/18005472325|300|") in new stack
Feb 3 09:47:00 	NOTICE 	[32239] app_dial.c: 	Hey! chan SIP/5034-ac08e480's context='macro-dialout-trunk', and exten='s'
Feb 3 09:47:00 	VERBOSE 	[32239] logger.c: 	-- Requested transfer capability: 0x00 - SPEECH
Feb 3 09:47:00 	VERBOSE 	[32239] logger.c: 	-- Called G0/18005472325
Feb 3 09:47:00 	DEBUG 	[19141] chan_dahdi.c: 	Queuing frame from PRI_EVENT_PROCEEDING on channel 0/22 span 1
Feb 3 09:47:00 	VERBOSE 	[32239] logger.c: 	-- DAHDI/22-1 is proceeding passing it to SIP/5034-ac08e480
Feb 3 09:47:02 	VERBOSE 	[19141] logger.c: 	-- Channel 0/22, span 1 got hangup request, cause 31
Feb 3 09:47:02 	WARNING 	[32239] app_dial.c:  Unable to forward voice or dtmf
Feb 3 09:47:02 	DEBUG 	[32239] chan_dahdi.c: 	Set option AUDIO MODE, value: ON(1) on DAHDI/22-1
Feb 3 09:47:02 	DEBUG 	[32239] chan_dahdi.c: 	Not yet hungup...  Calling hangup once with icause, and clearing call
Feb 3 09:47:02 	DEBUG 	[32239] chan_dahdi.c: 	Set option AUDIO MODE, value: OFF(0) on DAHDI/22-1
Feb 3 09:47:02 	VERBOSE 	[32239] logger.c: 	-- Hungup 'DAHDI/22-1'
Feb 3 09:47:02 	VERBOSE 	[32239] logger.c: 	== Everyone is busy/congested at this time (1:0/0/1)
Feb 3 09:47:02 	DEBUG 	[32239] app_macro.c: 	Executed application: Dial
Feb 3 09:47:02 	VERBOSE 	[32239] logger.c: 	-- Executing [s@macro-dialout-trunk:20] Goto("SIP/5034-ac08e480", "s-CHANUNAVAIL|1") in new stack
Feb 3 09:47:02 	VERBOSE 	[32239] logger.c: 	-- Goto (macro-dialout-trunk,s-CHANUNAVAIL,1)
Feb 3 09:47:02 	DEBUG 	[32239] app_macro.c: 	Executed application: Goto
Feb 3 09:47:02 	VERBOSE 	[32239] logger.c: 	-- Executing [s-CHANUNAVAIL@macro-dialout-trunk:1] GotoIf("SIP/5034-ac08e480", "1?noreport") in new stack
Feb 3 09:47:02 	VERBOSE 	[32239] logger.c: 	-- Goto (macro-dialout-trunk,s-CHANUNAVAIL,3)
Feb 3 09:47:02 	DEBUG 	[32239] app_macro.c: 	Executed application: GotoIf
Feb 3 09:47:02 	VERBOSE 	[32239] logger.c: 	-- Executing [s-CHANUNAVAIL@macro-dialout-trunk:3] NoOp("SIP/5034-ac08e480", "TRUNK Dial failed due to CHANUNAVAIL (hangupcause: 31) - failing through to other trunks") in new stack
Feb 3 09:47:02 	DEBUG 	[32239] app_macro.c: 	Executed application: Noop
Feb 3 09:47:02 	VERBOSE 	[32239] logger.c: 	-- Executing [18005472325@from-internal:5] Macro("SIP/5034-ac08e480", "outisbusy|") in new stack
Feb 3 09:47:02 	VERBOSE 	[32239] logger.c: 	-- Executing [s@macro-outisbusy:1] Playback("SIP/5034-ac08e480", "all-circuits-busy-now|noanswer") in new stack
Feb 3 09:47:02 	VERBOSE 	[32239] logger.c: 	-- <SIP/5034-ac08e480> Playing 'all-circuits-busy-now' (language 'en')
Feb 3 09:47:04 	DEBUG 	[32239] app_macro.c: 	Executed application: Playback
Feb 3 09:47:04 	VERBOSE 	[32239] logger.c: 	-- Executing [s@macro-outisbusy:2] Playback("SIP/5034-ac08e480", "pls-try-call-later|noanswer") in new stack
Feb 3 09:47:04 	VERBOSE 	[32239] logger.c: 	-- <SIP/5034-ac08e480> Playing 'pls-try-call-later' (language 'en')
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#2
I might question their statement that they didn't get the call
.
.
Feb 3 09:47:00 VERBOSE [32239] logger.c: -- Requested transfer capability: 0x00 - SPEECH
Feb 3 09:47:00 VERBOSE [32239] logger.c: -- Called G0/18005472325
Feb 3 09:47:00 DEBUG [19141] chan_dahdi.c: Queuing frame from PRI_EVENT_PROCEEDING on channel 0/22 span 1
Feb 3 09:47:00 VERBOSE [32239] logger.c: -- DAHDI/22-1 is proceeding passing it to SIP/5034-ac08e480
Feb 3 09:47:02 VERBOSE [19141] logger.c: -- Channel 0/22, span 1 got hangup request, cause 31
.
.

seems to suggest otherwise cause 31 is often an upline routing problem, turn on PRI debugging in asterisk and you will get more detail (ammunition)
 

hinzinho

Joined
Sep 18, 2009
Messages
461
Likes
0
Points
0
#3
Took me a while to figure how to use the PRI debug statement. lol! In case someone come across this, I ran these commands:

# touch /tmp/pridebug.txt
# chown asterisk pridebug.txt
# chgrp asterisk pridebug.txt
# asterisk -r
CLI> pri set debug file /tmp/pridebug.txt
CLI> pri debug span 1
after I'm done with the debug, turn off the debug
CLI> pri no debug span 1


Dicko, here's the output of the pri debug from two calls to that number. Hope it make senses to you as it's doesn't for me. Thanks!

Code:
-- Making new call for cr 33209
> Protocol Discriminator: Q.931 (8)  len=47
> Call Ref: len= 2 (reference 441/0x1B9) (Originator)
> Message type: SETUP (5)
> [04 03 80 90 a2]
> Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
>                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
>                                User information layer 1: u-Law (34)
> [18 03 a1 83 97]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0  Preferred  Dchan: 0
>                        ChanSel: As indicated in following octets
>                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
>                       Ext: 1  Channel: 23 ]
> [1e 02 80 83]
> Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: User (0)
>                               Ext: 1  Progress Description: Calling equipment is non-ISDN. (3) ]
> [6c 0c 21 80 39 32 35 39 33 34 33 32 33 35]
> Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
>                           Presentation: Presentation permitted, user number not screened (0)  '9999999999' ]
> [70 0c a1 31 38 30 30 35 34 37 32 33 32 35]
> Called Number (len=14) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)  '18005472325' ]
q931.c:3134 q931_setup: call 33209 on channel 23 enters state 1 (Call Initiated)
 Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 441/0x1B9) (Originator)
> Message type: RELEASE (77)
> [08 02 81 9f]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal, unspecified (31), class = Normal Event (1) ]
 Protocol Discriminator: Q.931 (8)  len=46
> Call Ref: len= 2 (reference 442/0x1BA) (Originator)
> Message type: SETUP (5)
> [04 03 80 90 a2]
> Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
>                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
>                                User information layer 1: u-Law (34)
> [18 03 a1 83 97]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0  Preferred  Dchan: 0
>                        ChanSel: As indicated in following octets
>                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
>                       Ext: 1  Channel: 23 ]
> [1e 02 80 83]
> Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: User (0)
>                               Ext: 1  Progress Description: Calling equipment is non-ISDN. (3) ]
> [6c 0c 21 80 39 32 35 39 33 34 33 32 33 35]
> Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
>                           Presentation: Presentation permitted, user number not screened (0)  '9999999999' ]
> [70 0b a1 38 30 30 35 34 37 32 33 32 35]
> Called Number (len=13) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)  '8005472325' ]
q931.c:3134 q931_setup: call 33210 on channel 23 enters state 1 (Call Initiated)
 Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 442/0x1BA) (Originator)
> Message type: RELEASE (77)
> [08 02 81 9f]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal, unspecified (31), class = Normal Event (1) ]
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 442/0x1BA) (Terminator)
< Message type: RELEASE COMPLETE (90)
q931.c:3766 q931_receive: call 33210 on channel 23 enters state 0 (Null)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
http://forum.elastix.org/old_files/pridebug.txt
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#4
That shows the call ARE being taken by your provider (your packets start with > theirs with < )

I would now take that back to your provider and ask why the are sending a disconnect cause 31 for calls to that number.
 

chucky

Joined
Jun 29, 2010
Messages
4
Likes
0
Points
0
#5
Have you tried calling the number from outside of your PBX environment to see if you get the same problem?

The reason I ask is that I had a similar problem with the 'all circuits busy' message when we were trying to connect to an unobtainable number from our PRI ISDN circuit. We were able to make calls to all other numbers without problem and quickly identified the problem by making a quick call to the problem number from outside of our PBX.

We have now modified our Elastix system to give out more meaningful messages when outbound calls are not successfully established.

Anyway, just a thought :)
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#6
I will expand, here in NANP land, where hinzhino and myself exist there are many regulations on who can call what toll free number, and from where and how that resporg (responsible organisation) has arranged access to and of course arranged payment for call completion, This number is owned by a "well known" VOIP provider here in the States, I noticed that some carriers will not complete that number, some will, hence my suggestion as to hinzhino's carrier as to why. His carrier will need to route this number to a peer that will complete it successfully (perhaps theyshould also learn to be more customer friendly :) , hinzinho's reported experience with his carrier will hopefully elucidate)

regards

dicko

(Shame on you S***tel for not knowing what you are doing or not arrangeing for compensation to the CLEC's and RBOC's that are apparently but reasonably denying those possibly unpaid for calls,!!)
 

hinzinho

Joined
Sep 18, 2009
Messages
461
Likes
0
Points
0
#7
Have you tried calling the number from outside of your PBX environment to see if you get the same problem?
Yes I have. Able to call the same number from another telco provider.

We have now modified our Elastix system to give out more meaningful messages when outbound calls are not successfully established.
Can you share with us how you able to modify this? I too would wish we have more meaningful messages than "all circuits are busy", even when calling an invalid #.
 

hinzinho

Joined
Sep 18, 2009
Messages
461
Likes
0
Points
0
#8
Well. My telco sent out a tech on-site and did a test call from their hand held device and got the same "disconnect" issue. The tech will pass this issue to their 2nd tier. Well, it's nice to know the issue is not on the PBX. Now time to sit and wait for the result.

Thanks Dicko for explaining about the ">" and "<".
 

Members online

No members online now.

Latest posts

Forum statistics

Threads
30,900
Messages
130,884
Members
17,561
Latest member
marouen
Top