<div dir="ltr"><div>Thanks. It does work.</div><div>I saw the timers in the code and assumed that the timers assumed their ITU defaults instead of being disabled by omission and were buggy.</div><div><br></div><div>Anyhow, I'm running a highly, highly modified libss7-2.0.0 with all kinds of modifications, it supports M2PA instead of TDM MTP2.</div><div>Its working with an STP I developed the test switch a Khomp (<a href="http://www.khomp.com.br">www.khomp.com.br</a>) KMG400.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em seg., 18 de jan. de 2021 às 09:01, Kaloyan Kovachev <<a href="mailto:kkovachev@varna.net">kkovachev@varna.net</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Are you sure you have the timers defined for the linkset?<br>
<br>
/etc/asterisk/ss7.timers - provides the default values for all of them <br>
and they need to be defined for each linkset<br>
isup_timer.t22 = 15000<br>
isup_timer.t23 = 300000 ; for ITU<br>
;isup_timer.t23 = 60000 ; for ANSI<br>
<br>
The code seems to do what it should:<br>
  <a href="https://github.com/asterisk/libss7/blob/master/isup.c#L5423" rel="noreferrer" target="_blank">https://github.com/asterisk/libss7/blob/master/isup.c#L5423</a><br>
<br>
case ISUP_TIMER_T23:<br>
        isup_stop_timer(param->ss7, param->c, ISUP_TIMER_T22);<br>
        isup_start_timer(param->ss7, param->c, ISUP_TIMER_T23);<br>
        /* no break here */<br>
case ISUP_TIMER_T22:<br>
        if (param->timer != ISUP_TIMER_T23) {<br>
                isup_start_timer(param->ss7, param->c, ISUP_TIMER_T22);<br>
        }<br>
        param->c->range = param->c->sent_grs_endcic - param->c->cic;<br>
        isup_send_message(param->ss7, param->c, ISUP_GRS, greset_params);<br>
        break;<br>
