<div dir="ltr">I think the inbound socket is the way to go.  You connect once and keep it open. A per call UUID lets your program sort everything out.  All handled in one program, with one socket.  No creating and tearing down processes and sockets constantly.<div><br></div><div>Reagards.</div><div><br></div><div>Guillermo</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 9, 2017 at 1:31 PM, Sean Ingham <span dir="ltr"><<a href="mailto:sean@missionlabs.co.uk" target="_blank">sean@missionlabs.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-size:12.8px">Hi Guillermo, Michael,</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Thanks for your responses. To give some more background, our specific use case is an incoming call (from user A) creates the outbound socket, then our app asks FreeSWITCH to originate a new call (between users B&C). User A then hangs up but the call between B&C will continue. When user A hangs up I still want to receive events from the newly originated (B->C) channel.<br><br>Inbound mode sounds like it might be the way to go but I like the way outbound socket mode creates an individual socket per call - from my app's point of view it's nicely compartmentalised.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><span class="m_-7870686333601983408gmail-im">Options I'm considering now are :<br>1) Use a single socket in inbound mode for all calls and rewrite my app accordingly<br></span>2) Keep using the socket dialplan application to establish an outbound socket, then have my app immediately park the call, close the outbound socket and establish an inbound socket and 'takeover' the call. This retains the advantage of individual sockets per call, but is rather clunky.</div><span class="m_-7870686333601983408gmail-im" style="font-size:12.8px"><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Alternatively is there a way of marking the newly originated channel (B->C) as being a child of the original channel so that when the inbound A leg hangs up the socket stays in place?</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Any thoughts on the best way to go are much appreciated.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Thanks,</div><div style="font-size:12.8px">Sean.</div></span></div>
<br>______________________________<wbr>______________________________<wbr>_____________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.<wbr>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.<wbr>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">FreeSWITCH-users@lists.<wbr>freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/<wbr>mailman/listinfo/freeswitch-<wbr>users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.<wbr>freeswitch.org/mailman/<wbr>options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Guillermo Ruiz Camauer<br></div>
</div>