<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=ISO-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18999">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff text=#000000>
<DIV><FONT size=2 face=Arial>Hi Robert</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>I think the write buffer notice you're getting is
normal audio loss due to the jitter buffer and jitter associated with the SIP
channel.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>It seems that remove_from_idlelist() in l4isup.c
may be the issue:</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>static void remove_from_idlelist(struct ss7_chan
*pvt) {<BR> struct linkset* linkset = pvt->link->linkset;<BR>
struct ss7_chan *prev, *cur;</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial> cur =
linkset->group_linkset->idle_list;<BR> prev = NULL;<BR>
while(cur != NULL) {<BR> if(pvt->cic == cur->cic)
{<BR> if(prev == NULL)
{<BR>
linkset->group_linkset->idle_list =
pvt->next_idle;<BR> } else
{<BR> prev->next_idle =
pvt->next_idle;<BR>
}<BR> pvt->next_idle =
NULL;<BR> return;<BR>
}<BR> prev = cur;<BR> cur =
cur->next_idle;<BR> }<BR> ast_log(LOG_NOTICE, "Trying to remove
CIC=%d from idle list, but not found?!?.\n", pvt->cic);<BR>}<BR></FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>What concerns me is the following
line:</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>if(pvt->cic == cur->cic) {</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>I get the impression that it should read something
like:</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>
<DIV><FONT size=2 face=Arial>if(pvt->cic == cur->cic &&
linkset->dpc == cur->linkset->dpc) {</FONT></DIV>
<DIV> </DIV>
<DIV>In my mind, this should, in theory, ensure that the CIC is matched not just
on the CIC number but also on the DPC.</DIV>
<DIV> </DIV>
<DIV>My thinking is that perhaps the current code is causing the wrong channel
to be removed from the idle list.</DIV>
<DIV> </DIV>
<DIV>Does this sound logical to you?</DIV>
<DIV> </DIV>
<DIV>Unfortunately this doesn't explain why I'm experiencing the problem but you
arn't, although I suspect that the crash may only occur once you try dial out a
call using a channel that wasn't correctly removed from the idle list. Depending
on the hunting policy in use, it may be that you're receiving calls on even CICs
and making them on odd CICs as long as there are free CICs, in which case you
may not experience the problem if you don't use more than 50% of your capacity.
Just a theory...</DIV>
<DIV> </DIV>
<DIV>--Greg</DIV>
<DIV> </DIV></DIV></FONT>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"
dir=ltr>
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: black"><B>From:</B>
<A title=robert@exa-omicron.nl href="mailto:robert@exa-omicron.nl">Robert
Verspuy</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=greg@csurf.co.za
href="mailto:greg@csurf.co.za">Gregory Massel</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A
title=asterisk-ss7@lists.digium.com
href="mailto:asterisk-ss7@lists.digium.com">asterisk-ss7@lists.digium.com</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Thursday, January 06, 2011 5:57
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: chan_ss7 1.4.3 bug with
overlapping CIC numbers on combined linksets</DIV>
<DIV><FONT size=2 face=Arial></FONT><FONT size=2
face=Arial></FONT><BR></DIV>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></BLOCKQUOTE></BODY></HTML>