[Freeswitch-users] Dead channels in freeswitch

[S. Scott]

If you're sure it's not the end points, than is traffic is passing thru a
stateful firewall (either direction/either side) where the SFW's UDP state
timers may be too fast.

/S

—————
iThing:  Big thumbs & little keys. Please excuse typo, spelling and grammar
errors • Thought of the Day – "With all this manure, there must be a pony
in here somewhere.”

On 2013-05-03, at 2:17, Farrukh Ali <smfarrukh at live.com> wrote:

 Yes BDF, you are right, but I have been using Asterisk for a while and
never faced such problem, there has to be some mechanism Freeswitch is
lagging, beside this Freeswitch is quiet flexible to use due to its unique
XML configuration style,
And thanks for response

Regards
Muhammad Farrukh

------------------------------
Date: Thu, 2 May 2013 08:51:42 -0400
From: bdfoster at davri.com
To: freeswitch-users at lists.freeswitch.org
Subject: Re: [Freeswitch-users] Dead channels in freeswitch

Just a note:

In your setup, a timeout if some sort is your only option. It may not be
efficient, it may not be perfect, but neither are your WiFi/Mobile clients
apparently.

-BDF
On May 2, 2013 7:09 AM, "Farrukh Ali" <smfarrukh at live.com> wrote:

Thanks everyone, and Steve timers might not be efficient solution but for
now it will be good for testing purpose, could you please tell me exactly
which file and parameter should I look for to change, is this configuration
located in sofia.conf.xml ? kindly reply!
and thanks to all again!

Regards,
Muhammad Farrukh

------------------------------
From: steveayre at gmail.com
Date: Tue, 30 Apr 2013 17:20:36 +0100
To: freeswitch-users at lists.freeswitch.org
Subject: Re: [Freeswitch-users] Dead channels in freeswitch

SIP over UDP has no way of knowing the other side has lost connectivity (eg
wifi down). Sip droid will know the local network is down and be able to
hang up the call because of that. FreeSWITCH has no such knowledge, so
won't know the call is hung up and will continue sending RTP.

3 possibilities are:
1) Use session timers
2) There is a parameter to hang up a call is no RTP has been received for a
certain period of time
3) Use SIP/TCP, keepalives might help (but the default is measured in hours)

Note that all of these are timeouts - you simply won't be able to know the
call has ended immediately.

Steve



On 30 Apr 2013, at 08:33, Farrukh Ali <smfarrukh at live.com> wrote:

Hi,

I need some help, there is an issue in Freeswitch with SIP clients, when a
call is not hung up properly Freeswitch does not close its RTP channels,
and it starts to get load on bandwidth after too many dead channels are
generated, Improper hang up means if during call sip client went out of the
range of WiFi, the client i.e SipDroid shows call hang up but freeswitch
continues to send voice packets. Kindly reply

_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting at freeswitch.org
http://www.freeswitchsolutions.com




Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
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
http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel
Communication Server  Official FreeSWITCH Sites
http://www.freeswitch.org http://wiki.freeswitch.org
http://www.cluecon.comFreeSWITCH-users mailing list
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
http://www.freeswitchsolutions.com




Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
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
http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel
Communication Server  Official FreeSWITCH Sites
http://www.freeswitch.org http://wiki.freeswitch.org
http://www.cluecon.comFreeSWITCH-users mailing list
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
http://www.freeswitchsolutions.com




Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
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/20130503/78e5f1bd/attachment-0001.html