[asterisk-ss7] CICS stay in pending state
Marcelo Pacheco
marcelo at m2j.com.br
Mon Jan 18 08:03:34 CST 2021
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 <kkovachev at 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
> > <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20210118/1ca0d897/attachment.html>
More information about the asterisk-ss7
mailing list