All circuits are busy - to a certain number.

Discussion in 'General' started by hinzinho, Feb 3, 2011.

  1. hinzinho

    Joined:
    Sep 18, 2009
    Messages:
    461
    Likes Received:
    0
    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')
    
     
  2. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    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)
     
  3. hinzinho

    Joined:
    Sep 18, 2009
    Messages:
    461
    Likes Received:
    0
    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
     
  4. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    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.
     
  5. chucky

    Joined:
    Jun 29, 2010
    Messages:
    4
    Likes Received:
    0
    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 :)
     
  6. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    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,!!)
     
  7. hinzinho

    Joined:
    Sep 18, 2009
    Messages:
    461
    Likes Received:
    0
    Yes I have. Able to call the same number from another telco provider.

    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 #.
     
  8. hinzinho

    Joined:
    Sep 18, 2009
    Messages:
    461
    Likes Received:
    0
    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 "<".
     

Share This Page