Summary:ASTERISK-07168: [patch] [post-1.4] Added Incremental Dialing to app_dial (Untested)
Reporter:Philipp Dunkel (pdunkel)Labels:
Date Opened:2006-06-14 12:55:50Date Closed:2011-06-07 14:03:22
Versions:Frequency of
Environment:Attachments:( 0) app_dial.diff
Description:Incremental dialing is the ability to wait a number of seconds between adding channels.


Will first ring Local/1@default for 5 seconds
If noone answered it rings Local/1@default and Local/2@default for another 5 seconds
if noone answered it rings Local/1@default and Local/2@default and Local/3@default for another 5 seconds

After that it rings all for the timeout time specified as before.

This is usefull if you don't want a lot of


in your dialplan. With Local this would be feaseable, but this is channel independant.


At this point I just wrote some bare code (attached). If this is something you people(male|female) find useful I'll go and do intensive testing on. If not I'll test at my own pace and just use it myself.
Comments:By: Serge Vecher (serge-v) 2006-06-14 13:20:30

can't you do the same thing (an more) with the new app_followme that's in trunk now?

By: Philipp Dunkel (pdunkel) 2006-06-14 17:39:32

AS far as I understand app_followme it is not.

First off, app_followme will call numbers in a context not devices. (Of course I could set them up to be just exten<x>,1,Dial(<DEVICE>)

Second app_followme will call the numbers sequentially. What happens here is <a> <ab> <abc> <abcd>... Meaning First it starts with one phone. After timeout it rings phone1 AND phone2 after another timeout it calls phone 1 AND phone2 AND phone3

Third app_followme will always ask the callee to confirm that the call should be taken, which is nice, but a killer for my use, since the person picking up the phone should get it, period.

Forth off, All the numbers would have to be defined ahead of time. It would be impossible to something like:

So I think this has merit. However a case can be made to not muck up app_dial anymore than it already is and rather do an DialIncrement()

Greetings, Philipp

By: Philipp Dunkel (pdunkel) 2006-06-16 03:54:00

So seeing that you reset the Status to new and set the Summary to [post-1.4] I am assuming you agree that this has some merit.

If You tell me which you think would be better:
  * Option Parameter to Dial()
  * Seperate Application DialIncremental()

I will rework the think accordingly and do some testing until the [post-1.4] time comes arround so that by that time there will be something solid to evaluate and put through the ringer.

Thanks, Philipp

By: jmls (jmls) 2006-10-31 04:03:10.000-0600

pdunkel: the patch doesn't apply to the latest svn trunk. Would you be able to update the patch accordingly ? Thanks.

By: Olle Johansson (oej) 2006-10-31 04:22:31.000-0600

You can do this with the local channel today - as you note. I don't like changing dial anyway, so a better way would be to create incrementaldial().

By: Philipp Dunkel (pdunkel) 2006-10-31 07:16:33.000-0600

I will rework this for the curretn SVN-trunk within the next couple of days.
I am in total agreement with oej that changing dial, being such a core app, would not be that good. Therefore I will work this as a seperate App in app_dial.c unless anyone has any strong objections.

I'll be back within a couple of days with a working patch.

Greetings, Philipp

By: Leif Madsen (lmadsen) 2006-10-31 07:27:36.000-0600

You can also accomplish the same thing with pure dialplan:

exten => s,1,Dial(Local/5-EXTEN@default)

exten => _X.,1,Set(RING_WAIT=${CUT(EXTEN,-,1)})
exten => _X.,n,Set(DIALER=${CUT(EXTEN,-,2)})
exten => _X.,n,Wait(${RING_WAIT})
exten => _X.,n,Dial(SIP/provider/${DIALER},24)

By: Serge Vecher (serge-v) 2006-11-03 11:53:52.000-0600

I think we should make a new *.conf file with all the cool features one can accomplish with a dialplan ...

By: Philipp Dunkel (pdunkel) 2006-11-03 12:54:56.000-0600

@blitzrage: This is absolutely not what this patch is about.
Edit: @blitzrate: Actually it is exactly what this is about. (See Addition at end)

You are just separating 2 fields an then plug them into a wait and a dial. What is sugest ist more like
exten => 1,1,Dial(IAX2/peer/1)
exten => 2,1,Wait(5)
exten => 2,2,Dial(IAX2/peer/2)
exten => 3,1,Wait(10)
exten => 3,2,Dial(IAX2/peer/3)
exten => 4,1,Wait(15)
exten => 4,2,Dial(IAX2/peer/4)

exten => 99,1,Dial(Local/1@waiters&Local/2@waiters&Local/3@waiters&Loacl/4@waiters)

And as I have just proven this can be done in dialplan. As can a lot of things there are apps for. Its just a hassle, especially if I dont write my dialplans by hand but have some form of management architecture around it.
This would be just a lot nicer:

exten => 99,1,IncrementDial(IAX2/peer/1&IAX2/peer/2&IAX2/peer/3&IAX2/peer/4,,5)

especially since I can easily switch between that and

exten => 99,1,Dial(IAX2/peer/1&IAX2/peer/2&IAX2/peer/3&IAX2/peer/4)

anytime I need to.

Greetings, Phil

(Additions at End)

What iof i have devices like


exten => 99,1,IncrementalDial(SIP/philipp&IAX2/george&SIP/leslie&IAX2/gunther,,5)
or a lot of dialplan magic to figure Technologies.

P.S.: I am very greatful for your insights. I just want to toss this around a bit before I invest more coding/debugging time into this. Does anyone here thinks this may be wothwhile or do you basically all agree that this is a waste of time? Thanks for the feedback.

By: Philipp Dunkel (pdunkel) 2006-11-17 14:17:19.000-0600

Having though about the pros and cons of doing this in a seperate app versus having to maintain that app.

I now tend to agree with you that preferred toing this via dialplan.

Therefore please close this issue and ignore it.

Greetings, Philipp

By: Jason Parker (jparker) 2006-11-17 15:20:27.000-0600

Closed by request of reporter.