[asterisk-ss7] Help aligning 8 SS7 E1s with our Telco

Tue Jan 25 06:47:21 CST 2011

Hi,

We need assistance aligning 8 E1 ports (2x Digium Quad Span TE410P) with our
TELCO.

We are working on a relatively big SS7 deployment for some time now. We are
using:

 asterisk-1.8.2.1
asterisk-addons-1.6.2.
dahdi-linux-complete-2.4.0+2.4.0
libss7-1.0.2

So far, we think that we should start sending and receiving SIO messages to
establish a layer 2 connection.

We currently have just two E1 ports connected to our TELCO. Layer 1 looks
good so far. We have both cards OK and neither the TELCO nor our server
report any alarms.

T4XXP (PCI) Card 1 Span 1                OK      0      0      0      CCS
HDB3          0 db (CSU)/0-133 feet (DSX-1)
T4XXP (PCI) Card 1 Span 2                OK      0      0      0      CCS
HDB3          0 db (CSU)/0-133 feet (DSX-1)

We are having problems to pass by the NOTALIGNED STATE.

The carrier asked us to configure the last channel as the D channel on both
spans (31, or 155 and 186 in our case).

Here is an extract of "lsdahdi"

### Span  5: TE4/1/1 "T4XXP (PCI) Card 1 Span 1" (MASTER) HDB3/CCS
...
155 PRI        MTP2        (In use) (SWEC: MG2)

### Span  6: TE4/1/2 "T4XXP (PCI) Card 1 Span 2" HDB3/CCS
186 PRI        MTP2        (In use) (SWEC: MG2)

We can see upon load of the chan_dahdi.so the modules get loaded and the
channels are registered as SS7 signaling.

    -- Registered channel 125, SS7 signalling
    -- Registered channel 125, SS7 signalling
    -- Registered channel 126, SS7 signalling
 We run a ss7 set debug on linktest 1 and we see SIO messages going out ( at
least I see > ) If this angle bracket doesn´t mean "out" please someone
correct me.
 We don´t seem to have any SIO back, so we get stuck at this point where the
T2 timer expires we go back to IDLE.
 {1] Link state change: IDLE -> NOTALIGNED
[1] Link state change: NOTALIGNED -> IDLE
[1] Link state change: IDLE -> NOTALIGNED
[1] Link state change: NOTALIGNED -> IDLE
[1] Link state change: IDLE -> NOTALIGNED
[1] Len = 4 [ ff ff 01 00 ]
[1] FSN: 127 FIB 1
[1] BSN: 127 BIB 1
[1] >[0] LSSU SIO
[1]
[1] Len = 4 [ ff ff 01 00 ]
[1] FSN: 127 FIB 1
[1] BSN: 127 BIB 1
[1] >[1] LSSU SIO
[1]
[1] Link state change: NOTALIGNED -> IDLE
[1] Link state change: IDLE -> NOTALIGNED
[1] Link state change: NOTALIGNED -> IDLE
[1] Link state change: IDLE -> NOTALIGNED

Compiling dahdi_pcap helped us a lot. Can some one please confirm from the 2
packet captures below, if the SIO and SIOS messages are incoming, as I see
from the "Point-to-Point Direction: Received (1)"  lines?:

No.     Time        Source                Destination           Protocol
Info
      2 0.536890                                                MTP2     SIO

Frame 2 (6 bytes on wire, 6 bytes captured)
    Arrival Time: Jan 24, 2011 17:48:55.106277000
    [Time delta from previous captured frame: 0.536890000 seconds]
    [Time delta from previous displayed frame: 0.536890000 seconds]
    [Time since reference or first frame: 0.536890000 seconds]
    Frame Number: 2
    Frame Length: 6 bytes
    Capture Length: 6 bytes
    [Frame is marked: False]
    [Protocols in frame: mtp2]
    Point-to-Point Direction: Received (1)
    Link Number: 155
Message Transfer Part Level 2
    .111 1111 = Backward sequence number: 127
    1... .... = Backward indicator bit: 1
    .111 1111 = Forward sequence number: 127
    1... .... = Forward indicator bit: 1
    ..00 0001 = Length Indicator: 1
    00.. .... = Spare: 0
    Status field: Status Indication O (0)

