Callback diaplan override

asterisknow 1.5 (final)
Asterisk (yum updates to current from distro as of this writing)
Trunk type: SIP

We had many issues getting Callback() to work properly, including behaving consistently from user to user and carrier to carrier (wire-line vs. wireless). We’ve recently been able to spend some time working on it and we’ve gotten the following to be both working properly and working consistently.

-----begin snip(a)----
as found in /etc/asterisk/extensions_additonal.conf (original)

include => callback-custom
exten => 2,1,Set(CALL=NXXNXXXXXX)
exten => 2,n,Set(DESTINATION=app-announcement-8.s.1)
exten => 2,n,Set(SLEEP=8)
exten => 2,n,System(/var/lib/asterisk/bin/callback ${CALL} ${DESTINATION} ${SLEEP} &)
exten => 2,n,Hangup
-----end snip(a)----

-----begin snip(b)----
as placed in /etc/asterisk/extensions_override_freepbx.conf (modified)

include => callback-custom
exten => 2,1,NoOp( == Override(2,1) == )
exten => 2,n,Set(CALL=NXXNXXXXXX)
exten => 2,n,Set(DESTINATION=app-announcement-8.s.1)
exten => 2,n,Set(SLEEP=8)
; -----
exten => 2,n,Congestion
exten => 2,n,Hangup(16)
exten => h,1,NoOp( == Override(h,1) == )
exten => h,2,System(/var/lib/asterisk/bin/callback ${CALL} ${DESTINATION} ${SLEEP} &)
-----end snip(b)----


The Congestion()-Hangup() combination more expressly – imo, correctly – performs as the Callback() experience is defined (and expected). It is resulting in flawless call-in to the callback() operation – dial, hear fast-busy, no connect charges, and hangup. The old way we were NOT getting the fast-busy, just perpetual ringing.


On our comparatively FAST multi-core hardware and given the comparatively slow call tear down time of the cellular carrier originators, we saw that the System( Callback() ) was being spawned way TOO early and actually dialing out before the tear down was completed (asynchronously threading) . This was causing the Callback() to go to the cellular users’ call-waiting handling which meant, in cases, to their voice mail.

In our case, the in-context “h” spawning the System( Callback() ) is resulting in flawless call-out (back) from the callback() operation. This appears to ensure the tear down has – in fact – occurred before the call-out setup progresses (synchronous operation). In our case, no more Callback() being sent to cellular users’ call-waiting handling (e.g. voice mail). We tried fiddling with the sleep timers but got into big numbers for certain carriers (e.g. cellular) that were ridiculously long for wire-line carrier users. By moving it to “h” handler, the one, carrier-agnostic short sleep timer works in all cases – in fact we can zero this timer out and it still works!

I submit this here for three reasons – (i) possible help to others, and (ii) for inspection, review and comment as to what we may have collaterally broken with the above edits, and (iii) if all good then perhaps feed-forward into the Callback() module.


N.B.: ask if other inclusions (logs) are needed. We’re up and running the “new” way so getting “old” way info may be challenging, but we’ll do what we can if really, really needed.

In getting the whole Callback() experience right, we also had to edit the “/var/lib/asterisk/bin/callback” php file.

-----begin snip©-----
//define the args for Originate
$channel = “Local/”.$callback_number."@from-internal";
//$channel = “zap/g0/”.$uservm[$vmcontext][$vmextension][‘options’][‘callme’];
$exten = $callback_exten;
$context = $callback_context;
$priority = $callback_priority;
$timeout = “15000”;
$callerid = “Callback <8887290000>”;
$variable = “”;
$account = “”;
$application = “”;
$data = “”;
-----end snip©-----

change $timeout

$timeout = “15000”;

$timeout = “30000”;

In our case, with the comparatively slow call-setup time of cellular users, the (default) 15 seconds (15000 ms) of ringing is two-and-a-half rings (at 6 second intervals). Given that the first ring is often NOT experienced by the callee, the resulting one-and-a-bit rings wasn’t enough time to “answer” the Callback() call-out (back).

As modified, the thirty (30) seconds, or thirty-thousand (30000) milliseconds, is five (5) rings, or four rings if the first ring is not experienced.

This variable is NOT accessible via the GUI and must be manually edited per above.


1 Like