Nuevo parche polaridad para Asterisk 1.4

Actualización final (19-dic-2007): A punto para las navidades, han incluido finalmente el parche tanto en la rama 1.4 como el el trunk. La versión 1.4.16 ya lo trae incluido. Gracias a fidojones por el aviso en los comentarios ;)

Volvemos a la carga. Desde que actualizar a la 1.4.x he notado que en ocasiones las llamadas entrantes que colgaban mientras estaban en cola, llegaban a sonar en los teléfonos. Pasaba pocas veces, quizás recibo pocas llamadas ;), pero después de recibir correos apuntando en la misma dirección, me dispuse a revisar el amado y odiado chan_zap.c. (Por cierto, en openpbx^H^H^H^H^H callweaver lo están reescribiendo desde 0)Resulta que se revirtieron algunos cambios necesarios para que funcione bien en las líneas de Telefónica de España. Las llamadas entrantes, una vez que se descuelgan con Answer(), no detectan el cuelgue remoto. No ocurría lo mismo con las llamadas que no se han contestado aún.

En cualquier caso, aquí os dejo el parche. Si va bien, lo intentaremos meter de nuevo en el svn ;)Parche chan_zap.c rama 1.4 version4

Descargar chan_zap.c-1.4-polarity-v5.diff

Para aplicarlo:

$ cd /usr/src/asterisk$ patch -p0 < /ruta/al/chan_zap.c-1.4-polarity-v5.diff

A continuación, recompilar, reinstalar y reiniciar asterisk, probar si funciona, y dejar un comentario

Versiones anteriores:

Actualizado (5 horas después de la publicación) : Como casi siempre, las primeras versiones nunca fueron buenas… Al corregir este fallo, introduje otro con las llamadas salientes… Corregido en la versión 2 del parche.

Actualización (12 de mayo): Según confirme Jose L. Villalon en los comentarios, el parche también funciona con asterisk 1.2.18. Habrá que ver a partir de qué versión de asterisk es necesario parchear.

Actualización (25 de junio): Gracias a SuD, que nos comenta acerca de un parámetro, polarityonanswerdelay, que tiene un valor por defecto demasiado alto, y que podría traer problemas al ignorarse ciertos cambios de polaridad. Para resultados óptimos, añadir polarityonanswerdelay=1 a vuestro zapata.conf (antes de la línea channel=> correspondiente).

Actualización (29 de junio): Adaptado a asterisk svn r72609. No se pierden los valores de answeronpolarityswitch, hanguponpolarityswitch ni polarityonanswerdelay al hacer un reload. Se contenmpla la detección de colgado dentro de la rutina de detección de callerid, según parche proporcionado por SuD.

Actualización (19 de julio): Adaptado a asterisk svn r75893.

Actualización (20 de julio): He abierto el bug #10238 en bugs.digium.com, para intentar que incluyan este parche en el código de asterisk y no tener que parchear cada nueva versión. Si estás interesado, deja allí tu experiencia con el parche.

Escrito por julianjm el 9/05/2007. |
Tags: Asterisk, Parche, Polaridad

76 Comments »

Bueno pues como siempre, has dado en el clavo. Ya tengo mi Asteris 1.4.4 con el parche y ese fallo ya está corregido.

Demomento no he detectado ningun problema mas con los cambios de polaridad.

Saludos.-

Comment by Juan I. Gonzalez — 9 May 2007 @ 18:42
Pues entonces te recomiendo que actualices con la versión 2 del parche.

La primera llamada saliente seguramente te funcione bien, pero la segunda no detectará el _descuelgue_ remoto y se colgará después del timeout.

Es lo que tiene ser betatester

Comment by julianjm — 9 May 2007 @ 20:45
JEJE, ya se sabe las cosas del directo …

Bueno pues nada ya esta parcheada y actualizada a la v2 y aparente mente funciona todo ok.

Saludos.-

Comment by Juan I. Gonzalez — 9 May 2007 @ 23:56
Gracias

Comment by Iñaki Baz — 10 May 2007 @ 8:33
Tras probar la deteccion de colgado en mi asterisk (1.2.18) sin que detectara la inversion de polaridad correctamente, he aplicado el parche y ha funcionado sin problemas.

Gracias por todo

Un saludo.

Comment by Jose L. Villalon — 12 May 2007 @ 13:15
Vaya lio. Tengo un TDM400P con FXO. Tenemos una linea de telefonica y otra de jazztel.

Telefonica genera inversiones:
RING on 1/1!
704747736 Polarity reversed (1 -> -1)
NO RING on 1/1!
704754825 Polarity reversed (-1 -> 1)

Jazztel no genera inversiones:
RING on 1/2!
NO RING on 1/2!

He activado la opcion “busydetect” con “busycount=3″, y aun asi no siempre funciona. Soy capaz de colgar las llamadas diciendo de viva voz “pi-pi-pi-pi”, pero a veces no es capaz de detectar el cuelgue de las llamadas entrantes. Me deja los buzones de voz con 30 segundos de pi-pi-pi…

He probado asterisk 1.4.4, y 1.5.5 con y sin parche. Seguire haciendo pruebas, que creo que me estoy liando yo solo…

Comment by SuD — 22 June 2007 @ 12:54
Encontré 2 problemas nuevos cuando asterisk acepta una llamada entrante e inmediatamente el llamador cuelga. Estoy con asterisk 1.4.5 + tu parche.

- polarityonanswerdelay, que por defecto vale 600 lo pongo a 0 (en zapata.conf). De lo contrario si se cuelga antes de 600ms de llamada se ignora la inversion. No lo he probado mucho pero de momento no me da problemas tenerlo a 0.

