Cannot start dialtone error * FIX *

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.

If I understand everything correctly, then with the above configuration, dialtone, patchup and patchdown announcements will not be available.

What are _

Announcements ?

When an autopatch is activated and when the connection is terminated, app_rpt provides the ability to play the corresponding voice notifications.

You would need to put those playback options in your dialplan.
It’s not a default function of app_rpt (built in)

These are default options.

https://wiki.allstarlink.org/wiki/Rpt.conf

[telemetry]
patchup=rpt/callproceeding
patchdown=rpt/callterminated

I stand corrected.

You should put in for a refund !

Well, I should not have labeled the post as a fix, but a work-around.
Something I have been doing for asterisk/app_rpt to get what I want/need for a long time.

To be honest, I don’t know where things went wrong with that.
I have suppressed messages since the days of acid.
I guess that depends on if your system is used by people and they get tired of needless system talking, or you run a personal station and want to impress your friends.

But I suspect the whole issue of dialtone has something to do with settings when you add a trunk.
Being nat, nat settings, canreinvite etc / some combination ?
Something flags the software wrong/unexpected for the sequence.

But one would think for all those that complain about it, someone would investigate further.
I am happy with a work-around. I likely never noticed because I have been using that patch string for 10+ years for special work-around functions unrelated.
For it is the only way you can enter dtmf in a way to have a true var to evaluate/execute inside of the asterisk/app_rpt/radio channel.

I may experiment with it later to find out what the exact issue is, but I have I have bigger steer to barn for the moment. Some have been waiting many years.

You might ask the devs working on beta2 to investigate/fix for upcoming release ?

This is community sourced software and nobody pays a dime for it. Few work for it. Everyone enjoys it.
I guess it comes down to how important to you it is.
A complaint is not a fix. You didn’t just buy a new car or even a dollar store trinket.

Thanks for this, it fixed my autopatch. Autopatch worked for years and then I noticed the dreaded “cannot start dialtone” issue. Not sure what changed but glad to have the feature back.

73

Kyle
K0KN

I wanted to mention just in case it helps any one else, that on a fresh install of Allstarlink on debian buster, I could not make the autopatch work. I received the unable to start dialtone which led me to figuring the tone zone wasn’t being setup.

After various runs of mashing I ultimately solved the problem with:

  • Making sure /etc/dahdi/system.conf was setup with at least loadzone=us and defaultzone=us
  • Checking out the sources and upgrading to .10 (which j noticed now has an exten= option to the autopatch command!)

With that I now have dialtone and calls get setup nicely :slight_smile:

Thanks for your work on this.
I tested this with my ASL 1.01 test box and did not get the same result.

I am guessing that something else you may have changed.

I will note for others that /etc.dahdi/system.conf is labeled system.conf.sample by default and needs changed (remove .sample) as well as the file permissions for the file.
And with 2.0b6 install the file was non existent. That was a manual install so who knows. I likely started with a earlier version than b6. It’s the only server I do not use for real telephony anyway, so never noticed.

I will take a new stab at it when I have time.
But can you think a little more on what else you may have changed?
Perhaps someone else will test and post result. My setup is wildly unique.

I suspect there was a change in app_rpt.c yes, but I have not walked through the commit history to try to narrow it down. Aside from reverting back to 1.4.23-9 and testing, I’m afraid I can’t offer much more detail as those were the two significant changes on my system.

I am using simpleusb in full duplex mode, single radio - the missing dahdi configuration seemed to be pivotol as I was able to hear dial tone once after installing the configuration and re-starting Asterisk under -9 (but not rebooting the actual debian system). But perhaps it was a fluke. I would still see the call fail to be setup.

It wasn’t until I upgraded to -10 that I could reliably receive tone from the autopatch command.

Here are my configurations:

; rpt.conf

61 = autopatchup,context=pstn-out,noct = 0,farenddisconnect = 1,dialtime=20000,quiet=0 ; Autopatch up
62 = autopatchdn ; Autopatch down
715 = autopatchup,context=nist,noct=1,farenddisconnect=1,dialtime=20000,exten=13034997111

; extensions.conf

[pstn-out]
exten = _1NXXNXXXXXX,1,Set(CALLERID(num)=7783825379)
exten = _1NXXNXXXXXX,n,Set(CALLERID(name)=“VE7IGP Repeater”)
exten = _1NXXNXXXXXX,n,Dial(IAX2/voipms/${EXTEN}, 30, L(1200000, 60000,25000))
exten = _1NXXNXXXXXX,n,Busy
exten =s,1,Playback,ss-noservice
exten =s,2,Hangup

