Asterisk – PRI to PRI Connection with HDLC Errors

asterisk

I want to connect(for learning, nothing serious), two asterisk server via ISDN PRI.
The first server will act as "telco" so is pri_net, the second server is the cpe, so I will use pri_cpe.

The cards are

pbx1-net: Digium TE205P
pbx2-cpe: Openvox D210P

Both servers/pbx use Debian 11 and dahdi 2.11 drivers

On the pbx-net this is dahdi/system.conf

    # Span 1: WCTDM/4 "Wildcard TDM400P REV E/F Board 5" (MASTER) 
    fxoks=1
    echocanceller=mg2,1
    fxoks=2
    echocanceller=mg2,2
    # channel 3, WCTDM/4/2, no module.
    fxsks=4
    echocanceller=mg2,4
    
    # Span 2: TE2/0/1 "T2XXP (PCI) Card 0 Span 1" 
    span=2,0,0,ccs,hdb3,crc4
    # termtype: te
    bchan=5-19,21-35
    dchan=20
    echocanceller=mg2,5-19,21-35
    
    # Span 3: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" 
    span=3,0,0,ccs,hdb3,crc4
    # termtype: te
    bchan=36-50,52-66
    dchan=51
    echocanceller=mg2,36-50,52-66
    
    # Global data
    
    loadzone    = it
    defaultzone = it

this is the /etc/asterisk/chan_dahdi.conf on pbx-net

    [trunkgroups]
    [channels]
    language=it
    context=local
    switchtype=euroisdn
    signalling=pri_net
    usecallerid=yes
    hidecallerid=no
    callwaiting=yes
    usecallingpres=yes
    callwaitingcallerid=yes
    threewaycalling=yes
    transfer=yes    ;se usi nt ptmp metti no
    canpark=yes
    cancallforward=yes
    callreturn=yes
    context=local
    echocancel=yes
    channel => 1-15,17-31
    echocancelwhenbridged=yes
    group=1
    callgroup=1
    pickupgroup=1
    immediate=no
    #include /etc/asterisk/dahdi-channels.conf

This is the /etc/asterisk/dahdi-channels.conf on pbx-net

; Span 1: WCTDM/4 "Wildcard TDM400P REV E/F Board 5" (MASTER) 
;;; line="1 WCTDM/4/0"
signalling=fxo_ks
callerid="Channel 1" <4001>
mailbox=4001
group=5
context=from-dahdi
channel => 1

;;; line="2 WCTDM/4/1"
signalling=fxo_ks
callerid="Channel 2" <4002>
mailbox=4002
group=5
context=from-dahdi
channel => 2

;;; line="4 WCTDM/4/3"
signalling=fxs_ks
callerid=asreceived
group=0
context=from-dahdi
channel => 4

; Span 2: TE2/0/1 "T2XXP (PCI) Card 0 Span 1" 
group=0,12
context=from-dahdi
switchtype = euroisdn
signalling = pri_net
channel => 5-19,21-35

; Span 3: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" 
group=0,13
context=from-dahdi
switchtype = euroisdn
signalling = pri_net
channel => 36-50,52-66

On the pbx-cpe side, the files are identical except for /etc/dahdi/system.conf (the 1,1,0 is 1: span 1: timing sourcing from pri_net side, 0: cable is 0-133feet)

# Span 1: TE2/0/1 "T2XXP (PCI) Card 0 Span 1" (MASTER) 
span=1,1,0,ccs,hdb3
# termtype: te
bchan=1-15,17-31
dchan=16
echocanceller=mg2,1-15,17-31

# Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" 
span=2,2,0,ccs,hdb3
# termtype: te
bchan=32-46,48-62
dchan=47
echocanceller=mg2,32-46,48-62

# Global data

loadzone        = it
defaultzone     = it

The other two files are identical, except for pri_net which became pri_cpe.

Now the problem:

On pri_cpe bpx the cli report is OK

dahdi show status
    Description                              Alarms  IRQ    bpviol CRC    Fra Codi Options  LBO
    T2XXP (PCI) Card 0 Span 1                OK      0      0      0      CCS HDB3          0 db (CSU)/0-133 feet (DSX-1)

On pri_net bpx the cli report is OK

dahdi show status
Description                              Alarms  IRQ    bpviol CRC    Fra Codi Options  LBO
Wildcard TDM400P REV E/F Board 5         OK      0      0      0      CAS Unk           0 db (CSU)/0-133 feet (DSX-1)
T2XXP (PCI) Card 0 Span 1                OK      0      0      0      CCS HDB3 CRC4     0 db (CSU)/0-133 feet (DSX-1)
T2XXP (PCI) Card 0 Span 2                OK      0      0      0      CCS HDB3 CRC4     0 db (CSU)/0-133 feet (DSX-1)

Also pri span report ok on both sides

net_side

pri show spans
PRI span 2/0: Up, Active

cpe_side

