Cannot start dialtone on DAHDI channel (again)

App_rpt-users
1

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?

2

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

3

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.

4

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?

5

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 libtonezone.so, 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.

6

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.
73

7

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.
73

8

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.

9

/dev/zap is part of zapatel.

https://wiki.allstarlink.org/wiki/ASLCorporate:History
http://www.zapatatelephony.org

10

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
11

Why not tell us here?

12

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.
73.

1 Like