asterisk users - Jan 2010 - Disa not fully bridging outbound call

Hello,
I have a situation where a remote worker dials in to the asterisk server, enters
the "secret code", then dials out via Disa on a PRI.  This was all
working great
until this morning.  Now the calls is placed out, connected but there is no
voice from/to either phone.  This is what shows on the CLI when the calls is
bridged at a verbose of 4 and a debug of 1:
[Jan 25 17:51:40]     -- Moving call from channel 21 to channel 2
[Jan 25 17:51:40]     -- Zap/0:2-1 answered Zap/1-1
[Jan 25 17:51:40] WARNING[5563]: chan_dahdi.c:1594 conf_add: Failed to add 20 to
conference 9/1: Invalid argument
[Jan 25 17:51:40] WARNING[5563]: chan_dahdi.c:1594 conf_add: Failed to add 20 to
conference 9/1: Invalid argument
[Jan 25 17:51:40]     -- Native bridging Zap/1-1 and Zap/0:2-1
[Jan 25 17:51:49]     -- Channel 0/1, span 1 got hangup request, cause 16
[Jan 25 17:51:49]     -- Hungup 'Zap/0:2-1'
[Jan 25 17:51:49]   == Spawn extension (from-inside-redir, 16037649936, 1)
exited non-zero on 'Zap/1-1'
[Jan 25 17:51:49]     -- Executing [h at from-inside-redir:1]
Hangup("Zap/1-1", "")
in new stack
[Jan 25 17:51:49]   == Spawn extension (from-inside-redir, h, 1) exited non-zero
on 'Zap/1-1'
[Jan 25 17:51:49]     -- Hungup 'Zap/1-1'
[Jan 25 17:51:49] WARNING[5412]: chan_dahdi.c:8615 pri_fixup_principle: Call
specified, but not found?
[Jan 25 17:51:49] WARNING[5412]: chan_dahdi.c:9759 pri_dchannel: Hangup on bad
channel 0/2 on span 1


This says it is using DAHDI but it is actually still Zaptel as I have not had
much success getting DAHDI to work on OpenSuSE, but that is another post for a
later date.

Any help is greatly appreciated.
Thank You

-- 
JohnM

John Millican wrote:
> Hello,
> I have a situation where a remote worker dials in to the asterisk server,
enters
> the "secret code", then dials out via Disa on a PRI.  This was
all working great
> until this morning.  Now the calls is placed out, connected but there is no
> voice from/to either phone.  This is what shows on the CLI when the calls
is
> bridged at a verbose of 4 and a debug of 1:
> [Jan 25 17:51:40]     -- Moving call from channel 21 to channel 2
> [Jan 25 17:51:40]     -- Zap/0:2-1 answered Zap/1-1
> [Jan 25 17:51:40] WARNING[5563]: chan_dahdi.c:1594 conf_add: Failed to add
20 to
> conference 9/1: Invalid argument
> [Jan 25 17:51:40] WARNING[5563]: chan_dahdi.c:1594 conf_add: Failed to add
20 to
> conference 9/1: Invalid argument
> [Jan 25 17:51:40]     -- Native bridging Zap/1-1 and Zap/0:2-1
> [Jan 25 17:51:49]     -- Channel 0/1, span 1 got hangup request, cause 16
> [Jan 25 17:51:49]     -- Hungup 'Zap/0:2-1'
> [Jan 25 17:51:49]   == Spawn extension (from-inside-redir, 16037649936, 1)
> exited non-zero on 'Zap/1-1'
> [Jan 25 17:51:49]     -- Executing [h at from-inside-redir:1]
Hangup("Zap/1-1", "")
> in new stack
> [Jan 25 17:51:49]   == Spawn extension (from-inside-redir, h, 1) exited
non-zero
> on 'Zap/1-1'
> [Jan 25 17:51:49]     -- Hungup 'Zap/1-1'
> [Jan 25 17:51:49] WARNING[5412]: chan_dahdi.c:8615 pri_fixup_principle:
Call
> specified, but not found?
> [Jan 25 17:51:49] WARNING[5412]: chan_dahdi.c:9759 pri_dchannel: Hangup on
bad
> channel 0/2 on span 1
> 
> 
> This says it is using DAHDI but it is actually still Zaptel as I have not
had
> much success getting DAHDI to work on OpenSuSE, but that is another post
for a
> later date.
> 
> Any help is greatly appreciated.
> Thank You
> 
As an FYI reply to my own post I was able to clear up the issue by rmmod and
restart of zaptel.  Not what I would call a good solution but it worked. Does
not tell me what caused the problem but at least the customer is happy for now.
JohnM