- Cuando esta leyendo el CID hay veces tambien ignora la inversion. En chan_zap.c:6360 (aprox) muestra un mensaje “Got event(%d)…” pero no hace nada mas.
He añadido esto y parece que funciona:
if (res == ZT_EVENT_POLARITY) {
callerid_free(cs);
ast_hangup(chan);
return NULL;
}

Comment by SuD — 25 June 2007 @ 20:11
Hola SuD,

Gracias por tu comentario. No me acordaba del polarityonanswerdelay, y la verdad es que como dices, tiene un valor demasiado alto. Actualizo el post para reflejarlo.

Respecto a las líneas que has añadido, podrías hacer un diff -u del chan_zap original y del modificado?

Gracias de nuevo,
Julián J. M.

Comment by julianjm — 25 June 2007 @ 20:32
Hmmm, corrijo…. polarityonanswerdelay tiene que ser mayor que 0 para que detecte los cuelgues en llamadas entrantes que aún no han sido contestadas.

El valor óptimo es 1:

polarityonanswerdelay=1

Comment by julianjm — 25 June 2007 @ 20:37
Lamentablemente me da esté error
Hunk #1 succeeded at 3775 (offset 12 lines).
Hunk #2 FAILED at 4066.
Hunk #3 succeeded at 6708 (offset 1 line).
1 out of 3 hunks FAILED — saving rejects to file channels/chan_zap.c.rej

[Jun 26 20:57:40] WARNING[4128]: chan_zap.c:11115 process_zap: Ignoring signalling
[Jun 26 20:57:40] WARNING[4128]: chan_zap.c:11115 process_zap: Ignoring usercallerid
[Jun 26 20:57:40] WARNING[4128]: chan_zap.c:11115 process_zap: Ignoring answeronpolarityswtich
[Jun 26 20:57:40] WARNING[4128]: chan_zap.c:11115 process_zap: Ignoring hanguponpolarityswitch
[Jun 26 20:57:40] WARNING[4128]: chan_zap.c:11115 process_zap: Ignoring polarityonanswerdelay

Comment by Carlos Yáñez del Pino — 26 June 2007 @ 19:51
Carlos, qué versión de asterisk estás utilizando?

Julian.

Comment by julianjm — 27 June 2007 @ 6:36
asterisk 1.4.5

Comment by Carlos Yáñez del Pino — 28 June 2007 @ 9:33
He encontrado un problema muy molesto de vez en cuando se desconfigura? (pdelay vuelve a valer 600 y parece ignorar las inversiones de polaridad y busydetect!)

Todo parece indicar que esto sucede cada vez que hago un “/etc/init.d/asterisk reload”, version 1.4.5 (juraria que con la 1.4.4 pasaba igual)

Comment by SuD — 28 June 2007 @ 9:43
Vale es un bug conocido. Mientras tanto me sugieren que haga los reload selectivamente desde la consola, con “module reload pbx_config.so”, etc.

http://bugs.digium.com/view.php?id=9186

Comment by SuD — 28 June 2007 @ 23:29
[…] buscadores (que sois unos cuantos), el parche actualizado estará disponible en el post anterior, Nuevo parche polaridad para Asterisk 1.4 Escrito por julianjm el 29/06/2007. Asterisk, Parche, Polaridad […]

Pingback by Julián J. Menéndez » Mejoras en la detección de inversiones de polaridad — 29 June 2007 @ 15:44
No me deja pastear el error completo, tan sólo queria decir que me da el siguiente error al aplicar el parche a la versión 1.4.7:

Hunk #5 FAILED at 10711.
Hunk #6 FAILED at 11128.

Comment by ru — 10 July 2007 @ 8:12
Parche actualizado para la revisión r74475. Supongo que funcione bien en la versión 1.4.7.

Comment by julianjm — 10 July 2007 @ 23:37
Me he vuelto loco porque había olvidado poner las líneas answeronpolarityswitch=yes y hanguponpolarityswitch=yes en zapata.conf. En cuanto las he puesto (después de aplicar el parche) todo a empezado a funcionar correctamente.

(Uso la versión 1.4.6 sobre Fedora 6)

Muchas gracias

Comment by Carlos Capote — 26 July 2007 @ 10:23
#18 Llevo un día de pruebas con el parche y creo que todavía tengo algunos problemillas. A las llamadas que entran por una de las líneas analógicas (de Telefónica España) fuera de horario laboral les doy la posibilidad de dejar un mensaje en el buzón de voz (voicemail) pulsando 1. El caso es que si pulsan 1 el mensaje que graba correctamente pero Asterisk no detecta el cuelge y la linea se queda “pillada”.

Creo que el resto de casos ya me los ha arreglado el parche. Muchas gracias

Comment by Carlos Capote — 27 July 2007 @ 15:09
Carlos, el parche en su estado actual (v5) necesita de una versión reciente de asterisk, porque uno de los problemas que solucionaba se corrigió en la versión 1.4.7 o 1.4.8 ( si mal no recuerdo). De ahi que si utilizas el parche con una versión antigua, puedes tener problemas.

Comment by julianjm — 27 July 2007 @ 15:20
Muy buenas Julián,

Tenías razón. He actualizado a la 1.4.9 y ya parece que va bien aunque sigo teniendo un problemilla que no sé si tendrá que ver con el parche de polaridad o no.

El problema que tengo ahora es con las llamadas salientes. Escucho tono aunque el destino esté comunicando. De hecho, si llamo a un móvil y desde el móvil se rechaza la llamada sigo Asterisk me sigue dando tono hasta que cuelgo yo. ¿Puede tener que ver con la polaridad, o es otro problema diferente?