[pstn-in]
exten => _X.,1,Answer
exten => _X.,n,rpt,${NODE}|S
exten => _X.,n,Hangup

[nist]
exten = _1NXXNXXXXXX,1,Set(CALLERID(num)=7783825379)
exten = _1NXXNXXXXXX,n,Set(CALLERID(name)=“VE7IGP Repeater”)
exten = _1NXXNXXXXXX,n,Dial(IAX2/voipms/${EXTEN}, 20, S(121))
exten = _1NXXNXXXXXX,n,Busy
exten =s,1,Playback,ss-noservice
exten =s,2,Hangup

; /etc/dahdi/system.conf

loadzone=us
defaultzone=us

I can use *61 to pick up tone, *611NXXXXXXXXX to dial the number, and *715 will auto dial. This has been reliable for the couple of days I’ve been testing.

Reverse autopatch also works using the configuration above although it was not set to use call parking. For now I am leaving pstn-in disabled until I decide how I want to go about handling incoming calls, if at all.

(the mixed use of = vs. => seems to be present in extensions.conf overall, it doesn’t seem to have an affect?)

Thanks for the additional info,
Just so I might narrow a few things down,
Could you also say if you also have sip phones configured in your system ?

I had the sip module loaded but was not using it. I just now did three tests with SIP using a local SIP device:

Auto patch out using:

exten = _1NXXNXXXXXX,n,Dial(SIP/voipms/${EXTEN}, 20, S(121))
worked fine.

Reverse auto patch from SIP client to the node failed

exten=> 580910,1,rpt(${NODE})

– Executing [580910@sip-phones:1] Rpt(“SIP/210-d409edd0”, “580910”) in new stack
[Jan 31 18:18:54] WARNING[9921]: app_rpt.c:23079 rpt_exec: We only accept links via IAX2, Echolink, TheLinkBox or Local!!
== Spawn extension (sip-phones, 580910, 1) exited non-zero on ‘SIP/210-d409edd0’

And auto patch to the SIP client using *61210

exten = 210,1,Dial(SIP/210);

audio worked fine in both directions.

For this issue, I can only guess that the above is not in the same dialing context ?
The default context is radio and you might just want to copy that string to the context of your sip phones.
Or, You might have to watch asterisk live to see the exact error.

So, I am really concerned mostly about dialtone, for this has been a hanging issue for a few years.
It does not really effect me adversely, I use patch quite on my dials, but I thought I might be able to get to the bottom of it for future releases.

I appreciate your notes.
Just have not had much time this winter as I normally do.

So, one more question.
What parameters are you using in your sip conf ‘general’ if any outside of bindport and bind address ie

alwaysauthreject=yes
allowguest=no
callwaiting = yes
threewaycalling = yes
callwaitingcallerid = yes
transfer = yes
canpark = yes
cancallforward = yes
callreturn = yes

And I lied… second question…
To you have your sip network NAT’d in config
externip =
localnet=

Just trying to lay some baseline when I test further.

For this issue, I can only guess that the above is not in the same dialing context ?

It was in my ‘sip-phones’ context. I assume from the warning from Asterisk that RPT() didn’t like it being from an incoming SIP call. That seems odd to me. Not really on my radar right now but when I am back working on this I’ll dig through that more.

The rest of my SIP settings are pretty stock - I am not really using SIP here, just tested it for this thread.

Nothing for externip or localnet.

[general]
context = pstn-in
allowoverlap = no
bindport = 5060

bindaddr=0.0.0.0

[voipms]
canreinvite=no
context=pstn-in
host=something.voip.ms ;(one of our multiple servers, you can choose the one closer to your location)
secret=xyzzy
type=peer
username=myusername
disallow=all
allow=ulaw
fromuser=myusername
trustrpid=yes
sendrpid=yes
insecure=invite
nat=yes

@Yokshs
Could you say where this stopped working for you ?
Did you use the version labeled as ‘DIAL’ ? Would that be where it dropped off ?

This should work as there is never a call in the code for dialtone. The extension is provided on the command string.

I hope that everyone remembers just what a dialtone is…
http://kttycat.com/DialTone.mp3

This will not work as the code will call for dialtone after the recognized patch command and will generate an error - “can not start dialtone”

If you were to use patchquite=1 option, it should work as long as everything else in your setup is right.