No.     Time        Source                Destination           Protocol
Info
      3 33.532990                                               MTP2
SIOS

Frame 3 (6 bytes on wire, 6 bytes captured)
    Arrival Time: Jan 24, 2011 17:49:28.102377000
    [Time delta from previous captured frame: 32.996100000 seconds]
    [Time delta from previous displayed frame: 32.996100000 seconds]
    [Time since reference or first frame: 33.532990000 seconds]
    Frame Number: 3
    Frame Length: 6 bytes
    Capture Length: 6 bytes
    [Frame is marked: False]
    [Protocols in frame: mtp2]
    Point-to-Point Direction: Received (1)
    Link Number: 155
Message Transfer Part Level 2
    .111 1111 = Backward sequence number: 127
    1... .... = Backward indicator bit: 1
    .111 1111 = Forward sequence number: 127
    1... .... = Forward indicator bit: 1
    ..00 0001 = Length Indicator: 1
    00.. .... = Spare: 0
    Status field: Status Indication OS (3)

These are some debug lines:
[Jan 24 22:42:18] ERROR[1528]: chan_dahdi.c:13534 dahdi_ss7_error: [1]
Received MSU in invalid state 1
[Jan 24 22:42:18] ERROR[1528]: chan_dahdi.c:13534 dahdi_ss7_error: [1]
Received MSU in invalid state 1
con hardhdlc
[Jan 24 23:09:26] ERROR[1283]: chan_dahdi.c:13534 dahdi_ss7_error: [1]
Received MSU in invalid state 1
[1] Got message smaller than the minimum SS7 SU length. Dropping
[Jan 24 23:09:26] NOTICE[1283]: chan_dahdi.c:3310 my_handle_link_exception:
SS7 got event: HDLC Overrun(7) on span 1/1
[Jan 24 23:09:26] NOTICE[1283]: chan_dahdi.c:3310 my_handle_link_exception:
SS7 got event: HDLC Overrun(7) on span 1/0
[Jan 24 23:09:26] NOTICE[1283]: chan_dahdi.c:3310 my_handle_link_exception:
SS7 got event: HDLC Overrun(7) on span 1/1
[Jan 24 23:09:26] NOTICE[1283]: chan_dahdi.c:3310 my_handle_link_exception:
SS7 got event: HDLC Bad FCS(8) on span 1/0
[Jan 24 23:09:26] NOTICE[1283]: chan_dahdi.c:3310 my_handle_link_exception:
SS7 got event: HDLC Overrun(7) on span 1/1
[1] Got message smaller than the minimum SS7 SU length. Dropping

Attached you will find system.conf, chan_dahdi.conf and dahdi_channels.conf,
please if you have any insights what can be going on on these regards, what
can we change, or what can be logged for further analysis, it would be very
much appreciated.

Also, can somebody explain what these messages in /var/log/messages mean?

Jan 23 09:23:39 ss7-core kernel: [202529.404359] wct4xxp 0000:03:01.0: All
spans in alarm : No validspan to source RCLK from

And this from /var/log/asterisk?:

[Jan 24 14:26:29] NOTICE[1170] chan_dahdi.c: SS7 got event: HDLC Abort(6) on
span 1/0
[Jan 24 15:55:30] NOTICE[1170] chan_dahdi.c: SS7 got event: HDLC Abort(6) on
span 1/1

Thank you very much in advance,

-- 
*José Pablo Méndez
     *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20110125/3a57824a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chan_dahdi.conf
Type: application/octet-stream
Size: 288 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20110125/3a57824a/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dahdi_channels.conf
Type: application/octet-stream
Size: 2064 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20110125/3a57824a/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: system.conf
Type: application/octet-stream
Size: 1564 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20110125/3a57824a/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ss7dump.pcap
Type: application/cap
Size: 284 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20110125/3a57824a/attachment-0001.pcap>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ss7dump2.7z
Type: application/octet-stream
Size: 442 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20110125/3a57824a/attachment-0007.obj>