<br>
Please note the 'no break here' comment - the GRS is sent from the next <br>
case, so if you have the timer defined GRS will be sent every 5 minutes <br>
for ITU and every minute for ANSI with the default values<br>
<br>
<br>
На 2021-01-17 23:01, Marcelo Pacheco написа:<br>
<br>
> Here's one scenario this happens:<br>
> asterisk talks to an STP<br>
> asterisk comes up and the STP can't reach the other ISUP side<br>
> asterisk sends GRS messages<br>
> no response comes<br>
> the first CIC of each GRS message now has a pending call (the GRS <br>
> message)<br>
> since the GRA will never come and asterisk won't automatically <br>
> retransmit that message, those trunks stay pending<br>
> The workarounds are to restart dahdi when connectivity to the other <br>
> ISUP side is up<br>
> or use SS7 RESET GROUP linkset dpc cic range<br>
> <br>
> Other switches will send GRS forever, until they get a response. See <br>
> ISUP timers T22 and T23.<br>
> <br>
> Em ter., 31 de jul. de 2018 às 07:08, Kaloyan Kovachev <br>
> <<a href="mailto:kkovachev@varna.net" target="_blank">kkovachev@varna.net</a>> escreveu:<br>
> <br>
>> Hi,<br>
>> please check if you have all the timers defined for both linksets more<br>
>> specificaly ISUP timers T16 and T17<br>
>> <br>
>> The proper functioning of libss7 depends on the timers and they need <br>
>> to<br>
>> be defined for _each_ linkset. To avoid mistakes you may configure the<br>
>> timers in a separate file (use ss7.timers from the samples) and just<br>
>> #include it for each linkset<br>
>> <br>
>> I am running libss2 with Asterisk 11 and 13 for several years now<br>
>> without any problems and CICs in pending state.<br>
>> <br>
>> На 2018-07-31 07:18, Dovid B написа:<br>
>> <br>
>>> Marcelo,<br>
>>> <br>
>>> Sorry for the delayed response. I wrote a script as well. For some<br>
>>> reason for CIC's 2 and 33 on one link and CIC 2 on the other when I<br>
>>> send the RSC, if I use dahdi_pcap it shows Asterisk sending the RSC <br>
>>> and<br>
>>> getting a response however in Asterisk when I have ss7 debug on for <br>
>>> the<br>
>>> linkset it shows Asterisk sending the RSC out but not getting a<br>
>>> response and the CIC('s) remain in PENDING which is making issues for<br>
>>> the remote side.<br>
>>> <br>
>>> Anyone interested in fixing this for a bounty?<br>
>>> <br>
>>> FROM: <a href="mailto:asterisk-ss7-bounces@lists.digium.com" target="_blank">asterisk-ss7-bounces@lists.digium.com</a><br>
>>> [mailto:<a href="mailto:asterisk-ss7-bounces@lists.digium.com" target="_blank">asterisk-ss7-bounces@lists.digium.com</a>] ON BEHALF OF Marcelo<br>
>>> Pacheco<br>
>>> SENT: Tuesday, February 20, 2018 16:16<br>
>>> TO: <a href="mailto:asterisk-ss7@lists.digium.com" target="_blank">asterisk-ss7@lists.digium.com</a><br>
>>> SUBJECT: Re: [asterisk-ss7] CICS stay in pending state<br>
>>> <br>
>>> For me it happens every time. It is fixed by sending/receiving an RSC<br>
>>> for the affected CICs.<br>
>>> <br>
>>> It seems to me this just isn't an important bug to fix (haven't<br>
>>> bothered anybody with the expertise to understand/fix it).<br>
>>> <br>
>>> Due to this and a few other issues, I'm not currently running this<br>
>>> version.<br>
>>> <br>
>>> 2018-02-20 11:29 GMT-03:00 Dovid Bender <<a href="mailto:dovid@telecurve.com" target="_blank">dovid@telecurve.com</a>>:<br>
>>> <br>
>>> Marcelo,<br>
>>> <br>
>>> That happens some times. Other times the entire second link wont work<br>
>>> and I need to reset them. Most of time I am able to issue a reset and<br>
>>> Asterisk free's up the CIC but on my first box it wont release the<br>
>>> first CIC. On my second box the first CIC on each link is still<br>
>>> pending. Seems like I am running into the same issue that you had. <br>
>>> From<br>
>>> what I understand there were a lot of improvements in lib libss7 2 <br>
>>> and<br>
>>> I am willing to sacrifice two CIC's. I would rather get the bug fixed<br>
>>> if I could but I don't know where to start.<br>
>>> <br>
>>> On Mon, Feb 19, 2018 at 7:02 PM, Marcelo Pacheco <<a href="mailto:marcelo@m2j.com.br" target="_blank">marcelo@m2j.com.br</a>><br>
>>> wrote:<br>
>>> <br>
>>> I detect a bug in the latest libss7 where for each group reset <br>
>>> message,<br>
>>> the first CIC of each range doesn't get processed (staying pending),<br>
>>> but every other CIC does. Can you confirm that's what you see. For<br>
>>> instance if its a full E1, the first channel of the E1 stays pending.<br>
>>> For an E1 with a signalling link and CIC 16 skipped, channel 1 and<br>
>>> channel 17 of the E1 stays pending.<br>
>>> <br>
>>> I fixed by returning an old and trusted highly patched personal <br>
>>> libss7<br>
>>> 1.0.0+and old asterisk (I cringe to have to use it, but its rock<br>
>>> solid).<br>
>>> <br>
>>> 2018-02-19 0:56 GMT-03:00 Dovid Bender <<a href="mailto:dovid@telecurve.com" target="_blank">dovid@telecurve.com</a>>:<br>
>>> <br>
>>>> Hi,<br>
>>>> <br>
>>>> We have an issue where some CICs stay in pending and wont go into<br>
>>>> Idle. If we do a block the other side see's it. The same goes for an<br>
>>>> unblock. For some reason no matter what we do certain cic's (it <br>
>>>> seems<br>
>>>> to be random) will stay in pending while the remote side see's them <br>
>>>> as<br>
>>>> Idle. Some times a reset will free it up, other times it wont. When<br>
>>>> doing a reset the other side responds that the cic has been reset <br>
>>>> yet<br>
>>>> Asterisk wont free it up. Any idea whats going on?<br>
>>>> <br>
>>>> [root@ast01 asterisk]# asterisk -rx'ss7 show cics 1' | grep Pending<br>
>>>> <br>
>>>> 2   518      2      Pending<br>
>>>> <br>
>>>> [root@ast01 asterisk]#<br>
>>>> <br>
>>>> st01*CLI> ss7 reset cic 1 518 2<br>
>>>> <br>
>>>> Sent RSC for linkset 1 on CIC 2 DPC 518<br>
>>>> <br>
>>>> [1] Len = 11 [ fe ac 08 85 06 c2 98 20 02 00 12 ]<br>
>>>> <br>
>>>> [1] FSN: 44 FIB 1<br>
>>>> <br>
>>>> [1] BSN: 126 BIB 1<br>
>>>> <br>
>>>> [1] >[520:0] MSU<br>
>>>> <br>
>>>> [1] [ fe ac 08 ]<br>
>>>> <br>
>>>> [1]     Network Indicator: 2 Priority: 0 User Part: ISUP (5)<br>
>>>> <br>
>>>> [1]     [ 85 ]<br>
>>>> <br>
>>>> [1]     OPC 611 DPC 518 SLS 2<br>
>>>> <br>
>>>> [1]     [ 06 c2 98 20 ]<br>
>>>> <br>
>>>> [1]             CIC: 2<br>
>>>> <br>
>>>> [1]             [ 02 00 ]<br>
>>>> <br>
>>>> [1]             Message Type: RSC(0x12)<br>
>>>> <br>
>>>> [1]             [ 12 ]<br>
>>>> <br>
>>>> [1]<br>
>>>> <br>
>>>> [1] Len = 12 [ ac ff 09 85 63 82 81 20 02 00 10 00 ]<br>
>>>> <br>
>>>> [1] FSN: 127 FIB 1<br>
>>>> <br>
>>>> [1] BSN: 44 BIB 1<br>
>>>> <br>
>>>> [1] <[520:0] MSU<br>
>>>> <br>
>>>> [1] [ ac ff 09 ]<br>
>>>> <br>
>>>> [1]     Network Indicator: 2 Priority: 0 User Part: ISUP (5)<br>
>>>> <br>
>>>> [1]     [ 85 ]<br>
>>>> <br>
>>>> [1]     OPC 518 DPC 611 SLS 2<br>
>>>> <br>
>>>> [1]     [ 63 82 81 20 ]<br>
>>>> <br>
>>>> [1]             CIC: 2<br>
>>>> <br>
>>>> [1]             [ 02 00 ]<br>
>>>> <br>
>>>> [1]             Message Type: RLC(0x10)<br>
>>>> <br>
>>>> [1]             [ 10 ]<br>
>>>> <br>
>>>> [1]<br>
>>>> <br>
>>>> Linkset 1: Processing event: ISUP_EVENT_RLC<br>
>>>> <br>
>>>> ast01*CLI><br>
>>>> <br>
>>>> ast01*CLI><br>
>>>> <br>
>>>> ast01*CLI> quit<br>
>>>> <br>
>>>> Asterisk cleanly ending (0).<br>
>>>> <br>
>>>> Executing last minute cleanups<br>
>>>> <br>
>>>> [root@ast01 asterisk]# asterisk -rx'ss7 show cics 1' | grep Pending<br>
>>>> <br>
>>>> 2   518      2      Pending<br>
>>>> <br>
>>>> [root@ast01 asterisk]#<br>
>>>> <br>
>>>> TIA.<br>
>>>> <br>
>>>> Dovid<br>
>>>> <br>
>>>> --<br>
>>>> _____________________________________________________________________<br>
>>>> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> <br>
>>>> --<br>
>>>> <br>
>>>> asterisk-ss7 mailing list<br>
>>>> To UNSUBSCRIBE or update options visit:<br>
>>>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-ss7" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-ss7</a><br>
>>> <br>
>>> --<br>
>>> _____________________________________________________________________<br>
>>> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
>>> <br>
>>> asterisk-ss7 mailing list<br>
>>> To UNSUBSCRIBE or update options visit:<br>
>>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-ss7" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-ss7</a><br>
>>> <br>
>>> --<br>
>>> _____________________________________________________________________<br>
>>> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
>>> <br>
>>> asterisk-ss7 mailing list<br>
>>> To UNSUBSCRIBE or update options visit:<br>
>>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-ss7" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-ss7</a><br>
>> <br>
>> --<br>
>> _____________________________________________________________________<br>
>> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
>> <br>
>> asterisk-ss7 mailing list<br>
>> To UNSUBSCRIBE or update options visit:<br>
>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-ss7" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-ss7</a><br>
</blockquote></div>