pri show spans
PRI span 1/0: Up, Active

I configured extensions.conf to call via the pri on both sides

[uscita]
exten => _X.,1,Dial(dahdi/g12/${EXTEN})
exten => _X.,n,Hangup

When I try to made a call on both consoles appear those error messages

On pri_net side
[May 1 18:57:50] NOTICE[2541]: chan_dahdi.c:2780 my_handle_dchan_exception: Got DAHDI event: HDLC Bad FCS (8) on D-channel of span 2

On pri_cpe side

[May  1 18:58:07] NOTICE[1489]: chan_dahdi.c:2777 my_handle_dchan_exception: Got DAHDI event: HDLC Abort (6) on D-channel of span 1
[May  1 18:58:07] NOTICE[1489]: chan_dahdi.c:2777 my_handle_dchan_exception: Got DAHDI event: HDLC Abort (6) on D-channel of span 1
[May  1 18:58:07] NOTICE[1489]: chan_dahdi.c:2777 my_handle_dchan_exception: Got DAHDI event: HDLC Abort (6) on D-channel of span 1

again on pri_net side

== Primary D-Channel on span 2 down
[May  1 18:59:32] WARNING[2541]: sig_pri.c:1212 pri_find_dchan: Span 2: D-channel is down!
[May  1 18:59:33] NOTICE[2541]: chan_dahdi.c:2780 my_handle_dchan_exception: Got DAHDI event: HDLC Abort (6) on D-channel of span 2
[May  1 18:59:40] NOTICE[2541]: chan_dahdi.c:2780 my_handle_dchan_exception: Got DAHDI event: HDLC Bad FCS (8) on D-channel of span 2
[May  1 18:59:42] NOTICE[2541]: chan_dahdi.c:2780 my_handle_dchan_exception: Got DAHDI event: HDLC Bad FCS (8) on D-channel of span 2
[May  1 18:59:43] NOTICE[2541]: chan_dahdi.c:2780 my_handle_dchan_exception: Got DAHDI event: HDLC Abort (6) on D-channel of span 2
[May  1 18:59:43] NOTICE[2541]: chan_dahdi.c:2780 my_handle_dchan_exception: Got DAHDI event: HDLC Bad FCS (8) on D-channel of span 2
[May  1 18:59:45] NOTICE[2541]: chan_dahdi.c:2780 my_handle_dchan_exception: Got DAHDI event: HDLC Bad FCS (8) on D-channel of span 2
  == Primary D-Channel on span 2 up
[May  1 18:59:58] NOTICE[2541]: chan_dahdi.c:2780 my_handle_dchan_exception: Got DAHDI event: HDLC Bad FCS (8) on D-channel of span 2
[May  1 18:59:58] NOTICE[2541]: chan_dahdi.c:2780 my_handle_dchan_exception: Got DAHDI event: HDLC Abort (6) on D-channel of span 2
[May  1 18:59:59] NOTICE[2541]: chan_dahdi.c:2780 my_handle_dchan_exception: Got DAHDI event: HDLC Bad FCS (8) on D-channel of span 2
    -- Registered SIP 'telefono3' at 192.168.0.2:59897
  == Using SIP RTP CoS mark 5
    -- Executing [511@local:1] Dial("SIP/telefono3-00000000", "dahdi/g12/511") in new stack
    -- Requested transfer capability: 0x00 - SPEECH
    -- Called dahdi/g12/511
[May  1 19:00:09] NOTICE[2541]: chan_dahdi.c:2780 my_handle_dchan_exception: Got DAHDI event: HDLC Abort (6) on D-channel of span 2
  == Primary D-Channel on span 2 down
[May  1 19:00:10] WARNING[2541]: sig_pri.c:1212 pri_find_dchan: Span 2: D-channel is down!
[May  1 19:00:11] NOTICE[2541]: chan_dahdi.c:2780 my_handle_dchan_exception: Got DAHDI event: HDLC Abort (6) on D-channel of span 2
  == Primary D-Channel on span 2 up
    -- Span 2: Channel 0/1 got hangup, cause 18
    -- Hungup 'DAHDI/i2/511-1'
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing [511@local:2] Hangup("SIP/telefono3-00000000", "") in new stack
  == Spawn extension (local, 511, 2) exited non-zero on 'SIP/telefono3-00000000'
[May  1 19:00:18] NOTICE[2541]: chan_dahdi.c:2780 my_handle_dchan_exception: Got DAHDI event: HDLC Bad FCS (8) on D-channel of span 2
[May  1 19:00:21] NOTICE[2541]: chan_dahdi.c:2780 my_handle_dchan_exception: Got DAHDI event: HDLC Abort (6) on D-channel of span 2

I try those solutions

