Problema con detección de colgado de una llamada de voip bajo Asterisk 11.15 y GXW 4232 1.0.5.5

[Miguel Alberto Sanz Pardo]

Hola buenos días,

Realmente esto tan sólo me ha pasado una vez que yo sepa pero quería comentáoslo por ver qué opiniones tenéis ya que yo no estoy seguro de qué puede haber pasado y creo que es algo que puede ser problemático si se vuelve a repetir.

Resulta que en una de las llamadas que realicé a través de un proveedor de voip es como si no se hubiera detectado el colgado y tuve que colgar mediante la consola de Asterisk,

Realicé una llamada a las 08.30 y colgué a las 08.35.

A las 9.00 fui a llamar y al tratar de llamar no me dejaba; me daba tono de llamada pero aparecía por el CLI un mensaje que decía 

NOTICE[1672][C-0000361d] chan_sip.c: Failed to place call for device Telefono042, too many calls

NOTICE[1672][C-00003620] chan_sip.c: Call from peer 'Tfn042' rejected due to usage limit of 1

¿No debería directamente haber dejado de darme tono de llamaba si el canal se quedó establecido anteriormente y no se cerró?

En el sip.conf tengo definido algo de este estilo para cada extension:

[telefonos](!)

type=friend

context=outgoing

host=dynamic

language = es

dtmfmode=rfc2833

disallow=all

allow=g729

allow=alaw

qualify=yes

canreinvite=no

busylevel=1

call-limit=1

Esta claro que de alguna forma se ha quedado pillado y no ha detectado el colgado, pero ¿Donde se supone que no lo ha detectado? ¿Qué creéis que ha podido pasar?

[Elio Rojano]

Normalmente suele deberse a que el paquete SIP que se utiliza para enviar el BYE, suele llevar alguna dirección IP en el From o algo así, que el operador no reconoce y no puede relacionar con tu conversación, con lo que no finaliza la llamada.

Esto suele pasar por no tener el externip=... correctamente en el sip.conf, así como no poner "nat=force_rport" en el contexto de definición del operador.

--
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
---
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asterisk-es...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a aster...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/asterisk-es.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Página web: http://www.sinologic.net/

Twitter: http://twitter.com/hellc2

LinkedIn: http://es.linkedin.com/in/rojano

[Miguel Alberto Sanz Pardo]

Hola Elio,

Muchísimas gracias por tu respuesta.

Por una parte, en el fichero sip.conf, en el contexto [general] tengo definido nat = force_rport,comedia (force_rport para evitar problemas de nat en SIP y comedia para evitar problemas de nat en RTP si no me confundo)

¿Sería incorrecto el no tenerlo definido en el contexto de definición del operador?

-Por otra parte tengo configurado el localnet pero no el externadd:

localnet=192.168.7.0/255.255.248.0

;externaddr = "direccion publica":5060

En esta centralita tan solo se registran equipos desde la propia LAN, de forma remota no se registra ningún equipo, de manera que no tengo redirigidos los puertos para SIP(5060) y patra RTP(10000-20000).

Si activo el campo externaddr de forma correcta , además de solucionar el problema actual, ¿Crees que puedan aparecer otro tipo de problemas en el entorno de trabajo que te acabo de comentar?

un saludo

Miguel Sanz

[Elio Rojano]

El 16 de abril de 2015, 15:52, Miguel Alberto Sanz Pardo <miguels...@gmail.com> escribió:

Hola Elio,

Muchísimas gracias por tu respuesta.

Por una parte, en el fichero sip.conf, en el contexto [general] tengo definido nat = force_rport,comedia (force_rport para evitar problemas de nat en SIP y comedia para evitar problemas de nat en RTP si no me confundo)

¿Sería incorrecto el no tenerlo definido en el contexto de definición del operador?

Si haces un sip show peer xxxxx, ahí puedes ver la configuración de NAT del operador.
Si lo pones en el general, debería estar definido también en el operador.

-Por otra parte tengo configurado el localnet pero no el externadd:

localnet=192.168.7.0/255.255.248.0

;externaddr = "direccion publica":5060

Lo del externaddr debería estar definido, ya que es la parte "dominio" de los paquetes salientes.

