Repositorio Institucional de Documentos

Repositorio de la Universidad de Zaragoza – Zaguan http://zaguan.unizar.es DIFUSIÓN DE DATOS EN STREAMING CON MEDIOS CIS TÁCTICOS Autor Rubén Villaverde Órpez Director/es Director académico: Prof. D. Jorge Ortín Gracía Director militar: Cap. D. Jorge Huertos Aparicio Centro Universitario de la Defensa - Academia General Militar Año 2018 Trabajo Fin de Grado II III Agradecimientos Quisiera dar mi agradecimiento a todas aquellas personas que de una forma u otra han participado con su esfuerzo, apoyo, conocimientos y experiencias personales en la realización de este proyecto. En primer lugar al Doctor Don Jorge Ortín García, director académico de este proyecto, cuya inestimable ayuda y consejo profesional ha sido una guía constante a lo largo de la consecución de los objetivos de dicho proyecto. En segundo lugar a la Compañía de Transmisiones I de la Brigada Aragón I, y a todo su personal, pero sobre todo al Capitán Don Jorge Huertos Aparicio, director militar del proyecto, y a los Tenientes Don Marcos Rozalén Fortúnez, Don Juan Ramón Pérez Quintanar y Don Miguel Donaire Ballesteros. Su experiencia y conocimientos han permitido profundizar en los aspectos más técnicos durante la realización del proyecto. Por último, pero no menos importante, agradecer también a mi familia y pareja su incondicional apoyo y ánimo transmitido, y también el aporte de motivación extra que me ha facilitado el camino hasta el final. IV V Abstract This final degree project tries to show to the reader an analysis about the viability, shortcomings and technical defects of streaming data transmission with CIS tactical means of the Army. Ultimately, it also tries to serve as a little guide or method to transmit streaming data. Nowadays, it is necessary to be informed, not only constantly, but also in a fast and safe way, and specially from anywhere. The current trend in communications is to transmit real time data with an objectively acceptable quality to the user. Today, almost all users does not conceive that, for example, a live video and voice transmission cannot be made, in fact it has become the most demanded service by the users. Therefore, the currently streaming transmission data with the available CIS tactical means will be analyzed, and the best way to do it with an acceptable quality for the final user will be investigated. As a little technical summary, the streaming or retransmission, consists of transmitting multimedia data between two terminals in a communications network. Thinking in a video conference for instance. In this transmission, the user receives the multimedia data at the same time that it is transmitted, and only a little data buffer is used to store the information flow when it is downloaded and used by the user. This method of data transmission is contrary to what users were used to do in the past. For example, in the past the user downloaded the video completely before. Now, through streaming, it is possible to view the video while downloading the data, which allows the possibility of making live video. For these reasons it will be necessary to analyze the viability of this type of data transmission. Firstly, because the tactical means of the Army should be able to support those kind of transmission, and secondly because the client must obtain the product with an objectively acceptable transmission quality. Regarding the CIS tactical means, satellite means will be used mainly, due to various advantages they have over other tactical equipment. As an advance, the main advantage offered by satellite terminals is the ability to link from almost anywhere, and also the fact that they allow very large link distances. The quality conditions of the transmission will be measured in two ways: subjectively and objectively. The objective vision will be given by technical data such as the available bandwidth. The subjective vision will be imposed by the end user's appreciation of quality. Therefore, in order to obtain the information and conclusive data for this project, a test scenario will be implemented with satellite means. Hence, with computer tools the expected results of a streaming data transmission will be obtained with an acceptable quality. Apart from this real scenario, a laboratory scenario will also be established to emulate different streaming transmissions, having more available alternatives analysis. VI VII Índice de contenidos Lista de tablas.............................................................................................................. IX Lista de ilustraciones ................................................................................................... XI Lista de acrónimos .................................................................................................... XIV CAPÍTULO 1 - INTRODUCCIÓN .................................................................................. 1 1.1 - Motivación ..................................................................................................... 1 1.2 - Objetivos del proyecto ................................................................................... 1 1.3 - Metodología .................................................................................................. 2 1.4 - Estructura de la memoria .............................................................................. 2 CAPÍTULO 2 - ESTADO DEL ARTE ............................................................................. 4 2.1 - Antecedentes ................................................................................................ 4 2.2 - Difusión de datos en Streaming .................................................................... 4 2.2.1 - Arquitectura TCP/IP ........................................................................ 5 2.2.2 - Arquitectura Streaming .................................................................... 6 2.3 - Situación actual en el Ejército de Tierra ........................................................ 7 CAPÍTULO 3 - DESARROLLO DEL PROYECTO ......................................................... 9 3.1 - Escenario de pruebas en laboratorio ............................................................ 9 3.1.1 - Conexionado físico y configuración IPv4 ......................................... 9 3.1.2 - Software Polycom PVX ................................................................. 10 3.1.3 - Software Wireshark ....................................................................... 12 3.1.4 - Software BitMeter .......................................................................... 13 3.2 - Escenario de pruebas real .......................................................................... 14 3.2.1 - Conexionado físico y configuración IPv4 ....................................... 14 3.2.2 - Software Polycom PVX ................................................................. 17 3.2.3 - Wireshark y Bitmeter ..................................................................... 18 CAPÍTULO 4 - ANÁLISIS DE LOS DATOS OBTENIDOS ........................................... 19 4.1 - Pruebas realzadas en el escenario de laboratorio ...................................... 19 4.2 - Pruebas realizadas en el escenario real ..................................................... 25 CAPÍTULO 5 - CONCLUSIONES ............................................................................... 27 ANEXOS ..................................................................................................................... 30 Anexo A - Matriz DAFO sobre medios satélite .................................................... 30 Anexo B - Guía de transmisión streaming en red IP ........................................... 31 Anexo C - Configuración de la red LAN .............................................................. 34 Anexo D - Configuración de Polycom PVX ......................................................... 39 BIBLIOGRAFÍA ........................................................................................................... 46 VIII IX Lista de tablas Tabla 1 - Configuración IPv4 ....................................................................................... 10 Tabla 2 - Pruebas de laboratorio ................................................................................. 19 Tabla 3 - Equipos satélite y ancho de banda .............................................................. 27 Tabla 4 - Posibilidades de uso según equipos ............................................................ 27 Tabla 5 - Matriz DAFO medios satélite ....................................................................... 30 Tabla 6 - Diagrama de flujo streaming ........................................................................ 33 CAPÍTULO 1 - INTRODUCCIÓN DIFUSIÓN DE DATOS EN STREAMING 1 CAPÍTULO 1 - INTRODUCCIÓN Para comenzar, haremos hincapié a modo de introducción en el alcance y objetivos de este proyecto, así como en la motivación y el porqué del mismo. La intención no es otra que facilitar al lector la comprensión de la necesidad de analizar la transmisión de datos en streaming, de cara a proporcionar una mejor comprensión de este método de transmisión de datos, así como su utilidad en el ámbito militar. 1.1 - Motivación La tecnología streaming 1 es un tipo de transmisión que se ha convertido de gran importancia en los ejércitos para transmitir datos e información fiable y oportuna. Las condiciones del combate contemporáneo exigen la explotación de la información de manera instantánea. Es por ello por lo que la difusión de datos en streaming es de vital importancia hoy en día para los ejércitos de todo el mundo. Por ello, la motivación principal de este proyecto es realizar un análisis sobre las posibles carencias o problemas técnicos de la transmisión de datos en streaming con medios satélite. De esta manera se podría analizar también qué soluciones se podrían implementar para solventar dichos problemas en el futuro. Por otro lado, este proyecto pretende ayudar a la decisión final del Mando en la toma de decisiones. En lo que respecta al planeamiento CIS (Sistemas de Telecomunicaciones e Información), el Mando debe asegurar el uso eficaz y oportuno de la información. Es por ello por lo que este proyecto está enfocado, no solo en analizar la utilidad de la transmisión de datos en streaming, sino también en servir de ayuda a la hora de decidir adecuadamente cómo hacer un uso eficaz de la información mediante el ejercicio del mando. 1.2 - Objetivos del proyecto El objetivo de este proyecto, como se ha comentado anteriormente, es el de analizar la viabilidad de la transmisión de datos en streaming, haciendo para ello uso de medios CIS tácticos. En concreto, el medio considerado es la transmisión por satélite, ya que esta presenta diversas ventajas notables sobre otros medios tácticos que se han venido usando, como pueden ser los obsoletos equipos de la RBA (mayor ancho de banda disponible, superior fiabilidad y alcance). En el Anexo A se muestra un análisis sobre las ventajas y desventajas del uso de medios satélite mediante una matriz DAFO. Los equipos satélite, pese a depender por norma general de la necesidad de pedir una SAS (Solicitud de Acceso Satélite, ver epígrafe 1.3 – Metodología, apartado 2) y esperar a que el escalón superior de su aprobación para su uso (Mediante su respectiva AS, o Acceso Satélite), presentan ventajas sobre los demás medios tácticos, sobre todo en lo que se refiere a la posibilidad de enlazar a grandes distancias, situar el equipo en casi cualquier lugar y tener un ancho de banda más que aceptable para la transmisión de datos en streaming. Una vez aclarado que los medios satélite son los más adecuados para una transmisión de datos en streaming vamos a pasar de un modo más específico a establecer los objetivos específicos del proyecto:  Montar un entorno de pruebas formado por una conexión streaming vía satélite para su posterior análisis, así como un entorno de pruebas en laboratorio.  Realizar ensayos y pruebas para determinar la viabilidad de transmisión de datos en streaming estableciendo sus posibles carencias y problemas técnicos.  Medir los consumos de recursos que implica la transmisión en streaming a través de satélite y medir tanto objetivamente como subjetivamente la calidad de la transmisión. 1 Streaming es el término asociado a la tecnología que permite distribuir contenido multimedia a través de una red de ordenadores en tiempo real, de manera que el cliente puede reproducir los datos directamente en su terminal según los descarga. CAPÍTULO 1 - INTRODUCCIÓN DIFUSIÓN DE DATOS EN STREAMING 2  Confirmar que la transmisión de datos en streaming es compatible con otros usos del ancho de banda como por ejemplo la telefonía.  Establecer una pequeña guía para el usuario acerca de la transmisión de datos en streaming. 1.3 - Metodología Para la realización de este proyecto se ha considerado necesario subdividir el trabajo en las siguientes fases: 1) Recopilación de la información necesaria para la realización del proyecto. Principalmente se solicitará información y se entrevistará al personal militar competente en materia de Transmisiones en el Ejército, acerca de los tipos de terminales satélite más adecuado para una transmisión de datos en streaming, así como consejo sobre qué escenario de transmisión de datos es más propicio para concluir con los objetivos del proyecto. 2) Petición de una SAS. Para poder establecer un escenario de transmisión de datos vía satélite, es necesario contar con el permiso adecuado del escalón superior (Jefatura de Sistemas y Programas del Centro de Gestión del Servicio Militar de Comunicaciones). Por ello se solicita a este una relación de medios, parámetros de transmisión y espacio de tiempo en el que se requiere que esté autorizada la transmisión de datos por satélite. Esta Jefatura, responde dando el AS a la unidad que lo solicitó. 3) Montaje de un escenario real de difusión de datos en streaming por satélite. Una vez autorizado su uso, se montarán dos terminales satélite THURAYA-IP, los cuales contarán con un ancho de banda de 16 Kbps. A cada uno de ellos se conectará un terminal (PC) con un software (Polycom PVX) que permite la realización de videoconferencia. Paralelamente se montará un escenario de laboratorio en el que se comprobarán como responderían los enlaces satélite a diferentes tipos de calidad de transmisión de datos en streaming. 4) Monitorización de la transmisión de datos en streaming. Durante la realización de la videoconferencia se usará un software específico (Wireshark y BitMeter) que permite monitorizar el tráfico de datos que sale desde uno de los terminales. Con este software se analizarán datos como el ancho de banda consumido, retardos y jitter. 5) Análisis de la viabilidad y los datos obtenidos de la transmisión. Por último, se analizarán los datos obtenidos del streaming y se comprobará si el montaje presenta carencias o problemas técnicos para realizar este tipo de transmisión de datos. También se comprobará que el streaming es compatible con otros servicios como la telefonía. 1.4 - Estructura de la memoria El presente proyecto se ha estructurado siguiendo los epígrafes que se relacionan a continuación: CAPÍTULO 1 – INTRODUCCIÓN: En este primer capítulo se hace una breve introducción al proyecto, indicando su motivación y objetivos y explicando la metodología seguida para su realización. CAPÍTULO 2 – ESTADO DEL ARTE: El segundo capítulo, comienza con una introducción sobre los antecedentes del uso de streaming, tanto a nivel civil como militar. Posteriormente, se analiza la arquitectura TCP/IP y la tecnología de difusión de datos en streaming, y se detallan los medios disponibles actualmente en el ET para realizar la transmisión en streaming. CAPÍTULO 3 – DESARROLLO DEL PROYECTO: En este tercer capítulo se expondrán dos escenarios de transmisión de datos vía streaming, uno simulado en laboratorio que modela al real, y el real propiamente dicho. Se explicarán los equipos utilizados así como su configuración y pasos para establecer operativamente los escenarios. CAPÍTULO 4 – ANÁLISIS DE LOS DATOS OBTENIDOS: Durante el cuarto capítulo se expondrán las pruebas realizadas tanto en el escenario de laboratorio, como en el escenario real. Tras ello, se analizarán los datos obtenidos de las pruebas. CAPÍTULO 1 - INTRODUCCIÓN DIFUSIÓN DE DATOS EN STREAMING 3 CAPÍTULO 5 – CONCLUSIONES: Se expondrán en este último capítulo, las conclusiones finales al proyecto, tanto sobre las pruebas, como sobre los equipos y posibilidades que tienen los mismos para realizar transmisiones de datos en streaming. ANEXOS: En este apartado, se expondrán cuatro anexos con información complemetaria al proyecto. BIBLIOGRAFÍA. CAPÍTULO 2 - ESTADO DEL ARTE DIFUSIÓN DE DATOS EN STREAMING 4 CAPÍTULO 2 - ESTADO DEL ARTE 2.1 - Antecedentes La tecnología o método de transmisión de datos multimedia vía streaming está a la orden del día. Concretamente esta difusión de datos multimedia se puso en marcha por primera vez en 1995, cuando la empresa RealNetworks, inc. utilizó el formato de audio RealAudio 1.0, permitiendo reproducir audio en tiempo real [1]. A medida que fueron transcurriendo los años, multitud de desarrolladores han proporcionado medios y software para la difusión de datos en streaming, como es el caso del famoso portal web de visualización de video Youtube. Desde entonces, esta tecnología ha revolucionado el mundo de las comunicaciones en tiempo real, no solo para el uso civil, sino también en el ámbito militar. Las comunicaciones en el Ejército de Tierra han tenido que evolucionar rápidamente a lo largo de los últimos años para adaptarse a la creciente revolución tecnológica de las telecomunicaciones. Tanto es así, que algunos medios de los que dispone el Ejército han quedado obsoletos con el paso de los años. Pero las nuevas tecnologías se han ido abriendo camino en los medios CIS de que disponen las unidades de Transmisiones, entre ellas las comunicaciones satélite y el streaming. De hecho, usando las redes IP por satélite se contempla el uso de streaming para videoconferencias y audio en tiempo real [2]. Por otro lado, la difusión de información en tiempo real ha cobrado vital importancia en las operaciones militares, y ya es usual ver drones retransmitiendo imagen en directo. Por ejemplo, en 2015 se estableció un contrato entre el Ministerio de Defensa y el Ejército de los Estados Unidos, para mediante la empresa AeroVironment, suministrar al Ejército de Tierra Español los UAV RQ-11B Raven DDL [3] (Ilustración 1), los cuales permiten realizar streaming de video. Ilustración 1 - RQ-11B Raven DDL [4] Por tanto, se puede concluir que el streaming de datos multimedia en el Ejército viene siendo usado desde hace años. Es un método de difusión de la información de vital importancia para las operaciones y seguirá siéndolo en el futuro con cada vez mayor facilidad y frecuencia. 2.2 - Difusión de datos en Streaming Streaming es el término asociado a la tecnología que permite distribuir contenido multimedia a través de una red de ordenadores en tiempo real, de manera que el cliente puede reproducir los datos directamente en su terminal según los va descargando. Antes de que el cliente pueda utilizar los datos descargados, se almacenan previamente en un Buffer de datos que dicho cliente tiene en su ordenador. Podemos distinguir varios tipos de transmisión de datos streaming [5]:  Streaming Tradicional (Descarga y Reproducción): Es el método más tradicional, en el que el usuario descarga completamente el archivo en su terminal. Tiene como ventaja el que el archivo puede ser llevado hacia delante o hacia detrás a gusto del usuario tantas veces como quiera, sin embargo, requiere alta capacidad de almacenamiento, sobre todo si se trata de CAPÍTULO 2 - ESTADO DEL ARTE DIFUSIÓN DE DATOS EN STREAMING 5 clips de video largos como por ejemplo películas. En la Ilustración 2 se puede observar el esquema básico de una transmisión streaming de este tipo. Ilustración 2 - Proceso streaming [6]  Live streaming (Presentación de streaming en Vivo): En este caso el usuario empieza a reproducir los datos directamente tras iniciar la descarga, con una tasa de transmisión constante. Normalmente funciona como si de una estación de radio se tratase, de manera que el cliente solo tiene acceso a lo que se está transmitiendo el en momento. De esta manera se aprovechan los recursos de la red puesto que el archivo no se almacena previamente. (Ej.: Videoconferencia).  Streaming Progresivo (Pseudo streaming): El archivo solicitado bajo demanda por el cliente se reproduce en el terminal a medida que es descargado. Permite realizar pausas y volver o adelantarse en el tiempo. En cambio, no aprovecha los recursos de red tan bien como el método Live streaming. (Ej.: Youtube). 2.2.1 - Arquitectura TCP/IP Como la difusión de datos en streaming se realiza normalmente empleando la arquitectura TCP/IP, vamos a describir teóricamente este modelo para poder comprender cómo trabaja la tecnología streaming a través de sus diferentes niveles o capas. Dada la cantidad de tareas que se deben realizar para poder transmitir información a través de una red, para simplificar el trabajo el modelo subdivide las tareas en diferentes capas que se ejecutan tanto en los terminales de usuario como en los routers que forman parte de la red. Así, establece cinco capas en las que cada una de ellas añade información para intercomunicarse con el siguiente subnivel. De esta manera cada capa o nivel tiene establecidos servicios y protocolos. Los primeros sirven para comunicarse entre un nivel N y su nivel superior N+1 a través de un interfaz determinado, y los segundos son un conjunto de reglas para que los niveles puedan comunicarse entre sí. En cada nivel se establece un conjunto de datos llamados PDU (Protocol Data Unit) que se intercambian las capas de mismo nivel, de manera que cada bloque de información de un nivel contiene la información propiamente dicha, más una cabecera de datos de control, que permite realizar las funciones propias del nivel. Por tanto, cuando una capa o nivel N pasa la información a un nivel N-1 encapsula la información que provenía del nivel N+1 añadiendo delante la cabecera de control. El encapsulado y desencapsulado son tareas del protocolo de ese nivel y no del servicio, siendo así esta tarea transparente para los demás niveles. En la Ilustración 3 puede observarse como cada capa encapsula su PDU con una cabecera antes de pasarla a la siguiente subcapa. En el destino, el proceso sería inverso, es decir, cada nivel desencapsula la PDU que le llega del nivel inferior y la pasa a su nivel superior [7]. CAPÍTULO 2 - ESTADO DEL ARTE DIFUSIÓN DE DATOS EN STREAMING 6 Ilustración 3 - TCP/IP PDU [8] Pasamos a definir las cinco capas de este modelo (En la Ilustración 4 pueden observarse los protocolos de cada capa): 1. Capa de Aplicación: Permite a las aplicaciones de red de distintos usuarios comunicarse entre sí. Su PDU se llama Mensaje. 2. Capa de Transporte: Transporta los mensajes de la capa de Aplicación entre usuarios. A su PDU se le denomina Segmento. 3. Capa de Red (o Internet): Encargada de establecer la comunicación entre hosts y transportar sus PDU llamadas Datagramas o Paquetes. 4. Capa de Enlace: Se encarga de encaminar los Datagramas por la red entre el origen y el destino. Su PDU se llama Trama. A nivel físico se encarga de hacer llegar los bits de cada trama desde un nodo de la red hasta el siguiente. Ilustración 4 - Modelo TCP/IP [9] 2.2.2 - Arquitectura Streaming La transmisión de datos streaming se realiza normalmente usando la arquitectura de red TCP/IP. Los elementos físicos de la capa de Internet del modelo se encargan de direccionar el flujo de datos (Stream) entre los terminales, en los que los datos van segmentados bajo los protocolos UDP (User Datagram Protocol) y TCP (Transmission Control Protocol) de la capa de Transporte. El protocolo RTP (Real Time Transport Protocol) es el encargado del envío de datos streaming en tiempo real de extremo a extremo en redes IP. Junto a este, se utilizan el protocolo RTSP (Real Time Streaming Protocol), el cual se encarga de la sincronización, monitorización de estadísticas y de la QoS (Quality of Service), y por otro lado el protocolo RTSP, que controla el flujo de datos en los servidores. Estos tres protocolos trabajan en la capa de aplicación y también conjuntamente en el proceso de envío de datos streaming [5]. CAPÍTULO 2 - ESTADO DEL ARTE DIFUSIÓN DE DATOS EN STREAMING 7 Para realizar una transmisión de datos en tiempo real el protocolo RTP se ejecuta sobre UDP. Los datos multimedia son encapsulados bajo una cabecera RTP que contiene el campo de número de secuencia, el campo de marca de tiempo y el identificador del origen de sincronización. A su vez, este paquete se encapsula bajo una cabecera UDP y luego sobre IP. Cuando el receptor recibe los datos, los desencapsula y los envía al reproductor multimedia para que los decodifique y los procese [7]. Entre cliente y servidor se establecen dos conexiones a nivel capa de transporte. La primera es bidireccional para el canal de control, establecido mediante TCP. La segunda es unidireccional y se usa para el envío de datos mediante UDP (Véase Ilustración 5). Para sincronizar el envío de datos, el protocolo RTSP mantiene solo una sesión abierta asociada a un identificador, en el que se usa TCP para establecer la conexión y UDP para el canal de envío de los datos propiamente dicho [1], como se ha mencionado anteriormente. Ilustración 5 - Protocolos streaming Cliente/Servidor [1] Por lo tanto, podemos establecer que en una típica transmisión de datos en streaming entre un cliente y un servidor genéricos, la familia de protocolos RTP trabaja conjuntamente para hacer llegar los datos en tiempo real de extremo a extremo. 2.3 - Situación actual en el Ejército de Tierra La transferencia de datos streaming en el ET no es un hecho novedoso. De hecho, las Transmisiones del Ejército suelen poner en práctica este tipo de transmisión de datos con bastante frecuencia. Las unidades que despliegan en una maniobra necesitan que sus puestos de mando estén continuamente comunicados con otros puestos de mando y con sus respectivas fuerzas. Estos enlaces se materializan aportando servicios de voz y datos. Hasta hace pocos años el servicio de voz se sustentaba sobre la base de telefonía en circuitos cableados (bien mediante hilo, bien mediante fibra óptica) o inalámbricos (mediante radioenlaces), pero la telefonía VoIP (IP Voice) ha sustituido prácticamente este sistema. Ahora las comunicaciones de voz se realizan sobre redes IP de datos, es decir, no son más que una mera transmisión streaming de datos de audio. La transmisión de VoIP se puede realizar a través de varios medios tácticos CIS, como por ejemplo terminales satélite y equipos de transmisión por radiofrecuencia. Por su parte, los servicios de datos proporcionan la posibilidad de realizar streaming de video (videoconferencias) a través de redes IP de datos. La manera oficial que el Ejército tiene de realizar videoconferencias es a través de los equipos Polycom. En 2016 el Ministerio de Defensa seleccionó el servicio de “Soluciones de Comunicaciones Unificadas” de Polycom para proporcionar al Ejército un servicio seguro, rápido y fiable de videoconferencia [10]. Para finalizar este apartado vamos a exponer los casos típicos de transmisión de datos en streaming que el ET emplea en sus comunicaciones:  Streaming de audio: El streaming de datos de audio mediante el sistema VoIP se realiza integrando la telefonía en una red IP. Los terminales telefónicos digitalizan la voz y la codifican usando la familia de Códecs G.7xx. Una vez digitalizada la voz, usan el Protocolo H.323 o SIP (Session Initiation Protocol) para codificar la voz antes de enviarla a la centralita IP, la cual gestiona todo el tráfico telefónico y permite acceder a las distintas redes, dando acceso telefónico a Internet y a la RTC (Red Telefónica Conmutada) mediante Gateways [11]. En la Ilustración 6 puede observarse el esquema básico de una red de VoIP. CAPÍTULO 2 - ESTADO DEL ARTE DIFUSIÓN DE DATOS EN STREAMING 8 Ilustración 6 - Esquema VoIP El Ejército, para desplegar sus redes de VoIP, usa diferentes medios para transmitir y enlazar estas redes IP. La telefonía IP al requerir poco ancho de banda puede ser transmitida sin problemas mediante equipos de la RBA 2 , en los que los vehículos adaptados disponen de terminales, centralitas y gateways. La información digital es transmitida mediante radioenlace entre los diferentes nodos. Otra opción usada suele ser el uso de equipos satélite, que al disponer de más ancho de banda permiten usar otros servicios paralelamente.  Streaming de video: La transferencia de datos en streaming suele usarse para realizar videoconferencias con el sistema Polycom, mencionado anteriormente. En la red IP, los terminales de los usuarios de la videoconferencia tienen instalados el software de videoconferencia y una cámara. El software Polycom PVX usa los protocolos H.323 o SIP, y H.264 para enviar el audio y el video respectivamente hasta el router, el cual es transmitido mediante una red IP por los equipos satélite del Ejército 3 hasta el otro extremo de la red, en la que el otro usuario se comunica por videoconferencia con el primero. En la Ilustración 7 puede verse el escenario básico de transmisión de una videoconferencia vía satélite. Ilustración 7 - Escenario streaming Satélite 4 Por lo tanto, podemos realizar varios comentarios respecto a cómo el ET realiza transmisiones en streaming. En primer lugar, notar que el streaming de datos en el Ejército es algo habitual, como ya se ha mencionado, y en segundo lugar decir que para transmitir datos que requieren un mayor ancho de banda (como una videoconferencia) es necesario utilizar equipos que dispongan suficientemente del mismo. En el Anexo B, podrá verse una pequeña guía para el usuario, sobre cómo establecer una transmisión streaming en una red IP. 2 Las estaciones de RBA tienen un ancho de banda de 512 Kbps. 3 Por norma general, puesto que la videoconferencia requiere mayor ancho de banda que una red de VoIP. 4 El escenario que se muestra es básicamente el que se va a usar para la realización de este proyecto. CAPÍTULO 3 - DESARROLLO DEL PROYECTO DIFUSIÓN DE DATOS EN STREAMING 9 CAPÍTULO 3 - DESARROLLO DEL PROYECTO Para comenzar este capítulo, y antes de establecer más en detalle los escenarios de laboratorio y real, se va a proceder a explicar en qué consiste específicamente el caso de uso considerado en este proyecto a grandes rasgos. Para poder analizar una transmisión de datos en streaming, y como se ha comentado anteriormente, se va a hacer uso de dos terminales satélite THURAYA-IP. Ambos, permitirán realizar una videoconferencia punto a punto con una conexión de datos IP. A cada equipo THURAYA-IP se conectarán dos terminales con software Polycom PVX con el cual se ejecutará la videoconferencia. Durante la transmisión se usará el software Wireshark para capturar el tráfico y poder medir datos como por ejemplo el uso del ancho de banda. De esta manera se analizarán problemas y carencias técnicas que puedan surgir durante la transmisión. También se analizarán los posibles problemas durante el montaje del escenario. 3.1 - Escenario de pruebas en laboratorio El motivo que conlleva el montaje y realización de un escenario de laboratorio no es más que el hecho de no poder disponer del uso de los terminales THURAYA-IP cada vez que se necesite 5 . Como se ha comentado ya, es necesario tener acceso satélite para poder usarlos y para ello previamente se ha de solicitar una SAS, con el consiguiente tiempo de espera hasta recibir su aprobación. Por lo tanto, para poder disponer de un escenario sencillo y fácil de montar, en el que se puedan hacer pruebas cada vez que se necesite, se ha optado por emular el escenario real en un entorno de laboratorio. Este escenario está enfocado en emular una transmisión de una videoconferencia vía satélite. Para ello se va a utilizar un router TP-LINK (Modelo Archer MR200) para realizar la conexión IP entre los dos terminales, de manera que emule lo más parecido posible a una transmisión de datos por satélite. Evidentemente, el router no puede emular ciertas características de una transmisión satélite (como por ejemplo el retardo o el jitter), pero si permitirá simular una conexión punto a punto para asemejar la conexión real y ver qué capacidad mínima es necesaria para el streaming. 3.1.1 - Conexionado físico y configuración IPv4 Para establecer este escenario de laboratorio se han usado dos portátiles Acer® con un sistema operativo anfitrión Windows 10® (versión de 64 bits). El motivo por el cual se ha optado por usar este SO (Sistema Operativo) es porque los terminales normalizados 6 del ET usan Windows 10 de base. Estos dos terminales se conectan mediante la interfaz Ethernet a las interfaces del router TP-LINK® Archer MR200. De esta manera se crea un entorno de red LAN (Local Area Network) en el que los dos terminales están conectados mediante el protocolo IPv4. En la siguiente Ilustración podemos ver la topología de la red LAN. 5 Como aclaración, es pertinente decir que antes de iniciar el proyecto se pretendía usar los terminales tácticos TLB 50ip y TLX 5ip, pero no ha sido posible debido a causas ajenas a la realización del proyecto. En lugar de ello, no quedó más remedio que usar los terminales civiles THURAYA-IP. 6 Un terminal normalizado del ET tiene un uso restringido para los usuarios, no pudiendo los mismos instalar programas o conectar memorias USB que puedan poner en peligro la integridad de la información autorizada por el Ministerio de Defensa. CAPÍTULO 3 - DESARROLLO DEL PROYECTO DIFUSIÓN DE DATOS EN STREAMING 10 Ilustración 8 - Red LAN La configuración IPv4 básica de la red LAN se muestra en la siguiente tabla: Tabla 1 - Configuración IPv4 Las direcciones IP se han establecido en la configuración de red de Windows 10 de manera manual por comodidad (Aunque es posible también que el router asigne automáticamente las IP comprendidas en un rango configurable). Para acceder a la interfaz de configuración del router simplemente se ha de escribir la dirección de la puerta de enlace en cualquier explorador web, es decir, escribir 192.168.1.1. Una vez nos acreditamos como administradores, nos aparecerá el menú de configuración. En él, se ha de seleccionar en este orden “Avanzado”, “Web” y “LAN”. Una vez dentro del menú “LAN” se seleccionará la dirección IP que se desea como puerta de enlace para los terminales. Por defecto se ha dejado la que estaba, es decir, 192.168.1.1. Otra opción importante es la que se selecciona en el apartado “Modo de operación”, en la que deberemos marcar “Modo router inalámbrico” (Este router está pensado para proporcionar acceso a internet mediante una tarjeta SIM 3G/4G de una compañía telefónica. En este mismo menú aparece para ello la opción “Modo router 3G/4G”). De esta manera ambos terminales se encuentran en la misma red y será posible a través del router realizar una conexión punto a punto. En el Anexo C se muestra en profundidad las conexiones cableadas y todos los pasos para configurar la red LAN. 3.1.2 - Software Polycom PVX Una vez establecida físicamente la red y configurada, pasamos a explicar el software que se usará para realizar nuestro streaming de datos. Dicho software se denomina Polycom PVX 7 (Versión 8.0.4), y realiza videoconferencias punto a punto, es decir, desde una dirección IP hasta otra. Contiene varias opciones de configuración, desde establecer la frecuencia de la llamada y el protocolo, elegir la interfaz por la que se realizará la videoconferencia, seleccionar la cámara de video o crear un listín de contactos (Consultar el Anexo D para ver la configuración de la instalación del programa y ver las diferentes opciones que presenta el software). Lo primero que se ha de hacer una vez instalado Polycom PVX es seleccionar la interfaz por la que se va a transmitir la videollamada. Para ello, en el menú de configuración (se accede pulsando la llave inglesa que aparece arriba a la izquierda de la aplicación), vamos al apartado Red. En Conexión seleccionamos la opción “Directamente conectado a una LAN” y en “Seleccionar adaptador de red” elegimos la interfaz Ethernet, como se muestra en la Ilustración 7 Este es el software oficial que el Ejército usa para realizar videoconferencias punto a punto. CAPÍTULO 3 - DESARROLLO DEL PROYECTO DIFUSIÓN DE DATOS EN STREAMING 17 Haciendo clic en la opción “Properties” se puede ver la dirección pública que el equipo satélite asigna automáticamente al terminal conectado (Ver Ilustración 22). Por suerte, el programa Polycom PVX tiene la opción de seleccionar que la conexión a la red se hace bajo NAT (Se mostrará más adelante). De esa manera es posible establecer la conexión punto a punto entre los dos terminales. Ilustración 22 - Thuraya-IP: Menú de propiedades 13 Como se puede observar en la Ilustración anterior, la dirección IP pública proporcionada al Terminal A es la 85.115.85.86 (“Network IP Address”). Ahora ya está todo configurado de manera óptima para la transmisión de datos streaming. La razón por la que se ha decidido hacer la videoconferencia usando la interfaz USB, es debido a que usando la Ethernet el programa Polycom PVX no detecta la dirección IP pública cuando se le solicita que trabaje bajo NAT. En cambio, con la interfaz USB sí lo hace. Para el Terminal B se ha de realizar todo este mismo procedimiento paso por paso. En este caso la dirección IP pública que el segundo THURAYA-IP proporcionó al Terminal B fue la 85.115.85.88. 3.2.2 - Software Polycom PVX Ahora que los terminales satélite están operativos y funcionan, es necesario hacer algunos ajustes en la configuración de Polycom PVX que difieren del entorno de laboratorio. Para empezar hay que conectar el terminal al THURAYA-IP mediante la interfaz USB. Una vez conectado abrimos Polycom PVX y se ha de acceder a su menú de configuración. En la pestaña “Red” se debe elegir la opción del modo de conexión “Tras NAT/servidor de seguridad”. Acto seguido deseleccionar la opción “Usar adaptador predeterminado de Windows” y elegir el adaptador “Hughes USBLAN Adapter”. Donde pone “Especificar dirección IP externa” se ha de seleccionar “Detectar dirección IP automáticamente”. De esta manera el programa recibe automáticamente la dirección IP que con anterioridad se pudo observar en el menú de propiedades del terminal satélite, es decir, la dirección IP 85.115.85.86 (Ver Ilustración 23). Todo esto se resume en que se obliga al programa a que trabaje bajo NAT con la dirección IP pública que el THURAYA-IP asignó al Terminal A, y haciéndolo además usando la interfaz USB. De esta manera ya está todo preparado para realizar la videoconferencia. 13 Captura de pantalla realizada durante las pruebas. CAPÍTULO 3 - DESARROLLO DEL PROYECTO DIFUSIÓN DE DATOS EN STREAMING 18 Ilustración 23 - Polycom PVX: Configuración bajo NAT 14 3.2.3 - Wireshark y Bitmeter Comenzando con BitMeter, hay que decir que no difiere su puesta a punto respecto a las pruebas de laboratorio. En cuanto a Wireshark, la única salvedad recae en que en la primera pantalla mostrada se ha de elegir para analizar la interfaz USBPcap2 (Puede volver a observarse en la Ilustración 11), puesto que queremos analizar el tráfico que fluye por la interfaz USB. El resto de parámetros sigue siendo igual que en el entorno de pruebas de laboratorio. Ya se dispone de toda la información necesaria para establecer ambos escenarios, por lo que ahora solo queda poner en marcha las pruebas de videoconferencias, y extraer los diferentes resultados. 14 Captura de pantalla realizada durante las pruebas. CAPÍTULO 4 - ANÁLISIS DE LOS DATOS OBTENIDOS DIFUSIÓN DE DATOS EN STREAMING 19 CAPÍTULO 4 - ANÁLISIS DE LOS DATOS OBTENIDOS En este capítulo vamos a analizar los datos que se recaban de las pruebas realizadas. En primer lugar, se va a realizar el análisis de las pruebas de laboratorio, y en segundo lugar se analizarán las pruebas del escenario real. Es interesante decir que en ambos escenarios el flujo de datos durante las videollamadas es bastante constante. No se observan picos de ancho de banda demasiado exagerados, como se podrá comprobar en las pertinentes capturas de pantalla realizadas durante las pruebas. 4.1 - Pruebas realzadas en el escenario de laboratorio Con objeto de simular las conexiones satélite mediante las pruebas de laboratorio, se pretende realizar varias videoconferencias con diferentes parámetros de conexión. Básicamente, se ha elegido realizar las videoconferencias a diferentes frecuencias de llamada usando el protocolo H.323, y una última usando el protocolo SIP a 512 Kbps de frecuencia de llamada. De este modo se podrá dilucidar de entre los medios satélite elegidos, cuál será más apropiado para realizar las videoconferencias, según qué parámetros. Una vez ya tenemos todo el conjunto de software configurado, el siguiente paso es realizar cada una de las pruebas. Para ello con Wireshark (con la gráfica I/O abierta) y BitMeter en ejecución, marcamos en Polycom PVX instalado en el Terminal A, la dirección IP del Terminal B, es decir, 192.168.1.102. Se realizarán las siguientes pruebas (Especificadas en la Tabla 2), de las cuales se obtendrán diferentes datos. Tabla 2 - Pruebas de laboratorio Vamos a pasar a mostrar, una a una, las ocho pruebas descritas en la anterior tabla. Como aclaración, no se debe confundir ancho de banda con velocidad de llamada, puesto que la segunda se refiere al consumo máximo de ancho de banda que se podría hacer con esa calidad de llamada elegida, es decir, no por seleccionar por ejemplo 32 Kbps, se consumirán esos 32 Kbps de ancho de banda, como se podrá comprobar a continuación. Las siguientes Ilustraciones son todas ellas capturas de pantalla realizadas durante las pruebas. Como se podrá apreciar en la gráfica I/O proporcionada por Wireshark, vienen marcado en rojo el conjunto de todos los paquetes, en color verde los paquetes UDP, y en color azul los paquetes TCP: CAPÍTULO 4 - ANÁLISIS DE LOS DATOS OBTENIDOS DIFUSIÓN DE DATOS EN STREAMING 20 1) Prueba a 32 Kbps y protocolo H.323: Ilustración 24 - Prueba de laboratorio 1 2) Prueba a 64 Kbps y protocolo H.323: Ilustración 25 - Prueba de laboratorio 2 CAPÍTULO 4 - ANÁLISIS DE LOS DATOS OBTENIDOS DIFUSIÓN DE DATOS EN STREAMING 21 3) Prueba a 128 Kbps y protocolo H.323: Ilustración 26 - Prueba de laboratorio 3 4) Prueba a 256 Kbps y protocolo H.323: Ilustración 27 - Prueba de laboratorio 4 CAPÍTULO 4 - ANÁLISIS DE LOS DATOS OBTENIDOS DIFUSIÓN DE DATOS EN STREAMING 22 5) Prueba a 512 Kbps y protocolo H.323: Ilustración 28 - Prueba de laboratorio 5 6) Prueba a 1024 Kbps y protocolo H.323: Ilustración 29 - Prueba de laboratorio 6 CAPÍTULO 4 - ANÁLISIS DE LOS DATOS OBTENIDOS DIFUSIÓN DE DATOS EN STREAMING 23 7) Prueba a 1920 Kbps y protocolo H.323: Ilustración 30 - Prueba de laboratorio 7 8) Prueba a 512 Kbps y protocolo SIP: Ilustración 31 - Prueba de laboratorio 8 A través de las diferentes gráficas, podemos que el ancho de banda necesario para llevar a cabo la videoconferencia es siempre menor que su frecuencia de llamada respectiva. Por ejemplo, en la primera gráfica (Ilustración 24), vemos que a esta calidad de videollamada, solo se necesitan aproximadamente 4 Kbps de bajada y unos 3,5 Kbps de subida, haciendo en total unos 7,5 Kbps de tráfico de datos por la interfaz Ethernet. CAPÍTULO 4 - ANÁLISIS DE LOS DATOS OBTENIDOS DIFUSIÓN DE DATOS EN STREAMING 24 Otra curiosidad que podemos comentar, es que la suma de Kilobits por segundo de la subida y de la bajada mostrada por BitMeter coincide con lo que Wireshark muestra en su recuento total de Kbps. Por ejemplo en la Ilustración 27, que se corresponde con la videollamada a 256 Kbps, la subida y la bajada son unos 35 Kbps cada una, y Wireshark muestra un total de 70 Kbps. El consumo de bits por segundo es bastante constante, como se ha comentado ya anteriormente. Se observa además que, como se esperaba, casi la totalidad de los paquetes transmitidos durante el transcurso de la videollamada son del tipo UDP (Mostrado en color verde). Únicamente, se hace uso del envío de paquetes TCP (Mostrado en color azul) para establecer los canales de comunicación, como se ha explicado en el apartado 2.2.2. Este hecho se observa sobre todo al principio del inicio de la videollamada, pues para iniciarla se ha de abrir el canal de comunicación vía TCP inexorablemente. Respecto a la apreciación de la calidad de la videollamada, se puede decir que la transmisión streaming transcurre sin sobresaltos ni cortes molestos. Se nota que a frecuencias de llamada bajas (Sobre todo a 32 Kbps) la calidad del video es algo pobre, pero aun así, se puede mantener una videoconferencia bastante aceptable. Respecto al sonido, se nota muy poco retardo, siendo casi instantánea la reproducción del sonido, tanto en el Terminal A como en el B. En la siguiente Ilustración se puede ver que el jitter es inexistente. Jitter es el término asociado a la variación en tiempo en el envío de paquetes. Se considera aceptable un jitter de aproximadamente unos 100 milisegundos. La solución al este problema se lleva acabo implementando un buffer, en el que se almacenan los paquetes que llegan para ir entregándolos poco a poco cuando hay congestión en la red [14]. En este caso no existe este fenómeno, como podemos comprobar en la siguiente Ilustración: Ilustración 32 - Jitter en laboratorio Esta gráfica ha sido obtenida en Wireshark, haciendo clic en el menú “Telephony”. Una vez abierto este menú desplegable, se obtiene la gráfica pinchando en “RTP”, y seguidamente en “RTP Streams” 15 . Se puede observar además, que no existe retraso (Max Delta) en envío de paquetes, y la cantidad de paquetes perdidos (Lost) es mínima. Para el streaming a 512 Kbps usando el protocolo SIP, podemos observar que no existe diferencia alguna con el realizado mediante el protocolo H.323. Las gráficas mostradas en las Ilustraciones 28 y 31 así lo muestran. Aunque SIP necesita menos recursos que H.323 para enviar paquetes [15], los datos no lo muestran así, por lo que, a no ser que haya mucha 15 No olvidar que los paquetes RTP se ejecutan bajo UDP. CAPÍTULO 4 - ANÁLISIS DE LOS DATOS OBTENIDOS DIFUSIÓN DE DATOS EN STREAMING 25 congestión en la red, se utiliza casi siempre el protocolo H.323. De hecho, en Polycom PVX viene establecido así por defecto. Tras todo este pequeño análisis, hay que tener en cuenta que toda esta transmisión de datos está hecha mediante una red LAN, y por lo tanto es de esperar que los retardos sean mínimos, e incluso inapreciables. Esto no sería así en una transmisión real por satélite, puesto que la información debe viajar varias veces entre el terminal satélite y el propio satélite, que está a casi 36000 Km de distancia en su órbita geoestacionaria. Pero por otro lado, estas pruebas de laboratorio nos sirven para hacernos una idea de qué cantidad de recursos se necesitan para hacer videollamadas vía satélite, según la calidad de la videollamada. 4.2 - Pruebas realizadas en el escenario real En primer lugar, se ha de decir que pese al poco tiempo en que estuvieron disponibles los terminales THURAYA-IP, se intentó obtener la mayor cantidad de datos posibles. Se realizaron varias pruebas a varias frecuencias de llamada, siempre usando el protocolo H.323. Una vez establecido el escenario, se orientaron los terminales, obteniendo aproximadamente un 75% de señal constante. Tras tener enlace satélite con cada uno de los terminales se intentaron realizar pruebas ping entre ellos. Tanto desde la dirección IP 85.115.85.86 del Terminal A, como desde la 85.115.85.88 del Terminal B, el resultado obtenido fue de aproximadamente una media de 280 ms. Por otro lado, podemos hacer una aproximación de lo que los paquetes tardan en viajar entre cada extremo del escenario real. En este escenario, la información viaja hacia el satélite y vuelve a bajar hacia el otro terminal. Como el satélite está en una órbita geoestacionaria a 35768 Km de distancia de la superficie de la tierra, podemos establecer que, usando la fórmula de la velocidad instantánea, donde “t” es el tiempo en segundos, d es la distancia hasta la órbita en metros, y c es la velocidad de la luz en metros por segundo, el tiempo que tarda en viajar la señal desde un terminal y el satélite es [16]: 𝑡 = 𝑑 𝑐= 35768000 𝑚 3𝑥108𝑚𝑠 ⁄= 0,119 𝑠 Si la información tiene que subir hasta el satélite, y volver a bajar, entonces el retardo mínimo físico será dos veces esta cantidad de tiempo, es decir, aproximadamente unos 0,238 segundos. Para los demás terminales satélite (los tácticos CIS), a diferencia de los THURAYA-IP, la información debe pasar por una estación de anclaje situada sobre terreno nacional, por lo que el mínimo tiempo de retardo será ahora cuatro veces mayor, es decir, 0,477 segundos. Estos tiempos de retardo serían los mínimos indispensables que necesita la información para ser llevada de un extremo a otro. Aparte de estos retardos, se debería contar con los tiempos que los equipos emplean para tratar la información hasta que se presenta finalmente al usuario 16 . Por tanto, se puede aproximar el retardo total en, unos 0,25 ms (Recordar que en las pruebas ping se ha obtenido alrededor de 0,28 ms) para los terminales civiles THURAYA-IP, y unos 0,5 ms para los terminales tácticos CIS TLB 50ip y TLX 5ip. Una vez se comprobó que los terminales tenían acceso a internet, se iniciaron los programas Wireshark (con su gráfica I/O) y Polycom PVX. Al marcar desde el Terminal A la dirección IP del Terminal B (85.115.85.88) y llamar, se pudo comprobar a los pocos segundos que en el terminal B aparecía lo que se muestra en la siguiente Ilustración: 16 Hoy en día, los tiempos de procesamiento de las computadoras modernas no exceden de unos pocos milisegundos, por lo que no supone una cantidad excesiva en el retardo total para el análisis de los datos obtenidos. CAPÍTULO 4 - ANÁLISIS DE LOS DATOS OBTENIDOS DIFUSIÓN DE DATOS EN STREAMING 26 Ilustración 33 - Llamada en escenario real Una vez aceptada la llamada, se comprobó que la gráfica I/O de Wireshark empezaba a mostrar el envío de paquetes al instante. En la siguiente ilustración, podemos comprobar el ancho de banda consumido durante el establecimiento de la primera llamada que se realizó a 32 Kbps: Ilustración 34 - Llamada real a 32 Kbps Se puede observar que efectivamente la gráfica muestra todo lo que entra y sale por la interfaz USB (USBPcap2). Por comodidad de lectura la gráfica muestra el total de todos los paquetes. Los paquetes UDP yTCP se comportaron exactamente igual que durante las pruebas de laboratorio. Como dato curioso, se observa que el consumo mas o menos regular de paquetes está entorno a unos 10 Kbps, un poco más que en las pruebas de laboratorio. Además, en este caso, el transcurso de la gráfica es más irregular que en las pruebas de laboratorio. Los tiempos de procesamiento de la información y el retardo de la señal, juegan un papel importante a la hora de transmitir datos en streaming. Por ello, la calidad del video fue peor, y también la recepción del audio, que aumentó respecto a las pruebas de laboratorio. La transmisión de la videollamada era algo incómoda, pero aun así, se podía mantener una conversación vía satélite. No ocurrió lo mismo cuando se quiso probar videollamadas a frecuencias de llamada más elevadas. El retardo en la recepción del video y el sonido hacían impracticables las videoconferencias. Incluso el establecimiento de llamada tardó bastantes segundos en aparecer en el otro terminal. Evidentemente, el terminal estaba configurado para transmitir a un máximo de 16 Kbps, por lo que, excepto la videoconferencia realizada a 32 Kbps de frecuencia de llamada, el resto resultó ser un conjunto de videoconferencias totalmente impracticables. ANEXOS DIFUSIÓN DE DATOS EN STREAMING 33 Tabla 6 - Diagrama de flujo streaming ANEXOS DIFUSIÓN DE DATOS EN STREAMING 34 Anexo C - Configuración de la red LAN En este anexo, se va a proceder a explicar cómo se realiza tanto el conexionado físico, como la configuración de la red LAN, para establecer por completo el entorno de pruebas de laboratorio. Conexionado físico En primer lugar, una vez conectado el router TP-LINK Archer MR200 a la corriente eléctrica y encendido, se deben conectar los cables Ethernet Cat-5e 17 entre el router y los terminales. En la siguientes Ilustraciones se puede ver la parte trasera del router, en el que conectaremos cada cable Ethernet a un puerto LAN, los cables conectados y la interfaz Ethernet de la tarjeta de red de un Terminal, en la que conectaremos los otros extremos libres de los respectivos cables. Ilustración 35 - TP-LINK: Interfaces Ilustración 36 - Interfaz Ethernet de un terminal Una vez está todo conectado, debería quedar como ya se expuso en el Capítulo 3, apartado 3.1.1 (Ver Ilustración 8). Configuración en Windows 10 El siguiente paso consiste en iniciar los terminales y abrir la configuración de red de Windows 10. Para ello, desde el “Panel de control”, pinchamos en “Centro de redes y recursos compartidos”, el cual nos abrirá una ventana en la que se deberá hacer clic en “Cambiar configuración del adaptador”: 17 Permiten una velocidad de transferencia de hasta 100 Mbps y una frecuencia de transmisión de 100 Mhz [18]. ANEXOS DIFUSIÓN DE DATOS EN STREAMING 35 Ilustración 37 - Interfaces de Windows 10 Pulsamos botón derecho sobre la interfaz Ethernet y a continuación “Propiedades”. Ahora buscamos el protocolo TCP/IPv4: Ilustración 38 - Propiedades de Ethernet Seleccionamos el protocolo TCP/IPv4 y pulsamos “Propiedades”, como aparece en la Ilustración 38. Aparecerá una nueva ventana en la que configuraremos manualmente 18 la interfaz Ethernet, como se muestra en la siguiente Ilustración: 18 Se ha decidido hacer la configuración manual por comodidad de trabajar siempre con las mismas direcciones IP, aunque es posible también hacerlo mediante la asignación automática de direcciones IP mediante el router por DHCP. ANEXOS DIFUSIÓN DE DATOS EN STREAMING 36 Ilustración 39 - Propiedades de TCP/IPv4 Para el otro terminal, se debe hacer lo mismo, con la salvedad de darle la dirección IP 192.168.1.102. De esta manera, queda realizada la configuración de las interfaces Ethernet en Windows 10. Configuración en el router Para configurar el router, abrimos un explorador web en Windows 10 e introducimos en su barra de direcciones la dirección IP por defecto del router, es decir, 192.168.1.1. El explorador nos llevará a la interfaz web del router, en el que deberemos introducir el usuario y la contraseña que se sabrá previamente 19 . En la siguiente Ilustración se muestra la pantalla de acreditación del router: Ilustración 40 - TP-LINK: Pantalla de acreditación Una vez acreditados, se mostrará el menú principal de configuración del router, en el que podremos acceder a las diferentes configuraciones. Se puede observar en la siguiente Ilustración como el router detecta ya los dos terminales conectados mediante las interfaces Ethernet, cada una con su dirección IP estática: 19 Si no se ha establecido usuario y contraseña, el router tiene siempre la posibilidad de reiniciarse de fábrica. En ese caso, el usuario y la contraseña serán “admin” y “admin”. ANEXOS DIFUSIÓN DE DATOS EN STREAMING 37 Ilustración 41 - TP-LINK: Menú principal Por defecto, el router viene configurado para tener como dirección IP la 192.168.1.1, de hecho, así se ha accedido a él. Si se desease cambiar la dirección IP del mismo, o asignar por DHCP un rango de direcciones, deberemos hacer clic en la pestaña superior que dice “Avanzado”. Tras ello, hacer clic “Internet” en el panel lateral y luego en “Configuración LAN” (Ver Ilustración 42). Puede verse además, que el modo DHCP está habilitado, para el caso en que se quiera dejar que el router asigne las direcciones IP de los terminales conectados a él por cualquier interfaz de manera automática. Por comodidad, se ha dejado la configuración del router tal cual por defecto. Ilustración 42 - TP-LINK: Configuración LAN Ahora, ya está todo preparado y configurado para que la red LAN funcione correctamente. Para comprobarlo, puede hacerse un comando ping 20 mediante la consola de comandos que Windows 10 tiene integrada. Se accede a ella pulsando la tecla “Windows + R” y escribiendo en la ventana que aparece “cmd”. Una vez abierta, se escribe el comando que se muestra en la siguiente Ilustración, en la que se puede ver como se hace ping desde un terminal a otro. Como se puede apreciar la respuesta es satisfactoria, y el enlace entre terminales está establecido. 20 Ping, es un comando que sirve para ver si existe conexión en una red. Se envían paquetes ICMP desde un terminal a otro para comprobar si responde o no, es decir, si el enlace entre dos terminales está establecido. ANEXOS DIFUSIÓN DE DATOS EN STREAMING 38 Ilustración 43 - Comando ping ANEXOS DIFUSIÓN DE DATOS EN STREAMING 39 Anexo D - Configuración de Polycom PVX En este anexo, se va a proceder a explicar detalladamente toda la configuración y opciones de las que dispone el software Polycom PVX (Versión 8.0.4). Este software, actualmente es soportado por la mayoría de las computadoras, puesto que no requiere unos recursos mínimos exigentes [19]. Una vez ejecutamos el instalador del programa, la instalación transcurre sin que el usuario deba configurar nada. Una vez instalado el software, ejecutamos el icono que aparece en el escritorio “Polycom PVX”. Se abrirá entonces la pantalla principal de este programa: Ilustración 44 - Polycom PVX: Pantalla principal En la Ilustración anterior, puede verse en la parte de abajo las opciones “VideoMail” y “Controles de llamada”. La primera sirve para grabar un video y enviarlo por email. En la segunda, podemos establecer la cámara a usar por el programa y también usar un teclado interactivo para marcar números o direcciones guardadas. Desplegando “Controles de llamada”, se puede establecer la cámara como sigue a continuación: ANEXOS DIFUSIÓN DE DATOS EN STREAMING 40 Ilustración 45 - Polycom PVX: Selección de cámara Las diferentes opciones de la pantalla principal no presentan mayor dificultad. En el panel lateral derecho, hay un botón para “Llamar”, otro para “Colgar”, un “Directorio” para almacenar contactos y una opción de “Marcación rápida” para llamar a contactos recientes. En la parte superior a la derecha está la barra de direcciones, en la que se introduce manualmente las direcciones IP a marcar para establecer una videollamada. Arriba a la izquierda, podemos ver tres botones redondos. De izquierda a derecha están: El botón “?” para acceder a la ayuda del software, el botón “i” para activar el programa mediante clave y actualizarlo en línea, y el botón de la llave inglesa, en el que accederemos al menú principal de configuración. En la siguiente Ilustración se muestra este menú: ANEXOS DIFUSIÓN DE DATOS EN STREAMING 41 Ilustración 46 - Polycom PVX: Configuración general En la el submenú “Rendimiento”, podemos elegir que recursos reservará el SO para trabajar con Polycom PVX, recomendándose que se asignen todos los recursos posibles para la propia aplicación: Ilustración 47 - Polycom PVX: Rendimiento En el menú “Video”, podemos establecer de nuevo la cámara con que trabajará el software para realizar las videollamadas: ANEXOS DIFUSIÓN DE DATOS EN STREAMING 42 Ilustración 48 - Polycom PVX: Configuración de video El menú más importante de este software, es sin duda el de “Red”. En el deberemos decirle al programa con que red de datos vamos a trabajar, pudiendo elegir entre: Red LAN, trabajar bajo servidor NAT o a través de VPN (Virtual Private Network). Se pueden ver estos modos de trabajo en las siguientes tres Ilustraciones: Ilustración 49 - Polycom PVX: Red LAN