Leading Ghost 0

Home » Asterisk Users » Leading Ghost 0
Asterisk Users 16 Comments

Hi all,

I have problems dialling out because my new telco (the previous gave no problems) tells me my PBX adds a leading 0 and that’s why I cannot dial out (but I can receive calls).

I make a small extensions.conf as a test:

exten => 666,1,Dial(DAHDI/g1/339xxxxxx)
but cannot dial out

Curious thing is that exten => 666,1,Dial(DAHDI/g1/0233xxxxxx)
and exten => 666,1,Dial(DAHDI/g1/233xxxxxx)
call the same number!!!

Line in use is a PRI.

My Asterisk version is 1.4.26.2
dahdi version: 2.2.0.2
wanpipe-3.4.6

I checked with intense pri debug and see no 0 inside frames….

How can I really be SURE Asterisk is not adding some leading zero?

Thank you.

Giorgio.

16 thoughts on - Leading Ghost 0

  • 2012/11/20 gincantalupo

    I have never heard of a way to automatically add digits when using PRI, however can you check your chan_dahdi.conf about the following lines:

    internationalprefix nationalprefix localprefix If presents, try messing with them. If you are using the PRI in Italy, every provider has PRI configured in its own way, some time even the same provider is configuring PRI lines in multiple times, but often the problems are on receiving the calls (like calls with and without the area code, with or without the leading zero, etc. etc.)

    Leandro

  • Hi Leandro,

    thanks for your answer.

    I already have tried those parameters but without any positive result.

    The telco technician has tried the line with its machine and it worked…remote telco technicians say they get a leading zero… I’m thinking there is something strange in the middle that adds the zero but do not know what it is. Strange is the fact that you can call some numbers with or without the prefix zero… Moreover we had no problem with the previous telco (fastweb).

    So we can only call PTSN numbers….not mobile phones.

    Giorgio

  • That is a real mistery! I like a lots these cases when all seems not working despite all being correctly configured, but you know first or later you’ll find the answer.

    From your website, it seems you are selling/renting PBX based on asterisk, so you can be sure nobody has messed with the asterisk or dahdi source code adding a zero… I am sure you have already tried with a brand new server.

    Have you checked the pridialplan and prilocaldialplan setting?

    If I was in your shoes, I’ll get another server, with a PRI configured as master and hook it at your PBX to really check if the zero is sent.

    Does the technician try to make phone calls from the same network cable you are using?

    Leandro

    2012/11/20 gincantalupo

  • Hi Leandro,

    I’m sure nobody has added something… tried prilocaldialplan and pridialplan but nothing changed. Question: if pridialplan or prilocaldialplan would work, should I see the 0 inside PRI frame with intense debug or it is hidden?

    Yes…the technician did it…there is only one cable.

    Maybe it is the socket circuitry that has something wrong but I do not know ho to check.

    Asap I’ll be on site I’ll do more testing.

    Thank you

    Giorgio

  • Somebody correct me if I’m wrong but I think you have to restart asterisk when you change these settings on dahdi. Keep that in mind.

    Cheers,

    Frederic

  • In my past experience the best recourse for dealing with a DAHDI trunked asterisk system is this sequence

    Service asterisk stop

    Service dahdi restart

    Service asterisk start

    From: asterisk-users-bounces@lists.digium.com
    [mailto:asterisk-users-bounces@lists.digium.com] Somebody correct me if I’m wrong but I think you have to restart asterisk when you change these settings on dahdi. Keep that in mind.

    Cheers,

    Frederic

  • The prilocaldialplan parameter is for inbound so you would have seen no changes. Did you try:

    pridialplan=unknown

    Did you restart dahdi and asterisk after the changes?

    Alex

  • Hi Leandro,

    I cannot restart dahdi because the PBX is in production, all I can do is a module reload chan_dahdi.so.

    Giorgio

  • Then if you did not restart dahdi and asterisk, then the changes to the parameters in chan_dahdi.conf and system.conf were never taken into account. There is no other way than really restarting asterisk and dahdi.

    Frederic

  • I am not really sure, restarting asterisk and dahdi can be the most obvious thing to do, but restarting the dahdi kernel module can be useless if you haven’t changed the kernel module configuration and reloading the module in asterisk can be enough if you have changed just the chan_dahdi.conf

    Leandro

    2012/11/21 Frederic Van Espen

  • Alex,

    I had already tried it….reloading chan_dahdi.so module is enough…I
    saw Asterisk was behaving differently after reload. To tell the truth, setting pridialplan=unknown causes Asterisk to stop reading following channels configuration…it says pridialplan is already unknown so it stops evaluating chan_dahdi.conf file…. useless to say that all n+1
    channels do not work. Maybe it is a bug but with that parameter set in that way I cannot dial.

    I’m sure Asterisk is dialling the right number:

    [2012-11-21 09:05:29] VERBOSE[8314] logger.c: > [70 0b a1 33 34 39 3x 3x
    3x 3x 3x 3x 34]
    [2012-11-21 09:05:29] VERBOSE[8314] logger.c: > Called Number (len) [
    Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan
    (E.164/E.163) (1) ‘3497078884’ ]
    [2012-11-21 09:05:29] VERBOSE[8314] logger.c: q931.c:3134 q931_setup:
    call 32781 on channel 6 enters state 1 (Call Initiated)
    [2012-11-21 09:05:29] VERBOSE[8314] logger.c: — Called 6/349xxxxxx4

    I’m starting to think it is a telco problem… in case I’d change some parameter like pridialplan or similar, shouldn’t I just see a leading 0
    in the frame like this:
    [70 0b a1 *30* 33 34 39 3x 3x 3x 3x 3x 3x 34] added by Asterisk/DAHDI??

    I’ve used this page as reference about frame fields:
    http://www.acacia-net.com/wwwcla/protocol/q931_ie.htm

    Thank you.

    Giorgio Incantalupo

  • Any changes inside chan_dahdi requires you to unload module chan_dahdi and load module chan_dahdi, in case you dont wish to.restart asterisk.

    pridialplan = national or unknown should help you solve the problem, however you need to unload n load dahdi module.

    Mitul

  • Giorgio,

    It looks like your pridialplan is net to national. You can see that in the line from your log that reads:

    “[2012-11-21 09:05:29] VERBOSE[8314] logger.c: > Called Number (len)
    [Ext: 1 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan
    (E.164/E.163) (1) ‘3497078884’ ]”

    If I remember correctly, it should read “TON: Unknown Number Type” if pridialplan was set to unknown. Unless this has changed, reloading chan_dahdi will NOT reconfigure Signalling, PRI, and SS7 parameters. You have to restart Asterisk.

    Alex

  • THIS IS INCORRECT! MOST changes to chan_dahdi.conf are applied on a reload. There are a few items like switchtype and signaling and a few other items which require chan_dahdi.so to be unloaded then loaded.

    —–Original Message—

  • Un-top-posting,

    No need for that.

    Some of the settings in chan_dahdi.conf (most of the per-span settings)
    are not applied at configuration reload. There are some slightly less brutal ways than fully restarting Asterisk to apply them:

    In the Asterisk CLI:

    dahdi restart

    Or, again in the Asterisk CLI:

    module unload chan_dahdi.so
    module load chan_dahdi.so

    No need to load / unload any kernel modules and such.