Thanks for your prompt reply. See below. 2010-02-26 13:19, Scott Lawrence skrev: > 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? > > no, no calls at all worked. >> 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 > > Thanks, should i do this even if no calls went through? > 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). >> >> - 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. > >
I see now that there was a register attempt coming from the wan. We have no remote devices so i will close that hole in the firewall. We use domain names but only locally. ie the complete setup resides on a lan with local dns providing resolution for the domain and forwarding other queries. Is my problem one that typically could be the effect of using ip:s instead of dns 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:1...@222.66.239.126>; tag=3134310133323035373734343237\r\nTo: >> \"141\"<sip:1...@222.66.239.126>;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-2b1af73596 79c238cb07f91e7af9f56bdc98;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 sipx-users@list.sipfoundry.org 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/
