DISEÑO DE UN SISTEMA DE MEDICIÓN AUTOMATIZADO DE PARÁMETROS DE CALIDAD DE SERVICIO EN LAS REDES DE NUEVA GENERACIÓN DE CANTV

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA ELECTRÓNICA DISEÑO DE UN SISTEMA DE MEDICIÓN AUTOMATIZADO DE PARÁMETROS DE CALIDAD DE SERVICIO EN LAS REDES DE NUEVA GENERACIÓN DE CANTV Por Andreina Beatriz Toro Ramírez Sartenejas, Febrero de 2007

2 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA ELECTRÓNICA DISEÑO DE UN SISTEMA DE MEDICIÓN AUTOMATIZADO DE PARÁMETROS DE CALIDAD DE SERVICIO EN LAS REDES DE NUEVA GENERACIÓN DE CANTV. Por: Andreina Beatriz Toro Ramírez Realizado con la Asesoría de Ing. Trina Adrián de Pérez (Tutor Académico) Ing. Francisco Lagos (Tutor Industrial) INFORME FINAL DE CURSOS EN COOPERACIÓN TÉCNICA Y DESARROLLO SOCIAL Presentado ante la Ilustre Universidad Simón Bolívar Como requisito Parcial para Optar por el Título de Ingeniero Electrónico Sartenejas, Febrero de 2007

3 UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería Electrónica Diseño de un sistema de medición automatizado de parámetros de calidad de servicio en las Redes de Nueva Generación de CANTV INFORME FINAL DE CURSOS EN COOPERACIÓN TÉCNICA Y DESARROLLO SOCIAL presentado por Andreina Beatriz Toro Ramírez RESUMEN: REALIZADO CON LA ASESORÍA DE Ing. Trina Adrián de Pérez (Tutor Académico) Ing. Francisco Lagos (Tutor Industrial) La Corporación CANTV cuenta hoy en día con una plataforma de NGN (Redes de Nueva Generación) que permite integrar los servicios de voz y datos sobre una misma tecnología. El servicio del sistema telefónico sobre estas Redes, debe acatar los estándares internacionales para cumplir con la Calidad de Servicio en el tráfico de voz sobre IP. El propósito de este proyecto fue desarrollar una herramienta automatizada de medición de parámetros de calidad, tales como: retardo, jitter y pérdida de paquetes, en el Servicio de Tráfico Telefónico sobre IP de la Red de Nueva Generación de CANTV que permita, de forma inmediata, detectar y notificar, vía correo electrónico, fallas en horas pico y al mismo tiempo aliviar el trabajo del personal del COR (Centro de Operaciones de la Red). Una vez finalizadas las pruebas, se puede concluir que, aunque el sistema todavía se encuentra en fase de prototipo, a la espera de la llegada de un servidor robusto para ser implementado, se puede afirmar que los resultados cumplieron con lo esperado al comienzo del proyecto. PALABRAS CLAVES Calidad de Servicio, Redes de Nueva Generación, Protocolo IP, Captura, Automatización, Sistema, Puerto. Aprobado con Mención: Postulado para el premio: Sartenejas, Febrero 2007 iv

4 INDICE CAPITULO I INTRODUCCIÓN Planteamiento del Tema Descripción del Proyecto Estructura del Informe de Pasantía...18 CAPÍTULO II CONCEPTOS Y FUNDAMENTOS Voz sobre redes de datos Paquetización de la voz Protocolos Protocolo IP (Internet Protocol) Encabezado IP Protocolo UDP (Protocolo de Datagramas de Usuario) Encabezado UDP Aplicación del Protocolo UDP Protocolo RTP (Real-Time Transport Protocol) Encabezado RTP Protocolo RTCP (Real-Time Control Protocol) Diagrama del paquete de transporte RTCP Protocolo NTP (Network Time Protocol) VoIP (Voice Over Internet Protocol) Componentes principales de VoIP: Estándar H Calidad de Servicio Factores que afectan la calidad de servicio CODEC Pérdida de Paquetes: Retardo Retardo Algorítmico Retardo de Paquetización Retardo de Serialización Retardo de Propagación Retardo de Componente Jitter (variación del retardo): Eco

5 Análisis de los informes del remitente y receptor para el cálculo de los parámetros de calidad de servicio Técnicas subjetivas de medición de calidad de servicio MOS (Mean Opinion Score) Modelo E Mejoramiento de la Calidad de Servicio: Plataforma NGN de CANTV Lenguaje de programación: JAVA Cualidades principales de Java Universalidad Sencillez Orientación a objetos Seguridad Adaptación a redes...66 CAPITULO III DESARROLLO DEL PROYECTO Fases del Proyecto Levantamiento de información Selección de software de automatización y captura Selección del Macro Recorder Selección del Software de Captura Base de Datos Retos en el Diseño de la Herramienta Características del diseño para la Herramienta de Automatización de medición de los parámetros de calidad de servicio de VoIP Implementación de la herramienta CAPÍTULO IV PRUEBAS REALIZADAS Y ANÁLISIS DE RESULTADOS Pruebas preliminares Pruebas con ambiente controlado Análisis del tráfico de VoIP CAPÍTULO V CONCLUSIONES Y RECOMENDACIONES BIBLIOGRAFIA

6 INDICE DE TABLAS Tabla 1. Códigos estándares de la voz digitalizada...46 Tabla 2. Impacto de las tramas perdidas en el factor Ie...47 Tabla 3. Rangos del retardo en un solo sentido...49 Tabla 4. Retardos Algorítmicos...50 Tabla 5. Retardos de Paquetización...51 Tabla 6. Retardos de Serialización...52 Tabla 7. Escala de MOS...59 Tabla 8. Relación entre técnica de codificación, tasa de transferencia y valor del MOS...60 Tabla 9. Valores aceptables del MOS y de R para CODECs de banda estrecha...61 Tabla 10. Formato de la Matriz de Selección...68 Tabla 11. Macro Recorders evaluados...69 Tabla 12. Matriz de Selección del Macro Recorder...72 Tabla 12. Softwares de Captura evaluados...81 Tabla 13. Matriz de Selección de los Softwares de Captura...83 Tabla 14. Estadísticas de los parámetros de Calidad de Servicio de la llamada Tabla 15. Promedio de Jitter, Retardo y Pérdida de Paquetes de la llamada Tabla 16. Estadísticas de los parámetros de Calidad de Servicio de la llamada Tabla 17. Promedio de Jitter, Retardo y Pérdida de Paquetes de la llamada Tabla 18. Estadísticas de los parámetros de Calidad de Servicio de la llamada Tabla 19. Promedio de Jitter, Retardo y Pérdida de Paquetes de la llamada Tabla 20. Estadísticas de los parámetros de Calidad de Servicio de la llamada Tabla 21. Promedio de Jitter, Retardo y Pérdida de Paquetes de la llamada Tabla 22. Estadísticas de los parámetros de calidad de servicio de la llamada Tabla 23. Promedio de Jitter, Retardo y Pérdida de Paquetes de la llamada Tabla 24. Resultados parciales de las tramas A y B Tabla 25. Valores totales de cada parámetro por llamada Tabla 26. Valor promedio de los parámetros de calidad de servicio para una llamada extremo a extremo Tabla 27. Análisis del tráfico de VoIP el día Tabla 28. Análisis del tráfico de VoIP el día Tabla 29. Análisis del tráfico de VoIP el día Tabla 30. Resumen del tráfico de VoIP de los 3 días Tabla 30. Promedio parcial y total de los retardos ida y vuelta Tabla 31. Resultados del retardo en el segmento NGN

7 INDICE DE FIGURAS Figura 1. Organigrama Principal CANTV...14 Figura 2. Organigrama de la Gerencia General Tecnología y Operaciones...15 Figura 3. Flujo de la voz...21 Figura 4. Anidamiento de Paquetes de Voz...22 Figura 5. Encabezado IP...24 Figura 6. Campo Versión...24 Figura 7. Campo Tipo de Servicio...25 Figura 8. Campo Banderas...26 Figura 9. Campo Opciones...27 Figura 10. Encabezado UDP...29 Figura 11. Pila de Protocolos...31 Figura 12. Encabezado RTP...31 Figura 13. Paquete de transporte RTCP...34 Figura 14. Tercer Cuerpo del Paquete RTCP...35 Figura 15. Transporte y comunicación entre fuente y receptor con la interacción entre los paquetes RTP y RTCP...36 Figura 16. Componentes de una aplicación de VoIP...38 Figura 17. Aplicación de los protocolos en las diferentes etapas de una llamada...43 Figura 18. Fuentes de Retardo...50 Figura 19. Fuentes de retardo...53 Figura 20. Pasos para mejorar la calidad de servicio...62 Figura 21. Plataforma NGN de CANTV...63 Figura 22. Funciones de KeyText Figura 23. Item en blanco...74 Figura 24. Selección de la opción Macro en el Item...75 Figura 25. Activación de una ventana, presionar un botón o selección de un menú...75 Figura 26. Agregar la hora y/o fecha...76 Figura 27. Agregar una combinación de teclas...76 Figura 28. Agregar pausas, tiempos de espera, loops o llamadas...77 Figura 29. Solicitar datos al usuario o mostrar un mensaje...78 Figura 30. Acción del Mouse...79 Figura 31. Ejecutar un programa, cargar una página web o enviar un correo electrónico...79 Figura 32. Programar un tinerario de ejecución del ítem...80 Figura 33. Pantalla principal de Wireshark

8 Figura 34. Base de Datos en Access...86 Figura 35. Función de cada Software...88 Figura 36. Diagrama de flujo con las rutinas automatizadas de Wireshark...89 Figura 37. Primera parte de la rutina de selección de la interfaz de red para realizar la captura...90 Figura 38. Segunda parte de la rutina de selección de la interfaz de red para realizar la captura...91 Figura 39. Rutina de finalización de la captura...91 Figura 40. Primera parte de la rutina de selección, copia y exportación de las estadísticas RTP...92 Figura 41. Segunda parte de la rutina de selección, copia y exportación de las estadísticas RTP...92 Figura 43. Rutina para filtrar los paquetes RTCP y ordenarlos de forma decreciente según el campo info Figura 44. Primera parte de la rutina de exportación de encabezados de un paquete RTCP a un archivo de texto...94 Figura 45. Segunda parte de la rutina de exportación de encabezados de un paquete RTCP a un archivo de texto...95 Figura 46. Formato del archivo rtdelay.txt...95 Figura 47. Diagrama de bloques de las rutinas a ejecutar en Java...97 Figura 48. Rutina de ejecución del proyecto...98 Figura 49. Formato del Reporte Final...99 Figura 50. Rutina de envío del correo electrónico Figura 51. Configuración de pantalla en Wireshark Figura 52. Configuración de los paquetes en la pantalla de Wireshark Figura 53. Pruebas preliminares Figura 55. Selección de las llamadas de VoIP Figura 56. Selección de las tramas Figura 57. Señalización de una llamada de ejemplo Figura 58. Señalización de la llamada Figura 59. Señalización de la llamada Figura 60. Señalización de la llamada Figura 61. Señalización de la llamada Figura 62. Señalización llamada

9 INDICE DE GRAFICAS Gráfica 1. Tráfico de VoIP el día Gráfica 2. Tráfico de VoIP el día Gráfica 3. Tráfico de VoIP el día

10 LISTA DE SÍMBOLOS Y ABREVIATURAS API: Application Programming Interface APP: Application (Aplicación) BRI: Basic Rate Interface. (Interfaz de razón básica) CANTV: Compañía Anónima Nacional Teléfonos de Venezuela CHA: Chacao CNT: Centro Nacional de Telecomunicaciones COR: Centro de Operaciones de la Red CQ: Custom Queuing CSRC: Contributing source DCN: Data Communication Network. (Red de Comunicación de Datos) DiffServ: Differentiated Services. (Servicios Diferenciados) EFR: Enhanced Full Rate FR: Full Rate FXO: Foreign Exchange Office FXS: Foreign Exchange Station GSM: Global System for Mobile communications GSTN: General Switched Telephone Network IOS: Internetwork Operating System. (Sistema Operativo) ITU: International Telecommunication Union ITU-T: ITU Telecommunication Standardization Sector (anteriormente CCITT) IP: Internet Protocol. (Protocolo de Internet) IPv4: Versión 4 del Protocolo de Internet IPv6: Versión 6 del Protocolo de Internet ISDN: Integrated Services Digital Network. (Red digital de servicios integrados) LAN: Local Area Network. (Red de Área Local) LAT: Local Area Transport. (Transporte de área local) LC: Logical Channel. (Canal Lógico) LCN: Logical Channel Number. (Numero de Canal Lógico) NGN: Redes de Nueva Generación NTN: National Terminal Number. (Número de Terminal Nacional) NTP: Network Time Protocol NUMA: Non-uniform memory access OSI: Open System Interconnection. (Interconexión de Sistemas Abiertos) OSS: Operation Support System. (Sistema de soporte de operaciones) 11

11 PAD: Packet Assembler / Disassembler. (Paquete para ensamblado y desensamblado) PBX: Private Business Exchange. PDN: Public Data Network. (Red Pública de Datos) PLP: Packet Layer Protocol. (Protocolo de Capa de Paquete) PQ: Priority Queuing. PSDN: Public Switched Data Network. (Red pública de conmutación de datos) PSN: Packet-Switched Network. (Red de Paquetes Conmutados) PSTN: Public Switched Telephone Network PT: Protocol Translation. (Translación de Protocolo) QoS: Quality of Service. (Calidad de Servicio) RC: Report Count RFC: Request For Comments. (Solicitud por Comentarios) RNR: Receiver Not Ready. (Receptor no Listo) RR: Receiver Report. (Informe del Receptor) RTCP: Real Time Control Protocol RTP: Real Time Transport Protocol SCN: Switched Circuit Network. (Red de Circuitos Conmutados) SDES: Source Description. (Descripción de Fuente): SSRC: Synchronization Source SVC: Switched Virtual Circuit. (Circuito virtual conmutado) TCP: Transmission Control Protocol. (Protocolo de control de transmisión) UDP: User Datagram Protocol VC: Virtual Circuit. (Circuito Virtual) VM: Virtual Machine. (Máquina Virtual) VoIP: Voz sobre IP WAN: Wide Area Network. (Red de Área Amplia) WFQ: Weight Fair Queuing 12

12 Capítulo 1 INTRODUCCIÓN En el presente capítulo se exponen detalladamente los aspectos más importantes del trabajo de pasantía, el cual se desarrolló en la empresa CANTV y se basó en el diseño de un sistema automatizado de medición de parámetros de calidad en el Servicio de Tráfico Telefónico sobre IP en las Redes de Nueva Generación (NGN) Planteamiento del Tema Es innegable la importancia de las telecomunicaciones dentro del sector económico, ya que ellas representan uno de los principales motores del desarrollo mundial. Todas las previsiones apuntan a que su importancia seguirá aumentando exponencialmente en la medida que surjan avances en la tecnología. En los últimos años, la industria de telecomunicaciones en América Latina exhibió una tendencia positiva. La expansión de la telefonía móvil, y en menor grado de Internet y banda ancha, han sido factores de crecimiento en la región, concentrando la mayor parte de las inversiones, fusiones y adquisiciones. En este sentido, los clientes de telefonía móvil han superado el número de líneas fijas en muchos de los países de la región (incluyendo Chile, Argentina, México, Brasil y Venezuela). Asimismo, el segmento de telefonía móvil ha atravesado un importante proceso de consolidación que comenzó en el 2003 con diversas adquisiciones empresariales a lo largo y ancho del continente. Particularmente en Venezuela el número de abonados telefónicos, tanto de telefonía fija como telefonía móvil celular, experimenta un aumento del 15% interanual aproximadamente. Dicha afirmación implicó que las compañías pioneras y operadoras como CANTV, se vieran en la necesidad de cambiar su enfoque, convirtiéndose en compañías flexibles y dinámicas capaces de adaptarse a este crecimiento y mantener una calidad de servicio sobresaliente. Para garantizar esto, CANTV ha llevado a cabo una reorganización interna respondiendo a la convergencia tecnológica, ha realizado una gran inversión en equipos de nuevas tecnologías y capacita continuamente a su personal en labores de monitoreo de su red de telecomunicaciones. 13

13 CANTV lleva a cabo actualmente un refrescamiento de imagen bajo el concepto Abrimos Horizontes, resaltando el compromiso de la empresa de innovar y mantenerse a la vanguardia de la tecnología. La meta de esta empresa es brindar total conexión con el mundo a través de la telefonía fija, la comunicación inalámbrica, el acceso a banda ancha y la mayor cobertura nacional de Movilnet y CANTV. Recientemente se modificó el organigrama de CANTV para incluir cargos que se hacen indispensables en este proceso de innovación y crecimiento. En la Figura 1 se puede apreciar el organigrama principal de la empresa, destacándose la Gerencia General de Tecnología y Operaciones en la cual se realizó el Proyecto de Grado. Figura 1. Organigrama Principal CANTV 14