Si tienes problemas por tener una direccion IP dinámica, también está el "externhost" para que puedas usar un dyndns o similar, pero es importante para poder formar el paquete SIP con la dirección IP externa.

 

En esta centralita tan solo se registran equipos desde la propia LAN, de forma remota no se registra ningún equipo, de manera que no tengo redirigidos los puertos para SIP(5060) y patra RTP(10000-20000).

Si activo el campo externaddr de forma correcta , además de solucionar el problema actual, ¿Crees que puedan aparecer otro tipo de problemas en el entorno de trabajo que te acabo de comentar?

ninguno... solo beneficios.

Teniendo el localnet definido, todos los paquetes SIP que envíes entre usuarios de la red interna, serán gestionados con la IP interna y no con la externa.

 

un saludo

Miguel Sanz

--
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
---
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asterisk-es...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a aster...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/asterisk-es.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Miguel Alberto Sanz Pardo]

Pues en cuanto pueda activo el externaddr

Un saludo y gracias de nuevo Elio

[Miguel Alberto Sanz Pardo]

Por cierto Elio, ¿Sabes si existe algún parámetro en los gateways o en el mismo Asterisk el cual corte una comunicación si han pasado más de X minutos?

[Elio Rojano]

La aplicación Dial tiene el parámetro: 

   L(x[:y[:z]]):                                                                                                                                                                   

        x - Maximum call time, in milliseconds

El sip.conf tiene el rtptimeout=X, que corta la llamada si Asterisk no detecta RTP en alguno de los canales en X segundos.

En un gateway no creo que haya nada de esto.

El 16 de abril de 2015, 17:52, Miguel Alberto Sanz Pardo <miguels...@gmail.com> escribió:

Por cierto Elio, ¿Sabes si existe algún parámetro en los gateways o en el mismo Asterisk el cual corte una comunicación si han pasado más de X minutos?

--

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
---
Has recibido este mensaje porque estás suscrito al grupo "asterisk-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a asterisk-es...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a aster...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/asterisk-es.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Raúl Alexis Betancor Santana]

En asterisk ... puedes usar los valores de timeout y de duración máxima de llamada ... pero si es el gateway quien no cierra el canal tras un BYE ... seguirá con la línea abierta.

---

[Miguel Alberto Sanz Pardo]

Anda, pues desconocía ese parámetro del Dial(), mira que habré mirado veces en la wiki de Asterisk 11 la aplicación Dial()  pero no me sonaba ese parámetro ^_^

Muchas gracias Elio ;)

un saludo

Miguel Sanz

[Elio Rojano]

Déjate de wikis...

core show application Dial

[Miguel Alberto Sanz Pardo]

Hola Raúl, ¿Qué tal?

Entonces si pongo una duracion max. de 60 min por llamada, cuelgo a los 10 min. y el gateway no cierra el canal tras el BYE, ¿A los 60 min. qué ocurriría? ¿La centralita no cortaría la comunicación de manera que se liberaría ese canal que había entre terminal-Asterisk-Proveedor VOIP ya que a los 10 min. piensa que ha colgado aunque el canal esté realmente abierto?

Gracias por tu respuesta

Un saludo

Miguel Sanz

[Elio Rojano]

El 16 de abril de 2015, 18:26, Miguel Alberto Sanz Pardo <miguels...@gmail.com> escribió:

Hola Raúl, ¿Qué tal?

Entonces si pongo una duracion max. de 60 min por llamada, cuelgo a los 10 min. y el gateway no cierra el canal tras el BYE, ¿A los 60 min. qué ocurriría? ¿La centralita no cortaría la comunicación de manera que se liberaría ese canal que había entre terminal-Asterisk-Proveedor VOIP ya que a los 10 min. piensa que ha colgado aunque el canal esté realmente abierto?

nada, que seguirá abierto el canal para el gateway.

Para que el gateway cierre el canal, debe recibir su correspondiente BYE por un lado o bien el corte de la conexión de la PSTN por el otro.

Por suerte, si es una línea analógica, el operador cortará la conexión si no hay audio durante cierto tiempo.

[Miguel Alberto Sanz Pardo]

