Hola.<\/p>\n
Hace unos dias estube pegando un repaso al documento sip-retransmit.txt y solamente lo encontre en ingles, lo le\u00ed y lo traduc\u00ed personalmente, espero que alguien le pueda ayudar.<\/p>\n
\n——————————————————————–
\n\u00bfQue es el problema de la retransmision SIP? (Sip retransmits)
\n——————————————————————————-<\/p>\nAlgunas veces aparecen mensajes en la consola de asterisk como los siguientes:<\/p>\n
– \u00abretrans_pkt\u00bb Hanging up call XX77yy – no reply to our critical packet.\u00bb
\n– \u00abretrans_pkt\u00bb: Cancelling retransmit of OPTIONs\u00bb<\/p>\nEl 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\u00f3n. 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\u00f1alizaci\u00f3n y afectar a la llamada.<\/p>\n
SIP Establecer Llamada – INVITE – 200 OK – ACK<\/p>\n
1 – Invite
\n2 – 200 OK
\n3 – ACK<\/p>\nPara iniciar una llamada SIP, se envia una petici\u00f3n INVITE.
\nEl software sip con el que iniciamos la llamada envia una petici\u00f3n invite (al usuario que llama) y espera una respuesta.
\nCuando la petici\u00f3n INVITE fu\u00e9 satisfactoria (el usuario se encuentra disponible y dem\u00e1s)el usuario\u00bbque es llamado\u00bb envia una petici\u00f3n ‘ACK’. Para informar al otro dispositivo que envi\u00f3 la petici\u00f3n INVITE hacia \u00e9l, que la recibi\u00f3 correctamente.
\nSe trata de un acuerdo a 3 vias que se repite mientras una llamada transcurre para asegurarse que todos los dispositivos \u00abel usuario que llama\u00bb y el \u00abque es llamado\u00bb se encuentran encendidos y funcionando.<\/p>\n– La primera respuesta que esperamos a menudo es un ‘100 Trying’.
\n Este mensaje significa que alg\u00fan tipo de servidor SIP ha recibido nuestra solicitud
\n y se asegura que vamos a obtener una respuesta.<\/p>\nPodria ser el otro extremo (el usuario al que llamamos) o un Proxy SIP o SBC que se encarga de las solicitud en nuestro nombre.<\/p>\n
– Despues de eso, a menudo se recibe una respuesta de clase 18x,como \u00abRing 180″ o \u00bb 183 Progreso de sesi\u00f3n\u00bb.
\n Esto significa que nuestra solicitud ha alcanzado al menos un extremo y alerta al otro dispositivo que ahi una llamada que viene.<\/p>\n– Por \u00faltimo (si todo a ido bien), la otra respuesta que recibimos del otro lado es un \u00ab200 OK\u00bb. Esto es una respuesta positiva. Este mensaje contiene la direcci\u00f3n directa del dispositivo que nos da la respuesta 200 OK.
\n Recuerde podria haber varios telefonos sonando. La direccion del telefono es especificada en el campo Contact de la Cabecera SIP.<\/p>\n– Para confirmar que podemos \u00abalcanzar\u00bb al telefono que respondi\u00f3 nuestra llamada y responder al 200 OK del otro telefono, ahora enviamos un \u00abACK’ a la direcci\u00f3n de Contacto de la cabecera SIP.
\n Si este ACK no es alcanzado por el otro telefono (al que llamamos), la llamada fallaria.
\nSi no podemos enviar un ACK, no podemos enviar nada ni un \u00abcolgado limpio\u00bb.<\/p>\nCuando una llamada falla la se\u00f1alizaci\u00f3n no tiene sentido dejarla activa.<\/p>\n
– Si recibimos una respuesta de error a nuestro INVITE, como \u00abBusy\u00bb o \u00abRejected\u00bb, enviamos un \u00abACK\u00bb a la direcci\u00f3n que enviamos anteriormente el INVITE, para confirmar su respuesta.<\/p>\n
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\u00faltiples, respondemos con ACK a cada una de ellas para hacerle saber que la respuesta nos llego correctamente.<\/p>\n
Si no recibimos un ACK (confirmaci\u00f3n del otro lado) a nuestro INVITE, incluso despues de reenviar nuestras peticiones al otro lado, la llamada finalizar\u00e1 con los mensajes citados m\u00e1s arribas.<\/p>\n
Otras peticiones SIP —
\n————————
\nOtras peticiones SIP son solamente a 2 v\u00edas. Petici\u00f3n — Respuesta.
\nNo hay confirmaci\u00f3n de recibir el tr\u00e1fico (ACK).<\/p>\nEn asterisk marcamos estas como CRITICAL. <\/p>\n
El proceso de calificaci\u00f3n —– OPCIONES
\n———————————–<\/p>\nSi t ua\u00f1ades a tu sip.conf ‘qualify=yes’ para un dispositivo, Asterisk manda opci\u00f3nes de respuesta cada minuto para el dispositivo y chequea si este responde.<\/p>\n
Cada solicitud una vez a\u00f1adida esta opci\u00f3n 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.<\/p>\n
\u00bfPor qu\u00e9 sucede esto?
\n—————————–<\/p>\nPor alguna raz\u00f3n la se\u00f1alizaci\u00f3n no funciona como se espera entre el servidor Asterisk y el otro dispositivo. Puede haber muchas razones por qu\u00e9 sucede esto:<\/p>\n
– Un dispositivo NAT enmedio de alguna de las 2 rutas<\/p>\n
– Un dispositivo NAT mal configurado y no deja pasar mensajes SIP<\/p>\n
– Un Firewall bloqueando los mensajes SIP o los redirecciona incorrectamente<\/p>\n
– Un middlebox SIP (SBC), que reescribe la cabecera de contacto incorrectamente.<\/p>\n
– Un proxy SIP mal configurado que se olvida de a\u00f1adir cabecera de registro de ruta para asegurarse de la correcta se\u00f1aliaci\u00f3n.<\/p>\n
– Perdida de paquetes. IP y UDP son medios de transporte poco fiable.
\n Si pierdes demasiados paquetes muchos paquetes de retransmisi\u00f3n ser\u00e1n enviados
\n y la comunicaci\u00f3n ser\u00e1 imposible. Si esto sucede con la se\u00f1alizaci\u00f3n los medios de comunicaci\u00f3n ser\u00e1n inservibles de todos modos.<\/p>\n\u00bfQue puedo hacer?
\n—————————————<\/p>\nActivar la depuraci\u00f3n SIP en asterisk (sip set debug on), tratar de comprender la se\u00f1aliacion y ver si se pierden las respuestas a INVITE o si pierdes los ACK.
\nCuando 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.<\/p>\nPara problemas de NAT o Firewall, ahi varios documentos que le ayudar\u00e1n. Empiece por leer el fichero ‘sip.conf.sample’ este es parte de Asterisk distribution.<\/p>\n
La se\u00f1alizaci\u00f3n est\u00e1ndar SIP, incluyendo las retransmisions y contadores de tiempos para ellos. Esta bien documentando en el IETF RFC 3261<\/p>\n
Buena suerte para solventar tus problemas SIP.\n<\/p><\/blockquote>\n
Saludos.<\/p>\n