Muchas gracias

Comment by Carlos Capote — 7 August 2007 @ 16:11
Carlos, es una mezcla de 2 problemas:

1) El teléfono que utilizas no soporta “early media”. ¿Escuchas los mensajes del tipo “el movil al que llama está apagado o fuera de cobertura”?

2) Efectivamente, es imposible detectar cuándo te rechazan la llamada… No es un problema del parche. La única forma es usando busydetect, y no es fiable 100%.

Comment by julianjm — 7 August 2007 @ 17:00
Respecto a lo 1º, no, no escucho esos mensajes. Respecto a lo 2º que dices tienes razón, lo he “medio apañado” añadiendo busydetect=yes y busycount=6. Muchas gracias

Comment by Carlos Capote — 8 August 2007 @ 6:45
Estoy teniendo bastante problemas al parchear un asterisk, instalado mediante BRISTUFF, con la version 1.4.2 de asterisk. me da un error en el segundo bloque de parcheo, pero he conseguido parchear yo a mano el fichero fuente, aun asi cuando compilo, asterisk me dice que no existe CHA ZAP., que version he de utilizar?, ¿ No utilizais bristuff para soporte RDSI en ninguno de los casos?

Comment by David — 9 August 2007 @ 12:12
Hola David, Esa versión es algo antigua, así que igual tienes más suerte con las primeras versiones del parche (v1, 2 o 3).

Respecto al soporte RDSI, yo prefiero mISDN:
1) Funciona bien (no digo que bristuff vaya mal, pero)
2) Chan_misdn viene de serie con asterisk. Bristuff es muy invasivo, como estás comprobando.
3) No tienes porqué usar una versión de asterisk antigua (temas de seguridad, etc)

Comment by julianjm — 9 August 2007 @ 13:03
Hola,

¿Alguién sabe o ha verificado si este patch funciona con la Asterisk 1.2.24 ?

Gracias,

Lluis

Comment by Lluis — 20 September 2007 @ 14:03
[…] mano del zapata.conf nos permite controlar bastante bien este aspecto que actualmente requiere del parche de Julian para que funcione […]

Pingback by SinoLogic » Review: La appliance de Digium AA50 — 9 October 2007 @ 21:06
Hola,

Tengo una instalación con el Asterisk 1.4.5 y he parcheado el chan_zap para detectar la inversión de polaridad. Hasta ahí todo bien, pero seguimos teniendo unos problemillas.

A veces cuando colgamos una llamada, mi extensión vuelve a sonar, descuelgo pero se escucha el tono de llamada. Hemos comprobado que no se trata de una nueva llamada entrante. ¿Será que no detecta bien el colgado de la llamada inicial?

Saludos.

Comment by Oscar — 10 October 2007 @ 15:53
Hola Oscar… pues a decir verdad a mi también me ocurre a veces, pero no le había dado mayor importancia. No he conseguido averiguar porqué asterisk detecta una nueva llamada. He intentado reproducir manualmente el problema, pero no me sale.

Tienes tu un escenario que provoce siempre este comportamiento?

Julian J. M.

Comment by julianjm — 10 October 2007 @ 20:07
Hola,

Pues la verdad es que no siempre sucede.
Yo creo que, cuando sucede, es por lo siguiente:

Entra una llamada en el Asterisk, éste la dirige a la extensión apropiada (en este punto se hace el puenteo entre el Zap de la línea y el Zap de la extensión). Durante la conversación todo va ok. Pero a la hora de colgar, si cuelga antes la extensión, Asterisk no cuelga el Zap de la línea lo suficientemente rápido, con lo cual vuelve a hacer el puenteo entre ese Zap y el Zap de la extensión. La extensión vuelve a sonar un par de veces pero lo cogemos y nos da tono de llamada.

Esto no siempre sucede, aunque intentemos reproducir el escenario.

En el zapata utilizo el answeronpolarityswitch y hanguponpolarityswitch. NO utilizao el busydetect ni el busycount. Pero no creo que sean necesarios.

Saludos.

Comment by Oscar — 11 October 2007 @ 9:08
Hola,

Hemos conseguido reproducir el problema.

Resulta que sucede siempre que en una llamada, cuelga antes la extensión interna. Entonces, se vuelve a hacer el bridge entre el zap de la línea externa y el zap de la extensión interna. Os adjunto las trazas que salen en la consola del Asterisk:

— Starting simple switch on ‘Zap/14-1′
[Oct 15 16:33:29] NOTICE[9370]: chan_zap.c:6361 ss_thread: Got event 18 (Ring Begin)…
[Oct 15 16:33:31] NOTICE[9370]: chan_zap.c:6361 ss_thread: Got event 2 (Ring/Answered)…
— Executing [s@entrada:1] Dial(”Zap/14-1″, “Zap/3|15|tTr”) in new stack
— Called 3
— Zap/3-1 is ringing
— Zap/3-1 is ringing
— Zap/3-1 answered Zap/14-1
— Hungup ‘Zap/3-1′
== Spawn extension (entrada, s, 1) exited non-zero on ‘Zap/14-1′
— Hungup ‘Zap/14-1′
— Starting simple switch on ‘Zap/14-1′
[Oct 15 16:34:03] WARNING[9376]: chan_zap.c:6501 ss_thread: CallerID returned with error on channel ‘Zap/14-1′
— Executing [s@entrada:1] Dial(”Zap/14-1″, “Zap/3|15|tTr”) in new stack
— Called 3xit
— Zap/3-1 is ringing
— Zap/3-1 is ringing
— Zap/3-1 answered Zap/14-1
— Hungup ‘Zap/3-1′
== Spawn extension (entrada, s, 1) exited non-zero on ‘Zap/14-1′
Hungup ‘Zap/14-1′

Comment by Oscar — 15 October 2007 @ 14:49
Oscar, gracias por la información… Voy a ver si lo puedo reproducir aquí, y encuentro la forma de arreglarlo.

Saludos

Comment by julianjm — 15 October 2007 @ 15:06
Pues no me sale… No consigo que se inicie una nueva llamada.

1) Hago una llamada entrante (desde un móvil)
2) Suenan las extensiones internas
3) Contesto
4) Cuelgo la extension interna
5) Cuelgo la llamada externa
6) No ocurre nada fuera de lo normal

Son estos los pasos que sigues tu?

Comment by julianjm — 15 October 2007 @ 15:30
Si, esos son los pasos. Yo también lo intenté reproducir con una TDM400P pero nada.

Nosotros tenemos el siguiente escenario:

1-. Utilizamos una TDM2400P con cancelador de eco.
2-. Utilizamos la detección de inversión de polaridad
3-. Para hacer las transferencias utilizamos el hookflash
4-. Los teléfonos analógicos son los Domo2 de telefónica.
5-. En el zapata.conf tenemos:

[channels]

context=default
language=es
signalling=fxo_ks
transfer=yes
threewaycalling=yes
relaxdtmf=yes
echocancel=yes
echocancelwhenbridged=yes
callgroup=2
pickupgroup=2
channel => 1-4,7-12

context=privadas
language=es
signalling=fxo_ks
transfer=yes
threewaycalling=yes
relaxdtmf=yes
echocancel=yes
echocancelwhenbridged=yes
callgroup=2
pickupgroup=2
channel => 5,6

context=entrada
language=es
signalling=fxs_ks
group=1
inmediate=yes
answeronpolarityswitch=yes
hanguponpolarityswitch=yes
channel => 13-16

Comment by Oscar — 15 October 2007 @ 15:34
Que raro… Puede que la TDM2400 sea más sensible a este problema, porque te puedo asegurar que con la TDM400 también ocurre, aunque nunca he conseguido provocarlo.

Podrías enviarme por email la siguiente información?
* Activa el debug para el módulo de la tdm. Deberías ver los cambios de polaridad en /var/log/messages
* En el CLI de asterisk, active el debug y el verbose.
CLI> set debug 99
CLI> set verbose 99

Provoca el bug. Y envíame los fragmentos pertinentes de /var/log/asterisk/full y /var/log/messages

Qué versión de asterisk usas? Podrías probar con la última de la serie 1.4?

Comment by julianjm — 15 October 2007 @ 15:56
Hola,

Tengo un “problemilla” con las transferencias de llamadas en teléfonos analógicos. Actualmente las estamos haciendo pulsando el botón de colgado (hookflash) para que la tarjeta detecte que queremos hacer una transferencia. Sé que también se puede hacer configurando una serie de teclas para que Asterisk detecte que queremos hacer una transferencia. El problema es que al utilizar el hookflash, cuando realmente queremos colgar debemos esperar al menos un par de segundos para que la tarjeta sepa que realmente queremos colgar y no realizar una transferencia. ¿Hay alguna forma de que el colgado y descolgado sea más rápido? Es decir, que puedas colgar y descolgar “rápido” y que la tarjeta no interprete que quieres hacer una transferencia sino colgar realmente.

Gracias y un saludo.

Comment by Oscar — 17 October 2007 @ 10:11
Oscar, en el zapata.conf hay una serie de parámetros para controlar esos tiempos:

; A variety of timing parameters can be specified as well
; Including:
; prewink: Pre-wink time (default 50ms)
; preflash: Pre-flash time (default 50ms)
; wink: Wink time (default 150ms)
; flash: Flash time (default 750ms)
; start: Start time (default 1500ms)
; rxwink: Receiver wink time (default 300ms)
; rxflash: Receiver flashtime (default 1250ms)
; debounce: Debounce timing (default 600ms)

Yo empezaría bajando el rxflash y/o rxwing, ya que el pulso que genera la tecla R es muy corto, con 100 o 150 tendría que ser suficiente, todo corte que supere esos milisegundos, se considera cuelgue.

Comment by julianjm — 17 October 2007 @ 11:00
HOla Julian,

He estado jugando con los parámetros rxflash y rxwink, he llegado a 128 ms, que es el umbral en el que me detecta la señal de la techa R. Pero el problema es que no me da la señal para hacer la transferencia, sino que me cuelga la llamada y me sale un “Resource busy or unavailable”.
Seguiré probando…

Comment by Oscar — 17 October 2007 @ 11:53
Hola de nuevo,

He estado probando un montón de valores para esos parámetros pero no consigo que funcione la R del teléfono. Me sale el siguiente error:

WARNING[2241]: chan_zap.c:1616 zt_set_hook: zt hook failed: Device or resource busy

He estado mirando por ahí en foros y parece ser que la gente lo soluciona con un parche. ¿Sabeis algo de esto?

Comment by Oscar — 17 October 2007 @ 14:17
Oscar, creo que has bajado demasiado el rxwing/rxflash. Tiene que ser lo más bajo posible, pero siempre y cuando te detecte la tecla R como HookFlash, es decir, que te de tono de invitación a marcar para hacer una transferencia.

Respecto a #39, he visto que hay un parche, pero que no llegaron a a aplicar porque causaba conflictos con la señalización e&m.

Cuando tenga un rato, le echo un vistazo.

Comment by julianjm — 17 October 2007 @ 15:43
Hola,

Tengo un problemilla con el CallerID en las transferencias. La situación es la siguiente:

