> It does seem like a bug. However, you have a complicated dialplan with a lot
> of pieces happening at
> once so it may not actually be an Asterisk bug but a problem with your
> dialplan. To unravel this is
> going to take some bookkeeping on your part.
Hi Richard,
Thanks for the detailed
On Wed, Aug 8, 2018 at 7:43 PM, Daniel Journo
wrote:
> > Doing some more tests, this reads like a bug to me.
> > Using a hanguphandler with DumpChan in the dialplan context that executes
> > the Queue, I can see that DYNAMIC_FEATURES is set.
> > After the attended transfer when the call is
> Doing some more tests, this reads like a bug to me.
> Using a hanguphandler with DumpChan in the dialplan context that executes
> the Queue, I can see that DYNAMIC_FEATURES is set.
> After the attended transfer when the call is ended, the hanguphandler still
> shows that DYNAMIC_FEATURES is set.
On Wed, Aug 8, 2018 at 1:53 PM, Daniel Journo
wrote:
> > Prior to a call entering a Queue, I set __DYNAMIC_FEATURES=NewRecordApp.
> > AgentA answers and is able to use that feature code.
> > If AgentA performs an attended transfer of a call from a queue to
> AgentB, the
> > feature code no
> Prior to a call entering a Queue, I set __DYNAMIC_FEATURES=NewRecordApp.
> AgentA answers and is able to use that feature code.
> If AgentA performs an attended transfer of a call from a queue to AgentB, the
> feature code no longer works.
>
> It only doesn't work when using Queue() and an
Hi,
I think I've identified an issue and just want to check before completing a bug
report.
Prior to a call entering a Queue, I set __DYNAMIC_FEATURES=NewRecordApp. AgentA
answers and is able to use that feature code.
If AgentA performs an attended transfer of a call from a queue to AgentB,
