Cannot start dialtone on DAHDI channel (again)

I am setting up the autopatch on V2.0.0 beta 6, and the infamous ‘cannot start dialtone’ error message is raising its ugly head again. Previous work-arounds suggest to use ‘quiet=1’, which avoids the problem by silencing the dial tone, however this is not a fix. In looking through the code I discovered that a routine called ‘tone_zone_play_tone’ is failing, which uses the first entry in the file descriptors (fds field in ast_channel struct) to play it, and this entry is always null. A ‘dahdi show status’ at the console shows an ‘unconfigured’ alarm as well. So, obviously the root cause of the error is a missing configuration file somewhere. I have looked through the code but cannot find where and how this is done, there appears to be mostly comments in chan_dahdi.conf, and nothing about dialtones. The inclusions file is setup correctly. Can anyone shed any light on this?

I assume you have read this post but I thought I’d mention it just in case you have not.

Thanks for that, and yes I did. This is the ‘previous workarounds’ that I mentioned in the post. Setting quiet to 1 disables the dialtone. I want to enable it, but it appears not to be properly configured on the DAHDI psuedo channel.

Ok, glad you saw that. I didn’t read it all because it’s a long thread but I thought there might be some other useful information in there. Oh well.

Are you doing an autopatch or PBX setup or is this install just for AllStar?

Hi Tim, and yes, I read through all the posts I could find on the subject. I am setting up the phone patch and am attempting to get the dialtone operational, and doing a deeper dive into the root cause of the error. It works well with quiet=1, which bypasses the dialtone issue, but gives the user no feedback that the patch is actually active, and I don’t want to release it without it. I have done some more investigating; and discovered that the culprit is an ENODATA error return from tone_zone_play_tone. It lives in, and copious amounts of grepping discovered that this is not included in the asterisk source, but the library is there. It appears to interact with a device called /dev/zap, onto which it does IOCTLS to start the dialtone. This is non-existent in /dev and lines 25783-25815 of app_rpt shows that if the open fails, then it opens /dev/null instead. I still need to confirm that is what it is actually doing, but I am pretty sure of it. The question of the day is, how to setup /dev/zap to deliver the tones. That will be the permanent fix. 73.

More info: I modified the source code to dump the error:
/* start dialtone if patchquiet is 0. Special patch modes don’t send dial tone */
int tzr;
if ((!myrpt->patchquiet) && (!myrpt->patchexten[0])
&& (tzr=tone_zone_play_tone(genchannel->fds[0],DAHDI_TONE_DIALTONE)) < 0)
ast_log(LOG_WARNING, “Cannot start dialtone: %d:%d:%d(%d) [%d]\n”,genchannel->fds[0],myrpt->patchquiet,myrpt->patchexten[0], tzr, errno);

Both patchquiet and patchexten[0] are zero, the return code from play_tone is -1, errno is 61 [ENODATA], and the file descriptor, fds[0] is 78, so something has been opened. Working on finding that out.

Correction: It is opening up /dev/dahdi/channel, which does exist (I am making discoveries as I go along…). So it appears that something is misconfigured or not working properly. Next task is to research how that gets set up and why it is refusing the IOCTL. Getting closer to a solution.

Just prior to that code, there is a call to set the tonezone with a similar IOCTL. If not configured, it is a null string, which appears to pass. When configured as ‘us’, (tonezone=) in rpt.conf, it fails. This should be a built-in, but it appears not to be there.

/dev/zap is part of zapatel.

I found the root cause of the missing dialtone, but there appears to be no interest in it. If you want to know more, contact me directly.

1 Like

Why not tell us here?

The root cause of the problem is trying to start the dial tone on the wrong file descriptor. In the app_rpt code, around line 11264, he attempts to start it with:
if ((!myrpt->patchquiet) && (!myrpt->patchexten[0])
&& (tone_zone_play_tone(genchannel->fds[0],DAHDI_TONE_DIALTONE) < 0))
If quiet is set (the workaround), it does not attempt the second statement, which is to plat the tone on fds[0]. I beleive that this is the wrong descriptor. Still reseaching which one is actually correct, and how to better find it rather than hard code it.

1 Like