1-. Un número externo llama a la centralita
2-. La extensión A coge la llamda. En su display puede ver el número externo.
3-. La extensión A hace una transferencia atendida con la extensión B. La extensión B ve en su display el número externo.

En el punto 3, la extensión B no debería ver el número de la extensión A? Una vez transferida la llamada sería cuando le aparecería el número externo, no?

Saludos.

Comment by Oscar — 23 October 2007 @ 11:16
Oscar, actualmente no existe esa funcionalidad. Sin embargo, el otro día me encontré con un parche para implementar lo que se conoce como “Remote Pary Identification”. Es exactamente lo que planteas.
Formará parte de asterisk 1.6, pero hay un parche para la 1.4.13. Si lo pruebas ya nos contarás ;

http://bugs.digium.com/view.php?id=8824

Comment by julianjm — 23 October 2007 @ 13:27
Gracias Julián. En cuanto lo pruebe os comentaré si ha funcionado.

Otro temilla, para detectar bien el CallerID que nos manda telefónica por una línea analógica, basta con la siguiente configuración en el zapata.conf?

cidsignalling=v23
cidstart=ring

Es que tenemos una instalación en la que no conseguimos ver el CallerID. Hemos comprobado que sí está llegando conectando un teléfono directamente a la línea telefónica.

Gracias y un saludo.

Comment by Oscar — 24 October 2007 @ 7:10
Oscar, esa configuración te funciona en otras instalaciones? Es la misma compañía telefónica?
Da asterisk algún error, o tarda más de la cuenta en contestar la llamada?

Comment by julianjm — 24 October 2007 @ 7:33
No tenemos ese mismo escenario en otra instalación. Esas líneas son de telefónica.

El Asterisk no da ningún error, lo que si le pasa es que lleva 2 tonos de retraso, es decir, tú llamas a la centralita pero la extensión destino no suena hasta pasados 2 tonos de llamada. No sé si esto tiene que ver con algún problema en el CallerID o es el tiempo que tarda la tarjeta en hacer el puenteo entre un zap y el otro.

Comment by Oscar — 24 October 2007 @ 7:54
El problema lo tienes en cidsignalling. Con V23 no funciona. Prueba con:

cidsignalling=bell

Ese debería funcionarte, ya que es el que asterisk tiene por defecto.

Julian J. M.

Comment by julianjm — 24 October 2007 @ 8:00
Hola, Julian

Actualmente, dispongo de 16 fXO en una tdm2400 con cancelación de eco hardware de 128 ms, asterisk 1.4.13 y zaptel 1.4.5.1.

El problema lo tengo cuando una de las 16 FXO falla o no esta conectada, asterisk no lo detecta y es imposible realizar una llamada saliente ya que se queda intentando hacer la llamada por el canal zaptel erroneo.

¿Se puede solucionar este problemilla?

Gracias,

Lluís

Comment by Lluis — 28 October 2007 @ 19:50
Lluis,

Si un módulo FXO falla, el problema ya no es de software ;). Es como tener un disco duro con sectores defectuosos, y en lugar de reemplazarlo por uno nuevo, intentar parchear el software para que no los utilice. Solo te dará problemas en el futuro.

En cambio, para detectar las líneas desconectadas, hay una opción de compilación en channels/chan_zap.c, ZAP_CHECK_HOOKSTATE, que comprueba si el canal tiene voltaje. Si no lo tiene, se supone que está desconectado, y no se utiliza ese canal.

Comment by julianjm — 29 October 2007 @ 0:13
Hola,

Efectivamente, después de indagar por google encontré lo del ZAP_CHECK_HOOKSTATE pero….también encontré esto

http://bugs.digium.com/view.php?id=8290&nbn=7

El tema es que tengo que utilizar las 16FXO como llamada de grupo ZAP/g5 y el ZAP_CHECK_HOOKSTATE debería funcionar bien…

A ver si consigo algo más

Gracias,

Lluís

Comment by Lluis — 29 October 2007 @ 8:40
Hola,

Como ya he contado en mensajes anteriores, tengo una instalación con una TDM2400P que me está dando algunos problemillas. A ver si a alguno le pasa lo mismo o sabe como puedo solucionarlo.

El problema es el siguiente: “Llamo a la centralita, me coge una extensión interna y hablamos sin problema. Pero si cuelga antes la extensión interna y luego cuelgo yo, Asterisk vuelve a hacer sonar la extensión interna como si fuera una nueva llamada”.

Inicialmente esto también nos pasaba, pero instalamos el parche para detección de la inversión de la polaridad y la detección del callerID. En ese momento, Telefónica no tenía activado el servicio de identificación de llamada. En ese momento nos funcionaba todo bien.

Posteriormente, Telefónica activó el servicio de identificación de llamada y fué cuando empezaron los problemas antes comentados.

¿Sabéis a que puede ser debido?

Saludos.

Comment by Oscar — 22 November 2007 @ 16:48
tENGO EL SIGUIENTE PROBLEMA
estoy estudiando ingenieria electronica y me titulo en 1 semana mas, mi problema es que mi asterisk esta salinedo a una linea analogica de PHS, que es como una linea telefonica inalambrica analoga, pero se demora como 1,5 seg en dar tono por ser inalambrica, por lo que al llamar por telefono desde mi asterik es como si estuviese pidiendo tono, ya que lo que creo es que se pierde el discado, porque el asterisk ya marco cundo la linea todavia no le da tono, alguien me podria ayudar por favor a tratar de ver como puedo decirle a mi asterisk que primero espere tono de marcado y despues que marque

un saludo desde chile
y gracias

