Your description of cascading network failure sounds suspiciously like STP. On Mar 13, 2014, at 12:35 PM, Bote Man <bote_radio@botecomm.com> wrote:
tl;dr = If you see WRONG_CALL_STATE messages in your logs, check your FreeSWITCH ip configs and ALSO check your network connectivity
I'm reviving this old thread just to provide an additional data point that emphasizes what Anthony advised, but for a different reason.
Yesterday I finally solved a long-standing problem with a very low use FreeSWITCH installation that was exhibiting just plain weird behavior. This installation is totally internal, extensions only, no PSTN connectivity, nothing is sent outside of the campus. It's all "just us chickens". The voice VLAN is distributed across the large campus over 3 or 4 Cisco switches.
Calls would randomly take 5-15 seconds to setup, then if they did ultimately connect there might not be audio on answer for a few to as many as 15 seconds, sometimes no audio at all for the entire duration of the call. During one test call I made and then hung up, the target extension continued ringing for 30 seconds! Weird.
I also noted the WRONG_CALL_STATE message in the logs at the time that matched the reported failures. Anthony's note put me on the right track to solving it because we discovered that the sprawling VLAN was just randomly losing connectivity in a rotating fashion to the various extensions. There was even one baffling case during our tests when pings to an extension timed out, but a call to that very same extension completed!
When we moved everything over to home on the same Ethernet switch and off the suspect network, VOILA! everything worked smoothly as expected with no more WRONG_CALL_STATE messages. Now that the extensions could respond to the authentication challenge and not have their responses get lost in the ether, everything works.
Bote Bote Communications Fort Lauderdale, FL
From: Anthony Minessale Sent: Tuesday, 17 December, 2013 22:14
It's challenging for auth and the 2nd invite is not reaching it. try "sofia global siptrace on" and "sofia loglevel all 9"
On Tue, Dec 17, 2013 at 7:13 PM, Moishe Grunstein <max@nysolutions.com> wrote: Do a sip trace sofia global siptrace on
console loglevel debug also check the sip-ip rtp-ip settings on your Sofia profiles. They may be using a variable such as local_ip4, with a wrong ip.
Thanks,
Moishe Grunstein Tornado Computer Systems, Inc. 212.400.7650 888.IPPBX.US
-----Original Message----- From: crazygabry Sent: Tuesday, December 17, 2013 7:38 PM
Hello everybody,
i cannot figure out this problem.. i have a multi tenant freeswitch installation. with every domain i can register users but when i try to make any call i get this behaviour:
sofia/internal/1000@MYDOMAIN:9060 [CS_NEW] [WRONG_CALL_STATE] 2013-12-18 00:30:22.714696 [DEBUG] switch_channel.c:3211 Send signal
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.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