Hi, I had some problems with sip peers losing connection suddenly without real network issues. In my case, it was useful to refresh the table used for real time configuration, we made an script for Postgres like this
PGUSER=user PGPASSWORD=password vacuumdb --full --table 'sip_buddies' asterisk_db Greetings, Elder D. Arohuanca On Fri, Nov 20, 2009 at 6:33 PM, Edwin Lam <edwin....@officegeneral.com>wrote: > Paul Scott wrote: > > How is your network structured? > > we have a central location where the * server is located. and 4 remote > locations connected via point to point lines. > > > Can you show me a sample entry from your sip.conf? > > we use realtime sip w/ mysql tables. a typical entry would looks > like this: > > [1234] > context=default10 > type=friend > secret=xyz > qualify=yes > host=dynamic > canreinvite=no > dtmfmode=rfc2833 > disallow=all > allow=g729 > allow=alaw > allow=ulaw > > > I was having this problem. But as far as I could tell there wasn't > > one. From a network stand point all phones were reachable asterisk > > was just reporting that it was Unreachable and it wasn't sending the > > calls. I switched to qualify=no and wrote a small agi to catch $ > > {HANGUPCAUSE} and log it to a file. If it records a bunch of > > chanunavail messages you still have a problem. > > > > If you don't want to turn qualify off you could play with the qualify > > times. I did a bunch of this before I just gave up. > > > > I'm sure there is a better or proper way of handling this. I'm > > interested to hear it. > > > > Paul > > > > > > > > On Nov 20, 2009, at 3:41 PM, Edwin Lam wrote: > > > >> hi folks. > >> > >> we've experienced some weird problems lately. we have about 600 > >> SIP phone on a single system running *1.4.26.2 for about a month. > >> recently there was massive UNREACHABLE messages like this one > >> showed up: > >> > >> chan_sip.c: Peer '2699' is now UNREACHABLE! Last qualify: 1252 > >> > >> then they all became reachable again in a few seconds. sometimes > >> it last for couple minutes. but sometimes it last for hours, when > >> that happens. the system will get very slow and eventually error > >> like this will start showing: > >> > >> channel.c: Exceptionally long voice queue length queuing to IAX2/ > >> hostpbx2-12619 > >> > >> after a while the whole system will become unresponsive > >> until i kill the asterisk process. > >> > >> i've checked our network switches/routers and connections. > >> they all work fine without any packet lost. > >> > >> any suggestions? > > > -- > Edwin Lam <edwin....@officegeneral.com> > Systems Engineer, Office General, Inc. > Ph: +1 415 439 4988 Fax: +1 415 283 3370 > http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0xD6506D20 > > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users