it's not 100% accurate in the media timeout. It would be too expensive to use actual timers, it uses the number of samples you should be getting from rtp and a number of loops where no media was received. Migrating from svn 13000 range to GIT is a big step and you may have to adjust to some new behaviors. media_timeout may not even have existed that long ago I don't recall. If you don't need media timeouts turn off the param or turn it up to longer. On Tue, Jun 29, 2010 at 1:09 PM, Michael Collins <msc@freeswitch.org> wrote:
Pastebin your dialplan and the lua script for starters. Also, is it the 5300 that is responding with the media timeout? -MC
On Tue, Jun 29, 2010 at 10:15 AM, Dan <freeswitch-users@digitaldan.com>wrote:
Hi guys, I have been running two freeswitch boxes (13754M) that answer calls from a cisco 5300 (both on the same network) and records them to disk with a small lua application. This has been working well for the past few months. I decided to upgrade one of them to trunk ( git-3fbd9e2 2010-06-11 11-08-51 -0500 ) and have run into a problem. Some calls will fail with a MEDIA_TIMEOUT after a few minutes, the time it takes to fail ranges from 4 minutes to 10 minutes, I don't have a full sip trace or pcap dump yet, I reverted back to the old freeswitch version (on the same hardware) and have not been able to reproduce it in a test environment yet ( I continue to try). Below are the relevant lines from the log files for one of the calls:
2010-06-23 07:42:19.033466 [DEBUG] switch_channel.c:2257 (sofia/external/ nobody@192.168.21.4) Callstate Change ACTIVE -> HANGUP 2010-06-23 07:42:19.033466 [NOTICE] mod_sofia.c:884 Hangup sofia/external/ nobody@192.168.21.4 [CS_EXECUTE] [MEDIA_TIMEOUT] 2010-06-23 07:42:19.033466 [DEBUG] switch_channel.c:2273 Send signal sofia/external/nobody@192.168.21.4 [KILL] 2010-06-23 07:42:19.033466 [DEBUG] switch_core_session.c:1023 Send signal sofia/external/nobody@192.168.21.4 [BREAK] 2010-06-23 07:42:19.033466 [DEBUG] switch_core_codec.c:146 sofia/external/ nobody@192.168.21.4 Restore previous codec PCMU:0.
My configuration is bone stock, so the rtp timeout value is at 300, but I have some calls that have lasted only 4 minutes. One other piece of information is that on one of the recordings that was hung up after 4 minutes and 17 seconds the recorded file was only 24 seconds long (it stopped recording after the first 24 seconds) , so I'm assuming freeswitch did not think there were any rtp packets to record.
Any ideas on where to start debugging this? I have setup a new freeswitch box connected to the same 5300 to reproduce, but have not been able to generate the call volume ( there where around 30 calls being recorded) yet, but I'm working on it.
Thanks!
_______________________________________________ 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
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900