Thanks for the response, I handle each call individually in this initial phase, where each call starts a ESL connection and handle the event subscription:
to monitor different events based on the "Channel-Call-UUID":
events = "BACKGROUND_JOB " \
         "DETECTED_TONE " \
         "CHANNEL_OUTGOING " \
         "CHANNEL_CREATE " \
         "CHANNEL_ANSWER " \
         "CHANNEL_PROGRESS_MEDIA " \
         "RECORD_START " \
         "CHANNEL_HANGUP " \
         "CHAN_NOT_IMPLEMENTED "

I will probably change the way I handle ESL connections for all my calls (~200 simultaneous calls @5CPS)

I had HAproxy doing TCP loadbalancer for ESL to couple of FS and what you mention makes sense, many TCP connections end up killing HAproxy.

Thanks

-Gonzalo


On Fri, Oct 7, 2016 at 6:32 AM, Ken Rice <krice@freeswitch.org> wrote:

As Michael commented, TCP connections going up and down can be expensive from a processing stand point, its almost always much more efficient to leave the connections up and re-use them vs tearing them down and restarting them for each new use

 

From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Jerris
Sent: Friday, October 7, 2016 8:09 AM
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>
Subject: Re: [Freeswitch-users] ESL terminate calls

 

why would you hang up a call that just hung up?  if you keep disconnecting the esl connection don't you just have to keep connecting a new one?  why do you do that?

On Friday, October 7, 2016, Gonzalo Gasca Meza <gascagonzalo@gmail.com> wrote:

I'm launching API Calls using ESL in FS 1.6 (via python)

 

For each new call, after call is hangup, 

I send a uuid_kill and then ESL.client.disconnect()

Are both necessary, or I can skip uuid_kill?

 

I'm trying to improve performance in my ESL and avoid unnecessary TCP connections to Freeswitch.

 

Thanks

 

-G

 

 

 


_________________________________________________________________________
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