Hi Everyone
We have encountered a problem on one of our servers where the local channels created and not optimized out of a call, cause a backlog of RTP (This is likely an Asterisk Issue). This however causes the server to exhibit high load and thus stop responding on SIP.
However we have also recognized that the script tl-ringgroup-base does not optimise the local channels out (And most of the calls exhibiting this backlog, call this script via the extension based huntlist). We were thinking of removing the "/n" when creating the WHOLE_STRING parameter for the local channels to be dialed so that they eventually are optimized out of the calls.
We are very weary about changing the Thirdlane dial plan script, as it is very extensive and complex. Please can someone give us an input on what could be affected negatively (or positively) should we remove the "/n" so that local channels can be optimized out. Also we would like to know of the advantages of having it there as opposed to removing it.
This is rather important as the server hosts a lot of clients and extensions, so we are very limited in terms of testing we can do under high load.
My advice is to not use 'extension based' ring groups. Instead use 'device based' ones. You will have much cleaner dialplan without all the nightmares that arise when you invoke chan_local. The reason for the /n was to avoid a common Dtmf issue that occurred after chan_local optimized itself out of the call. I quit using extension based ring groups so long ago I never even took time to check to see if chan_local is still overwhelmed with bugs and issues. I figured that tiger is never going to change his stripes.