Solution number 1: the card is broken, I bought another PRI card = FAIL
Solution number 2: change the pci slot of card pri_net side, and / or pri_cpe side = FAIL
Solution number 3: use a different dahdi version = FAIL
Solution number 4: use pridiallocalplan=unknown and pridialplan=unknown = FAIL
Solution number 5: revert pri_net pri_cpe roles = FAIL
Solution number 6: try another crossover cable = FAIL(I try 3 cables, two bought, one made by me, and all tested with network tester)
Solution number 7: reboot = FAIL
Solution number 8: remove the analog card from pci_net server = FAIL

Anyone has some suggestion? Thanks

Best Answer

Solution found. Was the cable bad, I follow this guide on youtube for make the pri cable and works perfect, I had only to reboot the pri_net machine.

Cause Data ? Cause Data!

libpri is not very clever in indicating what the cause data in the Cause information element (IE) means - in fact, as of 1.4.13, it only handles two cases out of a hundred given in Q.850! Thankfully, it's not just some random proprietary diagnostic data.

Referring to Q.850 Usage of cause and location ..., Table 1, we need to check what diagnostics are present for Cause 100 Invalid information element contents. Lo and behold, it's the information element identifier(s)! So, IE 0x18 (24) of the Call Proceeding message sent out by libpri was problematic. As it happens, IE 0x18 is the Channel ID element. So at least we know that the problem is in that particular element. For reference, here's the Cause IE that we received from Cisco:

< [08 03 80 e4 18]
< Cause (len= 5) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: User (0)
<                  Ext: 1  Cause: Invalid information element contents (100), class = Protocol Error (e.g. unknown message) (6) ]
<              Cause data 1: 18 (24)

Channel Identification IE -- To Identify or Not

Now that we've narrowed it down to an IE, Referring to Q.931, 4.5.13 Channel identification [IE], we note that the entire element is optional when responding to a call setup if, as is the case here, the user equipment simply wants to use the sole channel that was explicitly requested by the network (here: Cisco router).

Alas, libpri's internal API for sending the call proceeding message, q931_call_proceeding in q931.c, doesn't really make it easy not to send a complete channel id IE. In fact, libpri's struct q931_call doesn't retain the explicit most recently received channel id so there's no way to decide whether sending out a channel id IE is appropriate or not. Heck, it's an error that call_proceeding_ies[] contains Q931_CHANNEL_IDENT -- the call proceeding message does not always require this IE.

So, one fix would be simply not to send out the channel id.

But What is The Problem Within?

Alas, we may try and dig deeper and check what in the channel id IE did upset the Cisco's firmware.

Let's compare the channel id IE as received from Cisco, and as sent back in reply:

< [18 03 a9 83 81]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit  Other(PRI)  Spare: 0  Exclusive  Dchan: 0
<                       ChanSel: As indicated in following octets
<                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
<                       Ext: 1  Channel: 1 Type: CPE]

> [18 04 e9 81 83 81]
> Channel ID (len= 6) [ Ext: 1  IntID: Explicit  Other(PRI)  Spare: 0  Exclusive  Dchan: 0
>                       ChanSel: As indicated in following octets
>                       Ext: 1  DS1 Identifier: 1  
>                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
>                       Ext: 1  Channel: 1 Type: CPE]

The difference is fairly obvious: libpri replies with an entirely gratuituous DS1 Identifier octet. The DS1 Identifier is an identifier of a particular PRI span to be used on systems that use multiple links. This is not needed here at all since there's only one T1 span between libpri and the Cisco router.

This appears to be a bug in the Cisco firmware -- there's no reason it shouldn't accept the DS1 Identifier -- it's optional, but allowed by the standard. Unless of course the DS1 Identifier is somehow wrong -- I haven't investigated that.

The hack needed to get libpri to play ball is a one-liner in transmit_channel_id. All we need to do is suppress transmission of octet 3.1, the DS1 identifier. This patch does it:

--- libpri-1.4.14/q931.c.org    2013-04-16 15:22:24.910001979 -0400
+++ libpri-1.4.14/q931.c        2013-04-16 15:22:49.454001959 -0400
@@ -1441,7 +1441,7 @@
                return 0;
        }

-       if (!ctrl->bri && (((ctrl->switchtype != PRI_SWITCH_QSIG) && (call->ds1no > 0)) || call->ds1explicit)) {
+       if (0 && !ctrl->bri && (((ctrl->switchtype != PRI_SWITCH_QSIG) && (call->ds1no > 0)) || call->ds1explicit)) {
                /* We are specifying the interface.  Octet 3.1 */
                ie->data[pos++] |= 0x40;
                ie->data[pos++] = 0x80 | call->ds1no;

It should be added that this is by no means a permanent fix meant for inclusion in libpri, just a temporary hack that would require some wider-ranging tweaks to libpri to properly fix.

Best Answer

Related Solutions

Asterisk Connection not working

Cisco – Asterisk can’t make nor receive calls through a T1 PRI interface to a Cisco 2430 router

Cause Data ? Cause Data!

Channel Identification IE -- To Identify or Not

But What is The Problem Within?

Related Topic