Implementation for dialing extensions and then to IVR on timeout

Forums

Maybe just a brain-fart, but not finding a good way to implement this and hoping that someone has a suggestion. Here's the desired flow:

Inbound call comes in on DID
Ring extension 100
If 100 is busy, then ring extension 200
If no answer in 20 seconds, go to IVR main_menu

and for a different DID:

Inbound call comes in on DID
Ring extension 200
If 300 is busy, then ring extension 100
If no answer in 20 seconds, go to IVR main_menu

What is happening, is that even though the extension first rung is busy, "ringing' still occurs until the timeout and the IVR then gets played - even though the other extension is no busy.

This is all setup now as follows (and seems it was working but is no longer):

Forwarding (via user portal) on busy for extension 100 to 200, and visa-versa.
2 hunt lists setup to ring 100 (or 200) for 20 seconds and then to timeout to the IVR.

The Asterisk logs show:

[Feb 18 13:39:51] VERBOSE[24929] logger.c: -- Executing [s@macro-tl-userexten-rg-base:16] NoOp("Local/100@from-inside-tenant1-0000,2", "") in new stack [Feb 18 13:39:51] VERBOSE[24929] logger.c: -- Executing [s@macro-tl-userexten-rg-base:17] NoOp("Local/100@from-inside-tenant1-0000,2", "RECORD_CALLEE=") in new stack [Feb 18 13:39:51] VERBOSE[24929] logger.c: -- Executing [s@macro-tl-userexten-rg-base:18] NoOp("Local/100@from-inside-tenant1-0000,2", "OPTIONS=irtT") in new stack [Feb 18 13:39:51] VERBOSE[24929] logger.c: -- Executing [s@macro-tl-userexten-rg-base:19] NoOp("Local/100@from-inside-tenant1-0000,2", "TOUCH_MONITOR=") in new stack [Feb 18 13:39:51] VERBOSE[24929] logger.c: -- Executing [s@macro-tl-userexten-rg-base:20] Set("Local/100@from-inside-tenant1-0000,2", "CDR(userfield)=tenant1") in new stack [Feb 18 13:39:51] VERBOSE[24929] logger.c: -- Executing [s@macro-tl-userexten-rg-base:21] ChanIsAvail("Local/100@from-inside-tenant1-0000,2", "SIP/100-tenant1") in new stack [Feb 18 13:39:51] VERBOSE[24929] logger.c: -- Executing [s@macro-tl-userexten-rg-base:22] GotoIf("Local/100@from-inside-tenant1-0000,2", "0?exit") in new stack [Feb 18 13:39:51] VERBOSE[24929] logger.c: -- Executing [s@macro-tl-userexten-rg-base:23] Dial("Local/100@from-inside-tenant1-0000,2", "SIP/100-tenant1|20|irtT") in new stack [Feb 18 13:39:51] VERBOSE[24929] logger.c: -- Called 100-tenant1 [Feb 18 13:39:51] VERBOSE[24928] logger.c: -- Local/100@from-inside-tenant1-0000,1 is ringing [Feb 18 13:39:51] VERBOSE[12817] logger.c: -- Got SIP response 486 "Busy Here" back from 10.10.10.10 [Feb 18 13:39:51] VERBOSE[24929] logger.c: -- SIP/100-tenant1-00993370 is busy [Feb 18 13:39:51] VERBOSE[24929] logger.c: == Everyone is busy/congested at this time (1:1/0/0) [Feb 18 13:39:51] VERBOSE[24929] logger.c: -- Executing [s@macro-tl-userexten-rg-base:24] MacroExit("Local/100@from-inside-tenant1-0000,2", "") in new stack

