Callback (Ruby) does not send busy?

Dear All,

As the original callback script did not work for me at all, I installed Ruby and the replacement script. I also tried the new php version.

Both work fine. Almost.

The only problem is that seemingly callback does not send a busy signal to the caller and disconnect, but ‘picks up’ the call and sends the busy sound over the line that is alive… So the caller hears a busy tone, but gets charged for the call.

If I set the DID to go to the Busy-blackhole rather than the appropriate callback, busy is perfect… So it looks as if the callback script was not sending busy, but only disconnects…

Has anyone experienced anything similar?

I looked into how the callback is made.

The callback module (the web UI) writes into the /etc/asterisk/extensions_additional.conf lines line:

include => callback-custom
exten => 4,1,Set(CALL=0044xxxxx)
exten => 4,n,Set(DESTINATION=disa.3.1)
exten => 4,n,Set(SLEEP=2)
exten => 4,n,System(/var/lib/asterisk/bin/callback ${CALL} ${DESTINATION} ${SLEEP} &)
exten => 4,n,Hangup
; end of [callback]

Should it not send busy rather than simply hangup?

So here is what I have found:

I have tried callback with two DID providers.

Provider #1

Provider#1 passed the trigger call to my FreePBX box, which started the callback process, then hang up. When provider#1 got the hangup, it did something like:
b./play busy tone
c./hangup after certain delay

Problem was that due to Provider #1’s behaviour, calls were answered, and were consequently charged for. Not very wise if the callback DID is international or when you are roaming :slight_smile:

Provider #2

Provider#2 passed the trigger call to my FreePBX box, which started the callback process, then hang up. Provider#2 however did not do anything: it did not send a hangup signal to the caller, it did not answer the call, it did not send busy… This was better than provider#1, as the trigger call did not get charged, while callback still worked. However, this method leaves the user in doubt, as there is absolutely no feedback if the trigger call has ever reached the FreePBX callback server…

After some experimentation, I found a compromise workaround. It seems to work now, and I will leave it like this until I find any better solution. I modified the callback module’s PHP to write stuff like:

include => callback-custom
exten => 4,1,Set(CALL=0044xxxxx)
exten => 4,n,Set(DESTINATION=disa.3.1)
exten => 4,n,Set(SLEEP=15)
exten => 4,n,System(/var/lib/asterisk/bin/callback ${CALL} ${DESTINATION} ${SLEEP} &)
exten => 4,n,Ringing
exten => 4,n,Wait(10)
exten => 4,n,Hangup
; end of [callback]

So instead of immediate hangup, I make FreePBX send ringtone to caller for 10 seconds. So the caller (which is myself :slight_smile: will hear ringing and has 10 seconds to hang up manually before the call would hangup automatically and get charged…

This is not the best solution to the problem, and is a compromise. But it still is a workaround that helps for the time being. I will also need to play a bit more with timings.

Any better ideas out there?

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

We too have been having a heck of a whack of issues with CALLBACK, including the missing-in-action of the busy (or congestion) signal thereby necessitating a manual hangup.

We have RESOLVED both the missing-in-action busy/congestion signal and the resulting need for manual hangup.


; [callback] include => callback-custom exten => 2,1,Set(CALL=4165555555) exten => 2,n,Set(DESTINATION=app-announcement-8.s.1) ; Note (1) exten => 2,n,Set(SLEEP=12) ; - exten => 2,n,Congestion(6) exten => 2,n(BYEBYE),Hangup(0) exten => h,1,NoOp(HANGUPCAUSE is ${HANGUPCAUSE}, call=${CALL}, dest=${DESTINATION}) exten => h,n,System(/var/lib/asterisk/bin/callback ${CALL} ${DESTINATION} ${SLEEP} &) ; -

Firstly, note (2), the use of the Congestion() command sends the correct fast-busy (congestion) signal to the user calling into the CallBack(), and then the callers’ [cell] carrier hangs up shortly thereafter if the caller does not. The congestion signal results in a zero second duration call (NO ANSWER status). The Hangup() is seemingly necessary to really, really hangup the SIP trunk. Seemingly, we cannot rely on the Congestion()'s wait-for-hangup behavior alone.

I think the above should solve your issue too. The use of Congestion(), to my limited knowledge, should be provider agnostic (i.e. works when needed as needed, or benign otherwise).

Secondly, note (1), in our case, the destination is an ANNOUNCEMENT, which plays 1 second of ulaw-specific silence, and then progresses to the Disa() function. Without this 1 second of ulaw-silence, when the Disa “answers” the callback, our users were hearing NOTHING. The playing of the ulaw-silence gets the CODEC’s mojo going correctly.

You may or may not need this. If not, then, in your case, your DESTINATION is the DISA() directly.

To get this to work, I had to use the extension_OVERRIDE_freepbx.conf. Perhaps there’s a better placement of the dial plan fragment and someone may let us both know.