asterisk users - Feb 2005 - More complicated huntgroups / delayed ringing

Stefan Gofferje wrote:
> Hi Folks,
> 
> on my home asterisk, I have a "huntgroup" for incoming calls on
the
> private line which first let ring my phones in my office and living 
> room, after a while then office, living room and bedroom.
> I do this by simply putting two dial statements in sequence:
> 
> 
> [private_huntgroup_day]
> exten => s,1,Dial(Local/6001@internal&Local/6004@internal,15,rt)
> exten => s,2,Wait(1)
> exten => 
>
s,3,Dial(Local/6001@internal&Local/6003@internal&Local/6004@internal,20,rt)
> exten => s,4,Voicemail(u810920)
> exten => s,5,Hangup
> exten => s,104,Voicemail(b810920)
> exten => s,105,Hangup
> 
> 
> Trouble is, this appears to the office and living room phones as two 
> separate calls, so, if I miss this call, I have "2 missed calls"
in my
> display.
> Is there a way to make real huntgroups where I can say "first this and
> this, after 15 secs that also"?
> 
> Regards,
>   Stefan
> 
I've worked on this off and on.  I've been thinking about writing a 
patch to 'Dial/RetryDial' (why isn't retry just a flag for the Dial 
app?) that would do exactly that.

In my office, my boss wants the functionality that you describe.  I've 
attempted this in many different ways so far - sans patching the code. 
The only thing I've found that is somewhat functional is to use some 
TRULY creative extension logic utilizing Local/${EXTEN} and with 
RetryDial, but it still isn't perfect.  If I get a chance, I'll post my 
solution - mind you I don't currently use this so its not exactly 
perfect, or even production ready/usable.

Really I think that the best solution would be to have Dial/RetryDial 
have an optional DELAY for each channel listed in the dial-string.  Such 
that SIP/101&SIP/102[5]&SIP/103[10]&SIP/104[15] would result in
SIP/101
being rung immediately (with retry options to continue attempting if 
busy/etc.) while SIP/102 will not start ringing for another 5 seconds. 
SIP/103 will ring 5 seconds after SIP/102 starts, or 10 seconds after 
SIP/101 started. SIP/104 follows the same pattern, etc...

If anybody out there besides myself and the OP would like to 'me-too' on
this one, I'll post the feature request on the wiki/bug-tracker to see 
if it is possible to do.  I've looked at the code, and while I think it 
is possible, I'm not fully up to speed with the logic in Dial/RetryDial 
so I don't want to end up breaking it trying to make this work.

-Chris

PS: if enough people 'me-too' on this one and put forth $5-$10 a piece 
for a bounty, it might be worth it for one of the guru's to implement. 
I'll see if I can put some money into this as well - not sure though, I 
know my boss won't spend anything on it :(

Chris Wade wrote:
> Really I think that the best solution would be to have Dial/RetryDial 
> have an optional DELAY for each channel listed in the dial-string.  Such 
> that SIP/101&SIP/102[5]&SIP/103[10]&SIP/104[15] would result in
SIP/101
> being rung immediately (with retry options to continue attempting if 
> busy/etc.) while SIP/102 will not start ringing for another 5 seconds. 
> SIP/103 will ring 5 seconds after SIP/102 starts, or 10 seconds after 
> SIP/101 started. SIP/104 follows the same pattern, etc...
I've been considering doing this as well... something like a "dial 
list", with a delay before dialing and a timeout for each entry.
> PS: if enough people 'me-too' on this one and put forth $5-$10 a
piece
> for a bounty, it might be worth it for one of the guru's to implement. 
> I'll see if I can put some money into this as well - not sure though, I
> know my boss won't spend anything on it :(
I'll probably implement it anyway, but if there is a bounty attached it 
will get done sooner :-)

Stefan Gofferje wrote:
>> [private_huntgroup_day]
>> exten => s,1,Dial(Local/6001@internal&Local/6004@internal,15,rt)
>> exten => s,2,Wait(1)
>> exten => 
>>
s,3,Dial(Local/6001@internal&Local/6003@internal&Local/6004@internal,20,rt)
>>
>> exten => s,4,Voicemail(u810920)
>> exten => s,5,Hangup
>> exten => s,104,Voicemail(b810920)
>> exten => s,105,Hangup
I know this is OT from your posting, but I'm curious...