14 Dentro de la Gerencia General de Tecnología y Operaciones se encuentra ubicada la Gerencia de Operaciones Centralizadas de la Red, como se puede apreciar en la Figura 2. Figura 2. Organigrama de la Gerencia General Tecnología y Operaciones El Centro de Operaciones de la Red de CANTV (COR), dependencia adscrita a la Gerencia General de Tecnología y Operaciones, se encarga de garantizar la continuidad operativa de los dispositivos de nueva tecnología. En particular, la Gerencia de Soporte a las Redes, realiza las labores de monitoreo de todos los elementos que componen la red nacional, detectando y subsanando problemas relacionados con los servicios de telefonía, tanto analógica como digital. Por otro lado allí se ejecutan rutinas de mantenimiento preventivo a los equipos y elementos. La Corporación CANTV cuenta hoy en día con una plataforma de NGN (Redes de Nueva Generación) que permite integrar los servicios de voz y datos sobre una misma tecnología. El servicio del sistema telefónico sobre estas Redes, debe acatar los estándares internacionales para cumplir con la Calidad de Servicio en el tráfico de voz sobre IP. Hay factores que indudablemente afectan la calidad del servicio tales como: latencia o retardo, jitter y pérdida de paquetes. 15

15 Todos los elementos que componen la red NGN de CANTV pueden fallar, ya que éstos laboran constantemente sin descanso alguno y con impresionantes niveles de tráfico. La metodología para reparar una falla comienza con la detección de la causa y el elemento donde se produjo. La labor de detección y prevención de fallas se lleva a cabo en los centros de operaciones; allí se encuentra el personal que ejecuta labores de monitoreo las veinticuatro (24) horas del día durante los siete (7) días de la semana. La función de monitoreo es considerada de alta prioridad para la prestación de un servicio de calidad para los usuarios; para ello, ese personal cuenta con una conexión remota con todos los elementos que conforman la red. Actualmente CANTV está adecuando un nuevo rol operacional, mejorando los sistemas de monitoreo para poder determinar la calidad de servicio de las llamadas IP en tiempo real. Hasta el momento, las llamadas no están siendo monitoreadas en tiempo real, esto implica que sólo después de que haya sido reportada la mala calidad de servicio en una llamada se pueden tomar medidas al respecto. Al no contar con una herramienta que capture las tramas IP cuando se produce el error, no es posible acertar rápidamente donde se produjo y cual fue la falla, por lo tanto, activar medidas para repararlo toma tiempo. Además, es posible, que en el momento que se decidan monitorear los elementos de la llamada reportada, no se vuelvan a producir algunas fallas que generan mala calidad de servicio, lo que desvirtuaría el primer reporte, por ello la importancia y necesidad de monitorear continuamente las llamadas y actuar inmediatamente ante un evento de mala calidad de servicio. Se hace necesario establecer modelos automatizados de medición a bajos costos que permitan monitorear, constantemente, los parámetros mencionados anteriormente. Ello garantizaría la calidad de las llamadas, al tomar acciones proactivas sobre los elementos NGN en el caso de presentarse una falla Descripción del Proyecto El Proyecto de Grado, en concordancia con las necesidades señaladas por la Gerencia, implementa el diseño de un sistema automatizado de medición de calidad en el Servicio de Tráfico Telefónico sobre IP, en la red NGN de CANTV de acuerdo a los estándares emitidos por la ITU-T (International Telecommunication Union). El sistema estará comprendido por 3 softwares que se eligieron de acuerdo a criterios de selección específicos para cada caso y evaluados en matrices de selección. 16

16 La función del primer software consiste en capturar trazas IP y medir los siguientes parámetros de Calidad de Servicio: el Retardo de los paquetes que contienen la voz, de la fuente al destino, a través de la red; el Jitter, que indica la variación en los tiempos de llegada entre los grupos de paquetes y finalmente la Pérdida de Paquetes, que se calcula al conocer el número original de paquetes obtenido de la captura y el total de paquetes recibidos entre los extremos. Después de la captura de las tramas IP, se exporta a archivos de texto la data referente a los parámetros de calidad. El segundo programa tiene como función procesar la data exportada por el primer software y adaptar los resultados a los elementos de la Red NGN de la empresa. En el análisis detallado de cada llamada contenida en estos archivos, se comparan los valores de jitter, retardo y pérdida de paquetes obtenidos con los valores máximos aceptables. En el caso de superar alguno de estos valores se genera un archivo temporal que resume todos los parámetros medidos en dicha llamada en particular. Al finalizar todo el análisis, se genera un reporte final que contiene todos los datos correspondientes a las llamadas con mala calidad de servicio. Por último, el tercer software que es el Macro Recorder, responde a la necesidad primordial de este proyecto, que es la automatización de la herramienta de medición. Esto se lleva a cabo con un script mediante el cual se automatizan los procesos realizados por el primer y segundo software y a su vez se realizan las funciones de notificación de eventos de mala calidad de servicio, mediante el envío de un correo electrónico con el reporte final a la Coordinación de Soporte de NGN. El uso del Macro Recorder elimina la realización de tareas repetitivas. Básicamente, se trata de un grupo de comandos de una aplicación, organizados según un determinado juego de instrucciones y cuya ejecución puede ser pedida de una sola vez para realizar la función que se desea. El alcance del Proyecto de Grado consiste en presentar a CANTV una propuesta detallada que incluya la solución a implementar y los costos asociados a dicha implementación. Dicha herramienta debe ser una aplicación de software de características amigables, que dé poco margen para errores del usuario y que cubra el procedimiento de monitoreo de calidad de servicio en el tráfico de voz de la Red NGN. 17

17 Finalmente debe contar con un medio de notificación de sucesos que pueda emitir mensajes de alarma al personal de supervisión y gerencia del COR cuando sea necesario con las bitácoras de los procesos de cualquier falla que se haya generado. Las mediciones se deben realizar en horas pico, es decir, cuando el tráfico IP es crítico. Dichas mediciones se establecen entre los elementos que usen protocolo IP, por lo tanto, se podrá realizar entre los elementos que tienen puertos de red por donde se transportan los paquetes de voz generados. Se espera que este proyecto tenga un impacto importante en dos aspectos fundamentales: optimizar la carga de tareas del personal del COR en la guardia correspondiente y establecer un procedimiento estándar para el proceso de monitoreo de los parámetros de calidad en el Servicio de Tráfico Telefónico sobre IP, que garantice el cumplimiento de todos los pasos previos y posteriores al mismo. Es importante destacar que debido al proceso de notificación inmediata de errores de calidad de servicio al personal del COR, los usuarios notarán una mejora del servicio prestado por CANTV, ya que cualquier falla será atacada antes de que éstos la reporten, por lo tanto la empresa podrá brindar un nuevo valor agregado. Por último, este proyecto busca estimular el desarrollo de nuevas aplicaciones de automatización de procesos rutinarios, fomentando de esta manera la creación de herramientas con un impacto similar a éste Estructura del Informe de Pasantía A continuación se hace una breve descripción del contenido de los capítulos, con la intención de destacar la información más relevante con respecto al proyecto, las actividades propias del desarrollo del mismo y las etapas cubiertas para la consecución de los objetivos. Capítulo 1. Introducción: este capítulo contiene la presentación del proyecto, dando a conocer sus características más importantes y su alcance. Además se hace una descripción de la empresa y del departamento donde se elaborará el proyecto. 18

18 Capítulo 2. Conceptos y Fundamentos: abarca el sustento informativo y teórico necesario para la realización y comprensión del proyecto. Contiene información referente a: telecomunicaciones, protocolos IP, UDP, RTP, RTCP, calidad de servicio, redes de nueva generación (NGN), aplicaciones de captura (Sniffers) y aplicaciones de automatización (Macro Recorders). Capítulo 3. Desarrollo del Proyecto: en este capítulo se presenta una visión global del proyecto así como el desarrollo específico de cada una de las fases. Por otro lado se plantean las condiciones en las que se debe ejecutar la herramienta y se describen las dificultades y retos presentados durante su diseño. Capítulo 4. Pruebas realizadas y Análisis de Resultados: ofrece una descripción de las pruebas realizadas durante el diseño de la herramienta de medición; la implementación final se debió a un proceso escalonado de pruebas preliminares. Capítulo 5. Conclusiones y Recomendaciones: a partir de los resultados finales de la implementación de la herramienta, se exponen algunas conclusiones y recomendaciones de carácter general, dirigidas a la Gerencia del COR y al personal que allí labora. 19

19 CAPÍTULO II CONCEPTOS Y FUNDAMENTOS En el presente capítulo se establece el marco teórico relacionado con el Proyecto de Grado, facilitando la comprensión y desarrollo del mismo. Se puntualizan los conceptos más importantes, entre ellos se encuentran: telecomunicaciones, protocolos IP, UDP, RTP, RTCP, calidad de servicio, redes de nueva generación (NGN), aplicaciones de captura (Sniffers) y aplicaciones de automatización (Macro Recorders) Voz sobre redes de datos La voz, el vídeo y los datos convergen sobre una sola red de información que es transparente para el usuario e independiente de los medios que emplee para conectarse, ya sean fijos o inalámbricos. El inicio de la investigación en ésta área se remonta varios años atrás. Uno de los primeros desarrollos que vieron la luz del día (en marzo de 1997) fue el de la compañía MCI, de los Estados Unidos: un proyecto de 100 millones de dólares llamado VAULT. Esta nueva arquitectura de red permitía interconectar y combinar las redes tradicionales de telefonía con redes de datos. En la actualidad, se avanza decididamente hacia una integración de redes y servicios con objeto de lograr una única red multimedia, a partir de la tecnología digital que permita mayor nivel de interactividad entre sistemas complejos e inteligentes. La Banda Ancha permite transmitir vídeo analógico, digital, de alta definición, servicios de IP y llamadas telefónicas. Todos estos son servicios interactivos que se transportan por medio de una red mixta de fibra y cable coaxial, bidireccional y digital. Los emprendimientos de telefonía sobre redes IP llegan al punto de la construcción de redes especiales, que les ofrecen tanto a los carriers como a los particulares, la oportunidad de alcanzar determinados destinos. A esta aplicación se le llama Voz sobre IP (VoIP) 20

20 Paquetización de la voz Previo a la transmisión de las muestras codificadas de voz sobre redes de datos, es necesario armar paquetes. Si la voz está codificada con ley A, una conversación consiste en un flujo de 64 kb/s. Cada muestra dura 125 µs. Si bien se podría formar un paquete con cada muestra de voz, esto generaría un sobrecarga ( overhead ) demasiado importante, ya que cada paquete requiere de cabezales. Por otro lado, si se espera a juntar demasiadas muestras de voz, para formar un paquete con mínima sobrecarga porcentual, se pueden introducir retardos no aceptables. Un paquete IP puede tener hasta 1500 bytes de información. Si con muestras de 64 kb/s se quisiera completar los 1500 bytes del paquete IP, se introduciría un retardo de 125µs x 1500 = 187,5 ms. Esta demora no es aceptable en aplicaciones de voz. Por esta razón, se toman generalmente ventanas de 10 a 30 ms, como se aprecia en la Figura 3. Las muestras de voz de cada una de estas ventanas consecutivas se juntan y con ellas se arman paquetes. Figura 3. Flujo de la voz El anidamiento de los paquetes y su respectiva estructura se muestra en la Figura 4 a continuación: 21

21 Figura 4. Anidamiento de Paquetes de Voz Protocolos Protocolo IP (Internet Protocol) Un protocolo es un conjunto unificado de normas que configura un estándar, comúnmente aceptado, para el cumplimiento de un procedimiento necesario para obtener un resultado definido de antemano. En un contexto más sencillo, un protocolo se puede definir como las reglas que gobiernan la semántica, sintaxis y sincronización de la comunicación. En el caso de la IP, se trata de un conjunto de reglas para desmenuzar y empaquetar fragmentos de información en pequeños paquetes o datagramas que, aprovechando la infraestructura mundial de la World Wide Web, son distribuidos, cada uno de ellos, por el trayecto que en ese momento se considere óptimo, hasta alcanzar un destino común en el que son reorganizados y consolidados para la reconstrucción de la información original. El primer paso para trasmitir la voz sobre el protocolo IP consiste en digitalizar la voz mediante un codificador (llamado a veces "CODEC", de Codificador DEsCodificador). El mensaje de voz queda así reducido a una serie de unos y ceros 22

22 (es decir: queda en formato binario, apto para su tratamiento por ordenadores o procesadores específicos, como por ejemplo los DSP: Procesadores de Señales Digitales). Una vez en este formato numérico, se procede a su compresión (es decir: a la eliminación de todo aquello que pueda ser considerado no-información o información redundante) y a su división en pequeños bloques que son empaquetados en el formato definido por el protocolo IP, para poder ser enviados y, tras su recepción, desempaquetados, descomprimidos y reagrupados en el orden lógico que permita la reconstrucción del mensaje original. Finalmente, se procede a la reconversión del formato digital al analógico, para su conversión en una señal sonora física, que es la que se oye a través del altavoz del terminal telefónico. El Protocolo de Internet (IP) es un protocolo no orientado a conexión usado tanto por el origen como por el destino para la comunicación de datos por medio de una red de paquetes conmutados. Este protocolo no necesita una configuración previa para enviar paquetes a un equipo con el que no se había comunicado antes. El Protocolo de Internet provee un servicio de datagramas no fiable, denominado mejor esfuerzo (best effort), ya que no prevé ningún mecanismo para determinar si un paquete alcanza o no su destino y no proporciona seguridad sobre los datos transmitidos, sólo la proporciona a las cabeceras mediante checksums o sumas de comprobación. Si los datos a transmitir ("datagramas") superan el tamaño máximo negociado como unidad máxima de transferencia (MTU), se podrá dividir en paquetes más pequeños, y reensamblar luego cuando sea necesario. Estos fragmentos podrán ir cada uno por un camino diferente dependiendo de como estén de congestionadas las rutas en cada momento [1] Encabezado IP El datagrama IP consiste en una parte de encabezado y una parte de texto, el encabezado posee una parte fija de 20 bytes y una parte opcional de longitud variable. Su transmisión es en orden de Big Endian; el término Endian se refiere a la forma en que los números binarios de bytes múltiples son guardados en la computadora. Big Endian significa que se guardan de izquierda a derecha, comenzando por el bit con mayor orden en el campo 23

23 versión. [2] En la Figura 5 se presenta la estructura y campos del encabezado IP Versión IHL Tipo de Servicio Longitud Total Identificación Banderas Desplazamiento del fragmento Tiempo de vida Protocolo Suma de verificación del encabezado Dirección de origen Dirección de destino Opciones (0 o más palabras) Figura 5. Encabezado IP Versión (4 bits): El campo de versión lleva el registro de la versión del protocolo al que pertenece el datagrama tal y como se presenta en la Figura 6. Versión 0 Reservado Descripción 4 IP, Internet Protocol. 5 ST, ST Datagram Mode. 6 SIP, Simple Internet Protocol. SIPP, Simple Internet Protocol Plus. IPv6, Internet Protocol. 7 TP/IX, The Next Internet. 8 PIP, The P Internet Protocol. 9 TUBA Reservado Figura 6. Campo Versión IHL (4bits): Determina la longitud del encabezado en palabras de 32 bits, el menor valor válido es 5, cifra que se aplica cuando no hay opciones, mientras que el valor máximo de este campo es 15, esto limita el encabezado a 60 bytes. 24

24 Tipo de servicio (8bits): Especifica los parámetros para el tipo de servicio requerido. Son posibles varias combinaciones de confiabilidad y velocidad. Originalmente, el campo de 6 bits contenía (de izquierda a derecha) un campo de Precedencia de tres bits y tres banderas, D, T y R. El bit M se agregó en el RFC Esto se puede observar en la Figura 7. Figura 7. Campo Tipo de Servicio Longitud Total (16 bits): Contiene la longitud total del datagrama, incluyendo encabezado y datos, la longitud máxima es de 65,535 bytes. Identificación (16 bits): Usado para determinar a que datagrama pertenece un fragmento recién llegado. Todos los fragmentos de un datagrama contienen un mismo valor de identificación. Banderas (3 bits): En la Figura 8 a continuación se presenta un esquema de estas banderas 25

