En el protocolo SIP una petición o request enviado por un UAC (User Agent Clients) hacia un UAS (User Agent Servers) puede atravesar uno o varios SIP Proxy en su camino, y las respuestas a esta petición deben de volver exactamente por el mismo camino, a través de los SIP Proxy recorridos en el camino de ida. Esto es una cosa que sorprende cuando se estudia el protocolo SIP, ya que una de las características clave del protocolo IP es que los paquetes IP que forman parte de una comunicación entre dos equipos pueden llegar al destino por caminos diferentes y las respuestas pueden retornar hacia el origen también por caminos diferentes. Esta es una de las características fundamentales del protocolo IP, en el que tan solo es importante mantener la IP de origen y la IP de destino a lo largo de todo el desplazamiento del paquete por la red IP, transmitiéndose los paquetes IP a través de los routers intermedios mediante las correspondientes direcciones MAC de dichos routers (Capa 2). Por el contrario, en el protocolo SIP es necesario que todos los mensajes SIP correspondientes a una señalización y las consiguientes respuestas, vayan por el mismo camino, atravesando los mismos SIP Proxy. Para ello es necesario apuntar en algún sitio las direcciones IP de los SIP Proxy que se van atravesando, ya que esta información es imprescindible para poder volver por el mismo camino. Esta es la función del campo “Via” situado en la cabecera o “header” de los paquetes SIP.
Funcionamiento del campo “Via” en el protocolo SIP
Como se ve en el diagrama anterior, cada SIP Proxy coloca una línea en la parte superior del campo Via con su propia dirección IP. En el camino de vuelta, cada SIP Proxy retira de la parte superior del campo Via la línea que contiene su propia dirección IP y envía el paquete hacia la dirección IP contenida en la siguiente línea. El funcionamiento es sencillo pero cuando intentamos observarlo de forma práctica con el típico montaje de un Asterisk, vemos que no se cumple, ya que Asterisk no es un SIP Proxy.
Comunicación entre dos teléfonos IP a través de Asterisk
Mensaje INVITE desde la extensión 102 al servidor de Asterisk
Mensaje INVITE desde el servidor de Asterisk a la extensión 101
Como se observa en los dos mensajes INVITE anteriores, la extensión 102 cuando envía el mensaje INVITE hacia el servidor de Asterisk coloca una línea Via con su propia dirección IP, la 192.168.1.38. Cuando Asterisk envía este mensaje INVITE hacia la extensión 101, realmente está creando un nuevo mensaje INVITE en el que ya solo aparece una línea Via con su propia dirección IP, la 192.168.1.160. En cambio si reproducimos esta misma situación utilizando un SIP Proxy como Kamailio, observamos lo siguiente:
Comunicación entre dos teléfonos IP a través del SIP Proxy Kamailio
SIP Proxy Kamailio virtualizado sobre VMware
Mensaje INVITE desde la extensión 102 al SIP Proxy Kamailio
Mensaje INVITE desde el SIP Proxy Kamailio a la extensión 101
Se observa que el primero de estos mensajes INVITE que va desde la extensión 102 al SIP Proxy Kamailio es idéntico al enviado en el caso anterior, cuando el destino era el servidor de Asterisk. Es decir, la extensión 102 coloca en el campo Via su dirección IP. Sin embargo cuando Kamailio reenvía este mensaje hacia la extensión 101 si que añade una nueva línea Via en la parte superior con su propia dirección y además se añade otra nueva línea denominada Record Route, que sirve para que el SIP Proxy notifique que quiere estar en el “path” o camino para los siguientes “request” del mismo caller-id, es decir, de la misma llamada.
Campo Record-Route en el mensaje 200 OK enviado desde Kamailio a la extensión 102