* You are viewing the archive for January 5th, 2011

TDM410 and DSL

Hi all,
I have a system installation in Guam with two trunks. One has a DSL service
riding on it with the usual filter. That channel however keeps throwing
alarms. I bypassed the filter and it stopped throwing alarms, but of course
the high frequencies annoy the users. I swapped the filters and the alarms
came back.

Any suggestions? Could I have a bad DSL modem?


Too Few Fax Detections

OK, after my last message about fax detection, I feel a bit better informed and able to press forward. I started looking into this because I was getting lots of false positive fax detection errors in the logs with faxdetect=both set in chan_dahdi.conf.

Anyhow, I do not currently use fax detection, and we have a dedicated Fax DID on our PRI, so setting faxdetect=no works fine. Having said that, I would like to sort it out as I may want to use fax detection in the future. Unfortunately, I seem to be having odd results. I set faxdetect=incoming last night and restarted dahdi and asterisk. Since that time, we have received 17 faxes, but I only have three fax detections in my asterisk log, so far as I can tell:

# grep -i fax /var/log/asterisk/full
[Jan 5 05:53:39] NOTICE[6686] chan_dahdi.c: Fax detected, but no fax extension
[Jan 5 10:24:27] NOTICE[11834] chan_dahdi.c: Fax detected, but no fax extension
[Jan 5 11:48:52] NOTICE[13804] chan_dahdi.c: Fax detected, but no fax extension

All three calls listed are indeed fax calls, and since there is no fax extension in that context, the call just proceeds along as if nothing happened (which is appropriate).

My question is this: If I have received 17 faxes since enabling fax detection, shouldn’t I see ~17 entries in the log?

Assuming the answer to that question is yes, what might be causing the system to not detect faxes on the other 14 calls?

Many thanks,


Weird phone behavior after recent CentOS 5 update

For some reason our Asterisk box is doing something really unusual following applying a routine update to CentOS 5 on Monday.

We have Asterisk 1.4.2 and its been working great for years. But now when the phone system receives an incoming SIP call, its not providing any audible dial sound to any caller. It is recognizing the incoming call, and after no answer for about 5 rings or so, it goes to voice mail. But there is no audible ‘ring’ to the caller. Just nothing – blank, empty silence.

Of course any automated answering system (ie. business phone menu, etc.) that we have works just fine. Its just the lines that go directly to an internal phone that are no longer providing any audible ring which is sending a message to the caller that their call didn’t go through.

Does anyone have any idea what might cause this?


Asterisk replying to wrong port for NOTIFY messages

See the following SIP trace.
Where in the world does Asterisk get port 1025 to respond to?
This is asterisk 1.6.x.


Polarity Reverseal….with analog line

Hi !
I ma having trouble with my PTSN line. When I call to my asterisk I get this..

isr2=XX isr3=Y

I have just built a new system using an HP DL360G7 with a TE420 T1 card,
and this is the first system using a generation 7 server. I’m not sure
whether that is an issue or not.

I am using Asterisk 1.2, and Zaptel with patches for GEN5 of
the TE420 card. I have successfully used this combination on several
systems based on the DL360G6 and TE420(gen5), which have been in
production for many months now.

However, on the new server, while doing loopback testing, I have found
that several minutes after starting Zaptel and Asterisk, I start to get
several console and syslog messages per second of the form:

card 0 span N: isr2=XX isr3=Y

where N can be 0, 1, 2 or 3; XX can be 03, 40, 80, 83, C0 or C3; Y is
usually 0 or 2, but occasionally 3.

I have no idea what these numbers mean, except that in the code, the
message is output if isr2 is non-zero or if isr3&8 is non-zero.

I don’t know whether this behaviour is caused by cross-connecting the
ports using T1 crossovers (port 1 to 3 and 2 to 4, with 3 and 4 set to
pri_net instead of pri_cpe), and would disappear when connecting to
real T1 lines, or is caused by the new hardware.

Once the messages have started, they continue even if I stop Asterisk;
in order to stop them I need to shut down Zaptel too.

Originally I had the following in zaptel.conf:


And then, wondering if it was to do with timing slips, tried this:


That didn’t help, so I then tried this:


That seems to have helped at the moment, but I don’t know whether that
is coincidence or to be expected.

Any advice would be greatly appreciated!

I’m not able at present to move to DAHDI or a newer Asterisk.