[asterisk-users] How to disable subsequent transfers?

Andres Asterisk andresasterisk at gmail.com
Fri Sep 2 04:31:20 CDT 2016 

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 at 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 at 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 at coordinador:1]
Answer("Local/646xxxxxx at coordinador-00000014;2", "") in new stack
(..after some processing)
    -- Executing [s at macro-midial3:5]
Dial("Local/646xxxxxx at 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 at 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 at coordinador-00000014
;1!11139!!!3!51!Local/646xxxxxx at coordinador-00000014;1!1472723678.143
SIP/ctaadmon-00000056!macro-midial3!s!1!Up!AppDial!(Outgoing
Line)!646xxxxxx!!!3!18!Local/646xxxxxx at coordinador-00000014;2!1472723667.142
Local/646xxxxxx at coordinador-00000014;1!coordinador!646xxxxxx!1!Up!Transferred
Call!SIP/ctaadmon-00000054!!!!3!18!SIP/ctaadmon-00000054!1472723666.140
Local/646xxxxxx at 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 at coordinador-00000014;1 and
Local/646xxxxxx at 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 at coordinador-00000014;1
[Sep  1 11:54:59] DTMF[18360]: channel.c:4204 __ast_read: DTMF begin
passthrough '1' on Local/646xxxxxx at 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 at 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 at coordinador-00000014;1
[Sep  1 11:54:59] DTMF[18360]: channel.c:4178 __ast_read: DTMF end
passthrough '1' on Local/646xxxxxx at coordinador-00000014;1
    -- Started music on hold, class 'default', on SIP/ctaadmon-00000054
    -- <Local/646xxxxxx at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20160902/8ebc370b/attachment.html>

More information about the asterisk-users mailing list