Comment by joelo — 8 December 2007 @ 20:01
Julian He leido por todo internet y tu parece que eres el guru de asterisk, me puedes ayudar necesito resolver esto, instalo una version mas nueva, mi problema te lo conte en el post anterior…estoy un poco preocupado, esto me tien los pelos de punta…

muchas gracias julian

desde chile

Comment by joelo — 8 December 2007 @ 22:07
Joelo, solo tienes que añadir dos o tres “w” antes del número a marcar. Cada w es una espera de 0,5s. Ejemplo:

exten => _0X.,1,Dial(Zap/g0/www${EXTEN:1})

Comment by julianjm — 8 December 2007 @ 22:49
Disculpa que te moleste pero mi problema persiste, lo que pasa es que cuando marco de un softphone o un ata, llamo y espera un rato,despues se queda ahi tratando y cuando pienso que me comunique en realidad recien me da tono de marcado, he estano investigando y en indications.conf , se setea la frecuencia del dial, probe con eso y no pasa nada no se, a lo mejor no me esta reconociendo los tonos , pero lo raro es que con una linea telefonica normal estaba mas que bueno, si esta linea de phs fue lo que me ha quitado tiempo, cuando llamo hacia el asterisk ni un problema tambien…

ayudame pliss
gracias

Comment by joelo — 8 December 2007 @ 23:19
De este utstarcom no se puede marcar con cualquier telefono, como que no me reconoce un telefono analogo que instale directamente, en cambio probe otro y si pude llamar, tiene que ver con los tonos que recibe, donde es chino a lo mejor requiere tonos chinos, o sea de esa frecuencia??

que piensas tu ,la tecnologia es buena pero pucha que da dolores de cabeza

Comment by joelo — 8 December 2007 @ 23:33
el equipo es un UTstarco FSU810, es de utstarcom, es un equipo inalambrico de linea telefonica, busque pdf para enviar pero no encontre nada de este equipo

Comment by joelo — 8 December 2007 @ 23:35
Julian, gracias por tu amabilidad y para acotar el problema, a veces cuando llamo al numer 524396, que es mi telefono, lo llamo desde el asterisk, y tengo que salir con 9 para discar hacia afuera, pero no logro conectar si es que marco 9524396, pero si marco 988888524396, a veces se logra conectar y puedo llamar, yo pienso que puede ser un retardo ese, pero no resulta siempre, le coloque el retardo que me dijiste, pero no hizo nada me seguia dando tono, esta es la extension que ocupo

exten => _9.,1,Dial(Zap/1/${EXTEN:1})
exten => _9.,2,Hangup

muchas gracias julian, ojala salve de esta

Comment by joelo — 8 December 2007 @ 23:47
le hice un debug a la consola y esto fue lo que entrego

Dec 8 23:47:01 DEBUG[24967]: chan_sip.c:7276 check_user_full: Setting NAT on RTP to 0
Dec 8 23:47:01 DEBUG[24967]: chan_sip.c:10654 handle_request_invite: Checking SIP call limits for device 2030
Dec 8 23:47:01 DEBUG[24967]: chan_sip.c:6252 build_route: build_route: Contact hop:
— Executing Dial(”SIP/2030-081aa3d0″, “Zap/1/wwww524396″) in new stack
Dec 8 23:47:01 DEBUG[25076]: dsp.c:1621 ast_dsp_set_busy_pattern: dsp busy pattern set to 0,0
Dec 8 23:47:01 DEBUG[25076]: chan_zap.c:2065 zt_call: Dialing ‘wwww524396′
Dec 8 23:47:01 DEBUG[25076]: chan_zap.c:2137 zt_call: Deferring dialing…
— Called 1/wwww524396
Dec 8 23:47:02 DEBUG[25076]: chan_zap.c:4507 __zt_exception: Exception on 17, channel 1
Dec 8 23:47:02 DEBUG[25076]: chan_zap.c:3687 zt_handle_event: Got event Hook Transition Complete(12) on channel 1 (index 0)
Dec 8 23:47:05 DEBUG[25076]: chan_zap.c:4507 __zt_exception: Exception on 17, channel 1
Dec 8 23:47:05 DEBUG[25076]: chan_zap.c:3687 zt_handle_event: Got event Dial Complete(9) on channel 1 (index 0)
Dec 8 23:47:05 DEBUG[25076]: chan_zap.c:1554 zt_enable_ec: Enabled echo cancellation on channel 1
Dec 8 23:47:05 DEBUG[25076]: chan_zap.c:1570 zt_train_ec: Engaged echo training on channel 1
Dec 8 23:47:07 DEBUG[25076]: chan_zap.c:4507 __zt_exception: Exception on 17, channel 1
Dec 8 23:47:07 DEBUG[25076]: chan_zap.c:3687 zt_handle_event: Got event Dial Complete(9) on channel 1 (index 0)
Dec 8 23:47:07 DEBUG[25076]: chan_zap.c:1534 zt_enable_ec: Echo cancellation already on
Dec 8 23:47:07 DEBUG[25076]: chan_zap.c:3771 zt_handle_event: Done dialing, but waiting for progress detection before doing more…
— Zap/1-1 answered SIP/2030-081aa3d0
Dec 8 23:47:07 DEBUG[24967]: chan_sip.c:1413 __sip_ack: Stopping retransmission on ‘b520bf760466e707@bmJfanVydHViaWEuY250LnRlbHN1ci5jbA..’ of Response 2: Match Found

en esta ultima parte me da recien tono para marcar, cundo yo ta he marcado

muchas gracia julian

Comment by joelo — 9 December 2007 @ 2:50
Parche aplicado en Asterisk 1.4.16 al fin