[Feb 18 13:40:01] VERBOSE[24929] logger.c: [Feb 18 13:40:01] VERBOSE[24929] logger.c: [Feb 18 13:40:01] VERBOSE[24929] logger.c: [Feb 18 13:40:01] VERBOSE[24929] logger.c: [Feb 18 13:40:01] VERBOSE[24929] logger.c: [Feb 18 13:40:01] VERBOSE[24929] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:01] VERBOSE[24928] logger.c: [Feb 18 13:40:04] VERBOSE[24928] logger.c: [Feb 18 13:40:04] VERBOSE[24928] logger.c: [Feb 18 13:40:04] VERBOSE[24928] logger.c: [Feb 18 13:40:04] VERBOSE[24928] logger.c: [Feb 18 13:40:04] VERBOSE[24928] logger.c: [Feb 18 13:40:04] VERBOSE[24928] logger.c: [Feb 18 13:40:04] VERBOSE[24928] logger.c: [Feb 18 13:40:04] VERBOSE[24928] logger.c: -- Timeout on Local/100@from-inside-tenant1-0000,2
== CDR updated on Local/100@from-inside-tenant1-0000,2
-- Executing [t@from-inside-redir-Leyendecker:1] Hangup("Local/100@from-inside-tenant1-0000,2", "") in new stack
== Spawn extension (from-inside-redir-tenant1, t, 1) exited non-zero on 'Local/100@from-inside-Leyendecker-0000,2'
-- Executing [h@from-inside-redir-tenant1:1] Hangup("Local/100@from-inside-tenant1-0000,2", "") in new stack
== Spawn extension (from-inside-redir-tenant1, h, 1) exited non-zero on 'Local/100@from-inside-tenant1-0000,2'
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [dial@macro-tl-ringgroup-base:3] Goto("SIP/5060-a09a07a0", "dial-CHANUNAVAIL|1") in new stack
-- Goto (macro-tl-ringgroup-base,dial-CHANUNAVAIL,1)
-- Executing [dial-CHANUNAVAIL@macro-tl-ringgroup-base:1] Goto("SIP/5060-a09a07a0", "failed|1") in new stack
-- Goto (macro-tl-ringgroup-base,failed,1)
-- Executing [failed@macro-tl-ringgroup-base:1] MacroExit("SIP/5060-a09a07a0", "") in new stack
-- Executing [s@MainLine-tenant1:2] Set("SIP/5060-a09a07a0", "__RINGGROUP_TIMEOUT=") in new stack
-- Executing [s@MainLine-tenant1:3] Macro("SIP/5060-a09a07a0", "tl-menu|Main_Menu_Open-tenant1|") in new stack
-- Executing [s@macro-tl-menu:1] Set("SIP/5060-a09a07a0", "CALLERID(name)=") in new stack
-- Executing [s@macro-tl-menu:2] Goto("SIP/5060-a09a07a0", "Main_Menu_Open-tenant1|s|1") in new stack
-- Goto (Main_Menu_Open-tenant1,s,1)
== Channel 'SIP/5060-a09a07a0' jumping out of macro 'tl-menu'
-- Executing [s@Main_Menu_Open-tenant1:1] GotoIf("SIP/5060-a09a07a0", "0?start") in new stack
-- Executing [s@Main_Menu_Open-tenant1:2] Set("SIP/5060-a09a07a0", "TL_LEVEL=1") in new stack
-- Executing [s@Main_Menu_Open-tenant1:3] Ringing("SIP/5060-a09a07a0", "") in new stack
-- Executing [s@Main_Menu_Open-tenant1:4] Wait("SIP/5060-a09a07a0", "3") in new stack
-- Executing [s@Main_Menu_Open-tenant1:5] Answer("SIP/5060-a09a07a0", "") in new stack
-- Executing [s@Main_Menu_Open-tenant1:6] NoOp("SIP/5060-a09a07a0", "") in new stack
-- Executing [s@Main_Menu_Open-tenant1:7] Set("SIP/5060-a09a07a0", "TIMEOUT(digit)=5") in new stack
-- Digit timeout set to 5
-- Executing [s@Main_Menu_Open-tenant1:8] Set("SIP/5060-a09a07a0", "TIMEOUT(response)=10") in new stack
-- Response timeout set to 10
-- Executing [s@Main_Menu_Open-tenant1:9] BackGround("SIP/5060-a09a07a0", "ogm/tenant1/Main") in new stack
-- Playing 'ogm/tenant1/Main' (language 'en')

Ideas? Or a better way to go about trying to do this that does not rely on settings through the User Portal?

Appreciate any feedback!

Submitted by eeman on Wed, 02/18/2009 Permalink

try using the huntlist creating ring groups of 1 member timing out at 20 seconds.

Submitted by axisinternet on Thu, 02/19/2009 Permalink

That is pretty much what I had (and still have) - an inbound route for each of the 2 DIDs - both going to hunt lists:

DID 1 hunt list

Call extension 100 with timeout of 20 seconds
on timeout, go to IVR

DID 2 hunt list

Call extension 200 with timeout of 20 seconds
on timeout, go to IVR

In User Portal for each extension (100 and 200), under Forwarding, they are setup to, if extension is busy, to ring the other. This is what's not happening. If a call comes in for DID 1 and extension 100 is busy, asterisk is waiting for the timeout anyway and then going to the IVR - does not try even to ring 200. And the same for DID 2.....

Submitted by eeman on Thu, 02/19/2009 Permalink

huntlist does not use user portal settings, it uses the macro-tl-userexten-rg-base script

the huntlist will not wait 20 seconds if you are giving a true busy back. are you sure its not just ringing in on call waiting? That is not the same as busy.

Submitted by axisinternet on Thu, 02/19/2009 Permalink

OK was getting the feeling the user settings did not apply with the hunt list....

But, even though Asterisk is told that the extension dialed is busy, it still waits until the timeout expires:

[Feb 18 13:39:51] VERBOSE[24929] logger.c: -- Executing [s@macro-tl-userexten-rg-base:23] Dial("Local/100@from-inside-tenant1-0000,2", "SIP/100-tenant1|20|irtT") in new stack

[Feb 18 13:39:51] VERBOSE[24929] logger.c: -- Called 100-tenant1

[Feb 18 13:39:51] VERBOSE[24928] logger.c: -- Local/100@from-inside-tenant1-0000,1 is ringing