Do the extensions in your internal context have voicemail failovers 
attached to them? How do you keep some random voicemail from picking up 
instead of falling down to your 810920 voicemail?

-- 
Andrew Thompson
http://aktzero.com/
http://dev.asteriskdocs.org/

Stefan Gofferje wrote:
> Andrew Thompson schrieb:
> 
>> Stefan Gofferje wrote:
>>
>>>> [private_huntgroup_day]
>>>> exten =>
s,1,Dial(Local/6001@internal&Local/6004@internal,15,rt)
>>>> exten => s,2,Wait(1)
>>>> exten => 
>>>>
s,3,Dial(Local/6001@internal&Local/6003@internal&Local/6004@internal,20,rt)
>>>>
>>>> exten => s,4,Voicemail(u810920)
>>>> exten => s,5,Hangup
>>>> exten => s,104,Voicemail(b810920)
>>>> exten => s,105,Hangup
I'll be playing around with Local/ some in the next few days(now that I 
more understand what it's for).

I had a thought about your problem. Given the dialplan above, have you 
tried adding a Wait(15) to extension 6003@internal, so it doesn't start 
processing right away?

You could encapsulate it using something like:

[delayedinternal]
exten => _.,1,Wait(15)
exten => _.,2,Dial(Local/<fill with appropriate
variable>@internal,20,rt)

Note: I haven't tried this, and it might be utter malarky, but it seems 
logical, to me anyway. Also, please excuse any linebreaking that may 
have occured in my example.

-- 
Andrew Thompson
http://aktzero.com/
http://dev.asteriskdocs.org/

Stefan Gofferje wrote:
> That's brilliant! And so easy...
> Works exactly as supposed. You should put it onto the wiki under section 
> "tips & tricks".
> 
> Regards,
>   Stefan
> 
> PS: Chris, your boss might like this also!
Wow, is it too late to put in for royalties? ;)

I'm glad it worked for you.

-- 
Andrew Thompson
http://aktzero.com/
http://dev.asteriskdocs.org/

Stefan Gofferje wrote:
> Andrew Thompson schrieb:
> 
>> I'll be playing around with Local/ some in the next few days(now
that
>> I more understand what it's for).
>>
>> I had a thought about your problem. Given the dialplan above, have you 
>> tried adding a Wait(15) to extension 6003@internal, so it doesn't 
>> start processing right away?
>>
>> You could encapsulate it using something like:
>>
>> [delayedinternal]
>> exten => _.,1,Wait(15)
>> exten => _.,2,Dial(Local/<fill with appropriate
variable>@internal,20,rt)
>>
>> Note: I haven't tried this, and it might be utter malarky, but it 
>> seems logical, to me anyway. Also, please excuse any linebreaking that 
>> may have occured in my example.
> 
> 
> That's brilliant! And so easy...
> Works exactly as supposed. You should put it onto the wiki under section 
> "tips & tricks".
> 
> Regards,
>   Stefan
> 
> PS: Chris, your boss might like this also!
> 
> 
I've tried similar, it worked, just not quite what I had intended - but 
then again, this was several months ago when I tried that approach. 
I'll see about doing it this way again, but I will say the biggest pain 
is that my hunt groups are VERY large and considerably more complicated 
than just what I've described here.  A queue would work best in my 
situation, except that it will not ring in devices in the way we've been 
discussing, so I have to re-implement the queue system using the 
dialplan and something similar to what was just proposed - this is why 
it never quite worked as expected.  Regardless, I think it looks like 
one of the 'guru's is interested in this idea and may contemplate 
implementing this as an option to 'Dial' :)

-Chris

