FreePBX Distro 3.211.63-5 (DAHDI 2.11.14): incoming calls show up without first digit

Hello,

I’m testing/evaluating FreePBX Distro 3.211.63-5 (x64) with Asterisk 11 and DAHDI 2.11.14 installed on a bare metal box with HFC-S Cologne Chip based ISDN PCI Card (single port) to connect with an single BRI (not PRI) Euro-ISDN PSTN land-line.

I noticed that incoming external calls (no matter if the caller is a PSTN land-line or a mobile line number) are correctly routed to an extension I defined (e.g. Extension 100, a SIP Terminal) BUT those calls show up on Asterisk’s log like the Called number was without its very first digit (as example: if called number is 01234 56789 then the number reported on the Asterisk logs appears only as 1234 56789 without the very first 0 digit).

AFAIK the incoming route I set up shouldn’t alter any digit on incoming calls (per default it accepts any DID / any CID).

Any possible cross-reference with (g0/DAHDI) Trunk settings I should fix or with DAHDI Hardware settings (National/International type of number settings) ?

Here a log (is there a way to attach files - txt or png - here ?) of a call when an external Mobile 3994709093 calls the ISDN Land-line 0444333695 (which is the system’s ISDN Number, as example), please note the loss of the first digit 0 on 444333695 on this long log:
[font=Courier]
localhostCLI>
– Accepting call from ‘3994709093’ to ‘444333695’ on channel 0/1, span 1
– Executing [444333695@from-digital:1] NoOp(“DAHDI/i1/3994709093-3”, “Catch-All DID Match - Found 444333695 - You probably want a DID for this.”) in new stack
– Executing [444333695@from-digital:2] Goto(“DAHDI/i1/3994709093-3”, “ext-did,s,1”) in new stack
– Goto (ext-did,s,1)
– Executing [s@ext-did:1] ExecIf(“DAHDI/i1/3994709093-3”, “1?Set(__FROM_DID=s)”) in new stack
– Executing [s@ext-did:2] Gosub(“DAHDI/i1/3994709093-3”, “app-blacklist-check,s,1()”) in new stack



