Ya know my memory is short for things that I do not run into all the time.
And as always this error would come up on the lists all the time. But I had been away for a couple of years.
So, I finally ran into it myself on one of my virtual systems that I was adding sip and a did to.
So, after looking in /var/log/asterisk/messages and cleaning up errors that were clearly there after a reload, which I would suggest everyone do from time to time and especially when having any error.
Well, I still had the issue and was thinking of recompiling asterisk and dahdi.
But I decided to compare this install which was on a 512mb vps with a working vps @1gb.
So here is what worked for me as I use this in other twisted options in app_rpt for other functions.
rpt.conf
60=autopatchup,context=radio,noct=1,farenddisconnect=1,dialtime=90000,quiet=1
Now your context should already be set for ‘radio’ and you can check your node setup for that declaration to be sure. But putting it in the AP setting makes sure it is there for it anyway, or you may choose a new one.
Be aware that whatever context you choose, you will need dialplan extensions under that context in extensions.conf or use a goto to jump somewhere else from there if needed.
In any case this worked for me. quite=1 and works as intended.
I am guessing that when it is not stated in the command string, then the default is quite=0
A look in the source revealed this…
/* start dialtone if patchquiet is 0. Special patch modes don’t send dial tone */
if ((!myrpt->patchquiet) && (tone_zone_play_tone(genchannel->fds[0],DAHDI_TONE_DIALTONE) < 0))
{
ast_log(LOG_WARNING, “Cannot start dialtone\n”);
ast_hangup(mychannel);
ast_hangup(genchannel);
myrpt->callmode = 0;
pthread_exit(NULL);
Obviously patchquite (var) is referring to internal status’s and I’m not going to search it out past this, for now anyway. It appears there may be other issues effecting this internal var.