<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>tl;dr = If you see WRONG_CALL_STATE messages in your logs, check your FreeSWITCH ip configs and ALSO check your network connectivity<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>I'm reviving this old thread just to provide an additional data point that emphasizes what Anthony advised, but for a different reason.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>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!<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Bote<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Bote Communications<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Fort Lauderdale, FL<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Anthony Minessale<br><b>Sent:</b> Tuesday, 17 December, 2013 22:14<br><br></span><o:p></o:p></p><div><p class=MsoNormal>It<span style='color:black'>'</span>s challenging for auth and the 2nd invite is not reaching it.<o:p></o:p></p><div><p class=MsoNormal>try "sofia global siptrace on" and "sofia loglevel all 9"<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Dec 17, 2013 at 7:13 PM, Moishe Grunstein <<a href="mailto:max@nysolutions.com" target="_blank">max@nysolutions.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal>Do a sip trace<br>sofia global siptrace on<br><br>console loglevel debug<br>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.<br><br><br>Thanks,<br><br>Moishe Grunstein<br>Tornado Computer Systems, Inc.<br><a href="tel:212.400.7650">212.400.7650</a> <a href="http://888.IPPBX.US" target="_blank">888.IPPBX.US</a><br><br><br>-----Original Message-----<br>From: crazygabry<br>Sent: Tuesday, December 17, 2013 7:38 PM<br><br>Hello everybody,<br><br>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:<br><br>sofia/internal/1000@MYDOMAIN:9060 [CS_NEW] [WRONG_CALL_STATE]<br>2013-12-18 00:30:22.714696 [DEBUG] switch_channel.c:3211 Send signal<br><br><o:p></o:p></p></div></div></div></div></div></div></body></html>