[asterisk-ss7] chan_ss7 2.1.0 patch

[Abdul Basit]

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