NOT bug in 2.7 for ZAP handling, but in the chan_dahdi.conf

When I called from one extension at DAHDI channel 2-1 to DAHDI channel 1-1, it did not dial. I saw in the log:

[Mar 22 17:49:07] VERBOSE[5100] res_agi.c: – <DAHDI/2-1>AGI Script dialparties.agi completed, returning 0
[Mar 22 17:49:07] VERBOSE[5100] pbx.c: – Executing [s@macro-dial:7] Dial(“DAHDI/2-1”, “ZAP/1-1,”",tr") in new stack
[Mar 22 17:49:07] WARNING[5100] channel.c: No channel type registered for ‘ZAP’
[Mar 22 17:49:07] WARNING[5100] app_dial.c: Unable to create channel of type ‘ZAP’ (cause 66 - Channel not implemented)
[Mar 22 17:49:07] VERBOSE[5100] app_dial.c: == Everyone is busy/congested at this time (1:0/0/1)

Was that supposed to be DAHDI/1-1 installed of ZAP/1-1?

how did you configure your DAHDI extensions? are you set to DAHDI compatibility mode?

I figured it out. When you add ZAP extension, you specify the ZAP channel number. FreePBX automatically filled the ZAP device option for you. It did not really check if you are using DAHDI on the system, so that under “dial”, it filled ZAP/1-1, etc. Change that ZAP/1-1 manually to DAHDI/1-1 or whatever the channel number.

However, when I dial *65, it says “your extension number is”, without saying the actual extension number. I don’t know where to look into that.

that is wrong.

you should leave it as is. You need to put the system into DAHDI compatibility mode, it will do the translation automatically.

you set in amportal.conf:

ZAP2DAHDICOMPAT=true

Edit /etc/amportal.conf and add the following line:

ZAP2DAHDICOMPAT=true

Thanks, Blanchae. That seems works, but once I made change, the *65 will start announcing the largest extension number on ZAP channels for all the extensions. If I deleted the largest extension number, it will announce the next largest extension number for all the extension. So there is a bug somewhere in the FreePBX – it could not handle the AMPUSER correctly for ZAP channel users.

you will need to provide a call trace dialing *65 to see why it is doing that.

There was an issue reported in the forums the other day that I believe was the same issue. The problem was an incorrectly formatted dadhi configuration by some gen_dadhi related script that was breaking things.

You may want to search the forum for the issue, I seem to recall it was just in the last 1-2 weeks that it had come up and was tracked down to that.

Here are the log trace, DAHDI/2-1 has extension 7010, but somehow it gets AMPUSER 7138. I think the problem is in the extensions_additional.conf, but I don’t know how to fix it. Please note, if I delete the extension 7138, it will pick the next largest extension. I suspect this has something to do with ZAP and DAHDI conversion code. If I set ZAP2DAHDICOMPAT=false in the amportal.conf, *65 will not report any extension number.

[Mar 23 15:41:53] VERBOSE[29605] chan_dahdi.c: – Starting simple switch on ‘DAHDI/2-1’
[Mar 23 15:41:54] VERBOSE[29605] pbx.c: – Executing [*65@from-internal:1] Answer(“DAHDI/2-1”, “”) in new stack
[Mar 23 15:41:54] VERBOSE[29605] pbx.c: – Executing [*65@from-internal:2] Wait(“DAHDI/2-1”, “1”) in new stack
[Mar 23 15:41:55] VERBOSE[29605] pbx.c: – Executing [*65@from-internal:3] Macro(“DAHDI/2-1”, “user-callerid,”) in new stack
[Mar 23 15:41:55] VERBOSE[29605] pbx.c: – Executing [s@macro-user-callerid:1] Set(“DAHDI/2-1”, “AMPUSER=7138”) in new stack
[Mar 23 15:41:55] VERBOSE[29605] pbx.c: – Executing [s@macro-user-callerid:2] GotoIf(“DAHDI/2-1”, “0?report”) in new stack
[Mar 23 15:41:55] VERBOSE[29605] pbx.c: – Executing [s@macro-user-callerid:3] ExecIf(“DAHDI/2-1”, “1?Set(REALCALLERIDNUM=7138)”) in new stack

Currently, all incoming calls to each queue working correctly. All extensions can call each other and ring correctly, except calls between extensions all show the callerID on the phone from largest caller ID number.

you should have an entry auto generated in your chan_dahdhi_additional.conf file (or what ever we called it) that looks something like this:

;;;;;;[210]
signalling=fxo_ks
pickupgroup=1
mailbox=7010@device
immediate=no
echotraining=800
echocancelwhenbridged=no
echocancel=yes
context=from-internal
callprogress=no
callgroup=1
callerid=Device <7010>
busydetect=no
busycount=7
accountcode=
channel=>2

with what ever few differences are there based on your configuration. You should then have an astdb entry that looks something like this:

