Hi Pavel The function that reads SLTM and constructs the SLTA is std_test_receive in mtp3.c (called by mtp3_receive). As far as I see, the test pattern replied is the same as received in SLTM, which is correct according to Q.707 2.2, the test pattern is chosen by the emitter (EWSD in your case). If I remember correctly, EWSD has a fixed test pattern for the whole CCNC (stored on PMU:SIMP), so the test pattern for the whole switch is the same. This is a very interesting case, I'll try to reproduce the scenario with the Inet Spectra. Regarding to the link down for Ast and UP for the remote side, I saw (perhaps) the same issue with Nec Neax 61E (old and buggy version), and the only thing that worked was to set MTP3 T.21 to a lower value. Off course that's not the ideal solution, but forces the Ast side to assume the linkset is up with no TFx or TRA messages involved. T.21 should be between 63 to 65 seconds, on that case Ast complaints about receiving MSUs with the linkset down until T.21 expiration, when the linkset suddenly goes to up state. Just my 0.02. Best regards Gustavo On Jun 27, 2013, at 2:25 AM, Pavel Troller <patrol at sinus.cz> wrote: > Hi there! > I would like to report another issue, which was actually the first I've > found when trying to put my gateway into operation, but once solved it didn't > appear anymore, so it's not as important as other ones. But it's there and > it should be fixed. > As already discussed in my first post, I have an Asterisk box connected to > two EWSD exchanges. Every one has its own, well-separated linkset, with one > separate physical signalling link. So, it should work well even with very > limited MTP3 support in libss7. EWSDs have differnt PCs, Asterisk uses the > same OPC for both of them. > When I tried to start the gateway for the first time, a very strange things > were occuring: MTP2 came up on both links as expected, and then EWSDs started > to send an ISUP traffic immediately to the Asterisk. It means, that MTP3 > also successfully opened on the EWSD side, BUT NOT ON THE ASTERISK ONE! The > linksets were down! And Asterisk just reported tons of messages about > unexpected ISUP when linksets are not up. > Please note that we don't play the TRA game here in Czech Republic (and > probably in other European countries), so the only verification tool that > the linkset is up is sending SLTM and verifying correctness of the returned > SLTA. And it passed on EWSD and didn't pass on Asterisk side. > Finally I found that my cables are swapped (the new server assigned the > order of E1 cards differently than the old one) and that I'm trying to start > linksets against the opposite exchanges! Such a stupid error! But a very > strange is, that EWSDs didn't find it and they promptly tried to use the > linksets. So I'm afraid that the SLTAs returned as a response to their SLTMs > were somewhat "fake", containing data, which they liked, while they would not > definitely like the real data (a different PC would not make the linkset to > activate). EWSDs are very strict in this. Isn't it possible that when forming > the SLTA response, we just reverse the PCs from incoming SLTM instead of > putting our own data here ? > I tried to find the problem in the libss7 code but on the contrary to the > code in isup.c, I almost cannot understand the code in mtp3.c - it's not > commented well and I can't even find a place, where we construct an SLTA > to respond to the partner's SLTM. > With regards, > Pavel Troller > > -- > _____________________________________________________________________ > -- 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
|