Re: CICS stay in pending state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,
please check if you have all the timers defined for both linksets more specificaly ISUP timers T16 and T17

The proper functioning of libss7 depends on the timers and they need to be defined for _each_ linkset. To avoid mistakes you may configure the timers in a separate file (use ss7.timers from the samples) and just #include it for each linkset

I am running libss2 with Asterisk 11 and 13 for several years now without any problems and CICs in pending state.

На 2018-07-31 07:18, Dovid B написа:

Marcelo,

Sorry for the delayed response. I wrote a script as well. For some reason for CIC's 2 and 33 on one link and CIC 2 on the other when I send the RSC, if I use dahdi_pcap it shows Asterisk sending the RSC and getting a response however in Asterisk when I have ss7 debug on for the linkset it shows Asterisk sending the RSC out but not getting a response and the CIC('s) remain in PENDING which is making issues for the remote side.

Anyone interested in fixing this for a bounty?

FROM: asterisk-ss7-bounces@xxxxxxxxxxxxxxxx [mailto:asterisk-ss7-bounces@xxxxxxxxxxxxxxxx] ON BEHALF OF Marcelo Pacheco
SENT: Tuesday, February 20, 2018 16:16
TO: asterisk-ss7@xxxxxxxxxxxxxxxx
SUBJECT: Re:  CICS stay in pending state

For me it happens every time. It is fixed by sending/receiving an RSC for the affected CICs.

It seems to me this just isn't an important bug to fix (haven't bothered anybody with the expertise to understand/fix it).

Due to this and a few other issues, I'm not currently running this version.

2018-02-20 11:29 GMT-03:00 Dovid Bender <dovid@xxxxxxxxxxxxx>:

Marcelo,

That happens some times. Other times the entire second link wont work and I need to reset them. Most of time I am able to issue a reset and Asterisk free's up the CIC but on my first box it wont release the first CIC. On my second box the first CIC on each link is still pending. Seems like I am running into the same issue that you had. From what I understand there were a lot of improvements in lib libss7 2 and I am willing to sacrifice two CIC's. I would rather get the bug fixed if I could but I don't know where to start.

On Mon, Feb 19, 2018 at 7:02 PM, Marcelo Pacheco <marcelo@xxxxxxxxxx> wrote:

I detect a bug in the latest libss7 where for each group reset message, the first CIC of each range doesn't get processed (staying pending), but every other CIC does. Can you confirm that's what you see. For instance if its a full E1, the first channel of the E1 stays pending. For an E1 with a signalling link and CIC 16 skipped, channel 1 and channel 17 of the E1 stays pending.

I fixed by returning an old and trusted highly patched personal libss7 1.0.0+and old asterisk (I cringe to have to use it, but its rock solid).

2018-02-19 0:56 GMT-03:00 Dovid Bender <dovid@xxxxxxxxxxxxx>:

Hi,

We have an issue where some CICs stay in pending and wont go into Idle. If we do a block the other side see's it. The same goes for an unblock. For some reason no matter what we do certain cic's (it seems to be random) will stay in pending while the remote side see's them as Idle. Some times a reset will free it up, other times it wont. When doing a reset the other side responds that the cic has been reset yet Asterisk wont free it up. Any idea whats going on?

[root@ast01 asterisk]# asterisk -rx'ss7 show cics 1' | grep Pending

2   518      2      Pending

[root@ast01 asterisk]#

st01*CLI> ss7 reset cic 1 518 2

Sent RSC for linkset 1 on CIC 2 DPC 518

[1] Len = 11 [ fe ac 08 85 06 c2 98 20 02 00 12 ]

[1] FSN: 44 FIB 1

[1] BSN: 126 BIB 1

[1] >[520:0] MSU

[1] [ fe ac 08 ]

[1]     Network Indicator: 2 Priority: 0 User Part: ISUP (5)

[1]     [ 85 ]

[1]     OPC 611 DPC 518 SLS 2

[1]     [ 06 c2 98 20 ]

[1]             CIC: 2

[1]             [ 02 00 ]

[1]             Message Type: RSC(0x12)

[1]             [ 12 ]

[1]

[1] Len = 12 [ ac ff 09 85 63 82 81 20 02 00 10 00 ]

[1] FSN: 127 FIB 1

[1] BSN: 44 BIB 1

[1] <[520:0] MSU

[1] [ ac ff 09 ]

[1]     Network Indicator: 2 Priority: 0 User Part: ISUP (5)

[1]     [ 85 ]

[1]     OPC 518 DPC 611 SLS 2

[1]     [ 63 82 81 20 ]

[1]             CIC: 2

[1]             [ 02 00 ]

[1]             Message Type: RLC(0x10)

[1]             [ 10 ]

[1]

Linkset 1: Processing event: ISUP_EVENT_RLC

ast01*CLI>

ast01*CLI>

ast01*CLI> quit

Asterisk cleanly ending (0).

Executing last minute cleanups

[root@ast01 asterisk]# asterisk -rx'ss7 show cics 1' | grep Pending

2   518      2      Pending

[root@ast01 asterisk]#

TIA.

Dovid

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-ss7

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-ss7

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-ss7

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-ss7




[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite Backpacking]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux