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
|