[asterisk-ss7] chan_ss7 2.1.0 patch

[Abdul Basit]

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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20120712/c4fb7def/attachment-0001.htm>