Pre-dial - Ability to run dialplan on callee and caller channel right before actual Dial. Available on the Dial and FollowMe applications.
Pre-dial handlers allow you to execute a dialplan Gosub on a channel before a call is placed but after the Dial application is invoked. You can execute a dialplan Gosub on the caller channel and on each callee channel dialed.
The 'B' option executes a dialplan Gosub on the caller channel before any callee channels are created.
The 'b' option executes a dialplan Gosub on each callee channel after it is created but before the call is placed to the end-device.
Example execution sequences to show when things happen:
SIP/foo is calling SIP/bar
SIP/foo is the caller,
SIP/bar is the callee,
SIP/baz is another callee,
The syntax is intentionally similar to the Gosub application. If context or exten are not supplied then the current values from the caller channel are used.
Say SIP/abc is calling SIP/def. In the dialplan you have: Dial(SIP/def). When executed, SIP/def-123234 is created. But how can you tell that from dialplan?
You can use a pickup macro: M or U options to Dial(), but you have to wait till the called channel answers to know. The new pre-dial option 'b' to Dial(), will let you run dialplan on the newly created channel before the call is placed to the end-device.
Dialplan will run on SIP/def-123234 and allow you to know right away what channel will be used, and you can set specific variables on that channel.
You can run dialplan on the caller channel right before the dial, which is a great place to do a last microsecond UNLOCK to ensure good channel behavior.
With this above example, say SIP/123 and SIP/234 are running this dialplan.
- SIP/123 locks foo
- SIP/123 unlocks foo
- Due to some CPU load issue, SIP/123 takes its time getting to Dial(SIP/abc) and doesn't do it right away.
- Meanwhile... SIP/234 zips right by, lock 'foo' is already unlocked
- SIP/234 grabs the lock, does its thing and it gets to Dial(SIP/abc).
- SIP/123 wakes up and finally gets to the Dial().
Now you have two channels dialing SIP/abc when there was supposed to be one.
If your intention is to ensure that Dial(SIP/abc) is only done one at a time, you may have unexpected behavior lurking.
Now, under no circumstances can this dialplan be run through and execute the Dial unless lock 'foo' is released. Obviously this doesn't ensure that you're not calling SIP/abc more than once (you would need more dialplan logic for that), but it will allow a dialplan coder to also put the Dial in the locked section to ensure tighter control.