Ok… This has got to be the most crzay ass problem i have come across.
Most of that have helped me out in previous threads with my Lazy Channel problem, would know that this problem has been ongoing. However of late we have thought to take a gamble and hack away at the Asterisk Source code to try and get down to the crux of the problem. Since doing this unorthodox Debugging method we have since found out what the problem is, but are unable to work out what is causing it or how to resolve the problem, so once again, here i am seeking assistance from those of you who are in the know.
Below is the Debugging message that comes up on the CLI after we altered the code so that Asterisk would tell us what is going on (Before it would give us limited information), as you can see Asterisk is saying that the channel is currently on a call, however it isn’t, when i do the Zap Show Channel X/XX/XXX (X being the channel Number) it states that it is on-hook, which tells me that the channel is free.
What we cant work out is why Asterisk is doing this, what is telling that the channel is on a call when it is clearly not. The problem i have is that this issue is causing no end in grief for us, i now have to run a script that restarts Asterisk every 3-4 hours or i do it manually which ever comes first, this is so we can get utilization of our channels again (If for short period of time at best), but this is not practical as it runs the risk of loosing CDR records, and also causing more problems internally of Asterisk to keep doing that many restarts on an ongoing basis.
Mar 12 21:06:54 NOTICE[16502]: chan_zap.c:7330 available: Channel 124 is still in a call
Mar 12 21:06:54 NOTICE[16502]: chan_zap.c:7689 zt_request: Channel 124 is NOT available
Mar 12 21:06:54 NOTICE[16502]: chan_zap.c:7330 available: Channel 123 is still in a call
Mar 12 21:06:54 NOTICE[16502]: chan_zap.c:7689 zt_request: Channel 123 is NOT available
Mar 12 21:06:54 NOTICE[16502]: chan_zap.c:7330 available: Channel 121 is still in a call
Mar 12 21:06:54 NOTICE[16502]: chan_zap.c:7689 zt_request: Channel 121 is NOT available
Mar 12 21:06:54 NOTICE[16502]: chan_zap.c:7330 available: Channel 120 is still in a call
Mar 12 21:06:54 NOTICE[16502]: chan_zap.c:7689 zt_request: Channel 120 is NOT available
Mar 12 21:06:54 NOTICE[16502]: chan_zap.c:7330 available: Channel 119 is still in a call
Mar 12 21:06:54 NOTICE[16502]: chan_zap.c:7689 zt_request: Channel 119 is NOT available
Mar 12 21:06:54 NOTICE[16502]: chan_zap.c:7330 available: Channel 118 is still in a call
Mar 12 21:06:54 NOTICE[16502]: chan_zap.c:7689 zt_request: Channel 118 is NOT available
Mar 12 21:06:54 NOTICE[16502]: chan_zap.c:7613 zt_request: Channel 116 is available
How the system works is:
We have 200 DID numbers, this is handled by the Extensions.Conf file, and is from there referenced to any number of the AGI Scripts that await for it to be spawned. We have Includes.Lib working as well but we cant find any problems in there at all either, or for any reason that includes.lib would tell Asterisk that the Channel is still on a call (We cant see how it would anyway), we have checked out code to make sure the calls are being hung up properly and have also made sure that it is configured right in extensions.conf as well.
Any ideas or suggestions on this matter would be greatly appreciated.
I know a problem had been fixed in libpri where it would report a channel in use when it really wasn’t back in January. Not sure if it’s the same issue though. So the question is, are you running the latest release of libpri?
Tonight i am going to Remove Asterisk tottaly from the system, Remove Zaptel as well, and also Remove Libpri and redo everything from scratch.
Out of all the installs i have done using either Digium or Sangoma cards, this is the first i have seen of this problem. I suspect that my whole installation is corrupt somewhere and i need to remove that corruption, that has to be the only answer, i have been working on this for months now with no resolve to the problem.
I tell you, there are days where hitting a brick wall head on seems more appealing then being confronted with this problem, it is insanely nightmarish.
One other quick question thought, if i migrate to Asterisk 1.4.1 from 1.2.X what would i have to change in our Includes.Lib and out AGI scripts? is there significant changes in the way these things are handled?
Best practice would be not to troubleshoot and migrate at the same time, especially not on a production system. Yes there are lots of differences but that’s not the main headache.
I wont be migrating on the live system for a while, not untill i have the Dev system completed and is ready to take on the role of going live.
However i will have to do a full re-install though to make sure there are no module conflicts or even version conflicts in the system. This is the only way i think i can really begin to do a proper troubleshoot of the problem i suspect.
Ok. The non clearing of ISDN channels has to looked at from the ISDN to start with. IE use pri debug and confirm that the messaging is correct in both directions. IE even if you tell the exchange that you have cleared, Your channel wont clear till theyconfirm it back to you.
Basicly you need to run pri debug intence for a while then go through it.
Also instead of restarting asterisk would just reloading zap be better.?
Ok. The non clearing of ISDN channels has to looked at from the ISDN to start with. IE use pri debug and confirm that the messaging is correct in both directions. IE even if you tell the exchange that you have cleared, Your channel wont clear till theyconfirm it back to you.[/quote]
This has already been done, been working on this directly with Sangoma’s engineers directly trying to get to the source of the problem. the Pri Debugging has come back clean.
This has also been done, and it has come back clean as well, the messages are in syn with each other, and working as they should be.
In what regards do you mean reloading Zap sorry?
Restarting Asterisk so far has been the only way to get those channels back, we cant even destroy the channels as it says that the channel is not even in use, but yet Asterisk when it looks at the channel says “Sorry its on a call” but when you inspect the channel it says that on, it clearly is not. The problem is somewhere high up in Asterisk, finding it is the biggest problem and challenge.
I see what your saying Ian, but i have been doing that now for the last 2 months, debugging time is over for me, i have to look at taking alternative action i guess, i just don’t know how much debugging a person can do before they start going to bed counting binaries
