IAX2: Transfering a call back to originating server

[TJNII]

This is probably a simple problem but I’m struggling to find the answers, most threads are about how to get Asterisk to stop doing what I want.

I have two Asterisk servers. One is a primary, which handles all calls, the other is a enclave which handles a Stasis app. They’re linked over IAX2. The configs on both sides are nearly identical:

[general]
bandwidth=high
disallow=lpc10
jitterbuffer=no
encryption=yes
autokill=yes

[otherserver]
<The usual host and auth bits>
qualify=yes
trunk=yes

The flow is:

• A call comes into the primary for the app on the enclave
• The primary Dial()s the enclave over IAX2
• The enclave accepts the call, does a bunch of setup and app specific stuff
• When ready the enclave sends the call back to the primary via another Dial()

This is working, but the enclave server is staying in the call path. Simplifying this with a simple loopback dialplan:

Primary:

exten => _42XX,1,Dial(IAX2/dialin_bridge_internal/${EXTEN}@dialin_bridge_private_extens)
exten => 1230,1,Dial(PJSIP/1230)

Enclave:

exten => 4211,1,Dial(IAX2/primary/1230@dialin_bridge_internal_dialout)

I see the following on the enclave:

4d8fd57aa6e3*CLI> iax2 show channels
Channel               Peer                                      Username    ID (Lo/Rem)  Seq (Tx/Rx)  Lag      Jitter  JitBuf  Format  FirstMsg    LastMsg
IAX2/primary-11448    10.128.0.5                                primary     11448/30321  00014/00009  00040ms  -0001ms  0000ms  ulaw    Rx:NEW      Tx:ACK
IAX2/primary-22728    10.128.0.5                                dialin_bri  22728/10674  00009/00013  00040ms  -0001ms  0000ms  ulaw    Tx:NEW      Rx:ACK
2 active IAX channels

4d8fd57aa6e3*CLI> bridge show db641742-f2fe-42e2-9811-2b2dc9a701db
Id: db641742-f2fe-42e2-9811-2b2dc9a701db
Type: basic
Technology: simple_bridge
Subclass: basic
Creator:
Name:
Video-Mode: none
Video-Source-Id:
Num-Channels: 2
Num-Active: 2
Duration: 00:00:38
Channel: IAX2/primary-11448
Channel: IAX2/primary-22728

I tried using transfer but I’m 99% sure I’ve got the wrong syntax, I need to include the context:

exten => 4221,1,Transfer(IAX2/primary/1230@dialin_bridge_internal_dialout)
exten => 4221,n,NoOp("TransferStatus: ${TRANSFERSTATUS}")

When calling this I see:

[Feb 21 00:53:50]     -- Executing [4221@dialin_bridge_private_extens:1] Transfer("IAX2/primary-7359", "IAX2/primary/1230@dialin_bridge_internal_dialout") in new stack
[Feb 21 00:53:50]     -- Executing [4221@dialin_bridge_private_extens:2] NoOp("IAX2/primary-7359", ""TransferStatus: SUCCESS"") in new stack

But on the primary I see:

[Feb 21 00:54:19] WARNING[107][C-00000012]: chan_iax2.c:11173 socket_process_helper: Blind transfer of 'IAX2/dialin_bridge-17389' to 'primary/1230@dialin_bridge_internal_enter' failed

A search is yielding almost no IAX Transfer() examples, and none with a context. I tried turning on iax and core debugging but there wasn’t really any context around that warning. I might be totally off base in thinking I need to use Transfer() anyway.

Is there an easy way to get the enclave out of the channel path once the setup is done? Is there something obvious I’m overlooking here?

[penguinpbx]

Related to transfers of encrypted IAX calls, there is this debug note in chan_iax2.c:

ast_debug(1, "transfers are not supported for encrypted calls at this time\n");

As a potential workaround – not tested – if you:

1. Set up the variables that you want to share using IAXVAR function on server A - make one of these the name of the channel
2. Dial() with the ‘g’ option from server A to B
3. Figure things out on server B
4. Set up same/similarly named variables with IAXVAR on server B - making sure to set one of them as the name of the channel received from A so there is a reference point
5. Dial() back from server B to A
6. Stash the variables coming from B into a SHARED variable on A - using that key channel name from step 1
7. Hangup the “boomerang” call on A
8. Move forward to the next step in the dial plan with the original incoming call on A, where you parse out the SHARED variables

…then you might be able to close-the-loop.

[TJNII]

@penguinpbx

“transfers are not supported for encrypted calls at this time\n”

Aha, good find. That’s probably it. I’ll have to go back and reproduce to be sure, I don’t think I tried disabling encryption because I wouldn’t have expected that to be a problem. The system is working and the impact of this problem is low so I’ll probably just live with the behavior as higher priority problems have already stolen my focus. Good to know why it’s happening, thanks!