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

[Pavel Troller]

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