VoIP Mailing List Archives

andresasterisk at gmai... · Guest

Hi,

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.
Then, the agent makes an attended transfer (using asterisk internal transfer) of this costumer to some other party.
When the transfer is made, none of the endpoints should be able to make subsequent transfers.

On the Queue statement where the incoming call is placed, the 't' flag is used to enable the agent to make the transfer.
On the Dial statement used in the attended transfer, neither the 't' nor the 'T' flags are used.

But, after the transfer is completed, the party that the customer was transfered to is still able to tranfer.
I'll show some logs from my testing environment:

asterisk1*CLI> features show
Builtin Feature           Default Current
---------------           ------- -------
Pickup                    *8      *8
Blind Transfer            #       B
Attended Transfer                 1
One Touch Monitor
Disconnect Call           *       *0
Park Call
One Touch MixMonitor

(etc...)

Incoming call:

== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
    -- Executing [333@from-ctaadmon:1] NoOp("SIP/ctaadmon-00000054", "Entra el num 11139 con name Sala de formacion 3 exten=333") in new stack
(... some processing, then)
    -- Executing [333@from-ctaadmon:26] Queue("SIP/ctaadmon-00000054", "cola_agentes,twWr,,,,restartmixmonitor.py,enviar-canal-por-sendtext") in new stack

Notice that parameter t is used on the queue application. The agent should be able to transfer the call.
Then the agent picks up the call:

== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
    -- Called SIP/1001
    -- SIP/1001-00000055 connected line has changed. Saving it until answer for SIP/ctaadmon-00000054
    -- SIP/1001-00000055 is ringing
    -- SIP/1001-00000055 connected line has changed. Saving it until answer for SIP/ctaadmon-00000054
    -- SIP/1001-00000055 answered SIP/ctaadmon-00000054
(etc...)

SIP/ctaadmon-00000054 -> customer channel.
SIP/1001-00000055 -> agent channel.

Now that the agent is talking to the customer, the two channels are bridged:

asterisk1*CLI> core show channels concise
SIP/1001-00000055!coordinador!333!1!Up!AppQueue!(Outgoing Line)!1001!!!3!12!SIP/ctaadmon-00000054!1472723633.139
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

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),
which is assigned to the attended transfer, then the number which he wants to transfer the customer to:

