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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,
the problems you have posted 3 years ago were mostly for the stock 
libss7 (trunk - partially 1.0, partially something else at that time). 
Yes, it had many problems, but libss7 2.0, which have reached it's final 
status and it's place in the official code base, was completed few 
months later.

The behavior you describe simply can't happen with the timers enabled 
(particularly those from Q.707) and when the link is torn down the new 
call attempts will get congested and free to try other routes.
With "ss7 restart mtp3 <linkset> <slc>" you can restart a single link 
without interrupting other traffic, which should also clear the 
call_status and release clogged calls.

I agree that STP and cluster functionality is (still) missing from 
libss7 and this causes some limitations, but knowing that Asterisk with 
libss7 is SCP and not STP should be clear enough of what it is missing.

If you do find a problem with Asterisk 13 and libss7 2.0, please open a 
bug report on https://issues.asterisk.org with description and a way to 
reproduce it and i will do my best to provide a patch to fix it.

On 2016-04-20 17:58, Marcelo Pacheco 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.
> 
> 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 [1] 
> --
> 
> asterisk-ss7 mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-ss7 [2]



Links:
------
[1] http://www.api-digital.com
[2] http://lists.digium.com/mailman/listinfo/asterisk-ss7



[Index of Archives]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite Backpacking]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]     [Asterisk Books]

  Powered by Linux