Configuración de canales con DAHDI
Daniel Bareiro
Hace unos días me compré una placa OpenVox A400P con un módulo FXS y
otro FXO para hacer algunas pruebas en mi instalación de Asterisk de
casa. Estoy usando Asterisk 1.4.24.1 con DAHDI Linux 2.1.0.4 y DAHDI
Tools 2.1.0.2 en Debian GNU/Linux Lenny.
Estuve leyendo "The future of telephony" y este [1] documento buscando
información en Internet sobre la con figuración de ambos tipos de
canales.
El hardware fue reconocido sin problemas por parte del sistema operativo
y DAHDI:
# lspci
[...]
00:0a.0 Network controller: Tiger Jet Network Inc. Tiger3XX Modem/ISDN
interface
[...]
# cat /proc/dahdi/*
Span 1: DAHDI_DUMMY/1 "DAHDI_DUMMY/1 (source: HRtimer) 1" (MASTER)
Span 2: WCTDM/4 "Wildcard TDM400P REV E/F Board 5"
1 WCTDM/4/0 FXSKS RED
2 WCTDM/4/1 FXOKS
3 WCTDM/4/2
4 WCTDM/4/3
# dahdi_hardware
pci:0000:00:0a.0 wctdm+ e159:0001 Wildcard TDM400P REV E/F
# dahdi_cfg -vvvvvvv
DAHDI Tools Version - 2.1.0.2
DAHDI Version: 2.1.0.4
Echo Canceller(s):
Configuration
======================
Channel map:
Channel 01: FXS Kewlstart (Default) (Slaves: 01)
Channel 02: FXO Kewlstart (Default) (Slaves: 02)
2 channels to configure.
En los archivos de configuración hice las siguientes modificaciones:
/etc/dahdi/system.conf:
# DGB - 20090518
fxoks=2
fxsks=1
############ DGB
#[channels]
#language=en
#context=incoming
#signalling=fxs_ks
#usecallerid=yes
#hidecallerid=no
#callwaiting=yes
#callwaitingcallerid=yes
#threewaycalling=yes
#transfer=yes
#cancallforward=yes
#callreturn=yes
#echocancel=yes
#echocancelwhenbridged=yes
#rxgain=0.0
#txgain=0.0
#group=1
#pickupgroup=1
#immediate=yes
#musiconhold=default channel => 1
############ DGB
/etc/asterisk/chan_dahdi.conf:
; DGB - 20090518
group=0
signaling=fxo_ks
channel => 2
signaling=fxs_ks
channel => 1
Cargué los módulos wctdm y dahdi, pero cuando ejecuto «"dahdi show
channels» en el CLI de Asterisk, obtengo el siguiente mensaje de error:
No such command 'dahdi show channels' (type 'help dahdi show' for other
possible commands)
Supongo que más allá de no haber agregado en el archivo
/etc/asterisk/extensions.conf algo como:
exten => s,1,Wait(1) ; Wait a second, just for fun
exten => s,n,Answer ; Answer the line
exten => s,n,Dial(dahdi/2) ; zap has been changed to dahdi
exten => s,n,Hangup
exten => 1,1,Dial(dahdi/2|60|m(default)) ; zap has been changed to dahdi
exten => 1,2,hangup
la orden debería existir en la CLI. Cuál puede ser el problema? También
probé ejecutando lo siguiente en la CLI:
module unload chan_dadhi.so
module load chan_dadhi.so
Pero obtengo el siguiente mensaje de error:
[May 20 20:49:07] WARNING[23599]: loader.c:359 load_dynamic_module:
Error loading module 'chan_dadhi.so':
/usr/lib/asterisk/modules/chan_dadhi.so: cannot open shared object file:
No such file or directory
[May 20 20:49:07] WARNING[23599]: loader.c:653 load_resource: Module
'chan_dadhi.so' could not be loaded.
Esto último, aunque no estoy seguro si es la causa directa por la cual
no está accesible la orden de la CLI que mencionaba, parece ser un bug
ya que Asterisk está intentando buscar el módulo con el nombre
incorrecto: chan_dadhi.so en vez de chan_dahdi.so, estando sí este
último en el sistema de archivos.
Gracias anticipadas por responder.
Saludos,
Daniel
[1] http://bbs2.chinaunix.net/archiver/tid-1289253.html
--
Mi frase del día:
Work is the curse of the drinking classes.
-- Mike Romanoff
Daniel Bareiro - GNU/Linux registered user #188.598
Proudly running Debian GNU/Linux with uptime:
21:36:41 up 9 days, 21:55, 11 users, load average: 0.03, 0.07, 0.08
Iñaki Cívico
Error loading module 'chan_dadhi.so':
/usr/lib/asterisk/modules/chan_dadhi.so: cannot open shared object file:
No such file or directory
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkoUpYQACgkQZpa/GxTmHTcudQCeITsDhDEpfjY6pezGpGKRey3Y
KxUAoIXPhnfzU86zk/+wpgwnwR57KnE/
=PxuG
-----END PGP SIGNATURE-----
Daniel Bareiro
El jueves 21 de mayo del 2009 a las 10:13:10,
Iñaki Cívico escribió:
> Hola,
> [May 20 20:49:07] WARNING[23599]: loader.c:359 load_dynamic_module:
> Error loading module 'chan_dadhi.so':
> /usr/lib/asterisk/modules/chan_dadhi.so: cannot open shared object file:
> No such file or directory
>
> Prueba con chan_dahdi.so en lugar de chan_dadhi.so
Ufff... ahora que lo veo, no era nada de bug sino que el problema estaba
entre el teclado y la silla :-P Se ve que estaba medio dormido y escribí
el nombre al revés :-S
Ahora bien, ejecutando el:
alderamin*CLI> module unload chan_dahdi.so
alderamin*CLI> module load chan_dahdi.so
obtengo lo siguiente:
[May 21 06:07:43] WARNING[25314]: chan_dahdi.c:1233 dahdi_open: Unable
to specify channel 2: No such device or address
[May 21 06:07:43] ERROR[25314]: chan_dahdi.c:7662 mkintf: Unable to open
channel 2: No such device or address
here = 0, tmp->channel = 2, channel = 2
[May 21 06:07:43] ERROR[25314]: chan_dahdi.c:11270 build_channels:
Unable to register channel '2'
A qué puede deberse ese error? Algo incorrecto en la configuración, tal
vez?
Gracias por responder.
Saludos,
Daniel
--
Daniel Bareiro - GNU/Linux registered user #188.598
Proudly running Debian GNU/Linux with uptime:
06:09:01 up 10 days, 6:27, 11 users, load average: 0.27, 0.12, 0.09
Iñaki Cívico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkoVHEYACgkQZpa/GxTmHTe/zgCdGZj8Xw+IF75SW4hQuk80Zl6L
PEwAnijRcDKdw0+q6i8TADrkukA/Z1Iy
=41eZ
-----END PGP SIGNATURE-----
Daniel Bareiro
El jueves 21 de mayo del 2009 a las 15:04:44,
Iñaki Cívico escribió:
> > > [May 20 20:49:07] WARNING[23599]: loader.c:359 load_dynamic_module:
> > > Error loading module 'chan_dadhi.so':
> > > /usr/lib/asterisk/modules/chan_dadhi.so: cannot open shared object file:
> > > No such file or directory
> > >
> > > Prueba con chan_dahdi.so en lugar de chan_dadhi.so
> > Ufff... ahora que lo veo, no era nada de bug sino que el problema
> > estaba entre el teclado y la silla :-P Se ve que estaba medio
> > dormido y escribí el nombre al revés :-S
> >
> > Ahora bien, ejecutando el:
> >
> > alderamin*CLI> module unload chan_dahdi.so
> > alderamin*CLI> module load chan_dahdi.so
> >
> > obtengo lo siguiente:
> >
> > [May 21 06:07:43] WARNING[25314]: chan_dahdi.c:1233 dahdi_open: Unable
> > to specify channel 2: No such device or address
> > [May 21 06:07:43] ERROR[25314]: chan_dahdi.c:7662 mkintf: Unable to open
> > channel 2: No such device or address
> > here = 0, tmp->channel = 2, channel = 2
> > [May 21 06:07:43] ERROR[25314]: chan_dahdi.c:11270 build_channels:
> > Unable to register channel '2'
> >
> > A qué puede deberse ese error? Algo incorrecto en la configuración,
> > tal vez?
> Parece que no te ha creado los dispositivos. Puedes comprobarlo con ls
> -la /dev/dahdi y debería salir algo así:
> total 0
> drwxr-xr-x 2 root root 200 2009-05-18 17:37 .
> drwxr-xr-x 13 root root 3300 2009-05-18 17:37 ..
> crw-rw---- 1 root root 196, 1 2009-05-18 17:37 1
> crw-rw---- 1 root root 196, 2 2009-05-18 17:37 2
> crw-rw---- 1 root root 196, 3 2009-05-18 17:37 3
> crw-rw---- 1 root root 196, 4 2009-05-18 17:37 4
> crw-rw---- 1 root root 196, 254 2009-05-18 17:37 channel
> crw-rw---- 1 root root 196, 0 2009-05-18 17:37 ctl
> crw-rw---- 1 root root 196, 255 2009-05-18 17:37 pseudo
> crw-rw---- 1 root root 196, 253 2009-05-18 17:37 timer
>
> ¿Has arrancado con /etc/init.d/dahdi start?
Bueno, por las pruebas que estuve haciendo, parece que ya pude
solucionar este problema. Estuve investigando por varios flancos.
Primero revisando las entradas en /proc:
# cat /proc/dahdi/*
Span 1: WCTDM/4 "Wildcard TDM400P REV E/F Board 5" (MASTER)
1 WCTDM/4/0 RED
2 WCTDM/4/1
3 WCTDM/4/2
4 WCTDM/4/3
Luego de ejecutar dahdi_cfg -vvv:
# cat /proc/dahdi/*
Span 1: WCTDM/4 "Wildcard TDM400P REV E/F Board 5" (MASTER)
1 WCTDM/4/0 FXSKS RED
2 WCTDM/4/1 FXOKS
3 WCTDM/4/2
4 WCTDM/4/3
De esto pude rescatar dos cosas:
* La impresión de que era necesario ejecutar el comando dahdi_cfg para
que se apliquen sobre cada uno de los canales los tipos de
señalización especificados en /etc/dahdi/system.conf.
* La palabra «RED» desaparece al conectar a este módulo la línea
telefónica, por lo que intuyo que esto estaría significando que se
conectó la línea a un módulo operativo.
Entonces, luego de esto volví a hacer una prueba en la CLI:
alderamin*CLI> dahdi show channel
No such command 'dahdi show channel' (type 'help dahdi show' for other possible commands)
alderamin*CLI>
alderamin*CLI> module load chan_dahdi.so
alderamin*CLI> module load chan_dahdi.so
== Parsing '/etc/asterisk/chan_dahdi.conf': Found
-- Registered channel 2, FXO Kewlstart signalling
[May 24 15:04:54] WARNING[5306]: chan_dahdi.c:4090 handle_alarms:
Detected alarm on channel 1: Red Alarm
-- Registered channel 1, FXS Kewlstart signalling
-- Automatically generated pseudo channel
== Parsing '/etc/asterisk/users.conf': Found
== Registered channel type 'DAHDI' (DAHDI Telephony Driver)
== Manager registered action DAHDITransfer
== Manager registered action ZapTransfer
== Manager registered action DAHDIHangup
== Manager registered action ZapHangup
== Manager registered action DAHDIDialOffHook
== Manager registered action ZapDialOffHook
== Manager registered action DAHDIDNDon
== Manager registered action ZapDNDon
== Manager registered action DAHDIDNDoff
== Manager registered action ZapDNDoff
== Manager registered action DAHDIShowChannels
== Manager registered action ZapShowChannels
== Manager registered action DAHDIRestart
== Manager registered action ZapRestart
Loaded chan_dahdi.so => (DAHDI Telephony)
alderamin*CLI>
alderamin*CLI>
alderamin*CLI>
alderamin*CLI> dahdi show channels
Chan Extension Context Language MOH Interpret
pseudo default default
1 incomming es default
2 phones es default
Bien. Con esto queda probado que estaría funcionando, pero me quedaba la
duda de si este módulo se cargaba automáticamente durante el
bootstrapping del sistema operativo. En un principio, estuve revisando
los archivos de configuración de ejemplo que se generan durante la
instalación de Asterisk en el directorio /etc/asterisk, pero no encontré
alguna referencia. También estuve revisando el orden de los scripts de
inicio, comprobando que el script 'asterisk' se ejecuta después del
script 'dahdi'.
Hice un reboot de la instalación asegurándome previamente haber dejado
descomentada la línea con 'wctdm' en /etc/dahdi/modules y luego de
reiniciar el sistema operativo tanto la placa como los modos de
señalización sobre ambos canales se detectaron sin problemas.
Así que es un avance importante. Más aún teniendo en cuenta que ya tengo
tono en mi teléfono analógico convencional y pude llamar sin problemas a
una extensión SIP, lo cual me incentivó aún más :-)
Pero el problema que ahora estoy encontrando es que no puedo llamar
desde una extensión SIP al teléfono analógico. Si me pueden dar una mano
por este lado (configuraciones que haya puesto que sean innecesarias o
algo que podría y ser necesario y me esté faltando), me vendría bárbaro.
A continuación copio las configuraciones que estoy usando:
----------------------------------------------------------------------------
/etc/asterisk/sip.conf:
[general]
context=default
allowoverlap=no
bindport=5060
bindaddr=0.0.0.0
srvlookup=yes
mohinterpret=default
language=es
[authentication]
; DGB - 20090517
[200]
username=200
type=friend
secret=200
callerid=Daniel<200>
host=dynamic
nat=no
context=internal
mailbox=200@voicemail
callgroup=1
pickupgroup=1
[201]
username=201
type=friend
secret=201
callerid=Hector<201>
host=dynamic
nat=no
context=internal
mailbox=201@voicemail
callgroup=1
pickupgroup=1
----------------------------------------------------------------------------
/etc/asterisk/sip.extensions.conf:
[general]
static=yes
writeprotect=no
clearglobalvars=no
[globals]
CONSOLE=Console/dsp
IAXINFO=guest
username/password
TRUNK=Zap/G2
TRUNKMSD=1
[default]
; DGB - 20090517
[internal]
exten => _xxx,1,Dial(SIP/${EXTEN},15,tT)
exten => _xxx,2,VoiceMail(${EXTEN}@voicemail)
exten => _xxx,3,Playback(vm-goodbye)
exten => _xxx,4,Hangup
enten => 1010,1,Dial(DAHDI/2,15,Tr)
exten => 1010,n,Hangup
exten => *98,1,Answer
exten => *98,2,Wait(1)
exten => *98,3,VoiceMailMain(${CALLERID}@voicemail)
exten => *98,4,Hangup
exten => *600,1,Answer
exten => *600,2,Playback(demo-echotest)
exten => *600,3,Echo
exten => *600,4,Playback(demo-echodone)
exten => *600,5,Hangup
exten => _9.,1,Dial(DAHDI/1/${EXTEN:1})
exten => _9.,2,Hangup
include => phones
[phones]
include => internal
[incoming]
exten => s,1,Answer
exten => s,2,Playback(demo-echotest)
exten => s,3,Echo
exten => s,4,Playback(demo-echodone)
exten => s,5,Hangup
----------------------------------------------------------------------------
/etc/asterisk/chan_dahdi.conf:
[trunkgroups]
[channels]
context=default
switchtype=national
signalling=fxo_ls
rxwink=300
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no
; DGB - 20090518
; hardware channels
language=es
defaultzone=es
usecallerid=yes
hidecallerid=no
callwaiting=no
threewaycalling=yes
transfer=yes
echocancel=yes
echotraining=yes
inmediate=no
context=phones
signalling=fxo_ks
channel => 2 ; Telephone attached to port 2
context=incomming
signalling=fxs_ks ; Use FXS signalling for an FXS channel
channel => 1 ; PSTN attached to port 1
----------------------------------------------------------------------------
Al intentar hacer un llamado, veo en la CLI algo como lo siguiente:
[May 24 17:16:21] NOTICE[4830]: chan_sip.c:14721 handle_request_invite:
Call from '201' to extension '1010' rejected because extension not
found.
¿Será tal vez algo relacionado con las definiciones de los contextos?
Gracias por esponder.
Saludos,
Daniel
--
Mi frase del día:
BOFH excuse #361:
Communist revolutionaries taking over the server room and demanding all
the computers in the building or they shoot the sysadmin. Poor misguided
fools.
Daniel Bareiro - GNU/Linux registered user #188.598
Proudly running Debian GNU/Linux with uptime:
11:59:48 up 14 days, 12:18, 10 users, load average: 0.09, 0.11, 0.09
RamonciO
la señalización cambiada, los puertos fxs usan fxo_ks y los fxo usan
fxs_ks. Luego pones bien la señalización, pero los puertos al revés.
Debería quedar asi:
......
signaling=fxs_ks
channel => 1
signaling=fxo_ks
channel => 2
Daniel Bareiro
El martes 26 de mayo del 2009 a las 01:24:39,
RamonciO escribió:
> >/etc/asterisk/chan_dahdi.conf:
> >
> > [trunkgroups]
> >
> > [channels]
> > context=default
> > switchtype=national
> > signalling=fxo_ls
> > rxwink=300
> >
> > usecallerid=yes
> > hidecallerid=no
> > callwaiting=yes
> > usecallingpres=yes
> > callwaitingcallerid=yes
> > threewaycalling=yes
> > transfer=yes
> > canpark=yes
> > cancallforward=yes
> > callreturn=yes
> > echocancel=yes
> Revisa /etc/asterisk/chan_dahdi.conf. En el primero que pones tenías
Pero, por lo que veo, escribiste exactamente lo mismo que pegué en mi
archivo de configuración chan_dahdi.conf, solo que definiste primero el
canal 1 y luego el canal 2 (yo lo hice en el orden inverso, pero con la
señalización correcta).
De todas maneras, por la salida que mostraba que estaba observando en la
CLI, me da la impresión que se trata de alguna inconsistencia con las
definiciones de los contextos. Pero estuve revisando y no encuentro
dónde está el problema.
Por otra parte, también encontre lo siguiente, aunque no estoy seguro
que esté relacionado con el problema que estoy teniendo y sea algo más
que haya que retocar:
--------------------------------------------------------------------------------
alderamin*CLI> dialplan show internal
[ Context 'internal' created by 'pbx_config' ]
'*600' => 1. Answer() [pbx_config]
2. Playback(demo-echotest) [pbx_config]
3. Echo() [pbx_config]
4. Playback(demo-echodone) [pbx_config]
5. Hangup() [pbx_config]
'*98' => 1. Answer() [pbx_config]
2. Wait(1) [pbx_config]
3. VoiceMailMain(${CALLERID}@voicemail) [pbx_config]
4. Hangup() [pbx_config]
'1010' => 2. Hangup() [pbx_config]
'_2xx' => 1. Dial(SIP/${EXTEN}|15|tT) [pbx_config]
2. VoiceMail(${EXTEN}@voicemail) [pbx_config]
3. Playback(vm-goodbye) [pbx_config]
4. Hangup() [pbx_config]
'_9.' => 1. Dial(DAHDI/1/${EXTEN:1}) [pbx_config]
2. Hangup() [pbx_config]
Include => 'phones' [pbx_config]
-= 5 extensions (16 priorities) in 1 context. =-
--------------------------------------------------------------------------------
Como verás, no aparece la 'línea 1' donde se vincula la extensión 1010
con el canal DAHDI/2, sino directamente la 'línea 2' en la que se hace
el Hangup. Esto me llama la atención, porque en el archivo de
configuración sí está.
Gracias por responder.
Saludos,
Daniel
--
Mi frase del día:
Lo que has de decir, antes de decirlo a otro, dítelo a ti mismo.
-- Séneca. (2 a.C-65) Filósofo latino.
Daniel Bareiro - GNU/Linux registered user #188.598
Proudly running Debian GNU/Linux with uptime:
06:56:19 up 15 days, 7:14, 10 users, load average: 0.69, 0.59, 0.37
Iñaki Civico
me parece que tienes una errata en el extensions.conf
>>> enten <<<< => 1010,1,Dial(DAHDI/2,15,Tr)
exten => 1010,1,Dial(DAHDI/2,15,Tr)
por eso el parser se salta esta línea y no te aparece en el dialplan.
Saludos,
Iñaki
Daniel Bareiro
Iñaki Civico escribió:
> Hola Daniel,
Hola Iñaki.
> me parece que tienes una errata en el extensions.conf
>
> >>> enten <<<< => 1010,1,Dial(DAHDI/2,15,Tr)
>
> exten => 1010,1,Dial(DAHDI/2,15,Tr)
>
> por eso el parser se salta esta línea y no te aparece en el dialplan.
Uhhh... mirá que error pavote!! Y eso que lo revisé varias veces :-/
Te cuento que corrigiendo eso, al hacer un 'dialplan show internal'
ahora sí ya aparece esa línea. Al principio, antes de haber visto en la
CLI el dialplan, me daba la impresión que se trataría de un problema de
contextos, pero menos mal que se me ocurrió hacer un show del dialplan
desde la CLI ya que permitió acotar más la causa del problema. Con todas
estas cosas uno va aprendiendo :-)
Ahora con esto ya puedo llamar desde una extensión SIP a un teléfono
analógico y viceversa. También desde cada uno de ellos puedo hacer
llamados a la red telefónica pública. Vamos avanzando...
Probando las llamadas entrantes, la situación con la que me encontré es
que desde el teléfono desde el cual hago la prueba escucho 'tono de
llamado', pero sin que la central me responda en algún momento. De
nuevo, revisando la CLI de Asterisk, el mensaje que estoy observando es
el siguiente:
-- Starting simple switch on 'DAHDI/1-1'
[May 27 06:21:15] NOTICE[15038]: chan_dahdi.c:6830 ss_thread: Got event
18 (Ring Begin)...
[May 27 06:21:16] NOTICE[15038]: chan_dahdi.c:6830 ss_thread: Got event
2 (Ring/Answered)...
== Starting DAHDI/1-1 at incomming,s,1 failed so falling back to exten
's'
== Starting DAHDI/1-1 at incomming,s,1 still failed so falling back to
context 'default'
[May 27 06:21:16] WARNING[15038]: pbx.c:2474 __ast_pbx_run: Channel
'DAHDI/1-1' sent into invalid extension 's' in context 'default', but no
invalid handler
Parece ser que toda esta salida se estaría repitiendo por cada vez que
suena el teléfono.
Probando hacer un 'include => incoming' en el contexto default, ahora sí
me atiende el Asterisk, pero sin embargo sigo obteniendo el mensaje de
la extensión 's':
-- Starting simple switch on 'DAHDI/1-1'
[May 27 06:27:57] NOTICE[15262]: chan_dahdi.c:6830 ss_thread: Got event
18 (Ring Begin)...
[May 27 06:27:57] ERROR[15262]: callerid.c:564 callerid_feed: No start
bit found in fsk data.
[May 27 06:27:57] WARNING[15262]: chan_dahdi.c:6870 ss_thread: CallerID
feed failed: Success
[May 27 06:27:57] WARNING[15262]: chan_dahdi.c:6970 ss_thread: CallerID
returned with error on channel 'DAHDI/1-1'
== Starting DAHDI/1-1 at incomming,s,1 failed so falling back to exten
's'
== Starting DAHDI/1-1 at incomming,s,1 still failed so falling back to
context 'default'
-- Executing [s@default:1] Answer("DAHDI/1-1", "") in new stack
-- Executing [s@default:2] Playback("DAHDI/1-1", "demo-echotest") in
new stack
-- <DAHDI/1-1> Playing 'demo-echotest' (language 'es')
-- Executing [s@default:3] Echo("DAHDI/1-1", "") in new stack
Lo curioso es que luego de hacer esta prueba, no puedo volver a rutear
llamadas a la red telefónica pública. El mensaje que obtengo en la CLI
al intentar hacer esto es el siguiente:
-- Executing [9112@internal:1] Dial("SIP/201-0979bf48",
"DAHDI/1/112") in new stack
[May 27 06:29:33] WARNING[15281]: app_dial.c:1237 dial_exec_full: Unable
to create channel of type 'DAHDI' (cause 0 - Unknown)
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [9112@internal:2] Hangup("SIP/201-0979bf48", "") in new
stack
== Spawn extension (internal, 9112, 2) exited non-zero on
'SIP/201-0979bf48'
alderamin*CLI>
-- Executing [9114@internal:1] Dial("SIP/201-09778fc0",
"DAHDI/1/114") in new stack
[May 27 06:30:16] WARNING[15350]: app_dial.c:1237 dial_exec_full: Unable
to create channel of type 'DAHDI' (cause 0 - Unknown)
== Everyone is busy/congested at this time (1:0/0/1)
-- Executing [9114@internal:2] Hangup("SIP/201-09778fc0", "") in new
stack
== Spawn extension (internal, 9114, 2) exited non-zero on
'SIP/201-09778fc0'
-- Executing [9112@internal:1] Dial("SIP/201-0979bf48",
"DAHDI/1/112") in new stack
[May 27 06:30:22] WARNING[15352]: app_dial.c:1237 dial_exec_full: Unable
to create channel of type 'DAHDI' (cause 0 - Unknown)
¿Cuál puede estar siendo el problema?
Gracias por responder
Saludos,
Daniel
--
Mi frase del día:
Artificial intelligence has the same relation to intelligence as
artificial flowers have to flowers.
-- David Parnas
Daniel Bareiro - GNU/Linux registered user #188.598
Proudly running Debian GNU/Linux with uptime:
05:54:40 up 16 days, 6:13, 10 users, load average: 0.02, 0.01, 0.00
Iñaki Cívico
signalling=fxs_ks ; Use FXS signalling for an FXS channel
channel => 1 ; PSTN attached to port 1
Daniel Bareiro
El miércoles 27 de mayo del 2009 a las 12:04:01,
Iñaki Cívico escribió:
Sí, efectivamente ese era el problema que estaba teniendo. Últimamente
parece que estoy algo distraído :-|
Haciendo algunos cambios en el archivo extensions.conf para probar las
llamadas entrantes de manera que estas sean derivadas a una extensión SIP,
encontré algo que me llama la atención: si hago una prueba llamando a mi
línea desde un teléfono móvil, al atender con un softphone desde la
extensión SIP, si desde el móvil cortan la llamada, el sofphone detecta el
corte sin problemas, pero al revés no ocurre lo mismo. O sea, si corto la
llamada desde el sofphone, desde el móvil veo que que cronómetro de
duración de llamada sigue avanzando como si aún no se hubiera cortado.
¿Cuál puede estar siendo el problema?
Viendo en los logs de la CLI, me encontré con lo siguiente:
alderamin*CLI>
-- Starting simple switch on 'DAHDI/1-1'
[May 30 14:28:46] NOTICE[18535]: chan_dahdi.c:6830 ss_thread: Got event 18 (Ring Begin)...
[May 30 14:28:47] NOTICE[18535]: chan_dahdi.c:6830 ss_thread: Got event 2 (Ring/Answered)...
-- Executing [s@incoming:1] Dial("DAHDI/1-1", "SIP/201|15|tT") in new stack
-- Called 201
-- SIP/201-09243ea8 is ringing
-- Nobody picked up in 15000 ms
-- Executing [s@incoming:2] Hangup("DAHDI/1-1", "") in new stack
== Spawn extension (incoming, s, 2) exited non-zero on 'DAHDI/1-1'
-- Hungup 'DAHDI/1-1'
-- Starting simple switch on 'DAHDI/1-1'
[May 30 14:29:11] NOTICE[18544]: chan_dahdi.c:6830 ss_thread: Got event 18 (Ring Begin)...
[May 30 14:29:11] ERROR[18544]: callerid.c:564 callerid_feed: No start bit found in fsk data.
[May 30 14:29:11] WARNING[18544]: chan_dahdi.c:6870 ss_thread: CallerID feed failed: Success
[May 30 14:29:11] WARNING[18544]: chan_dahdi.c:6970 ss_thread: CallerID returned with error on
channel 'DAHDI/1-1'
-- Executing [s@incoming:1] Dial("DAHDI/1-1", "SIP/201|15|tT") in new stack
-- Called 201
-- SIP/201-09243ea8 is ringing
-- Nobody picked up in 15000 ms
-- Executing [s@incoming:2] Hangup("DAHDI/1-1", "") in new stack
== Spawn extension (incoming, s, 2) exited non-zero on 'DAHDI/1-1'
-- Hungup 'DAHDI/1-1'
-- Starting simple switch on 'DAHDI/1-1'
[May 30 14:29:36] NOTICE[18554]: chan_dahdi.c:6830 ss_thread: Got event 18 (Ring Begin)...
[May 30 14:29:36] ERROR[18554]: callerid.c:564 callerid_feed: No start bit found in fsk data.
[May 30 14:29:36] WARNING[18554]: chan_dahdi.c:6870 ss_thread: CallerID feed failed: Success
[May 30 14:29:36] WARNING[18554]: chan_dahdi.c:6970 ss_thread: CallerID returned with error on
channel 'DAHDI/1-1'
-- Executing [s@incoming:1] Dial("DAHDI/1-1", "SIP/201|15|tT") in new stack
-- Called 201
-- SIP/201-09243ea8 is ringing
-- SIP/201-09243ea8 answered DAHDI/1-1
== Spawn extension (incoming, s, 1) exited non-zero on 'DAHDI/1-1'
-- Hungup 'DAHDI/1-1'
Las líneas que estoy usando en el archivo de configuración no cambiaron
demasiado en comparación con lo que mostraba en un mensaje anterior:
[incoming]
exten => s,1,Dial(SIP/201,15,tT)
exten => s,2,Hangup
Estimo que como el timeout de la llamda es de 15 segundos, y el móvil aún
sigue llamando, eso hace que cada 15 segundos se vuelva a ejecutar
nuevamente el "switch on 'DAHDI/1-1'". Puede tener que ver con el problema
ese mensaje "exited non-zero on 'DAHDI/1-1'"?
Gracias de nuevo por responder.
Saludos,
Daniel
--
Mi frase del día:
Ni el pasado existe, ni el futuro. Todo es presente.
-- Gonzalo Torrente Ballester. (1910-????).
Daniel Bareiro - GNU/Linux registered user #188.598
Proudly running Debian GNU/Linux with uptime:
14:19:51 up 19 days, 14:38, 10 users, load average: 0.07, 0.09, 0.03
Iñaki Civico
lo que te pasa cuando llamas de un móvil es normal. Cuando cuelgas tu
teléfono sip, asterisk cuelga el canal DAHDI analógico, pero como la
llamada se ha originado desde el móvil, la llamada permanece establecida
entre el móvil y la central que tiene el bucle de abonado. Si no se
vuelve a descolgar, se cortará la llamada en el móvil cuando salte el
timeout de 60 s. en la CO del proveedor. Puedes probarlo manteniendo el
móvil después de colgar la llamada en el asterisk y verás que llega a
cortarse, lo único es que te va a costar un minuto más :-) También
puedes comprobar que durante ese tiempo 'fantasma' tu línea dará
comunicando a otras llamadas.
Daniel Bareiro
Iñaki Civico escribió:
> Hola Daniel,
Hola Iñaki
> > Haciendo algunos cambios en el archivo extensions.conf para probar
> > las llamadas entrantes de manera que estas sean derivadas a una
> > extensión SIP, encontré algo que me llama la atención: si hago una
> > prueba llamando a mi línea desde un teléfono móvil, al atender con
> > un softphone desde la extensión SIP, si desde el móvil cortan la
> > llamada, el sofphone detecta el corte sin problemas, pero al revés
> > no ocurre lo mismo. O sea, si corto la llamada desde el sofphone,
> > desde el móvil veo que que cronómetro de duración de llamada sigue
> > avanzando como si aún no se hubiera cortado. ¿Cuál puede estar
> > siendo el problema?
> lo que te pasa cuando llamas de un móvil es normal. Cuando cuelgas tu
> teléfono sip, asterisk cuelga el canal DAHDI analógico, pero como la
> llamada se ha originado desde el móvil, la llamada permanece establecida
> entre el móvil y la central que tiene el bucle de abonado. Si no se
> vuelve a descolgar, se cortará la llamada en el móvil cuando salte el
> timeout de 60 s. en la CO del proveedor. Puedes probarlo manteniendo el
> móvil después de colgar la llamada en el asterisk y verás que llega a
> cortarse, lo único es que te va a costar un minuto más :-) También
> puedes comprobar que durante ese tiempo 'fantasma' tu línea dará
> comunicando a otras llamadas.
Sí, haciendo unas pruebas más tarde el día que envié este correo, pude
comprobar que lo que comentaba también sucede con nuestro prestador de
telefonía sin un Asterisk de por medio. No me había percatado de este
detalle antes. Será que cuando uno tiene una central PBX en casa y
empieza a hacer todo tipo de pruebas, estas cosas salen al aire :-)
Gracias por responder.
Saludos,
Daniel
--
Mi frase del día:
Mal mascado y bien remojado.
Daniel Bareiro - GNU/Linux registered user #188.598
Proudly running Debian GNU/Linux with uptime:
23:22:30 up 23 days, 23:40, 10 users, load average: 0.02, 0.04, 0.06