[prev in list] [next in list] [prev in thread] [next in thread] 

List:       asterisk-ss7
Subject:    Re: [asterisk-ss7] KNK SS7-27 - first experiences - part 2
From:       Pavel Troller <patrol () sinus ! cz>
Date:       2013-06-27 6:58:09
Message-ID: 20130627065809.GA32011 () tangens ! sinus ! cz
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]