Tzafrir Cohen wrote:
Hmmm... what version of asterisk is it?
This reminds me of a bug that was fixed very early in 1.4 and also in
later 1.2 .
In any case, this description suggests that we should not rely too much
on whatever is written in the config files and check what is actually
happening.
So could you please provide a trace (verbose lever 3)?
asterisk:~# asterisk -rvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Asterisk 1.4.16.2, Copyright (C) 1999 - 2007 Digium, Inc. and others.
Created by Mark Spencer <[EMAIL PROTECTED]>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty'
for details.
This is free software, with components licensed under the GNU General
Public
License version 2 and other licenses; you are welcome to redistribute
it under
certain conditions. Type 'core show license' for details.
=========================================================================
== Parsing '/etc/asterisk/asterisk.conf': Found
== Parsing '/etc/asterisk/extconfig.conf': Found
Connected to Asterisk 1.4.16.2 currently running on asterisk (pid = 4364)
Verbosity was 4 and is now 48
-- Starting simple switch on 'Zap/3-1'
-- Executing [EMAIL PROTECTED]:1] Dial("Zap/3-1", "Zap/g3/110") in
new stack
[Feb 5 13:04:31] DEBUG[27875]: dsp.c:1682 ast_dsp_set_busy_pattern:
dsp busy pattern set to 520,500
[Feb 5 13:04:31] DEBUG[27875]: chan_zap.c:1954 zt_call: Dialing '110'
[Feb 5 13:04:31] DEBUG[27875]: chan_zap.c:2030 zt_call: Deferring
dialing...
-- Called g3/110
-- Zap/7-1 answered Zap/3-1
[Feb 5 13:04:32] DEBUG[27875]: chan_zap.c:2781 zt_answer: Took
Zap/3-1 off hook
[Feb 5 13:04:32] DEBUG[27875]: chan_zap.c:3274 zt_bridge: master: 3,
slave: 7, nothingok: 0
[Feb 5 13:04:32] DEBUG[27875]: chan_zap.c:3289 zt_bridge: Stopping
tones on 3/0 talking to 7/0
[Feb 5 13:04:32] DEBUG[27875]: chan_zap.c:3301 zt_bridge: Stopping
tones on 7/0 talking to 3/0
[Feb 5 13:04:32] DEBUG[27875]: chan_zap.c:3107 zt_link: Making 7
slave to master 3 at 0
[Feb 5 13:04:32] DEBUG[27875]: chan_zap.c:1262 conf_add: Added 20 to
conference 9/3
[Feb 5 13:04:32] DEBUG[27875]: chan_zap.c:1262 conf_add: Added 18 to
conference 9/7
-- Native bridging Zap/3-1 and Zap/7-1
[Feb 5 13:04:36] DEBUG[27875]: chan_zap.c:1420 zt_enable_ec: Echo
cancellation already on
[Feb 5 13:04:36] DEBUG[27875]: chan_zap.c:3051 zt_unlink: Unlinking
slave 7 from 3
[Feb 5 13:04:36] DEBUG[27875]: chan_zap.c:1294 conf_del: Removed 20
from conference 9/3
[Feb 5 13:04:36] DEBUG[27875]: chan_zap.c:1294 conf_del: Removed 18
from conference 9/7
-- Hungup 'Zap/7-1'
== Spawn extension (internal, 9110, 1) exited non-zero on 'Zap/3-1'
-- Hungup 'Zap/3-1'
asterisk*CLI> module reload
So far, that's the way it should be. After lots of data from the log, I
pick up the phone again and dial and get:
-- Starting simple switch on 'Zap/2-1'
-- Executing [EMAIL PROTECTED]:1] Dial("Zap/2-1", "Zap/g3/110") in
new stack
[Feb 5 13:07:52] DEBUG[28162]: chan_zap.c:1862 zt_call: FXO: setup
deferred dialstring: 110
-- Called g3/110
-- Zap/1-1 is ringing
-- Zap/1-1 is ringing
-- Hungup 'Zap/1-1'
== Spawn extension (internal, 9110, 1) exited non-zero on 'Zap/2-1'
-- Hungup 'Zap/2-1'
So before the reload dialing to Zap/g3 resulted in Zap/7-1 being used,
after the reload it results in Zap/1-1 being used.
I really don't see how it helps, but maybe more experienced eyes can tell.
Shachar
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
