ChannelRedirect hangs when chan is executing Dial

I’m trying to write DTMF based 3-way code for an analog channel driver, and I’m running into an issue trying to redirect the channel that dials the 3-way initiator (The ChannelRedirect target is currently executing the Dial app). Without adding too much information, here’s some quick info:

Running Asterisk 11.5.0
Issue is essentially identical to
Full example code and logs (it’s a long post) can be found here:

What I am looking to achieve:
I would like to either figure out if there’s a quick patch to ChannelRedirect (it would possibly end up in pbx.c under the async goto function), or if there’s a better way to implement a DTMF based 3-way call that looks essentially like an attended transfer until the final action (the initiator instead of hanging up hits a DTMF code to start the three way).

I can add or clarify any extra information if needed. Thanks!

I would say this was a developer question (see the sticky posting on such questions) not an end user one. This involves the masquerading process. The comments in the code used to say “this is a seriously wacked out process”. It is an area of the code where angels fear to tread.

Thanks David, I’ll put this into a Jira request.

In the meantime, if anyone has gotten a DTMF 3-way call to work purely in dialplan, please let me know!

Do not use JIRA. JIRA is for reporting bugs, not for requesting new features. If you request a new feature without providing a patch, against the trunk version, to implement it, the report will be closed as “not a bug”.

You need to chase it on the developer mailing list or IRC channel.

Ok, I’ll do my best on IRC. As far as I can tell, ChannelRedirect doesn’t function properly, so I figured this was a corner-case bug. I’ll try to dig around source code more, as well as see if anyone has ever gotten DTMF based 3-way calling to work using another technique.

The bug report you quote was closed as fixed. The comments in it says that delaying the the transfer when the request is mode on the channel which is running the dialplan is expected behaviour.

Even if you disagree with that, you would be best advised to get agreement from the developers that it is not expected behaviour, before submitting a bug report.

The implementors of Asterisk seem to have chosen to do transfres as C code, not as dialplan fragmnets based on a more general features mechanism.