Queue and all-circuits-busy-now

Hello there.

Ive had a read around and also searched google for answer which I am failing to find - so any help would be great.

Im running AAH and seeing the following problem.

When our office is closed, we run a “oncall” service which diverts to 3 local exts. and 2 remote numbers.

I have created a queue for this and entered the numbers as follows; (for the 07 mobile numbers, I have dialling rules which work).

22xx
22xx
22xx
07799xxxxxx
07774xxxxxx

All phones ring as they should, however, it seems should one of the mobiles be off or reject the call, the caller will hear the all-circuits-busy-now and the call will drop.

Ideally, I want the queue (or whole system) to stop giving that message and carry on trying until it can be picked up.

Is this possible?

Thanks

Matt

The issue appears to be that your mobile carrier is actually answering the call and playing the message. Therefore if the mobiles are off or out-of-range and immediately pick-up to play a message or voicemail then indeed that will be the first line to catch the call in the queue.

MuppetMaster,

Both numbers are on different networks and dont have voicemail. If what you are saying is true - if it was classed as a pickup it would surely connect the user on hold?

It seems it is signalling to Asterisk that “im busy, go away” and Asterisks passes that message onto the end user as “circuits busy” - which is what I want to avoid.

Matt

[quote=“msmartinwsx”]MuppetMaster,

Both numbers are on different networks and dont have voicemail. If what you are saying is true - if it was classed as a pickup it would surely connect the user on hold?

It seems it is signalling to Asterisk that “im busy, go away” and Asterisks passes that message onto the end user as “circuits busy” - which is what I want to avoid.

Matt[/quote]

I do not think that Asterisk is playing a message that ‘all circuits are busy’ as you would have to specifically program this into your dialplan/queues.conf. So I believe the line is being connected and that it is the network provider playing that message, although without seeing your verbose CLI it is hard to say for sure.

One solution may be to not use a queue and instead do a dial that upon answer does an Answering Machine detection (or just in this case as a ‘automated message’ detection):

