[asterisk-ss7] chan_ss7 2.1.0 patch

[Marcelo Pacheco]

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 
> <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20120712/51308468/attachment.htm>