Re: CICS stay in pending state

Kaloyan Kovachev <kkovachev@xxxxxxxxx> · Mon, 18 Jan 2021 14:01:11 +0200

Are you sure you have the timers defined for the linkset?

/etc/asterisk/ss7.timers - provides the default values for all of them 

and they need to be defined for each linkset

isup_timer.t22 = 15000
isup_timer.t23 = 300000 ; for ITU
;isup_timer.t23 = 60000 ; for ANSI

The code seems to do what it should:
 https://github.com/asterisk/libss7/blob/master/isup.c#L5423

case ISUP_TIMER_T23:
	isup_stop_timer(param->ss7, param->c, ISUP_TIMER_T22);
	isup_start_timer(param->ss7, param->c, ISUP_TIMER_T23);
	/* no break here */
case ISUP_TIMER_T22:
	if (param->timer != ISUP_TIMER_T23) {
		isup_start_timer(param->ss7, param->c, ISUP_TIMER_T22);
	}
	param->c->range = param->c->sent_grs_endcic - param->c->cic;
	isup_send_message(param->ss7, param->c, ISUP_GRS, greset_params);
	break;

Please note the 'no break here' comment - the GRS is sent from the next 

case, so if you have the timer defined GRS will be sent every 5 minutes 

for ITU and every minute for ANSI with the default values

На 2021-01-17 23:01, Marcelo Pacheco написа:

Here's one scenario this happens:
asterisk talks to an STP
asterisk comes up and the STP can't reach the other ISUP side
asterisk sends GRS messages
no response comes

the first CIC of each GRS message now has a pending call (the GRS 

message)

since the GRA will never come and asterisk won't automatically 

retransmit that message, those trunks stay pending

The workarounds are to restart dahdi when connectivity to the other 

ISUP side is up

or use SS7 RESET GROUP linkset dpc cic range

Other switches will send GRS forever, until they get a response. See 

ISUP timers T22 and T23.

Em ter., 31 de jul. de 2018 às 07:08, Kaloyan Kovachev 

<kkovachev@xxxxxxxxx> escreveu:

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

--
_____________________________________________________________________
-- 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