RFC 1918 y modelo de resolución por capas TCP/IP para SIP

 

!Hola red!

El #RFC1918 indica las "mejores prácticas" de direccionamiento de una red privada, esto es algo realmente importante de seguir.

- 10.0.0.0 - 10.255.255.255 (10/8 subnet)

- 172.16.0.0 - 172.31.255.255 (172.16/12 subnet)

- 192.168.0.0 - 192.168.255.255 (192.168/16 subnet)

En ocasiones no se siguen las recomendaciones, quizás porque un técnico llega a una instalación donde existe un direccionamiento con IP públicas y supone un gran esfuerzo cambiar todo el direccionamiento de la red, y claro si funcione no lo toques. Otras veces puede haber en la red un direccionamiento extraño como puede ser el del protocolo #APIPA en épocas donde no había un servidor #DHCP y que los técnicos deciden mantener pensando que es un direccionamiento correcto para esa red, por no hablar de otros casos curiosos.

Quizás para la mayoría de protocolos de internet esto no sea un problema, aunque para el protocolo #SIP esto sí supone un gran problema. Los mensajes SIP contienen cabeceras que contienen información relevante para establecer la llamada y la negociación de las capacidades de media de una sesión, en estas cabeceras se suele incluir información de la IP privada de la red telefónica que en algunos casos puede ocasionar problemas graves.

Si la negociación de la señalización y del "media" contiene cabeceras con IP privadas siguiendo las recomendaciones del RFC1918 los dispositivos SIP #PBX, #proxies y #SBC no les supone un problema establecer la negociación de señalización y audio, ya que los equipos suelen estar preparados para ello, sobretodo los más modernos. Hay que tener en cuenta que al protocolo SIP no le gusta mucho encontrarse con IP privadas en esas cabeceras aunque la mayoria de equipos ya son capaces de resolverlo.

Sin embargo no ocurre lo mismo cuando se configura un direccionamiento público en una red privada, esto puede causar problema graves tanto de señalización como de media, incluso puede causar problemas dificiles de diagnosticar por un técnico experimentado.

Ojo no hablamos de que se haya configurado un NAT transversal de la IP real o el equipo esté en la nube y por ejemplo la cabecera "contact" contenga la IP pública real de la red, en esos casos no suele haber mayor problema. Hablamos de entornos donde está detrás de NAT con un direccionamiento público.

Si tuvieramos un problema dificil de resolver o un técnico se encontrase atascado en una incidencia una de las recomendaciones es seguir un modelo de resolución de problemas por capas de abajo hacia arriba. En este caso a mi me gusta seguir el modelo #TCP/IP donde un problema de direccionamiento privado estaría situado en la capa internet que es una capa inferior respecto a un problema relacionado con la parte #SIP o audio #RTP situado en la capa de aplicación, por lo que tratar de resolver el problema en una capa superior a la internet será bastante dificil.

https://www.researchgate.net/figure/Open-Systems-Interconnection-and-TCP-IP-model-of-VoIP_fig2_327815552

Resolver el problema de direccionamiento desde la raíz es algo esencial para corregir el problema de forma definitiva, otras formas de resolución del problema de direccionamiento en la red no se han mostrado 100% efectivas y para ello seguir la recomendación del RFC 1918 es algo esencial.

Personalmente conocer los tipos de direccionamiento y su uso es algo que aprendí bastante pronto en mi formación y que ha sido de mucha utilidad.

Para aquellos #instaladores y #técnicos que llegan a una instalación y se encuentran una red con un direccionamiento público les animo a alzar la mano en forma de queja. Realizar una instalación de #vozip con un direccionamiento público puede dar mucho dolores de cabeza que no creo que nadie quiera sufir, por lo que corregir el problema a tiempo será algo realmente importante.

Más información:

https://es.wikipedia.org/wiki/Red_privada

https://www.asteriskguru.com/tutorials/sip_nat_oneway_or_no_audio_asterisk.html

Pablo Álvarez