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