Use hangup-handlers

Hi,
I used hangup-handlers to send DTMF when hang up?
Example :
[internal]
exten => ${TTQSPHONE},1,Set(CHANNEL(hangup_handler_push)=send3,s,1);
exten => ${TTQSPHONE},2,Dial(DAHDI/g09/1009,30,Tt)
exten => ${TTQSPHONE},n,Hangup()
;exten => h,1,NoOp(Hangup TTQS)
;exten => h,2,Goto(send3,s,1)

[send3]
exten => s,1,NoOp(thong)
exten => s,n,sendDTMF(3,500)

i want to send DTMF to hangup my device . i used h extensions but not successful.
Thanks a lot

You should assume that device has already hungup and gone when h is run. Whilst that might not actually be true, you should assume it is true.

What you might want is to set the Dial option to continue after a successful call and send the DTMF whilst the caller is still up.

My device connect to FXS port. I remote it through DTMF. Press 3 to hangup my device.
when IP phone hang up , automatically send 3 to my device. I try to use h extension and handler hangup. but not successful.
Does u have ideal?

Suggestion (Dial option) already given.

Can u tell about your ideal clearly?
I try to use h extension or handler hangup when hangup IP but DTMF digit3 not send to my device, and my device not off hook, It always on hook. I want to off hook my device when IP phone hang up not press 3.

core show application dial:

g    - Proceed with dialplan execution at the current extension if the
       destination channel hangs up.

But i make call to my Device by IP Phone and remote off hook my Device. g extension is processed if my Device off hook ,not IP Phone.
IP Phone hangup => my Device hangup too by sendDMTF.
:frowning:
Thanks a lot

If you want to do something to the called channel when the calling channel hangs up, you will need to write a new channel driver. This is not something that can be done from the dialplan.

When you hang up the calling device, the Dial application hangs up, and destroys the called channel before the any further dialplan processing is doen on the calling channel. In any case, you have set the handler on the calling channel, so the DTMF will be sent to the calling channel.

I do not know whether you can actually get dialplan run on the called channel, before Dial hangs it up. My guess is no. However, if you can, you would need to set the handler on the called channel. There are various mechanisms to run dialplan on the called channel at the moment that it answers. My guess is that you would only be able to do things that don’t require the ability to communicate with the device.

I suspect you really need to create a proper channel driver, rather than trying to simulate one with the dialplan.

Hi @all,

even if my post is a few days too late, i was searching for a way to playback a file to the callee after the caller has hung up, and found a solution (or better call it a workaround). I think it pretty much fits into this thread, so it may help.

Instead of dialing out using die dial() application, you can originate() a call and delegate it to a second context, then bridge() it back to the client’s call.

Soon as any of the channel hangs up, bridge() returns and the other channel will continue in its context:

[dialout]
exten => _X.,1,NoOp(Starting dialout procedure to ${EXTEN})
same => n,Set(GLOBAL(cid${UNIQUEID})=${CHANNEL})
same => n,Ringing()
same => n,Originate(SIP/${EXTEN}@sipprovider,exten,delegate,${UNIQUEID},1,30)
same => n,Set(GLOBAL(cid${UNIQUEID})=)
same => n,Hangup()

[delegate]
exten => _X.,1,NoOp(Bridging originated call to channel ${cid${EXTEN}})
same => n,Bridge(${cid${EXTEN}})
same => n,Playback(myPlaybackFile)
same => n,Hangup()

Two backdraws:

First, I’ve found no other way to made the CHANNEL id available to the channel of the originated call, but to use a global variable. I thought that set(__varname=…) should do the job, but it doesn’t. So I create a global variable with a unique name out of UNIQUEID, holding the CHANNEL id. Then I use UNIQUEID as target extension in originate() (which would not work for the CHANNEL id itself, because of its format). Maybe anyone has a better solution for this?

Second, I’m not sure whether it is a problem that the originated call is not explicitely answered or if bridge() is answering the call automatically. However, calling Answer() directly could lead to a race-condition, when Originate() returns prior the channels are bridged. Does anyone know if this is an issue?

At least I’ve made a lot of tests and it was working all the time.

Regards, andy

You can probably use the G option on Dial, together with bridge, to reverse the role of the channels in the dialplan. You could probably also use E or M, but that feels more messy to me.