[Freeswitch-users] Bridge Call and Join Conference

[Colin Morelli]

Ugh and now I'm here to throw another wrench in this whole problem again.
Apparently this approach works *on some calls *and not on others. While I
can't yet identify why it works, it does consistently fail on some numbers.
For example, this works when dialing my cell phone (consistently). It fails
(consistently) when dialing the (804) 222-1111 test number

Looking through the call logs, it seems that in the case it works (with my
cell phone), uuid_transfer executes the transfer on the bridged channel *and
then* the originator channel. In the case where it doesn't work (the test
number), uuid_transfer executes the transfer on the originator channel, and
never touches the bridged channel. This results in the originate failing
with ORIGINATOR_CANCEL.

Is this a bug? It seems like for some reason the api_on_answer executes (on
some calls) possibly too early.

Best,
Colin

On Sat, Jun 4, 2016 at 1:00 PM Colin Morelli <colin.morelli at gmail.com>
wrote:

> Nevermind I think I figured it out. Using "export" instead of "set" caused
> api_on_answer to be set on both channels. Combined with the {mintwo} flag
> on the conference, what ended up happening was FS would execute the
> transfer of both channels for the first channel, which would place both
> callers into the conference. Then, it would execute the api_on_answer for
> the bridged channel (because that variable was exported) which (depending
> on when it ran) would pull the channel out of the conference and put it
> back in, but pulling that user out would trip the mintwo flag and
> apparently leave the call in a strange state.
>
> Changing "export" to "set" seems to have solved the problem.
>
> On Sat, Jun 4, 2016 at 12:53 PM Colin Morelli <colin.morelli at gmail.com>
> wrote:
>
>> Alright so after experimenting with this, it doesn't seem to work
>> reliably (though I may be using it wrong). Roughly half of the time
>> everything works fine and both parties are joined together. The other half
>> of the time the bridged leg doesn't make it to the conference (but also
>> stays active). This is the httapi response I'm providing:
>>
>> <document type="xml/freeswitch-httapi">
>>    <work>
>>       <execute application="export" data="hangup_after_bridge=false" />
>>       <execute application="export" data="api_on_answer=uuid_transfer
>> ${uuid} -both
>> 'conference:2ee73476-aea4-4f85-861f-287f90a42275++flags{mintwo,dist-dtmf}'
>> inline" />
>>       <execute application="export" data="ringback=${us-ring}" />
>>       <execute application="bridge" data="sofia/external/
>> sips:number at sip.trunking.provider.com;transport=tls" />
>>    </work>
>> </document>
>>
>> Would appreciate any insight.
>>
>> Best,
>> Colin
>>
>> On Wed, Jun 1, 2016 at 12:13 PM Colin Morelli <colin.morelli at gmail.com>
>> wrote:
>>
>>> Awesome - this is exactly what I was looking for. Don't know how I
>>> missed it.
>>>
>>> Thank you!
>>>
>>> Best,
>>> Colin
>>>
>>> On Wed, Jun 1, 2016 at 12:08 PM Abaci B <abaci64 at gmail.com> wrote:
>>>
>>>> one way to do it would be to use api_on_answer
>>>> <https://freeswitch.org/confluence/display/FREESWITCH/Channel+Variables#ChannelVariables-Theapi_onfamily>
>>>> to execute a uuid_transfer -both
>>>> <https://freeswitch.org/confluence/display/FREESWITCH/mod_commands#mod_commands-uuid_transfer>
>>>> to transfer both legs to the conference (make sure to set
>>>> hangup_after_bridge to false).
>>>>
>>>> On Tue, May 31, 2016 at 4:59 PM, Colin Morelli <colin.morelli at gmail.com
>>>> > wrote:
>>>>
>>>>> So, I'm trying to setup certain calls such that they enter into a
>>>>> conference asap. I have the process working using bridging conferences
>>>>> right now, which is okay, but bridging conferences forces the dialing leg
>>>>> of the call to go to an answered state immediately, while the bridge leg is
>>>>> still ringing. So, while everything seems to work correctly, it messes with
>>>>> some of my reconciliation/reporting process with another database that are
>>>>> fed off of channel state events. Essentially it looks like every call was
>>>>> answered.
>>>>>
>>>>> So I was curious to know if there's a way to make a call that creates
>>>>> a bridged leg, and then as soon as the leg is answered immediately joins
>>>>> both legs into a conference. Is the only way to do it to listen for the
>>>>> channel_bridge events and then transfer the call myself?
>>>>>
>>>>> Best,
>>>>> Colin
>>>>>
>>>>>
>>>>> _________________________________________________________________________
>>>>> Professional FreeSWITCH Consulting Services:
>>>>> consulting at 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 at lists.freeswitch.org
>>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>>> UNSUBSCRIBE:
>>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>>> http://www.freeswitch.org
>>>>>
>>>>
>>>>
>>>> _________________________________________________________________________
>>>> Professional FreeSWITCH Consulting Services:
>>>> consulting at 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 at lists.freeswitch.org
>>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>> UNSUBSCRIBE:
>>>> http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>> http://www.freeswitch.org
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160604/8f3371b7/attachment.html