Hello Marcelo, > Per usual, read the fine manual. Wait, there's no manual ! You're right :-). > Since you seem to have done your part and actually knows some ss7 and > isup, here comes a hint. > > You created two or more linksets where you must have a single one. > libss7 don't have the ss7 routing feature. It seems strange to me. Let's try to explain this in more detailed way. There is 1 (one) Asterisk box. It has 2 (two) "linksets" configured, with 1 (one) signallink link per linkset. Linkset 1 is configured for one DPC and with CICs 1 - 496. Linkset 2 is configured for another (different) DPC and also with CICs 1 - 496. Both the systems connected to this Asterisk box are configured to respond directly to the linkset between them and the Asterisk, so it's sure that a MSU from DPC1 cannot come over LS2 and vice versa. I hope that this extremely simple setup is in the scope of current libss7 functionality. Or am I wrong ? > In libss7 linkset concept is diferent from official ss7 linkset. > > All signalling links that carry ISUP traffic for a given set of channels > must be kept on a single linkset, as well as all ISUP channels that go > through those links. I hope that my setup is conformant with this limitation. > > It looks like you're getting incoming signalling for ISUP channels that > are on another linkset. It really looks like this, but I still hope it's not the case. Please note that the traffic on the box is rather high, such an error occurs for one of, say, 10000 call attempts. I think that in case of such a fatal routing problem, which you are talking about, it wouldn't be possible to use the system regularly. > > I'm sure you didn't find any libss7 bug. Really strong words! I wouldn't say it for any of my programs :-). > I have a highly customized version of libss7/dahdi/asterisk, fixing lots > of issue, but this isn't one of them. Possibly your setup/usage scenario is a bit different ? > Processed over one million call setups, with a very complex setup (6 > linksets, 7 links, 6E1 on a single switch, plus another 6E1 on remote > switches using my simple STP solution, sharing the local links over SS7 > over UDP - my simpler proprietary alternative to sigtran). These switches (I have two of them, but the second one is still on a regular unpatched SS7 stack) make approx. 3 millions of call setups per week. My record (without restarting/crashing Asterisk) is about 3 weeks with more than 10 millions of calls. > > If you need commercial support, contact me off list. Thanks for your offer. With regards, Pavel > > On 06/24/13 09:02, Pavel Troller wrote: > > Hi! > > I would like to share my expiernce with deployment of this experimental SS7 > > branch. > > The first impressions are good, especially the timers seem to work well, > > saving many calls from being frozen. > > However, there are still some strange things, which I would like to discuss > > here, one by one. > > The first one is, that the channel sometimes doesn't recognize a message > > (mostly RLC), even it comes from an action initiated by the channel itself. > > Typically, the following is appearing often: > > > > [Jun 24 13:33:41] ERROR[3975]: chan_dahdi.c:14406 dahdi_ss7_error: [1] ISUP timer t17 expired on CIC 27 DPC 4097 > > [1] Got RLC but we didn't send REL/RSC on CIC 27 PC 4097 reseting the cic > > > > As I understand, there were some timeouts and now the channel tries to > > recover by sending RSC and firing T17. However, it seems that it immediately > > rejects RLC, which comes back as a response to the RSC which was just sent > > upon expiry of T17. And this appears again and again in the rhythm of T17, > > and the channel is not operational. > > ss7 show calls shows the following line for the misbehaving CIC: > > 27 4097 11 IAM IAM > > > > Or, a very similar situation: > > [2] Got SUS but no call on CIC 48 PC 4096 reseting the CIC > > [2] Got RLC but we didn't send REL/RSC on CIC 48 PC 4096 reseting the CIC > > > > The first question is, why there was no call while SUS was received. My > > idea is, that both the parties hung up their phones in the same time and > > that the call was undergoing destruction on Asterisk side (REL just sent > > or something like this), while SUS arrived. Maybe the call was marked as > > cleared even before RLC came back ? OK, I can understand this. But > > if the CIC was reset as the first message says (i.e. RSC was sent), why the > > RLC going back is not recognized then ? > > > > Or, just now the following appeared: > > > > [1] Got ACM but we didn't send IAM on CIC 10 PC 4097 reseting the cic > > [1] Got RLC but we didn't send REL/RSC on CIC 10 PC 4097 reseting the cic > > > > Again, it's questionable, why this happened, but the second line seems > > to indicate some brokeness again. > > > > To explain: The channel is operating on a gateway equipped with 16 E1s > > and current traffic is about 10 CAPS, there are two linksets to two > > cooperating exchanges. They are EWSDs, which have very mature and stable > > SS7, so I'm almost sure that they are not making signalling errors. > > > > With regards, > > Pavel > > > > -- > > _____________________________________________________________________ > > -- 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 > >
|