25 Figura 8. Campo Banderas o R, Reservado. 1 bit. Debe ser colocado en 0. o DF, Don't fragment. 1 bit. Significa no fragmentar, es una orden para los enrrutadores de que no fragmenten el datagrama, porque el destino es incapaz de juntar las piezas de nuevo. o MF, More fragments. 1 bit Indica si el datagrama contiene fragmentos adicionales. Desplazamiento del fragmento (13 bits): Indica en que parte del datagrama actual va el presente fragmento. Todos los fragmentos excepto el último del datagrama deben tener un múltiplo de 8 bytes, que es la unidad de fragmentos elemental Tiempo de vida (8 bits): Es un contador que limita la vida de un paquete. Cuando este campo se decrementa y llega a cero el paquete se descarta y se envía de regreso un paquete de aviso al host de origen. Protocolo (8bits): Indica el protocolo de las capas superiores al que debe entregarse el paquete. TCP y UDP son los más comunes, sin embargo, la numeración de los protocolos es global en toda Internet y se define en el RFC

26 Suma de verificación del encabezado (16 bits): Verifica solamente el encabezado; permite detectar errores generados por palabras de memoria erróneas en un enrutador. El algoritmo consiste en sumar todas las medias palabras de 16 bits a medida que llegan, usando aritmética de complemento a uno, y luego obtener el complemento a uno del resultado. Se supone que la suma de verificación del encabezado es cero cuando llega el paquete al destino. Dirección de origen y dirección de destino (64 bits): Indican el número de red y el número de host del origen y destino. Opciones: Proporciona un recurso que permite que las versiones subsiguientes del protocolo incluyan información no presente en el diseño original. El campo de Opciones se rellena para completar múltiplos de cuatro bytes. Originalmente se definieron cinco opciones, como se lista a continuación en la Figura 9, pero se han agregado otras más. La lista completa ahora se mantiene en la línea Opción Seguridad Enrutamiento estricto desde el origen Enrutamiento libre desde el origen Registrar ruta Marca de tiempo Descripción Especifica qué tan secreto es el datagrama Indica la ruta completa a seguir Da una lista de los enrutadores que no deben evitarse Hace que cada enrutador agregue s dirección IP Hace que cada enrutador agregue su dirección y su marca de tiempo Figura 9. Campo Opciones Protocolo UDP (Protocolo de Datagramas de Usuario) UDP, es un protocolo no orientado a la conexión. Proporciona una forma para que las aplicaciones envíen datagramas IP encapsulados sin tener que establecer una conexión y por lo tanto no proporciona ningún tipo de control de errores ni de flujo, aunque si utiliza mecanismos de detección de errores. Cuando se detecta un error en un datagrama, en lugar de entregarlo a la aplicación, se descarta. Como el protocolo es no orientado a la conexión, cada datagrama UDP existe independientemente del resto de los datagramas [3]. 27

27 UDP se define en el RFC 768 de la siguiente manera [4] : este Protocolo de Datagramas de Usuario (UDP: User Datagram Protocol) se define con la intención de hacer disponible un tipo de datagramas para la comunicación por intercambio de paquetes entre ordenadores en el entorno de un conjunto interconectado de redes de computadoras. Este protocolo asume que el Protocolo de Internet (IP: Internet Protocol) se utiliza como protocolo subyacente. UDP transmite segmentos que consisten en un encabezado de 8 bytes, seguido por la carga útil. El protocolo UDP es muy sencillo y tiene utilidad para las aplicaciones que requieren pocos retardos o para ser utilizado en sistemas sencillos que no pueden implementar el protocolo TCP. El número de protocolo es 17 (21 octal) cuando se usa en el Protocolo de Internet. [5] Las características del protocolo UDP son: No garantiza la fiabilidad. No se asegura que cada datagrama UDP transmitido llegue a su destino. Es un protocolo del tipo best-effort porque hace lo que puede para transmitir los datagramas hacia la aplicación pero no puede garantizar que la aplicación los reciban. No preserva la secuencia de la información que proporciona la aplicación. La información se puede recibir desordenada y la aplicación debe estar preparada por si se pierden datagramas, llegan con retardo o llegan desordenados. El módulo UDP debe ser capaz de determinar las direcciones de origen y destino en un entorno Internet así como el campo de protocolo de la cabecera del protocolo Internet. Una posible interfaz UDP/IP devolvería el datagrama de Internet completo, incluyendo toda la cabecera, en respuesta a una operación de recepción. Una interfaz de este tipo permitiría también al módulo UDP pasar un datagrama de Internet completo con cabecera al módulo IP para ser enviado. IP verificaría ciertos campos por consistencia y calcularía la suma de control de la cabecera del protocolo Internet Encabezado UDP La Figura 10 muestra los campos de un datagrama UDP: 28

28 Puerto de origen Longitud UDP Data ::: Puerto de destino Suma de comprobación Figura 10. Encabezado UDP Puerto de Origen (16 bits): Número de puerto del que envía, se pone en cero si no se utiliza Puerto de Destino (16 bits): Indica el puerto al que el paquete está dirigido. Longitud UDP (16bits): La longitud en bytes del encabezado UDP y la data encapsulada. El mínimo valor de este campo es 8 y la longitud máxima de un datagrama UDP es de bytes. Suma de verificación UDP (16bits): Este campo es opcional, es el complemento a uno de 16bits de la suma de los complementos a uno de las palabras de la combinación de una pseudo-cabecera construida con información de la cabecera IP, la cabecera UDP y los datos, y rellenada con octetos de valor cero en la parte final (si es necesario) hasta tener un múltiplo de dos octetos Aplicación del Protocolo UDP El protocolo UDP al no estar orientado a la conexión y no enviar ningún mensaje para confirmar que se han recibido los datagramas, su uso se adecua cuando se quiere transmitir información en modo multicast (a muchos destinos) o en modo broadcast (a todos los destinos), ya que no tiene sentido esperar la confirmación de todos los destinos para continuar con la transmisión. Lo que realmente proporciona es una interfaz al protocolo IP con la característica agregada de desmultiplexar varios procesos utilizando puertos. UDP es ideal para aplicaciones que necesitan tener control preciso sobre el flujo de paquetes aunque no se asegure que cada datagrama llegue a su destino, control de errores o temporización. 29

29 Los usos principales de este protocolo son: Servidor de Nombres de Internet [6] Transferencia Trivial de Ficheros (Trivial File Transfer) [7] Protocolo RTP (Real-Time Transport Protocol) El protocolo RTP es utilizado para el transporte de la voz. El protocolo de transporte en tiempo-real RTP y el protocolo de control RTCP están definidos en el RFC-3550 del año El objetivo del protocolo RTP consiste en asegurar una calidad de servicio (Quality of Service QoS) para servicios del tipo tiempo-real. Se utiliza con UDP/IP para identificación de carga útil, la numeración secuencial, el reporte de la calidad (función del protocolo RTCP) y la medición de tiempo. Para ello entre sus funciones se encuentran: la memorización de datos, la simulación de distribución interactiva, el control y mediciones de aplicaciones [8]. El RTP trabaja en la capa 4 y sobre UDP, por lo tanto posee un checksum para detección de error y la posibilidad de multiplexación de puertas (port UDP). Las sesiones de protocolo RTP pueden ser multiplexadas, para ello se recurre a un doble direccionamiento mediante el número de puerto en UDP y las direcciones IP. Sobre RTP se disponen de protocolos de aplicación del tipo H.320/323 para vídeo y voz. Para la reservación de ancho de banda el RTP funciona en conjunto con RSVP (capa 3) de esta forma asegura la QoS del tipo Garantizada. La QoS del tipo Diferenciada se logra mediante la priorización de tráfico que puede adoptar dos alternativas. En IP se pueden asignar diversas alternativas de prioridad para formar una cola de espera en routers; un algoritmo particular de gestión de prioridad de tráfico es el WFQ (Weighted Fair Queuing) que utiliza un modelo de multiplexación TDM para distribuir el ancho de banda entre clientes. Cada cliente ocupa un intervalo de tiempo en un Round-Robin. El RTP provee transporte para direcciones unicast y multicast. Es por ello que se encuentra involucrado el protocolo IGMP (Internet Group Management Protocol) para administrar el servicio multicast. El paquete de RTP incluye un encabezado fijo y el payload de datos; RTCP utiliza el encabezado del RTP y ocupa el campo de carga útil. 30

30 El protocolo RTP - HC (Real-Time Protocol - Header Compression) permite la compresión del encabezado para mejorar la eficiencia del enlace en paquetes de corta longitud en la carga útil. Reduce los 40 Bytes de encabezado en RTP/UDP/IP a una fracción de 2 a 5 Bytes, eliminando aquellos repetidos en todos los paquetes. 11 La posición RTP en la pila de protocolos se aprecia a continuación en la Figura Espacio de usuario Kernerl del SO Aplicación multimedia RTP Interfaz de socket UDP IP Ethernet Figura 11. Pila de Protocolos Encabezado RTP El encabezado RTP está comprendido por los siguientes campos tal y como se observa en la Figura 12 [9]: V P X CC M Tipo de Carga útil Número de Secuencia Marca de Tiempo Identificador de origen de sincronización Identificador de origen de contribución (CSRC [0..15] :::) Versión (2bits): Figura 12. Encabezado RTP Número del tipo de versión, la versión definida por la especificación actual es 2. Relleno, P (1bit): Si hay uno o más bytes al final del paquete que no es parte la carga útil, este bit estará colocado. El último bit del paquete indica el número de bytes de relleno. El relleno puede ser necesario para algunos algoritmos de encriptación. 31

31 Extensión, X (1bit): Si el encabezado fijo es seguido por una extensión del encabezado, el bit de extensión estará colocado. Este mecanismo permite añadir información al encabezado RTP mediante implementaciones. Conteo CSRC (CC), (4 bits): Especifica el número de identificadores CSRC que sigue el encabezado fijo, si éste es cero la fuente de sincronización es la fuente de la carga útil. El marcador (M - Marker), (1 bit): Un bit de marcador definido por el perfil particular de media. La carga útil Type (PT), (7 bits): Un índice en una tabla de perfiles de media que describe el formato de carga útil. Los mapeos de carga útil para audio y video están especificados en el RFC Número de secuencia, (16 bits): El número de secuencia se incrementa por cada paquete RTP enviado, y puede ser usado por el receptor para detectar paquetes perdidos y para restaurar la secuencia de paquete. El valor inicial de la secuencia es aleatorio e impredecible para evitar ataques a la encriptación. Timestamp, (32 bits): Refleja el instante de muestreo del primer byte en la carga útil. Varios paquetes consecutivos pueden tener el mismo timestamp si son lógicamente generados en el mismo tiempo - por ejemplo, si son todo parte del mismo frame de video. CSRC (Contributing source), (32 bits cada uno): Identifica las fuentes contribuyentes para la carga útil. El número de fuentes contribuyentes está indicado por el campo de la cuenta CSRC; allí puede haber más de 16 fuentes contribuyentes. Si hay fuentes contribuyentes múltiples, entonces la carga útil son los datos mezclados de esas fuentes. 32

32 SSRC (Synchronization source), (32 bits): Identifica la fuente de sincronización. Si la cuenta CSRC es cero, entonces la fuente de carga útil es la fuente de sincronización. Si la cuenta CSRC es distinta a cero, entonces el SSRC identifica el mixer (mezclador) Protocolo RTCP (Real-Time Control Protocol) El protocolo RTCP completa a RTP monitoreando la calidad de servicio y obteniendo información acerca de los participantes en la sesión, debido a que facilita la comunicación entre extremos para intercambiar datos. RTCP se basa en la transmisión periódica de paquetes de control a todos los participantes en la sesión mediante el mismo método de RTP de distribución de paquetes de datos. El protocolo UDP dispone de distintas puertas (UDP Port) como mecanismo de identificación de protocolos [10]. La función primordial de RTCP es la de proveer una realimentación de la calidad de servicio. Se relaciona con el control de congestión y flujo de datos. El RTCP involucra varios tipos de mensajes, entre ellos: SR Send report (informe de emisión): conjunto de estadísticas de transmisión y recepción que proviene de participantes que son emisores activos. Dispone de 3 secciones bien diferenciadas: 1. Los primeros 8 Bytes se refieren a un encabezado común. 2. La segunda parte de 20 Bytes permite la evaluación de diferentes parámetros (retardo, jitter, eficiencia de datos, etc). 3. La tercera parte de 24 Bytes lleva reportes que han sido obtenidos desde el último reporte informado. Incluye los siguientes reportes: cantidad total de paquetes RTP perdidos y a la proporción de los mismos; la cantidad de paquetes recibidos y el jitter entre paquetes; el horario del último paquete recibido y el retardo de transmisión del mismo. RR Receiver Report (informe del receptor): conjunto de estadísticas que sólo provienen de participantes receptores. 33

33 SDES Source Description (descripción de fuente): los paquetes de descripción de fuente están compuestos de varios elementos, incluido el CNAME (Canonical Name). Constituyen la tarjeta de visita de la fuente. Bye (mensaje de fin): indica que se termina una sesión. APP Application: Funciones específicas de una determinada aplicación Diagrama del paquete de transporte RTCP El diagrama del paquete de transporte RTCP se presenta a continuación en la Figura 13: 0 31 V P RC PT=SR=200 Longitud Sender (SSRC del autor del reporte) NTP TImestamp (byte más significativo) NTP TImestamp (byte menos significativo) RTP Timestamp Sender s Packet Count Sender s Octet Count SSRC 1 (SSRC de la primera fuente) Datos RR adicionales SSRC N Datos RR adicionales Figura 13. Paquete de transporte RTCP Primer Cuerpo: Versión (2bits) Padding P (1 bit) RC. Report Count (5 bits) PT. Carga útil. (8 bits) Longitud (16 bits) Longitud del reporte SSRC que lo origina. (32 bits) 34

34 Segundo Cuerpo: NTP timestamp: segundos desde el 1/1/1900 entero y decimal. Instante de tiempo en que se envía el reporte (32 bits +32 bits). RTP timestamp: el mismo instante en ticks de RTP (equivalencia). (32 bits) Paquetes enviados desde el inicio de la sesión por (SSRC). (32 bits) Octetos enviados desde el inicio de la sesión por (SSRC). (32 bits) Tercer Cuerpo: Conjunto de RR, uno por cada fuente escuchada, tal y como se aprecia a continuación en la Figura 14. SSRC de la fuente sobre la que se reporta Tasa de pérdidas Nº acumulado de paquetes perdidos Nº de secuencia mayor recibido Variación del retardo entre llegadas: J(i)=J(i-1)+( Di -J(i-1))/16 Ultimo SR y tiempo transcurrido desde entonces Figura 14. Tercer Cuerpo del Paquete RTCP Los destinatarios de los paquetes RTP devuelven información sobre la calidad de recepción, utilizando diferentes formas de paquetes RTCP, según si ellos mismos son emisores de contenido o no. Los dos tipos, SR y RR, contienen ninguno, uno o varios bloques de informe de receptor, permitiendo así la sincronización de las fuentes de las cuales el receptor ha recibido un paquete de contenido RTP desde el último informe. En la Figura 15 se observa un diagrama que ilustra el transporte y comunicación entre fuente y receptor con la interacción entre los paquetes RTP y RTCP, los cuales poseen contenido de audio, video, etc. e informes de recepción respectivamente. 35

35 Paquete RTP: contenido R T P Encabezado Contenido: Audio, video, etc. Fuente Receptor Paquete RTCP: información R T C P Encabezado Descripción informes de recepción Figura 15. Transporte y comunicación entre fuente y receptor con la interacción entre los paquetes RTP y RTCP Protocolo NTP (Network Time Protocol) NTP es un protocolo de Internet que, mediante el enrutamiento de paquetes que tengan latencia variable, sincroniza los relojes de los sistemas informáticos. Dicho protocolo fue diseñado para resistir las consecuencias de una latencia variable y utiliza como capa de transporte al puerto UDP 123. NTP surgió en 1985 y sigue vigente, su autor original fue Daye Mills de la Universidad de Delaware. Este protocolo emplea la escala de tiempo UTC y el Algoritmo de Marzullo e incluye soporte para características como segundos intercalares [11]. Un segundo intercalar o segundo adicional es un ajuste de un segundo para mantener los estándares de emisión de tiempo cercanos al tiempo solar medio. NTPv4 se mantiene el sincronismo hasta 10 milisegundos (1/100 segundos) a través de Internet, y en redes de área local sobre condiciones ideales puede acercarse hasta 200 microsegundos (1/5000 segundos) o más. El demonio NTP de unix es un proceso de nivel de usuario que se ejecuta continuamente en la máquina que soporta NTP y la mayor parte del protocolo está implementado en ese proceso de usuario. 36

