Transfer caller to exten

[dj_kill]

Hello.

For some scenario I want to redirect calls in AMI script to extension.

So, scenario: CallerA call to CallerB. CallerB answers, to both callers some files played and then both redirected to context/exten.

I use Manager Redirect AMI call.
If I redirect only CallerB than it goes to context/exten and CallerA got disconnected.
If I use ExtraChannel/ExtraContext/ExtraPriority in Redirect - both CallerA and CallerB hangs
If I redirect only CallerA also both hangs.

Is it possible somehow redirect call originator channel from AMI script?

[david551]

That is not what I would expect. Please provide logs.

[dj_kill]

Yes, sure.
Caller A (he originate call) - 996098
Caller B (he receive call) - 996099
Asterisk: Asterisk 13.27.0

extensions.conf:

[dynamic-nway]
exten => _X.,1,NoOp(-------------------- Call goes to MeetMe ----------------------------)
exten => _X.,n,Set(CONFNO=${EXTEN})
exten => _X.,n,Set(MEETME_EXIT_CONTEXT=dynamic-nway-invite)
exten => _X.,n,Set(DYNAMIC_FEATURES=)
exten => _X.,n,MeetMe(${CONFNO},pdMX)
exten => _X.,n,Hangup

[996]
exten => _XXX,1,NoOp(-------------------- Custom calls ----------------------------)
exten => _XXX,n,Set(DYNAMIC_FEATURES=nway-start)
exten => _XXX,n,Dial(SIP/${CONTEXT}${EXTEN},60,rTtg)

[dynamic-nway-invite]
exten => 0,1,NoOp(-------------------- N-Way adding caller  ----------------------------)
exten => 0,n,Set(DYNAMIC_FEATURES=nway-inv#nway-noinv)
exten => 0,n,AGI(nway.py,${CONFNO})

exten => i,1,AGI(nway.py,${CONFNO})

[macro-nway-start]
exten => s,1,NoOp(-------------------- N-Way call initialized ----------------------------)
exten => s,n,Set(CONFNO=${RAND(100,100000)})
exten => s,n,AGI(nway.py,${CONFNO})
exten => s,n,Hangup()

[macro-nway-ok]
exten => s,1,NoOp(-------------------- N-Way call caller added ----------------------------)
exten => s,n,AGI(nway.py,${CONFNO})

[macro-nway-notok]
exten => s,1,NoOp(-------------------- N-Way call caller denied ----------------------------)
exten => s,n,SoftHangup(${BRIDGEPEER})

Session log is in attachment.

AMI command are:

rdict = {
          'Action': 'Redirect',
        'ActionID': str(uuid4()),
         'Channel': '',
           'Exten': '',
         'Context': 'dynamic-nway',
        'Priority': '1',

First redirect Channel = BRIDGEPEER and exten is randum number.
Second redirect Channel = CHANNEL to the same exten.

Actually I want to create n-way call scenario with AGI and AMI.

logs.txt (217.6 KB)

[david551]

So this isn’t actually third party control then!

Have you read this warning:

; IMPORTANT NOTE: The applicationmap is not intended to be used for all Asterisk
; applications. When applications are used in extensions.conf, they are executed
; by the PBX core. In this case, these applications are executed outside of the
; PBX core, so it does not make sense to use any application which has any
; concept of dialplan flow. Examples of this would be things like Goto,
; Background, WaitExten, and many more. The exceptions to this are Gosub and
; Macro routines which must complete for the call to continue.

You are doing Goto in a sneaky way and I’m not surprised it doesn’t work. I’d say you were way outside the intended usage of custom features.

I’d suggest proper third party control (a separate thread which is not triggered by the feature code) which monitors for the DTMF.

[ambiorixg12]

Mybe trying the F option on the dial command you could do the transfer, if Asterisk assume the redirect of the caller as hangup,

[dj_kill]

Than I don’t fully understand what does it mean “3rd party control”.
For the n-way call it should be like another PBX and calls should be bridged to that PBX?

I search a lot on internet and I saw some examples with n-way call scenario with ChannelRedirect (which is not working) and a lot of remarks about “3rd party control” without any solution example…

Can you please explain a bit?

[dj_kill]

For example this scenario will be “third party control”:
https://wiki.asterisk.org/wiki/display/AST/ARI+and+Channels%3A+Handling+DTMF

[david551]

Third party control means that the call is being manipulated by something which is not part of the call itself. AMI is typically used for third party control, so AMI Redirect is intended for third party control use. You are trying to get the code associated with one of the parties to initate the the operations, which is first party control.

You need to either monitor the DTMF events from an AMI process, or have the feature generate a user event whcih is detected by an AMI process

You are, in a way, undermining the mechanism that you used to initiate the redirection during the redirection. It is difficult to analyze exactly that will be handled, but is clearly well outside the intended use of custom features.

Double redirects do work when they are ued, as expected, on a call that is bridged.

Also I asked for traces, but you only gave the dialplan. Whilst I think that this whole arrangement needs rethinking, if one wanted to understand whate was going wrong currently, you will need very extensive tracing, almost certainly including the DEBUG level.

[dj_kill]

Traced with AMI debug are attached as a file. logs.txt

By 3rd party you mean something like event listener. And in that event listener we need to catch specific DTMFs, get all bridge details for these DTMFs and manipulate them over AMI?
Can we redirect call from AMI script which is not triggered within that call?

[david551]

It is not usual to trigger an AMI script within a call!