[Feb 18 13:39:51] VERBOSE[12817] logger.c: -- Got SIP response 486 "Busy Here" back from 10.10.10.10

[Feb 18 13:39:51] VERBOSE[24929] logger.c: -- SIP/100-tenant1-00993370 is busy

[Feb 18 13:39:51] VERBOSE[24929] logger.c: == Everyone is busy/congested at this time (1:1/0/0)

[Feb 18 13:39:51] VERBOSE[24929] logger.c: -- Executing [s@macro-tl-userexten-rg-base:24] MacroExit("Local/100@from-inside-tenant1-0000,2", "") in new stack

[Feb 18 13:40:01] VERBOSE[24929] logger.c: -- Timeout on Local/100@from-inside-tenant1-0000,2

If it did proceed to dial the next extension, in the hunt list, I could add the next extension to dial and then timeout to the IVR. The script has only one timeout value, so if extension 100 was not busy, how long would it ring before going to the next extension and then the IVR - don't understand how the timeout would be applied in this situation....

Submitted by eeman on Thu, 02/19/2009 Permalink

if you are using the huntlist menu.. each ringgroup has its own timeout setting. Your capture shows that it did macro exit immediately at 13:29:51, but what I dont understand is the 10 second delayat 13:40:01

Submitted by axisinternet on Fri, 02/20/2009 Permalink

That 10 second delay is also something I'm not understanding...

I do see the time out in the huntlist setup for each ring group, which I could set to 20 seconds - but, then I would, for what I see, have 40 seconds before the IVR would be played - or whatever the group1+group2 added up to. They are not wanting 200 to ring unless 100 is busy and visa versa. So for extension 100:

Ring 100 for 20 seconds.
If 100 is busy, ring 200 instead
Go to the IVR

It's that step 2 that I'm having troubles figuring out how to accomplish.....

Chris

Submitted by eeman on Fri, 02/20/2009 Permalink

see I havent been experiencing that delay when I have 4 ring groups within a huntlist. I have some adtran TA908's providing FXS connections to customer's PBX equipment and they usually want hunting on their main number:

Ring group 1 rings extension 60 seconds

ring group 2 rings extension 60 seconds

and so on

and so forth

my final action was playback busy since all the lines in the huntlist were busy. While I never had every line busy out and call the 'when everything is busy' script, I can assure you that every ring group cycle was immediate. I never had to wait the 60 seconds.

based on your info it doesnt appear you would be waiting 40 seconds. You may find only the last step imposing a 10 second delay after a litany of extensions. Knowing what the actual delay is and if its cyclical would help pin down the exact problem.

Submitted by axisinternet on Fri, 02/20/2009 Permalink

How would I not have the 40 second delay potentially. If 100 rings for 20 seconds and there's no answer - then 200 rings for 20 seconds and there's no answer, then the IVR.....there's 40 seconds there of ringing.

The issue seems to be that I *only* want to ring the other extension if the first one is busy:

Dial(SIP/100);

if (IsBusy(SIP/100)) { Dial(SIP/200) };

if (NoAnswer) { Dial(IVR) };

Both 100 and 200 go to the same phone so, if she's not there to answer 100, she'll not be there to answer 200 either.....

Maybe huntlists are not the right way to go about this, but I've looked over Feature Codes, queues, combinations of them and nothing seems as quite suited for this functionality other than huntlists, but there I'm running into a wall as well.

Might have to just write a custom script to do this......

Submitted by eeman on Fri, 02/20/2009 Permalink

the possibility that each 20 sec delay is skipped (as it should be) once a busy message is returned and that your real and only delay is at the end of all the Dial applications.

scenario A

all numbers ring sequentially and immediately abandon to next number bypassing 20 second delays, finally after exhausting all numbers there is a delay before the script that launches IVR runs, and that delay showed as 10 seconds

scenario B

all numbers ring sequentially and despite reporting back busy, you are waiting 20 seconds at each and every step of the process.

you need to deterimine if you are scenario A or scenario B. I run them all the time and have never ever seen scenario B, and never checked on scenario A since i have never had every line busy.

Submitted by eeman on Fri, 02/20/2009 Permalink

what about using the findme-followme application and send it to a feature extension that maps to your IVR?

Submitted by axisinternet on Fri, 02/20/2009 Permalink

Hmmmm....that might work, will have to test it out.

What I've just done now is to add another ring group to the huntlists to dial the other extension, which 'should' kick in when the first one returns busy. Set it down to 15 secs timeout. If the first extension does not answer, but is not busy, the 2nd extension should ring for 15 secs and then fail over to the IVR.

Submitted by eeman on Sun, 06/28/2009 Permalink

I believe I have discovered the fix for this problem. While fixing another bug in tl-userexten-rg-base which was occuring as a result of chan_local, I got reports that using 'Hunt List' for sequential ringing performs significantly better. The patch is only 9 lines. Hopefully it gets submitted in the next release, but if you need the patch before then I could email the changes.