Tap here to compare the top VoIP providersTap here to hide the top VoIP Providers
Asterisk ss7 faq
Frequently Asked Questions for chan_ss7for chan_ss7 by Dicea
;Does chan_ss7 work with Sangoma cards?:
- Is chan_ss7 certified?
- No, no certification of chan_ss7 has been obtained, nor is such certification in progress. Of course, should anyone wish to start a process of obtaining certification, we would be interested in helping out that effort.
- How can I configure multiple signalling links?
- In version 0.8 and later, a linkset can consists of more than one link.
- How can I connect to more than one remote signalling point?
- In version 0.8 and later, there is support for multiple linksets that can be connected to different peers.
- I can't compile chan_ss7 / I got these errors when trying compile chan_ss7
- The compiler probably can't find headerfiles for asterisk and/or zaptel. Instead of only typing "make", add an INCLUDE variable before the make command like this: INCLUDE="-I<directory-containing-zaptel.h> -I<directory-containing-asterisk>" make
- I have trouble starting Asterisk and chan_ss7
- chan_ss7 can't open the signalling device properly. This may be because there is no signalling device, the driver for the signalling device hasn't be loaded or the wrong signalling device has been specified in ss7.conf. To learn how to configure the driver and chan_ss7, read full step-by-step guide
- I get all these bad-frame errors
- This can be allmost anything - but it is usually because chan_ss7 lose its data on the path from the remote end. The datapath is something like remote switch <--> zaptel-hardware <--> zaptel-driver <--> chan_ss7 and the data can get lost in any of these steps. For now, most of these errors occur because the 8 bytes get lost between the zaptel hardware and the zaptel driver. 1000 times pr. second, the zaptel hardware issues an interrupt to the zaptel driver. The zaptel driver then reads 8 bytes of data from a buffer in the zaptel hardware. If these 8 bytes is not read from the hardware buffer before the next interrupt occurs, they will be lost. This is actually not a rare event. The cause can be slow hardware or multiple devices sharing the same IRQ. Sometimes it can be solved by removing unnecesary hardware from the machine, sometimes it can be solved by reconfiguring the IRQ of some of the devices. In most cases it can be detected by looking at /proc/zaptel/*. If the line "IRQ misses: 3245" (where 3245 is an arbitrary number) occurs, it is because the driver hasn't been able to copy the hardware buffer before getting the next interrupt. If there is no IRQ misses it could simply be a bad connection or cable...
- I get messages like
- "warning failure in ZT_SPECIFY for circuit 1: device or resource busy": Either multiple instances of asterisk is running, or another channel driver is using the same device nodes as chan_ss7, typically chan_zap. Be sure that the channel drivers are not using the same device nodes (circuits). If ISDN is not used, chan_zap needs not be loaded.
- I get messages like (with asterisk 1.6.0.x) [Sep 17 18:51:41] WARNING
- loader.c:422 load_dynamic_module: Error loading module 'chan_ss7.so': /usr/lib/asterisk/modules/chan_ss7.so: undefined symbol: ast_dsp_set_digitmode:
Asterisk 1.6.1 is ok
;I was trying to configure total 32 E1. I got following msg when i am trying to run mtp3d config.c_707 loadconfiglink Too many links defined for linkset 'MSC1' for link 'l17' (max 16)
/* Upper bounds only determined by installed hardware, use decent values */ #define MAX_E1_CONNECTOR_NO 16 #define MAX_CIC 4096 #define MAX_LINKSETS 8 #define MAX_LINKS 128 #define MAX_LINKS_PER_LINKSET 16 #define MAX_LINKS_PER_HOST 16 #define MAX_SPANS_PER_HOST 16 #define MAX_SCHANNELS 16 #define MAX_SCHANNELS_PER_E1 16 #define MAX_IFS_PER_HOST 2 #define MAX_HOSTS 16 #define MAX_ROUTES_PER_HOST 16
- Excessive poll delay warning
[Sep 19 22:30:49] NOTICE mtp.c: Excessive poll delay 5985! [Sep 19 22:40:49] NOTICE mtp.c: Excessive poll delay 5355!
This "Excessive poll delay" warning is a known and yet mysterious problem. We see it on some machines, but not on others, and we have not gathered sufficient statistics to narrow down the cause for it.
It would be very useful to gather that statistics in the form of output from the shell commands:
uname -a /sbin/lspci cat /proc/cpuinfo cat /proc/meminfo cat /proc/interrupts grep "Excessive poll delay" /var/log/asterisk/messages | tail -10
The output should be e-mail too one of chan_ss7 authors Anders Baekgaard (ab at netfors.com) with the Subject "chan_ss7 statistics". Anders kindly requested everybody reading this post to help solving the problem, regardless you experience it your self.
- change server hardware
- dont use ide drivers
- other side has link down
- Write buffer full on CIC=4 (wrote only 0 of 160), audio lost.
[Sep 19 18:41:08] NOTICE l4isup.c: Write buffer full on CIC=4 (wrote only 0 of 160), audio lost. [Sep 19 18:41:08] NOTICE l4isup.c: Write buffer full on CIC=4 (wrote only 0 of 160), audio lost. [Sep 19 18:41:08] NOTICE l4isup.c: Write buffer full on CIC=4 (wrote only 0 of 160), audio lost.
Actually, the "Write buffer" is a kind of jitter-buffer. It is inside the zaptel driver and is initialized by chan_ss7 to 4 * 160 bytes (80ms). You can increase it to some other multiple of 160, but it requires a recompile, and will also increase the audio-delay.
The "write-buffer full" problem often occur because of jitter on the IP-net.
In IP-networks, there is allways a time-delay from the time a packet is sent to it get received at another host. This delay is unfortunately not allways the same. Sometimes, the packets will arrive too slow, and sometimes they will arrive too fast. When they arrive too fast, the send-buffer is filled, chan_ss7 writes the "Write buffer full" and then drop the packets.
This problem does not occur in the conventional circuit-switched telephone network, since it is completely synchronous and a dedicated (logical) circuit is reserved between the sender and receiver.
To get around this problem, you can setup trafic-shaping on the network, insert a bigger buffer in chan_ss7 (which will cause more delay), to even-out the difference in time-delay. Maybe it will helpl to configure the routers to "chop up" big packets in order to get the small RTP packets going smoothly.
- Limit exceeded when trying to adjust numbufs
[Sep 19 18:41:08] WARNING l4isup.c: Limit exceeded when trying to adjust numbufs to 8, for circuit 4. [Sep 19 18:41:08] WARNING l4isup.c: Limit exceeded when trying to adjust numbufs to 8, for circuit 4. [Sep 19 18:41:08] WARNING l4isup.c: Limit exceeded when trying to adjust numbufs to 8, for circuit 4.
Check your ulimit settings. If you get something like this:
ivr:~/ss7 # ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 38911 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) 3440460 open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 38911 virtual memory (kbytes, -v) 6618160 file locks (-x) unlimited The most probable cause is too low open files value - 1024. Set it to unlimited or at least to a reasonable big value like 524288 :-) ivr:~/ss7 # ulimit -n 524288 ivr:~/ss7 # ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 38911 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) 3440460 open files (-n) 524288 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 38911 virtual memory (kbytes, -v) 6618160 file locks (-x) unlimited ivr:~/ss7 # ulimit -n
- Is it possible to test/develop on chan_ss7 without access to SS7 equipment?
- You can use two Asterisk boxes, each running chan_ss7 on a Digium E1 card. Use an E1 cross-cable to connect the two boxes. Configure each box with its own point code (just use 1 and 2 for the point codes, since this is not connected to any other SS7 network). Remember to set one end as a sync source and the other end as not a sync source in the zaptel.conf.
- Where can I find documentation on the MTP2/3 and ISUP protocols implemented by chan_ss7?
- The SS7 protocols are defined in a series of documents published by ITU-T. The main sources of information for chan_ss7 has been the following ITU-T documents:
- Q.703 (MTP2 protocol)
- Q.704 (MTP3 protocol)
- Q.707 (Testing and maintenance)
- Q.763 (ISUP packet formats)
- Q.764 (ISUP signalling procedures)
- Q.850 (ISUP release cause codes)
- Q.762 (General function of messages and signals)
An older, public release of these documents is available at http://www.nmedia.net/docs/ccitt/1992/q/ (The usage conditions http://www.nmedia.net/docs/ccitt/conditions.txt for these documents waive all guarantees. For more information on this early ITU document release, see Carl Malamud's book Exploring The Internet http://museum.media.org/eti/)
The ITU-T documents can be purchased on CD from ITU-T, and it is also possible to obtain a free download of three documents. The procedure is explained on this ITU-T page.
- Will the Asterisk SS7 cluster work for SIP/IAX/zaptel also?
- No, the cluster support in chan_ss7 uses changeover mechanisms in MTP3, and the load sharing mechanism in MTP3, and hence are very SS7 specific.
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+