asterisk users - Oct 2007 - Infuriating problems: no dial tone, dropped calls, no voice: 1.2.13 and 1.4.11

Hi
I've had an asterisk setup for the past 15 months, based on the debian
asterisk packaging. Until late August of this year, I had no problems
once initial setup was complete- the system worked essentially
flawlessly.

Since August I have been having exceedingly infuriating intermittent
problems that are causing me occasional periods of nasty trouble:
1. No Dial Tone. Every Sunday night at just prior to midnight ( about
the last second before monday), the Dial tone ceases on all zap
handsets. Investigation shows that the zaptel layer is not transmitting
sound to the handset- ztmonitor shows it being sent, but nothing is
arriving at the handset. (You can also see sound being rx from the
handset). This problem has occured spontaneously at other times but the
midnight thing is just plain odd (nothing is happening on that box at
the time).
2. I tried to upgrade from the asterisk packages in debian etch (1.2.13)
to sid (1.4.11). This added new problems to the mix. Suddenly, no voice
was being offered through asterisk at all to any zap channel. I tracked
it down to my use of T/t in the Dial strings- this was somehow
preventing native bridging from occuring. This can be verified because
other call routings (e.g. IAX->zap; SIP->zap) have the same problem (and
cannot be corrected by removing a t/T because there's no native bridge).
Reverting to 1.2.13 seems to have fixed this problem. (Is this some kind
of sound path regression? Debug logging has shown nothing).
3. Finally, with 1.4.11 especially, the system seems to have been quite
unstable, with asterisk crashing (and ringing every phone in the house
incessantly- which my wife was NOT happy about), especially when two
simultaneous calls overlap in some way (this hasn't crashed 1.2.13 as
badly, but asterisk seemed to need a reset afterwards).

I suspected a dodgy channel bank ( I had a really old eBay special for
$20 which had timing problems from day 1 ) so I upgraded a little ( the
Zhone - more expensive and not super, but at least it has firmware and a
console for mgmt ). This has had some effect, but nothing has changed
about the fundamental problem (1 above).

Other hardware: the T1 interface card is the R1T1 from rhino, there is a
Wildcard TDM400P REV I, with a single FXO port for the incoming line
from the POTS. The computer itself seems quite fine, no sign of
interrupt errors or other problems with the hardware (I ran a memtest
and a cpuburn neither of which showed any issues). zttest shows nothing
unusual (99.87% iirc over about 10 minutes).

I am happy to share anything that will help resolve the issue- my feeble
C skills in attempting some printf in the ast_channel_bridge command to
see what was being chucked about pretty much failed entirely because the
timing went badly off... Trying to chuck ast_log calls in there didn't
work very well either :(

Thanks
Christian

Christian Weeks wrote:
> Hi
> I've had an asterisk setup for the past 15 months, based on the debian
> asterisk packaging. Until late August of this year, I had no problems
> once initial setup was complete- the system worked essentially
> flawlessly.
>
> Since August I have been having exceedingly infuriating intermittent
> problems that are causing me occasional periods of nasty trouble:
> 1. No Dial Tone. Every Sunday night at just prior to midnight ( about
> the last second before monday), the Dial tone ceases on all zap
> handsets. Investigation shows that the zaptel layer is not transmitting
> sound to the handset- ztmonitor shows it being sent, but nothing is
> arriving at the handset. (You can also see sound being rx from the
> handset). This problem has occured spontaneously at other times but the
> midnight thing is just plain odd (nothing is happening on that box at
> the time).
> 2. I tried to upgrade from the asterisk packages in debian etch (1.2.13)
> to sid (1.4.11). This added new problems to the mix. Suddenly, no voice
> was being offered through asterisk at all to any zap channel. I tracked
> it down to my use of T/t in the Dial strings- this was somehow
> preventing native bridging from occuring. This can be verified because
> other call routings (e.g. IAX->zap; SIP->zap) have the same problem
(and
> cannot be corrected by removing a t/T because there's no native
bridge).
> Reverting to 1.2.13 seems to have fixed this problem. (Is this some kind
> of sound path regression? Debug logging has shown nothing).
> 3. Finally, with 1.4.11 especially, the system seems to have been quite
> unstable, with asterisk crashing (and ringing every phone in the house
> incessantly- which my wife was NOT happy about), especially when two
> simultaneous calls overlap in some way (this hasn't crashed 1.2.13 as
> badly, but asterisk seemed to need a reset afterwards).
>
> I suspected a dodgy channel bank ( I had a really old eBay special for
> $20 which had timing problems from day 1 ) so I upgraded a little ( the
> Zhone - more expensive and not super, but at least it has firmware and a
> console for mgmt ). This has had some effect, but nothing has changed
> about the fundamental problem (1 above).
>
> Other hardware: the T1 interface card is the R1T1 from rhino, there is a
> Wildcard TDM400P REV I, with a single FXO port for the incoming line
> from the POTS. The computer itself seems quite fine, no sign of
> interrupt errors or other problems with the hardware (I ran a memtest
> and a cpuburn neither of which showed any issues). zttest shows nothing
> unusual (99.87% iirc over about 10 minutes).
>
> I am happy to share anything that will help resolve the issue- my feeble
> C skills in attempting some printf in the ast_channel_bridge command to
> see what was being chucked about pretty much failed entirely because the
> timing went badly off... Trying to chuck ast_log calls in there didn't
> work very well either :(
>
> Thanks
> Christian
>   
I think you should stick with 1.2 for now at least until all the bugs 
are worked out.  Stability seems to be a real issue although many would 
have you believe otherwise.

The other thing that jumps out is the exact timing of your issue in 
number 1.  Random problems  can be very difficult to track down but 
yours is consistent, so it should be pretty easy to find the culprit.  
Check your cron jobs.  If you have something running at almost midnight 
on Sunday, that is probably your issue.  Logs may be of help.

Thanks,
Steve Totaro