[Freeswitch-users] Bridge Call and Join Conference

[Colin Morelli]

Sorry for blowing everyone up with emails - but hopefully this will be
helpful to someone else in the future.

As it turns out, api_on_answer is entirely disconnected from the bridging
concept (makes sense now that I look into how this all works more). It was
working when calling my cell phone because I was receiving early media
(ringing) from the SIP trunking provider. This resulted in the bridge
starting so that, by the time api_on_answer executed, there was a bridged
leg. In the case of the test number, however, I receive no early media. As
a result, when the channel was answered, the bridge hadn't started yet, so
there was no remote leg to transfer.

After digging through the source, I discovered, "api_before_bridge" which
appears to execute *after* the channels have have their peer sessions
setup, as part of the bridge loop, whether early media was present or not.
This now seems to be working consistently, as I expect it to.

I'd still really appreciate someone letting me know if this is good/bad, or
if you know of a better approach.

Best,
Colin

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

> 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/124f6b14/attachment-0001.html