2007-12-13 21:28 +0000 [r92815] Tilghman Lesher

* channels/chan_zap.c: Properly initialize polarity statuses, so
that they are detected properly. Reported by: julianjm Patch by:
julianjm (Closes issue #10238)

Comment by fidojones — 19 December 2007 @ 11:12
¿Significa eso que a partir de la 1.4.16 ya no es necesario instalar el parche?

Comment by Carlos Capote — 19 December 2007 @ 17:17
Efectivamente.

Comment by julianjm — 19 December 2007 @ 17:39
Hola a todos

Nosotros estamos teniendo en una instalación el mismo problema que comentaba Oscar en un post anterior.

Llamo al asterisk y la operadora responde. Ella cuelga y en la consola vemos que asterisk cuelga. Cuando yo cuelgo, el asterisk detecta una inversión de polaridad y la linea vuelve a sonar. Esa es la llamada “fantasma”.

Hemos estado comparando con lo que pasa en nuestra oficina, y es curioso. En nuestro caso, cuando la operadora cuelga asterisk no cuelga. En realidad el canal sigue abierto hasta que el que ha llamado cuelga (entonces el asterisk detecta la inversión y cuelga). Esto tiene cierta lógica con lo que pasa en una línea analógica en casa: la línea no se cuelga hasta que cuelga el que ha llamado.

En el caso que falla, me da la sensación de que cuando la operadora cuelga y el asterisk cuelga, el canal sigue activo a nivel del operador. Lo que ocurre es que cuando el que ha llamado cuelga, se provoca la inversión de polaridad del colgado (la que debería usarse para detectar el colgado), y eso es lo que “despierta” al asterisk como una llamada nueva (que en realidad no existe).

La verdad es que es raro, porque no nos ha pasado en ninguna otra instalación (al menos hasta ahora…). Teníamos la 1.2 y hemos actualizado todo a la 1.4.16, pero el problema persiste

¿A alguien más le pasa? No sé si Oscar lo resolvió finalmente….

Un saludo

Alberto

Comment by Alberto Iglesias — 20 December 2007 @ 9:41
Alberto, es precisamente al contrario. Acabo de hacer la prueba con mi centralita:

1) Llamo desde el móvil. (Starting simple switch on Zap/4-1). También se produce una inversión de polaridad.
2) Contesto la llamada desde una extensión
3) Cuelgo la extensión. En asterisk se hace el cuelgue, el canal queda libre (aunque en realidad aún no lo esté). En ningun momento se genera una inversion de polaridad (aún).
4) Cuelgo en el móvil. Veo la inversion de polaridad. Asterisk _ni se inmuta_.

Como le comentaba a javivi, para localizar el bug hacen falta los logs, tanto de /var/log/messages como de /var/log/asterisk/full. Pero para el primero hay que habilitar el debug, cargando el módulo wctdm con debug=1.

Comment by julianjm — 20 December 2007 @ 10:05
Hola de nuevo

Creo que ya has hablado con javivi. Hemos estado hoy todo el día haciendo pruebas y la verdad es que es rarrro, rarro, rarro….

Tal y como nos dijiste, activamos el debug=1 en el wctdm24xxp (es una TDM800P) y vemos las inversiones 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!

Seguimos la secuencia que tú comentabas, y las inversiones de polaridad se cumplen tal y como dices, pero no sé por qué leches cuando recibe la inversión de polaridad del golgado interpreta que es una llamada nueva. Hemos dado doscientas mil vueltas al extensions y al zapata, pero la verdad es que todo parece estar bien y seguir la secuencia lógica… hasta que cuelgas.

Para probarlo ahora tenemos una línea a la que llamamos, se escucha la mósica de espera durante 5 segundos y nos cuelga. En cuanto colgamos nosotros… Casper nos llama de nuevo.

Lo hemos estado comparando con el asterisk de nuestra oficina, y lo único que vemos raro es los valoras absolutos de la inversión de polaridad. Me explico, en nuestra oficina, al recibir la llamada el cambio es de (1) a (-1) y al colgar es de (-1) a (1). Sin embargo, el la instalación “maldita” se produce al revés, al llamar es de (-1) a (1) y al colgar pasa de (1) a (-1). Supuestamente lo que importa es la inversión de polaridad, y no los valores absolutos, pero ya se me están acabando las ideas y de momento es lo único que no me cuadra.

Si no vemos nada más, tendremos que probar a cambiar la polaridad en los PTR de Ono, y ver si al entrar al revés lo hace bien. Se podría hacer algún cambio en asterisk para interpretarlo al revés? Evidentemente, ahora no tenemos acceso a la oficina del cliente.

Lo siguiente que se nos ocurre es cambiar la tarjeta por si es un problema hardware, aunque se me hace un poco raro….

Cualquier idea será bien recibida…

Un saludo y gracias…

Comment by Alberto Iglesias — 21 December 2007 @ 21:35
Tengo la version 1.4.9 y el problema que tengo es esté

El teléfono que utilizas no soporta “early media”. ¿Escuchas los mensajes del tipo “el movil al que llama está apagado o fuera de cobertura”?

¿Este problema depende del teléfono que llama o de la línea?

Comment by Carlos Yáñez de Pino — 14 March 2008 @ 0:07
Las líneas analógicas tienen todas early media… Desde que se acaba de marcar, asterisk “escucha” lo que hay en la línea. Desde el punto de vista de asterisk, es early media hasta que se detecta la inversión de polaridad y el canal pasa a modo “Answered”.

Pero también depende del teléfono desde el que llamas, ya que tiene que permitir la reproducción de audio antes de que esté oficialmente contestada la llamada.

