Una correcta configuración del Router es un elemento clave para asegurar una correcta comunicación entre la Central Telefónica VoIP (IPPBX) y entidades externas como extensiones remotas, servicios de Proveedores VoIP y otras IP PBXs.
Network Address Translation (NAT)
Cuando el host de red A envía una solicitud a otro host de red B, el host de red A espera una respuesta a su solicitud. Cuando ambos hosts de red residen en una dirección IP pública, el intercambio es directo y bastante sencillo.
Sin embargo, si uno de los hosts de red reside en una dirección IP Privada, las cosas empiezan a complicarse, porque el entorno de red no es un entorno NAT/PAT. Si el host de red A está en un entorno NAT/PAT, cuando envíe una petición al host de red B, el host A construirá su petición usando la única dirección IP que conoce - su dirección IP privada. El problema aquí es que las direcciones IP privadas (LAN) NO son enrutables a través de la Internet pública.
Sin embargo, deberíamos ser capaces de ver las respuestas de vuelta porque, a medida que el tráfico cruza el dispositivo WAN-to-LAN (Router), el dispositivo WAN-to-LAN manipulará las cabeceras de los paquetes de "Dirección IP de origen", y traducirá la dirección IP privada (192.168.0.3) a la dirección IP pública antes de enviarlo - de ahí el término NAT, o Traducción de Dirección de Red - lo que significa que el tráfico sale con la dirección IP pública (por ejemplo: 212.213.214.215). El dispositivo WAN-to-LAN mantendrá un registro de esta manipulación de direcciones IP. La lista de tales manipulaciones hechas por el dispositivo WAN-to-LAN se llama típicamente Tabla de Mapeo NAT.
Podemos visualizar cómo podría ser una entrada de NAT Mapping en el siguiente ejemplo:
Network Address Translation (NAT)
| WAN Side | LAN Side | ||
| IP address | Port number | IP address | Port number |
| 212.213.214.215 | ANY | 192.168.0.3 | ANY |
Cuando se envía una respuesta a la solicitud enviada anteriormente, el dispositivo WAN-to-LAN realizará la misma manipulación a la inversa en la "Dirección IP de destino". Esto significa que la dirección IP de destino en la cabecera del paquete tendría que ser cambiada de "212.213.214.215" a "192.168.0.3" y luego reenviada a la LAN, donde el host de red con dirección IP "192.168.0.3" la procesaría.
Paquetes Keep-Alive (Keep Alive Packets)
Teniendo en cuenta que cada entrada creada en la tabla NAT Mappings en el dispositivo WAN-to-LAN tiene un periodo de validez de 20 a 60 segundos (TTL o Time-To-Live). Cada vez que un paquete atraviesa la frontera WAN-to-LAN desde la misma dirección IP y puerto LAN a la misma dirección IP y puerto WAN mientras la entrada de mapeo NAT en cuestión sigue activa, el TTL se reinicia y el dispositivo WAN-to-LAN comienza de nuevo la cuenta regresiva del periodo de validez.
Cuando un Cliente SIP, tal como un Teléfono SIP, se registra con un Servidor SIP por ejemplo, se crea una entrada en la tabla de Mapeo NAT. Sin embargo, si no se intercambia más tráfico antes de que expire el tiempo TTL, entonces el Mapeo NAT expira, y cualquier tráfico originado desde el lado WAN hacia el Teléfono SIP no podrá alcanzarlo porque la entrada de Mapeo NAT ya no existe. Así que un Cliente SIP también debe ser configurado para enviar mensajes Keep-Alive al Servidor SIP, con un intervalo de alrededor de 15 segundos (que debería ser lo suficientemente bueno para todas las implementaciones NAT/PAT razonables).
El Cliente SIP enviará un Mensaje SIP al Servidor SIP que es sintácticamente correcto (obligando al Servidor a responder), pero solicitando algún servicio o función que el Servidor SIP no tendrá disponible. Esto generaría una respuesta de Método No Implementado del Servidor SIP. Esto está habilitado por defecto para Teléfonos SIP aprovisionados por STUN.
Funcionalmente esto no logra ningún propósito, pero es suficiente para asegurar que el Mapeo NAT establecido sobre el límite WAN-a-LAN nunca expire (se mantiene vivo de ahí el nombre Keep Alive), y asegura que el Servidor SIP será capaz de contactar al Cliente SIP a través del Mapeo NAT.
NAT / PAT es insuficiente para SIP
Hay una serie de razones fundamentales por las que NAT y PAT simples son insuficientes para resolver los problemas de NAT transversal para el tráfico VoIP en general y para la Señalización SIP más específicamente. Un pequeño subconjunto de las razones:
- El estándar SIP requiere que se especifiquen varios campos de cabecera, algunos de los cuales necesitan contener la dirección IP a la que se deben enviar las respuestas. Dado que NAT y PAT sólo operan en las cabeceras IP, y no en la carga útil UDP, el dispositivo WAN-to-LAN no aborda esta cuestión en absoluto.
- SIP no sólo realiza las tareas de establecimiento, ajuste y desconexión de llamadas, sino que también incorpora la fase de negociación del códec multimedia dentro de un protocolo integrado denominado SDP (Protocolo de Descripción de Sesión). Una vez más, el dispositivo WAN-to-LAN no aborda este contenido adicional a nivel NAT o PAT.