> Here's a completely different and rather ambitious idea...
> What about replacing (or complement) the Dial and Queue apps by a 
> meta-ACD app. Something like a scipting language. Something REALLY scary 
> flexible and powerful. Something where another wiz can write a GUI 
> for... So, with this, asterisk could even kick Nortel or Aspect off some 
> Markets... At least here in Germany, callcenters and fighting a really 
> heavy price-war, having the need to save money where possible... Saving 
> half a million for the Meridian plus service etc... could make asterisk 
> quite interesting...
yah you mean ICD :)

Stefan Gofferje wrote:
> Hum... sounds pretty much like you needed an ACD rather than a simple 
> immediate / delayed calling huntgroup...
> 
> Regards,
>   Stefan
> 
Exactly, but if you look, * queues don't quite measure up to these 
requirements.  The asterisk-ICD project is getting there, but still too 
immature I think.

-Chris

Stefan Gofferje wrote:
> So, if I ran a 0900 support-no. for people without contracts, they 
> probably won't like paying EUR 3,60 per minute to hear music and -
after
>  three or four minutes - be told, there's still no agent free to answer
> the call...
I believe this is correct, the call must be answered before app_queue 
can handle it. However, how many customers do you think would sit there 
for 3 or 4 minutes of ringing with no announcement messages or anything? 
I doubt very many would last past 60 seconds.

If you run a "premium" service, you have to either answer the call 
immediately or reject it quickly, because as you said, no caller will be 
happy paying your premium rates only to be told that their call cannot 
be answered.

On Tue, 8 Feb 2005, Kevin P. Fleming wrote:
> I believe this is correct, the call must be answered before app_queue 
> can handle it. However, how many customers do you think would sit there 
> for 3 or 4 minutes of ringing with no announcement messages or anything? 
> I doubt very many would last past 60 seconds.
Technically you may be able to provide audio cues without answering, at 
least in some countries (think isdn and in band progress messages). 
Unfortunatly this is useless for queues since most operators have a limit 
on the call setup phase. After a minute or so in an alerting state they 
release the connection.

Peter

On Tue, 2005-02-08 at 22:50 +0100, Stefan Gofferje wrote:
> Queues are not too bad but lacking an important feature. As far as I 
> could figure out, they couldn't just ring without answering.
Hum? I'm running * 1.0.5, and Queue rings without prior answering the
line. Although most queue examples seem to assume you want MOH and
stuff, which of course implies a prior Answer, it isn't actually
necessary. I was specifically concerned about this point, since in
my home setup I receive ISDN calls via chan_capi, and while directing
them into the queue I only want the caller to pay if either a phone
or voicemail picks the call up. Maybe I missed something, as I didn't
follow the entire thread, but Queue ringing without Answer works here.

Regards, Bruno.

----- Original Message ----- 
From: "Stefan Gofferje" <stefan@gofferje.homelinux.org>
To: "Asterisk Users Mailing List - Non-Commercial Discussion" 
<asterisk-users@lists.digium.com>
Sent: Tuesday, February 08, 2005 9:12 PM
Subject: Re: [Asterisk-Users] More complicated huntgroups / delayed ringing

> Kevin P. Fleming schrieb:
>> Chris Wade wrote:
>>
>>> Might also help to implement this type of 'strategy' for
the 'Queue'?
>>> Just another little idea, I still like the previously discussed
options
>>> as well.
>>
>>
>> Possibly, although it could be done with a queue by just directing the 
>> queue to call a Local channel that then distributes the calls in this 
>> fashion.
>
> Here's a completely different and rather ambitious idea...
> What about replacing (or complement) the Dial and Queue apps by a meta-ACD 
> app. Something like a scipting language. Something REALLY scary flexible 
> and powerful. Something where another wiz can write a GUI for... So, with 
> this, asterisk could even kick Nortel or Aspect off some Markets... At 
> least here in Germany, callcenters and fighting a really heavy price-war, 
> having the need to save money where possible... Saving half a million for 
> the Meridian plus service etc... could make asterisk quite interesting...
>
> Regards,
>   Stefan
>
>
Mmm, yes be nice to see something to rival Symposium, for a lot less cash.

Steve (Symposium/Meridian sysadmin)