sip*CLI> database show device/222
/DEVICE/7010/default_user                          : 7010                      
/DEVICE/7010/dial                                  : ZAP/2                  
/DEVICE/7010/type                                  : fixed                    
/DEVICE/7010/user                                  : 7010

The macro-user-callerid uses the callerid from the dadhi file to find this DEVICE record and from there it pulls up your user information form the AMPUSER record. Something is not right in your dadhi configuration which is resulting in the wrong callerid from dadhi being transmitted which would create your error.

I have in the chan_dahdi_additional.conf for ext 7010:
;;;;;;[7010]
signalling=fxo_ks
pickupgroup=
mailbox=7010@device
immediate=no
echotraining=800
echocancelwhenbridged=no
echocancel=yes
context=from-internal
callprogress=no
callgroup=
callerid=device <7010>
busydetect=no
busycount=7
accountcode=
channel=>2-1

In asterisk -rvvv, I have this output:
*CLI> database show device
/DEVICE/7010/default_user : 7010
/DEVICE/7010/dial : ZAP/2-1
/DEVICE/7010/type : fixed
/DEVICE/7010/user : 7010

They all seems correct. If Dahdi not configured correctly, could all the calls handle correctly?

check the forums, over the last couple weeks. I’m almost sure someone had your exact same issue and it was a dadhi configuration issue that was making those settings not take.

This line looks wrong:

channel=>2-1

It should be channel 2 or 1 but not both. I wonder if this is causing the problem, creating a ring group that says try channel 2 first then go to channel 1.

Philippe, Thanks! You are absolutely correct. The problem is in that chan_dahdi.conf file.

The original file does not have these two lines in front of the channel number:

callerid=“my name”<7010>
mailbix=7010
channel =>2

I mistakenly thought the extension channels don’t need to specify the extension numbers, that could totally configured in the FreePBX. That was wrong. Only specifying the Extension number in FreePBX will not work properly.

As to Blanchae’s suggestion, it seems using ZAP/2-1 or ZAP/2 making no difference.

Thanks so much!

you should just be able to include the chan_dahdi_additional.conf at the end of your chan_dahdi.conf after you have done any trunk setup that is needed. That should take care of things I believe.

Thanks for the suggestion, Philippe. I have one more question, if I may. Everything seems working well, except pickup ringing extensions now. I checked *8 is enabled, ** also enabled in the feature code.

In the chan_dahdi.conf, each channel also have callgroup=1 and pickupgroup=1 before the channel number. But I could not get any extension pickup. Looked the full log, it seems the extension trying to pick up always hangup by pbx.c.

[Mar 24 15:23:34] VERBOSE[22262] app_dial.c: – DAHDI/1-1 is ringing
[Mar 24 15:23:35] VERBOSE[22264] chan_dahdi.c: – Starting simple switch on ‘DAHDI/2-1’
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Executing [*8@from-internal:1] Macro(“DAHDI/2-1”, “user-callerid,SKIPTTL,”) in new stack
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Executing [s@macro-user-callerid:1] Set(“DAHDI/2-1”, “AMPUSER=7010”) in new stack
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Executing [s@macro-user-callerid:2] GotoIf(“DAHDI/2-1”, “0?report”) in new stack
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Executing [s@macro-user-callerid:3] ExecIf(“DAHDI/2-1”, “1?Set(REALCALLERIDNUM=7010)”) in new stack
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Executing [s@macro-user-callerid:4] Set(“DAHDI/2-1”, “AMPUSER=7010”) in new stack
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Executing [s@macro-user-callerid:5] Set(“DAHDI/2-1”, “AMPUSERCIDNAME=my name”) in new stack
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Executing [s@macro-user-callerid:6] GotoIf(“DAHDI/2-1”, “0?report”) in new stack
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Executing [s@macro-user-callerid:7] Set(“DAHDI/2-1”, “AMPUSERCID=7010”) in new stack
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Executing [s@macro-user-callerid:8] Set(“DAHDI/2-1”, “CALLERID(all)=“my name” <7010>”) in new stack
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Executing [s@macro-user-callerid:9] GotoIf(“DAHDI/2-1”, “1?continue”) in new stack
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Goto (macro-user-callerid,s,18)
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Executing [s@macro-user-callerid:18] NoOp(“DAHDI/2-1”, “Using CallerID “my name” <7010>”) in new stack
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Auto fallthrough, channel ‘DAHDI/2-1’ status is ‘UNKNOWN’
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Executing [h@from-internal:1] Macro(“DAHDI/2-1”, “hangupcall”) in new stack
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Executing [s@macro-hangupcall:1] GotoIf(“DAHDI/2-1”, “1?skiprg”) in new stack
[Mar 24 15:23:37] VERBOSE[22264] pbx.c: – Goto (macro-hangupcall,s,4)

What could be wrong with this one?

Thanks so much for your help!

I would suggest you start a new thread to try to get help for that as you are going to be unlikely to get many people looking at it as far down as it is in a totally unrelated thread.

(e.g. you hijacked your own thread).