36 Para el mejor rendimiento de NTP, en vez de usar la intervención de un demonio NTP externo, se emplea un reloj NTP Standard con lazo de seguimiento de fase, implementado en el kernel del sistema operativo NTP emplea un sistema de jerarquía de estratos de reloj, en donde los sistemas de estrato 1 se sincronizan con un reloj externo (GPS o reloj de radio). Por su parte, los sistemas de estrato 2 de NTP derivan su reloj de uno ó más de los sistemas de estrato 1 y así sucesivamente. (Cabe mencionar que esto es diferente de los estratos de reloj utilizados en los sistemas de telecomunicaciones) [12]. Las estampas de tiempo empleadas por NTP consisten en un segundo de 23bit y una parte fraccional de 32bit, dando así una escala de 232 segundos (136 años) con una resolución teórica de 32 2 segundos (0.233 nanosegundos) VoIP (Voice Over Internet Protocol) VoIP significa en inglés Voice Over Internet Protocol. La función principal de VoIP consta en permitir que la voz viaje a través de Internet en paquetes IP. La telefonía IP lleva a cabo la transmisión tanto de voz como datos. VoIP es una tecnología que permite encapsular la voz en paquetes para ser transportados sobre redes de datos sin tener que disponer de la red pública de telefonía conmutada conocida como la PSTN, término general que se refiere a la diversidad de redes y servicios telefónicos existentes a nivel mundial que son redes desarrolladas a lo largo de los años para transmitir las señales vocales. La voz se convierte previamente a datos, entre dos puntos distantes. Esto hace posible el uso de las redes de datos para realizar llamadas telefónicas, y por lo tanto desarrollar una única red convergente que curse todo tipo de comunicación, ya sea voz, datos, video o cualquier tipo de información. La PSTN fundamenta su concepto en la conmutación de circuitos, es decir, la realización de una comunicación necesita del establecimiento de un circuito físico durante todo el tiempo que se tome la llamada, incluyendo los silencios, por lo tanto los recursos se liberan al culminar la llamada y esto limita el uso de los mismos. 37

37 Por su parte, en una conversación de telefonía IP se envían múltiples conversaciones a través del mismo canal, conocido como circuito virtual y se codifican en paquetes y en flujos independientes, por lo tanto, no se usan circuitos físicos y en el momento que se detecta un silencio en una conversación, los paquetes de datos de otras conversaciones pueden ser transmitidos por la red, esto hace mucho eficiente el uso de recursos Componentes principales de VoIP: A continuación en la Figura 16 se aprecian los componentes de una aplicación de VoIP, los cuales serán explicados inmediatamente: Figura 16. Componentes de una aplicación de VoIP Los siguientes elementos ya disponibles en el mercado, permiten según diferentes diseños construir las aplicaciones VoIP: Adaptadores para PC. Hubs Telefónicos. Unidades de audioconferencia múltiple. (MCU Voz). Teléfonos IP. El Teléfono IP es un terminal que tiene soporte VoIP nativo y puede conectarse directamente a una red IP. La red IP provee conectividad entre todos los terminales, ésta puede ser una red IP privada, una Intranet o el Internet 38

38 Servicios de Directorio. Un directorio es una base de datos optimizada para lectura, navegación y búsqueda. Los directorios tienden a contener información descriptiva basada en atributos y tienen capacidades de filtrado muy sofisticada. Los directorios generalmente no soportan transacciones complicadas ni esquemas de vuelta atrás como los que se encuentran en los sistemas de bases de datos diseñados para manejar grandes y complejos volúmenes de actualizaciones. Las actualizaciones de los directorios son normalmente cambios simples, o todo o nada, siempre y cuando estén permitidos. Los directorios están afinados para dar una rápida respuesta a grandes volúmenes de búsquedas. Estos tienen la capacidad de replicar la información para incrementar la disponibilidad y la fiabilidad, al tiempo que reducen los tiempos de respuesta. Cuando la información de un directorio se replica, se pueden producir inconsistencias temporales entre las réplicas mientras ésta se está sincronizando. Hay muchas formas diferentes de proveer un servicio de directorio. Diferentes métodos permiten almacenar distintos tipos de información en el directorio, tener distintos requisitos sobre como la información ha de ser referenciada, consultada y actualizada, como es protegida de los accesos no autorizados, etc. Algunos servicios de directorio son locales, es decir, proveen el servicio a un contexto restringido. Otros servicios son globales y proveen servicio a un contexto mucho más amplio. Los servicios globales normalmente son distribuidos, esto significa que los datos están repartidos a lo largo de distintos equipos, los cuales cooperan para dar el servicio de directorio. Típicamente, un servicio global define un espacio de nombres uniforme que da la misma visión de los datos, independientemente de donde se esté, en relación a los propios datos. El servicio DNS (Domain Name System) es un ejemplo de un sistema de directorio globalmente distribuido. Servidor. El servidor provee el manejo y funciones administrativas para soportar el enrutamiento de llamadas a través de la red. o Sistema basado en H.323 Gatekeeper. o Sistema basado en SIP Servidor SIP. 39

39 o Sistema basado en MGCP o MEGACO Call Agent (Agente de llamadas). Gatekeeper. El Gatekeeper es un elemento opcional en la red, su función es gestionar y controlar los recursos de la red, para evitar situaciones de saturación de la misma. Cuando el gatekeeper está presente, todos los demás elementos que contacten dicha red deben hacer uso de éste. Gateways (pasarelas RTC / IP). El Gateway convierte las señales desde las interfaces de telefonía tradicional (POTS, T1/E1, ISDN, E&M trunks) a VoIP y provee un acceso permanente a la red IP. Las llamadas de voz se digitalizan, codifican, comprimen y paquetizan en un gateway de origen y luego, se descomprimen, decodifican y rearman en el gateway de destino. El término pasarela de VoIP en ocasiones también se suele utilizar para hacer referencia a otros elementos funcionales, en tal caso se le suelen llamar pasarelas de VoIP especiales, en tanto que se posicionan entre redes IP para desarrollar determinadas funciones de mapping, por ejemplo en la capa IP. Entidades específicas como proxies VoIP, transcodificadores VoIP, traductores de direcciones de red VoIP, etc., caen en esta categoría de pasarelas de VoIP. El Gateway es un elemento esencial en la mayoría de las redes, su misión es la de enlazar la red VoIP con la red telefónica analógica PSTN o RDSI. Se considera al Gateway como una caja que por un lado tiene un Interface LAN Ethernet, Frame Relay o ATM y por el otro dispone de uno o varios de los siguientes interfaces: o FXO (Foreign Exchange Office). Para conexión a la red telefónica básica. o FXS (Foreign Exchange Station). Para conexión a teléfonos analógicos. o E&M. Es una interfaz en un dispositivo VoIP que le permite ser conectado a las líneas troncales analógicas de un PBX (Private Business exchange). 40

40 o BRI (Basic Rate Interface). Interfaz de razón básica. Servicio ISD que proporciona dos canales B más un canal de datos. La BRI es adecuada para negocios pequeños. o PRI. Acceso primario RDSI (Red Digital de Servicios Integrados) Existen dos tipos de Gateways: o Gateway H.323/H.320: realiza la conversión entre estos dos formatos de forma que los terminales H.323 se pueden comunicar con equipos RDSI de videoconferencia, que pueden formar parte de la red corporativa o estar situados en la red pública. o Gateway H.323/RTB (Voz sobre IP): Hacen posible las comunicaciones de voz entre los terminales H.323 y los teléfonos convencionales, estén en la red corporativa o en la red pública. Los Gateways tienen una serie de atributos que caracterizan el volumen y tipos de servicios que pueden proveer, tales como: o Capacidad: Expresa el volumen de servicio que puede brindar el gateway; está relacionado directamente con el número de puertos que tiene (igual al número máximo de llamadas simultáneas) y la velocidad del enlace de acceso. o Codecs de voz utilizados. o Protocolos de señalización soportados, tanto relativos a redes de VoIP como relativos a redes SCN (Red de Circuitos Conmutados). o Rango de direccionado, que es el rango o abanico de números telefónicos de los cuales se tiene acceso en la GSTN (General Switched Telephone Network) desde la red IP. En general, las pasarelas de interconexión (gateways) tienen que proporcionar los siguientes "mecanismos" o funciones: o Adaptación de señalización - básicamente tiene que ver con las funciones de establecimiento y finalización de las llamadas. 41

41 o Control de los medios - se relaciona con la identificación, procesamiento e interpretación de eventos relacionados con el servicio generado por usuarios o terminales. o Adaptación de medios - corresponde a los requerimientos de las redes Los gateways de interconexión cumplen la función control de medios, manejando la información de control generada por el terminal. En comunicaciones de voz, la información de control del nivel de usuario más destacada son los tonos multifrecuencia (DTMF) que producen un teclado telefónico convencional. Las técnicas de compresión de voz de baja velocidad introducen considerable distorsión en los tonos DTMF, provocando la recepción y correspondiente decodificación incorrecta en los receptores. Por lo tanto, se requiere que las señales de audio y los tonos DTMF sean separados en la pasarela, si no lo ha sido ya en el emisor y conducidos de forma independiente al receptor. Existen dos posibles soluciones para el transporte de los tonos DTMF: Transporte "dentro de banda": consiste en transportar estos tonos, digitalizados y paquetizados, con los protocolos RTP/UDP, mediante un formato de carga útil dedicado. Transporte "fuera de banda": conlleva a utilizar un canal de control de medios seguro (no UDP, sino TCP) para el transporte de las señales DTMF. El protocolo UDP no ofrece garantía en la entrega de paquetes y esto afecta el transporte de los tonos DTMF "dentro de banda", con nefastas consecuencias para el funcionamiento del servicio en caso de pérdida de un paquete asociado a un tono DTMF, sin embargo, tiene la ventaja de que los tonos permanecen sincronizados en el tiempo con respecto a la voz. El transporte "fuera de banda" gana en seguridad respecto a la entrega segura de los paquetes, no obstante, las señales pierden su referencia exacta en el tiempo en relación con el stream de voz. Esta es precisamente la solución adoptada en la Recomendación H.323, mediante el canal H

42 Estándar H.323 El estándar H.323 es una recomendación del ITU-T (International Telecommunication Union), que define los protocolos para proveer sesiones de comunicación audiovisual sobre paquetes de red. A partir del año 2000 se encuentra implementada por varias aplicaciones de Internet que funcionan en tiempo real como Microsoft Netmeeting y GnomeMeeting, este último utiliza la implementación OpenH323. H.323 es una parte de la serie de protocolos H.32x, los cuales también dirigen las comunicaciones sobre RDSI, RTC o SS7. [13] Debido a la existencia del estándar H.323 del ITU-T, el cual cubre la mayor parte de las necesidades para la integración de la voz, se decidió que el H.323 fuera la base del VoIP. Por lo tanto, el VoIP se considera como una clarificación del H.323, de tal forma que en caso de conflicto, y a fin de evitar divergencias entre los estándares, se decidió que H.323 tendría prioridad sobre el VoIP. El VoIP tiene como objetivo fundamental garantizar la interoperabilidad entre equipos de diferentes fabricantes, fijando aspectos tales como la supresión de silencios, codificación de la voz y direccionamiento, y estableciendo nuevos elementos para permitir la conectividad con la infraestructura telefónica tradicional. Estos elementos se refieren básicamente a los servicios de directorio y a la transmisión de señalización por tonos multifrecuencia. El VoIP/H.323 comprende a varios estándares y se apoya en protocolos que cubren distintos aspectos de la comunicación. En la Figura 17 se ilustra la aplicación de los protocolos en las diferentes etapas de una llamada. Figura 17. Aplicación de los protocolos en las diferentes etapas de una llamada 43

43 llamada: Los protocolos se explicarán a continuación de acuerdo a las etapas de la Direccionamiento: 1. RAS (Registration, Admision and Status). Protocolo de comunicaciones que permite a una estación H.323 localizar otra estación H.323 por medio del Gatekeeper. 2. DNS (Domain Name Service). Servicio de resolución de nombres en direcciones IP a través de un servidor DNS y con el mismo objetivo que el protocolo RAS Señalización: 1. Q Señalización inicial de llamada. 2. H Control de llamada: señalización, registro y admisión, y paquetización/ sincronización del stream (flujo) de voz. 3. H Protocolo de control para especificar mensajes de apertura y cierre de canales para streams de voz. Compresión de Voz: 1. Requeridos: G.711 y G Opcionales: G.728, G.729 y G.722 Transmisión de Voz: 1. UDP. La transmisión se realiza sobre paquetes UDP, a pesar que UDP no ofrece integridad en los datos, hay mayor aprovechamiento del ancho de banda que con TCP. 2. RTP. Se encarga de la temporización, marcando los paquetes UDP con la información necesaria para la correcta entrega de los mismos en recepción. Control de la Transmisión: RTCP. Se utiliza principalmente para detectar situaciones de congestión de la red y en cuyo caso tomar acciones correctoras. 44

44 Existen tres tipos de redes IP: Internet. El estado actual de la red no permite un uso profesional para el tráfico de voz. Red IP pública. Los operadores ofrecen a las empresas la conectividad necesaria para interconectar sus redes de área local en lo que al tráfico IP se refiere. Se puede considerar como algo similar a Internet, pero con una mayor calidad de servicio y con importantes mejoras en seguridad. Hay operadores que incluso ofrecen garantías de bajo retardo y/o ancho de banda, lo que las hace muy interesante para el tráfico de voz. Intranet. La red IP implementada por la propia empresa. Suele constar de varias redes LAN (Ethernet conmutada, ATM, etc.) que se interconectan mediante redes WAN tipo Frame-Relay/ATM, líneas punto a punto, RDSI para el acceso remoto, etc. La empresa tiene bajo su control prácticamente todos los parámetros de la red, por lo que resulta ideal para su uso en el transporte de la voz Calidad de Servicio No hace demasiado tiempo, la calidad de los servicios de telefonía IP era realmente deficiente, con sonidos que llegaban a los interlocutores distorsionados y retardados. Actualmente los niveles de calidad son realmente próximos a los de los servicios de telefonía convencional, si bien no llegan a reemplazar por completo los sistemas tradicionales, si llegan perfectamente a cubrir entre un 80 a un 95 por ciento de la utilización de los mismos. El avance en tecnología de servicios VoIP ha evolucionado de forma exponencial durante los últimos dos años, incorporando fabricantes como Cisco, Lucent, Intel, Quicknet, IBM y muchos otros sistemas dedicados al soporte VoIP. A continuación se presentan los factores que intervienen en la calidad de servicio durante el tráfico de voz sobre IP. 45

45 Factores que afectan la calidad de servicio Los factores que afectan la Calidad de Voz: CODEC Pérdida de paquetes Retardo Jitter Eco CODEC La voz se digitaliza antes de ser transmitida sobre una red. Los códigos estándares comunes son listados en la siguiente Tabla 1: Codificación Algoritmo Tasa de la Estándar data (kbps) G.711 PCM (Pulse Code Modulation) 64 G.726 ADPCM (Adaptive Differential Pulse Code Modulation) 16, 24, 32, 40 G.728 LD-CELP (Low Delay Code Excited Linear Prediction) 16 G.729 CS-ACELP (Conjugate Structure Algebraic CELP) 8 G MP-MLQ (Multi-Pulse Maximum Likelihood Quantization) 6.3, 5.3 ACELP (Algebraic Code Excited Linear Prediction) 6.3, 5.3 Tabla 1. Códigos estándares de la voz digitalizada Existe una relación directa entre la calidad de voz y la velocidad de datos; a mayor velocidad de datos, mayor calidad de voz Pérdida de Paquetes: La tasa de pérdida de paquetes, representa el porcentaje de paquetes transmitidos que se descartan en la red. Estos descartes pueden ser producto de una alta tasa de error en alguno de los medios de enlace o por sobrepasarse la capacidad de un buffer de una interfaz en momentos de congestión. Los paquetes perdidos son retransmitidos en aplicaciones que no son de Tiempo Real. Sin embargo, una característica del tráfico de tiempo real como la voz es la ineficiencia de la retransmisión de tramas perdidas en la capa de transporte debido a los grandes retardos que esto genera. Por lo tanto, para evitar la distorsión vocal, los terminales de 46

