<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-compose;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">> Doing some more tests, this reads like a bug to me.<br>
> Using a hanguphandler with DumpChan in the dialplan context that executes<br>
> the Queue, I can see that DYNAMIC_FEATURES is set.<br>
> After the attended transfer when the call is ended, the hanguphandler still<br>
> shows that DYNAMIC_FEATURES is set. It's just not accessible.<br>
><br>
> Any thoughts?<br>
> It likely depens on how you are doing the attended transfer. Via DTMF? Via SIP<br>
> or channel technology protocol?<br>
> Does the Agent B channel have the DYNAMIC_FEATURES channel variable set<br>
> on it?<br>
><br>
<br>
Thanks for the reply.<br>
<br>
To answer your question, the attended transfers are done via the endpoint's feature buttons. So I assume it's via SIP requests.<br>
<br>
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.<br>
<br>
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().<br>
<br>
For non-Queue calls that are going via the Local Channels that only use Dial().<br>
When endpoint_201 dials *1, it is matched with their own channel.<br>
> DTMF feature hook 0x7f18d803a978 matched DTMF string '*1' on 0x7f18c000b080(PJSIP/endpoint_201-0000cb55)<br>
<br>
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.<br>
At that point, it can match the local channel since that's where DYNAMIC_FEATURES was originally set.<br>
> No DTMF feature hooks on 0x7f189c0660b0(PJSIP/endpoint_202-0000cb5b) match '*1'<br>
> DTMF feature hook 0x7f1894abd408 matched DTMF string '*1' on 0x7f186c04efa0(Local/fromfeature_201@phones-00005a17;1)<br>
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.<br>
Probably works by accident.<br>
<br>
But calls passing through a Local channel that ends in Queue() don't act the same way.<br>
<br>
The Queue's initial dial of the queuemembers includes the inheritance as expected.<br>
So when endpoint_201 answers and they dial *1, this is the result.<br>
> DTMF feature hook 0x7f18c4018278 matched DTMF string '*1' on 0x7f18b0002ca0(PJSIP/endpoint_201-0000cacc)<br>
<br>
But following a transfer, using the same SIP messaging as the non-queue calls, this is the result...<br>
> DTMF feature string on 0x7f18bd369720(PJSIP/endpoint_202-0000cae8) is now '*1'<br>
> No DTMF feature hooks on 0x7f18bd369720(PJSIP/endpoint_202-0000cae8) match '*1'<br>
> Playing DTMF stream '*1' out to 0x7f18e4112980(Local/queue_dialplan_101@queue-000059b2;2) <---- this channel still has DYNAMIC_FEATURES set (see below) but it just passes the DTMF through?<br>
> DTMF begin '*' received on Local/queue_dialplan_101@queue-000059b2;1<br>
> DTMF begin passthrough '*' on Local/queue_dialplan_101@queue-000059b2;1<br>
and it's passed all the way back and played to the caller.<br>
<br>
This is in spite of the fact that Local/queue_dialplan_101@queue-000059b2;2 has DYNAMIC_FEATURES set earlier in the dialplan.<br>
> Set("Local/queue_dialplan_101@queue-000059b2;2", "__DYNAMIC_FEATURES=NewRecordApp")<br>
And still set at the end of the call, confirmed using DumpChan within the channels hangup handler.<br>
<br>
> Dumping Info For Channel: Local/queue_dialplan 101@queue-000059b2;2:<br>
> Variables:<br>
> DYNAMIC_FEATURES=NewRecordApp<br>
<br>
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.<br>
<br>
I hope that wasn't too long winded!<br>
<br>
Thanks for the help and time!<br>
Dan</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif""><o:p></o:p></span></p>
</div>
</body>
</html>