<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Gregory,<br>
<br>
Op 06-01-11 16:11, Gregory Massel schreef:
<blockquote cite="mid:0BF87A30CB654203A4385FE7642F860B@GregDesktop"
type="cite">Hello
<br>
<br>
I seem to have picked up a bug in chan_ss7 (version 1.4.3) and I
was wondering if anyone else can confirm the same experience or
assist in developing a fix.
<br>
<br>
The problem arises when there are multiple combined linksets with
overlapping CIC numbers. This was supported from chan_ss7 version
1.4 (and described as "Dutch ISUP" in the NEWS file) through the
inclusion of a patch developed by Robert Verspuy.
<br>
<br>
</blockquote>
I'm running 2 asterisk servers (although still with chan_ss7 1.2.1
with my own patches backported).<br>
<br>
<blockquote cite="mid:0BF87A30CB654203A4385FE7642F860B@GregDesktop"
type="cite">The only unusual messages that I pick up are the
following:
<br>
NOTICE[1467] l4isup.c: Trying to remove CIC=68 from idle list, but
not found?!?.
<br>
</blockquote>
I don't see that kind of message in my logfiles,<br>
But I do see the following:<br>
<br>
[Jan 6 09:52:08] NOTICE[29584] l4isup.c: Got call progress, but
call setup not active, CIC=95, state=5?!?<br>
<br>
I don't know if this is related somehow.<br>
<br>
<blockquote cite="mid:0BF87A30CB654203A4385FE7642F860B@GregDesktop"
type="cite">
<br>
So it seems that the patch is effective at matching the CICs in
one section, but perhaps some else in the code something else also
needs to be patched to allow clean-up of the CICs once used.
<br>
</blockquote>
This could be.<br>
I don't know the code very well, and this was my first patch to get
everything working on our systems.<br>
<blockquote cite="mid:0BF87A30CB654203A4385FE7642F860B@GregDesktop"
type="cite">
<br>
Eventually, something exhausts itself and everything falls apart
with the following message flooding repeatedly:
<br>
NOTICE[8513]: mtp.c:413 mtp_put: Full MTP receivebuf, event lost,
type=15.
<br>
</blockquote>
I don't see any log messages like that,<br>
But I do see:<br>
[Jan 6 12:53:18] NOTICE[14044] l4isup.c: Write buffer full on
CIC=99 (wrote only 160 of 240), audio lost (suppress 13).<br>
<br>
This could also be related.<br>
We have mainly inbound calls, so it could be a bit of the same
issue, but with the call setup the other way around.<br>
<br>
I did look into the buffer problems before, but did not find any
cause on the server (not very busy).<br>
So I assumed this was likely be caused by transferring the call from
SS7 to SIP.<br>
<br>
With a bit extra latency through SIP, and a bit too much jitter, I
think it's possible that chan_ss7 can not fill the write buffer,<br>
or when the rtp packets from sip suddenly arrive, the writesbuffer
can be filled to much?<br>
<br>
But all my issues seem only temporary.<br>
After these log messages, the CIC's are still usable and I see a few
minutes later calls on those CIC's with problems.<br>
And we had no crash eiter of a running system.<br>
<br>
Both servers are now running for a 6 weeks and 5 hours (sinds the
last maintenance).<br>
And handled together a bit more than 600.000 inbound SS7 and 10.000
outbound SS7 calls.<br>
Totally processed around 900.000 calls.<br>
<br>
From last februari until september (8 months) the servers had their
longest time without any problems.<br>
The system had to be restarted for maintenance and adding a few
extra SS7 links.<br>
<br>
With kind Regards<br>
Robert Verspuy<br>
<br>
<div class="moz-signature">-- <br>
<b>Exa-Omicron</b><br>
Patroonsweg 10<br>
3892 DB Zeewolde<br>
Tel.: 088-OMICRON (66 427 66)<br>
<a class="moz-txt-link-freetext" href="http://www.exa-omicron.nl">http://www.exa-omicron.nl</a></div>
</body>
</html>