46 voz tienen que retransmitir con muestras de voz perdidas, conocida como Frame Erasures y la calidad de servicio depende en como los terminales manejan esto. En caso de una sola pérdida, el terminal deja un intervalo en el flujo de voz. Para el caso en que muchas muestras se pierden, una estrategia de recuperación consiste en la reproducción de muestras de voz previas. Y para contrarrestar las ráfagas de errores se utiliza la interpolación, esta técnica se conoce como Packet Loss Concealment (PLC), la cual basándose en las muestras de voz previas, el decodificador predecirá cuales tramas perdidas deberían ser. Un algoritmo PLC para PCM está descrito en la ITU-T G.711 apéndice I.: Un buffer histórico circular consistiendo de 48.75ms de muestras de voz previa es guardado. Una vez que la Frame Erasure es detectada, el contenido del buffer histórico será usado para estimar el periodo de caída corriente. Esta información será entonces usada para generar una señal sintetizada para llenar el intervalo. Con el PLC en G.711, la salida de audio es retardada por un adicional de 3.75ms para proveer una transición suave entre las señales real y sintetizada. En general, si las pérdidas no son demasiadas grandes, y la señal no es muy cambiante las perdidas pueden ser inaudibles después de aplicar el PLC. Algunas líneas de guía de planificación provisional en el efecto de pérdida de tramas sobre la calidad de voz están descritas en la ITU-T G.113 apéndice I. El factor de deterioro Ie mide el valor del impacto. Si Ie tiene un valor de 0 significa que no existe deterioro, a mayor Ie, deterioro más severo. La siguiente Tabla 2, es derivada de la G.113 apéndice I y muestra el impacto de las tramas perdidas en el factor Ie. Codec Ie (0% loss) Ie (2% pérdida de Ie (5% pérdida de tramas aleatorias) tramas aleatorias) G.711 sin PLC G.711 con PLC G.729A * G * * Los valores fueron tomados para un 4% de pérdida de tramas aleatorias Tabla 2. Impacto de las tramas perdidas en el factor Ie En el estándar G.711, cuando la tasa de pérdida de tramas es 2%, el factor Ie es 35. Sin embargo, con PLC el factor Ie se reduce a 7. Con una velocidad baja los codec s tales como el G.729ª y G.723.1, tienen un factor Ie de 11 y 15 respectivamente 47

47 aun cuando no existe pérdida de tramas. Un 2% de pérdida de tramas incrementará el factor Ie de 19 a 24 respectivamente. Un enlace de esta naturaleza es relativamente tolerante a la pérdida de paquetes, mas no así al retraso de la voz. A diferencia de las redes que utilizan el protocolo de Internet de una manera convencional para manejar datos, ya se ha dicho que no es posible solicitar una retransmisión de paquetes porque el usuario lo consideraría inaceptable. En breves palabras, la pérdida de paquetes en la red se debe fundamentalmente al sobreflujo de información que pudiera originarse en alguno de los nodos. Para la transmisión de voz se considera aceptable una pérdida de paquetes menor al 5%, aunque lo ideal es mantenerse por debajo del 0.1% y en el dado caso de no contar inmediatamente con uno de estos paquetes, la conversación continúa sin él Retardo El retardo es también otro factor fundamental que deriva de la calidad de la transmisión y de presentarse, el usuario percibiría que en su conversación, lo que dice se solapa con lo que se escucha. La telefonía por conmutación de circuitos mantiene normalmente un retraso entre 30 y 50ms que no es distinguible por el usuario. Si comparamos esta cifra con el retraso de 800ms a 2s que se tiene para llamadas en Internet, encontramos enormes diferencias. En caso de que el retraso sea mayor a 300ms, las conversaciones pueden llegar a ser muy molestas, razón por la cual, la recomendación G.114 de la UIT-T establece que el retraso en viaje redondo para telefonía, no puede ser mayor a 300ms. Este problema, sin embargo, es por lo general menor a 100ms para VoIP, lo cual satisface por completo las necesidades de los usuarios. G.114 provee los siguientes rangos con relación al límite de retardo de una vía, esto se muestra en la Tabla 3. 48

48 Retardo de una vía Rango (ms) Descripción Aceptable para una gran cantidad de aplicaciones de usuarios Aceptable, siempre y cuando el administrador de la red esté atento del impacto del tiempo de transmisión en la calidad de transmisión Sobre 400 Inaceptable para propósitos de planeación de red en general Tabla 3. Rangos del retardo en un solo sentido El retardo total en la conversación es la suma de los retardos acumulados. El primer retardo es en la matriz de switch (el retardo producido por el proceso store-andforward) y el retardo de procesamiento (cambio de encabezado de paquetes, por ejemplo). A esto se suman los retardos propios del proceso de compresión vocal (insignificante en codificación G.711 y más elevado en aplicaciones con G.729). Los retardos en la red pueden ser reducidos mediante el protocolo de reservación RSVP. El retardo debido a la compresión vocal se puede eliminar usando la velocidad de 64 kbps sin compresión (G.711). VoIP se desarrolló para reducir costos con menor velocidad y usando la infraestructura de Internet. Actualmente, con el modelo de una red IP de alta velocidad, la compresión vocal no es obligatoria en una red local. En este caso, Telefonía-IP se desarrolla para brindar una red de servicios integrados soportada en protocolo IP, sin límites en el ancho de banda. El efecto de retardo en la transmisión de voz se discute en la ITU G.114. Los efectos causados por el retardo incluyen el Eco y el Talker Overlap. En el RFC-3550 se define que el retardo es expresado en unidades de 1/65536 segundos, y se da entre la recepción del último paquete SR de la fuente de origen SSRC_n y el envío del bloque de recepción. Si no se ha recibido todavía un paquete SR de la fuente de origen SSRC_n, se coloca un cero en el campo DLSR. Se denota SSRC_r al receptor de dicho reporte de recepción. La fuente de origen SSRC_n puede computar el retraso de propagación ida y vuelta a SSRC_r al grabar el tiempo A cuando este bloque de recepción es recibido. Calcula el total del tiempo ida y vuelta A-LSR usando el último campo (LSR) del timestamp SR y luego 49

49 restándole este campo para dejar el retraso de propagación como(a-lsr-dlsr). Los tiempos se muestran en una representación hexadecimal de campos de 32bits y la representación equivalente en decimal de coma flotante (floating- point decimal representation). Los dos puntos indican un campo de 32 bits dividido en parte una entera de 16 bits y una parte de fracción de 16 bits Esto se puede utilizar como una medida aproximada de la distancia al cluster receptor, aun cuando muchos links tienen retrasos asimétricos. A continuación en la Figura 18 se presenta una ilustración de una red VoIP y sus respectivas fuentes de retardo: Figura 18. Fuentes de Retardo Retardo Algorítmico Es el retardo que introduce el CODEC y es inherente en el algoritmo de codificación. La Tabla 4 resume los retardos algorítmicos de códigos comunes. Codificación Estándar Retraso Algorítmico (ms) G * G G G ** G *** * El retraso algorítmico puede aumentar a 3.75ms si se implementa el PLC. ** Incluye "lookahead buffer". *** Incluye "lookahead buffer" Tabla 4. Retardos Algorítmicos 50

50 Los algoritmos de compresión usados en los Codec s analizan un bloque de muestras PCM entregadas por el codificador de voz. Estos bloques tienen una longitud variable que depende del codificador, el tamaño básico de un bloque del algoritmo g.729 es 10ms, mientras que el tamaño básico de un bloque del algoritmo g es 30ms Retardo de Paquetización Es el tiempo que se tarda en llenar un paquete de información (carga útil), de la conversación previamente codificada y comprimida. Este retardo es función del número de bloques de una sola trama y del tamaño de bloque requerido por el codificador de voz. En RTP, las muestras de voz generalmente se acumulan antes de ponerlo en una trama para transmisión de esta forma se reducen la cantidad de cabeceras (overhead). La RFC 3550 especifica que el retardo de paquetización por defecto debiera ser de 20ms. En el caso específico de G.711, esto representa que 160 muestras serán acumuladas y transmitidas posteriormente en una sola trama. Para el caso de G se genera una trama de voz cada 30 ms y cada trama de voz es transmitida usualmente como un simple paquete RTP. Los retardos de paquetización mas comunes se muestran el la Tabla 5 Codificador Rata Carga útil Retardo de Carga útil Retardo de (Kbps) (bytes) Paquetización (ms) (bytes) paquetización (ms) PCM, G ADPCM, G CS-ACELP, G MP-MLQ, G MP-ACELP, G Tabla 5. Retardos de Paquetización Retardo de Serialización Es el tiempo requerido para transmitir un paquete IP, se relaciona directamente con la tasa del reloj de la transmisión. En el caso de usar G.711 y un período de paquetización es 20 ms, es decir hay 160 bytes de carga útil en RTP, entonces el tamaño de la trama completa será de 206 bytes asumiendo encapsulación PPP. Para transmitir la trama, requerirá 1.1ms en una línea T1, 3.2 ms a 512 Kbps, 25.8 ms a 64 Kbps. El retardo de Serialización se presenta 51

51 cuando los paquetes pasan a través de otro dispositivo de almacenamiento y retransmisión tales como un Router o un Switch. Los retardos de Serialización en milisegundos para diferentes tamaños de tramas, se muestran en la Tabla 6. Tabla 6. Retardos de Serialización Retardo de Propagación Es una función de la distancia geográfica, es el tiempo requerido por la señal óptica o eléctrica para viajar a través de un medio de transmisión. La velocidad de propagación en el cable es aproximadamente de 4 a 6 ms/km. Para transmisión satelital, el retardo es 110 ms para un satélite con altitud de km y 260 ms para un satélite con altitud de km Retardo de Componente Son retardos generados por varios componentes dentro del sistema de transmisión. Hay un retardo mínimo a la velocidad del backplane y algunos retardos variables debido al encolamiento y procesamiento en el router. Un backplane es un componente de las computadoras con arquitectura NUMA (Nonuniform memory access) que facilita la interconexión de los módulos o celdas que componen la computadora. Las fuentes del retardo se clasifican en dos tipos: retardo fijo que se adiciona directamente al total del retardo de la conexión, tales como el retardo de Codec, 52

52 retardo de Paquetización, retardo de Serialización, retardo de Switch y jitter del Buffer y retardo variable que se adiciona por demoras en las colas de los buffer. A continuación, en la Figura 19 se identifican todos los posibles retardos fijos y variables que existen en una red, los cuales fueron nombrados anteriormente. Figura 19. Fuentes de retardo Jitter (variación del retardo): Es el efecto por el cual el retraso entre paquetes no es constante. Se trata de una latencia variable producida por la congestión de tráfico en el backbone de red, por la cantidad de retardo de encolamiento y tiempo de procesamiento que varía de acuerdo al tráfico cargado en la red. Se puede utilizar un buffer para distribuir los paquetes y reducir el jitter, pero introduce un retardo adicional. Lo correcto es incrementar el ancho de banda del enlace. Esta solución es posible en un backbone pero de menor posibilidad en los enlaces WAN. Otra posibilidad es la formación de colas para prioridad de tráfico de telefonía sobre los de datos. El jitter es entonces un grave problema para las aplicaciones en tiempo real y como se dijo en las redes IP se presenta entre otras razones debido a las diferentes rutas que puede seguir un paquete por la red. La telefonía convencional no presenta este problema porque la línea se mantiene abierta entre las terminales y además, no es necesario compartir recursos con otras formas de tráfico. En las aplicaciones de VoIP el gateway fuente genera tramas de voz a intervalos regulares, es decir, cada 20 ms, sin embargo, el gateway destino 53

53 típicamente no recibirá tramas de voz en intervalos regulares debido al problema del jitter. En general, la estrategia en comunicación para solventar el problema de jitter es almacenar las tramas recibidas en un buffer tan grande que permita a las tramas más lentas llegar a tiempo para ser ubicadas en la secuencia correcta. El jitter más grande debido a algunas tramas de mayor tamaño, serán almacenadas en el buffer lo cual introduce retardo adicional. Muchas aplicaciones usan un buffer jitter adaptativo para minimizar el retardo debido al buffering, es decir, si la cantidad de jitter en la red es pequeño, el tamaño del buffer será pequeño, mientras que si el éste se incrementa debido al aumento del tráfico en la red, el tamaño del buffer de destino se incrementará automáticamente para compensarlo. Por consiguiente, el jitter en la red empeorará la calidad de voz en la magnitud que crece el retardo de extremo a extremo debido al buffer de destino. Para efectos del análisis de calidad de servicio se utiliza como parámetro el promedio del jitter por llamada, este promedio resulta de la suma de los respectivos interarrival jitters. En el RFC-3550 se define el Interarrival Jitter como una estimación de la variación estadística de los datos de tiempo RTP entre llegada de paquetes, medida en unidades del timestamp y expresada como entero sin signo. El interarrival jitter J se define como la desviación media en valor absoluto de la diferencia de espaciamiento D entre un par de paquetes en el receptor comparado con dicha diferencia en el remitente. Según las indicaciones de la ecuación 1, esto es equivalente a la diferencia en el tiempo relativo del tránsito para los dos paquetes; el tiempo relativo del tránsito es la diferencia entre el timestamp RTP de un paquete y el reloj del receptor a la hora de la llegada, medido en las mismas unidades. Si Ri es el tiempo de llegada en las unidades del timestamp de RTP para el paquete i y Si es el timestamp RTP del paquete i, entonces para dos paquetes i y j, D se puede expresar como: D ( i j) ( R R ) ( S S ) = ( R S ) ( R S ), j i j i j i i i = (1) 54

54 El Interarrival Jitter se debe calcular constantemente cada vez que el paquete i de datos se recibe de la fuente SSRC_n, usando esta diferencia D para ese paquete y el paquete anterior i-1 en orden de la llegada (no necesariamente en secuencia), según la fórmula: ( i 1) ( D( i 1, i) J ( i 1) ) J ( i) = J + (2) 16 Siempre que se publique un informe de la recepción, el valor actual de J es muestreado. El cálculo del Interarrival Jitter debe coincidir con la fórmula especificada anteriormente para permitir que los monitores de perfil independiente validen las interpretaciones de los informes que vienen de diferentes implementaciones. Este algoritmo es el estimador óptimo de primer orden y el parámetro 1/16 da una buena reducción del nivel de ruido mientras se mantiene un índice razonable de la convergencia [14] Eco Las características latencia (retraso) y jitter pueden producir eco sobre la señal telefónica, lo cual hace necesario el uso de canceladores de eco (ITU G.168). Existen varios tipos de eco, el Eco acústico puede presentarse en una red de voz como consecuencia del pobre acoplamiento entre el dispositivo de escucha (earpiece) y el dispositivo de habla (mouthpiece) en el microteléfono. El Eco híbrido se presenta cuando parte de la energía eléctrica es reflejada al abonado llamante por el circuito híbrido en la PSTN. Cuando el retardo de extremo a extremo de una vía es corto, el eco que se genere por el circuito de voz regresará al abonado llamante muy rápidamente y éste no será percibido. La cancelación de eco no es necesaria si el retardo de una vía es menor a 25ms. Si el eco regresa dentro de los 50 ms, no será percibido. Sin embargo, el retardo de una vía en una red VoIP casi siempre excederá los 25 ms. Entonces, siempre se requiere la cancelación de eco. El cancelador de eco se construye mediante la técnica de ecualización transversal adaptativa. Consiste en usar una parte de la señal de transmisión para 55

55 cancelar el eco producido por la desadaptación de impedancias en el circuito híbrido que convierte de 4 a 2 hilos Análisis de los informes del remitente y receptor para el cálculo de los parámetros de calidad de servicio. La realimentación sobre la calidad de la recepción debe ser útil no sólo para el remitente sino también para otros receptores y monitores ajenos a dicha comunicación que deseen saber el estado de la red. Entre las ventajas que brinda tener esta retroalimentación están, por ejemplo: el remitente puede modificar sus transmisiones; los receptores pueden determinar si los problemas son locales, regionales o globales; los encargados de red pueden evaluar el funcionamiento de sus redes para la distribución multicast utilizando los monitores como receptores de paquetes RTCP únicamente y no de paquetes de datos RTP [15]. Se pueden estimar diferencias entre cualquier par de informes mediante las cuentas acumulativas en los bloques de reporte de información tanto del remitente como del receptor, esto permite realizar medidas sobre períodos de corto y largo plazo, y proporcionar de esta manera resistencia contra la pérdida de un reporte. La diferencia entre los dos últimos informes recibidos se puede utilizar para estimar la calidad reciente de la distribución. El timestamp del NTP es incluido para calcular tasas de estas diferencias sobre el intervalo entre dos informes. Debido a que el timestamp es independiente de la tasa del reloj para la codificación de los datos, es posible colocar monitores de calidad de codificación. Un cálculo importante es la tasa de pérdida de paquetes sobre el intervalo entre un par de reportes de recepción. La diferencia en el número acumulativo de los paquetes perdidos, proporciona el número perdido durante dicho intervalo. La diferencia en la extensión de la última secuencia de números recibidos, suministra el número de los paquetes esperados 56

