> On December 29, 2004 22:35 pm, Andrew Kohlsmith wrote: > > > Well it is hard to go back to a specific configuration since I have > > used the system to test the rpm packages I compile. > > Yikes.
Yep. But there is only one way to "know for sure" that a new package is working. I have had much success in 2004. So much that I figured all the warnings on the list to "not upgrade a working system" were for the ultra paranoid. Still think that is mostly true. > > Nothing like using a production server for testing, eh? I have > > reverted to a (actually several) pre 1.0 release that worked well, > > changed the port, moved the PCI slot, changed out the motherboard > > three times, enabled and disabled onboard devices, tried several > > kernels, rerun the cabling from the smart jack, checked the > > powersupply voltages, UPS, power cabling, etc etc etc. Basic > > troubleshooting? yeah man. > > That wasn't meant to be flip -- Perhaps I've just been bitten too many > times myself by doing the exact same thing you just did -- I back up my > config (going as far as to rsync or image the partition if I need) > before changing something like that on a production system... especially > something as important as our main telephone system. :-) Understood. I want to believe that each day will only bring improvements to the code. Sure, I know that bugs can slip in to the updates but that should be temporary if it happens at all... right? hahahahaha! Perhaps my doctor is right and I am crazy. > > I dont have a T100P lying around so I cant do much in the way of > > changing the interface. Yet. Before I commit to changing that I want > > to rule out any other possibilities... How can one determine without a > > shadow of a doubt that it is the card or otherwise? I have enabled all > > the debugging I can find BUT the output is foriegn to me... <shrug> > > Yeah -- I don't know -- I am the last to blame hardware (10 years as an > embedded electronics designer does that to you) but failing everything > else it really does seem that this is the issue, does it not? Yes it does, but I still want to think it is me. After all, I have spent more time compiling RPMS than I have learning the dialplan. With that said my production dialplan is the most basic you can get. I have an alternate, more complicated dialplan that I am developing but I only switch that in for brief periods testing during low traffic hours. My plan is to move the complicated part of the dialplan to a secondary server that will handle the the real work - VoIP calls, AVR, Voicemail, etc. over TDMoE or IAX2... still thinking that one out. > Something else I learned the hard way -- have any criticial hardware > available onhand, not at a distributor, even if they can ship overnight > -- I have a story about a DS3 MUX that had both controllers die and the > manufacturer shipped one overnight but UPS lost it... true story. > It's expensive to have hardware sitting on the shelf idle but better > that than be without phone service or whatever other critical system > you've got. :-) yep I need another T400p, a spare engine for my truck and not one, but two legal age females on hand in case my wife gets the flu, or worse. Of course I have a 7206VXR here sitting on a shelf with a lot of pretty cards stuffed in it just waiting for a chance to prove itself... but thats a different story altogether. > > Is there a way to log all communication on the D Channel? Have I > > missed some critical debugging reference? I'm going crosseyed looking, > > tweaking and trying the same things over again. > > pri debug span 1 will show you all q.931 traffic and intense will show > you the q.921 traffic too, but this seems deeper than that -- I am not a > telco expert but it certainly seems like something very low level is > buggered. I am sorry I can't be more help. Well you tried and I commend you for that. I wouldn't even be asking here if I had even the slightest clue on what to do next. Perhaps Digium will come through with some testing tomorow / err / I mean today. I have to do whatever it takes to regain 99.999% reliability for my dial-up customers. I would like to accomplish this with Asterisk, as a proof of concept if for nothing else, but I will be forced to pull it out of the chain if a resolution can't be found in the next couple days. This has gone on toooo long and I am looking bad. oops. Gotta get some sleep. Thanks for you comments! Regards, -- Andrew McRory - President/CTO Linux Systems Engineers, Inc. - http://www.linuxsys.com Located in beautiful Tallahassee, Florida Office 850-224-5737 Office 850-575-7213 Mobile 850-294-7567 _______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