[Sep 1 11:54:22] DTMF[18353]: channel.c:4109 __ast_read: DTMF end '1' received on SIP/1001-00000055, duration 250 ms
[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
[Sep 1 11:54:22] DTMF[18353]: channel.c:4271 __ast_read: DTMF end emulation of '1' queued on SIP/1001-00000055
    -- Started music on hold, class 'default', on SIP/ctaadmon-00000054
    -- <SIP/1001-00000055> Playing 'pbx-transfer.gsm' (language 'en')
[Sep 1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end '6' received on SIP/1001-00000055, duration 250 ms
[Sep 1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough '6' on SIP/1001-00000055
[Sep 1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end '4' received on SIP/1001-00000055, duration 250 ms
[Sep 1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough '4' on SIP/1001-00000055
[Sep 1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end '6' received on SIP/1001-00000055, duration 250 ms
[Sep 1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough '6' on SIP/1001-00000055
[Sep 1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end 'x' received on SIP/1001-00000055, duration 250 ms
[Sep 1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough 'x' on SIP/1001-00000055
[Sep 1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end 'x' received on SIP/1001-00000055, duration 250 ms
[Sep 1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough 'x' on SIP/1001-00000055
[Sep 1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end 'x' received on SIP/1001-00000055, duration 250 ms
[Sep 1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough 'x' on SIP/1001-00000055
[Sep 1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end 'x' received on SIP/1001-00000055, duration 250 ms
[Sep 1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough 'x' on SIP/1001-00000055
[Sep 1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end 'x' received on SIP/1001-00000055, duration 250 ms
[Sep 1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough 'x' on SIP/1001-00000055
[Sep 1 11:54:23] DTMF[18353]: channel.c:4109 __ast_read: DTMF end 'x' received on SIP/1001-00000055, duration 250 ms
[Sep 1 11:54:23] DTMF[18353]: channel.c:4178 __ast_read: DTMF end passthrough 'x' on SIP/1001-00000055
    -- Executing [646xxxxxx@coordinador:1] Answer("Local/646xxxxxx@coordinador-00000014;2", "") in new stack
(..after some processing)
    -- Executing [s@macro-midial3:5] Dial("Local/646xxxxxx@coordinador-00000014;2", "SIP/ctaadmon/0646xxxxxx,,frRM(cambiardb-canal-original)") in new stack
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
    -- Called SIP/ctaadmon/0646xxxxxx
    -- SIP/ctaadmon-00000056 answered Local/646xxxxxx@coordinador-00000014;2
(...)

The attended transfer is made without any problem. On the 'Dial' statement neither 't' nor 'T' flags are used.
Now, we have four channels:

asterisk1*CLI> core show channels concise
SIP/ctaadmon-00000054!coordinador!646xxxxxx!1!Up!Transferred Call!Local/646xxxxxx@coordinador-00000014;1!11139!!!3!51!Local/646xxxxxx@coordinador-00000014;1!1472723678.143
SIP/ctaadmon-00000056!macro-midial3!s!1!Up!AppDial!(Outgoing Line)!646xxxxxx!!!3!18!Local/646xxxxxx@coordinador-00000014;2!1472723667.142
Local/646xxxxxx@coordinador-00000014;1!coordinador!646xxxxxx!1!Up!Transferred Call!SIP/ctaadmon-00000054!!!!3!18!SIP/ctaadmon-00000054!1472723666.140
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

Which are:

SIP/ctaadmon-00000054 -> costumer channel.
SIP/ctaadmon-00000056 -> party where the costumer was transfered to.
Local/646xxxxxx@coordinador-00000014;1 and Local/646xxxxxx@coordinador-00000014;2 -> Local channels created during transfer.

The problem is that if the called party (646xxxxxx) presses the '1' key (sends a '1' dtmf), then a transfer is initiated:

[Sep 1 11:54:59] DTMF[18358]: channel.c:4194 __ast_read: DTMF begin '1' received on SIP/ctaadmon-00000056
[Sep 1 11:54:59] DTMF[18358]: channel.c:4204 __ast_read: DTMF begin passthrough '1' on SIP/ctaadmon-00000056
[Sep 1 11:54:59] DTMF[18360]: channel.c:4194 __ast_read: DTMF begin '1' received on Local/646xxxxxx@coordinador-00000014;1
[Sep 1 11:54:59] DTMF[18360]: channel.c:4204 __ast_read: DTMF begin passthrough '1' on Local/646xxxxxx@coordinador-00000014;1
[Sep 1 11:54:59] DTMF[18358]: channel.c:4109 __ast_read: DTMF end '1' received on SIP/ctaadmon-00000056, duration 160 ms
[Sep 1 11:54:59] DTMF[18358]: channel.c:4149 __ast_read: DTMF end accepted with begin '1' on SIP/ctaadmon-00000056
[Sep 1 11:54:59] DTMF[18358]: channel.c:4178 __ast_read: DTMF end passthrough '1' on SIP/ctaadmon-00000056
[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
[Sep 1 11:54:59] DTMF[18360]: channel.c:4149 __ast_read: DTMF end accepted with begin '1' on Local/646xxxxxx@coordinador-00000014;1
[Sep 1 11:54:59] DTMF[18360]: channel.c:4178 __ast_read: DTMF end passthrough '1' on Local/646xxxxxx@coordinador-00000014;1
    -- Started music on hold, class 'default', on SIP/ctaadmon-00000054
    -- <Local/646xxxxxx@coordinador-00000014;1> Playing 'pbx-transfer.gsm' (language 'en')
[Sep 1 11:55:03] WARNING[18360]: features.c:2560 builtin_atxfer: No digits dialed for atxfer.
    -- <Local/646xxxxxx@coordinador-00000014;1> Playing 'pbx-invalid.gsm' (language 'en')

Channel SIP/ctaadmon-00000056 passes through the dtmf digit.
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.
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
Queue statement with the 't' flag executed on the customer channel (SIP/ctaadmon-00000054)?

If so, how can i fix that?
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
neither 't' or 'T' on the Dial that is made in the transfer.
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..

Regards,

Andrés