We are getting, since Saturday, a ton of flakiness in our Asterisk/TL MTE installation. Calls crossed within extensions on a given tenant, tons of channels list in 'core show channels' that are bridged to none and cannot be killed without restarting Asterisk, and more. The problems started with 1.6.0.15 installed - recompiled and installed - same issued. Upgraded it to 1.6.2.16.2 and still - no resolution. Any one see such behavior and have any suggestions?
We did open a support issue with Digium under a support contract and one of the things they noted so far was:
"Another thing I noticed is a heavy use of local channels. It looks like very few of those channels use the '/n' at the end to make the channel stay alive. I recommend going through dialplan and ensuring that all your local channels are using the '/n' to keep it alive unless there is a very specific purpose for it not staying alive. If the local channel is passing audio at all or being bridged to another call, then it should stay alive."
Looking through the dialplan configs, it would appear to be correct - very few have the /n. Since one of our issues is open channels that won't close, I don't know that this would be the source of the troubles - seems the opposite. But would be interest in what you (Alex) think....and/or anyone else....
Chris
AxisInternet, Inc.
local channels
I agree with Erik. Unfortunately there is no way to completely eliminate local channels without major change to the dialplan, but there are places (which Erik noted) where you can avoid using Local channel without major sacrifice in functionality.
a better advise is DONT USE CHAN_LOCAL! if you go through digium changelogs for every version of asterisk you'll see it accounts for 20% of all bug fixes for the last several years. My advise is to stop using 'extension based ring groups' in your huntlists and replace them with 'device based ring groups'. In your IVR's stop using Dial number as an option and replace it with a custom command using Goto. This will put a good dent into your dialplan. Using /n might keep chan_local in the middle of the call but do you really want that? Chan_local can be attributed to 5 separate problems with DTMF.
Additionally if you use /n you dont let chan_local back out of the call and re-connect the two endpoints. This means that the far-end jitter buffers will not work the way they are supposed to. This also means the call has no chance of reducing itself to Packet2Packet transfers which essentially means you're going to be shelling out MTE licensing 13times more frequently for new servers than on a server that has a very high rate of Packet2Packet transfer calls.