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

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

Ensayo y les cuento…

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

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.

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

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.

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?

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…

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.

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

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)

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

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

muchas gracias julian, ojala salve de esta