Monitoring Links stop receiving data


Developer Group

Developer Group
Connect with thousands of other developers to brainstorm ideas, share best practices and tips - or just chat about the latest emerging technologies making noise in the field. And of course, get the most up-to-date service and support news from Dialogic.
Dialogic SS7 and SIGTRAN Signalling

Monitoring Links stop receiving data

  • We are facing a strange behavior while monitoring SS7 links using 2 Septel 4 PCI boards. When we start gctload everything works fine. After a while (15 to 20 minutes) we no longer receive traffic from certain monitoring links (and no errors appear regarding them) and we end up with data coming from 2 monitoring links out of 12. we checked all wiring even we replaced the complete wiring and still the issue occurs. All connections are twisted pair terminated on RJ45. Once we restart gctload we recevie traffic on all links.

    We are sure there are no pending messages using gctload -t1.

    Any suggestions or ideas are highly appreciated.

  • Could you post the screen output you get from the gctload -t1 command? Have you also run the gtcload -t2 command and could you post that screen capture as well?
  • 1) What is the output of the  gctload -t1 , gctload -t2  , What is the GCT_LIB version ?

    2) If (1) is showing not issue ,  What is the NUM_MSGS configured , maximum allocated ? Congestion counters, if the NUM_MSGS is below 600 , try to increase this to 10000 only for testing


    3) If the traffic is sent to your links via a concentrator/MUX , and always the same links get no traffic , check with the concentrator , also I faced similiar problem due to bad BNC quality and poorly fitted inners , but this was always showing BER before stopping or bad impendance matching ,check that  from those links using K15 PA  

    4) If you have no BER errors before the problem , try to change the PCI slot of the card


  • Wisam,

    The situation you describe seems strange. Could you post the config.txt so that the distribution of links across the two boards is clear?

    It would be useful to understand which links you stop receiving traffic for and whether these are always the same links?

  • config.txt
    Tim, Khalid, Paul,

    Thanks for your replies.

    We noticed that we recevie board reset failure message

    SSD_MSG_STATE_IND (0x06a0) with status 0x62 - Board failure. All links on that board then fail.

    It seems the board fails after a while. We will try to switch the E1s on the 2 boards to see if the second board fails under load or it is an issue related to the first board.

    Other thoughts is to change the switch on the board.

    We need your feedback Paul, shall we expect a hardware failure that need to replace the card?

    Cards are installed on the first 2 PCI slots, we tried other setups before but one the cards failed to start.

    Always the same links fail on board 0.

    Links are taken direclty not thoruhg mux.

    gctload -t1 is normal as below, gctload -t2 showed nothing, attached the config file.

    GCTLOAD System status:

    MSGs in system: 600

    MSGs allocated: 0

    MSGs free: 600

    Maximum MSGs allocated: 26

    Out of MSG count: 0

    Congestion module Id: 0x21

    Congestion onset: 300

    Congestion abate: 60

    Congestion status: 0

    Congestion count: 0

    GCTLIB library: V1.22

  • Hi,

    do you have other hardware (boards) installed in this system?

    It is unlikely that you are overloading the board. It should comfortably handle more than 500MSUs (with some headroom) across the links being monitored. That said, it would be useful to understand the behaviour if you swap links to the other board.

  • Hello Paul,

    We tried the follwoing and still with the same results:

    - We moved the links to the second board. Still the first board fails

    - We removed all borads other than the septel boards.

    - We changed the phyisical installation. Board 0 failed.

    - We will try to install one board only and do the test again. and we will work on a workaround to capture the reset failure message and restart gctload.

    The boards are installed on HP ML350 G5 server running windows 2003 enterprise R2.

    Any suggestions will be welcomed and I will keep you updated with results.

  • Hi i am also facing a similar problem in an IVR setup using SS7 signalling. After about an hour the host does not reply back with ACM for an IAM recieved.

    Pls suggest what can be the issue.
  • Hi,

    We removed one of the cards and still the problem occures. We implmented the workaround to restart gctload once we receive the reset failure message. We faced another issue that sometimes the links stop receving data without receving the failure message.

    Could this be realted to voltage levels on the PCI solts?

  • Hi,

    I have not seen any issue related to power rails over the life of this product. The SPCI card has been in the field for many years.

    On the SPCI card there is a rotary switch marked BOOT. Could you confirm the results of setting this to position 8?

    I would not expect this to impact a monitoring based solution though it has had an impact in a small number of voice based solutions which I believe relates to the way buss mastering is handled in some BIOS implementations.

  • Hello Paul,

    I mentioned the voltage issue because we faced hardware issues with HP G5 servers. The 5.V voltage under load sometimes dorp to lower than 4.7 V. This happened with us while using other hardware.

    We will try the boot switch and will keep you updated.

  • Hi,

    it is unlikely that the boot switch will help here but please go ahead and confirm.

    The feedback on the power rails is useful. I will check with our hardware team whether they believe that would impact the board though it seems unlikely it would impact only one board in a two board system.

  • Hello Paul,

    Good news.

    We tried the boot switch on the board 0 and it didn't fail for 14 hours but the second board failed. we chaned it on both to 8 and till now they are running without issues (20 hours).

    We will keep monitoring and we hope it will continue working without issues.


  • pls share config.txt and system.txt