asterisk users - Aug 2018 - Queue breaks Dynamic_Features on Attended Transfer

On Wed, Aug 8, 2018 at 1:53 PM, Daniel Journo <dan at
keshercommunications.com>
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 longer works.
> >
> > It only doesn’t work when using Queue() and an Attended transfer is
> > performed.
> >
> > Is this a bug or is there something that needs to be set to allow the
> > DYNAMIC_FEATURES to be inherited after an attended transfer from a
queue?
>
> 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. It's just not accessible.
>
> Any thoughts?
>
It likely depens on how you are doing the attended transfer.  Via DTMF?
Via SIP or channel technology protocol?
Does the Agent B channel have the DYNAMIC_FEATURES channel variable set on
it?

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20180808/ff84dc91/attachment.html>

> 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. It's just not accessible.
>
> Any thoughts?
> It likely depens on how you are doing the attended transfer.  Via DTMF? 
Via SIP
> or channel technology protocol?
> Does the Agent B channel have the DYNAMIC_FEATURES channel variable set
> on it?
>
Thanks for the reply.

To answer your question, the attended transfers are done via the endpoint's
feature buttons. So I assume it's via SIP requests.

I've been doing some tests and reviewing the debug logs to try to understand
the problem and still think it's a bug at this point.

Firstly, most of my inbound calls are answered and then Dial() Local channels.
These Local channels set __DYNAMIC_FEATURES and various other things. They are
also needed to ensure functionality like MixMonitor can be started on the Local
channel and then not affected by any transfers. The Local channels then either
Dial() some peers via other local channels (as some peers are required to press
1 to accept the call) or a Local channel that dials a Queue().

For non-Queue calls that are going via the Local Channels that only use Dial().
When endpoint_201 dials *1, it is matched with their own
channel.
> DTMF feature hook 0x7f18d803a978 matched DTMF string '*1' on
0x7f18c000b080(PJSIP/endpoint_201-0000cb55)
Interestingly, after the attended transfer from endpoint_201 to endpoint_202,
when endpoint_202 dials *1, it can no longer match and passes it back to the
Local channel that originally dialled endpoint_201.
At that point, it can match the local channel since that's where
DYNAMIC_FEATURES was originally set.
> No DTMF feature hooks on 0x7f189c0660b0(PJSIP/endpoint_202-0000cb5b) match
'*1'
> DTMF feature hook 0x7f1894abd408 matched DTMF string '*1' on
0x7f186c04efa0(Local/fromfeature_201 at phones-00005a17;1)
So although the transfer caused the variable to be lost, the Local channel, as
the parent, remained and stepped in to complete the *1 request.
Probably works by accident.

But calls passing through a Local channel that ends in Queue() don't act the
same way.

The Queue's initial dial of the queuemembers includes the inheritance as
expected.
So when endpoint_201 answers and they dial *1, this is the
result.
> DTMF feature hook 0x7f18c4018278 matched DTMF string '*1' on
0x7f18b0002ca0(PJSIP/endpoint_201-0000cacc)
But following a transfer, using the same SIP messaging as the non-queue calls,
this is the result...
> DTMF feature string on 0x7f18bd369720(PJSIP/endpoint_202-0000cae8) is now
'*1'
> No DTMF feature hooks on 0x7f18bd369720(PJSIP/endpoint_202-0000cae8) match
'*1'
> Playing DTMF stream '*1' out to
0x7f18e4112980(Local/queue_dialplan_101 at queue-000059b2;2) <---- this
channel still has DYNAMIC_FEATURES set (see below) but it just passes the DTMF
through?
> DTMF begin '*' received on Local/queue_dialplan_101 at
queue-000059b2;1
> DTMF begin passthrough '*' on Local/queue_dialplan_101 at
queue-000059b2;1
and it's passed all the way back and played to the caller.

This is in spite of the fact that Local/queue_dialplan_101 at queue-000059b2;2
has DYNAMIC_FEATURES set earlier in the dialplan.
> Set("Local/queue_dialplan_101 at queue-000059b2;2",
"__DYNAMIC_FEATURES=NewRecordApp")
And still set at the end of the call, confirmed using DumpChan within the
channels hangup handler.
> Dumping Info For Channel: Local/queue_dialplan 101 at queue-000059b2;2:
> Variables:
> DYNAMIC_FEATURES=NewRecordApp
I can't really explain why the channel can still have DYNAMIC_FEATURES, but
it's not perform matching apart from thinking it's a bug.

I hope that wasn't too long winded!

Thanks for the help and time!
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20180809/70083348/attachment.html>

