Per usual, read the fine manual. Wait, there's no manual ! 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. 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. It looks like you're getting incoming signalling for ISUP channels that are on another linkset. I'm sure you didn't find any libss7 bug. I have a highly customized version of libss7/dahdi/asterisk, fixing lots of issue, but this isn't one of them. 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). If you need commercial support, contact me off list. 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 >
|