On Fri, 2010-02-26 at 11:20 +0100, Ola Samuelson wrote: > Hi all! > I have an installation which works most of the time... sigh... > In fact it works prefectly for weeks then... > Latest 4.0.4 on centos 5.3 from iso. > > This morning no calls in/out could be made.
But extension-to-extension calls within the system worked? What about calls from an extension to local services like the auto-attendant? > I looked at the ITSP side and all accounts are registered and not > expired. To debug this, you'll need to trace the message flow and see what's going wrong. See: http://wiki.sipfoundry.org/display/xecsuserV4r0/Display+SIP+message+flow+using+Sipviewer when you get the trace data, take a look at it using sipviewer and/or post the trace with a description of your configuration (identify components by IP address), what you were doing, and which call in the trace you're talking about (by call-id or frame number in the trace, preferably). If you can identify an attempted call that took place while you were experiencing the problem, it should be in that snapshot, and you could use sipx-trace to get it out of the logs. > You could still surf using the same internet line. > > Just restarted all sipxpbx services using web gui....it all works. > > So...my assumptions are: > - Hardware and internet is ok > - Error in sipx > > I think the proper Benny Hill quote here is: "Never assume boy, you > make an ass out of you and me...." > (Or who said that?) I first saw it on an episode of "The Odd Couple", but it may have been old before then... > I took a snapshot and selected a few pieces from the logs where it > says something that looks "not good". > I am wondering if you could see something that looks fishy....i can of > course supply the full trace. > > - Found some "err" in logs > - Found some "loop" - what? How can i fix it? A loop usually means that you've got your system configured such that there is more than one way to address a message to it, but the system doesn't recognize all of them. When you use one it does not accept as 'itself', then it tries to forward it, which sends it back to itself, etc. Usually, these get cut off fairly quickly and do no harm (except that whatever the request was trying to do does not work), but in extreme cases they can cause overloads by filling message queues. The instance you quoted below looked like a REGISTER request that was trying to register using an IP address of the system instead of the domain name. I'm guessing the IP address was the public address of the system, which it does not recognize as itself? Hard to tell from what you quoted. Use domain names. > More questions: > - Could using accented characters in identities and such a problem? There is a problem with some UTF-8 encoded display names (XX-7460) when they go through sipXbridge, but I think that's cosmetic, and not likely related to your main problem. > - I have 9 gateways but i am really only using 4 right now. Problem > with many gateways? No. > \n====================END====================" > "2010-02-26T00:33:29.497219Z":1502561:SIP:ERR:sip.flyglinjen.se:SipClientTcp-13945:B3CF9B90:SipXProxy:"SipClientWriteBuffer[SipClientTcp-13945]::insertMessage > mWriteBuffer has 101 entries, exceeding the limit of 100" > "2010-02-26T00:33:29.498623Z":1502562:OUTGOING:INFO:sip.flyglinjen.se:SipUserAgent-2:B6EC0B90:SipXProxy:"SipUserAgent::sendTcp > TCP SIP User Agent sent message:\n----Remote Host:192.168.1.254---- Port: > 41902----\nSIP/2.0 408 Request timeout\r\nFrom: > \"141\"<sip:[email protected]>; tag=3134310133323035373734343237\r\nTo: > \"141\"<sip:[email protected]>;tag=98c5342c\r\nCall-Id: 3220698761\r\nCseq: > 1 REGISTER\r\nVia: SIP/2.0/TCP > 192.168.1.25;branch=z9hG4bK-sipXecs-468a17514600fef835c5409e5846d47ac7dd;received=192.168.1.254;rport=41902\r\nVia: > SIP/2.0/TCP > 192.168.1.25;branch=z9hG4bK-sipXecs-3f679929c423ba88dac0fb8bc326c192cd51;received=192.168.1.254;rport=41902\r\nVia: > SIP/2.0/TCP > 192.168.1.25;branch=z9hG4bK-sipXecs-3b15f1d1529b48baa01c5f319e2b597a5469;received=192.168.1.254;rport=41895\r\nVia: > SIP/2.0/UDP > 192.168.1.25;branch=z9hG4bK-sipXecs-35070acd5c9af7d24353ddbdcb915883b758;received=192.168.1.254;rport=5060\r\nVia: > SIP/2.0/TCP 192.168.1.25;branch=z9hG4bK-sipXecs-2b1af735967 9c238cb07f91e7af9f56bdc98;received=192.168.1.254;rport=47212\r\nVia: SIP/2.0/UDP 192.168.1.25;branch=z9hG4bK-sipXecs-144985028e5033f75f91a40f6db188e8e4ea;received=192.168.1.254;rport=5060\r\nVia: SIP/2.0/TCP 192.168.1.25;branch=z9hG4bK-sipXecs-ff1e3f27d715e672eb3cc1642301c9c736ea;received=192.168.1.254;rport=47212\r\nVia: SIP/2.0/TCP 192.168.1.25;branch=z9hG4bK-sipXecs-f11f16b734539c2d0f5ec676e3ad3c8d597f;received=192.168.1.254;rport=47212\r\nVia: SIP/2.0/UDP 192.168.1.25;branch=z9hG4bK-sipXecs-ee7fb7e4821c39a7e7aabdca17882b8cbacc;received=192.168.1.254;rport=5060\r\nVia: SIP/2.0/UDP 127.0.1.1:5109;branch=z9hG4bK-1740403486;rport=5109;received=173.204.53.138\r\nServer: sipXecs/4.0.4 sipXecs/sipXproxy (Linux)\r\nContent-Length: 0\r\n\r\n--------------------END--------------------" > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
