[Freeswitch-users] using enable_heartbeat to detect network problems in event_socket

Wed Aug 5 18:25:00 MSD 2015

Well, let me suggest you to reconsider your approach. There’s a java library that uses ‘pure java sockets’ (java-esl), it’s based on netty (an implementation of the Java New IO (java.nio) API), and works like a charm. You can use this client library to register for events (heartbeat is one of them) and have a background thread to monitor for those events, while at the same time you can execute commands (answer calls, originate calls, bridge, hangup, schedule operations, etc) by just calling java methods on instances of the Client class.

I think it’s better to use the FreeSWITCH heartbeat event to detect network outages instead of relying on the session_heartbeat (heartbeat events per call). After all, a network outage will affect your control of all calls, so as soon as FS is unreachable, you won’t be able to control the calls anymore. For call disconnects, just listen for the CHANNEL_HANGUP event.

From: <freeswitch-users-bounces at lists.freeswitch.org<mailto:freeswitch-users-bounces at lists.freeswitch.org>> on behalf of Babak Yakhchali <babak.freeswitch at gmail.com<mailto:babak.freeswitch at gmail.com>>
Reply-To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org<mailto:freeswitch-users at lists.freeswitch.org>>
Date: Wednesday, August 5, 2015 at 6:54 AM
To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org<mailto:freeswitch-users at lists.freeswitch.org>>
Subject: Re: [Freeswitch-users] using enable_heartbeat to detect network problems in event_socket

thank you all for your answers. As I want to implement it using only java and tcp I think using session heartbeat with a monitoring timer is my best solution.

On Wed, Aug 5, 2015 at 3:21 PM, Regis M <regis.freeswitch.org at tornad.net<mailto:regis.freeswitch.org at tornad.net>> wrote:
As Stanislas said.. in TCP, broken socket is detected by client only if server closes it properly or client is trying to sending something on closed/died server socket.... I think in nodejs, an open connection will wait forever too if not sending anything.

2015-08-05 12:35 GMT+02:00 Danny Gershman <danny.gershman at gmail.com<mailto:danny.gershman at gmail.com>>:
Not sure this is helpful for you, but create a simple TCP socket connection with NodeJS.  When there is a connection failure an immediate callback occurs.

On Wed, Aug 5, 2015 at 6:25 AM Stanislav Sinyagin <ssinyagin at gmail.com<mailto:ssinyagin at gmail.com>> wrote:
it's not Java-specific really.

Imagine you have an open TCP connection that has no traffic, and
somewhere inbetween there's a network failure. You will only know
about it when you start sending the data, and the TCP timeout occurs.
You will get the socket error exception only after all retransmission
attempts failed, and that may take quite some significant time. If
ICMP is allowed in the network, some failures would generate ICMP
messages which will speed up the process, but you can't rely on this.

So, if you need to know about the failure quickly enough, you need to
monitor the server reachability with some connectionless protocol,
like ICMP echo or some UDP-based keepalive.

On Wed, Aug 5, 2015 at 11:14 AM, Michael Jerris <mike at jerris.com<mailto:mike at jerris.com>> wrote:
> are you saying Java provides no way to detect a tcp socket disconnect?
>
>
> On Wednesday, August 5, 2015, Babak Yakhchali <babak.freeswitch at gmail.com<mailto:babak.freeswitch at gmail.com>>
> wrote:
>>
>> but if for example network connection is lost the socket will remain open
>> forever!
>>
>> On Wed, Aug 5, 2015 at 12:04 PM, Michael Jerris <mike at jerris.com<mailto:mike at jerris.com>> wrote:
>>>
>>> I would just detect the socket closing instead of using a heartbeat for
>>> sure
>>>
>>>
>>> On Wednesday, August 5, 2015, Babak Yakhchali
>>> <babak.freeswitch at gmail.com<mailto:babak.freeswitch at gmail.com>> wrote:
>>>>
>>>> Hi
>>>> I'm using pure java sockets (not current available esl implementations)
>>>> with event_socket to control sessions. to detect lan disconnects I'm using
>>>> session_heartbeat events every 1 second (this is adjustable). Considering
>>>> performance is this a bad approach or not ? any better suggestions?
>>>> if I execute enable_heartbeat before answering the call this message is
>>>> printed on console:
>>>> switch_core_session.c:1555 sofia/internal/1000 at 172.16.90.1<mailto:1000 at 172.16.90.1> using
>>>> scheduler due to bypass media or media is not established.
>>>>
>>>> should I answer the session before calling enable_heartbeat?
>>>> thanks
>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/20150805/639f0909/attachment.html 