Hola.

Hace unos dias estube pegando un repaso al documento sip-retransmit.txt y solamente lo encontre en ingles, lo leí y lo traducí personalmente, espero que alguien le pueda ayudar.

——————————————————————–
¿Que es el problema de la retransmision SIP? (Sip retransmits)
——————————————————————————-

Algunas veces aparecen mensajes en la consola de asterisk como los siguientes:

– «retrans_pkt» Hanging up call XX77yy – no reply to our critical packet.»
– «retrans_pkt»: Cancelling retransmit of OPTIONs»

El protocolo SIP se basa en peticiones y respuestas a esas peticiones. Ambas partes envian y reciben respuestas a las solicitudes. Algunas de estas partes son esenciales para una comunicación. En una red TCP/IP pueden ocurrir muchas cosas con los paquetes IP. Firewalls, dispositivos NAT (Routers), Session Border controllers y Proxys SIP, pueden provocar una mala señalización y afectar a la llamada.

SIP Establecer Llamada – INVITE – 200 OK – ACK

1 – Invite
2 – 200 OK
3 – ACK

Para iniciar una llamada SIP, se envia una petición INVITE.
El software sip con el que iniciamos la llamada envia una petición invite (al usuario que llama) y espera una respuesta.
Cuando la petición INVITE fué satisfactoria (el usuario se encuentra disponible y demás)el usuario»que es llamado» envia una petición ‘ACK’. Para informar al otro dispositivo que envió la petición INVITE hacia él, que la recibió correctamente.
Se trata de un acuerdo a 3 vias que se repite mientras una llamada transcurre para asegurarse que todos los dispositivos «el usuario que llama» y el «que es llamado» se encuentran encendidos y funcionando.

– La primera respuesta que esperamos a menudo es un ‘100 Trying’.
Este mensaje significa que algún tipo de servidor SIP ha recibido nuestra solicitud
y se asegura que vamos a obtener una respuesta.

Podria ser el otro extremo (el usuario al que llamamos) o un Proxy SIP o SBC que se encarga de las solicitud en nuestro nombre.

– Despues de eso, a menudo se recibe una respuesta de clase 18x,como «Ring 180″ o » 183 Progreso de sesión».
Esto significa que nuestra solicitud ha alcanzado al menos un extremo y alerta al otro dispositivo que ahi una llamada que viene.

– Por último (si todo a ido bien), la otra respuesta que recibimos del otro lado es un «200 OK». Esto es una respuesta positiva. Este mensaje contiene la dirección directa del dispositivo que nos da la respuesta 200 OK.
Recuerde podria haber varios telefonos sonando. La direccion del telefono es especificada en el campo Contact de la Cabecera SIP.

– Para confirmar que podemos «alcanzar» al telefono que respondió nuestra llamada y responder al 200 OK del otro telefono, ahora enviamos un «ACK’ a la dirección de Contacto de la cabecera SIP.
Si este ACK no es alcanzado por el otro telefono (al que llamamos), la llamada fallaria.
Si no podemos enviar un ACK, no podemos enviar nada ni un «colgado limpio».

Cuando una llamada falla la señalización no tiene sentido dejarla activa.

– Si recibimos una respuesta de error a nuestro INVITE, como «Busy» o «Rejected», enviamos un «ACK» a la dirección que enviamos anteriormente el INVITE, para confirmar su respuesta.

Para asegurar el orden de las llamadas, un cliente SIP retransmite mensajes si no se demora demasiado entre la solicitud y respuesta esperada. Podemos retransmitir varias veces durante un tiempo esperando una respuesta. Nosotros transmitidos varias veces esperando un ACK para INVITE. Si obtenemos respuestas múltiples, respondemos con ACK a cada una de ellas para hacerle saber que la respuesta nos llego correctamente.

Si no recibimos un ACK (confirmación del otro lado) a nuestro INVITE, incluso despues de reenviar nuestras peticiones al otro lado, la llamada finalizará con los mensajes citados más arribas.

Otras peticiones SIP —
————————
Otras peticiones SIP son solamente a 2 vías. Petición — Respuesta.
No hay confirmación de recibir el tráfico (ACK).

En asterisk marcamos estas como CRITICAL.

El proceso de calificación —– OPCIONES
———————————–

Si t uañades a tu sip.conf ‘qualify=yes’ para un dispositivo, Asterisk manda opciónes de respuesta cada minuto para el dispositivo y chequea si este responde.

Cada solicitud una vez añadida esta opción a nuestro sip.conf, se envia un numero de veces (para comprender la posible perdida de paquetes) y si no obtenemos respuesta, el dispositivo se considera inalcanzable. A partir de ese momento se envia una nueva solicitud cada decimo de segundo.

¿Por qué sucede esto?
—————————–

Por alguna razón la señalización no funciona como se espera entre el servidor Asterisk y el otro dispositivo. Puede haber muchas razones por qué sucede esto:

– Un dispositivo NAT enmedio de alguna de las 2 rutas

– Un dispositivo NAT mal configurado y no deja pasar mensajes SIP

– Un Firewall bloqueando los mensajes SIP o los redirecciona incorrectamente

– Un middlebox SIP (SBC), que reescribe la cabecera de contacto incorrectamente.

– Un proxy SIP mal configurado que se olvida de añadir cabecera de registro de ruta para asegurarse de la correcta señaliación.

– Perdida de paquetes. IP y UDP son medios de transporte poco fiable.
Si pierdes demasiados paquetes muchos paquetes de retransmisión serán enviados
y la comunicación será imposible. Si esto sucede con la señalización los medios de comunicación serán inservibles de todos modos.

¿Que puedo hacer?
—————————————

Activar la depuración SIP en asterisk (sip set debug on), tratar de comprender la señaliacion y ver si se pierden las respuestas a INVITE o si pierdes los ACK.
Cuando usted sabe lo que sucede, tu has tomado el primer paso para localizar el problema. Vea la lista de arriba e investigue en su red.

Para problemas de NAT o Firewall, ahi varios documentos que le ayudarán. Empiece por leer el fichero ‘sip.conf.sample’ este es parte de Asterisk distribution.

La señalización estándar SIP, incluyendo las retransmisions y contadores de tiempos para ellos. Esta bien documentando en el IETF RFC 3261

Buena suerte para solventar tus problemas SIP.

Saludos.