using enable_heartbeat to detect network problems in event_socket
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@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
I would just detect the socket closing instead of using a heartbeat for sure On Wednesday, August 5, 2015, Babak Yakhchali <babak.freeswitch@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@172.16.90.1 <javascript:_e(%7B%7D,'cvml','1000@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
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@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@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@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@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
if you're concerned about FreeSWITCH performance, you can monitor the general network connectivity with ping tests, or some other cheap heartbeat protocol, and use ESL heartbeat at a lower rate. But in general, once per second doesn't seem to be dangerous for anything. On Wed, Aug 5, 2015 at 9:39 AM, Babak Yakhchali <babak.freeswitch@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@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@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@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@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
_________________________________________________________________________ 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
are you saying Java provides no way to detect a tcp socket disconnect? On Wednesday, August 5, 2015, Babak Yakhchali <babak.freeswitch@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@jerris.com <javascript:_e(%7B%7D,'cvml','mike@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@gmail.com <javascript:_e(%7B%7D,'cvml','babak.freeswitch@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@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@freeswitch.org <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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
no. if socket is closed, an exception is thrown and you can catch it and handle it. but if for example your connection is lost, socket will be open till keep alive timer expires. this keep alive is os based and you can not set it for every socket (may be I'm wrong about this part). On Wed, Aug 5, 2015 at 1:44 PM, Michael Jerris <mike@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@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@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@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@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@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
_________________________________________________________________________ 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
http://stackoverflow.com/questions/1480236/does-a-tcp-socket-connection-have... On Wed, Aug 5, 2015 at 1:50 PM, Babak Yakhchali <babak.freeswitch@gmail.com> wrote:
no. if socket is closed, an exception is thrown and you can catch it and handle it. but if for example your connection is lost, socket will be open till keep alive timer expires. this keep alive is os based and you can not set it for every socket (may be I'm wrong about this part).
On Wed, Aug 5, 2015 at 1:44 PM, Michael Jerris <mike@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@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@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@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@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@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
_________________________________________________________________________ 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
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@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@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@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@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@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@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
_________________________________________________________________________ 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
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@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@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@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@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@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@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@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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
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@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@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@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@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@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@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@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@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
_________________________________________________________________________
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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
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@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@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@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@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@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@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@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@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@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
_________________________________________________________________________
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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
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@lists.freeswitch.org<mailto:freeswitch-users-bounces@lists.freeswitch.org>> on behalf of Babak Yakhchali <babak.freeswitch@gmail.com<mailto:babak.freeswitch@gmail.com>> Reply-To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org<mailto:freeswitch-users@lists.freeswitch.org>> Date: Wednesday, August 5, 2015 at 6:54 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org<mailto:freeswitch-users@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@tornad.net<mailto:regis.freeswitch.org@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@gmail.com<mailto:danny.gershman@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@gmail.com<mailto:ssinyagin@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@jerris.com<mailto:mike@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@gmail.com<mailto:babak.freeswitch@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@jerris.com<mailto:mike@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@gmail.com<mailto:babak.freeswitch@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@172.16.90.1<mailto:1000@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@freeswitch.org<mailto: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<mailto: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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto: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<mailto: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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto: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<mailto: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 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto: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<mailto: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 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org<mailto: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<mailto: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
I strongly agree with that. java-esl helps a lot.
On Aug 5, 2015, at 9:25 AM, Hector Geraldino <Hector.Geraldino@ipsoft.com> wrote:
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@lists.freeswitch.org <mailto:freeswitch-users-bounces@lists.freeswitch.org>> on behalf of Babak Yakhchali <babak.freeswitch@gmail.com <mailto:babak.freeswitch@gmail.com>> Reply-To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Date: Wednesday, August 5, 2015 at 6:54 AM To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org <mailto:freeswitch-users@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@tornad.net <mailto:regis.freeswitch.org@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@gmail.com <mailto:danny.gershman@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@gmail.com <mailto:ssinyagin@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@jerris.com <mailto:mike@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@gmail.com <mailto:babak.freeswitch@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@jerris.com <mailto:mike@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@gmail.com <mailto:babak.freeswitch@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@172.16.90.1 <mailto:1000@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@freeswitch.org <mailto:consulting@freeswitch.org> > http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/> > > Official FreeSWITCH Sites > http://www.freeswitch.org <http://www.freeswitch.org/> > http://confluence.freeswitch.org <http://confluence.freeswitch.org/> > http://www.cluecon.com <http://www.cluecon.com/> > > FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> > http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/>
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/>
_________________________________________________________________________ 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
participants (7)
-
Babak Yakhchali
-
Danny Gershman
-
Hector Geraldino
-
Michael Jerris
-
Regis M
-
servtelar
-
Stanislav Sinyagin