<!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">
Op 06-01-11 19:19, Gregory Massel schreef:
<blockquote cite="mid:58C0F36588834B3F92907C5C21EBF901@GregDesktop"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<meta name="GENERATOR" content="MSHTML 8.00.6001.18999">
<style></style>
<div><font face="Arial" size="2">Hi Robert</font></div>
</blockquote>
Hi Gregory,<br>
<br>
I don't see your e-mail on the asterisk-ss7 list. Are you still a
member?<br>
<blockquote cite="mid:58C0F36588834B3F92907C5C21EBF901@GregDesktop"
type="cite">
<div> </div>
<div><font face="Arial" size="2">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>
</blockquote>
That's my idea also.<br>
<blockquote cite="mid:58C0F36588834B3F92907C5C21EBF901@GregDesktop"
type="cite">
<div> </div>
<div><font face="Arial" size="2">It seems that
remove_from_idlelist() in l4isup.c may be the issue:</font></div>
<div> </div>
<div><font face="Arial" size="2">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> </div>
<div><font face="Arial" size="2"> 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> </div>
<div><font face="Arial" size="2">What concerns me is the following
line:</font></div>
<div> </div>
<div><font face="Arial" size="2">if(pvt->cic == cur->cic) {</font></div>
<div> </div>
<div><font face="Arial" size="2">I get the impression that it
should read something like:</font></div>
<div> </div>
<div><font face="Arial" size="2">
</font>
<div><font face="Arial" size="2"><font face="Arial" size="2">if(pvt->cic
== cur->cic && linkset->dpc ==
cur->linkset->dpc) {</font></font></div>
<div><font face="Arial" size="2"> </font></div>
<div><font face="Arial" size="2">In my mind, this should, in
theory, ensure that the CIC is matched not just on the CIC
number but also on the DPC.</font></div>
<div><font face="Arial" size="2"> </font></div>
<div><font face="Arial" size="2">My thinking is that perhaps the
current code is causing the wrong channel to be removed from
the idle list.</font></div>
<div><font face="Arial" size="2"> </font></div>
<div><font face="Arial" size="2">Does this sound logical to you?</font></div>
</div>
</blockquote>
Yes, maybe there is still an issue in this source.<br>
<br>
But the problem is a bit more complicated.<br>
With our connection to the Dutch ISUP (KPN), we have two linksets
(Asd2 and Asd3).<br>
The linksets do not share a E1's.<br>
Both linksets have their own signalling link on the first E1.<br>
But it is possible to receive signalling on the Asd2 signal link for
a call on CIC 25 from the Asd3 link.<br>
<br>
So only checking the dpc is not enough. When calling the
remove_from_idlelist function, besides the pvt also the
corresponding dpc must be passed along,<br>
just like I did in my patch.<br>
<br>
<blockquote cite="mid:58C0F36588834B3F92907C5C21EBF901@GregDesktop"
type="cite">
<div>
<div><font face="Arial" size="2"> </font></div>
<div><font face="Arial" size="2">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...</font></div>
</div>
</blockquote>
We have seperate E1's for inbound and outbound traphic.<br>
And we don't have much outbound traphic, maybe even nothing in the
last weeks.<br>
<br>
<blockquote cite="mid:58C0F36588834B3F92907C5C21EBF901@GregDesktop"
type="cite">
<div>
<div><font face="Arial" size="2"> </font></div>
<div><font face="Arial" size="2">--Greg</font></div>
</div>
</blockquote>
With kind regards,<br>
Robert
<blockquote cite="mid:58C0F36588834B3F92907C5C21EBF901@GregDesktop"
type="cite">
<div>
<div><font face="Arial" size="2"> </font><br>
</div>
</div>
</blockquote>
<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>