Suponiendo el peor de los casos, en el cuál se tengan bien configurados los ficheros de Asterisk y el gateway, pero en el que por alguna razón el canal sigue abierto en el gateway y el operador tiene una liínea analógica pero no es capaz de cortar a los x minutos seguidos sin detección de audio ¿Se os ocurre alguna solución posible ante este tipo de casos? Imaginad que una línea se queda abierta durante 1 día entero y la habéis tenido que cortar desde la consola.

[Raúl Alexis Betancor Santana]

ssh gateway reboot

---

De: "miguelsanzpardo" <miguels...@gmail.com>
Para: aster...@googlegroups.com

[Miguel Alberto Sanz Pardo]

Hola Raúl,

En el caso que me ocurrió en concreto, al provocar un Hangup de dicho canal abierto desde la consola pude volver a llamar desde el teléfono que estaba conectado al gateway sin necesidad de rebootar el gateway.

Con la última pregunta me refiero a que si se os ocurre alguna posible solución para evitar este tipo de problemas en caso de que el propio Asterisk no sea capaz de detectarlo, estoy pensando que crear un demonio que mire el CDR cada X tiempo podría ser una solución pero no sé si será la más eficiente (Que mire el CDR y si ve algo raro que rebootee el GW)

un saludo y gracias por tu respuesta.

[Raúl Alexis Betancor Santana]

El problema se te causa ... porque el gateway está SIEMPRE enviando RTP al Asterisk ... así que no vas a tener JAMAS un rtptimeout en ese escenario.

Es el típico problema de usar gateways ... y por eso huyo de ellos como de la peste. Si en el lado PSTN no te cortan la llamada, el gateway no la va a cortar por las buenas ... y tendrás que cerrarla tu desde el Asterisk.

Lo que puedes hacer, a modo 'protección' ... es pasarle al parámetro L del asterisk, el valor de la mediana de duración de las llamadas. Aunque acabarás con quejas de llamadas que se cortaron mientras hablaban. O establecer un timeout global ... de digamos 30 minutos ... y cortar cualquier llamada que lleve tanto tiempo.

En un flujo normal de llamadas, la situación que comentas debería de ser marginal, sino es que hay un problema grave en el lado PSTN y deberías de mirar como solucionarlo.

[Miguel Alberto Sanz Pardo]

Ha sido 1 llamada de 20000, pero ya sabes como es la ley de Murphy, y ante posibles problemas mejor tratar de evitarlos cuanto antes.

Muchas gracias por tu ayuda Raúl ;)

[Raúl Alexis Betancor Santana]

1 de 20000, lo que he dicho ... marginal ... ;)

[Miguel Alberto Sanz Pardo]

He probado con el parámetro L y creo que va perfecto para lo que quiero hacer ;)

No obstante, también he probado a poner en el sip.conf:

rtptimeout=60

rtpholdtimeout=70

y a tapar ambos micros de los dos teléfonos pero debe de seguir mandando paquetes RTP de info. porque no corta en ningún momento la comunicación al pasar los 70 segundos.

Por cierto, hablando de parámetros de timeout, ¿Conviene tener activado el parámetro rtpkeepalive(RTP) en la propia centralita(creo recordar que me dijiste que era importante que estuviera activado)? En tal caso ¿cada cuantos seg. sería recomendable el envio de keep alives? Actualmente lo tengo desactivado.

En cuanto al parámetro qualify(SIP) lo tengo igual a no en caso de los proveedores de voip para que siempre me den opción a poder llamar, no sé hasta que punto esto puede ser peligroso. Otra opción sería poner en vez de no o yes, un valor númerico relativamente alto supongo. También lo tengo a no en los usuarios remotos que conectan via movil, para que siempre puedan ser alcanzables y no aparezcan como UNREACHABLES si tienen una latencia superior a la que se usa en qualify=yes. No sé hasta que punto esto es malo.

[Sir Brain Colward]

Lo de tapar el micrófono no sirve nada salvo que tengas el VAD (voice activity detection) activado, lo cual suele ser raro.

Prueba a poner una regla en iptables que corte el tráfico RTP momentáneamente durante la llamada para hacer la prueba (así simulas el que se pierda el RTP o que no llegue el RTP).