56 durante el intervalo. El cociente de estos dos es la fracción de pérdida de paquetes sobre el intervalo. Este cociente debe igualar el campo de fracción perdida si los dos informes son consecutivos. La tasa de pérdida por segundo puede ser obtenida dividiendo la fracción de la pérdida entre la diferencia en los timestamps del NTP, expresados en segundos. El número de los paquetes recibidos es el número de los paquetes esperados menos el número perdido. El número de los paquetes esperados se puede también utilizar para evaluar la validez estadística de cualquier estimación de la pérdida. Por ejemplo, 1 fuera de 5 paquetes perdidos tiene una significación más baja que 200 fuera de De la información del remitente, un monitor externo a la comunicación, puede calcular la tasa de datos promedio de carga útil y la tasa promedio del paquete sobre un intervalo sin tener que recibir los datos. Al tomar el cociente de los dos, se obtiene el tamaño promedio de la carga útil. Al asumir que la pérdida de paquetes es independiente del tamaño del paquete, entonces el número de paquetes recibidos por un receptor en particular mide el tamaño promedio de la carga útil y da el rendimiento de procesamiento disponible por dicho receptor. Las cuentas acumulativas permiten medidas a largo plazo de la pérdida de paquetes, usando las diferencias entre los reportes. El campo de fracción perdida proporciona una medida a corto plazo de un solo reporte. Esto llega a ser más importante mientras más aumenta el tamaño de una sesión, lo suficiente hasta que la información del estado de recepción no se puede guardar para todos los receptores, o el intervalo entre los reportes se convierte en tanto tiempo, que solamente un informe se pudo haber recibido de un receptor en particular. El campo de interarrival jitter proporciona una segunda medida a corto plazo sobre la congestión de la red. Se puede decir que la pérdida de paquetes mide la congestión persistente mientras que el jitter se refiere a la congestión transitoria. 57

57 La medida de jitter puede indicar la congestión antes de que se produzca la pérdida del paquete. El campo de interarrival jitter es solamente una foto del jitter a la hora de un informe y no pretende ser tomado cuantitativamente. Por el contrario, su intención es la comparación de un número de reportes referentes a un receptor en particular en un cierto plazo o referente a receptores múltiples, por ejemplo, dentro de una sola red, al mismo tiempo. Para que la comparación sea válida entre receptores, es importante que el interarrival jitter sea calculado con la misma fórmula en todos los receptores. Para efectos de comparación y monitoreo se recomienda utilizar el promedio del jitter por llamada. Debido a que el cálculo del interarrival jitter se basa en el timestamp de RTP que representa el instante en que la primera data del paquete fue muestreada, cualquier variación en el retraso durante el instante de muestreo y el tiempo en que se transmite el paquete afectará el cálculo final del jitter. Tal variación en retraso ocurre en los paquetes de audio de duración variable. También ocurre para las codificaciones video porque el timestamp es igual para todos los paquetes de una trama pero estos paquetes no son todos transmitidos al mismo tiempo. La variación del retraso hasta la transmisión reduce la exactitud del cálculo del jitter como medida del comportamiento de la red por sí misma, pero es apropiado incluirlo al considerar que el búfer del receptor debe acomodarlo. Cuando el cálculo del jitter se utiliza como medida comparativa, la componente (constante), debido a la variación del retraso hasta la transmisión, se elimina, para observar un cambio en la componente del jitter de la red a menos que éste sea relativamente pequeño Técnicas subjetivas de medición de calidad de servicio Los parámetros objetivos de QoS son medidos por medios técnicos (midiendo cualidades físicas de circuitos, redes y señales), mientras que los subjetivos (QoS percibido) se obtienen vía exámenes y pruebas subjetivas entre usuarios. A continuación se explican en detalle dos técnicas subjetivas de medición de calidad de servicio. 58

58 MOS (Mean Opinion Score) El ancho de banda determina la calidad de voz en una red IP. La calidad se basa en un Resultado Promedio de Opinión (MOS, por sus siglas en inglés) de 4.0 o superior, el cual es una medida subjetiva de la calidad del sonido basado en la escala de la UIT-T, recomendación P.800, tal y como se expone en la Tabla 7: Puntuación Calificación 5 Excelente 4 Buena 3 Regular 2 Pobre 1 Mala Tabla 7. Escala de MOS El valor de MOS real se determina en base a un experimento estadístico: un gran número de personas escuchan la misma llamada y valoran su calidad. Los analizadores pueden valorar marcaciones MOS de acuerdo a distintos criterios personales. Pueden darse datos MOS total o por llamadas y, normalmente, es la medida más utilizada. Las técnicas de codificación evitan que el sonido sea natural y no sintético y buscan reducir el ancho de banda. Cabe recordar que conforme el ancho de banda disminuye, la calidad de sonido se degrada en mayor grado. Es por ello que la elección de la codificación que vaya a implementarse en la red deberá tomar en cuenta estas consideraciones. La calidad de voz depende en gran parte de la codificación que se emplee y por ello existe esta escala conocida como MOS que representa hoy en día el estándar más común en la medida de la calidad. Los valores MOS, a pesar de ser subjetivos, son considerados efectivos pues representan un balance de todos los factores de calidad en telefonía que se han venido discutiendo. En la Tabla 8 se hace referencia a la relación entre la técnica de codificación, tasa de transferencia y valor del MOS. 59

59 Técnica de Codificación Tasa de transferencia (kbps) MOS G G G G G GSM Full Rate (RPE_LTP) Tabla 8. Relación entre técnica de codificación, tasa de transferencia y valor del MOS Modelo E El modelo E fue desarrollado dentro de ETSI como herramienta de planeamiento de transmisión, se describió originalmente en el informe técnico ETR 250 de ETSI, y se estandardizó por el ITU como G.107. El objetivo del modelo era determinar un grado de calidad R que incorpore la trayectoria completa del discurso de boca a oído. El rango del factor R está comprendido entre 0-100, sin embargo, valores por debajo de 50 son generalmente inaceptables. Por otro lado las conexiones de teléfono típicas no consiguen superar los 94, por lo tanto, el rango típico está comprendido entre Para CODECs de banda ancha el factor R puede aumentar sobre 100, típicamente 110 para una conexión intacta. El modelo básico está representado en la ecuación 3: R = R I I I + A W (3) o s d e + Donde Ro es un factor base determinado a partir de los niveles de ruido, la intensidad Is representa debilitaciones que ocurren simultáneamente con el discurso, Id representa las debilitaciones que se retrasan respecto al discurso, Ie representa el factor de debilitación supuesto del equipo, A el factor de ventaja y W es un factor de corrección de banda ancha. El factor de debilitación supuesto del equipo, Ie, se utiliza típicamente para representar los efectos de la voz sobre el IP. Por ejemplo, asumiendo valores estándar para todas las variables entonces el factor R para una conexión G. 729A ideal sin pérdida, jitter o retardo estaría dado por la ecuación 4. 60

60 R = R IE = (4) 0 = El factor de ventaja, A, se utiliza para representar la conveniencia del usuario de poder hacer la llamada telefónica, por ejemplo, un celular es muy conveniente de utilizar, por lo tanto la gente perdona la calidad por su conveniencia. En la Tabla 9 se presentan los valores aceptables del MOS y de R para CODECs de banda estrecha. Opinión del usuario Factor de R Cuenta del MOS Máximo obtenible para el G Muy satisfecho Satisfecho Algunos usuarios satisfechos Muchos usuarios descontentos Casi todos los usuarios descontentos No recomendado Tabla 9. Valores aceptables del MOS y de R para CODECs de banda estrecha Para CODEC s banda ancha la gama de la cuenta del MOS sigue siendo 1-5 aun cuando la gama del factor de R es más alta. Esto significa que un CODEC de banda estrecha puede tener una cuenta del MOS de 4.3 y un CODEC banda ancha puede tener una cuenta del MOS de 3.9, aun cuando el CODEC del banda ancha suena mucho mejor Mejoramiento de la Calidad de Servicio: En la actualidad existen metodologías que permiten actuar en pro de una mejora en la calidad del servicio, a continuación en la Figura 20 se presenta un esquema que ilustra los pasos a seguir con este fin: 61

61 Análisis - Evaluación - Monitoreo - Diagnóstico - Comprobación Simular y realizar pruebas a aplicaciones de usuarios para identificar problemas Diagnóstico en búsqueda del origen de la causa, con el fin de aislar el problema antes de que el usuario sufra un impacto Análisis de la red y estatus para el transporte de voz y datos Monitoreo en tiempo real y análisis de las llamadas de acuerdo a parámetros de calidad Aseguramiento que los niveles de servicio se están cumpliendo, reporte de fallas y soluciones Figura 20. Pasos para mejorar la calidad de servicio Producto del arduo proceso de análisis, evaluación, monitoreo, diagnóstico y comprobación realizados con los años, actualmente la calidad de servicio se está logrando en base a los siguientes criterios de prevención: La supresión de silencios, otorga más eficiencia a la hora de realizar una transmisión de voz, ya que se aprovecha mejor el ancho de banda al transmitir menos información. Compresión de cabeceras aplicando los estándares RTP/RTCP. Priorización de los paquetes que requieran menor latencia. Las tendencias actuales son: CQ (Custom Queuing): Asigna un porcentaje del ancho de banda disponible. PQ (Priority Queuing): Establece prioridad en las colas. WFQ (Weight Fair Queuing): Se asigna la prioridad al tráfico de menos carga. DiffServ (Servicios Diferenciados): Evita tablas de encaminados intermedios y establece decisiones de rutas por paquete. 62

62 La implantación de IPv6 (versión 6 del Protocolo de Internet) que proporciona mayor espacio de direccionamiento y la posibilidad de tunneling Plataforma NGN de CANTV En la Figura 21, se presenta un diagrama de la plataforma NGN que CANTV posee actualmente. En dicho esquema se ilustran algunos de sus componentes, tales como los Nodos de acceso de abonados, en los cuales se interconectan las líneas y los equipos telefónicos, los equipos Media Gateways, que tienen como principal función la conversión de Voz sobre IP a TDM (Red PSTN o red fija de CANTV) y se comunican con los switches y routers, que son los dispositivos que transportan los datos entre las redes IP. Estos elementos se encuentran definidos en diferentes Segmentos de IP, para manejar controles lógicos de enrutamientos de paquetes. Existe el equipo Softswitch que permite el manejo de la base de datos de abonados, señalización, enrutamientos de las llamadas, el cual se comunica con cada uno de los elementos definidos anteriormente. Figura 21. Plataforma NGN de CANTV 63

63 2.5. Lenguaje de programación: JAVA En un primer nivel, Java es un lenguaje de programación de propósito general, orientado a objetos, que fue introducido por Sun Microsystems en 1995, y diseñado en principio para el ambiente distribuido de Internet. Lo que hace de Java un concepto diferente es que, en un segundo nivel, es también un entorno para la ejecución de programas, englobado en la llamada máquina virtual de Java. Este entorno es un software que permite que las aplicaciones escritas en Java se ejecuten en cualquier ordenador, independientemente del sistema operativo y de la configuración de hardware utilizados Cualidades principales de Java A continuación se detallan las cinco principales cualidades de éste lenguaje: Universalidad Sencillez Orientación a objetos Seguridad Adaptación a redes Universalidad La universalidad de los byte codes hacen de Java el lenguaje idóneo para desarrollar aplicaciones para Internet. De hecho, la mayor parte de los navegadores (Netscape Navigator, Internet Explorer, HotJava) integran VM (Máquinas Virtuales), y por tanto intérpretes de Java, lo que hace posible acceder automáticamente a los applets presentes en las páginas web. De nuevo la sencillez de Java hace que esta integración no reduzca en absoluto las prestaciones de los navegadores, permitiendo además la ejecución rápida y simultánea de gran cantidad de applets. También se suele hacer referencia a la universalidad de Java con términos equivalentes como transportabilidad, o independencia de plataforma, pues para ejecutar un programa basta compilarlo una sola vez: a partir de entonces, se puede hacer correr en cualquier máquina que tenga implementado un intérprete de Java. Además, las bibliotecas estándar de funciones y métodos de Java, definidas en su API (Application Programming Interface), facilitan la programación de multitud de 64

64 acciones complejas, tales como: desarrollo de interfaces gráficas, multimedia, multitarea, interacción con bases de datos. Ningún otro lenguaje, ni compilado ni interpretado, dispone como Java de una cantidad tan grande de funciones accesibles en cualquier plataforma sin necesidad de cambiar el código fuente Sencillez Java es un lenguaje de gran facilidad de aprendizaje, pues en su concepción se eliminaron todos aquellos elementos que no se consideraron absolutamente necesarios. Por ejemplo, en comparación con otros lenguajes como C ó C++, es notable la ausencia de punteros, o lo que es lo mismo: es imposible hacer referencia de forma explícita a una posición de memoria; ello ahorra gran cantidad de tiempo a los programadores, dado que el comportamiento imprevisto de los punteros es una de las principales fuentes de errores en la ejecución de un programa. Por otra parte, el código escrito en Java es por lo general mucho más legible que el escrito en C ó C Orientación a objetos Aunque C++ es también, como Java, un lenguaje orientado a objetos, la diferencia fundamental es que Java lo es desde su concepción, mientras que C++ se diseñó como un lenguaje compatible con C (que no es orientado a objetos), de este modo, un programa escrito en C++ puede ignorar la mayoría de las características de orientación a objetos de C++ y compilarse sin problemas en un compilador de C++. Sin embargo, un programador no puede obviar la orientación a objetos cuando escribe un programa en Java, y esto hace que las aplicaciones escritas en Java tengan interesantes ventajas. Para entender qué es la orientación a objetos, recordemos que los lenguajes tradicionales no orientados a objetos, como Pascal o C, estaban pensados para trabajar de forma secuencial y basaban su funcionamiento en el concepto de procedimiento o función. La tarea principal del programa se dividía en funciones o tareas más pequeñas, a menudo muy interrelacionadas, por lo que era difícil modificar una función sin tener que revisar el resto del programa: por tanto, también era difícil reutilizar o actualizar los programas ya escritos. En el caso de los lenguajes orientados a objetos, el concepto clave no es el de función, sino el de objeto. Un objeto es un elemento de programación, autocontenido y reutilizable, y que podríamos definir como la representación en un programa de un 65

65 concepto, representación que está formada por un conjunto de variables (los datos) y un conjunto de métodos (instrucciones para manejar los datos). Los objetos, además, poseen la capacidad de enviarse mensajes entre sí durante la ejecución de un programa Seguridad Java fue diseñado para ofrecer las siguientes medidas de seguridad básicas: Uso de un lenguaje de programación seguro. Integración de un sistema de control de permisos para los programas. Encriptación y uso de certificados. Se definen mecanismos para que los programadores puedan firmar el código, de manera que los usuarios puedan verificar quien es el propietario del código y que este no ha sido modificado después de ser firmado Adaptación a redes Java irrumpió en el mercado para potenciar la interactividad en Internet, y sus applets, pequeños programas en Java que se cargan junto con una página web desde un servidor, son ejecutados por la VM del navegador del cliente como una parte de la página Web. Además de las ventajas que supone su ejecución local, los applets disponen de una significativa riqueza de recursos y son capaces de realizar tareas muy complejas a pesar de su reducido tamaño. Una de las explicaciones de esta sorprendente capacidad es el hecho de que los applets se sirven del propio código del navegador en cuya VM se ejecutan, utilizándolo para tareas tales como presentación gráfica o comunicaciones. Sin embargo, el acceso a las funciones del navegador es totalmente automático y transparente para el programador, que debe limitarse a invocar ciertas funciones de la API de Java; estas invocaciones, interpretadas por el navegador, dan origen a acciones muy complejas. Esta observación es muy importante cuando se discute del rendimiento de Java, pues todas estas acciones se realizan en la máquina que está ejecutando el applet, y la rapidez de ejecución de las mismas no depende de que Java sea un lenguaje semiinterpretado (o semicompilado). Entre las tareas básicas más comunes que suelen realizar los applets, se encuentran: visualizar animaciones en la ventana del navegador; reproducir sonidos; 66

66 establecer comunicaciones con el servidor del que procede el applet (p. ej. para cargar desde él ficheros de cualquier naturaleza); crear interfaces gráficas con los elementos habituales de los entornos de ventanas (como Macintosh o Windows): menús desplegables, botones, áreas de texto, barras de desplazamiento, etc.; pedir datos al usuario para procesarlos (gestionando eventos como pulsaciones de teclas o acciones con el ratón); etc. No obstante, es posible programar applets para realizar tareas de enorme complejidad [16]. 67

