[asterisk-ss7] KNK SS7-27 - first experiences - part 2

[Pavel Troller]

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