Comment by julianjm — 20 March 2008 @ 17:22
Saludos he estado revisando su blog y creo que aca podre lograr una solucion a mi problema tengo un asterisk conectado con un gateway los canales de salida son celulares pero no me dan reversa de polaridad y el billing se activa cuando se termina de marcar el numero eso hace que la llamada se facture y antes de que sea realizada medi los voltajes de la llamada y son los siguientes linea stand by -48 dc cuando la llamada es direccionada se pone -7 dc y asi hasta terminar la llamada vuelve a -48 dc.

Comment by Walter Hernandez — 10 April 2008 @ 17:13
Walter, mucho me temo que no hay solución a tu problema, ya que esos 7 voltios que comentas, los tienes nada más contestar la línea, no cuando contestan en el otro extremo. Sin inversiones de polaridad no hay forma (fiable) de detectar el inicio de la conversación.

Comment by julianjm — 10 April 2008 @ 17:29
Hola!

A ver si alguien puede ayudarme

Mi asterisk no detecta los cambios de polaridad en un caso muy concreto:
1) Llamo desde mi centralita (ya sea via ip o con las lineas zap)
2) Hablo perfectamente con mi interlocutor (siempre que sea telefono fijo)
3) Cuelga él antes que yo.
En ese caso mi linea no detecta el colgado.

Si me llaman de fuera, entonces si que mi centralita detecta el colgado, cuelgue quien cuelgue primero.

Tengo una asterisk: 1.4.17-1
Una Digium 410P

Mi zapata.conf =
[trunkgroups]

[channels]

language=es
context=from-pstn
signalling=fxs_ks
immediate=no
progzone=es
callprogress=no

usecallerid=yes
cidsignalling=v23
cidstart=ring
useincomingcalleridonzaptransfer=yes
callerid=asreceived

echocancel=256
echocancelwhenbridged=no
echotraining=no
rxgain=1
txgain=1

;#################################
answeronpolarityswitch=yes ;#
hanguponpolarityswitch=yes ;#
polarityswitchondelay=1 ;#
;#################################

group=0
callgroup=1
pickupgroup=1
channel => 1
channel => 2

Alguna idea para poder detectar el cambio de polaridad?
Es que yo ya no puedo mas, me estoy quedando sin ideas

Comment by Oberon1900 — 12 April 2008 @ 17:13
Hola Julian:

Tengo un Asterisk con una TDM808P (8 FXO), que se alimenta de 8 extensiones que saco de una planta telefónica Hibrida Panasonic, ya que todavía no puedo migrar toda la empresa a Asterisk. El problema es que cuando levanto una llamada externa algunas llamadas se me cortan inesperadamente. Revisando el CDR veo que esta llamada se me registra como NO ANSWER a pesar de haber sido contestada. No se si esto también tiene que ver con lo del cambio de polaridad del que han hablado, tengo las opciones de answeronpolarityswitch=yes,
hanguponpolarityswitch=yes y polarityswitchondelay=1 en zapata.conf.

Comment by Juan Agudelo — 15 April 2008 @ 20:24
Mi versión de Asterisk es la 1.4.18

Comment by Juan Agudelo — 15 April 2008 @ 20:26
Hola Juan!

Puedes postear tu zapata.conf o si quieres poner el wctdm en modo debug y veras porque cuelga (o porque no descuelga).

Para ponerlo en modo debug:
1) /etc/init.d/asterisk stop
2) rmmod wctdm
3)lsmod wctdm debug=1
4) /etc/init.dasterisk start

y tendras información en /var/log/messages

Comment by Oberon1900 — 16 April 2008 @ 8:12
Gracias:

Ensayo y les cuento…

Comment by Juan Agudelo — 16 April 2008 @ 21:43
Tenia una tarjeta TDM400P y la polaridad funcionaba correctamente, cambie a una TDM2400 a la cual conecto 2 troncales de la PSTN, pero no cuelga la llamada si alguien llama aun cliente SIP(xlite) o en forma inversa siempre y cuando sea por SIP, de SIP a SIP si cuelga, anexo la info que tengo, alguien concera el problema la versiona que he estado empleando es 1.4.21.1

context=users
language=es
signalling= fxs_ks
group= 2
inmediate=yes
echocancel=yes
callerid= asreceived
callwaiting= no
callprogress= yes ; muestra el tiempo de llamada
answeronpolarityswitch= yes
hanguponpolarityswitch= yes
polarityonanswerdelay= 1
;busydetect= yes
;busycount= 6
transfer=yes
channel => 1
channel => 2

Comment by sergio roman j. — 24 July 2008 @ 22:17
He instalado una T1 en mi asterisk. Las llamadas salen perfectamente, pero las llamadas entrantes desde el punto de vista del que genera la llamada, no timpbra y luego de un silencio como de unos 10 segundos se queda en reorder o 120 ipm (pi, pi, pi, pi…). Desde el punto de vista del que recibe, suena el telefono definido, pero una vez contestado, luego de un silencio determinado, suena tambien el reorder. Tengo la señalizacion loop start. No he salido a camino hasta el momento. Si alguien puede ayudar gracias por adelantado.

Comment by yrving — 5 August 2008 @ 6:02
julian tengo la version 1.4.21.2 de asterisk , en ciertos foros dicen que esta version no necesita correccion de polaridad tengo activado el answeronpolarityswitch=yes
hanguponpolarityswitch=yes
,no tengo problema para tarificar sin embargo si se me queda ocupada la linea analogica con las llamadas entrantes ……

que me recomiendas para esta situacion , aplico un parche o ¿o cual crees que puede ser el problema? te agradezco por la ayuda

Comment by mauricio — 9 December 2008 @ 14:58