voip-info.org/wiki/index.php … t%20(addon

If it finds one, try to dial again while dropping the line that had the answering machine/automated message. I have tried the Answering Machine detection and it seems to work well, but I have not done it for this type of an application.

Hi again,

I can paste the CLI output at the time - however, Asterisk is playing the sound file for that message and in the american accent.

Im going to look at that link now, however, as the call is not reaching the mobile voicemail (as I dont have it) - Im not sure if it will help.

Matt

[quote=“msmartinwsx”]Hi again,

I can paste the CLI output at the time - however, Asterisk is playing the sound file for that message and in the american accent.

Im going to look at that link now, however, as the call is not reaching the mobile voicemail (as I dont have it) - Im not sure if it will help.

Matt[/quote]

I would be interested to know more about your setup, in terms of:

  • PSTN interconnection
  • Dialplan
  • queues.conf

Have you specifically configured Asterisk to play ‘all-circuits-busy-now.gsm’ in your configuration? Also, and I know this is a long shot, ‘the voice’ does do voice overs for other providers besides Asterisk.

Hi there,

We have no actual pstn lines connected to the box. We use services from Gradwell.com.

All outbound calls are passed to them and then outbound from there. The message isnt caused on their end by something like congestion as we are not getting that error (and on checking with them, the call has already been passed the PSTN side of things fine)

As far as I know and can see in the AAH config - there are no dialplans, however, I could be wrong :wink:

The queue concerned is;

[5009]
wrapuptime=0
timeout=15
strategy=ringall
retry=1
queue-youarenext=queue-youarenext
queue-thereare=queue-thereare
queue-thankyou=queue-thankyou
queue-callswaiting=queue-callswaiting
music=default
monitor-join=yes
monitor-format=
member=Local/2211@from-internal/n
member=Local/2210@from-internal/n
member=Local/2201@from-internal/n
member=Local/077xxxxxxxx@from-internal/n
member=Local/077xxxxxxxx@from-internal/n
maxlen=0
leavewhenempty=no
joinempty=yes
context=
announce-holdtime=yes
announce-frequency=120

The messages are definately generated by Asterisk. I have called both numbers when off/rejected and they both given different messages by different speaking, english (british) people.

Just to add to this. It appears that the mobile network is signalling that the phone cant be called because it is off/busy but then asterisk completely dumps the call.

Two CLI logs, the first was when I rejected the call - the second was when the phone was off.

—1
– Executing Goto(“Local/077xxxxxxxx@from-internal-be9a,2”, “s-NOANSWER|1”) in new stack
– Goto (macro-dialout-trunk,s-NOANSWER,1)
– Executing NoOp(“Local/077xxxxxxxx@from-internal-be9a,2”, “Dial failed due to NOANSWER”) in new stack
– Executing Macro(“Local/077xxxxxxxx@from-internal-be9a,2”, “outisbusy”) in new stack
– Executing Playback(“Local/077xxxxxxxx@from-internal-be9a,2”, “all-circuit s-busy-now”) in new stack
– Local/077xxxxxxxx@from-internal-be9a,1 answered IAX2/gradwell-out-1
– Stopped music on hold on IAX2/gradwell-out-1
– Playing ‘all-circuits-busy-now’ (language ‘en’)

–2
– IAX2/gradwell-out-5 is making progress passing it to Local/077xxxxxxxx@from-internal-a986,2
– Hungup ‘IAX2/gradwell-out-5’
== No one is available to answer at this time (1:0/0/0)
– Executing Goto(“Local/077xxxxxxxx@from-internal-a986,2”, “s-NOANSWER|1”) in new stack
– Goto (macro-dialout-trunk,s-NOANSWER,1)
– Executing NoOp(“Local/077xxxxxxxx@from-internal-a986,2”, “Dial failed due to NOANSWER”) in new stack
– Executing Macro(“Local/077xxxxxxxx@from-internal-a986,2”, “outisbusy”) in new stack
– Executing Playback(“Local/077xxxxxxxx@from-internal-a986,2”, “all-circuits-busy-now”) in new stack
– Playing ‘all-circuits-busy-now’ (language ‘en’)
– Local/077xxxxxxxx@from-internal-a986,1 answered IAX2/gradwell-out-1
– Stopped music on hold on IAX2/gradwell-out-1

Ah, you are using Asterisk@Home, and not ‘core’ Asterisk alone, I should have picked up on that from your first post. Then, indeed, there may be something happening in there that you are not aware of. There are dial plans in Asterisk@Home, you just can not readily see them from the Web GUI. They would reside in the appropriate files in /etc/asterisk, but of course any changes you make there could cause issues with them being overwritten by AMP or consistency issues.

Now, somewhere within the bowels of A@H it is detecting the reject done by the mobile via IAX2 and then playing that message (you may see that in the Goto based on the hangup cause). I do not know enough about how A@H has built its dialplans and logic to know exactly how to handle this response differently than the way it is right now. But, this is entirely configurable, so it is ‘fixable’, just need to change the underlying A@H.

OK :smile:

I will have to have a poke around to see if it can silently accept the noanswer message and carry on or rety.

Matt

Right.

I have commented out this;

[macro-outisbusy]
;exten => s,1,Playback(all-circuits-busy-now)
;exten => s,2,Playback(pls-try-call-later)
;exten => s,3,Macro(hangupcall)

So that it does not hang up the call - which seems to be an interim solutions but instead of carry on ringing the other phones, it kills that and starts the queue again.

Is there anyway to carry on with that queue cycle instead of starting again? (That you know of)

You need to be able to determine which line actually returned the condition so that you are sure not to include it in the next go around. Instead of using a queue you could simply use a Dial command, something like:

This would ring all of the SIP extensions simultaneously. So, what you might be able to do is something like this, where you try the mobiles first, then if they do not answer you try the other numbers (or another strategy that is more appropriate for your use case):

[try_groups] exten => s,1,Dial(SIP/${MOBILE1}&SIP/${MOBILE2}|30|tT) exten => s,2,GotoIf($["${DIALSTATUS}" = "NOANSWER"]?3:4) exten => s,3,Dial(SIP/${LINE1}&SIP/${LINE2}|30|tT) exten => s,4,Hangup

This way if the mobiles do not answer after a 30 second dial attempt, or if they return prematurely because of a reject/turned-off, you may try the second group of landlines.

There may be more elegant ways to do this…

An additional option would be to use the Local Channel to effectively fork your dialplan. I have not tested, but theoretically this might solve the problem as well:

[code][try_group]

exten => s,1,Dial(Local/100@try_mobile&Local/100@try_fixed|30|tT)
exten => s,2,Goto(wrap_up|s|1)

[try_mobile]

exten => 100,1,Dial(SIP/${MOBILE1}&${MOBILE2}|30|tT)
exten => 100,2,GotoIf($["${DIALSTATUS}" = “ANSWER”]?4:3)
exten => 100,3,Wait(35)
exten => 100,4,Hangup

[try_fixed]

exten => 100,1,Dial(SIP/${FIXED1}&${FIXED2}|30|tT)
exten => 100,2,Goto(wrap_up|s|1)

[wrap_up]

exten => s,1,Voicemail(u${WHOEVER})
exten => s,2,Hangup[/code]

Like I said, I have not tested and thinking out loud here, but worth a shot if you need more control.

One last thought, you might try two different queues. One with the mobiles and one with the fixed lines, or one for each mobile, etc. This way, if you get an early return on the mobiles the call is still queued elsewhere.

Once again, thinking out loud.

You have to make sure you are making changes in such a way as not to impact other aspects of A@H or be overwritten the next time you change something via the Web GUI.

Hi,

Im abit lost with how and where to add that - also how to replace the mobile variables with the numbers that need to be called :frowning:

Matt

[quote=“msmartinwsx”]Hi,

Im abit lost with how and where to add that - also how to replace the mobile variables with the numbers that need to be called :frowning:

Matt[/quote]

Bridging the A@H configuration/logic with core Asterisk ‘programming’ is a bit mystical for me too. My experience with A@H is with the GUI, as I never looked under the hood to see how it worked its magic.

Hehe :smile:

I’ll go off and have a play.

Thanks for your help.