[asterisk-ss7] Another serious libss7 bug, that won't affect everyone but will be trouble if it does affect you.

[Marcelo Pacheco]

I had a signalling link go down without an alarm on the span, the
signalling link in question shares the E1 with the defaultdpc switch,
the alarm was between the defaultdpc switch and the STP from the other side.
Due to custom changes I made to libss7, the dead link was detected.
The link has no redundancy, so the linkset was down.
But, when an outgoing IAM for the linkset came up, libss7 still tries to
deliver it, and leaves an open call for that IAM.
So not until all channels of the linkset are left with a dead open call,
IAMs are still attempted, hanging the user calls until timeout.
So the alternate route can't be used, in this case, until 30 outgoing
calls happened, leaving 30 frustated users. The alternate route uses
another linkset.

Same happens if asterisk starts and none of the ss7 links align, it
still keeps trying those calls.

An alarm should actually be ignored for this, only the status of the
MTP2 links should be used to determine if the linkset is up or down.



Bug 2, when the link with 30 dead calls come back up, libss7 now thinks
all channels are busy, it doesn't reset the whole linkset, completely
depending on the other side sending an incoming GRS to clear the whole
mess up.


For all of you that only care about revenue but not about quality, not a
big deal.
I have switches with a half a dozen linksets, including STP only
linksets, used to relay SS7 traffic to remote switches.
This will grow to over 20 linksets in the future.

Can't simply restart dahdi or asterisks, other linksets have dozens of
active calls.

libss7 was written properly with the information mattf had, and the guys
testing it only cared about simplistic scenarios.

Definitely not carrier class anything.



Long term, not a problem for me, I'll fix that, for myself.
But if you intend on doing really serious stuff with libss7, good luck,
it's not designed for that.

Just a sample of the now almost 20 issues I found, perhaps now I have
only 5 unfixed issues.

-- 
Atenciosamente,

Marcelo Pacheco
M2J Comunicações e Informática
Fixo: (27)2222-8118 / (27)2233-2296
Vivo: (27)9964-5440
Claro: (27)9312-5319
MSN: marcelo at macp.eti.br
E-mail: marcelo at m2j.com.br