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