[asterisk-ss7] chan_ss7 2.1.0 patch

[Marcelo Pacheco]

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

Marcelo Pacheco
M2J Communications - Brazil