I am, by no stretch of the imagination, an Asterisk expert. Therefore, I will be careful about describing my experience setting up Asterisk 1.6.0.5 and DAHDI to work with the CallCentric service. Most times I do things because they work, but I don’t know why they work. Others may find this helpful.
Some quick history. I had a working Asterisk 1.4.21.2 with Zaptel platform. The server suffered a disk drive crash (no mirror). As I waited for the new drives to arrive to fix it (I’m going to setup mirroring now), I needed to put Asterisk on a spare machine I have. I did get the old machine to boot to a point that I could salvage the old /etc/asterisk configuration directory. So I had the old config file to start with on the new server.
I chose to install Asterisk 1.6.0.5. So I installed Zaptel to learn later that DAHDI must be used. So, I installed libpri 1.4.9 (because that’s what I did last time), DAHDI 2.1.0.3+2.1.0.2, and Asterisk 1.6.0.5. The builds and installs went in without any issues.
I ran dahdi_genconf to generate the dahdi config files. I also selectively copied in the old install’s config files. At first, I couldn’t get my TDM400 card to work under Asterisk. But with a little luck and monitoring of the console log, I was able to find and fix the troubles.
My first major problem was fxo_ls / fxo_fs signaling issues. Some of my config files were fxo_fs and other’s were fxo_ls. I don’t know the difference between the two. The old install used fxo_ks signaling. However, the new install seemed to favor fxo_ls. So, I changed all the fxo_ks to fxo_ls and my TDM400 channels came into service and I got a dial tone.
My second issue with the TDM400 was that when ever I pressed a digit on my analog phone I’d get a very fast busy signal. Snooping around, I ran the “DAHDI SHOW CHANNELS” command. I noticed that the “context=” parameter was set to something wild. I found this in the users.conf file. The old install didn’t use the users.conf file. I changed the “context=” in the users.conf file for each extension to the appropriate section in the extensions.conf file. This fixed the problem. I was then able to use the analog extensions to dial around in Asterisk 1.6.0.5. I like this feature (users.conf file) as it allowed me to simplify my extensions.conf file from the old insall. BTW, the command “/usr/sbin/dahdi_genconf users” creates the users.conf file for you.
So now I went to trying to register with Asterisk with CallCentric’s service. Using the old install’s sip.conf file, the new install registered with CallCentric right away. So then I tried to place test calls using my analog extensions (my TDM400 card) and X-LITE SIP softphone.
1). I could call out using the SIP softphone. Everything worked perfect.
2). I could call out using the analog extensions. Everything worked perfect.
3). I could call the SIP extension from the analog extension (no CallCentric involved). Everything worked perfect including my VoiceMail().
4). I could call the analog extension from the SIP extension (no CallCentric involved). Everything worked perfect including my VoiceMail().
BUT
5). When ever I called IN to the Asterisk server the analog extension would ring, which is good. I would answer the call. The calling party would continue to hear ringing. The called party (my analog extension) would hear “dead air”. In short time, Asterisk would print out an error message and close the connection. The error message was:
[Jan 28 12:37:06] WARNING[9385]: chan_sip.c:2794 retrans_pkt: Maximum retries exceeded on transmission 9069766-3442153005-996654@msw2.telengy.net for seqno 1 (Critical Response) -- See doc/sip-retransmit.txt.
[Jan 28 12:37:06] WARNING[9385]: chan_sip.c:2821 retrans_pkt: Hanging up call 9069766-3442153005-996654@msw2.telengy.net - no reply to our critical packet (see doc/sip-retransmit.txt).
-- Hungup 'DAHDI/2-1'
== Spawn extension (from-callcentric, 14578878052, 1) exited non-zero on 'SIP/14578878052-09b3de60'
I turned on “SIP DEBUG ON” in the Asterisk console. I could tell from the SIP packets being printed that Asterisk was not putting my “external IP” in the SIP packets. This was even though I had the EXTERNHOST= coded in the [general] section. Remember, this sip.conf had come from my old install. I did some reading in the “doc/sip-retransmit.txt” document. I came to the conclusion that I had to add the “nat=yes” and “localnet=192.168.0.0/255.255.0.0” parameters to the [general] section of the sip.conf file to force Asterisk to use my “externhost=” parameter.
When I ran Asterisk and made the calls again, I noticed that the “NAT” issue was fixed. Asterisk was now inserting my “external IP”. However, I was getting the same result (error message) on incoming calls.
Out of ideas, I opened a ticket with CallCentric Support. They responded quickly. They said they experienced my trouble during their testing of Asterisk 1.6.0.3. To fix it, they had to add the following parameters to the [general] section of the sip.conf file. The parameters they told me to add are:
session-timers=refuse
session-expires=180
session-minse=90
session-refresher=uas
This worked. My installation of Asterisk 1.6.0.5 and Dahdi 2.1.0.3 is now working as expected. When the new drives arrive and I get the old machine back in business, I should be able to install and configure it much quicker. I hope you find this helpful.
Dan McNaul