El segundo punto, sobre el qualify, la respuesta es "depende". Si lo pones a no presupones que siempre está activo, independientemente de las circunstancias. Esto está bien para proveedores, gateways y similares que siempre están encendidos y "alcanzables". Si le pones a yes presupones que sólo está activo durante el intervalo entre OPTIONS. Si este intervalo es pequeño es más preciso, pero require mucho más proceso del asterisk y puede dar lugar a falsos negativos. En contra si es grande bien puede ocurrir que en medio del intervalo el peer deje de responder (lo apagan, corte de red, cambia la IP dinámica con la que se presenta...) por mucho que Asterisk diga que esta OK. Lo normal es dejar el valor por defecto y sólo tocarlo en casos de latencia, problemas con el rendimiento de Asterisk (he visto Asterisks medio morirse por un exceso de OPTIONS), problemas con NATs y similares.

Pero al final eres tú quien debe evaluar que es lo que te viene mejor para tu instalación.

Saludos,

SBC

--

[Miguel Alberto Sanz Pardo]

Acabé poniendo un límite de duración de llamada de 1h y 30 minutos (en el propio Dial( L( ) ) tal y como me aconsejásteis), de manera que si se llega a esa duración la centralita corta la llamada.

Pues bien, he podido observar en tres días en concreto que hubo varias llamadas que llegaban a los 5400s (1h y 30 min). Me he puesto a analizar los logs de la centralita y he podido observar que ocurrió algo del estilo:

- Se va la luz en los gateways(esto lo presupongo según la info. que obtengo de la centralita en el archivo de messages) pero no en la centralita porque el SAI al que  está la centralita ha aguantado más.

- De tal manera, se desregistra el gateway de la centralita y cuando vuelve la luz se vuelve a registrar

- Las llamadas que estaban en curso en medio del apagón no son cortadas hasta que el propio Dial las corta a la hora y media. Al parecer el gateway es incapaz de enviar el BYE a la centralita y los canales quedan abiertos hasta que pasan los 5400s.

Voy a probar a forzar un corte de rtp tal y como me comento cesar con un rtptimeout cortito a ver si consigo detectarlo de esta manera y os cuento.

[Miguel Alberto Sanz Pardo]

Comprobado, forcé mediante el iptables a que no pasara el tráfico RTP y funciona a las mil maravillas el parámetro rtptimeout. Anteriormente no realicé las pruebas como es debido...

Pero vamos, tal y como comentó Elio en su día, justo el rtptimeout se usa para estos casos:

; rtptimeout=60

; Terminate call if 60 seconds of no RTP or RTCP activity on the audio channel when we're not on hold. This is to be able to hangup  a call in the case of a phone disappearing from the net, like a powerloss or grandma tripping over a cable.

Básicamente es lo que me pasaba, que mi teléfono (mi gateway en este caso) de repente se quedaba sin energía y no mandaba el BYE nunca.

Muchas gracias de nuevo a todos ;)

[Raúl Alexis Betancor Santana]

No creo que sea un apagón del gateway ... ya que el RTP-Timeout de Asterisk saltaría a los 30-45s

Ahí tienes que tener otro tipo de problema, en plan el gateway mandó el BYE y el Asterisk se lo pasó por el forro de los @@

---

De: "miguelsanzpardo" <miguels...@gmail.com>
Para: aster...@googlegroups.com

Enviados: Lunes, 25 de Mayo 2015 11:59:06
Asunto: [Asterisk-ES] Re: Problema con detección de colgado de una llamada de voip bajo Asterisk 11.15 y GXW 4232 1.0.5.5

Acabé poniendo un límite de duración de llamada de 1h y 30 minutos (en el propio Dial() tal y como me comentásteis), de manera que si se llega a esa duración la centralita corta la llamada.

Pues bien, he podido obrservar en dos días en concreto que hubo varias llamadas que llegaban a los 5400s (1h y 30 min). Me he puesto a analizar los logs de la centralita y he podido observar que ocurrió algo del estilo:

- Se va la luz en los gateways(esto lo presupongo) pero no en la centralita porque el SAI al que  está la centralita ha aguantado más.

- De tal manera, se desregistra el gateway de la centralita y cuando vuelve la luz se vuelve a registrar

- Las llamadas que estaban en curso no son cortadas hasta que el propio Dial las corta a la hora y media.

¿Sabéis si hay alguna forma de poder solucionar este problema? Entiendo que el gateway no envió el paquete de BYE al apagarse de repente y la línea se quedó abierta entre la centralita y el proveedor, lo cuál es una putada.

[Miguel Alberto Sanz Pardo]

Inicialmente tenía el rtptimeout desactivado Raúl, por lo cuál éste no saltaba, ahora sí que debería de saltar. 

La prueba la hice tratando de realizar una llamada poniendo previamente una cadena del iptables con un DROP de los paquetes RTP. De tal manera a los 60 seg. la llamada se cortaba. Ahora tengo que tratar de repetir el evento de que en medio de una llamada se produzca un desregistro del gateway y ver como reacciona(espero que haga lo mismo).

Lo único que se ve si juntas la info del CDR y del archivo messages es que:

- messages: a las 09.30 de repente se desregistraron los diferentes puertos de los gateways y al rato se volvieron a registrar. 

- CDR: Y justamente a las 9:30 habia una llamada en curso la cual siguió sin ser cortada.

un saludo y gracias por tu ayuda Raúl

 

Miguel Sanz

[Miguel Alberto Sanz Pardo]

Esta noche hubo un evento de este tipo, de manera que el canal se quedo "enganchado". El caso es que el parámetro rtptimeout cumplió su cometido y a los 90 segundos(puse ese valor en vez del 60 que viene por default) colgó el canal :)

Esto es lo que pude ver en el log /var/log/asterisk/messages

[2015-05-26 20:41:36] NOTICE[1738][C-0001c986] chan_sip.c: Call from peer 'IPC_082' rejected due to usage limit of 1

[2015-05-26 20:41:36] NOTICE[1738][C-0001c986] chan_sip.c: Failed to place call for device TelefonoPublico082, too many calls

[2015-05-26 20:41:49] NOTICE[1738][C-0001c988] chan_sip.c: Call from peer 'IPC_082' rejected due to usage limit of 1

[2015-05-26 20:41:49] NOTICE[1738][C-0001c988] chan_sip.c: Failed to place call for device TelefonoPublico082, too many calls

[2015-05-26 20:42:46] NOTICE[1738] chan_sip.c: Disconnecting call 'SIP/IPC_082-00044858' for lack of RTP activity in 91 seconds

Tengo limitado cada teléfono público-extensión con un call-limit = 1, de manera que si un canal se queda "enganchado" y alguien más trata de usar ese mismo teléfono saltará el call-limit. De esta manera veo rápidamente si se quedó "enganchado" un canal.

Seguiré observando los logs pero esto tiene buena pinta.

un saludo

Miguel Sanz

[Miguel Alberto Sanz Pardo]

Por cierto, ¿existe alguna manera de que para un tipo de llamadas en concreto se pueda usar un rtptimeout determinado y para otro tipo de llamadas otro?

En el sip.conf parece indicar que es un parámetro que puede ser usado para los pares de forma individual, pero he estado haciendos prueba y parece ser que es un parámetro general. ¿Se os ocurre alguna forma de poder solucionar este problema?

[Miguel Alberto Sanz Pardo]

Creo que hablé antes de tiempo, el parámetro sí que parece funcionar de manera individual, pero poco sentido tiene ponerlo en la extensión asociada al proveedor si éste sigue enviando paquetes RTP hacia el llamante., porque nunca la cortará mediante rtptimeout.

Si el rtptimeout se lo ponemos al teléfono que está conectado al gateway, el cuál sí que deja de enviar paquetes RTP, a los x segundos sí que se corta la llamada.

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

Si tengo algo de este estilo en el sip.conf

[general]

rtptimeout=90

[miguel]

type=friend

rtptimeout=60

[pedro]

type=friend

(no tiene timeout)

[proveedor voip]

type=peer

rtptimeout=30

Si Miguel llama a través del proveedor VOIP y de repente se apaga el gateway, a los 60 segundos de no haber envío de paquetes RTP entre Asterisk y el gateway, los canales serán cortados.

Si Pedro llama a través del proveedor VOIP y de repente se apaga el gateway, a los 90 segundos de no haber envío de paquetes RTP entre Asterisk y el gateway, los canales serán cortados.

[Miguel Alberto Sanz Pardo]

Porque función relacionada con el rtptimeout para lanzarla desde el Dialplan no existe ¿No?