– Goto (macro-hangupcall,s,3)
– Executing [s@macro-hangupcall:3] ExecIf(“DAHDI/i1/3994709093-3”, “0?Set(CDR(recordingfile)=)”) in new stack
– Executing [s@macro-hangupcall:4] Hangup(“DAHDI/i1/3994709093-3”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘DAHDI/i1/3994709093-3’ in macro ‘hangupcall’
== Spawn extension (macro-dial-one, h, 1) exited non-zero on ‘DAHDI/i1/3994709093-3’
== Spawn extension (macro-dial-one, s, 42) exited non-zero on ‘DAHDI/i1/3994709093-3’ in macro ‘dial-one’
== Spawn extension (macro-exten-vm, s, 14) exited non-zero on ‘DAHDI/i1/3994709093-3’ in macro ‘exten-vm’
== Spawn extension (from-did-direct, 100, 2) exited non-zero on ‘DAHDI/i1/3994709093-3’
– Hungup 'DAHDI/i1/3994709093-3’
localhost
CLI>
[/font]

Please note that regarding the 0444333695 number is made of 0444 (local prefix / area code prefix) and 333695.

Just another note: a call from land-line or mobile (in my country at least) to a land-line number is always started by dialling the whole number (made of a local prefix/area code - made of one, two or three [1-9] digits - and this area code always starts with a 0 followed by number) so 0x+number, 0xx+number or 0xxx+number (except for special emergency numbers which don’t have a local prefix).

Any idea ? where could be the issue ? what I do wrong ? Could be DAHDI Settings about National and International prefixes (0/00 as example) ?

It seem to me that changing those prefixes and restarting DAHDI as requested by FreePBX didn’t changed anything on incoming calls.

Best regards, Davide.

[color=blue]
Edit 08/02/2013: I found a thread similar to mine here although that user didn’t wrote where was exactly his issue and what exactly he did to solve it (apart from telling that it regarded the way he configured DAHDI).
[/color]

Whether you like it or not your inbound call is to 444333695 from 3994709093

Despite your parochial view internationally 39* is italy 44* is UK. not in-coincidentally NANP is 1NXXNXXXXX

Each country has a different way to dial + (the assumed localized international prefix) here it is 011 in the UK it is 00 just adjust your trunks to accept andf modify that reality.

Hello dicko,

I didn’t understand exactly what you meant to explain me with the statement “Despite your parochial view internationally 39* is italy 44* is UK. not in-coincidentally NANP is 1NXXNXXXXX”.

What’s NANP ?

I now that +39 means 0039 (internationally) and 39 is the Country Code reserved for Italy (I’m quite sure about that, as 44 is reserved for UK) and to call a PSTN italian number a foreign user should digit, here as example, +39 0444333695 (to call the 0444333695 land-line’s number) and +39 3994709093 (to call the 3994709093 mobile line’s number).

I also now that a user calling within the same country (Italy to Italy) could use simply the format 0444333695 and 3994709093 (but he could also dials the same numbers putting before +39 to user number if, as example, the call is originating from a Mobile phone). In both cases the calls will complete.

So the called party should see the caller number (on both ISDN lines AND old POTS analog lines) exactly as it really is (0xxxxxxx for land-line and 3xxxxxxxxx for mobile lines). Please don’t count the number of x I wrote (it’s just as an example).

Said that I don’t care about +39 (or 0039) because nobody in Italy is used to call italian numbers putting before the 0039 to a PSTN Land-line/Mobile-line number (although if you do that on Mobile phones it works pretty well as written above).

The point I don’t understand is why the first digit (but only if it is equal to 0) of the number get lost when the Telco’s Provider is sending the whole called number with its 0 (so 0444333695): shouldn’t I see 0444333695 called by 3994709093 ?

Thanks! Davide.

The “0” is not actually part of the number. NAMP is the North American numbering plan. All numbers in North America look like this… AAA PPP NNNN where A is the area code, P is the exchange prefix and N is the number. If someone is out of my local calling area, they have to dial 1 first, but the 1 is not actually part of the number and is not transmitted as part of the CLID. All I get is AAA PPP NNNN. If a person is inside my calling area they don’t dial the 1, just the 10 digits. either way I get the same CLID. Likewise in your case, the 0 is not actually part of the number, and is Not being sent to you by telco. I don’t see anything in your logs that indicate that a 0 is being sent to you. I think I’ve said the same thing dicko said, just worded it a little differently.

I would surmise that your dilemma is that you want the number reflected on th CLID display on your phone to exactly reflect what must be dialed to return the call I’m not sure there is any easy way to do that.

That being said, you should be able to create filing rules in the outbound routes to prefix the 0 to dialed number where necessary. That way, even though the 0 doesn’t show up in the CLID display, dialing the number without the 0 will always go through.

BF

I understand your line of reasoning: it’s correct but only if you consider NAMP the only one numbering standard adopted.

If I apply your way of thinking here in Italy I should then expect that calling back (or just calling) the number you say is (or should be) the real one (so dialling exactly 444333695 as per Asterisk incoming call’s log) then I should reach someone…but it’s not true.

As I wrote yet, every PSTN number in Italy starts with 0 (and not the 0 - like the 9 in USA - used to place an outbound call like when this one originates behind a PBX).

That’s a completely another toy to play with: we don’t need to think “if the called number is in my area or so…then…” we just call the whole number because the 0 is simply PART of it.

This rule is valid since 1999 (I think) except for:

  • Mobile phone’ numbers (3xx followed by seven digits, where each Mobile operator has its 3xx type, as example: 333, 347 or 339 and so on).
  • Emergency/Special numbers (like 1xx Public Services and 8xx Toll Free numbers).

There are other special cases but they are out of scope.

In my case I think the italian 0 forms part of what you call your AAA Area Code.

As example this is a list of italian Area Codes:

049 is used for Padova city
02 is valid for Rome
06 is used for Milan
0422 is used for Treviso city

I really can’t call a subscriber only dialling 49xxxxxx I must use 049xxxxx. A call back to 49xxxxx (as presented) will fail.

Read here from Wikipedia about Italy (so basically in my country Regional Area Codes are incorporated into subscriber’s number): “In some cases a trunk code (usually 0) must still be dialed, as in Belgium, Italy, Switzerland, South Africa and some locations within the NANP”.

I’m sure there is something wrong in my configuration of DAHDI (or DAHDI Module) because a lot of Asterisk / FreePBX systems are already deployed here since Asterisk was born.

More explicit here:

Trunk Prefix: Leading 0 is dialled both within and from outside Italy.

And more here (directly from ITU) in English about the Area Code +39 (Italy):

Typo, sorry…I meant: In my case I think the italian 0 forms part of what you call your AAA Area PPP Exchange Prefix Code (as you call it).

Actually there is just one standard, E.164, which was developed from AT&T’s 1948 original NANP plan. For your carrier’s behavior ( apparently E.164 compliant) your national number including any prefix might need to be modified. You might want to google

asterisk nationalprefix=0

(and internationalprefix=00) to match what you need.

Hello dicko,

what you said is what I suspect BUT I have yet forced it (at least) manually editing this configuration file:

/etc/asterisk/chan_dahdi_channels_custom.conf

which probably is not the right file (even if it’s included in chan_dahdi.conf) and it looks like:

[channels]
language=it
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
group=1
callgroup=1
pickupgroup=1
pridialplan=unknown
prilocaldialplan=unknown
nationalprefix=0
internationalprefix=00
; overlapdial=yes
priindication=outofband

But still no way to fix this issue regarding the leading 0.

AFAIK the problem is that actually there is NO place in DAHDI Configuration Module (so through GUI) to set both nationalprefix and internationalprefix variables.

AT LEAST for what I saw.

It seems to me that there is a lot of confusion (or lack of coherence) about what DAHDI Configuration Module actually does / is able to do / is not able to do and in which way does it / doesn’t it against dahdi configuration files and, at least, for BRI setup.

Out of Topic: consider that selecting BRI CPE PTMP signalling method (which was introduced by Development very recently, see fixes to Bug 6244) there are always options which one can erroneously consider to be not important or not global (as example: “Pridialplan” and “Prilocaldialplan”; since PRI is not BRI the presence of these options leaves me with the doubt about their effects on the BRI I’m setting up).

Pointing back to the issue I’ve read elsewhere that nationalprefix and internationalprefix variables should also be placed BEFORE any channels definition (in my case, before channel >= 1-2 declaration) to have an effect for those channels.

Let me assume that this issue could be definitely fixed by setting national and international prefixes, a few questions then will arise (especially if I insist in give DAHDI Configuration Module a try):

  • Where and in which way should I do this fix if DAHDI Configuration Module doesn’t let me do that (no settings) ?
  • Should I manually alter which file exactly ?
  • Which order then eventually I should respect in inserting variables ?
  • In which way DAHDI Configuration Module copes with dahdi (ALL) configuration files IF some settings are available through GUI (about Digital Hardware part I mean) and others are missing ?
  • Will DAHDI Configuration Module overwrite my manually set variables (if any) ?
  • If “yes” (dahdi_cfg runs during each (re)boot): which settings will be touched and which default template will be then used ?
  • What is this template (Global settings ?)
  • Why can’t we have a full page with all options (specific ones and global ones) about dahdi under the DAHDI Configuration Module ?

I feel I actually have an incomplete control against dahdi through its DAHDI Configuration Module but also this module is, IMHO, incomplete and confusing. Am I wrong ? I which way could I help ?

Davide.

- Where and in which way should I do this fix if DAHDI Configuration Module doesn't let me do that (no settings) ?
There is currently no way to add custom settings per each digital card or analog card. You can however apply custom settings globally (read below)
- Should I manually alter which file exactly ?
See above
- Which order then eventually I should respect in inserting variables ?
For future reference ALL variables should be listed before the channel delcaration
- In which way DAHDI Configuration Module copes with dahdi (ALL) configuration files IF some settings are available through GUI (about Digital Hardware part I mean) and others are missing ?
For settings in chan_dahdi and in modprobe there are extra input boxes to allow custom input. These 'custom' setting may or may not get put in digital and analog settings. For now they are not there
- Will DAHDI Configuration Module overwrite my manually set variables (if any) ?
yes if they are not placed in a custom file.
- If "yes" (dahdi_cfg runs during each (re)boot): which settings will be touched and which default template will be then used ?
Why is dahdi_cfg running everytime you reboot! That is absurd. You'd essentially be regenerating your configurations each time you reboot the system.
- What is this template (Global settings ?)
chan_dahdi.conf, settings which happen BEFORE any real channels are defined. Essentially you could place your international and national settings in this file and it will apply to ALL channels as the settings are defined ONCE before ANY channel is defined.
- Why can't we have a full page with all options (specific ones and global ones) about dahdi under the DAHDI Configuration Module ?
Because there are many many settings and if you'd like to pay my salary to add all of those features then be my guest, however my employer, Schmoozecom has paid me to add the relevant features that apply to our client base or that our client base has requested. You can always file a ticket/feature request and I will get to it eventually, as I have done for most of the other tickets relating to dahdi. Though Dicko has provided you with good information you can't assume that the development staff will always be looking at these forums or that we can or will remember what has been said, this is why bug reports are very essential.

More information can be found here: Sangoma Documentation

Hello Tony, I appreciate your intervention here.

You are the expert here and your worlds have a lot of importance.

From your sentences I understand that (correct me if I’m wrong):

  • DAHDI Configuration Module (I'm referring to DAHDI Config 2.10.14/2.11.14) is not actually designed to manage all possible parameters that dahdi configuration files are providing (it manages only a subset of them).
  • Each user is free to manage dahdi configuration file's parameters - which are not all available through DAHDI Configuration Module cited above - by manually editing some additional dahdi configuration files respecting some sort of insertion order (ordering parameters insertion inside each file respecting section's order and also ordering #include statements in each configuration file when that's permitted), let me consider some of them:
    1. (A) /etc/asterisk/chan_dahdi_general.conf (which should not be edited by user because it's auto-generated by FreePBX and which is included BEFORE the [channels] section of /etc/asterisk/chan_dahdi.conf)
    2. (B) /etc/asterisk/chan_dahdi_general_custom.conf (which is actually blank)
    3. (C) /etc/asterisk/chan_dahdi_channels_custom.conf (which is included AFTER the [channels] section of /etc/asterisk/chan_dahdi.conf and where I added the nationalprefix=0 and internationalprefix=00 parameters
    4. (D) /etc/asterisk/chan_dahdi_groups.conf (which should not be edited by user because it's auto-generated by FreePBX)
    5. (E) /etc/asterisk/chan_dahdi_additional.conf (which should not be edited by user because it's auto-generated by FreePBX)
    6. (F) /etc/asterisk/dahdi-channels.conf (which is auto-generated by dahdi_genconf tool and should not be edited because it shall overwritten each time the dahdi_genconf runs, this configuration file should be inclued in /etc/asterisk/chan_dahdi.conf but AFAIK it's not!)
    7. (G) /etc/modprobe.d/dahdi.conf (which should not be edited by user because it's auto-generated by FreePBX and any modification should be performed through FreePBX's GUI as advised)
    8. (H) /etc/modprobe.d/dahdi.blacklist.conf
    9. (I) /etc/dahdi/system.conf (which should not be edited by user because it's auto-generated by FreePBX and any modification should be performed through FreePBX's GUI)

    Am I missing something ?

    What a confusion (in my head). Isn’t it ?

    Someone should definitely start to write a specific Wiki page about this labyrinth of configuration files and the way they interact each others considering that DAHDI Configuration Module (FreePBX) has relationships with them.

    Count on me.

    Then, when you worte:

    Because there are many many settings and if you'd like to pay my salary to add all of those features then be my guest, however my employer, Schmoozecom has paid me to add the relevant features that apply to our client base or that our client base has requested.

    I must admit that I’m not able to pay you a full monthly salary or an additional one to the one you receive yet from Schmoozecom Inc. (I would if I could!).

    I understand you.

    I’m not commanding nothing to you.

    I’m just reporting some nice enhancements, features (or inconsistencies I found) that could or couldn’t be evaluated by you when you have some spare time and/or resources to manage them.

    You can always file a ticket/feature request and I will get to it eventually, as I have done for most of the other tickets relating to dahdi.

    That’s a nice advice: sure I’ll open TRAC Tickets for what IMO could be useful both to me and to other users that, like me, are trying to use FreePBX Distro with my same Hardware and same Euro-ISDN BRI connection (probably few in USA but more in Europe).

    More, when you wrote:

    Though Dicko has provided you with good information you can't assume that the development staff will always be looking at these forums or that we can or will remember what has been said, this is why bug reports are very essential.

    I never assumed anything.

    Having said so I’m telling you all I want to contribute with what I have here (an bare metal system with ISDN BRI connection to make some basic testing) trying to help you enhancing (in many ways) a specific part of FreePBX Distro that is DAHDI Configuration Module, part that’s interesting me more than others.

    I hope you will accept my thoughts and my questions regarding what I found and I hope you will agree with me that I did them in a polite way and with a language as clear as possible for my personal level of English (which isn’t my mother tongue).

    Regards, Davide.

    P.S.
    Yes, I’ve read that document many weeks ago…

Hello Tony,

in your opinion should I leave both parameters (in my case: [color=blue]nationalprefix=0[/color] and [color=blue]internationalprefix=00[/color]) under the [color=green][channels][/color] section of:

/etc/asterisk/chan_dahdi_channels_custom.conf

which is then included (by means of the string #include /etc/asterisk/channel_dahdi_channels_custom.conf) AFTER the [color=red][channels][/color] section of

/etc/asterisk/chan_dahdi.conf

Shouldn’t be included BEFORE that section as you said ?

Maybe the issue will vanish if those parameters could be included directly under the [color=red][channels][/color] section of

/etc/asterisk/chan_dahdi.conf

other than including them by means of a configuration’s file inclusion.

I will test this other different way of declare those parameters (I already can say that with the first one, which is actually used, the issue shows up).

Here the cat of /etc/asterisk/chan_dahdi.conf
;--------------------------------------------------------------------------------;
; Do NOT edit this file as it is auto-generated by FreePBX. All modifications to ;
; this file must be done via the web gui. There are alternative files to make ;
; custom modifications, details at: http://freepbx.org/configuration_files ;
;--------------------------------------------------------------------------------;
;
[general]
; generated by module
#include chan_dahdi_general.conf
; for user additions not provided by module
#include chan_dahdi_general_custom.conf
[color=red][channels][/color]
language=en
busydetect=yes
busycount=10
usecallerid=yes
callwaiting=yes
usecallingpres=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=no
immediate=no
faxdetect=no
rxgain=0.0
txgain=0.0
; for user additions not provided by module
[color=blue]#include chan_dahdi_channels_custom.conf[/color]
; include dahdi groups defined by DAHDI module of FreePBX
#include chan_dahdi_groups.conf
; include dahdi extensions defined in FreePBX
#include chan_dahdi_additional.conf

Here the cat of /etc/asterisk/chan_dahdi_channels_custom.conf
[color=green][channels][/color]
language=it
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
group=1
callgroup=1
pickupgroup=1
pridialplan=unknown
prilocaldialplan=unknown
[color=blue]nationalprefix=0[/color]
[color=blue]internationalprefix=00[/color]
; overlapdial=yes
priindication=outofband

Hoping those parameters have really an effect…

Regards, Davide.

No. You are declaring the [channels] sections twice and you are going to have conflicts because of that. Remove everything from your custom file. Simply go into the module and add those settings under “global settings”. There are text boxes at the bottom of the popup modal that allow you to add custom settings. it’s really THAT easy and I’ve been trying to tell you that from the start but you keep thinking about how to do it with editing files. You don’t need to edit ANY files. So stop thinking like that. All control can be found in the module.

Side note. My name is NOT tony.

My apologizes, Andrew. Sorry, I confused your Alias with Tony Lewis (don’t ask my why because I don’t know).

Hi tm1000,

OK I tested on fresh newly installed FreePBX 3.211.63-6 (DAHDI Configuration Module 2.11.15) on bare metal.

Of two parameters ([color=blue]nationalprefix[/color] and [color=blue]internationalprefix[/color]) manually added through DAHDI Global Settings window with the procedure you say ONLY the last one added (in this case [color=blue]internationalprefix[/color]) hits the /etc/asterisk/chan_dahdi.conf file, the first one disappears.

See the DAHDI Global Settings window before:
http://postimage.org/image/p62qv04ij/

See it after it was Saved, Applied and Restarted/Reloaded DAHDI (as per FreePBX request):
http://postimage.org/image/qqgm9nse7/

And this is the fresh FreePBX auto-generated /etc/asterisk/chan_dahdi.conf file has it appears just after the Save, Apply and Restart/Reload DAHDI:

;--------------------------------------------------------------------------------; ; Do NOT edit this file as it is auto-generated by FreePBX. All modifications to ; ; this file must be done via the web gui. There are alternative files to make ; ; custom modifications, details at: http://freepbx.org/configuration_files ; ;--------------------------------------------------------------------------------; ;

[general]

; generated by module
#include chan_dahdi_general.conf

; for user additions not provided by module
#include chan_dahdi_general_custom.conf

[channels]
language=en
busydetect=yes
busycount=10
usecallerid=yes
callwaiting=yes
usecallingpres=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=no
immediate=no
faxdetect=no
rxgain=0.0
txgain=0.0
[color=blue]internationalprefix=00[/color]

; for user additions not provided by module
#include chan_dahdi_channels_custom.conf

; include dahdi groups defined by DAHDI module of FreePBX
#include chan_dahdi_groups.conf

; include dahdi extensions defined in FreePBX
#include chan_dahdi_additional.conf

As you can see the [color=blue]nationalprefix[/color] parameter (equal to 0) is not present.

Tested inverting the order of insertion (first I added the [color=blue]internationalprefix[/color] then the [color=blue]nationalprefix[/color]) but nothing changed AND when I reopened the Global Settings window it showed no (manually added) parameters at all…fields were blanks.

Reverting back to the first order described it shows only the [color=blue]internationalprefix[/color] that could be easily removed and so it will disappear from the configuration file too.

Should I open a Ticket in TRAC ?

Regards, Davide.

This was fixed.

Thanks tm1000!

I see it works now.

I’ll then test this updated DAHDI Configuration Module (2.10.16/2.11.16) as per your advice. Thanks again. Davide.