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