En este numeral del documento se explica el funcionamiento, puesta en marcha y protocolos de pruebas realizadas en el Nodo Captura para validar su funcionamiento en un ambiente real en redes NGN´s evaluando la señalización SIP.
5.3.3 Descripción del funcionamiento Nodo Captura
El nodo captura este compuesto por tres partes, el primero de ellos es un servidor SIP que para nuestro caso utilizamos Kamailio versión 4, el cual es el encargado de almacenar en una base de datos, (Mysql) toda la señalización SIP que le llega al nodo captura, el segundo de ellos es un agente captura que hace la función de puerto de escucha y es el encargado de copiar, modificar y llevar toda la señalización SIP hacia nuestro servido SIP y por ultimo una interfaz web que es la que se encarga de filtrar los resultados y mostrarlos en un ambiente web.
Se instala el Nodo Captura, se realiza las modificaciones y desarrollos al interior del mismo para poder observar el comportamiento de la trama SIP y llegado al caso realizar modificaciones a la trama para la interoperabilidad de elementos de una red NGN o una integración de dos NGN´s de diferentes fabricantes. Ver anexo 2.
18
74 5.3.4 Características del hardware Nodo Captura
Para la implementación e instalación del nodo captura se tuvo en cuenta una serie de requisitos tanto de hardware como de software como fueron los siguientes:
Se instaló un sistema operativo Linux Ubunto versión 12.04 con todas sus actualizaciones sobre una máquina que tenía la siguientes características de hardware: Procesador Intel Core i7-3770 3.4GHz, Disco Duro de 1TB SATA y Memoria DDR3 8GB 1600MHz. El cual demostró un comportamiento aceptable en cuanto rendimiento de maquina se refiere.
5.3.5 Análisis Nodo Captura
En este numeral se explica la plataforma de pruebas en la que se ha implementado el sistema y el rendimiento del mismo. Se ha buscado un diseño adecuado para la señalización del protocolo SIP, que muestre las condiciones reales las cuales permita pruebas y medidas con flexibilidad.
Se ha montado una serie de escenarios para caracterizar, tomar medicas de QoS y observar el comportamiento de la señalización SIP de la red redes NGN ZTE-PUJ y ANKLA; para esto se puso en marcha el Nodo Captura y se le inyecto tráfico por medio de generador de tráfico, este nos permite medir un tráfico real (genera tráfico que emula la señalización SIP y tráfico de media RTP).
El escenario utilizado para las medidas se puede ver en la figura 5-1. Se ha utilizado UDP en lugar de TCP, para evitar el control de flujo que TCP realiza por defecto. Así, el tráfico interferente siempre es el mismo, y no se adapta al ancho de banda disponible, haciendo que el sistema trabaje siempre en el peor caso.
El generador tráfico envía el tráfico en primer lugar al proxy de la red NGN ZTE-PUJ, después al Nodo Captura el cual realiza la función de escucha para poder evaluar la señalización SIP, después al proxy destino la red NGN ANKLA y por ultimo al receptor del generador de tráfico de la red de destino en la figura 5-2 podemos observar la señalización que está pasando por el Nodo Captura.
75
Figura 5-1. Generación de tráfico SIP las diferentes redes NGN´s
Figura 5-2. Traza de una de las pruebas de interconexión de búsqueda de llamada se sesión de las diferentes NGN´s
Después de realizar un análisis detallado de la señalización SIP que está pasando por el Nodo Captura no encontramos ningún parámetro adicional o faltante en sus cabeceras de mensajes SIP, la cual se puede ver en la figura 5-3.
76
Figura 5-3. Diagrama de secuencia de la señalización SIP de una llamada de Softswitch Vs Softswitch
Se realiza una exportación a un analizador de protocolos (wireshark) para observar el comportamiento de la señalización SIP entre las dos redes NGN´s esto se hace para tener una segunda visualización de los mensajes SIP el cual no nos arroja ningún comportamiento que no esté contemplado en RFC 3162.
Figura 5-4. Captura de traza de la señalización SIP de una llamada de Softswitch Vs Softswitch
5.3.6 Emulación Trama SIP para el Comportamiento del Nodo Captura.
Al no encontrase ningún tipo de alteración en la trama SIP para la interoperabilidad de redes NGN´s acudimos a un emulador de trama SIP (Sip Inspector) para probar el funcionamientos del Nodo Captura en la detección y modificación de parámetros adicionales o faltantes en su señalización SIP (RFC 3261).
77
Se realiza una serie de pruebas invocando los problemas de interoperabilidad mencionados en el numeral 2-3.
5.3.6.4 SIP campo y longitudes mensaje Proxy SIP.
Mientras que el RFC 3261 no define ninguna longitud máxima de los mensajes de SIP, la realidad es que los proveedores a menudo imponen límites de longitud de los campos y los mensajes recibidos. Ya sea por razones de seguridad o arquitectura, lo cierto es que hay muchos sistemas que no pueden o no quieren manejar los campos tan grandes como otros sistemas pueden generarlas. A pesar de que en el [RFC 3261] se definen algunos códigos de respuesta específicos 413 (Entidad de solicitud demasiado grande), 414 (Request-URI es demasiado larga) y 513(Mensaje demasiado grande).
El Nodo captura realizó modificaciones a la trama SIP simulada para evitar este tipo de errores como son: 413 (Entidad de solicitud demasiado grande), 414 (Request-URI es demasiado larga) y 513(Mensaje demasiado grande), dando como resultado un autentificación a un proxy. Ver anexo 7.1.
5.3.6.5 Parámetros TEL-URI
El problema de la interoperabilidad más común es en esta área, es la colocación de los parámetros TEL URI, por ejemplo, el "tgrp" y "contexto tronco" parámetros del [RFC4904], y la "rn", "NPDI", y los parámetros "CIC" a partir del [RFC4694]. El RFC 3261 sección 19.1.6 está muy claro que todas las características de la telefonía de abonado, incluyendo los parámetros, se coloca en la parte de user-info de una SIP URI. Por lo tanto los parámetros de Tel-URI se convierten en parámetros de usuario de SIP, parámetros SIP URI no.
Se realizó la comprobación de la simulación de un TEL-URI a través del Nodo Captura dando como resulta un envío de mensajes SIP, transparente para las entidades emisor y receptor. Ver anexo 7.2.
5.3.6.6 Invite –Reinvite (Subscribe)
Crea una invitación al ser negada reenvía la invitación y no puede establecer una comunicación por falta de parámetros en el protocolo SDP, por ejemplo, que los dispositivos a enrutar las llamadas sobre la base del códec, o la asignación de ancho de banda, o los dispositivos de transcodificación que se envían no estén de acuerdo con lo necesario.
78
Se simulo un escenario evitando este tipo de problemas de interoperabilidad, dando como resultado un envío de señalización SIP éxito. Ver Anexo 7.3
5.3.6.7 Valor De Cabecera PRACK
SIP ofrece un medio para indicar el uso de extensión, los vendedores hacen suposiciones acerca de las capacidades de los otros UA, literalmente significa "no quiero que esta solicitud tenga éxito, a menos de que el posible receptor conozca el uso de extensión".
Por ejemplo, la etiqueta de opción 100rel para apoyar PRACK, se inserta en la cabecera requieren de una petición INVITE. Esto es fundamentalmente erróneo en el uso real. El apoyo a PRACK no es universal, en todo sentido, y la inserción de esta etiqueta en la cabecera Requerir conduce a las llamadas fallidas. Se emulo el escenario anterior dando como resultado un envío de señalización SIP éxito. Ver Anexo 7.4