[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-ss7
Subject: Re: [asterisk-ss7] chan_ss7 2.1.0 patch
From: Abdul Basit <basit.engg () gmail ! com>
Date: 2012-07-12 12:38:30
Message-ID: CAGQG5MbyW_HD+oCA7Df=_WJKTAoxq+ceT7aTE8MPcYdtBBBsXw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I appreciate your findings. I have small test setup for few days. If you
want me to test anything else please share.
I will do will completely free just for the community. So don't hesitate.
I have setup as follows:
1 opc/dpc
6 signalling links.
8 E1s (4 +4) openVOX cards
Centos 5.5 32bit with Linux version 2.6.18-194.3.1.el5PAE
Asterisk 1.6.2.10
4GB RAM
Intel Dual core Dual Xeon(TM) CPU 2.80GHz
chan_ss7 version 1.4.3 (that will be updated)
--
Regards,
Abdul Basit
On Thu, Jul 12, 2012 at 5:22 PM, Marcelo Pacheco <marcelo@m2j.com.br> wrote:
> http://sip.m2j.com.br/chan_ss7-trunk.tgz
>
> I'll remove it from there next Monday.
>
> DON'T USE THIS UNLESS YOU KNOW WHAT YOU'RE DOING.
> DIFF THE SOURCE AND ANALYZE THE CHANGES.
> I make a living out of providing paid support for linux/internet/tdm
> stuff. So I won't provide any free support for anything.
>
>
> On 07/12/12 07:58, Abdul Basit wrote:
>
> These are good options. chan_ss7 need to be more optimized. I can test in
> my environment if you can share some test cases.
>
> What is the plan of including this patch in main stream?
>
>
> On Thu, Jul 12, 2012 at 2:34 PM, Marcelo Pacheco <marcelo@m2j.com.br>wrote:
>
>> A few bugs / features I found with chan_ss7 2.1.0, and the fixed I
>> applied in order to use it successfully:
>>
>> 1 - Even with dahdi mtp2 channel, chan_ss7 still sends FISU and LSSU
>> non-stop. When in mtp2 mode, it should conserve CPU by sending SUs only
>> when something has changed. Since I only plan to use chan_ss7 with dahdi
>> mtp2, I increased the select interval to 200ms to reduce the CPU intensity
>> of the mtp3 sender thread. The proper solution is to properly support mtp2
>> dahdi mode, not sending extra FISU and LSSU never.
>>
>>
>> 2 - ss7 link status - shows sent bytes as 16 always, this is caused by
>> writecount initialized with ZAP_BUF_SIZE and then never incremented in
>> dahdi mtp2 mode. I changed it so it gets incremented only for successful
>> writes with len > 6, only counting sends with LI > 1 (skip FISU and LSSU).
>> I also reduced writecount and readcount to unsigned long, since 4GB is a
>> LOT of sinalling data, let it wrap.
>>
>>
>> 3 - Nature of address 1 shouldn't add 00 prefix do ANI and DNI. Disabled
>> the intentional fall through in isup.c - decode_isup_phonenum, this is
>> needed for proper operations in Brazil.
>>
>>
>>
>> Now to the bugs without a fix:
>>
>>
>>
>> 4 - seq_lth / seq_htl is buggy, after about 1000 calls in seq_lth, I get:
>>
>> [2012-07-04 12:34:04] WARNING[26854] l4isup.c: No idle circuit found,
>> linkset=XXX.
>> [2012-07-04 12:34:04] WARNING[26854] l4isup.c: SS7 requester: No idle
>> circuit available, linkset=XXX.
>> [2012-07-04 12:34:04] WARNING[26854] app_dial.c: Unable to create channel
>> of type 'SS7' (cause 34 - Circuit/channel congestion)
>> [2012-07-04 12:34:04] VERBOSE[26854] app_dial.c: == Everyone is
>> busy/congested at this time (1:0/1/0)
>> [2012-07-04 12:34:04] VERBOSE[26854] pbx.c: -- Auto fallthrough,
>> channel 'SIP/XXXXXX-00000001' status is 'CONGESTION'
>>
>> even_mru works fine (processed about 2000 calls without issue). The
>> scenario is a single OPC/DPC pair with a single E1, CIC 1-15,17-31,
>> signalling channel on 16, internal signalling link.
>>
>>
>> 5 - ss7 reset crashes asterisk when in mtp3d mode.
>>
>> 6 - ss7 cluster crashes (it could be configuration dependent)
>>
>> 7 - chan_ss7 periodically suffers from some race condition and cpu
>> consumption spikes to 100% of one of the systems cpu threads. This happens
>> even with no active calls and no new call setups. I confirmed this is
>> caused by chan_ss7 by monitoring per thread cpu consumption with top + H
>> option and then executing strace on those threads and the two threads that
>> suffer from this are the read/write to the sigchan threads.
>>
>>
>> I'm sending this as my contribution, however I gave up on chan_ss7 due to
>> difficulty implementing the signalling network layout I need. The same
>> layout works beautifully with libss7 (on a single system layout).
>>
>>
> This is somehow not good. chan_ss7 should have more simplified layout.
>
>
>> Marcelo Pacheco
>> M2J Communications - Brazil
>>
>
>
> --
> Regards,
>
> Abdul Basit
>
>
>
>
> --
> _____________________________________________________________________
> -- 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
>
>
>
> --
> _____________________________________________________________________
> -- 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
[Attachment #5 (text/html)]
I appreciate your findings. I have small test setup for few days. If you want me to \
test anything else please share.<div><br></div><div>I will do will completely free \
just for the community. So don't hesitate. </div><div>
<br></div><div>I have setup as follows:</div><div> </div><div>1 opc/dpc</div><div>6 \
signalling links.</div><div>8 E1s (4 +4) openVOX cards</div><div>Centos 5.5 32bit \
with Linux version 2.6.18-194.3.1.el5PAE</div><div>Asterisk 1.6.2.10</div>
<div>4GB RAM</div><div>Intel Dual core Dual Xeon(TM) CPU 2.80GHz</div><div>chan_ss7 \
version 1.4.3 (that will be updated)</div><div><br></div><div><div>-- \
</div><div>Regards,</div><div><br></div><div>Abdul Basit</div></div>
<div> <br><br><div class="gmail_quote">On Thu, Jul 12, 2012 at 5:22 PM, Marcelo \
Pacheco <span dir="ltr"><<a href="mailto:marcelo@m2j.com.br" \
target="_blank">marcelo@m2j.com.br</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<a href="http://sip.m2j.com.br/chan_ss7-trunk.tgz" \
target="_blank">http://sip.m2j.com.br/chan_ss7-trunk.tgz</a><br> <br>
I'll remove it from there next Monday.<br>
<br>
DON'T USE THIS UNLESS YOU KNOW WHAT YOU'RE DOING.<br>
DIFF THE SOURCE AND ANALYZE THE CHANGES.<br>
I make a living out of providing paid support for linux/internet/tdm
stuff. So I won't provide any free support for anything.<div><div \
class="h5"><br> <br>
On 07/12/12 07:58, Abdul Basit wrote:
</div></div><blockquote type="cite"><div><div class="h5">These are good options. \
chan_ss7 need to be more optimized. I can test in my environment if you can share \
some test cases.
<div><br>
</div>
<div>What is the plan of including this patch in main stream?</div>
<div>
<div><br>
</div>
<div><br>
<div class="gmail_quote">On Thu, Jul 12, 2012 at 2:34 PM,
Marcelo Pacheco <span dir="ltr"><<a href="mailto:marcelo@m2j.com.br" \
target="_blank">marcelo@m2j.com.br</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> A few bugs / features I found with chan_ss7 2.1.0, and \
the fixed I applied in order to use it successfully:<br>
<br>
1 - Even with dahdi mtp2 channel, chan_ss7 still sends
FISU and LSSU non-stop. When in mtp2 mode, it should
conserve CPU by sending SUs only when something has
changed. Since I only plan to use chan_ss7 with dahdi
mtp2, I increased the select interval to 200ms to reduce
the CPU intensity of the mtp3 sender thread. The proper
solution is to properly support mtp2 dahdi mode, not
sending extra FISU and LSSU never.<br>
<br>
<br>
2 - ss7 link status - shows sent bytes as 16 always, this
is caused by writecount initialized with ZAP_BUF_SIZE and
then never incremented in dahdi mtp2 mode. I changed it so
it gets incremented only for successful writes with len
> 6, only counting sends with LI > 1 (skip FISU and
LSSU). I also reduced writecount and readcount to unsigned
long, since 4GB is a LOT of sinalling data, let it wrap.<br>
<br>
<br>
3 - Nature of address 1 shouldn't add 00 prefix do ANI and
DNI. Disabled the intentional fall through in isup.c -
decode_isup_phonenum, this is needed for proper operations
in Brazil.<br>
<br>
<br>
<br>
Now to the bugs without a fix:<br>
<br>
<br>
<br>
4 - seq_lth / seq_htl is buggy, after about 1000 calls in
seq_lth, I get:<br>
<br>
[2012-07-04 12:34:04] WARNING[26854] l4isup.c: No idle
circuit found, linkset=XXX.<br>
[2012-07-04 12:34:04] WARNING[26854] l4isup.c: SS7
requester: No idle circuit available, linkset=XXX.<br>
[2012-07-04 12:34:04] WARNING[26854] app_dial.c: Unable to
create channel of type 'SS7' (cause 34 - Circuit/channel
congestion)<br>
[2012-07-04 12:34:04] VERBOSE[26854] app_dial.c: ==
Everyone is busy/congested at this time (1:0/1/0)<br>
[2012-07-04 12:34:04] VERBOSE[26854] pbx.c: -- Auto
fallthrough, channel 'SIP/XXXXXX-00000001' status is
'CONGESTION'<br>
<br>
even_mru works fine (processed about 2000 calls without
issue). The scenario is a single OPC/DPC pair with a
single E1, CIC 1-15,17-31, signalling channel on 16,
internal signalling link.<br>
<br>
<br>
5 - ss7 reset crashes asterisk when in mtp3d mode.<br>
<br>
6 - ss7 cluster crashes (it could be configuration
dependent)<br>
<br>
7 - chan_ss7 periodically suffers from some race condition
and cpu consumption spikes to 100% of one of the systems
cpu threads. This happens even with no active calls and no
new call setups. I confirmed this is caused by chan_ss7 by
monitoring per thread cpu consumption with top + H option
and then executing strace on those threads and the two
threads that suffer from this are the read/write to the
sigchan threads.<br>
<br>
<br>
I'm sending this as my contribution, however I gave up on
chan_ss7 due to difficulty implementing the signalling
network layout I need. The same layout works beautifully
with libss7 (on a single system layout).<br>
<br>
</blockquote>
<div><br>
</div>
<div>This is somehow not good. chan_ss7 should have more
simplified layout. </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> Marcelo Pacheco<br>
M2J Communications - Brazil<br>
</blockquote>
<div> </div>
<div> </div>
<div>-- </div>
<div>Regards,</div>
<div><br>
</div>
<div>Abdul Basit</div>
<div><br>
</div>
<div> </div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><div class="im"><pre>--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" \
target="_blank">http://www.api-digital.com</a> --
asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
<a href="http://lists.digium.com/mailman/listinfo/asterisk-ss7" \
target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-ss7</a></pre> \
</div></blockquote> <br>
</div>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" \
target="_blank">http://www.api-digital.com</a> --<br> <br>
asterisk-ss7 mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-ss7" \
target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-ss7</a></blockquote></div>
</div>
--
_____________________________________________________________________
-- 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic