SIP channels colgados Rx:BYE y asterisk DeadLock

[alphil]

Saludos a todos. De nuevo tengo que pedir vuestras opniones y/o
consejos.
Tengo montado: Debian 6 (32-bits) , libpri-1.4-current, dahdi-linux-
complete-current, asterisk 1.6.2.18.1 con addons (también probé el
asterisk 1.8.4.3). Es una instalación nueva para una oficina pequeña
10 ext. SIP, 2 RDSI y una RTB-FAX. Se montó, se compiló sin ningún
problema. Funcionó perfectamente en "pruebas". Pero, el primer día en
"real", cuando la gente empezó a usar telefonos: transferir,
recuperar, aparcar, etc., llega un momento, cuando todo lo que va por
SIP, deja funcionar. Es decir, entran llamadas de la calle y suena
extensión de operadora, pero no se puede descolgar la llamada. Tampoco
deja llamar entre extensiones, ni consultar Voicemail, nada, pero
NINGUNA extensión. Entrando en CLI: sip show channels - hay unos 3-4
canales con el Last Message Rx:BYE. En el panel de la operadora de
Cisco SPA508G con botonera BLF, están leds rojos (InUse) de las
extensiones BYE, pero están colgadas fisicamente.
Total, intento a desbloquear las extensiones:
hangup request SIP/XXX - no va
core restart now - no va
/etc/init.d/asterisk restart - no va
kill asterisk_pid - no va
Unica forma de reiniciar es kill -9 asterisk_pid. Luego volvemos a
ejecutarlo y todo va bien, a menos que hay que reiniciar el Cisco
SPA508G, porque quedan leds BLF en rojo.
Mientras pasa eso, comprobamos el rendimiento del sistema: RAM, CPU,
HDD - todo correcto. En full log - no hay ningún error.
Lo primero que hicimos es un downgrade de Asterisk de 1.8.4.3 a
1.6.2.18.1 y la misma tarde vuelve a caer. En tres dias llevamos 7
reinicios.
La configuración es sencilla - lo que entra por RDSI, va a la
operadora Cisco SPA508G, la operadora lo distribuye entre las
extensiones. Apenas hay 5 llamadas simultaneas.
Examiné ese foro y ví varios topics parecidos. La gente consigue
solucionarlo con los scripts que matan los canales colgados o
estableciendo rtptimeout corto. En mi caso - no hay forma de tumbar el
canal por el software. Y cuando llega el 'rtptimeout' recibo el error:
"Disconnecting call 'SIP/XXX-xxxxxxx' for lack of RTP activity in 60
seconds", pero el canal queda activo (BYE)
Alguna opnion ???
Gracias.

[Germán Aracil]

Espera a que solucionen un par de bugs que no han sacado aun en la .3,
porque están en pruebas.
A mi me pasaba, con chan_local mezclando con sip.

El 30/06/11 00:48, alphil escribió:

[Germán Aracil]

También puedes bajarte del svn la 1.8. Mira esto:

https://issues.asterisk.org/jira/browse/ASTERISK-18026

El 30/06/11 00:48, alphil escribió:

[alphil]

On 30 jun, 01:28, Germán Aracil <gara...@tucall.com> wrote:
> Espera a que solucionen un par de bugs que no han sacado aun en la .3,
> porque están en pruebas.
> A mi me pasaba, con chan_local mezclando con sip.

En que versión ? Tienes algún Cisco SPA5XX. En mi caso es, un teléfono
el que mas movimientos hace.

https://issues.asterisk.org/view.php?id=18403
Aquí veo que pasa algo parecido con Blind Transfer y un Cisco 7941.
El problema es que el error mio no lo puedo reproducir. No consigo
encontrar las circustancias. Pero un par de veces al día pasa seguro.


>

[alphil]

Revisando otros foros, encuentro comentarios, que algunos consiguen
solucionar las situaciónes parecidas, desactivando BLF en Cisco
Attendat Console.
Por desgracia, no puedo permetir realizar esa prueba. Lo que puedo
hacer, es esperar hasta el sabado y actualizar asterisk hasta 1.8.5-
rc1, ya que veo que hay muchas cosas corregidas, comparando con
1.8.4.4
http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-1.8.5-rc1-summary.html
Por otra parte, da miedo montar una RC1 para un sistema en
producción.

[Aldo Alexander Leyva Alvarado]

Tuve un problema similar con la versión 1.8.3.3, 1.8.3.4 al final era un problema de timing. Checa en el CLI que sale cuando le das: timing test

--
Este email pertenece a la lista de Asterisk-ES (http://www.asterisk-es.org)

~~~ Normas de la lista Asterisk-ES: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Para anular la suscripción: asterisk-es...@googlegroups.com

[alphil]

fpbx*CLI> timing test 1000
Attempting to test a timer with 1000 ticks per second.
Using the 'timerfd' timing module for this test.
It has been 1000 milliseconds, and we got 1000 timer ticks

No se si la respuesta es correcta. Es normal que usa "timerfd" en vez
de DAHDI ?

On 1 jul, 03:20, Aldo Alexander Leyva Alvarado <aleyva2...@gmail.com>
wrote:

> >http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asteris...

[Saúl Ibarra Corretgé]

Aupa,

2011/7/1 alphil <alp...@teleline.es>:

> fpbx*CLI> timing test 1000
> Attempting to test a timer with 1000 ticks per second.
> Using the 'timerfd' timing module for this test.
> It has been 1000 milliseconds, and we got 1000 timer ticks
>
> No se si la respuesta es correcta. Es normal que usa "timerfd" en vez
> de DAHDI ?
>

TimerFD es el más eficiente y el que más prioridad tiene, por lo que
si tienes DAHDI y TimerFD se usará TimerFD.

Pero con TimerFD se han reportado problemas de deadlocks (actualmente
hay parches en el reviewboard). Para usar el timing de DAHDI tienes
que deshabilitar TimerFD explicitamente:

noload => res_timing_timerfd.so

en el modules.conf

--
/Saúl
http://saghul.net | http://sipdoc.net

[Aldo Alexander Leyva Alvarado]

A mi tener timerfd me dejaba la pbx inestable, con los problemas que comentas, cambialo a DAHDI en  /etc/asterisk/modules.conf ponle noload => res_timing_timerfd, baja  y levanta nuevamente el servicio.

Saludos,

http://comunidad.asterisk-es.org/index.php?title=Lista:normas-asterisk-es

[alphil]

fpbx*CLI> timing test 100
Attempting to test a timer with 100 ticks per second.
Using the 'DAHDI' timing module for this test.
It has been 1009 milliseconds, and we got 101 timer ticks

fpbx*CLI> timing test 1000
Attempting to test a timer with 1000 ticks per second.

Using the 'DAHDI' timing module for this test.
It has been 1000 milliseconds, and we got 1001 timer ticks

Pues, la semana que viene, veré resultados. Ya os digo algo.


On 1 jul, 17:03, Aldo Alexander Leyva Alvarado <aleyva2...@gmail.com>

[alphil]

Quiero agradecer a todos los participantes de este tópic, llevo 2
semanas sin DeadLock (tras usar DAHDI como timing module), aunque dejo
este tema abierto hasta septiembre, por el siguiente motivo. El día
cuando apliqué el cambio, era el primer día de vacaciones y el volumen
de las llamadas se ha reducido a 1/3 de lo normal y no se puede
comparar la situación "antes de" y "despues de". La primera semana de
septiembre reportaré como va el asunto.