Inversión de polaridad y llamadas fantasma
bauer
Desde hace un tiempo llevamos arrastrando este problema y, aunque en
un post anterior comenté una solución "parche" que funcionaba, parece
que ahora no funciona y tenemos que encontrar una solución.
Llevamos unos días analizando el tema y haciendo pruebas, y aunque
todo parece que debería ir bien, seguimos igual. Os resumo lo que
tenemos ahora, la secuencia que seguimos y el problema:
Tenemos una centralita con tres líneas analógicas con salto. La
tarjeta es una Digium TDM800P con 4 FXO, el asterisk y zaptel están
actualizados a la última versión del 1.4. Para las pruebas, hemos
creado un contexto especial para la última de las líneas con el
siguiente dialplan:
[pruebas]
exten => s,1,Answer()
exten => s,n,WaitMusicOnHold(5)
exten => s,n,HangUp()
exten => h,1,HangUp()
Es decir, llamamos a la línea, el asterisk nos contesta, nos pone la
música en espera durante 5 segundos y nos cuelga. En ese momento, los
canales quedan liberados y todo parece correcto. Lo más divertido es
que cuando cuelga el que ha llamado, el asterisk interpreta que ha
entrado una llamada nueva y reproduce la misma secuencia. Cuando
trasladas esto al comportamiento real de la centralita en el cliente,
se traduce en que cada vez que alguien cuelga antes que el que ha
llamado, entra una llamada nueva que no es real. Esto sólo pasa en
llamadas entrantes, ya que en salientes cuando cuelgas se libera la
línea analógica (manda el que ha llamado).
El zapata para esa línea lo tenemos así:
[channels]
language=es
progzone=es
musiconhold=default
context=incoming
callprogress=no
usecallerid=yes
hidecallerid=no
switchtype=national
;Pruebas
group=3
signalling=fxs_ks
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
;busydetect=no
;busycount=5
answeronpolarityswitch=yes
hanguponpolarityswitch=yes
faxdetect=no
callwaiting=yes
context=pruebas
channel=>8
Hemos activado el debug=1 en el módulo wctdm24xxp y vemos que la línea
tiene inversión de polaridad...
Dec 21 22:21:48 debian kernel: RING on 1/8!
Dec 21 22:21:48 debian kernel: 3737694 Polarity reversed (-1 -> 1)
Dec 21 22:21:49 debian kernel: NO RING on 1/8!
Dec 21 22:22:02 debian kernel: RING on 1/8!
Dec 21 22:22:02 debian kernel: 3741139 Polarity reversed (1 -> -1)
Dec 21 22:22:02 debian kernel: NO RING on 1/8!
De hecho, todo parece comportarse correctamente y seguir la secuencia
lógica, pero en cuanto cuelgas entra la llamada de Casper. Hemos
probado a desactivar el uso de inversión de polaridad y todo sigue
igual. Hemos probado quitando diferentes combinaciones de HangUp,
quitando el Answer, hemos conectado una extensión IAX remota simulando
la operadora y lo mismo (con Answer inicial y sin él). La misma
situación en nuestra oficina sigue la misma secuencia y funciona
correctamente (no hace caso a la inversión de polaridad del colgado).
Lo único diferente son los valores absolutos de las inversiones de
polaridad. Es decir, en nuestra oficina se producen las mismas
inversiones de polaridad pero a la inversa, al llamar pasa de 1 a -1 y
al colgar pasa de -1 a 1. Entiendo que debería dar igual, porque lo
que importa es que se invierta la polaridad y no los valores inicial y
final, pero a estas alturas ya me vale cualquier cosa. El lunes
probaremos a cambiar la polaridad en los PTR de Ono, pero no estoy muy
convencido.
He estado pensando algún parche temporal hasta encontrar el orígen
real del problema, y se me ocurren las siguientes ideas:
- Que cuando la operadora cuelgue el teléfono, se retarde un tiempo
antes de que el asterisk cuelgue. De este modo, daríamos tiempo a que
cuelgue el que ha llamado y no habría problema. He probado a poner
Wait(5) en el s y en el h, pero los ignora. En cuanto cuelgas, el
asterisk cuelga.
- Otra idea sería detectar en el dial plan el tiempo desde el último
colgado en esa línea, de manera que si la nueva llamada se produce en
menos de 5 segundos tras el último colgado, la ignore. Mi idea es
guardar en una variable el valor temporal del último colgado para
compararlo cuando entra una nueva llamada. Estoy investigando como
hacerlo, pero no tengo mucha experiencia en dialplan y tengo mucho que
aprender.
Resumiendo (...a buenas horas), por un lado está encontrar la causa
del problema real (las líneas de momento las he descartado porque las
inversiones de polaridad las hace cuando debe, quizá la tarjeta?...) y
por otro conseguir implementar alguno de los parches que he comentado.
Cualquier ayuda o pista en uno de estos caminos lo agradeceré
enormemente porque os podeis imaginar que el cliente está
"encantado"...
Perdón por el tocho, pero quería detallar bien el problema para que se
entendiera...
Un saludo y gracias
Alberto
Elio Rojano
--
http://www.sinologic.net/
Julian J. M.
Cuando cuelgan en el otro extremo, suena el teléfono, aunque solo sea
un poco?
Julián J. Menéndez
Julian J. M.
> Dec 21 22:21:48 debian kernel: 3737694 Polarity reversed (-1 -> 1)
> Dec 21 22:21:49 debian kernel: NO RING on 1/8!
> Dec 21 22:22:02 debian kernel: RING on 1/8!
> Dec 21 22:22:02 debian kernel: 3741139 Polarity reversed (1 -> -1)
> Dec 21 22:22:02 debian kernel: NO RING on 1/8!
>
> De hecho, todo parece comportarse correctamente y seguir la secuencia
> lógica, pero en cuanto cuelgas entra la llamada de Casper. Hemos
No es correcto... El problema es que no debería generarse un evento
RING a las 22:22:02, ya que el NO RING que le sigue es el que provoca
que asterisk se vaya OFFHOOK (vamos, que descuelgue e inicie la
ejecución del dialplan).
He estado haciendo pruebas en mi línea de casa, y pasa pocas veces. En
9 de cada 10 llamadas (como los dentistas) solo veo la inversión de
polaridad después de colgar el móvil... pero hay un caso en el que sí
veo el RING, la polaridad, y el NO RING. Por eso a mi también, aunque
esporádicamente, me entraban llamadas fantasma...
La solución es bajar la sensibilidad de la detección, de forma que
siga detetando bien los casos reales, pero no se deje engañar tan
facilmente por pequeñas variaciones de voltaje enla línea (asociadas
al cambio de polaridad final)
En lo que viene siendo un parche, quedaría algo como:
Index: wctdm.c
===================================================================
--- wctdm.c (revision 2759)
+++ wctdm.c (working copy)
@@ -862,7 +862,7 @@
res = wc->reg0shadow[card];
if ((res & 0x60) && wc->mod[card].fxo.battery) {
wc->mod[card].fxo.ringdebounce += (ZT_CHUNKSIZE * 16);
- if (wc->mod[card].fxo.ringdebounce >=
ZT_CHUNKSIZE * 64) {
+ if (wc->mod[card].fxo.ringdebounce >=
ZT_CHUNKSIZE * 128) {
if (!wc->mod[card].fxo.wasringing) {
wc->mod[card].fxo.wasringing = 1;
zt_hooksig(&wc->chans[card],
ZT_RXSIG_RING);
Vamos, cambiar ese 64 por un 128... De hecho, mirando el código del
módulo wctdm24xx, trae este valor por defecto.
Saludos
Julián J. Menéndez
bauer
He editado el wctdm.c y he cambiado el valor DEFAULT_RING_DEBOUNCE de
64 a 128, he recompilado todo y.... no chuta (Casper sigue ahí...)
La tarjeta es una TDM800, y he visto que usa el wctdm24xxp (es en este
módulo en el que tengo que activar el debug=1 para ver las inversiones
de polaridad). De todos modos y como comentas, en este módulo el valor
por defecto ya es 128.
En el debug de /var/log/messages seguimos con el p... RING...
Dec 23 10:39:55 debian kernel: RING on 1/8!
Dec 23 10:39:55 debian kernel: 36406841 Polarity reversed (-1 -> 1)
Dec 23 10:39:55 debian kernel: NO RING on 1/8!
Dec 23 10:40:06 debian kernel: RING on 1/8!
Dec 23 10:40:06 debian kernel: 36409608 Polarity reversed (1 -> -1)
Dec 23 10:40:06 debian kernel: NO RING on 1/8!
Será cuestión de ir subiendo el valor 256, etc.????
Un saludo
Alberto
Julian J. M.
RING's reales... Será cuestión de que vayas subiéndolo poro a poco
hasta que consigas detectar el 100% de los reales y el 0% de los
fantasmas...
De cualquier modo, algo raro hay en esa línea. :)
Julián J. Menéndez
bauer
POR FINNNN!!!!! He puesto el valor a 256 tanto en wctdm como en
wctdm24xxp (creo que el que influye en el caso de la TDM800 es el que
pongas en wctdm24xxp) y ahora funciona perfectamente. He hecho un
montón de llamadas y nunca me ha fallado. Igual puede fallar alguna,
pero si es puntual me doy con un canto en los dientes. La duda que me
queda es si será de las líneas o de la tarjeta. Apostaría por las
lineas...
De hecho, a toro pasado estaba pensando que el problema de estos
rebotes ya lo habíamos visto alguna vez con centralitas Alcatel, pero
de manera puntual (como te pasa a ti, Julián). Os aseguro que con
Alcatel nos hubiéramos vuelto locos y no hubiéramos conseguido nada.
Un punto más para Asterisk (aunque ya no le hace falta...).
Y por supuesto..... ahora mismo estoy de rodillas mirando hacia
Fuerteventura haciendo alabanzas...XD En serio, muchas gracias Julián.
Llevábamos bastante tiempo con este tema, y nos estaba volviendo
locos, a parte de que el cliente ya se estaba empezando a mosquear.
Por otro lado, he estado trabajando en una de las soluciones para
parchear el tema hasta que encontráramos la solución real. Aunque
ahora ya no hace falta, me gustaría comentarla porque la tenía casi
funcionando salvo un aspecto.
El dialplan era el siguiente:
exten => s,1,GotoIf($["${GLOBAL(${CHANNEL}_TIEMPO)}" == ""]?2:3)
exten => s,n,Set(GLOBAL(${CHANNEL}_TIEMPO)=$[${EPOCH}-100])
exten => s,n,Set(GLOBAL(${CHANNEL}_DIF)=$[${EPOCH}-${GLOBAL($
{CHANNEL}_TIEMPO)}])
exten => s,n,NoOp(El tiempo desde el colgado es ${${CHANNEL}_DIF})
exten => s,n,GotoIf($[${GLOBAL(${CHANNEL}_DIF)} <= 20]?10)
exten => s,n,NoOp(El callerid es ${CALLERID(number)})
exten => s,n,GotoIf($[${LEN(${CALLERID(number)})} != 0]?9)
exten => s,n,Set(CALLERID(all)="Desconocido")
exten => s,n,Dial(IAX2/30,45,tTwW)
exten => s,n,HangUp()
exten => h,1,GotoIf($[${GLOBAL(${CHANNEL}_DIF)} <= 20]?2:4)
exten => h,n,Set(GLOBAL(${CHANNEL}_TIEMPO)="")
exten => h,n,Goto(5)
exten => h,n,Set(GLOBAL(${CHANNEL}_TIEMPO)=${EPOCH})
exten => h,n,HangUp()
Como veréis, básicamente tengo una variable por canal que almacena el
instante temporal del último colgado, cuando entra una llamada nueva,
calculo el tiempo desde el último colgado y si es menor que 20
segundos interpreto que es la llamada fantasma, por lo que cuelgo la
llamada y reseteo el tiempo para que la próxima llamada que entre me
la acepte fijo (ya he colgado la llamada fantasma, por lo que la
próxima la tiene que aceptar).
Lo he estado probando entre ayer y hoy y me funciona bien salvo en un
caso: cuando primero cuelga el que ha llamado (no hay llamada
fantasma) también se almacena el tiempo y te quedas 20 segundos sin
poder recibir llamadas.
Lo que he intentado hacer pero he sido incapaz es saber desde el
dialplan quién ha colgado. He probado con HANGUPCAUSE, pero se refiere
a la causa del colgado y no a quién ha colgado. ¿Hay alguna variable o
manera de saber quién ha colgado la llamada? Si consiguiera eso,
cuando el colgado lo ha hecho el llamante podría saltarme todo el tema
de la comparación de tiempos.
Gracias a Julián ahora esto ya no me hace falta para este caso, pero
en el futuro nunca se sabe...
Un saludo y de nuevo muchas gracias
Alberto
PD: Gracias a ti también Elio por molestarte en contestar...
Ramses II
Un comentario sobre tu dialplan...
> -----Mensaje original-----
> De: aster...@googlegroups.com
> [mailto:aster...@googlegroups.com] En nombre de bauer
> Enviado el: domingo, 23 de diciembre de 2007 12:21
> Para: asterisk-es
> Asunto: [Asterisk-ES] Re: Inversión de polaridad y llamadas fantasma
Mira, la prioridad "n" te ayuda a que si insertas alguna línea en medio, no
tengas que renombrar toda esa extensión, ¿no?.
En la forma que lo tienes hecho, sigues teniendo que renombrar, no las
prioridades, pero sí los saltos que haces a prioridades concretas de la
extensión.
En mi opinión, yo cambiaría los saltos a prioridades concretas por saltos a
etiquetas. Poniéndote un ejemplo con parte de tu dialplan, si no me
equivoco, te quedaría:
exten => h,1,GotoIf($[${GLOBAL(${CHANNEL}_DIF)} <= 20]?SIGUE:FINALIZA)
exten => h,n(SIGUE),Set(GLOBAL(${CHANNEL}_TIEMPO)="")
exten => h,n,Goto(5)
exten => h,n,Set(GLOBAL(${CHANNEL}_TIEMPO)=${EPOCH})
exten => h,n(FINALIZA),HangUp()
Saludos,
Ramses