[asterisk-ss7] CICS stay in pending state
Kaloyan Kovachev
kkovachev at varna.net
Mon Jan 18 06:01:11 CST 2021
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 at varna.net> 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 at lists.digium.com
>>> [mailto:asterisk-ss7-bounces at lists.digium.com] ON BEHALF OF Marcelo
>>> Pacheco
>>> SENT: Tuesday, February 20, 2018 16:16
>>> TO: asterisk-ss7 at lists.digium.com
>>> SUBJECT: Re: [asterisk-ss7] 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 at telecurve.com>:
>>>
>>> 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 at m2j.com.br>
>>> 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 at telecurve.com>:
>>>
>>>> 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 at ast01 asterisk]# asterisk -rx'ss7 show cics 1' | grep Pending
>>>>
>>>> 2 518 2 Pending
>>>>
>>>> [root at 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 at ast01 asterisk]# asterisk -rx'ss7 show cics 1' | grep Pending
>>>>
>>>> 2 518 2 Pending
>>>>
>>>> [root at 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
More information about the asterisk-ss7
mailing list