<div dir="ltr">Sorry for blowing everyone up with emails - but hopefully this will be helpful to someone else in the future.<div><br></div><div>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.</div><div><br></div><div>After digging through the source, I discovered, "api_before_bridge" which appears to execute <i>after</i> 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.</div><div><br></div><div>I'd still really appreciate someone letting me know if this is good/bad, or if you know of a better approach.</div><div><br></div><div>Best,</div><div>Colin</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jun 4, 2016 at 1:41 PM Colin Morelli <<a href="mailto:colin.morelli@gmail.com">colin.morelli@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ugh and now I'm here to throw another wrench in this whole problem again. Apparently this approach works <i>on some calls </i>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<div><br></div><div>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 <i>and then</i> 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.</div><div><br></div><div>Is this a bug? It seems like for some reason the api_on_answer executes (on some calls) possibly too early.</div><div><br></div><div>Best,</div><div>Colin</div></div><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Sat, Jun 4, 2016 at 1:00 PM Colin Morelli <<a href="mailto:colin.morelli@gmail.com" target="_blank">colin.morelli@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>Changing "export" to "set" seems to have solved the problem.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jun 4, 2016 at 12:53 PM Colin Morelli <<a href="mailto:colin.morelli@gmail.com" target="_blank">colin.morelli@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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:<div><br></div><div><div><font face="monospace"><document type="xml/freeswitch-httapi"></font></div><div><font face="monospace"> <work></font></div><div><font face="monospace"> <execute application="export" data="hangup_after_bridge=false" /></font></div><div><font face="monospace"> <execute application="export" data="api_on_answer=uuid_transfer ${uuid} -both 'conference:2ee73476-aea4-4f85-861f-287f90a42275++flags{mintwo,dist-dtmf}' inline" /></font></div><div><font face="monospace"> <execute application="export" data="ringback=${us-ring}" /></font></div><div><font face="monospace"> <execute application="bridge" data="sofia/external/<a href="mailto:sips%3Anumber@sip.trunking.provider.com" target="_blank">sips:number@sip.trunking.provider.com</a>;transport=tls" /></font></div><div><font face="monospace"> </work></font></div><div><font face="monospace"></document></font></div></div><div><br></div><div>Would appreciate any insight.</div><div><br></div><div>Best,</div><div>Colin</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 1, 2016 at 12:13 PM Colin Morelli <<a href="mailto:colin.morelli@gmail.com" target="_blank">colin.morelli@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Awesome - this is exactly what I was looking for. Don't know how I missed it.<div><br></div><div>Thank you!</div><div><br></div><div>Best,</div><div>Colin</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 1, 2016 at 12:08 PM Abaci B <<a href="mailto:abaci64@gmail.com" target="_blank">abaci64@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>one way to do it would be to use <a href="https://freeswitch.org/confluence/display/FREESWITCH/Channel+Variables#ChannelVariables-Theapi_onfamily" target="_blank">api_on_answer</a> to execute a <a href="https://freeswitch.org/confluence/display/FREESWITCH/mod_commands#mod_commands-uuid_transfer" target="_blank">uuid_transfer -both</a> to transfer both legs to the conference (make sure to set hangup_after_bridge to false).</div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Tue, May 31, 2016 at 4:59 PM, Colin Morelli <span dir="ltr"><<a href="mailto:colin.morelli@gmail.com" target="_blank">colin.morelli@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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. <div><br></div><div>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?</div><div><br></div><div>Best,</div><div>Colin</div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.org</a><br>
<a href="http://www.cluecon.com" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br></blockquote></div><br></div>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.org</a><br>
<a href="http://www.cluecon.com" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a></blockquote></div></blockquote></div></blockquote></div></blockquote></div></div></blockquote></div>