Redirecting channels to a Conference

Hello!

I have a problem with redirecting two non-bridget channes to a Conference.

The dialplan is:

[start-nway]
exten => s,1,NoOp()
        same => n,ChannelRedirect(${BRIDGEPEER},conference-nway,6666,1)
        same => n,ConfBridge(6666)
        same => n,Return()


[conference-nway]
exten => _XXXX,1,Answer()
        same => n,SET(_DYNAMIC_FEATURES=)
        same => n,ConfBridge(${EXTEN})
        same => n,Hangup()

the features.conf is:

[applicationmap](+)
start_nway => *0,self,GoSub,start-nway\,s\,1

When the caller presses *0, the called channel is redirecting to the conference. But the caller’s channel leaves the conference after the first voice phrase. Is it correct?

[Nov 22 14:33:08] DTMF[30894][C-0000004e]: channel.c:4001 __ast_read: DTMF begin '*' received on PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa
[Nov 22 14:33:08] DTMF[30894][C-0000004e]: channel.c:4012 __ast_read: DTMF begin passthrough '*' on PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa
[Nov 22 14:33:08] DTMF[30894][C-0000004e]: channel.c:3887 __ast_read: DTMF end '*' received on PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa, duration 100 ms
[Nov 22 14:33:08] DTMF[30894][C-0000004e]: channel.c:3938 __ast_read: DTMF end accepted with begin '*' on PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa
[Nov 22 14:33:08] DTMF[30894][C-0000004e]: channel.c:3976 __ast_read: DTMF end passthrough '*' on PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa
[Nov 22 14:33:08] DTMF[30894][C-0000004e]: channel.c:4001 __ast_read: DTMF begin '0' received on PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa
[Nov 22 14:33:08] DTMF[30894][C-0000004e]: channel.c:4012 __ast_read: DTMF begin passthrough '0' on PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa
[Nov 22 14:33:08] DTMF[30894][C-0000004e]: channel.c:3887 __ast_read: DTMF end '0' received on PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa, duration 120 ms
[Nov 22 14:33:08] DTMF[30894][C-0000004e]: channel.c:3938 __ast_read: DTMF end accepted with begin '0' on PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa
[Nov 22 14:33:08] DTMF[30894][C-0000004e]: channel.c:3976 __ast_read: DTMF end passthrough '0' on PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa
    -- PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa Internal Gosub(start-nway,s,1) start
    -- Executing [s@start-nway:1] Set("PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa", "BR_TO_CHAN=PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587101-000000ab") in new stack
    -- Executing [s@start-nway:2] ChannelRedirect("PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa", "PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587101-000000ab,conference-nway,6666,1") in new stack
    -- Executing [s@start-nway:3] ConfBridge("PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa", "6666") in new stack
    -- Channel PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587101-000000ab left 'simple_bridge' basic-bridge <168faa99-8e69-4750-84c1-c72199a95883>
    -- Executing [6666@conference-nway:1] Answer("PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587101-000000ab", "") in new stack
    -- Executing [6666@conference-nway:2] Set("PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587101-000000ab", "_DYNAMIC_FEATURES=") in new stack
    -- Executing [6666@conference-nway:3] ConfBridge("PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587101-000000ab", "6666") in new stack
    -- Channel CBAnn/6666-00000058;2 joined 'softmix' base-bridge <3edb6ff1-9eb2-4431-b1cd-8fbb3476acd1>
    -- <PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa> Playing 'conf-onlyperson.slin' (language 'ru')
    -- <PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587101-000000ab> Playing 'confbridge-join.alaw' (language 'ru')
    -- <CBAnn/6666-00000058;1> Playing 'confbridge-join.gsm' (language 'en')
    -- Channel PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587101-000000ab joined 'softmix' base-bridge <3edb6ff1-9eb2-4431-b1cd-8fbb3476acd1>
    -- <PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa> Playing 'confbridge-join.slin' (language 'ru')
    -- <CBAnn/6666-00000058;1> Playing 'confbridge-join.gsm' (language 'en')
    -- Executing [s@start-nway:4] Return("PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa", "") in new stack
  == Spawn extension (manager_dial, s, 3) exited non-zero on 'PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa'
    -- PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa Internal Gosub(start-nway,s,1) complete GOSUB_RETVAL=
    -- Channel PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa left 'simple_bridge' basic-bridge <168faa99-8e69-4750-84c1-c72199a95883>
  == Spawn extension (manager_dial, s, 3) exited non-zero on 'PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa'
    -- PJSIP/9f3ee6b6-30ee-4070-97bf-9bac3fcf8587110-000000aa Internal Gosub(hangup_call_end,s,1) start

I’d say this goes well beyond what is safe to do with a feature code. You are, effectively, forcing the callee into a GoTo, which is not an operation that would be considered safe, even if done directly.

I’d say the result was undefined.

If the special case of atxferthreeway won’t work for you, I’d suggest monitoring the DTMF with AMI and having it do a double channel redirect. One might be able to replace the whole Dial process with ARI, but I have no experience of that, and can’t say whether that really is within its capability.

Cool dial plan!

You might be able to add an astDB variable X into [start-nway], then add g option to the caller’s Dial() application call, and finally branch in next line of dial plan after the Dial() by checking for X. (Not sure, didn’t test - would need to see more details in dial plan and logs.)

Hello! Thanks!
I’v resolved this issue with the Originate command …