Problema con comunicación, se corta siempre a los 15 min. 24 seg.

[Miguel Alberto Sanz Pardo]

Hola buenos días,

Estamos realizando unas pruebas con Asterisk relacionadas con telerecargas a través de teléfonos públicos y está ocurriendo que en la mayoría de las ocasiones la telerecarga no se llega a realizar por completo (se queda a mitad) porque a los 15 min. 24 seg. se corta la comunicación(siempre se corta en el mismo instante temporal)

Ayer de 6 intentos uno funciono.

Haciendo un SIP debug, pude ver que en el caso en el que funcionó la comunicación el BYE lo enviaba el teléfono público al sistema de gestión(SETM); justo al revés que en los casos fallidos, donde el BYE era enviado por el SETM

Otra cosa que pude observar en las trazas es que en el caso de la comunicación correcta antes de que se enviara el BYE el teléfono púbico recibía el mensaje REGISTER de sí mismo(según las trazas) y luego de Asterisk recibía el mensaje OPTIONS y el 200 OK

¿Puede haber algún parámetro en asterisk que esté haciendo que justo a los 15 min. 24 seg casi siempre se corte la comunicación?

La configuración que disponemos es:

TELEFONO PUBLICO (SIP 223) --> GATEWAY --> ASTERISK <--- GATEWAY  <--- SETM (SIP 214)

Os dejo la captura que hice con el SIP DEBUG, aunque es un poco rollo, pero si alguien tiene ganas de echarle un vistazo ahí está.

Ahora me pondré a hacer un TCPDUMP a ver si con wireshark puedo ver algo que me aporte más información.

PD: Anteriormente se hicieron varias telerecargas de forma seguida sin haber fallos de comunicación.

[Fernando Villares]

15 minutos 900 segundos....rtp TIMEOUT y los sessions timers xD busca por ese lado

--
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 los RTP Timers los tengo comentados y entiendo que en default no estarían actuando.¿En principio para este caso en concreto interesa que estén así no?

Respecto  a los SIP session timers he visto que de forma predefinida tenemos:

session-timers=accept

session-expires=1800seg

session-minse=90seg

session-refresher=uas

Para este caso en concreto(el caso fallido) el callee es el que está mandando un BYE cuando el que lo debe de mandar es el caller.

Y la comunicación se corta como tu bien dices a unos 900 segundos. Para tratar de evitar estos cortes ¿Qué valores les darías a dichos parámetros?

session-timers=refuse ?

session-refresher = uac ?

Luego también están los SIP Timers que de forma predefinida están así:

t1min=100ms

timert1=500ms

timerb=64*timert1

Supongo que estos últimos no nos estarán afectando, no sea que cuando haya un INVITE este no llegue y se corte la comunicación de alguna forma.

Os dejo unas capturas realizadas con el tcpdump para poder ver con wireshark:

Para ver el tráfico de forma sencilla hay que poner en el filtro del wireshark --> sip.from.user==214|| sip.from.user==223|| sip.to.user==214|| sip.to.user==223

Las dos primeras trazas son de comunicaciones erróneas y la tercera es de una comunicación que ha funcionado.

un saludo y gracias por las respuestas.

[Miguel Alberto Sanz Pardo]

Las trazas

[Raúl Alexis Betancor Santana]

On Fri, May 09, 2014 at 01:06:14AM -0700, Miguel Alberto Sanz Pardo wrote:
> Pues los RTP Timers los tengo comentados y entiendo que en default no
> estarían actuando.¿En principio para este caso en concreto interesa que
> estén así no?

Todo parámetro tiene un valor por defecto, que comentes el parámetro
no lo deshabilita.

> Respecto a los SIP session timers he visto que de forma predefinida
> tenemos:
> session-timers=accept
> session-expires=1800seg
> session-minse=90seg
> session-refresher=uas
>
> Para este caso en concreto(el caso fallido) el callee es el que está
> mandando un BYE cuando el que lo debe de mandar es el caller.
> Y la comunicación se corta como tu bien dices a unos 900 segundos. Para
> tratar de evitar estos cortes ¿Qué valores les darías a dichos parámetros?
> session-timers=refuse ?
> session-refresher = uac ?

Para evitar esos problemas, deberías de arreglar el problema de red
que los causa, normalmente con los STS, si uno de los extremos no lo
soporta, el que si lo soporta, los ignora, ya que no llega a
negociarlos.

> Luego también están los SIP Timers que de forma predefinida están así:
> t1min=100ms
> timert1=500ms
> timerb=64*timert1
>
> Supongo que estos últimos no nos estarán afectando, no sea que cuando haya
> un INVITE este no llegue y se corte la comunicación de alguna forma.

No, esos son los valores habituales de retransmisión de los SIP
Request


Saludos

[Miguel Alberto Sanz Pardo]

Pues al parecer con añadir session-timers=refuse no ha habido problemas de comunicación, por ahora 4 de 4 telecargas han llegado bien.

A ver si sigue funcionando así de bien. Lo raro es que anteriormente se pudieron hacer telecargas sin hacer falta modificar este parámetro, pero bueno si así lo hemos solucionado.

un saludo y gracias por vuestra ayuda

[Juan Felipe]

Este problema te sucede cuando realizas llamadas entre extensiones? Tiene extensiones remotas? Esta utilizando un NAT?

Enviado desde mi iPhone

--

[Fernando Villares]

tranquilo estimado los session timers vuelven locos a mas de uno cuando no se sabe q coños hacen xD...lo importante es saber q estan alli y q hacen!!!!

[Miguel Alberto Sanz Pardo]

Parece que ya funcionan bien pero está pasando algo curioso que tengo que investigar y que no me había dado cuenta hasta ahora.

Si yo desde mi teléfono público estoy haciendo la telecarga con el STEM(Sistema de gestión) y otro teléfono llama al SETM me acaba cortando la comunicación :(, supongo que será algún parámetro de Asterisk, mañana o el lunes investigaré más pero os lo quería contar porque me quedé mosca y me quitó el sueño.

Y otra cosita que vi que me da que está relacionado con eso mismo es que:

Si yo tengo una comunicación con otro terminal(una llamada normal y corriente mediante teléfonos IP dentro de la red de Asterisk) y un tercer terminal me llama no le da tono busy sino que le da tono de llamada y me aparece en el teléfono un aviso de que me están llamando desde esa extensión mientras estoy hablando con el otro XD. ¿Os ha pasado esto alguna vez? Supongo que será el mismo parámetro que está afectando a las comunicaciones entre el teléfono público y el SETM cuando llama otro terminal.

un saludo

Miguel Sanz

[Ricardo Peironcely]

Lo que dices de que te entra la llamada, es porque tu teléfono gestiona más de una línea. Es algo normal.

Es el propio telefono el que en vez de dar un ringing debería devolver un busy, si quieres que funcione así, busca en el manual del terminal si puedes bloquearlo a una llamada simultánea.

Un saludo / Best regards / С уважением

Ricardo Peironcely

--

[Miguel Alberto Sanz Pardo]

Hola de nuevo y gracias por las respuestas

He probado a hacer las pruebas mediante un gateway y 4 teléfonos y analógicos y observo algo que me gustaría modificar.

Situación inicial: A llama a B y comienza la comunicación

C trata de llamar a A y da señal de llamada

D trata de llamar a A mientras C trata de llamar a A con anterioridad y en tal caso le da tono de ocupado.

¿Cómo hago para decirle a C que A está ocupado realmente? ¿Hay alguna variable de Asterisk que solucione esto? DIALSTATUS no me vale puesto que el propio sistema no se entera de esto. 

Creo que en la configuración del gateway no aparece nada del estilo de que gestione más de una línea pero le echaré un vistazo ahora.

un saludo

Miguel Sanz

[Ricardo Peironcely]

Ya te lo contesté ayer. Tu endpoint gestiona dos líneas o mejor dicho en este caso dos llamadas por línea. 

Si es analógico, te estará dando un tono en la conversación entre A y B indicando "llamada en espera". Probablemente si en el gateway desactivas la llamada en espera, se comporte como tu quieres.

Otra opción es usar las opciones call-limit y busylevel en la definición del sip.conf, pero eso tiene efectos colaterales. Mejor hacer que el endpoint se comporte como tu quieres.

Un saludo / Best regards / С уважением

Ricardo Peironcely

--

[Fernando Villares]

disable call waiting ademas!!!!

[Miguel Alberto Sanz Pardo]

Muchas gracias por las respuestas, gracias a vuestra ayuda ya funciona el sistema como deseaba.

Busqué dicha opción en el gateway y en efecto aparecía como activada (llamada en espera - call waiting), la desactive y ya no hay problemas por llamadas en espera.

También probé a usar el call-limit(el cual al parecer en la version 11 de asterisk está obsoleto) y el busylevel sin desactivar la opción del call waiting, pero no conseguí solucionar el problema modificando dichos valores.

Otra opción fue el usar el GROUP y GROUP_COUNT, tal y como me aconsejo Raul

Muchas gracias 

un saludo 

Miguel Sanz