67 CAPITULO III DESARROLLO DEL PROYECTO El objetivo fundamental del Proyecto de Grado es elaborar una herramienta automatizada que permita realizar el monitoreo de los parámetros de calidad de servicio de forma confiable y automática, con poca o prácticamente ninguna supervisión del personal del COR, permitiendo a dicho personal dedicarse a otras actividades ya que se ahorra significativamente tiempo y esfuerzo. El resultado de la herramienta debe resumirse en un reporte amigable e intuitivo. El proceso de diseño se produjo de una manera muy dinámica, realizándose modificaciones y mejoras a medida que se realizaban pruebas preliminares. El producto final fue el resultado de la evolución de esos lineamientos iniciales. En el presente capítulo se presenta una visión global del proyecto así como el desarrollo específico de cada una de las fases Fases del Proyecto Se detalla a continuación los procedimientos seguidos en cada fase: Levantamiento de información Se realizó una revisión bibliográfica y un estudio de los estándares de Protocolos IP, UDP, RTP, RTCP, redes NGN y algoritmos de medición de calidad de servicio (QoS) Selección de software de automatización y captura Se definieron los parámetros de selección que se implementaron en la siguiente Matriz de Selección para cada caso, dicha matriz se presenta a continuación en la Tabla 10: No. Parámetro Peso Evaluación Parámetro Calificación Sist.1 Sist Sist. n Sist.1 Sist Sist. n EVALUACIÓN TOTAL Tabla 10. Formato de la Matriz de Selección 68

68 Se evaluaron comparativamente varios sistemas de captura y automatización. Para rellenar cada una de las celdas de la matriz de selección se propuso valorar individualmente cada parámetro hasta un máximo de 5 puntos. De esta forma, la calificación de cada parámetro se obtuvo según la fórmula expuesta en la ecuación 4. Calificaci ón = Peso Evaluacion _ Individual (4) La evaluación total de cada sistema es el resultado de la suma de todas las calificaciones de sus parámetros. Se seleccionaron los respectivos softwares a partir de los resultados obtenidos en la evaluación total de cada matriz Selección del Macro Recorder Para la selección del Macro Recorder, las características fundamentales que se tomaron en cuenta fueron las siguientes: Costo. Capacidad de cargar y ejecutar varios macros por un macro master. Declarar, incrementar, decrementar, multiplicar y dividir variables. Ejecutar programas, accesos directos, URL s y documentos. Permitir el comienzo de la ejecución del macro en un momento específico previamente determinado. Garantía y confiabilidad Ayuda en línea. Para simplificar la lectura de matriz de selección a cada software se le asignó un número de sistema tal y como se observa en la Tabla 11. Sist. N Softwares 1 Macro Scheduler 2 Auto Macro Recorder 4,8 3 AutoHotkey KeyText3 5 Mouse and Key Recorder 6 MacroMaker Tabla 11. Macro Recorders evaluados La matriz con lo resultados se presentan a continuación en la Tabla

69 N PARÁMETROS Peso SOFTWARE DE AUTOMATIZACIÓN Nivel de solución a las necesidades de CANTV Sist. 1 Evaluación Parámetro Calificación Sist. 2 1 Costo económico Estabilidad Diseño Fácil programación Velocidad Aplicaciones de notificaciones vía mail, aviso con 6 comandos condicionales e internet Funciona con cualquier aplicación Extrae data y genera reportes Posee contraseña de seguridad Nivel de seguridad ante fallas Nivel de desarrollo de las aplicaciones de software necesarias Posibilidad de trabajo en régimen de red local Habilidad para editar y optimizar macros previamente grabados El macro funciona si la posición de la ventana cambia o si se presentan cambios menores en el sistema Capacidad ilimitada de repetición del macro Capacidad de ejecutar los macros que son globales o 16 de archivos específicos Cargar y ejecutar varios macros por un macro master Permite escribir manualmente un script con los 18 comandos a ejecutar Permite crear un macro utilizando un macro recorder Sist. 3 Sist. 4 Sist. 5 Sist. 6 Sist. 1 Sist. 2 Sist. 3 Sist. 4 Sist. 5 Sist. 6 70

70 N PARÁMETROS SOFTWARE DE AUTOMATIZACIÓN Peso Sist 1 Evaluación Parámetro Sist 2 Sist 3 Sist 4 Sist 5 Sist 6 Sist 1 Sist 2 Calificación Sist 3 Sist 4 Sist 5 20 Permite ejecutar un macro presionando 1 sola tecla Generar comandos únicos para una corrida específica n Declara, incrementa, decrementa, multiplica y divide variables Nivel de protección de acceso a datos Facilidad de salva/restaura del sistema Envia clicks del teclado y mouse a cualquier ventana sin 25 estar previamente activada Permite ácilmen archivos Ventana de dialogo pata interacción con el usuario Permite comenzar la ejecución del macro en un 28 momento específico Guarda en archivos Facilidad para eliminar archivos Ejecuta programas, accesos directos, URLs y documentos Activa, esconde, cierra, minimiza o cambia de tamaño cualquier ventana Monitorea el sistema (cierra ventanas no deseadas en el momento que aparezcan) Permite tener una ventana transparente o siempre en el tope Convierte cualquier script en un ejecutable (exe) que puede ser corrido en cualquier computadora Cantidad de subsistemas que incluye Nivel de protección de acceso a opciones Sist 6 71

71 N PARÁMETROS Evalcuación Parámetro Calificación SOFTWARE DE AUTOMATIZACIÓN Peso Sist. 1 Sist. 2 Sist. 3 Sist. 4 Sist. 5 SIs.t 6 Sist. 1 Sist. 2 Sist. 3 Sist. 4 Sist. 5 Sist. 6 Cualquier tecla o botón del ácil puede actuar como activador de un macro (deshabilita o ácilmente las teclas predefinidas como accesos directos por Windows) Permite ácilme ácilmente por comandos al día y hora local Ejecuta acciones definidas en un script como respuesta a apagado del sistema o logoff Mantenimiento/asesoría del fabricante Garantía y confiabilidad Calidad de los manuales de usuario Ayuda en línea Plataforma que soporta el sistema Requerimientos de hardware Facilidad de la explotación y entrenamiento Tabla 12. Matriz de Selección del Macro Recorder Total

72 Como se puede observar en la Tabla 12 el sistema que obtuvo mayor puntuación fue el sistema 3 llamado KeyText3, con un total de 1810 puntos. KeyText3 cumple con los requisitos fundamentales que se buscaban en un Macro Recorder: Es económico, su costo es de 25$ por servidor Presenta características amigables por lo tanto su uso es intuitivo Permite realizar operaciones algebraicas con variables Es capaz de ejecutar todo tipo de programas Al contar con un reloj interno se pueden ejecutar macros de acuerdo a un itinerario previamente establecido Es confiable y La ayuda en línea es inmediata. A su vez, KeyText3 posee innumerables funciones adicionales que permiten optimizar el diseño y programación de la herramienta automatizada de medición y alerta. Entre las funciones programables más resaltantes se encuentran las posibilidades de: Activación de una ventana, presionar un botón o selección de un menú Agregar la hora y/o fecha Agregar una combinación de teclas Agregar pausas, tiempos de espera, loops (ciclos) o llamadas Solicitar datos al usuario o mostrar un mensaje Acción del Mouse Ejecutar un programa, cargar una página web o enviar un correo electrónico Programar un itinerario de ejecución del item En la Figura 22 a continuación se ilustran de forma general todas las funciones nombradas anteriormente: 73

73 Figura 22. Funciones de KeyText3 Todas las funciones se programan en un ítem. Cada ítem es una hoja en blanco lista para programar y representa una rutina en particular que podrá ser ejecutada al activar el hotkey o cuando el reloj marque la hora y minuto predeterminado para su ejecución. Dependiendo de la licencia que se tenga se puede acceder a un número determinado de ítems. Para el caso de la licencia ilimitada se cuenta con 234, desde el ítem llamado 1A hasta el 9Z. El formato de estos ítems se presenta a continuación en la Figura 23, en particular para el caso del 5A al 5Z. Figura 23. Item en blanco 74

74 Cuando se tienen rutinas que implican correr un programa o cargar una página web se debe configurar el ítem como un Macro, de esta forma estas acciones estarán en orden. Dicha configuración se hace seleccionando la opción Macro en el Menu Action, tal como se muestra a continuación en la Figura 24: Figura 24. Selección de la opción Macro en el Item Seguidamente se explican las funciones programables mencionadas con anterioridad: Activación de una ventana, presionar un botón o selección de un menú: Mediante la selección de algunas de las opciones presentadas a continuación en la Figura 25, se pueden programar cualquiera de las opciones mencionadas. Figura 25. Activación de una ventana, presionar un botón o selección de un menú 75

75 Agregar la hora y/o fecha: Se puede seleccionar el formato de hora y fecha que se prefiera, al igual que cualquier fecha del calendario. Esto se muestra en la Figura 26. Figura 26. Agregar la hora y/o fecha Agregar una combinación de teclas: Cada tecla debe ser agregada individualmente, se puede repetir cada tecla n veces. La pantalla simula un teclado, tal y como se observa en la Figura 27 Figura 27. Agregar una combinación de teclas 76

76 Agregar pausas, tiempos de espera, loops o llamadas: Con este menú se pueden realizar las acciones de control del macro. La opción más importante es Ignore Returns, la cual debe ser colocada al comienzo de los macros, permitiendo que el código sea escrito de forma más amigable e intuitiva, es decir, colocando n rutinas por líneas separadas por un enter. Si no se activa esta opción, el enter que separa las líneas del código será tomado literal y se presionará cada vez que aparezca en el código. Por lo tanto, al activar esta configuración, se debe escribir explícitamente return si se desear presionar la tecla enter. Otra opción muy útil es Begin a Loop, esto permite ejecutar una rutina n veces sin tener que repetirla en el código. Estas opciones se observan claramente en la Figura 28 Figura 28. Agregar pausas, tiempos de espera, loops o llamadas Solicitar datos al usuario o mostrar un mensaje: Esta función permite mostrar mensajes de alerta al usuario o por otra parte solicitar datos necesarios para seguir con la ejecución del respectivo macro. Esto se observa en la Figura 29 a continuación. 77

77 Figura 29. Solicitar datos al usuario o mostrar un mensaje Acción del Mouse: Esta opción permite simular movimientos y/o clicks del Mouse sobre la interfaz gráfica que esté activa en un momento determinado. La característica más importante radica en que existe la opción de usar coordenadas fijas o coordenadas relativas a la ventana activada; éstas últimas son muy útiles ya que no son dependientes de la posición de la ventana en un futuro ni del tamaño de la misma, es decir, es independiente de si la pantalla se abre maximizada o en un tamaño en particular, ni en que ubicación de la pantalla se encuentra realmente. La configuración de las acciones de Mouse se realizan tal y como presenta en la Figura 30 78

78 Figura 30. Acción del Mouse Ejecutar un programa, cargar una página web o enviar un correo electrónico: El único requisito es especificar el camino o path donde se encuentra la carpeta que contiene el programa a ejecutar o la dirección específica de la página que se desea abrir. La selección de la función que se desea ejecutar se realiza en la pantalla presentada en la Figura 31. Figura 31. Ejecutar un programa, cargar una página web o enviar un correo electrónico 79

79 Programar un itinerario de ejecución del ítem : Ésta es la función más importante de KeyText, ya que permite establecer el itinerario de ejecución de la herramienta de medición. Se puede establecer por año, mes, día, hora y minuto. Esto se puede observar en la Figura 32 Figura 32. Programar un tinerario de ejecución del ítem 80

80 Selección del Software de Captura En el caso de los softwares de captura, los parámetros de mayor peso a la hora de realizar el estudio de mercado fueron: Costo. Fácil uso. Separación de las capturas por encabezados y campos (Ethernet, IP, UDP, RTP). Filtro a nivel de software (rtcp display) Detección automática de la configuración de la red. Separación de la data por comas. Ayuda en línea. Garantía y confiabilidad. Para simplificar la lectura de Matriz de Selección a cada software se le asignó un número de sistema tal y como se observa en la Tabla 12. Sist. N Softwares 1 Wireshark 2 SoftPerfect Network Protocol Analyzer 3 Packet Analyzer Professional and Enterprise Editions 4 PacketScan 5 Lon Scanner Protocol Analyzer 6 IP Tools Tabla 12. Softwares de Captura evaluados La matriz con lo resultados se presentan a continuación en la Tabla 13: 81

81 N PARÁMETROS Peso Evaluación Parámetro Calificación SOFTWARE DE CAPTURA Sist.1 Sist 2 Sist 3 Sist. 4 Sist 5 Sist. 6 Sist. 1 Sist. 2 Sist. 3 Nivel de solución a las necesidades de CANTV 1 Costo Estabilidad Diseño Fácil uso Velocidad Plataforma que soporta el sistema Requerimientos de hardware Nivel de desarrollo de las aplicaciones de software necesarias Filters Setup *Hardware Filter (capture) *Software Filter (rtp) (display) *Los filtros se pueden guardar para todas las capturas Permite crear y enviar tramas Forma de separar las capturas por encabezados y 12 campos (Ethernet, IP, UDP,RTP) Facilidad para guardar en archivos la captura en sí y sus reportes Loopback monitoring Real Time Packet Decoding Supported protocols Command line parameters Log views and log files Print file and preview Import/export filters Import/export data Separa la data por comas Sist. 4 Sist. 5 Sist. 6 82

82 Evaluación Parámetro Evaluación N PARÁMETROS Sist Sist Sist Sist. Sist. Sist. Sist. Sist. SOFTWARE DE CAPTURA Peso Sist.1 Sist Sist. 2 Sist Timestamp resolution Auto-detecting network configuration Import/Export network profile List and manage open ports and attached processes Posibilidad de trabajo en régimen de red local Aplicaciones Extra Traffic Flow Diagram Host Activity Protocol Distribution Diagram Summary Statistics Network utilization statistics Protocol statistics Graphic Reports Call Trace & Statistics View Diagnostico y generacion de eventos Monitorea simultaneamente canales y networks 37 multiples Mantenimiento/asesoría del fabricante Garantía y confiabilidad Calidad de los manuales de usuario Ayuda en línea TOTAL Tabla 13. Matriz de Selección de los Softwares de Captura 83

83 Al analizar los resultados obtenidos en la Tabla 13, se observa que el software que sumó mayor cantidad de puntos fue el sistema 1, es decir, Wireshark, por lo tanto fue el seleccionado como el software de captura para este Proyecto de Grado. Wireshark es un analizador de protocolos de red para Unix y Windows, y es libre. Permite revisar datos de una red activa o de un archivo de captura en algún disco. Se puede examinar interactivamente la información capturada, viendo información de detalles y sumarios por cada paquete. Wireshark tiene varias características poderosas, incluyendo un lenguaje completo para filtrar lo que se quiere ver y la habilidad de mostrar el flujo reconstruido de una sesión de TCP. Destaca también por su impresionante soporte de protocolos, gracias, sin duda, a la licencia GPL y sus más de 200 colaboradores de todo el mundo. Wireshark analiza protocolos de red lo cual permite capturar y navegar entre contenidos de las estructuras de red. Es una aplicación utilizada por profesionales de redes para solucionar problemas de todo tipo, análisis, desarrollo de protocolos y programas y como una herramienta educativa. Toda la información capturada puede ser guardada o impresa y el programa puede analizar 750 distintos protocolos. Su interfaz es intuitiva. Dentro de las características principales están: o Los datos pueden ser capturados desde una red activa o leídos desde un fichero. o Puede leer ficheros de captura de tcpdump (libpcap), NAI's Sniffer (comprimido y no comprimido), Sniffer Pro, NetXray, Sun snoop y atmsnoop, Shomiti/Finisar Surveyor, AIX's iptrace, Microsoft's Network Monitor, Novell's LANalyzer, RADCOM's WAN/LAN Analyzer, HP-UX nettl, i4btrace, Cisco Secure IDS iplog, reportes pppd (formato pppdump), AG Group's/WildPacket's EtherPeek/TokenPeek/AiroPeek y Visual Networks' Visual UpTime. 84

84 o Los datos activos pueden leerse de Ethernet, FDDI, PPP, Token-Ring, IEEE , IP clásica sobre ATM e interfaces de lazo. o Los ficheros de captura pueden se editados o convertidos por comandos de línea. o Analiza 750 protocolos. o Permite tener filtros de pantalla y la configuración de estos filtros se puede guardar para futuras capturas. La pantalla principal de Wireshark se presenta a continuación en la Figura 33: Figura 33. Pantalla principal de Wireshark El procedimiento detallado de la captura y sus respectivas pantallas serán explicados en el punto 3.3, dentro de las características del diseño para la herramienta de automatización de medición de los parámetros de calidad de servicio de VoIP. Este software, al ser el que se automatiza, representa la base esencial sobre la cual se desarrolla el diseño, por lo tanto, merece ser explicado en detalle dentro de los procedimientos. 85

