All of my installation are based on ISO. All. I've never seen these issues you are seeing. Although that might help your situation, it seems it is because it is replacing something that is broken with a new known working component.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, July 06, 2010 1:47 PM To: sipx-users Subject: Re: [sipx-users] Random Dropped Registrations > 1) Set your logging level to INFO (or DEBUG if you like that better). That's where they are at. > 2) Wait for the problem to be manifest, that is, a phone is first seen > and then later not seen on the Active Registrations screen without any > explanation. We've done this. > 3) Take a snapshot using the Diagnostics -> Snapshot screen. Request > the time period to be covered by the captured logs to be the present > back to about 3 hours ago. That should be enough time to capture the > genesis of the problem. I have snapshots from when this happens. > 6) Do "merge-logs --ft=[extension] --include-method=register", where > [extension] is the extension of the phone in question. This extracts > the REGISTER requests and their responses which have From or To fields > containing [extension]. The tools which were suggested to me are both where I'm stuck at this time. The merge-logs command and the regtimes command don't exit on the ISO so I've gotten sidetracked in resolving those issues. This has lead to other problems while the problem continues. There is nothing special about my install, nothing modified, it's just a standard ISO install with my name/IP. At this point, I need to move on. Someone suggested that I give an RPM install a try, which might be closer to what most on the list are using and so I am in the process of doing this. I badly need to get the phones working because calls are going missed. I'm hoping this install will fix the problem. Then I can get back to this machine to find out what the heck has been going on. Does that sound reasonable? > 7) Do "sipviewer merged.xml &" to run sipviewer and display the > filtered log information. > > 8) Stare at the sipviewer screen to see what's going wrong. What you > should see is REGISTER requests going from the phone to the proxy to > the registrar, and responses going back. The requests will come in > pairs, the first one gets a 401/407 response, the second gets a 200 > response. Then there will be a gap of several minutes, then the next > pair, etc. With the default settings, the times at the left are in > local time, so you should look around the time when the phone was > unexpectedly not registered. (You can change the times to UTC from > the pulldown menus.) Each 200 response contains a header "Expires: > [number]", where [number] is the number of seconds into the fiture > that the registration has been extended until. The next successful > REGISTER should complete within that number of seconds of each successful REGISTER. > > Admittedly, one of these steps might fail. If so, please copy down > the details of the failure, and we will (have to) solve that problem first. > (See http://www.urbandictionary.com/define.php?term=yak+shaving) > > Dale _______________________________________________ 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/
