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. On Wed, Apr 20, 2016 at 10:50 AM, Michal Ryb?rik <michal at rybarik.sk> wrote: > Hi, > > I'm running libss7 with SS7-27 patches on Asterisk 11 for few years, and > it works perfectly. Millions of calls connected without any issue, restart, > unstability, etc. During interoperability testing we had some problems with > deadlocks after BLOcking CICs with older SS7-27 patches, but I debugged it > and Kaloyan fixed it then, fix is included in official sources now. All > this should be published as libss7 2.0. Kaloyan did a lot of work on this > and I really don't see _any_ issues now. > > -- > Michal Rybarik > > > On 04/19/2016 07:27 PM, Marcelo Pacheco wrote: > >> I have my own extensive unpublished patch for Asterisk 1.8 that fixes >> lots of SS7/ISUP issues for me. >> I tried Asterisk 11 with unpatched sources and found lots of issues >> again. I couldn't even get a stable environment with just all trunks >> aligned. >> So I'm not surprised you're having problems. >> No, my patch isn't available, not it will for free. Most problems have >> been reported to this list before, and haven't been addressed in the 3 >> years passed since I reported them. >> So I don't advise anybody to use either ss7 solutions, you will have >> serious problems. The libss7 development process is unable to deliver a >> serious ss7 solution that will work properly. >> >> > > -- > _____________________________________________________________________ > -- 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/20160420/84669353/attachment-0001.html>
|