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