On Wed, Aug 8, 2018 at 7:43 PM, Daniel Journo <dan at
keshercommunications.com>
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 ended, the hanguphandler
> still
> > shows that DYNAMIC_FEATURES is set. It's just not accessible.
> >
> > Any thoughts?
> > It likely depens on how you are doing the attended transfer.  Via
DTMF?
> Via SIP
> > or channel technology protocol?
> > Does the Agent B channel have the DYNAMIC_FEATURES channel variable
set
> > on it?
> >
>
> Thanks for the reply.
>
> To answer your question, the attended transfers are done via the
> endpoint's feature buttons. So I assume it's via SIP requests.
>
> I've been doing some tests and reviewing the debug logs to try to
> understand the problem and still think it's a bug at this point.
>
> Firstly, most of my inbound calls are answered and then Dial() Local
> channels. These Local channels set __DYNAMIC_FEATURES and various other
> things. They are also needed to ensure functionality like MixMonitor can be
> started on the Local channel and then not affected by any transfers. The
> Local channels then either Dial() some peers via other local channels (as
> some peers are required to press 1 to accept the call) or a Local channel
> that dials a Queue().
>
> For non-Queue calls that are going via the Local Channels that only use
> Dial().
> When endpoint_201 dials *1, it is matched with their own channel.
> > DTMF feature hook 0x7f18d803a978 matched DTMF string '*1' on
> 0x7f18c000b080(PJSIP/endpoint_201-0000cb55)
>
> Interestingly, after the attended transfer from endpoint_201 to
> endpoint_202, when endpoint_202 dials *1, it can no longer match and passes
> it back to the Local channel that originally dialled endpoint_201.
> At that point, it can match the local channel since that's where
> DYNAMIC_FEATURES was originally set.
> > No DTMF feature hooks on 0x7f189c0660b0(PJSIP/endpoint_202-0000cb5b)
> match '*1'
> > DTMF feature hook 0x7f1894abd408 matched DTMF string '*1' on
> 0x7f186c04efa0(Local/fromfeature_201 at phones-00005a17;1)
> So although the transfer caused the variable to be lost, the Local
> channel, as the parent, remained and stepped in to complete the *1 request.
> Probably works by accident.
>
> But calls passing through a Local channel that ends in Queue() don't
act
> the same way.
>
> The Queue's initial dial of the queuemembers includes the inheritance
as
> expected.
> So when endpoint_201 answers and they dial *1, this is the result.
> > DTMF feature hook 0x7f18c4018278 matched DTMF string '*1' on
> 0x7f18b0002ca0(PJSIP/endpoint_201-0000cacc)
>
> But following a transfer, using the same SIP messaging as the non-queue
> calls, this is the result...
> > DTMF feature string on 0x7f18bd369720(PJSIP/endpoint_202-0000cae8) is
> now '*1'
> > No DTMF feature hooks on 0x7f18bd369720(PJSIP/endpoint_202-0000cae8)
> match '*1'
> > Playing DTMF stream '*1' out to 0x7f18e4112980(Local/queue_
> dialplan_101 at queue-000059b2;2) <---- this channel still has
> DYNAMIC_FEATURES set (see below) but it just passes the DTMF through?
> > DTMF begin '*' received on Local/queue_dialplan_101 at
queue-000059b2;1
>
Does Local/queue_dialplan_101 at queue-000059b2;1 have DYNAMIC_FEATURES set on
it?
> DTMF begin passthrough '*' on Local/queue_dialplan_101 at
queue-000059b2;1
> and it's passed all the way back and played to the caller.
>
> This is in spite of the fact that Local/queue_dialplan_101 at
queue-000059b2;2
> has DYNAMIC_FEATURES set earlier in the dialplan.
> > Set("Local/queue_dialplan_101 at queue-000059b2;2",
"__DYNAMIC_FEATURES> NewRecordApp")
> And still set at the end of the call, confirmed using DumpChan within the
> channels hangup handler.
>
> > Dumping Info For Channel: Local/queue_dialplan 101 at
queue-000059b2;2:
> > Variables:
> > DYNAMIC_FEATURES=NewRecordApp
>
> I can't really explain why the channel can still have DYNAMIC_FEATURES,
> but it's not perform matching apart from thinking it's a bug.
>
> I hope that wasn't too long winded!
>
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.

Here are some pointers to help:

It will help you to see what is going on by drawing out the channel
chains.  For instance I think your initial
non-queue call chain looks like:
PJSIP/caller --> Bridge1 --> L/caller;1 -- L/caller;2 --> Bridge2
-->
L/feature;1 -- L/feature;2 --> Bridge3 --> PJSIP/201

DTMF feature hooks match DTMF coming from a channel toward a bridge.  They
do not match DTMF
going in the other direction.  (This is why Local/queue_
dialplan_101 at queue-000059b2;2 does not act on
the DTMF above.)

SIP attended transfers involve two calls.  One call is placed on hold while
the endpoint initiates another
call.  When you complete the transfer the two remote parties get bridged
together.
For example:
A (PJSIP/A-1) calls B (PJSIP/B-1) and talk in Bridge1
B (PJSIP/B-1) places A (PJSIP/A-1) on hold to start an attended transfer
B (PJSIP/B-2) calls C (PJSIP/C-2) in another call and talk in Bridge2
When B completes the transfer A (PJSIP/A-1) is bridged with C (PJSIP/C-2).
* Note the A and C channels could wind up in either Bridge1 or Bridge2
depending upon circumstances.
* Note that there are two different PJSIP/B channels involved.
* Note that until the attended transfer is completed the second call B
makes has no connection with the
first call and thus inherits no channel variables from the first call.
* Note that if the A and C parties are connected to B through local
channels it is the local channels which
represent the A and C parties that are involved in the transfer.

Local channels always come in pairs.  When you dial a local channel it is
the ;1 channel that acts as an
outgoing channel and the ;2 channel executes dialplan and acts as an
incoming channel.  This is the
initial role between the two channels in a local channel pair.  In the
transfer scenario I describe above
(the answering channel initiates the transfer) the local channels maintain
the relationships after the transfer.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20180808/e4577a86/attachment.html>