I had a similar use case to this although I use Event Socket to control the call rather than an XML dialplan. You could do something like this:

Incoming call from A-Leg hits a dialplan extension that calls the API 'originate' command to create a new call between the proxy endpoint and your conference application. The originate command would look something like this:
originate sofia/gateway/proxy/$1 &bridge(9999@public)

This new call is completely independent of the A-leg, so should persist when the A-leg hangs up.

Some info on calling api commands from the dialplan can be found here: https://wiki.freeswitch.org/wiki/Mod_commands#From_the_Dialplan

Hope that helps!

Sean.
http://www.wirex-precision.co.uk



On Tue, Sep 5, 2017 at 1:36 PM, David Villasmil <david.villasmil.work@gmail.com> wrote:
I have this dialplan i'd like to do, let's see if i can explain it :)

I have a call coming in on 5080, which i forward to another box.
When B-leg is answered, I want to disconnect the A-leg and bridge B-leg to a conference.

I'm trying with the following:


    <extension name="Move_b_leg_to_conference" continue="false">
        <condition field="destination_number" expression="^9999$">
            <action application="callcenter" data="support@default"/>
        </condition>
    </extension>
   
    <extension name="Forward_to_proxy" continue="true">
        <condition field="destination_number" expression="^(.*)$">
            <action application="export" data="nolocal:execute_on_answer=transfer -bleg 9999@public"/>
            <action application="bridge" data="sofia/gateway/proxy/$1"/>
            <action application="hangup" data="NORMAL_CLEARING"/>
        </condition>
    </extension>
 
The idea is to answer the call with the second extension and execute_on_answer to transfer the b-leg to extension 9999 on public, which sends it over to the conference...

But this doesn't seem to be working, the call seems to be sent to 9999@public:

2017-09-04 23:09:21.243247 [NOTICE] sofia.c:8159 Channel [sofia/external/4345412121] has been answered
EXECUTE sofia/external/4345412121 transfer(-bleg 9999@public)
2017-09-04 23:09:21.243247 [DEBUG] switch_ivr.c:2165 (sofia/external/12345@1.2.3.4) State Change CS_EXECUTE -> CS_ROUTING
2017-09-04 23:09:21.243247 [NOTICE] switch_ivr.c:2172 Transfer sofia/external/12345@1.2.3.4 to XML[9999@public@public]

I've also tried doing uuid_transfer on the bleg like so:

    <extension name="Forward_to_proxy" continue="true">
        <condition field="destination_number" expression="^(.*)$">
            <action application="set" data="new_uuid=${create_uuid foo}" inline="true"/>
            <!-- <action application="export" data="nolocal:api_on_answer=uuid_transfer ${new_uuid} -bleg 9999 XML public"/> -->
            <action application="bridge" data="{hangup_after_bridge=true,origination_uuid=${new_uuid}}sofia/gateway/proxy/$1"/>
            <action application="uuid_kill" data="${uuid}"/>
        </condition>
    </extension>

and also instead of uuid_transfer, i tried putting the bleg on hold like:

            <action application="export" data="nolocal:api_on_answer=uuid_hold ${new_uuid}"/>

But is seems as soon as the aleg dies, the whole thing dies


Help is much appreciated!



Regards,

David Villasmil
ᐧ

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org