unload chan_zap.so
load chan_zap.so
restart when convenient

zaptel.c turn on debug mode “debug=1”
static int debug;

wcfxo.c:30
/* Un-comment the following for POTS line support for Japan */
/* #define JAPAN */

http://www.marko.net/asterisk/archives/0212/0588.html

system(“/etc/init.d/zaptel restart”);
into /usr/local/src/asterisk/channels/chan_zap.c:4900

Well, after bummin around thinking I had bad fxo cards, I finally discovered that I was loosing two phones in my home when I had the cards plugged in… Turns out the jack I had plugged into, was wired for two phones (line 1, green/red and line 2, yel/blk) and I also was using a 4 wire phone cord for the connection. It turns out that the x100p cards are wired in such a way internally that if you are running a 4 wire phone cord to them, that you might short out between the two lines at the jack (which worked separately with phones and computers) and get funky results…..=20

Moral of the story is to always use two wire phone cords with the x100p fxo cards. Problem solved, and I was able to continue my development….

Thanks

Sean Garland

the main problem was probably adding timing

-span=1,0,0,ccs,hdb3,cdc4
+span=1,1,0,ccs,hdb3,crc4

the second (a minor?) was that the e100p was sharing IRQ with an usb
controller

telephone links
http://www3.sympatico.ca/bparker/index1.html#06

http://www.ling.upenn.edu/~kurisuto/phone_wiring.html

For some of these noise problems, it is good to do a jitter analysis. I
found it to be the cause of the problems I was having with my Cisco phone
and a X-Lite client. Also, I found that the X-Pro client is better at voice
delivery than the X-Lite client.

Anyway, if you have tcpdump available on your asterisk server, use it to
collect some timing statistics.

For example,

tcpdump -i eth0 -T rtp dst host x.x.x.x and dst port 8000

(if I have this wrong, ‘man tcpdump’ will help you with the various
options).

Should decode the rtp stream on eth0 to port 8000 on x-lite.=20

Pipe the output to a file. Should look like:

14:44:43.618422 10.1.1.60.8000 > sip.oneunified.net.15958: udp/rtp 160 c0
4208 758720
14:44:43.619033 10.1.1.60.8000 > sip.oneunified.net.15958: udp/rtp 160 c0
4209 758880
14:44:43.665234 10.1.1.60.8000 > sip.oneunified.net.15958: udp/rtp 160 c0
4210 759040
14:44:43.665521 10.1.1.60.8000 > sip.oneunified.net.15958: udp/rtp 160 c0
4211 759200
14:44:43.665925 10.1.1.60.8000 > sip.oneunified.net.15958: udp/rtp 160 c0
4212 759360

This sample doesn’t correspond to the command line shown, but gives you an
idea.

http://www.erg.abdn.ac.uk/users/alastair/tcpdump.html has some descriptive
comments about what you see.

Anyway, now import the file into a spreadsheet. Do deltas between the times
(first entry on each line, I usually discard the 14:44: stuff and focus on
the nn.nnnnn portion) on each line (line 2 – line 1, line 3 – line 2, … ).
Make an x-y chart with the numbers in the second last column, 4208, …, as
x and the deltas as y.

You may find some interesting results in terms of packet delivery timing.
Excellent packet delivery occurs with a max jitter of 20 to 40 ms. Cisco
phones have a dynamic jitter buffer up to 150 ms. My problem before was
that an X-Lite softphone on a slow machine or on a really bad internet
connection was averaging jitter between 80 and 200 ms. It was giving my
phone a really hard time. Hence the pops and periods of multi second
silence.