Re: [asterisk-ss7] KNK SS7-27 - first experiences - part 2
Hi all, i am happy to report, that i have (finally) put this version in production with asterisk 11 and works very stable for a bit over a week now. I have uploaded the patch for asterisk 11 to JIRA [1] The final changes made to libss7 (new trunk) can be downloaded from [2] If you would like to use /team/rmudgett/ss7_27_knk branch (which is asterisk trunk) do not forget to apply the changes from [3] If you have any bug reports or problems, with this latest version, please report here or in the issue [1] [1] https://issues.asterisk.org/jira/browse/SS7-27 [2] https://reviewboard.asterisk.org/r/2150 [3] https://reviewboard.asterisk.org/r/2170 -- _ -- 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
Re: [asterisk-ss7] KNK SS7-27 - first experiences - part 2
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 pat...@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 -- _ -- 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
Re: [asterisk-ss7] KNK SS7-27 - first experiences - part 2
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 pat...@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
Re: [asterisk-ss7] KNK SS7-27 - first experiences - part 2
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 pat...@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 pat...@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:
