<div dir="ltr">Hi,<br><br> Consider the following scenario. A customer's incoming call enters the system, and after some processing, the call is placed on a queue, where it will be picked up by an agent. <br> Then, the agent makes an attended transfer (using asterisk internal transfer) of this costumer to some other party.<br> When the transfer is made, none of the endpoints should be able to make subsequent transfers.<br> <br> On the Queue statement where the incoming call is placed, the 't' flag is used to enable the agent to make the transfer.<br> On the Dial statement used in the attended transfer, neither the 't' nor the 'T' flags are used.<br><br> But, after the transfer is completed, the party that the customer was transfered to is still able to tranfer. <br> I'll show some logs from my testing environment:<br><br>asterisk1*CLI> features show<br>Builtin Feature           Default Current<br>---------------           ------- -------<br>Pickup                    *8      *8<br>Blind Transfer            #       B<br>Attended Transfer                 1<br>One Touch Monitor<br>Disconnect Call           *       *0<br>Park Call<br>One Touch MixMonitor<br><br>(etc...)<br><br>Incoming call:<br><br>  == Using SIP RTP TOS bits 184<br>  == Using SIP RTP CoS mark 5<br>    -- Executing [333@from-ctaadmon:1] NoOp("SIP/ctaadmon-00000054", "Entra el num 11139 con name Sala de formacion 3 exten=333") in new stack<br>(... some processing, then)<br>    -- Executing [333@from-ctaadmon:26] Queue("SIP/ctaadmon-00000054", "cola_agentes,twWr,,,,restartmixmonitor.py,enviar-canal-por-sendtext") in new stack<br><br>Notice that parameter t is used on the queue application. The agent should be able to transfer the call.<br>Then the agent picks up the call:<br><br>  == Using SIP RTP TOS bits 184<br>  == Using SIP RTP CoS mark 5<br>    -- Called SIP/1001<br>    -- SIP/1001-00000055 connected line has changed. Saving it until answer for SIP/ctaadmon-00000054<br>    -- SIP/1001-00000055 is ringing<br>    -- SIP/1001-00000055 connected line has changed. Saving it until answer for SIP/ctaadmon-00000054<br>    -- SIP/1001-00000055 answered SIP/ctaadmon-00000054<br>(etc...)<br><br>SIP/ctaadmon-00000054 -> customer channel.<br>SIP/1001-00000055 -> agent channel.<br><br>Now that the agent is talking to the customer, the two channels are bridged:<br><br>asterisk1*CLI> core show channels concise<br>SIP/1001-00000055!coordinador!333!1!Up!AppQueue!(Outgoing Line)!1001!!!3!12!SIP/ctaadmon-00000054!1472723633.139<br>SIP/ctaadmon-00000054!from-ctaadmon!333!26!Up!Queue!cola_agentes,twWr,,,,restartmixmonitor.py,enviar-canal-por-sendtext!11139!!!3!12!SIP/1001-00000055!1472723633.138<br><br>Now, the agent makes an attended transfer to 646xxxxxx (a 9 digit number, not shown). To do so, first he sends the '1' key (dtmf), <br>which is assigned to the attended transfer, then the number which he wants to transfer the customer to:<br><br>[Sep  1 11:54:22] DTMF[18353]: channel.c:4109 __ast_read: DTMF end '1' received on SIP/1001-00000055, duration 250 ms<br>[Sep  1 11:54:22] DTMF[18353]: channel.c:4135 __ast_read: DTMF begin emulation of '1' with duration 250 queued on SIP/1001-00000055<br>[Sep  1 11:54:22] DTMF[18353]: channel.c:4271 __ast_read: DTMF end emulation of '1' queued on SIP/1001-00000055<br>    -- Started music on hold, class 'default', on SIP/ctaadmon-00000054<br>    -- <SIP/1001-00000055> Playing 'pbx-transfer.gsm' (language 'en')<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end '6' received on SIP/1001-00000055, duration 250 ms<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough '6' on SIP/1001-00000055<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end '4' received on SIP/1001-00000055, duration 250 ms<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough '4' on SIP/1001-00000055<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end '6' received on SIP/1001-00000055, duration 250 ms<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough '6' on SIP/1001-00000055<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end 'x' received on SIP/1001-00000055, duration 250 ms<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough 'x' on SIP/1001-00000055<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end 'x' received on SIP/1001-00000055, duration 250 ms<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough 'x' on SIP/1001-00000055<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end 'x' received on SIP/1001-00000055, duration 250 ms<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough 'x' on SIP/1001-00000055<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end 'x' received on SIP/1001-00000055, duration 250 ms<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough 'x' on SIP/1001-00000055<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end 'x' received on SIP/1001-00000055, duration 250 ms<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough 'x' on SIP/1001-00000055<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end 'x' received on SIP/1001-00000055, duration 250 ms<br>[Sep  1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough 'x' on SIP/1001-00000055<br>    -- Executing [646xxxxxx@coordinador:1] Answer("Local/646xxxxxx@coordinador-00000014;2", "") in new stack<br>(..after some processing)<br>    -- Executing [s@macro-midial3:5] Dial("Local/646xxxxxx@coordinador-00000014;2", "SIP/ctaadmon/0646xxxxxx,,frRM(cambiardb-canal-original)") in new stack<br>  == Using SIP RTP TOS bits 184<br>  == Using SIP RTP CoS mark 5<br>    -- Called SIP/ctaadmon/0646xxxxxx<br>    -- SIP/ctaadmon-00000056 answered Local/646xxxxxx@coordinador-00000014;2<br>(...)<br><br>The attended transfer is made without any problem. On the 'Dial' statement neither 't' nor 'T' flags are used.<br>Now, we have four channels:<br><br>asterisk1*CLI> core show channels concise<br>SIP/ctaadmon-00000054!coordinador!646xxxxxx!1!Up!Transferred Call!Local/646xxxxxx@coordinador-00000014;1!11139!!!3!51!Local/646xxxxxx@coordinador-00000014;1!1472723678.143<br>SIP/ctaadmon-00000056!macro-midial3!s!1!Up!AppDial!(Outgoing Line)!646xxxxxx!!!3!18!Local/646xxxxxx@coordinador-00000014;2!1472723667.142<br>Local/646xxxxxx@coordinador-00000014;1!coordinador!646xxxxxx!1!Up!Transferred Call!SIP/ctaadmon-00000054!!!!3!18!SIP/ctaadmon-00000054!1472723666.140<br>Local/646xxxxxx@coordinador-00000014;2!macro-midial3!s!5!Up!Dial!SIP/ctaadmon/0646xxxxxx,,frRM(cambiardb-canal-original)!1001!!!3!18!SIP/ctaadmon-00000056!1472723666.141<br><br>Which are:<br><br>SIP/ctaadmon-00000054 -> costumer channel.<br>SIP/ctaadmon-00000056 -> party where the costumer was transfered to.<br>Local/646xxxxxx@coordinador-00000014;1 and Local/646xxxxxx@coordinador-00000014;2 -> Local channels created during transfer.<br><br>The problem is that if the called party (646xxxxxx) presses the '1' key (sends a '1' dtmf), then a transfer is initiated:<br> <br>[Sep  1 11:54:59] DTMF[18358]: channel.c:4194 __ast_read: DTMF begin '1' received on SIP/ctaadmon-00000056<br>[Sep  1 11:54:59] DTMF[18358]: channel.c:4204 __ast_read: DTMF begin passthrough '1' on SIP/ctaadmon-00000056<br>[Sep  1 11:54:59] DTMF[18360]: channel.c:4194 __ast_read: DTMF begin '1' received on Local/646xxxxxx@coordinador-00000014;1<br>[Sep  1 11:54:59] DTMF[18360]: channel.c:4204 __ast_read: DTMF begin passthrough '1' on Local/646xxxxxx@coordinador-00000014;1<br>[Sep  1 11:54:59] DTMF[18358]: channel.c:4109 __ast_read: DTMF end '1' received on SIP/ctaadmon-00000056, duration 160 ms<br>[Sep  1 11:54:59] DTMF[18358]: channel.c:4149 __ast_read: DTMF end accepted with begin '1' on SIP/ctaadmon-00000056<br>[Sep  1 11:54:59] DTMF[18358]: channel.c:4178 __ast_read: DTMF end passthrough '1' on SIP/ctaadmon-00000056<br>[Sep  1 11:54:59] DTMF[18360]: channel.c:4109 __ast_read: DTMF end '1' received on Local/6469xxxxxx@coordinador-00000014;1, duration 160 ms<br>[Sep  1 11:54:59] DTMF[18360]: channel.c:4149 __ast_read: DTMF end accepted with begin '1' on Local/646xxxxxx@coordinador-00000014;1<br>[Sep  1 11:54:59] DTMF[18360]: channel.c:4178 __ast_read: DTMF end passthrough '1' on Local/646xxxxxx@coordinador-00000014;1<br>    -- Started music on hold, class 'default', on SIP/ctaadmon-00000054<br>    -- <Local/646xxxxxx@coordinador-00000014;1> Playing 'pbx-transfer.gsm' (language 'en')<br>[Sep  1 11:55:03] WARNING[18360]: features.c:2560 builtin_atxfer: No digits dialed for atxfer.<br>    -- <Local/646xxxxxx@coordinador-00000014;1> Playing 'pbx-invalid.gsm' (language 'en')<br><br>Channel SIP/ctaadmon-00000056 passes through the dtmf digit.<br>It seems that the channel that picks the digit and starts the transfer is Local/646xxxxxx@coordinador-00000014;1, one of the two 'legs' created on the transfer.<br>Does that local channel inherit the capability to make transfers from the agent channel (SIP/1001-00000055), which in turn can make transfers because of the <br>Queue statement with the 't' flag executed on the customer channel (SIP/ctaadmon-00000054)?<br><br>If so, how can i fix that? <br>If the agent makes an outcoming call, and then he transfers that call, there is no problem, using a 'T' on the first Dial and <br>neither 't' or 'T' on the Dial that is made in the transfer.<br>But if it is a incoming call, it has to be placed in the queue. And then i need the 't' on the queue statement..<br> <br>Regards,<br><br>Andrés<br></div>