Thanks. It does work. 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.
Anyhow, I'm running a highly, highly modified libss7-2.0.0 with all kinds of modifications, it supports M2PA instead of TDM MTP2. Its working with an STP I developed the test switch a Khomp ( www.khomp.com.br) KMG400. Em seg., 18 de jan. de 2021 às 09:01, Kaloyan Kovachev <kkovac...@varna.net> escreveu: > 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 > > <kkovac...@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-boun...@lists.digium.com > >>> [mailto:asterisk-ss7-boun...@lists.digium.com] ON BEHALF OF Marcelo > >>> Pacheco > >>> SENT: Tuesday, February 20, 2018 16:16 > >>> TO: asterisk-ss7@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 <do...@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 <marc...@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 <do...@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@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
