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