It seems neither mtp3_receive nor std_test_receive are doing all the checks that they should. Just dpc against pc is checked. In fact, one of the common errors is the SLC misconfiguration, and that scenario is not checked here (at least in the good old 1.6 atthila version). If I can replicate the scenario, I'll take a deeper look on Q.707 to fix this. Keep you posted. Gustavo On Jun 27, 2013, at 3:58 AM, Pavel Troller <patrol at sinus.cz> wrote: > Hi Gustavo! > >> 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. > > I have no doubts about the test pattern. It must be the same and it is the > same. However, the test is more complex to accept the SLTA - I think, that > not only the test pattern, but also the whole RL is verified (i.e. OPC, DPC, > NI, SLS) and must match expected values. And in this case, the DPC must be > wrong! EWSD is very strict in its requirements and I don't believe that it > would ignore such a mismatch. So, I'm suspecting that the DPC sent in the > SLTA is not taken from the Asterisk linkset configuration, but just copied > from the incoming SLTM's OPC. I cannot imagine another scenario, which would > lead to the observed problem. > >> >> 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. > > I already have a very low MTP3 T.21 value, to bring the linkset up ASAP. > >> >> Just my 0.02. > > Many thanks! > >> >> Best regards >> >> Gustavo > > With the best regards, > Pavel > >> >> >> 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 >>>
|