British Telecom ISDN BRI line issues

Home » Asterisk Users » British Telecom ISDN BRI line issues
Asterisk Users 19 Comments

Should I understand that no Asterisk user has issues with ISDN “system
access” configuration from UK? or maybe no one is using Asterisk In UK 🙂 ?

On Tue, May 8, 2012 at 12:46 PM, khalid touati wrote:

> Hi All,
> I am posting this thread with the hope that someone in UK (or elsewhere)
> had a similar issue:
> Our issue is simple, we cannnot use our ISDN line, when watching asterisk
> console it gives a bunch of ISDN errors where the following is probably the
> most relevant:
>
> Span: 4 TEI=0 MDL-ERROR (J): N(R) error in state 7(Multi-frame established)
>
> We are using asterisk 1.8.12.0 with dahdi 2.6.0, on CentOS 6.2. I can post
> configuration and/or further information if needed.
>
> —
> Khalid Touati
> Network Administrator
> CCNA
>
>
>

19 thoughts on - British Telecom ISDN BRI line issues

  • I have no idea. But other than the error you have given very little
    information to go on. Which card are you using, what type of ISDN line
    (PTP?), what’s the DAHDI or Sangoma (or…) and Asterisk configuration,
    what do the log files say, etc?

    Have you tried calling the vendor of the ISDN card for support?

    Regards,
    Patrick

  • Thank you for your answer, I think I posted dhadi version and so but let
    me add more details and recap them below:

    We are using asterisk 1.8.12.0 with dahdi 2.6.0, on CentOS 6.2. it’s a
    digium card 1HA8-0400BLF

    output of dahdi_hardware: pci:0000:04:08.0 wctdm24xxp+ d161:8008
    HB8-0000

    From BT side: it is called by BT a “system access” ISDN2 BRI (per BT NT
    mode and signaling as PTP)

    chan_dahdi.conf
    ; Span 1: WCBRI/0/0 “HB8-0000” (MASTER) AMI/CCS
    group=1,11
    context= mainmenu
    switchtype = euroisdn
    signalling = bri_cpe
    channel => 1-2
    context = default
    group = 63

    ; Span 2: WCBRI/0/1 “HB8-0000” AMI/CCS
    group=1,12
    context=mainmenu
    switchtype = euroisdn
    signalling = bri_cpe
    channel => 4-5
    context = default
    group = 63

    ; Span 3: WCBRI/0/2 “HB8-0000” AMI/CCS
    group=1,13
    context=mainmenu
    switchtype = euroisdn
    signalling = bri_cpe
    channel => 7-8
    context = default
    group = 63

    ; Span 4: WCBRI/0/3 “HB8-0000” AMI/CCS
    group=1,14
    context=mainmenu
    switchtype = euroisdn
    signalling = bri_cpe
    channel => 10-11
    context = default
    group = 63

    the error when placing a call : *Span: 4 TEI=0 MDL-ERROR (J): N(R) error in
    state 7(Multi-frame established)
    *
    Thank you!!

    On Wed, May 9, 2012 at 1:22 PM, Patrick Lists <
    asterisk-list@puzzled.xs4all.nl> wrote:

  • You did not provide system.conf. Do you have something like this (may
    have errors, I did not check):

    loadzone = uk
    defaultzone = uk
    span => 1,1,0,ccs,ami,te,term
    bchan = 1,2
    hardhdlc = 3

    span => 2,2,0,ccs,ami,te,term
    bchan = 4,5
    hardhdlc = 6

    span => 3,3,0,ccs,ami,te,term
    bchan = 7,8
    hardhdlc = 9

    span => 4,4,0,ccs,ami,te,term
    bchan = 10,11
    hardhdlc = 12

    Then as root:
    modprobe wctdm23xxp

    And as root:
    dahdi_cfg -vvv

    And check if all is well (green leds, happy messages in
    /var/log/messages, etc.).

    Then in chan_dahdi.conf use something like:

    ;BRI Module
    group = 1
    signalling = bri_cpe
    context = incoming
    channel => 1,2,4,5,7,8,10,11

    Your chan_dahdi.conf has “group” and “context” multiple times and that
    does not seem right (admittedly it’s been ages since I setup a Digium card).

    Hope this helps. If not follow the installation manual step for step or
    call Digium support.

    http://docs.digium.com/H8/hx8_series_manual.pdf

    Regards,
    Patrick

  • Yeah sorry for that, I realized something is missing after I sent the
    email, but it is exactly what I have (other than order here, which doesn’t
    really matter: you posted ami,te,term, I have ami,term,te).
    Actually I had couple technicians from digium look at it and they said BT
    equipements is not responding to the card within a certain range that the
    card is looking for (i’m not sure what range but I do believe too it’s a BT
    issue), But I have run all the couple command that Patrick suggested (to
    double check), tested again and still same kind of errors.
    But Thank you very much Patrick for the guide, I was looking for that it’s
    been a couple days!!
    I just hope someone that has the exact same issue or someone with previous
    BT experience see this and help 🙂 ..we never know 🙂 !

    On Wed, May 9, 2012 at 2:40 PM, Patrick Lists <
    asterisk-list@puzzled.xs4all.nl> wrote:

  • Too bad you could not (yet) make it work. Hope you get somewhere with
    BT. Once you get past the people following those silly scripts you
    should be able to talk to someone who has a clue and resolve this issue.

    Good luck!

    Regards,
    Patrick

  • Hi All,
    I did downgrade to asterisk 1.6.2.6 and dahdi 2.3 which is working with
    other BRI line (in our NL office), but I get this type of errores:

  • No but there is a bug report with a lot of information that seems
    similar: https://issues.asterisk.org/jira/browse/14031

    In Europe telco’s drop the D-channel (cut off power) to save on the
    electric bill. The libpri/dahdi/asterisk combo should detect a dropped
    D-channel and signal the telco to fire up the D-channel. Judging from
    that bugreport (“Unresolved”) it seems Digium has still not succeeded in
    properly handling this situation.

    Should you not be able to resolve this issue and really require an ISDN
    BRI connection then have a look at an Eicon Diva or Sangoma card. Both
    cards+drivers properly handle a dropped D-channel. I have used Eicon
    Diva and Sangoma BRI cards in the Netherlands and they work fine. Or you
    could get a blackbox from Beronet, Patton, Audiocodes etc. If you feel
    adventurous you can also get a BRI card with a HFC-S Cologne chipset and
    get the latest and greatest isdn4k-utils, mISDN, mISDNuser and lcr from
    http://misdn.eu, build, install and configure lcr to talk to asterisk. A
    few weeks ago I set it up and did one test call and that call worked
    fine. Use at own risk 🙂

    Regards,
    Patrick

  • There are patches in the works already (being tested by users in Europe)
    to deal with this layer 1 issue. Upcoming releases of DAHDI and Asterisk
    should have support for it.

  • Patrick,
    I got confused though is this true:
    Any Asterisk soft+digium hdw => it doesn’t work
    Any Asterisk soft+sangoma hdw => it works
    Patched asterisk soft+digium hdw => it will work (per Kevin)

  • Hi Khalid,

    Judging from that bug report I *think*:

    There seem to be combinations that do work. It is my understanding from
    that bugreport that an older libpri works with an older version of
    asterisk that does not have this issue. If your goal is to deploy the
    latest-and-greatest libpri, dahdi and asterisk 1.8 releases then it does
    not seem to work.

    In my experience yes. Same goes for Eicon Diva Server cards.

    Yes per Kevin’s comment.

    Regards,
    Patrick

  • Unfortunately not and I don’t have a Digium BRI card to test with
    anyway. Perhaps you could ask Kevin for the patches so you can
    participate in the testing and help making sure it works properly?

    Regards,
    Patrick

  • My Issie is finally fixed and I can make calls, I received actually from
    digium the fix, I’ll try to give as much details as I can to make sure
    people who find this thread understand pb and solution.

    Problem: not able to dial calls using BRI from British Telecom configured
    as “system access” or PTP (“standard access which is PTMP works fine) (see
    above for errors thrown)
    Solution: adding this line “options wctdm24xxp bri_persistentlayer1=1” to
    /etc/modprobe.d/dahdi.conf and restarting asterisk and dahdi of course.
    Versions used: asterisk 1.6.2.6 dahdi 2.3.0.1 libpri 1.4.10.2
    Special thanks to Patrick! thanks and good luck to all!

  • bri_presistentlayer means that the drivers will force the >D-channel to
    always be up then do not be surprised if BT disables the ISDN port. They
    don’t like it if a customer forces them >to power the D-channel all the
    time at their expense. And with their ISDN team not contactable it may be a
    bit of a >challenge >to get them to enable the port again (after you
    promised not to mess with heir D-channel again…).

    Hi Patrick,
    it seems like you have the magic ball, I think what you described is
    exactly what happened:
    After we tested the server+ link and we were able to have simultaneous
    calls (as expected), and knowing that this server was not touched (not even
    rebooted), it is back not dialing through PTP link.The server remained
    working from Friday to at least Monday then boom, when I called BT…of
    course no explanation…. I am just wondering: their mechanism to miss up
    things, is it automatic or manual ( I think automatic).

  • Hi Khalid,

    As far as I know the telco’s monitoring infra will automagically disable
    the ISDN port. You can request that the telco disable monitoring of the
    port which will prevent them from shutting it down. But if there’s
    something wrong with the port/linecard on their switch they will no
    longer notice. In the end the only solution is to deploy software than
    can properly handle the D-channel in all its states.

    Regards,
    Patrick

  • It turned out that we were just using a non matching configuration from
    Dahdi tools, we were trying to use spans that has no modules inside, once
    we configured only the spans that has BRI modules (under systems.conf and
    dahdi-channels.conf), things started to work normally.