Persist outbound event socket after channel is destroyed
I'm using the socket application in the dialplan to establish an outbound event socket to my app. I use the async and full flags to expose full api functionality. I currently use myevents to filter only events related to the current channel, I also use the linger command to ensure the socket stays up until all channel events have been sent to my app (after which FS then tears down the socket). However, what I'm trying to do is prevent FS closing the socket at all, and always leave it up to my app to close the socket when it's finished with it. Is this possible with ESL in outbound mode? In other words, I want the socket to linger longer :) Sean.
What exactly do you want to do? The call is already over... If you want to monitor FS or do anything else not related to the call, you should probably be using an INBOUND socket. Guillermo On Mon, Aug 7, 2017 at 5:35 AM, Sean Ingham <sean@missionlabs.co.uk> wrote:
I'm using the socket application in the dialplan to establish an outbound event socket to my app. I use the async and full flags to expose full api functionality.
I currently use myevents to filter only events related to the current channel, I also use the linger command to ensure the socket stays up until all channel events have been sent to my app (after which FS then tears down the socket).
However, what I'm trying to do is prevent FS closing the socket at all, and always leave it up to my app to close the socket when it's finished with it. Is this possible with ESL in outbound mode?
In other words, I want the socket to linger longer :)
Sean.
_________________________________________________________________________ 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
-- Guillermo Ruiz Camauer
linger is the closest thing to this. It will wait for final events before it drops.
On Aug 8, 2017, at 10:14 AM, Guillermo Ruiz Camauer <grcamauer@gmail.com> wrote:
What exactly do you want to do? The call is already over... If you want to monitor FS or do anything else not related to the call, you should probably be using an INBOUND socket.
Guillermo
On Mon, Aug 7, 2017 at 5:35 AM, Sean Ingham <sean@missionlabs.co.uk <mailto:sean@missionlabs.co.uk>> wrote: I'm using the socket application in the dialplan to establish an outbound event socket to my app. I use the async and full flags to expose full api functionality.
I currently use myevents to filter only events related to the current channel, I also use the linger command to ensure the socket stays up until all channel events have been sent to my app (after which FS then tears down the socket).
However, what I'm trying to do is prevent FS closing the socket at all, and always leave it up to my app to close the socket when it's finished with it. Is this possible with ESL in outbound mode?
In other words, I want the socket to linger longer :)
Hi Guillermo, Michael, 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. 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. Options I'm considering now are : 1) Use a single socket in inbound mode for all calls and rewrite my app accordingly 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. 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? Any thoughts on the best way to go are much appreciated. Thanks, Sean.
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. Reagards. Guillermo On Wed, Aug 9, 2017 at 1:31 PM, Sean Ingham <sean@missionlabs.co.uk> wrote:
Hi Guillermo, Michael,
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.
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.
Options I'm considering now are : 1) Use a single socket in inbound mode for all calls and rewrite my app accordingly 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.
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?
Any thoughts on the best way to go are much appreciated.
Thanks, Sean.
_________________________________________________________________________ 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
-- Guillermo Ruiz Camauer
participants (3)
-
Guillermo Ruiz Camauer
-
Michael Jerris
-
Sean Ingham