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 <marc...@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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

-- 
_____________________________________________________________________
-- 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

Reply via email to