85 Base de Datos Se programó la base de elementos NGN que permiten la comunicación de Voz sobre IP (Switch, Media Gateway, Gatekeeper, Firewall, Routers y Nodo Pots). Dicha base de datos se implementó usando el programa Access, tal y como se observa en la Figura 34, con el fin de relacionar cada dirección IP fuente y destino de aquellas llamadas que presenten calidad de servicio deficiente con su respectivo nombre (hostname o IP type). De esta forma se agiliza el reconocimiento y ubicación del elemento que presentó una falla. Cuando se tiene la información definitiva con las todas llamadas que presentaron mala calidad de servicio, se correlacionan las direcciones IP con su respectivo nombre dentro de la red NGN de CANTV Figura 34. Base de Datos en Access 3.2. Retos en el Diseño de la Herramienta Este proyecto, al tratarse de una herramienta innovadora que monitorea variables de VoIP, cuyo desarrollo y aplicación se encuentra en pleno auge en el país, se realizó con un el levantamiento de información laborioso y fue todo un reto, puesto que actualmente la compañía está haciendo un profundo seguimiento del tema y VoIP representa un mundo que apenas se está esta difundiendo en los nuevos esquemas operacionales de CANTV. Sin embargo, gracias a la existencia de Internet y su fácil acceso, se pudieron establecer excelentes relaciones con los desarrolladores de los softwares de captura y automatización, vía correo electrónico. Ellos brindaron un apoyo 86

86 incondicional y respondieron pacientemente cualquier duda o sugerencia durante toda la elaboración del proyecto. Otro importante reto en el presente trabajo de pasantía fue adaptar el grado de libertad brindado por la empresa en la obtención del objetivo; su único requisito fue la elaboración de la herramienta de automatización. Sin embargo, el camino a seguir era completamente libre y las alternativas a desarrollar eran múltiples. Por tener tan diversas opciones, el levantamiento de información en pos de la realización de las matrices de selección fue un trabajo arduo y complejo, con el fin de seleccionar los programas que se adaptaran mejor a las necesidades de CANTV. Sumada a esta difícil estrategia de recolección de información para el diseño, está la complejidad del escenario de prueba. Actualmente la empresa se encuentra mejorando sus escenarios de pruebas para poder brindar un excelente servicio; debido a esta etapa transitoria de mejoras, existe una limitante de recursos en la sede CNT (Centro Nacional de Telecomunicaciones) que permita realizar las pruebas del diseño y los avances en la programación de la herramienta mediante la realización de una captura real. En una situación ideal, todo lo que se quisiera implementar tendría que ser probado siempre en escenarios reales y no en simulaciones, sin embargo, debido a la gran cantidad de trabajos operacionales que usaban los mismos recursos, se tuvieron que realizar capturas simulando llamadas mediante Softphones dentro del segmento de prueba en la sede de los Palos Grandes, y cuando había disponibilidad con el servidor en CNT en la Libertador, se podían confirmar las pruebas realizando capturas de tráfico real. Esta situación no es la óptima puesto que retrasa el proceso de creación de rutinas, ya que el script del Macro Recorder debe ser modificado para cada PC en particular. El procedimiento que KeyText automatiza no puede ser devuelto una vez iniciado, así que de ocurrir alguna falla durante la etapa de diseño en la herramienta de automatización, la única alternativa es abandonar su ejecución y comenzarla de nuevo. Posterior al intento fallido se deben efectuar ajustes que permitan un mejor funcionamiento de la herramienta, basándose en las características de la falla. 87

87 Por otro lado el tiempo de ejecución de la rutina completa toma de 45 minutos a una hora aproximadamente. Esta dinámica de trabajo implica una seria concentración para la depuración de la herramienta, demanda gran atención permanecer alerta a la expectativa de una falla para que, en caso de ocurrir, poder registrar sus características, sus posibles causas y después corregirla. Las correcciones efectuadas pueden ser detalles, como unas coordenadas invertidas, una variable, un signo, un tiempo de espera muy corto, etc. Sin embargo, se debe esperar a que se efectúe otra corrida para verificar que realmente la falla de la herramienta haya sido corregida Características del diseño para la Herramienta de Automatización de medición de los parámetros de calidad de servicio de VoIP. En la etapa de levantamiento de información, estudio de procedimientos de medición y optimización de los recursos de software y hardware se determinaron las principales características y funciones que debía tener la herramienta de automatización. A partir de estas bases teóricas se concibió un esquema de trabajo inicial que, a medida que se fuera probando en los escenarios reales de ejecución y captura, se iría depurando hasta alcanzar el diseño final que responda eficientemente a las necesidades de la empresa. A continuación en la Figura 35, se presenta un esquema que ilustra cómo están distribuidas las funciones de cada software: Key Text Automatiza Procesa Captura Java Wireshark Access Figura 35. Función de cada Software 88

88 El script de KeyText ejecuta las rutinas automatizando los clicks del mouse o del teclado para cada captura con el fin de extraer la data necesaria para análisis de la calidad de servicio. Dicho código se encuentra en formato digital en los anexos. en la Figura 36. En general, la herramienta automatiza las funciones expuestas a continuación Figura 36. Diagrama de flujo con las rutinas automatizadas de Wireshark A continuación se explican en detalle cada una de las etapas que se automatizaron: 89

89 1. Rutina de inicio del programa de captura, Wireshark. En este caso se dan los comandos necesarios para iniciar el programa. Esto es automático y no requiere de ninguna pantalla, sólo comandos automáticos invisibles al usuario. 2. Rutina de selección de la interfaz de red para realizar la captura. La selección de la interfaz de captura se realiza haciendo clic sobre la opción Interfaces en el menú Capture tal y como se observa en la Figura 37. Figura 37. Primera parte de la rutina de selección de la interfaz de red para realizar la captura Una vez abierta la ventana con las distintas opciones de interfaces, se procede a seleccionar aquella interfaz que cumpla con la descripción adecuada. En el caso de este proyecto de grado se busca capturar sobre la interfaz 3Com 3C90x Ethernet Adapter (Microsoft s Packet Scheduler), siendo ésta la tercera opción, tal y como se observa en la Figura

90 Figura 38. Segunda parte de la rutina de selección de la interfaz de red para realizar la captura 3. Rutina de finalización de la captura, dado un tiempo establecido. Una vez transcurrido el tiempo establecido para la captura, en este caso 5 minutos, se detiene la captura, al pulsar el botón Stop que aparece en la parte inferior de la pantalla. Esto se observa en la Figura 39. Figura 39. Rutina de finalización de la captura 4. Rutina de selección, copia y exportación de las estadísticas RTP. Del menú Statistics se selecciona el submenú RTP y a su vez de éste se selecciona la opción Show all RTP Streams. Tal y como se observa en la Figura

91 Figura 40. Primera parte de la rutina de selección, copia y exportación de las estadísticas RTP. Una vez que aparece la pantalla con las estadísticas RTP, se procede a copiarlas y a exportarlas a un archivo de texto denominado rtp-info.txt. Estos pasos se ilustran claramente en las Figuras 41 y 42 respectivamente. Figura 41. Segunda parte de la rutina de selección, copia y exportación de las estadísticas RTP 92

92 Figura 42. Formato del archivo rtp-info.txt 5. Rutina para filtrar los paquetes RTCP y ordenarlos de forma decreciente según el campo info. Se filtran los paquetea RTCP, para ello se coloca el cursor sobre la opción de filtros y se escribe rtcp, luego se presiona la tecla enter. Posteriormente se hace clic dos veces seguidas sobre la opción Info para ordenar los paquetes de forma decreciente, de esta forma se tendrán en el tope los paquetes que contengan información sobre el Roundtrip Delay (retardo ida y vuelta). Esto se ve en la Figura 43. Filtra los paquetes RTCP Ordena de forma decreciente según el campo info Figura 43. Rutina para filtrar los paquetes RTCP y ordenarlos de forma decreciente según el campo info. 93

93 6. Rutina de exportación de encabezados de un paquete RTCP a un archivo de texto denominado rtdelay.txt Esta rutina será ejecutada n veces, siendo n el número de paquetes RTCP que se desean analizar, este número está predeterminado en el script y es modificable. En esta rutina se copian los encabezados e información necesaria para determinar el IP origen y destino con su respectivo Roundtrip Delay. Esto se puede observar en las Figuras 44 y 45. Se exporta el número de trama y la data de los protocolos IP y UDP a un archivo de texto Figura 44. Primera parte de la rutina de exportación de encabezados de un paquete RTCP a un archivo de texto 94

94 Se exporta la data específica referente al Roundtrip Delay Figura 45. Segunda parte de la rutina de exportación de encabezados de un paquete RTCP a un archivo de texto Dicha información se exporta a un archivo de texto denominado rtdelay.txt, tal y como se muestra en la Figura 46. Figura 46. Formato del archivo rtdelay.txt 7. Rutina de salida del programa de captura y generación de archivo de registros o log files en formato específico de captura (.pcap). Esta rutina se realiza en cuestión de segundos, copia el archivo en formato.pcap y como nombre le coloca la fecha y hora en el siguiente formato ddmmaaaa_hhmm. Posteriormente procede a cerrar el programa Wireshark. 95

95 8. Etapa de ejecución del código de java que relaciona los dos archivos de textos generados durante la captura y analiza dicha data con el fin de generar un reporte final que resuma los parámetros monitoreados de las llamadas con mala calidad de servicio. A continuación en la Figura 47 se presenta el diagrama de bloques ilustrando las rutinas a ejecutar por JAVA: 96

96 Se ejecuta java Lee archivo rtp-info.txt Lee archivo rtdelay.txt Analiza y valida cada línea en busca de un valor que supere el límite establecido para jitter y pérdida de paquetes Analiza cada línea verificando que efectivamente se haya copiado la línea Roundtrip Delay Se descarta la línea NO Jitter > 30 ms Pérdida > 1 % La línea tiene Roundtrip Delay? SI NO Se descarta la línea SI Se genera un archivo (A) con las líneas que tienen valores superiores al límite, y se levanta una bandera con la causa Se leen las líneas validadas y se promedia el valor de Roundtrip Delay de las que tengan igual IP origen y destino, e igual puerto RTCP origen y destino. (Esto significa que pertenecen a la misma llamada) Se genera un archivo (B) con 1 sola línea por llamada y su respectivo Roundtrip Delay > 5ms Se leen comparan archivos A y B Verificar banderas y determinar la causa de la mala calidad de servicio SI Coinciden IPorigen, IPdestino y puerto RTCP=puerto RTP+1 NO Las llamadas no pueden tener las 3 causas a la vez. Tienen jitter y/o pérdida o tienen exceso de Roundtrip Delay Se genera el Reporte Final, con el resumen de los eventos detectados Figura 47. Diagrama de bloques de las rutinas a ejecutar en Java 97

97 Para correr el programa en Java es necesario seleccionar la opción Execute Project del menú Build. A continuación en la Figura 48 se ilustran estos pasos. Figura 48. Rutina de ejecución del proyecto Una vez ejecutado el programa en Java se genera un Reporte Final que resume el comportamiento de la red durante el monitoreo, en dicho reporte sólo aparecen las llamadas que presentaron mala calidad de servicio con sus respectivos parámetros e información importante. En la Figura 49 se presenta un patrón de dicho Reporte Final. 98

98 Figura 49. Formato del Reporte Final 9. Rutina de envío vía correo electrónico del reporte final a los empleados del COR. En esta rutina se abre la página web y se procede a realizar los clics necesarios para entrar en la cuenta del usuario soporte.ngn. Posteriormente se hace clic en Compose Mail, se agrega la dirección del destinatario, se agrega el texto correspondiente, se adjunta el archivo correspondiente al Reporte Final y finalmente se envía el correo. Estos pasos están enumerados a continuación en la Figura

99 Figura 50. Rutina de envío del correo electrónico 3.4. Implementación de la herramienta Tal como se ha explicado anteriormente, la herramienta para la automatización de la medición es un programa o script que se ejecutará bajo la plataforma del Macro Recorder, denominado KeyText, por lo tanto es necesario tener corriendo en la PC dicho programa para que se pueda iniciar la herramienta. Además se deben colocar los archivos contentivos del código y el ejecutable de Key Text ( QoS.ktt ), así como la carpeta 000_Java (contentiva de archivos auxiliares exportados de Wireshark y el ejecutable de Java) en el directorio C:\Archivos de programa\qos_voip de la PC donde se va a ejecutar la herramienta. KeyText para automatizar los procesos de captura y análisis de data hace uso de las interfaces gráficas de ambos programas ejecutando rutinas que simulan clicks del mouse o del teclado, de esta forma es capaz de automatizar cualquier función que un usuario ejecuta manualmente en tiempo real. Por lo tanto se deben ajustar las 100

100 características de la interfaz gráfica de Wireshark y JCreator con el fin de respetar las posiciones de los elementos en la pantalla, de forma tal que las coordenadas predeterminadas en el script coincidan con las reales. La importancia del Macro Recorder (KeyText) radica en el hecho que éste puede ser programado por tiempo e itinerarios, es decir, las rutinas se pueden activar en un tiempo previamente establecido, dicha carácterística automatiza por completo el proceso de medición y alarma de eventos. Los requisitos de pantalla de Wireshark que se deben cumplir se configuran en el submenú preferencias dentro del menú Edit, tal como se presenta a continuación en la Figura 51. Figura 51. Configuración de pantalla en Wireshark Una vez seleccionada la ubicación de los tipos de paquetes, se configura el número de paquetes de cada tipo que debe aparecer en la interfaz gráfica. Para ello se hace clic sobre la interfaz y se arrastra con el Mouse hasta llegar a la posición deseada, 101

101 por comodidad y mejor visibilidad de la descripción de cada paquete se decidió establecer en la pantalla lo siguiente: 15 paquetes de la lista general de paquetes. 5 paquetes de Bytes Dicha configuración se observa en la Figura 52 Packet List 15 paquetes 5 paquetes Packet Bytes Packet Details Figura 52. Configuración de los paquetes en la pantalla de Wireshark 102

102 CAPÍTULO IV PRUEBAS REALIZADAS Y ANÁLISIS DE RESULTADOS El presente capítulo ofrece una descripción de las pruebas realizadas durante el diseño de la herramienta de medición; la implementación final se debió a un proceso escalonado de pruebas preliminares. Los resultados surgen a partir de los archivos de registros que genera la herramienta en cada sesión de prueba Pruebas preliminares Durante el diseño de la herramienta de medición se realizaron pruebas preliminares por etapas con el fin de ir ensamblando por partes lo que se convertiría en la prueba definitiva, capaz de capturar, analizar y enviar el reporte final automáticamente. Debido a las limitaciones de recursos de la sede final en CNT, lugar donde se implementaría en definitiva la herramienta; fue necesario crear ambientes controlados de pruebas en la sede de los Palos Grandes. De esta forma se hizo posible ir depurando tanto el código del Macro Recorder (KeyText), el cual automatiza las rutinas, como el código de Java, el cual procesa la data previamente capturada. Las pruebas comenzaron como etapas independientes de captura, llamada, automatización y procesamiento de data. Una vez que cada elemento funcionaba a la perfección por separado, se empezaron a combinar progresivamente. Con cada combinación se realizaron pruebas exhaustivas con el fin de buscar errores y optimizar su funcionamiento. En el momento que la herramienta funcionó perfectamente dentro del ambiente controlado de los Palos Grandes, es decir, capturando llamadas realizadas manualmente y no con tráfico IP en tiempo real. Se decidió implementar la herramienta en CNT y probarla con altos niveles de tráfico. Las capturas iniciales tuvieron un tiempo de duración de 60 segundos, de esta forma se facilitaba la corrección de errores. Hay que recordar que una vez que se inicia el macro con la rutina, hay que esperar que finalice su ejecución para corregir cualquier error que se haya presentado. Por esta razón se optó por realizar capturas de corta duración. Dichas pruebas sirvieron para fijar los valores máximos de cada parámetro. 103

103 A medida que se optimizaba el macro se fueron agregando funciones más complejas tales como la consulta de la base de datos para relacionar las direcciones IP de las llamadas con mala calidad con el respectivo nombre del elemento y el envío del correo electrónico con el Reporte Final. A continuación en el diagrama de la Figura 53 se presenta un resumen detallado de cada una de las etapas con sus respectivas actividades; observando como se combinaron progresivamente hasta obtener la rutina definitiva. Figura 53. Pruebas preliminares 104