[asterisk-ss7] chan_ss7 or libss7 work with asterisk v13?

[Gustavo Marsico]

Hi Marcelo

Sounds weird, I’ve several links on unstable networks going thru STPs (going thru NUC’s on several switches) and we didn’t see the problems you describe.
Also, with Attila’s patches provides information when a linkset is OOS, and channels after a MTP2 recover is just clean.
libss7 2.0 (a Kaloyan’s tremendous work of Attila’s patches) there's nothing to do with the old 1.0.
Actually, I’ve seen the last week a remote issue with a cuasi-associated SPC, we receive TFP and the box removed the internal route so the subscribers took the 2nd route with any particular issue. When a TFA was received libss7 added the internal route again, and the traffic restarted properly. I’m running 13.5.0 with libss7-2.0.0 (with a small patch present on the wiki site). 
Sure, is not perfect, but it’s better than nothing and it fits on most of installations. I’ve several boxes and some of them has 16 E1 with 1.4 millions calls/month, and the issues we got are not related with SS7.

Regards

Gustavo

> On Apr 20, 2016, at 11:58 AM, Marcelo Pacheco <marcelo at m2j.com.br> wrote:
> 
> It might work just fine if your TDM switch is just a cross over direct cable connection.
> But if you have a link that goes through a pair of STPs, each 1000 miles away, in transmission routes that go down and up, without an ALARM, because there's a semi permanent connection behind the TDM switch.
> 
> Asterisk <-> local transmission <-> TDM switch <-> long distance transmission for the signalling links <-> STP
> 
> In other scenarios, even with stable STP connections there are problems.
> I have posted those problems here 3 years ago. Nobody was interested in doing anything about them.
> 
> 
> Perhaps its a ITU only problem. Anyhow, good luck for you all. The problems where explained. There's a Brazilian saying, he who warns you is your friend. You have been warned.
> 
> Here's one SERIOUS problem... If the signalling link is down, Asterisk internally continues trying to send the IAMs, never getting anything back (the signalling link is down), or perhaps the down part is between the STP and the remote TDM switch. In such cases there are MTP3 TFP (transfer prohibbited), TFA (transfer allowed) that tell you if the remote switch is reachable or not.
> 
> When the signallink link comes back up, all channels are clogged with incomplete calls, oh, the customers trying to place those calls get utter silence until they give up (and until all CICs are clogged).
> 
> If I have an Asterisk with multiple routes, some which are fine, some which are now clogged, the only recourse is a full DAHDI unload/load or asterisk restart, dropping all active DAHDI calls.
> 
> I managed to do a very dirty solution where incoming calls are accepted, clearing up the clogged channels, but I still haven't figured out how to properly reset the CICs when connectivity is restarted.
> 
> You can't simply drop active calls, ISUP/SS7 is all about reliability. Anyone that knows what ISUP/SS7 and TDM ISUP interconnects are all about will grade this asterisk implementation a piece of junk.
> 
> I already identified a dozen MTP3 messages that are ignored and that just happens I haven't received them yet, but they can happen, and are required for certification. Any commercial gateway processes them correctly.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4127 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20160420/f4ef6138/attachment.bin>