Trabajo Fin De Grado Grado Ingeniería De Las Tecnologías De Telecomunicación

Trabajo Fin de Grado Grado Ingeniería de las Tecnologías de Telecomunicación

Evaluación de calidad de la API WebRTC

Autor: Alejandro Alhama Riego Tutor: Rafael Estepa Alonso

Equation Chapter 1 Section 1

Dep. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2017

Proyecto Fin de Grado Grado Ingeniería de las Tecnologías de Telecomunicación

Evaluación de calidad de la API WebRTC

Autor: Alejandro Alhama Riego

Tutor: Rafael Estepa Alonso Profesor titular

Dep. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2017

iii

Trabajo Fin de Grado: Evaluación de calidad de la API WebRTC

Autor: Alejandro Alhama Riego

Tutor: Rafael Estepa Alonso

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2017

El Secretario del Tribunal

A mi familia A mis amigos

vii

Agradecimientos

A mi familia, por apoyarme durante tanto tiempo y animarme con cada pequeña victoria que iba consiguiendo, asi como en los peores momentos de desaliento, enseñándome que por muchos problemas que se presenten, la perserverancia y la voluntad conseguirán llevar a cabo cualquier proyecto. Pero por encima de todo, por su amor incondicional. A mis amigos, con los que he compartido todos estos últimos años, sufriendo con cada examen y disfrutando de cada reunión improvisada en el piso que tanta gente ha acogido. Especialmente a mis compañeros de piso, a los cuales podía recurrir tanto para quejarme de todo como para divertirme, y también muy especialmente a mi querida amiga y compañera, que siempre ha estado conmigo animándome a seguir y brindándome todo su cariño. A mis maestros, por todos estos años de formación durante los cuales han conseguido transmitirme la pasión por el conocimiento, que espero no perder nunca. Gracias especialmente al departamento de telemática, tanto como por las lecciones impartidas como por la oportunidad de disponer de un laboratorio donde llevar a cabo las pruebas. Gracias dentro de este departamento a mi tutor, por toda su dedicación y por las facilidades que me ha proporcionado durante la realización de este proyecto.

Alejandro Alhama Riego Sevilla, 2017

Resumen

En los últimos años, las comunicaciones se han transformando de forma vertiginosa, portando cada vez más al entorno web, debido a esta tendencia, se considera necesario el estudio de las nuevas tecnologías que se nos ofrecen, prestando especial atención a la calidad de servicio. Siempre han existido gran cantidad de programas en nuestros ordenadores destinados a la comunicación entre los usuarios, tanto gratuitos como de pago, muchos de estos programas han decidido ofrecer sus servicios también en nuestro navegador web, ofreciéndonos en el mismo un entorno cada vez más unificado. La obtención de los medios y la señalización para realizar dichas comunicaciones por parte de los programas siempre ha conllevado un problema extra para los desarrolladores en el entorno web, pero, la tecnología WebRTC nos permite solventar dichos problemas con facilidad. El objetivo de este documento es el estudio de la tecnología WebRTC y la realización de pruebas que nos permitan, de forma objetiva, evaluar la calidad de servicio que nos ofrece.

Abstract

In recent years, our communication has greatly evolved, leading to the web environment, due to this trend, it is necessary to study these recent technologies, paying special attention to its quality of service. A lot of different programs have always existed for user communication, commercial or free, many of them have chosen to also deliver their services to our browsers, giving us a unified environment. Media devices and signaling have been a struggle for developers in web environment, but WebRTC allows us to easily solve those problems. The purpose of this paper is the development of a study in WebRTC’s technology and to test objectively its quality of service.

xiii

Índice

Agradecimientos ix Resumen xi Abstract xiii Índice xiv Índice de Tablas xvi Índice de Figuras xviii 1 Introducción y objetivos 1 1.1 Introducción 1 1.2 Objetivos 3 2 WebRTC 5 2.1 ¿Que es WebRTC? 5 2.1.1 Historia 5 2.1.2 Actualidad 7 2.2 Casos de uso y alternativas. 8 2.2.1 Casos de uso 9 2.2.2 Alternativas al uso de WebRTC 15 2.3 WebRTC 19 2.3.1 Explicaciones previas 19 2.3.2 Descripción y funcionamiento 25 3 Implementación del escenario WebRTC 35 3.1 Requisitos y escenario 35 3.1.1 Requisitos 35 3.1.2 Escenario 41 3.2 Alternativas de implementación 41 3.2.1 Manera de utilizar la tecnología WebRTC 42 3.2.2 Servidor web que utilizar 43 3.2.3 Forma de señalización que implementar 44

3.2.4 Alimentación de audio a la aplicación 45 3.3 Implementación propuesta 46 4 Pruebas y resultados 49 4.1 Batería de pruebas 49 4.1.1 Códecs 49 4.1.2 Medidas de QoS 50 4.1.3 Audios utilizados 53 4.2 Obtención de resultados 53 4.2.1 Software de automatización 54 4.2.2 Preparación de audios y ejecución de análisis. 55 4.3 Estadísticas obtenidas 56 4.3.1 P.563 56 4.3.2 P.862 57 5 Conclusiones y líneas de avance 61 5.1 Conclusiones 61 5.2 Líneas de avance 62 Referencias 65 ANEXO A: CONFIGURACIÓN Y USO DEL ENTORNO 71 Glosario 79

ÍNDICE DE TABLAS

Tabla 2–1. Ventajas e Inconvenientes de WebRTC 25 Tabla 2–2. Websocket Vs DataChannel 31 Tabla 3–1. RQF-00 Mostrar página de inicio y bienvenida 35 Tabla 3–2. RQF-01 Registrar usuario 36 Tabla 3–3. RQF-02 Redirigir al usuario a la sala de llamada 36 Tabla 3–4. RQF-03 Establecer un socket de conexión 36 Tabla 3–5. RQF-04 Realizar llamada 37 Tabla 3–6. RQF-05 Autoaceptación llamada 37 Tabla 3–7. RQF-06 Selección de códec 37 Tabla 3–8. RQF-07 Finalizar la llamada 38 Tabla 3–9. RQF-08 Carga de audios 38 Tabla 3–10. RQNF-00 Interfaz de usuario simple e intuitiva 39 Tabla 3–11. RQNF-01 Interfaz de usuario responsiva 39 Tabla 3–12. RQNF-02 Ejecución correcta de la aplicación en varios navegadores 39 Tabla 3–13. RQNF-03Múltiples sesiones concurrentes 40 Tabla 3–14. RQNF-04 Seguridad en las comunicaciones 40 Tabla 3–15. RQNF-05 Pruebas de software 40 Tabla 3–16. Opciones de señalización para WebRTC [78] 44 Tabla 4–1. Escala MOS para calidad de audio 50 Tabla 4–2. Resultados para cada audio 59

xvii

ÍNDICE DE FIGURAS

Figura 1-1. Cliente-Servidor HTTP. 1 Figura 1-2. RTC en el navegador. 2 Figura 2.1 Primera Implementación por parte de Ericsson 6 Figura 2.2 Crecimiento en el uso por sectores [11] 7 Figura 2.3 Twilio 9 Figura 2.4 Regroup Therapy 10 Figura 2.5 BananaBread 11 Figura 2.6 WebRTC Snake 12 Figura 2.7 XirSys 13 Figura 2.8 Solaborate 14 Figura 2.9 Seguimiento de cabezas Skype 16 Figura 2.10 Códecs soportados por Flash Player 17 Figura 2.11 Pila de protocolos de WebRTC para datos y señalización 19 Figura 2.12 Arquitectura WebRTC 21 Figura 2.13 Escenario real en Internet con STUN y TURN 23 Figura 2.14 Paquetes RTP y SRTP 24 Figura 2.15 Arquitectura de WebRTC 26 Figura 2.16 Interacciones del objeto MediaStream 28 Figura 2.17 Interacciones del objeto RTCPeerConnection 29 Figura 2.18 Envío de audio y video mediante SRTP sobre UDP 30 Figura 2.19 Realización de llamada WebRTC 32 Figura 2.20 Recepción de llamada WebRTC 33 Figura 2.21 Cierre de llamada WebRTC 33 Figura 2.22 Llamada completa WebRTC 34 Figura 3.1 Escenario real a simular 41 Figura 3.2 Talky.io 42 Figura 3.3 Cuota de mercado de diferentes servidores web 43 Figura 3.4 Estructura con cables de audio virtuales 45 Figura 3.5 Escenario de laboratorio planteado 47 Figura 4.1 Diferencias entre métodos de análisis 52 Figura 4.2 Primera conversación mostrada con Audacity 53 Figura 4.3 Pseudocódigo de automatización 54 Figura 4.4 Ejemplo de notas obtenidas con P.563 para un audio 56 Figura 4.5 Notas obtenidas con P.862 y códec OPUS 57 Figura 4.6 Notas obtenidas con P.862 y códec PCMA 58 Figura A.1 Configuración IP señalización 71

Figura A.2 Inicio del Servidor 71 Figura A.3 Página registro 72 Figura A.4 Página de llamada 72 Figura A.5 Codecs disponibles 73 Figura A.6 Codecs soportados 73 Figura A.7 Instalacion Python 3 74 Figura A.8 Instalacion Selenium 74 Figura A.9 Cables virtuales 75 Figura A.10 Pseudocódigo de automatización 76 Figura A.11 Cambio IP scripts 77 Figura A.11 Cambio IP scripts 77

xix

1 INTRODUCCIÓN Y OBJETIVOS

Through our memories, future generations will see that we can overcome any fear! -Zidane Tribal -

1.1 Introducción

as comunicaciones en tiempo real o Real Time Communication (RTC) se han convertido en uno de los mayores retos para la web, las RTC deberían ser tan sencillas y comunes como la introducción de texto L en aplicaciones web [1]. Sin ellas, estamos limitados en nuestra capacidad de crear nuevas formas de interacción. Hasta ahora las RTC han sido complejas y por lo general, corporativas, necesitando de tecnologías de audio y video licenciadas o desarrolladas personalmente. Además, la integración en servicios existentes ha sido difícil, especialmente en la web. Aun con estas dificultades, muchos servicios web utilizan RTC en la actualidad, pero, necesitan descargas, aplicaciones nativas o plugins para su correcto funcionamiento, como podría ser el caso de Skype, estas necesidades, además, tienden a ser problemáticas y molestas, son difíciles de desplegar, probar y mantener. La arquitectura web clásica está basada en el paradigma Cliente-Servidor, donde los navegadores mandan una petición HTTP (Hypertext Transfer Protocol) al servidor web, que responde con la información solicitada.

Figura 1-1. Cliente-Servidor HTTP.

2 Introducción y objetivos

En el escenario de una aplicación web, el servidor puede contener código JavaScript en la página HTML que manda como respuesta al cliente. Este código puede interactuar con los navegadores mediante APIs JavaScript estándar y con los usuarios mediante la interfaz. La utilización de JavaScript en nuestras aplicaciones web nos añade el componente dinámico que no se encuentra en la conjunción HTML + CSS, este lenguaje de alto nivel se ejecuta en los navegadores del usuario, en vez de hacerlo en nuestro servidor, de esta forma, por ejemplo, las validaciones que se realicen en los datos que nos envía el usuario, serán realizadas sin mandarse previamente al servidor, evitando el uso de recursos para las mismas y el envío de código malicioso a nuestro servidor. Estas, entre otras razones, han convertido a JavaScript en una pieza clave para el desarrollo de aplicaciones web, además, debido a su gran potencia y popularidad como lenguaje de scripting, su uso se ha extendido fuera de los navegadores [2], siendo utilizado en proyectos tan importantes como MongoDB o NodeJS, además de ser soportado, por ejemplo, en documentos PDF de Adobe. En cuanto a las RTC, la potencia de JavaScript ha permitido el desarrollo del mayor proyecto de código abierto para comunicaciones en tiempo real basado en navegadores: WebRTC. WebRTC es un nuevo estándar que permite a los navegadores comunicarse utilizando una arquitectura peer-to- peer, su tecnología permite el envío de audio, video y datos entre navegadores HTML 5. Esta es una gran evolución en el mundo de las aplicaciones web, ya que permite, por primera vez, desarrollar aplicaciones multimedia en tiempo real sin la necesidad de plugins propietarios. [3]

Figura 1-2. RTC en el navegador. WebRTC permite aunar dos campos históricamente separados, por una parte, las telecomunicaciones, y por otra parte el desarrollo web, ya que, aquellos que no vienen del mundo de las telecomunicaciones, pueden encontrar sobrecogedor el mundo de la señalización, y, por otra parte, aquellos que no tienen tanto manejo en los últimos avances de la programación web pueden encontrar APIs sencillas para trabajar.

1.2 Objetivos

Esta nueva tecnología resulta muy prometedora para todos, desde desarrolladores individuales que quieran introducir las RTC en sus proyectos hasta grandes compañías que quieran portar sus comunicaciones de una solución comercial a una solución basada en software libre desarrollada por sus equipos. Aunque esta tecnología tenga muchas posibilidades, para garantizar el correcto funcionamiento de la RTC, es necesario el cumplimiento de unos niveles mínimos de calidad. Esta calidad puede ser medida de varias formas, una de ellas mediante la medida de las pérdidas y los diferentes retardos que experimentan los paquetes durante la comunicación, ya sea introducidos por la red o debido al procesamiento de los paquetes en los extremos; otra forma de medirlo sería mediante la evaluación de la percepción de voz del audio recibido por los extremos [4]. Esta última medida de calidad es en la que se enfocará este proyecto, evaluando WebRTC en términos perceptibles. Esta medida se aplica como un estándar de la industria para la medida objetiva de la calidad de llamadas de voz, siendo utilizada por fabricantes móviles, vendedores de equipos de red y operadores de telefonía. Para la realización del proyecto se plantean ciertos puntos a seguir: 1) Análisis de las distintas posibilidades para la utilización de WebRTC 2) Análisis de las distintas medidas de calidad por percepción de la calidad existentes. 3) Selección de audios a utilizar conforme a exigencias de estándares 4) Selección de códecs a estudiar 5) Desarrollo del entorno web para la realización de pruebas 6) Planteamiento de los escenarios de prueba a utilizar 7) Configuración de los escenarios y medidas de calidad 8) Realización de pruebas experimentales 9) Análisis de los resultados obtenidos 10) Conclusiones y posibles líneas de mejora.

4 Introducción y objetivos

2 WEBRTC

Fear tends to come from ignorance. Once I knew what the problem was, it was just a problem, nothing to fear. - Patrick Rothfuss -

l objetivo de este documento es conseguir que el lector se familiarice de forma rápida y efectiva con la tecnología WebRTC y con de las capacidades del mismo, desde un punto de vista corporativo y desde las E consideraciones de calidad de servicio. Para ello será necesario plantear distintas cuestiones, desde cuales fueron las motivaciones que llevaron a la creación de esta tecnología hasta la situación actual de la misma. Este capítulo se dedicará al análisis en profundidad de WebRTC, como fue creado, cuáles son sus componentes, sus aplicaciones a nivel comercial y las alternativas existentes en el mercado actual. De la misma forma, para su mejor comprensión, también será necesario definir aspectos fundamentales relativos a calidad de servicio y señalización, así como los protocolos que posibilitan dicha tecnología.

2.1 ¿Que es WebRTC?

Como ya se ha dicho anteriormente, WebRTC, también conocido como Web Real-Time Communications, es un proyecto de código abierto que permite comunicaciones en tiempo real sin plugins a través de una API JavaScript. Gracias a su colección de protocolos de comunicación es posible que los navegadores web soliciten información desde servidores backend además de información en tiempo real de los navegadores de otros usuarios. Esto permite desarrollar aplicaciones para conferencias de video, transferencia de ficheros, chat entre usuarios o compartir el escritorio sin la necesidad de plugins internos o externos.

2.1.1 Historia

La historia de WebRTC va vinculada a Google, su mayor impulsor, la aplicación de video de Gmail se popularizó en 2008, y en 2011 Google nos presentó Hangouts, que utiliza el servicio Google Talk. El año anterior, Google compró Global IP Solutions, también conocida como GIPS, una empresa estadounidense que desarrollaba software para el procesamiento a tiempo real de video y audio en redes IP, consiguiendo una gran cuota del mercado VoIP, GIPS desarrolló también los códecs de audio iLBC e iSAC [5], así como tecnología para la cancelación de ecos, tecnología que posteriormente fue necesaria para el desarrollo de las RTC. [6] También en 2010, Google finalizó la compra de On2 Technologies, una compañía dedicada de desarrollar códecs de video, siendo el último de ellos VP8, esta empresa creo los códecs como una versión gratuita de los códecs de la serie H.26X, que habían sido estandarizados, patentados y ampliamente usados. Dichos códecs se abrieron al mundo como software libre bajo el nombre de WebM, con la idea de sustituir H.264 en los videos web, reduciendo el gasto en patentes para todo el mundo y en especial Google en sí misma. [7]

6 WebRTC

Tras dicha compra Google liberó todas las tecnologías desarrolladas por GIPS y On2, tras ello se comprometió con los organismos de normalización del IETF y W3C para asegurar el consenso de la industria para estos nuevos estándares. De vuelta a 2011, en enero, Ericsson presentó la que sería la primera implementación del futuro WebRTC [8], en la misma ya se hacía referencia al streaming peer-to-peer sin la necesidad de servidores de retransmisión. En su presentación se utiliza una API llamada ConnectionPeer, la misma está basada en el trabajo preliminar de la Web Hypertext Application Technology Working Group (WHATWG), una comunidad de personas interesadas en la evolución de HTML y sus tecnologías relacionadas. [9]

Figura 2.1 Primera Implementación por parte de Ericsson

Tras ello en mayo de 2011, Google presentó el proyecto de código abierto para comunicación en tiempo real para navegadores conocido como WebRTC [10]. Los principios rectores del proyecto WebRTC presentan que sus APIs deberían ser de código abierto, gratuitos y estandarizados, incorporados en los navegadores web y más eficientes que las tecnologías existentes. A esta presentación le siguió una gran cantidad de trabajo por parte de Google para la evolución de este proyecto, así como para conseguir la estandarización de los protocolos en la IETF [11] y de las APIs para navegador en el W3C [12]. Dentro del W3C se creó el Web Real-Time Communications Working Group, para continuar con la evolución de esta tecnología, desde este grupo se espera una gran evolución en base a: a) Resultado del trabajo conjunto con el grupo RTCWEB del IETF para definir el set de protocolos que definirá las RTC en los navegadores. b) Los problemas de privacidad que aparezcan al exponer las capacidades y streams locales. c) Discusiones técnicas dentro del propio grupo. d) Conocimiento ganado gracias a la experimentación previa. e) Feedback por parte de otros grupos de trabajo. [13] [14]

2.1.2 Actualidad

Después de 6 años desde la primera implementación de WebRTC y de su presentación al público, la adopción por parte del mercado, los organismos de estandarización y de los desarrolladores de navegadores web ha sido razonablemente buena: Más de 1100 proveedores y proyectos están utilizando WebRTC en enero de 2017, siendo en 2014 más de 300 e incrementándose en más de 20 de media mensual hasta la actualidad. Siendo mayormente utilizada por empresas de sectores especializados, siendo el más importante el sector sanitario, seguido del sector educacional, pero siendo también utilizados en otros sectores como el de los videojuegos. Otro de los servicios que más rápidamente se han extendido ha sido el de la externalización, debido a la carencia de desarrolladores expertos en WebRTC [15]

Figura 2.2 Crecimiento en el uso por sectores [11]

Algunas grandes empresas han adaptado rápidamente WebRTC dentro de sus servicios, como WhatsApp, Facebook Messenger, appear.in y plataformas como TokBox o Twilio, cimentando la confianza por parte del sector. Aun con esto, el crecimiento no ha sido todo lo rápido que se esperaba, ya que todavía existen problemas de interoperabilidad entre distintos navegadores, además de los temores con respecto a seguridad de esta tecnología. [16] Con respecto a la inserción por parte de WebRTC en los navegadores su adaptación ha sido de forma gradual, pero en la actualidad ya es soportada por la mayoría de grandes navegadores: En PC es posible a partir de las siguientes versiones de navegador: Microsoft Edge 12, Google Chrome 28, Mozilla Firefox 22, por parte de Apple, el pasado 7 de Junio de 2017 se ha anunciado que WebRTC será incorporado en la última versión de Safari que será lanzada en Septiembre de 2017. También es soportado en Android desde las siguientes versiones: Google Chrome 28, Mozilla Firefox 24 y Opera Mobile 12. Además de ser soportado en otros SO propietarios como Chrome OS o Firefox OS. [14] Es necesario especificar que, aunque este soportado, no implica que todas las funciones y APIs del mismo funcionen. Cabe destacar que no existe ningún tipo de soporte planeado para Internet Explorer en la actualidad. [17]

8 WebRTC

Con respecto a la estandarización de WebRTC también se han realizado considerables avances, por parte del IETF se han realizado gran cantidad de documentos, llegando a redactarse hasta ahora 5 RFCs: • RFC 7478 Web Real-Time Communication Use Cases and Requirements: Esta RFC publicada en marzo de 2015, fue el primer documento en convertirse en una RFC, se trata de una RFC de propósito informativo para describir casos de uso para las RTC en los navegadores web, y, a partir de los mismos, define los requisitos con respecto a funcionalidades de los navegadores. [18] • RFC 7675 Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness: Dicho documento, de octubre de 2015, y propuesto como estándar define un mecanismo para evitar ataques a los usuarios, asegurando que el usuario remoto está dispuesto a recibir tráfico, dando un nuevo uso a las utilidades STUN. [19] • RFC 7742 WebRTC Video Processing and Codec Requirements: Esta propuesta de estándar, de marzo de 2016, esta especificación proporciona los requisitos y consideraciones para que las aplicaciones WebRTC envíen y reciban video mediante redes, especificando también los requisitos para el procesamiento de dicho video. [20] • RFC 7874 WebRTC Audio Codec and Processing Requirements: Esta propuesta de estándar, publicada en mayo de 2016, define los requisitos para el procesamiento de audio, así como, los requisitos de códecs mínimos que se deben satisfacer en los puntos terminales de WebRTC. [21] • RFC 7875 Additional WebRTC Audio Codecs for Interoperability: Se trata de un documento de propósito informativo publicado en mayo de 2016, este documento proporciona algunas directrices con respecto a los códecs que deberían ser utilizados para abordar los casos de usos más relevantes enfocándose en la interoperabilidad. [22] Por parte del W3C, se han publicado muchos documentos, aunque por ahora solamente uno de ellos se encuentra en el nivel de madurez de Candidate Recommendation, un documento ampliamente revisado y cumpliendo los requisitos técnicos del grupo de trabajo, siendo este documento “Media Capture and Streams” definiendo las APIs para la captura de medios. Por parte del WebRTC Working Group continua el trabajo con gran cantidad de documentos Working Drafts. [23] Con todo esto, las previsiones para WebRTC son buenas, tras 5 años su tecnología ha madurado enormemente y su despliegue en términos corporativos y de inserción son altos, pero esta es, aún, una tecnología joven, todavía debe pasar tiempo para que desde la industria se creen nuevos casos de uso para la tecnología, así como para que sea complemente adoptada en nuestros navegadores. Existe una gran cantidad de trabajo por delante, y para ello serán necesarios una gran cantidad de expertos en RTC, por lo menos durante la próxima década. Expertos que conseguirán llevar esta tecnología a su siguiente grado de madurez, solventando los problemas actuales y aquellos que se presentarán.

2.2 Casos de uso y alternativas.

Ya se ha presentado la historia de WebRTC y su evolución hasta la actualidad, con esto, abordaremos las diferentes aplicaciones en las que WebRTC, y como esta tecnología puede ayudar a solventar problemas de diferentes sectores. Se analizarán varios de los posibles casos de uso, en la mayoría de ellos comentaremos una o varias empresas que ya aprovechan hoy en día WebRTC, ya sea como base de su negocio o como complemento de uno o varios de sus productos. Una vez que ya se presenten estos casos de uso y como se han llevado a un entorno productivo, se analizarán las diferentes alternativas que se ofrecen de forma comercial o gratuita al uso de esta tecnología en la actualidad, así como cuales son las ventajas y desventajas de estos servicios con respecto a nuestra alternativa de código abierto.

2.2.1 Casos de uso

2.2.1.1 Conferencia de Video Este mercado lleva existiendo por más de una década. Su principal objetivo siempre han sido las conferencias de video empresariales, vendidas a compañías multinacionales con grandes presupuestos de IT. En los últimos años dichas compañías han pasado a ofrecer conferencias de video basadas en la nube, intentando cambiar el gasto de IT de un enfoque CAPEX (Capital Expenditure) a OPEX (Operating Expenditure), pasando a vender los servicios de video. WebRTC se ha adoptado dentro de esta tendencia y puede ser considerada un acelerador de la misma. La mayoría de los proveedores WebRTC han intentado introducirse en este mercado, siendo su mejor baza la reducción en el coste final al usuario, debido al bajo coste de desarrollo y operación que esta tecnología ofrece. Con respecto a este caso de uso existen una gran cantidad de proveedores de servicios que han cosechado gran éxito, se hablará de dos de ellos: Twilio y Veeting Rooms. • Twilio:

Figura 2.3 Twilio

Esta empresa con sede en San Francisco y fundada en 2007 ofrece un servicio CPaaS (Communication Platform as Service). Entre los servicios que ofrece se encuentra la integración de llamadas de voz en las plataformas web de sus clientes mediante el uso de WebRTC soportada gracias a su infraestructura de baja latencia en la nube. Alguno de los clientes que utilizan este servicio de Twilio serían WIX o Datalot, siendo tarificados mediante el formato de pay-as-you-go. [24] • Veeting Rooms: Esta startup sueca, ofrece un servicio de integración directa de WebRTC que permite a múltiples participantes atender a una conferencia de video. La diferencia de esta empresa con el resto de sus competidores es el énfasis en la privacidad de los datos, estando todos sus componentes en Suiza. En esa privacidad radica su éxito ya que este este nicho de mercado ha sido ignorado por los grandes proveedores de conferencias de video en la nube. Algunos de sus clientes son Domino’s Pizza o Clintara ofreciendo a los mismos posibilidad de pago mediante suscripción o con pay-as-you-go. [25]

10 WebRTC

2.2.1.2 Telemedicina Para WebRTC la telemedicina es un mercado interesante. El verdadero desafío de este sector queda en lidiar con las diferentes regulaciones y responsabilidades. Por ejemplo, en los EEUU, los proveedores de este servicio tienen que asegurar el cumplimiento de HIPAA, este requisito legal incluye, entre algunos requisitos, la privacidad de los pacientes. WebRTC está posicionada de forma única como una tecnología muy adecuada por varias razones: ▪ WebRTC es seguro y privado por defecto, mientras que otros sistemas requieren de trabajo adicional para securizarse. ▪ WebRTC es adecuado para la incorporación en los procesos de negocio, requiriéndose enormemente en la telemedicina, desde un punto de vista regulador. [26] Todavía existe una gran cantidad de mercado por explotar en este sector, ya que las exigencias regulatorias en el mismo pueden disuadir a los proveedores de entrar en este mercado, pero dado el volumen de negocio que este sector ofrece es inevitable el acercamiento por parte de los proveedores. Algunas de las empresas que ya se han introducido en este sector podrían ser Regroup Therapy y TruClinic, ayudadas por WebRTC para el cumplimiento de HIPAA: • Regroup Therapy

Figura 2.4 Regroup Therapy

Se trata de una empresa estadounidense que habilita sesiones de terapia personales o en grupo. Los terapeutas que deseen ofrecer sus servicios de forma remota pueden hacer uso de Regroup Therapy y crear una cuenta online. Por su parte la empresa se hace cargo de validar a estos terapeutas, revisando sus credenciales y su capacidad de tratar pacientes. La empresa obtiene sus beneficios dentro del coste de todas las sesiones que se llevan a cabo. La telemedicina tiene muchos sectores, la terapia de grupo es solo uno de ellos, y muchos más servicios relacionados pueden ofertarse utilizando WebRTC. [27] • TruClinic Otra empresa estadounidense que se ha aventurado en el campo de la telemedicina es TruClinic, esta empresa ofrece la posibilidad de visitar doctores online. WebRTC juega el rol de posibilitar llamadas de video insertado en los procesos de negocio, aquellos que necesitan ser seguros y privados debido a las regulaciones de los servicios de telemedicina. WebRTC también permite que dichos servicios sean accesibles desde casi cualquier dispositivo adaptándose al mismo sin la necesidad de instalaciones. Esta empresa ha conseguido el apoyo de varias entidades del sector médico privado estadounidense como Leavitt Partners o la University of Utah Health Care. [28]

2.2.1.3 Industria del videojuego Uno de los mercados menos explotados cuando hablamos de WebRTC se trata de la industria del videojuego. Hay muchas conversaciones sobre el potencial que podría tener esta tecnología, pero muy poca acción, debido a la falta de experiencia por la mayoría de desarrolladores. [29] [30] Por esta razón, en esta sección se exponen demos en vez de juegos reales o empresas dedicadas ello. Con estos ejemplos es posible observar las capacidades de WebRTC que están siendo estudiadas en la actualidad y hacia donde podría evolucionar. Esta baja tendencia podría cambiar debido al amplio mercado que representa dicha industria, mercado que sigue creciendo día a día y que cada vez atrae a más inversores. Por ello, y como cualquier industria tradicional, una reducción de los costes o una mejora de las prestaciones ofrecidas puede llevar a la adaptación de WebRTC como soporte a sus videojuegos. Para ejemplificar estas posibilidades presentaremos dos demos técnicas que hacen uso de esta tecnología de forma distinta, BananaBread y Snake: • BananaBread

Figura 2.5 BananaBread

Se trata de un juego first person shooter o de acción en primera persona 3D tradicional, el mismo ha sido portado para correr íntegramente en HTML5, utilizando JavaScript y WebGL. WebRTC se introdujo en este proyecto en 2013 debido al potencial de su canal de datos. Este canal fue integrado permitiendo ofrecer una baja latencia de red para el intercambio de información entre los jugadores de una sesión multijugador. Para los juegos multijugador, la latencia es un aspecto clave para proporciona una mejor experiencia a los jugadores. La capacidad de ofrecer conexiones P2P directamente a los jugadores puede reducir la latencia y además reducir la carga en el servidor de juego. Pero todavía es necesaria una investigación más profunda en este aspecto. [31]

12 WebRTC

• Snake

Figura 2.6 WebRTC Snake

Este juego se creó como una demo de HTML5 por parte de Nicolas Beauvais simplemente para demostrar que es posible utilizar esta tecnología en videojuegos. [32] La única diferencia que tiene con el juego original radica en la posibilidad de utilizar la cámara web para controlar los movimientos de la serpiente. Esto se ha conseguido mediante el uso de una librería JavaScript llamada headtrackr, que permite capturar video mediante WebRTC y procesar la imagen para seguir la cabeza. [33] Aunque el resultado es bastante tosco y difícil de usar para este juego específico, presenta otras implicaciones con respecto a la interacción por parte del usuario en otros juegos con WebRTC, teniendo en cuenta las capacidades mostradas por Microsoft con Kinect. [34]

2.2.1.4 Soluciones IT Los proveedores de soluciones IT se encuentran en el centro del ecosistema WebRTC. Ellos permiten llenar los espacios que la especificación de WebRTC no resuelve, conllevando una gran cantidad de capacidades backend a las que hay que dar solución. Existen gran cantidad de proveedores de estos servicios con grandes diferencias, en este caso se hablará de Digium y de XirSys. • Digium Digium ofrece un framework gratuito de comunicación ampliamente usado y popular llamado Asterisk. Fundada en 1999, Digium lleva en el terreno de las comunicaciones IP mucho más tiempo que WebRTC. Asterisk añadió soporte para WebRTC, que permite a cualquiera que necesite un PBX (Private Branch Exchange) o un servidor SIP (Session Initiation Protocol) la posibilidad de aceptar llamadas mediante WebRTC desde un navegador. Las ventajas de adoptar una plataforma que ha añadido WebRTC quedan en la sencilla integración con la infraestructura ya existente, así como la riqueza del framework y la arquitectura con una gran cantidad de desarrolladores y proveedores de servicios. Este soporte doble de WebRTC y las arquitecturas legadas pone limitaciones a lo que puede ser logrado con el uso de WebRTC como el soporte de video o la utilización del canal de datos.

• XirSys

Figura 2.7 XirSys

XirSys ofrece un SaaS (Service as Service) para NAT (Network Address Translation) transversal para WebRTC. En muchos casos los desarrolladores prefieren no lidiar con los problemas que conlleva instalar, configurar, integrar y mantener los servicios necesarios para sortear NAT. En estos casos, se busca un proveedor que pueda ofrecer esta solución baja un acuerdo de nivel de servicio. Las ventajas de externalizar estos problemas a un proveedor externo son múltiples, como podría ser la posibilidad de centrarse en la experiencia del usuario con la solución, flexibilidad para lidiar con los picos de uso y la reducción del coste de mantenimiento. SaaS puede incluir todo tipo de servicios, siendo una solución NAT transversal la más obvia de ellas, pero sería posible extenderse a la señalización, el procesado de los medios y grabación, por mencionar algunas de las áreas donde el desarrollo ha demostrado ser difícil. Gracias a estas soluciones es posible reducir el tiempo para el lanzamiento del producto al mercado además de simplificar el trabajo a largo plazo. [35]

2.2.1.5 Otros Casos de Uso Existen muchas más historias y casos de uso aparte de los ya presentados, el ecosistema actual de WebRTC cubre una gran cantidad de proveedores y de servicios distintos, algunos de ellos sin un modelo de negocio claro. En los años venideros este ecosistema pasará por una transición donde determinados proveedores desaparecerán, otros proveedores aparecerán y algunos de los ya existentes se fusionarán y consolidarán. Para terminar, se hablará de otros casos no relacionados entre si que servirán para terminar de ejemplificar la amplia variedad de posibilidades que nos ofrece WebRTC. Estas 3 empresas son las siguientes: la plataforma social Solaborate, la compañía de streamig Peer5 y la WebRTC School.

14 WebRTC

• Solaborate

Figura 2.8 Solaborate

Solaborate es una plataforma social y de colaboración dedicada a los profesionales y a las compañías. Ofrece una nueva aproximación al Networking profesional y a la colaboración productiva, intentando llegar a una audiencia muy específica. Solaborate utiliza WebRTC para permitir llamadas de voz y de audio tanto 1 a 1 como conferencias multipunto. En el mercado de las redes sociales, los proveedores tienden a ofrecer servicios gratuitos con modelos de negocio basados en anuncios, características premium o la monetización de los datos. En el caso de Solaborate no existe ningún modelo de negocio aparente, vía utilizada en algunos casos como forma de crecer para ser absorbidas o utilizada hasta que un modelo de negocio se presenta por si mismo. [36]

• Peer5 Esta startup israelí se ha centrado desde sus orígenes en el canal de datos. En WebRTC encontraron la capacidad de conectar navegadores directamente, y sobre ello, construyeron la posibilidad de cooperación entre navegadores cuando estos intentan acceder a contenido similar. Esta posibilidad se puede utilizar para reducir la carga de los servidores de streaming de video, además de para compartir todo tipo de ficheros, facturando en base al tráfico utilizado. Debido a la reducción de la carga en los servidores que albergan el contenido original, sería posible reducir los requisitos de ancho de banda necesarios en las granjas de servidores, y debido a su naturaleza, cuantos más usuarios intentaran acceder al mismo contenido al mismo tiempo, mayor sería la reducción de la carga. [37]

• WebRTC School Este no se trata de un proveedor en el sentido clásico de la palabra, no se encarga del desarrollo relacionado con WebRTC, si no que ofrece servicios de aprendizaje alrededor de WebRTC. Es el resultado del trabajo de Vocale, el proveedor que también dirige la SIP School, ofreciendo el muy necesario aprendizaje y programas de certificación. Ofrece dos cursos distintos, uno enfocado a desarrolladores y otro a aquellos que necesitan integrar y mantener servicios de WebRTC, utilizando un pago mediante suscripción. Esta compañía ocupa un rol de apoyo al ecosistema, mercado en el cual aún hay espacio para más proveedores que quieran adoptar un rol similar, permitiendo a otros proveedores que quieran aprovechar las posibilidades de WebRTC formar a sus empleados. [38]

2.2.2 Alternativas al uso de WebRTC

El mercado de WebRTC sigue creciendo de forma constante, aun con esto, muchos de los proveedores seguirán utilizando otro tipo de soluciones para solventar sus necesidades de comunicación. Las razones para ello pueden pasar por la falta de normalización, la juventud de esta tecnología, la dificultad de transición desde los anteriores sistemas de comunicación o la mayor confianza en otras tecnologías que pueden ofrecer los mismos servicios. En este apartado habla de estas alternativas al uso de WebRTC, desde un punto de vista empresarial o tecnológico.

2.2.2.1 Skype Como proveedor de servicios de comunicación es imposible no pensar en Skype. Se trata de un software propietario distribuido por Microsoft tras la comprar de la compañía homónima y que permite comunicaciones de texto, voz y vídeo sobre Internet. No es correcto realizar una comparación entre WebRTC y Skype ya que, aunque ambos nos ofrezcan la posibilidad de conectarnos con otros usuarios mediante video o audio, existen grandes diferencias. La más obvia es que Skype se trata de una aplicación, mientras que WebRTC es una tecnología que puede ser utilizada en gran cantidad de aplicaciones. También es necesario indicar que Skype queda limitado a su habilidad de ofrecer una conexión, ya sea de texto plano, audio o vídeo. WebRTC por otra parte puede ir más allá incorporándose dentro de otras opciones más diversas como se demostró en los casos de uso anteriormente planteados. [39] Por esto en este apartado se tratará a Skype como una alternativa a WebRTC en el mercado de la interacción directa entre usuarios, no como un competidor debido a sus grandes diferencias. Skype implementa un modelo freemium. La mayoría del servicio es gratuito, pero es necesario crédito o una suscripción para tener acceso a parte de sus servicios. Los usuarios registrados de Skype se identifican por un nombre de Skype único y son mostrados en el directorio de Skype. Estos usuarios registrados pueden comunicarse mediante mensajes, llamadas de voz, llamadas de video y compartir sus pantallas. Se soportan tanto llamadas 1 a 1 como con múltiples conferenciantes hasta un máximo de 25 participantes. Al ser la compañía dominante con respecto a llamadas por internet goza de unas cifras muy sólidas, cuentan con 300 millones de usuarios activos mensuales, con una media de 4,9 millones de usuarios que gastan 3 mil millones de minutos utilizando su servicio. [40] Entre los servicios de pago que ofrece Skype se encuentran las llamadas a números de teléfono y Skype Empresarial o las características incluidas en Office 365. Se pueden realizar llamadas a números de teléfono de todo el mundo con su aplicación, siendo posible contratar tarifas con cuotas de minutos y destinos del mundo dependiendo de la tarifa o utilizando crédito de Skype y pagando por cada uso. Skype empresarial y Office 365 empresarial nos permiten ampliar las capacidades que ya oferta Skype además de añadir gran cantidad de complementos y servicios [41]: - Se permite la carga de presentaciones PowerPoint cargada con herramientas interactivas en las mismas como anotaciones o punteros láser. - Se añade la existencia de una pizarra, permitiendo dibujar y editar sobre la misma como si se encontraran en la misma sala. - Se puede facilitar el acceso a las reuniones gracias a invitaciones por URL más sencillas. - Aumenta el máximo de personas en reunión hasta 250, permitiendo, además, que hasta 10.000 personas puedan acceder en formato de difusión de la reunión. - Añade otras herramientas de colaboración como la posibilidad de grabar las reuniones, iniciar sesiones de preguntas y respuestas o realizar sondeos a los participantes. - Ampliación de la asistencia técnica a nivel empresarial 15

16 WebRTC

- Aumento de la calidad de video, así como características adicionales de recorte automático y seguimiento de cabezas.

Figura 2.9 Seguimiento de cabezas Skype

Estas son algunas de las características que hacen de Skype una gran alternativa comercial al uso de WebRTC para la realización de conferencias. Con respecto a disponibilidad, Skype se encuentra disponible tanto en Windows, como en OS X de Apple como en Linux a nivel de escritorio, en este último operativo se encuentra disponible una beta que utiliza WebRTC lanzada el pasado 1 de Marzo de 2017 [42]. También existe soporte para gran cantidad de dispositivos móviles como iOS, Android y BlackBerry, así como en consolas como Xbox One o PlayStation Vita. Con respecto a códecs utilizados inicialmente para el audio se utilizaba G.729 y SVOPC, hasta que Skype desarrollo su propia tecnología llamada SILK para reemplazar a ese último, buscando una solución más ligera y embebible, distribuyéndolo como gratuita. Por esta naturaleza gratuita fue utilizado, entre otros, dentro de la plataforma de juegos Steam. Los principios de transmisión de este códec fueron integrados junto a los de CELT para conseguir transmisiones de alta calidad, dando lugar al códec Opus que posteriormente fue estandarizado por el IETF. [43] Con respecto a video, se comenzó utilizando el códec VP7, cambiando posteriormente al uso de H.264, códec que se utiliza en la actualidad. El código y protocolo de Skype permanecen cerrados y son privativos de la aplicación, Skype opera con base en el modelo P2P en vez del usual modelo Cliente-Servidor. Nótese que el modelo más popular, SIP, también es P2P, pero su implementación generalmente requiere su registro en un servidor. Skype utiliza el algoritmo AES de 256-bit para cifrar la voz, los archivos transferidos o el mensaje instantáneo. Para la versión de pago se utiliza el algoritmo RSA de 2048-bit para el acceso a correo de voz y de 1536-bit durante la negociación para establecer la conexión. Para ello utilizan una clave asimétrica, que permite evitar ataques del tipo man-in-the-middle. Aun con esto es imposible verificar que los algoritmos son usados correctamente, completamente y en todos los casos, ya que no hay posibilidad de revisión sin la especificación del protocolo el código fuente. Algunos de los casos de uso mencionados anteriormente para WebRTC pueden ser solventados de forma sencilla con la utilización de Skype, por ello casi 40.000 compañías confían en Skype para realizar sus comunicaciones de forma sencilla, significando esto más de un 20% de la cuota de mercado. [44]

2.2.2.2 Adobe Flash Adobe Flash es una plataforma software multimedia usada para la producción de animaciones y aplicaciones de internet, de escritorio y juegos. Flash permite el streaming de audio y de video y puede capturar entrada de ratón, teclado, micrófono y cámara. Este programa cuenta con su propio lenguaje de programación llamado ActionScript, que permite el desarrollo de animaciones interactivas, videojuegos, aplicaciones web, aplicaciones de escritorio y móviles. Los usuarios finales pueden ver contenido Flash mediante el software gratuito Adobe Flash Player. Adobe Flash Player ejecuta software escrito en el lenguaje ActionScript permitiendo la manipulación de texto, datos, gráficos, sonido y video. Este reproductor, al igual que Adobe Flash, puede también acceder a ciertos hardware conectados, como cámaras web y micrófonos, una vez se ha concedido permiso por parte de usuario para ello. Flash Player incluye soporte nativo para diferentes formatos de datos, aunque algunos de ellos solo son accesibles mediante la interfaz de ActionScript. Entre los formatos soportados se encuentran opciones ampliamente utilizadas como XML, que puede ser manipulado mediante JavaScript y ActionScript; JSON, que permite la interoperabilidad con servicios web y programas JavaScript, y otras opciones propias de adobe como AMF. y SFW. Principalmente Flash Player es una plataforma multimedia y de gráficos, por eso mismo permite el uso de los siguientes formatos multimedia de forma nativa para su descodificación y reproducción: FLV, PNG, JPEG y GIF. Con respecto a los códecs que soporta Flash Player encontramos que mediante Flash Video (FLV), el contenedor de formatos de fichero, podemos utilizar una gran cantidad de formatos de audio y de video, dentro de los formatos de video podemos ver formatos como Soreson Spark, VP6 o H.264, mientras que para el audio podemos optar entre AAC, MP3, ADPCM o Speex. [45]

Figura 2.10 Códecs soportados por Flash Player

18 WebRTC

Con respecto al coste de uso de dicha tecnología, Adobe ha avanzado en su esfuerzo de reducir o eliminar los costes de licencia de Flash, por ejemplo, se creó el Open Screen Project que elimina las cuotas de licencia y abre los protocolos de datos de Flash al público. También se abrieron al público diversos componentes relacionados con Flash como la ActionScript Virtual Machine 2 que fue donado a la Fundación Mozilla o el Adobe Flex Framework que fue donado a la Apache Software Foundation. Para el streaming de contenido Flash Player se apoya en varios protocolos que explicaremos a fondo más adelante, HTTP, y TCP. Esta tecnología ha llegado a una gran cantidad de usuarios, conociéndose que en 2013 más de 400 millones de equipos de escritorio actualizaron a la versión más reciente, pero aún con estos grandes números Adobe Flash Player cuenta con gran cantidad de detractores y es criticado duramente por parte del sector tecnológico, llegando a recomendar su desactivación e incluso su desinstalación. Con respecto a la usabilidad, Flash player presenta algunos problemas clásicos relacionados con la necesidad de instalación como puede ser la falta de soporte para Linux, al estar pensado para sistemas Windows, o la necesidad de desinstalar manualmente las versiones anteriores antes de realizar la instalación de una nueva versión. También se presentan problemas al conectar las aplicaciones Flash ocasionando un comportamiento inconsistente del manejo de entradas como teclado y ratón ofreciendo una mala experiencia de usuario. Pero sin duda, los problemas que más controversia han generado son aquellos relacionados con la privacidad y la seguridad: Flash Player soporta el almacenamiento local de datos, que puede ser utilizado de forma similar a las cookies HTTP. Esta característica permite a los sitios web almacenar datos no ejecutables en el ordenador del usuario, como información de autenticación, marcadores de juegos, trabajo guardado o ficheros temporales. Flash Player solo permite el acceso a dichos datos por parte del mismo dominio web que los ha originado. Debido a esta capacidad de guardar información, los sitios web pueden utilizar esta característica para reunir estadísticas del usuario, de esta forma, la posibilidad de crear un perfil basado en las estadísticas del usuario es considerado un potencial problema de privacidad. Esta característica puede ser deshabilitada de forma completa de forma manual por parte del usuario, pero dichas acciones pueden llevar a reducir o incluso imposibilitar la funcionalidad de algunos sitios web, ya sean datos como las preferencias o el progreso en juegos. Desde hace varios años, el registro de problemas de seguridad de Adobe Flash Player ha llevado a que muchos expertos en seguridad recomienden no instalar Flash, aun con ello, para la gente que necesite de su uso se recomienda la actualización solo desde fuentes fiables, ya que, por ejemplo, gran cantidad de phishing presente nos ofrece actualizaciones fraudulentas de esta aplicación. En la actualidad a día 20 de junio de 2017 existen más de 1000 entradas de vulnerabilidades en la Common Vulnerabilites and Exposures [46], posibilitando la ejecución remota de código o la posibilidad de espiar mediante el uso de webcams. Grandes empresas del sector de la seguridad han mostrado su preocupación con respecto a este problema, Symantec en su reporte de 2009 indico que Adobe Reader y Flash Player ocupaban el segundo puesto en la vulnerabilidad más atacada, tratándose de una vulnerabilidad de ejecución de código remoto [47]. Kaspersky subrayo en su informe de 2012 que las vulnerabilidades presentes en Flash Player permiten a los cibercriminales saltar los sistemas de seguridad integrados en las aplicaciones, así como que un 47,5% de los usuarios de Flash fueron afectados por una o más vulnerabilidades críticas. [48] Estos son algunos problemas que han llevado al descontento por parte de la comunidad, también por parte de empresas existen declaraciones en contra de su uso, En 2010 Steve Jobs, CEO de Apple, afirmó que ninguno de sus nuevos dispositivos iPhone ni iPad permitirían el uso de Flash, citando estos problemas de seguridad como una de las razones además de los problemas de estabilidad que Flash presenta [49]. En Julio de 2015 una serie de vulnerabilidades llevaron a la petición por parte del jefe de seguridad de Facebook de discontinuar el software completamente [50] y a los navegadores Mozilla, Chrome y Safari a bloquear todas las versiones anteriores de Flash Player. Estas razones junto a la creciente adopción de HTML5, están llevando al declive del uso de dicha tecnología, que será reemplazada por tecnologías como WebRTC que permitan las mismas posibilidades de forma más segura y estable.

2.3 WebRTC

En este apartado se analizan profundamente todos los componentes de WebRTC y cómo funcionan los mismos, en este apartado intervienen diferentes tecnologías y estándares de telecomunicación, que serán analizados antes de describir los componentes de dicha tecnología. Para visualizar las distintas tecnologías y conceptos que es necesario analizar, se presenta la pila de protocolos utilizada por WebRTC, y, en base a ella, empieza el análisis.

Figura 2.11 Pila de protocolos de WebRTC para datos y señalización

Se visualiza de forma sencilla la división entre el plano de datos y el plano de control. Dentro del plano de control, a la izquierda, se explica de forma breve el concepto de señalización aplicado a llamadas de voz, el protocolo de transporte TCP, la tecnología de WebSocket por su uso en la posterior implementación, así como el protocolo HTTP. Con respecto al plano de datos se detalla el protocolo de transporte UDP, los protocolos ICE, STUN y TURN, y el protocolo SRTP junto a RTP.

2.3.1 Explicaciones previas

2.3.1.1 Señalización La señalización es utilizada para coordinar la comunicación y enviar mensajes de control entre las entidades que se comunican. La señalización se usa para el intercambio mensajes de control de sesión, conocidos como SDP, configuraciones de red como candidatos ICE y capacidades de los medios que se disponen. Los protocolos difieren en sus características por la calidad de sus mecanismos de transmisión, su arquitectura, su disponibilidad y su grado de seguridad. Conviene conocer algunos de los más básicos que permitirán afianzar el concepto: • SIP: significa “Session Iniciation Protocol” (protocolo de inicio de sesiones) y permite establecer sesiones multimedia entre usuario cliente y servidor para transmisión de voz o vídeo (teleconferencias). Se intercambian peticiones o respuestas entre agentes de usuario a través de un servidor proxy o redirector. • IAX2: son las siglas de “Inter-Asterisk Exchange Protocol” y es un código abierto. Es decir, podemos cambiarlo y modificarlo según nuestra conveniencia. Resulta más eficaz que SIP porque los metadatos se transmiten in-band, o sea, que se pueden oír por diferentes canales a la vez.

20 WebRTC

• H.323: es uno de los protocolos de ITU-T (International Telecommunication Union). Originalmente se hizo para transportar aplicaciones multimedia en redes LAN, pero también ha venido a usarse para voz IP. Es el que usaba por ejemplo Microsoft Netmeeting, un programa de videollamada parecido a Skype que se usaba en XP y Windows 98. Tiene muy poca fiabilidad como protocolo de señalización en videoconferencias y transmisión de voz IP. Dentro del tema que estamos tratando, en WebRTC, la señalización trata varios puntos necesarios: - Envío de mensajes de control utilizados para comenzar y finalizar la comunicación. - Mensajes de error. - Metadatos sobre los medios como los códecs, configuración de los códecs, ancho de banda y tipos de medios. - Datos para establecer comunicaciones seguras. - Información de red como direcciones IP y puertos como son vistos desde el exterior. - Detección de candidatos para la comunicación. Como ya se ha comentado dicho proceso de señalización es necesario, pero este proceso no está implementado dentro de las APIs WebRTC, tienen que ser creados y definidos por los desarrolladores. Según sus creadores, la señalización no fue incluida dentro de WebRTC para evitar la redundancia y para maximizar la compatibilidad con las tecnologías que ya están establecidas. [51] Este caso de estudio particular se plantea en el apartado de implementación, hablando más en profundidad de la señalización adecuada para WebRTC y para este caso de estudio particular.

2.3.1.2 TCP Transmission Control Protocol (TCP) o Protocolo de Control de Transmisión, es uno de los protocolos fundamentales en Internet. Fue creado entre los años 1973 y 1974 por Vint Cerf y Robert Kahn [52]. Muchos programas dentro de una red de datos compuesta por redes de ordenadores pueden usar TCP para crear “conexiones” entre sí a través de las cuales puede enviarse un flujo de datos. El protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo orden en que se transmitieron. También proporciona un mecanismo para distinguir distintas aplicaciones dentro de una misma máquina, a través del concepto de puerto. Esto significa que los routers (que funcionan en la capa de red) sólo tienen que enviar los datos en forma de datagrama, sin preocuparse por la monitorización de datos porque esta función la cumple la capa de transporte Es un protocolo orientado a la conexión, ya que el cliente y el servidor deben anunciarse y aceptar la conexión antes de comenzar a transmitir los datos a ese usuario que debe recibirlos. TCP da soporte a muchas de las aplicaciones más populares de Internet (navegadores, intercambio de ficheros, clientes FTP, etc.) y protocolos de aplicación HTTP, SMTP, SSH y FTP. Entre sus características se encuentran: ▪ Permite colocar los datagramas nuevamente en orden cuando vienen del protocolo IP. ▪ Permite la monitorización del flujo de los datos y así evitar la saturación de la red. ▪ Permite que los datos se formen en segmentos de longitud variada para "entregarlos" al protocolo IP. ▪ Permite multiplexar los datos, es decir, que la información que viene de diferentes fuentes (por ejemplo, aplicaciones) en la misma línea pueda circular simultáneamente. ▪ Por último, permite comenzar y finalizar la comunicación de forma preestablecida. Debido a estas características este protocolo es utilizado cuando es necesaria una conexión estable con baja o ninguna tolerancia a pérdidas, caso encontrado en la señalización, donde es necesario garantizar la correcta recepción por parte de ambos extremos.

2.3.1.3 WebSocket WebSocket es una tecnología que proporciona un canal de comunicación bidireccional y full-duplex sobre un único socket TCP. Está diseñada para ser implementada en navegadores y servidores web, pero puede utilizarse por cualquier aplicación cliente/servidor, proporcionando baja latencia en la comunicación cliente-servidor. La API de WebSocket está siendo normalizada por el W3C, mientras que el protocolo WebSocket ya fue normalizado por la IETF como la RFC 6455 [53]. Debido a que las conexiones TCP comunes sobre puertos diferentes al 80 son habitualmente bloqueadas por los administradores de redes, el uso de esta tecnología proporcionaría una solución a este tipo de limitaciones proveyendo una funcionalidad similar a la apertura de varias conexiones en distintos puertos, pero multiplexando diferentes servicios WebSocket sobre un único puerto TCP (a costa de una pequeña sobrecarga del protocolo).

Figura 2.12 Arquitectura WebRTC

La especificación WebSocket del W3C [54] define un API que establece conexiones "socket" entre un navegador web y un servidor. Dicho con otras palabras: existe una conexión persistente entre el cliente y el servidor, y ambas partes pueden empezar a enviar datos en cualquier momento. Las últimas versiones de Chrome y Chrome para Android son completamente compatibles con la RFC6455, incluidos los mensajes binarios. Además, Firefox es compatible a partir de la versión 11 e Internet Explorer a partir de la versión 10. Algunos ejemplos de casos prácticos podrían ser: ▪ Juegos online multijugadores ▪ Aplicaciones de chat ▪ Rotativos de información deportiva ▪ Actualizaciones en tiempo real de las actividades de tus amigos [55] [56]

22 WebRTC

2.3.1.4 HTTP y HTTPS Hypertext Transfer Protocol o HTTP es el protocolo de comunicación que permite las transferencias de información en la World Wide Web. HTTP fue desarrollado por el World Wide Web Consortium y la Internet Engineering Task Force, colaboración que culminó en 1999 con la publicación de una serie de RFC, el más importante de ellos es la RFC 2616 que especifica la versión 1.1. HTTP define la sintaxis y la semántica que utilizan los elementos de software de la arquitectura web (clientes, servidores, proxies) para comunicarse. HTTP es un protocolo sin estado, es decir, no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. El cliente realiza una petición enviando un mensaje, generalmente al puerto estándar 80, con un formato definido al servidor y tras ello el servidor le envía un mensaje de respuesta con el contenido requerido. Por otra parte, el sistema HTTPS utiliza un cifrado basado en SSL/TLS para crear un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y del navegador utilizado por el cliente) más apropiado para el tráfico de información sensible que el protocolo HTTP. De este modo se consigue que la información sensible (usuario y claves de paso normalmente) no pueda ser usada por un atacante que haya conseguido interceptar la transferencia de datos de la conexión, ya que lo único que obtendrá será un flujo de datos cifrados que le resultará imposible de descifrar. El puerto estándar para este protocolo es el 443. Google en su esfuerzo por conseguir unos niveles de seguridad adecuados, obliga a utilizar HTTPS en todas las aplicaciones web que utilicen WebRTC en su navegador Chrome, en caso contrario, dichas aplicaciones no funcionarán. [57]

2.3.1.5 UDP User Datagram Protocol (UDP) es un protocolo del nivel de transporte basado en el intercambio de datagramas que permite el envío de datagramas a través de la red sin que se haya establecido previamente una conexión, ya que el propio datagrama incorpora suficiente información de direccionamiento en su cabecera. Tampoco tiene confirmación ni control de flujo, por lo que los paquetes pueden adelantarse unos a otros; y tampoco se sabe si ha llegado correctamente, ya que no hay confirmación de entrega o recepción. Su uso principal es para protocolos como DHCP, BOOTP, DNS y demás protocolos en los que el intercambio de paquetes de la conexión/desconexión son mayores, o no son rentables con respecto a la información transmitida, así como para la transmisión de audio y vídeo en real, donde no es posible realizar retransmisiones por los estrictos requisitos de retardo que se tiene en estos casos. Las características principales de este protocolo son: • Trabaja sin conexión, es decir que no emplea ninguna sincronización entre el origen y el destino. • Trabaja con paquetes o datagramas enteros, no con bytes individuales como TCP. Una aplicación que emplea el protocolo UDP intercambia información en forma de bloques de bytes. • No es fiable. No emplea control del flujo ni ordena los paquetes. • Su gran ventaja es que provoca poca carga adicional en la red ya que es sencillo y emplea cabeceras muy simples. UDP se utiliza sobre todo en tareas de control y en la transmisión de audio y vídeo a través de una red. No introduce retardos para establecer una conexión, no mantiene estado de conexión alguno y no realiza seguimiento de estos parámetros. Así, un servidor dedicado a una aplicación particular puede soportar más clientes activos cuando la aplicación corre sobre UDP en lugar de sobre TCP. Por esta razón UDP se utiliza como el protocolo de transporte para la transmisión de datos de WebRTC, tanto para la transmisión de video y audio como para la transmisión de datos.

2.3.1.6 ICE, STUN y TURN Estas tres tecnologías están relacionadas, ya que todas ellas buscan solución al problema de atravesar NAT para conseguir comunicación. STUN (sigla en inglés de Session Traversal Utilities for NAT) es un protocolo de red del tipo cliente/servidor que permite a clientes NAT encontrar su dirección IP pública, el tipo de NAT en el que se encuentra y el puerto de Internet asociado con el puerto local a través de NAT. Esta información es usada para configurar una comunicación UDP entre dos hosts que se encuentren tras enrutadores NAT. Este protocolo está definido en RFC 5389. [58] STUN es usado principalmente por teléfonos o software VoIP. Éste incorpora un cliente STUN que envía una petición a un servidor STUN. El servidor STUN informa entonces al cliente de la IP pública de este último y qué puerto ha sido abierto por NAT para permitir el tráfico entrante a la red del cliente. Por otra parte, existe el protocolo TURN (Traversal Using Relays around NAT), dicho protocolo ayuda en el descubrimiento de caminos entre los pares en Internet, aunque solo para audio, video y datos, no para señalización, la diferencia con respecto a STUN es que utiliza un relé intermediario público para retransmitir paquetes entre los pares. Esta opción es solamente utilizada para intercambiar paquetes cuando no existe otra opción, ya que, consume recursos de un servidor y suma latencia en las comunicaciones debido este nuevo paso intermedio. Se encuentra definido en la RFC 5766 [59] El único caso en el que TURN es necesario es cuando uno de los pares se encuentras detrás de un NAT simétrico, y el otro par se encuentra tras un NAT simétrico o un NAT de cono restringido de puertos. La frecuencia con la que este caso se da es difícil de aclarar, pero se estima que es de alrededor de un 8%. [60] ICE, siglas de Interactive Connectivity Establishment, definido en la RFC 5245 [61], es una técnica que utiliza SDP, STUN y TURN para descubrir un camino de red entre pares en Internet con la menor latencia posible. Inicialmente, ICE utilizará STUN con UDP para conectar directamente a los pares, y, si esto falla, utilizar un servidor de relé TURN, así como TCP si fuera necesario. Finalmente, se nos plantea el siguiente escenario en el mundo real, siendo el centro el camino de los datos:

Figura 2.13 Escenario real en Internet con STUN y TURN

WebRTC utiliza las posibilidades que nos ofrece ICE para conseguir la mejor conexión entre los pares.

24 WebRTC

2.3.1.7 RTP y SRTP Para transportar la voz sobre IP, se utilizan el protocolo IP a nivel de red y el protocolo UDP a nivel de transporte. Pero estos dos protocolos no son suficientes para asegurar el transporte de la voz. De hecho, UDP es un protocolo sin corrección de errores, y en ningún momento se asegura la llegada de paquetes en su orden de emisión. Para el transporte de datos en tiempo real, como la voz o el vídeo, es necesario utilizar dos protocolos suplementarios: RTP (Real-Time Transport Protocol) y RTCP (RTP Control Protocol). RTP y RTCP son dos protocolos que se sitúan en el nivel de aplicación y se utilizan junto con el protocolo de transporte UDP. RTP y RTCP pueden utilizar el modo unicast (punto a punto) y el modo multicast (multipunto). RTP y RTCP utilizan puertos diferentes. RTP utiliza un número de puerto par, y RTCP el número de puerto impar que sigue a continuación. Cuando una sesión RTP es abierta, al mismo tiempo se abre una sesión RTCP implícita. La función de RTP es proporcionar un medio uniforme de transmisión de datos sometidos a limitaciones de tiempo real (audio, vídeo, etc.). La función principal de RTCP es informar de la calidad de servicio proporcionada por RTP. Este protocolo recoge estadísticas de la conexión y también información, como por ejemplo bytes enviados, paquetes enviados, paquetes perdidos o Jitter entre otros. Una aplicación puede usar esta información para incrementar la calidad de servicio (QoS), ya sea limitando el flujo o usando un códec de compresión más baja. En resumen. RTCP se usa para informar de la QoS. [62] El Secure Real-time Transport Protocol (o SRTP) define un perfil de RTP (Real-time Transport Protocol), con la intención de proporcionar cifrado, autenticación del mensaje e integridad, y protección contra reenvíos a los datos RTP en aplicaciones unicast y multicast. Fue publicado por primera vez por el IETF en marzo de 2004 como la RFC 3711. [63] WebRTC utiliza SRTP como parte de su estándar. Dado que RTP está muy relacionado con RTCP (RTP control protocol), que puede ser usado para controlar una sesión RTP, SRTP también tiene un protocolo hermano llamado Secure RTCP (o SRTCP). SRTCP proporciona las mismas características relacionadas con la seguridad a RTCP, al igual que hace SRTP con RTP.

El empleo de SRTP o SRTCP es opcional al empleo de RTP o RTCP; pero incluso utilizando SRTP/SRTCP, todas las características que estos protocolos proporcionan (tales como cifrado y autenticación) son opcionales y pueden ser habilitadas o deshabilitadas por separado. La única excepción a esto último es la autenticación de los mensajes, que es obligatoria cuando se está usando SRTCP.

Figura 2.14 Paquetes RTP y SRTP

2.3.2 Descripción y funcionamiento

Ahora que ya se han visto algunas de las tecnologías que dan soporte a WebRTC para su funcionamiento en el mundo real, es momento de explicar los componentes de esta tecnología.

El código fuente de este proyecto está disponible en el repositorio: https://chromium.googlesource.com/external/webrtc. Este proyecto tiene una licencia BSD (Berkeley Software Distribution) con algunas restricciones, como que las redistribuciones del código fuente deben conservar el copyright anterior y ni el nombre de Google ni los nombres de sus colaboradores podrán usarse para respaldar o promocionar productos derivados de este software sin el permiso previo por escrito.

WebRTC se compone de varios elementos y software libre como el motor de voz, el motor de vídeo, el ecualizador de red, cancelación de echo acústico, etc. También utiliza varios códecs para el procesamiento de audio y vídeo.

Tabla 2–1. Ventajas e Inconvenientes de WebRTC Ventajas Inconvenientes

El código fuente de WebRTC tanto la parte La API web solo está disponible para utilizarla web como la móvil es abierto y libre en lenguaje JavaScript.

No necesita plugins ni programas El navegador web del usuario tiene que ser adicionales para utilizar esta tecnología compatible con la tecnología WebRTC. Esta tecnología está en continua evolución Al estar esta tecnología en continuo desarrollo y y desarrollo, apoyado por una gran evolución los sistemas tienen que ser adaptados comunidad de organizaciones y a posibles cambios programadores de todos los países del mundo. Las conexiones entre usuarios y aplicaciones con esta tecnología se crean punto a punto, sin necesidad de pasar la información o los datos por un servidor intermedio. Ofrece una API documentada y pública para desarrolladores.

Utiliza los estándares y normas establecidas por la IETF, W3C y RFC

El audio y video de WebRTC son encriptados por defecto

26 WebRTC

2.3.2.1 Arquitectura de WebRTC Su arquitectura general es la siguiente:

Figura 2.15 Arquitectura de WebRTC

Cabe destacar las 3 partes que se señalan en la leyenda.

- API para desarrolladores web: Es la interfaz o API que ofrece el navegador web para poder hacer aplicaciones con WebRTC. Esta interfaz ofrece los métodos necesarios para ser implementada en lenguaje JavaScript para poder usar WebRTC y así poder obtener los recursos de la máquina, configurar la conexión entre pares, abrir un canal de transmisión de datos, obtener los candidatos, etc. - API para desarrolladores de navegadores: Es una interfaz o API para que los desarrolladores de navegadores puedan realizar las conexiones entre pares utilizando la tecnología WebRTC. - Software reemplazable por desarrolladores de navegadores: Es el software que puede ser remplazado por los desarrolladores de navegadores como los códecs de voz, los de vídeo o los de conexión, aunque este último es desarrollado por la IETF.

2.3.2.2 Códecs utilizados en WebRTC Los códecs que utiliza actualmente WebRTC para vídeo y audio son varios, aunque estos pueden cambiar en un futuro.

Para el vídeo se utiliza:

- VP8: Este códec es parte del proyecto WebM. Incluye componentes para ocultar paquetes perdidos, limpiar las imágenes de ruido, capacidades de captura y reproducción a través de múltiples plataformas. Google está desarrollando la siguiente versión de este códec el V9 para integrarlo en su navegador Chrome y en WebRTC.

- H.264-MPEG: es un códec de alta compresión de vídeo desarrollado por el ITU-T Video Coding Experts Group (VCEG) y el ISO/IEC Moving Picture Experts Group (MPEG). Es un formato muy extendido y en reproductores de vídeo de todo tipo. El códec H.264 se puede combinar con los códecs de audio ACC o MP3 dentro del contenedor MPEG-4 (conocido como MP4).

Para audio se incluye varios códecs como:

- G.711: También conocido como códec “PCMA” o “PCMU”, (según su variante), es un codec que no utiliza compresión, por lo que obtiene una mayor calidad de voz a costa de un mayor consumo de ancho de banda. No utiliza algoritmos complejos, por lo que no necesita grandes capacidades de procesamiento. Su calidad es similar a la de la telefonía convencional.

- G.722: es un códec de audio estándar ITU-T 7 KHz de banda ancha que opera a 48, 56 y 64 Kbit / s. Fue aprobado por la UIT-T en noviembre de 1988. Este codec mantiene los consumos de ancho de banda del codec G711, pero duplicando la calidad del audio a costa de aumentar la complejidad de los algoritmos utilizados y de los requisitos necesarios.

- iSAC: es un robusto adaptador de ancho de banda y códec de voz de banda y súper banda ancha desarrollada por Global IP Solutions utilizados en muchas aplicaciones de Voz sobre IP (VoIP) y de streaming de audio. iSAC es utilizado por los líderes de la industria en cientos de millones de puntos finales de VoIP.

- iLBC: es un códec libre de voz de banda estrecha, fue desarrollado por Global IP Solutions utilizado en muchas aplicaciones de Voz sobre IP (VoIP) y audio streaming. Este códec se incluye como parte del proyecto WebRTC.

- OPUS: Opus es un códec digital con pérdida, muy versátil y abierto. Combina los algoritmos de SILK y CELT, y alterna entre ellos cuando es necesario para lograr la mayor eficiencia posible. Opus tiene una latencia más baja que los demás códecs de audio (22,5 ms por defecto, cuando los demás tienen más de 100 ms), lo que hace que sea ideal para la comunicación en tiempo real. Según su especificación, es un códec ajustable dinámicamente pudiendo pasar, de la mejor calidad de audio: 48 kHz y un gran consumo de ancho de banda, hasta una calidad mínima (8kHz) y un ancho de banda minimalista.

• Para la transmisión de datos utiliza buffers de desviación (jitter) dinámicos y técnicas de ocultación de error para procesar el audio y el vídeo ayudando a mitigar los efectos de la pérdida de paquetes y las redes no confiables.

28 WebRTC

2.3.2.3 API para desarrolladores web Por medio de esta API en JavaScript se puede acceder a la cámara web y al micrófono de un equipo para realizar conexiones entre pares o entre múltiples usuarios, la API proporciona al desarrollador varios una interfaz implementar los métodos y poder acceder a los recursos de la máquina. Para adquirir y comunicar datos de streaming, WebRTC implementa las siguientes API: • getUserMedia (MediaStream): obtener acceso a flujos de datos como la cámara y el micrófono del usuario. • RTCPeerConnection: llamada de audio o vídeo, con módulos para el cifrado y gestión de ancho de banda. • RTCDataChannel: comunicación entre pares para datos genéricos.

2.3.2.3.1 getUserMedia (MediaStream) La API de MediaStream fue diseñada para facilitar el acceso a los flujos de medios de cámaras y micrófonos locales. El método getUserMedia()es la forma principal de acceder a los dispositivos de entrada locales. La API tiene algunos puntos clave: ▪ Un flujo de medios en tiempo real que está representado por un stream de objetos en forma de vídeo o audio. ▪ Proporciona un nivel de seguridad a través de los permisos del usuario que solicita al usuario antes de que una aplicación web puede empezar a ir a buscar un stream. ▪ La selección de los dispositivos de entrada es manejada por el API MediaStream (por ejemplo, cuando existen varios micrófonos conectados al equipo).

Figura 2.16 Interacciones del objeto MediaStream

Cada objeto MediaStream incluye varios objetos MediaStreamTrack. Representando vídeo y audio de diferentes dispositivos de entrada. Cada objeto MediaStreamTrack puede incluir varios canales (canal un audio derecho e izquierdo). Estas son las partes más pequeñas definidas por la API MediaStream. Hay dos formas de dar salida a los objetos MediaStream. En primer lugar, podemos hacer que se reproduzca en un vídeo o en un elemento de audio. En segundo lugar, podemos enviar la salida al objeto RTCPeerConnection, que a continuación, enviará dichos objetos a un par remoto. [64] 28

2.3.2.3.2 RTCPeerConnection API La interfaz RTCPeerConnection es la responsable de la gestión completa del ciclo de vida de las conexiones entre pares, teniendo entre sus tareas:

▪ Gestión del flujo completo de trabajo ICE para el recorrido de las NAT. ▪ Envío automático de mensajes keepalive entre los pares. ▪ Supervisión de streams locales. ▪ Supervisión de streams remotos. ▪ Comienzo automático de renegociación de los streams. ▪ Creación de ofertas de conexión, aceptación de las respuestas, supervisión del estado de la conexión y más.

Figura 2.17 Interacciones del objeto RTCPeerConnection

Un objeto de esta API debe mantener como ya se ha mencionado un estado de señalización, un estado de la conexión, un estado de la conexión ICE y los recursos disponibles en ambos extremos gracias al intercambio de SDP entre los pares.

30 WebRTC

Para ello, la API ofrece gran cantidad de métodos para llevar a cabo todas estas tareas, se presentan algunos de los más relevantes: ▪ RTCPeerConnection.createOffer(): Este método crea la oferta solicitada para encontrar el par remoto con una configuración especifica.con ▪ RTCPeerConnection.createAnswer(): Este método crea la respuesta para la oferta recibida del par remoto, los parámetros de entrada son el primero la configuración como puede ser de audio/vídeo, y los dos siguientes son los callBacks que se ejecuta según el éxito o el error de la ejecución de este método. ▪ RTCPeerConnection.setLocalDescription(): Esta función cambia la descripción local asociada con la conexión. La descripción define las propiedades de la conexión como puede ser el códec. ▪ RTCPeerConnection.setRemoteDescription(): Esta función cambia la descripción remota asociada con la conexión. ▪ RTCPeerConnection.addStream(): Esta función añade un objeto MediaStream como recurso local de audio o vídeo. El recurso que se añade puede ser el stream remoto o local. La API también cuenta con varios controladores de eventos para el manejo de recepción de streams remotos o cambios en el estado de las conexiones ICE: ▪ RTCPeerConnection.onaddstream: Este controlador se invoca cuando se activa el evento addstream. Este evento se envía cuando se añade un MediaStream a esta conexión por el par remoto. ▪ RTCPeerConnection.onicecandidate: Este controlador se invoca cuando se activa el evento icecandidate. Este evento se envía cuando se añade un objeto RTCIceCandidate. ▪ RTCPeerConnection.oniceconnectionstatechange: Este controlador se invoca cuando se activa el evento iceconnectionstatechange. Este evento se envía cuando el valor de iceConnectionState cambia.

Figura 2.18 Envío de audio y video mediante SRTP sobre UDP

2.3.2.3.3 RTCDataChannel La interfaz RTCDataChannel de WebRTC representa un canal de datos bidireccional entre pares de una conexión. Los objetos de este tipo se pueden crear utilizando RTCPeerConnection.createDataChannel(), o se reciben en un evento de tipo RTCDataChannel.datachannel evento en una RTCPeerConnection existente. Para utilizar esta característica del API de WebRTC es necesario establecer una conexión con un par (peer), se configura exactamente igual que para realizar una videollamada y se envían los mensajes por medio del objeto RTCPeerConnection creando una instancia de un nuevo canal, se utiliza el método de la interfaz createDataChannel() para crear el canal. Una vez la conexión RTCPeerConnection ha sido establecida se pueden abrir uno o varios canales para el envío de datos binarios o de texto. Para realizar este envío de datos de forma segura, se utiliza el protocolo SCTP, un protocolo que aúna las mejores cualidades de TCP y UDP sobre un túnel TLS seguro sobre UDP. Las transmisiones son orientadas a mensaje, con fiabilidad y entrega configurable, tiene un mecanismo de control de flujo y de control de congestión. Dicho protocolo se encuentra estandarizado por el grupo SIGTRAN de IETF en la RFC 4960 [65] La API DataChannel se realizó muy similar a la API Websocket de forma intencionada, utilizando los mismos controladores de eventos, así como campos muy similares. DataChannel ofrece las mismas posibilidades que ofrece WebSocket, pero entre pares en vez de con la utilización de un servidor. [66]

Tabla 2–2. Websocket Vs DataChannel

Websocket DataChannel

Encripción Configurable Obligatorio

Fiabilidad Fiable Configurable

Entrega Ordenada Configurable

Multiplexado No (Posible con extensión) Si

Transmisión Orientada a mensajes Orientada a mensajes

Transferencia binaria Si Si

Transferencia UTF-8 Si Si

Compresión No (Posible con extensión) No

32 WebRTC

2.3.2.4 Flujo de una llamada WebRTC En este apartado se observa el flujo de información que se lleva a cabo cuando realizamos una llamada, cuando recibimos una llamada, cuando decidimos terminar una llamada, y el flujo completo de una llamada visto desde ambos extremos. Los tres primeros ejemplos que se verán están enfocados desde uno de los extremos de la aplicación y provienen de la página oficial de WebRTC. [67] Realización de una llamada:

Figura 2.19 Realización de llamada WebRTC

En este diagrama de flujo se presenta un escenario en el cual la creación del objeto RTCPeerConnection queda orquestado por la aplicación. En el mismo se observa cómo se crean las variables MediaStream y se añaden al Stream local para su visualización y como se añaden al objeto RTCPeerConnection para su posterior envío. Es posible ver también el proceso de envío de las ofertas de señalización por parte de ambos extremos.

Recepción de una llamada:

Figura 2.20 Recepción de llamada WebRTC

Ahora se observa el proceso del cierre de la conexión al terminar la llamada, realizando los cambios de estado pertinentes en la conexión y retirando los streams:

Figura 2.21 Cierre de llamada WebRTC

34 WebRTC

En este último diagrama el W3C [64] presenta una llamada completa entre los dos extremos

Figura 2.22 Llamada completa WebRTC

Se pueden observar los eventos más relevantes que se van disparando, así como los callbacks pertinentes, cabe destacar el uso del servidor de relay por parte de Bob, así como la utilización de respuestas provisionales (pranswer) antes de completar el proceso de ICE.

3 IMPLEMENTACIÓN DEL ESCENARIO WEBRTC

Where's the fun in playing fair? - Carolina Ravassa -

n este nuevo capítulo se analizarán los distintos requisitos que necesitamos para conseguir las medidas que nos permitirán analizar la calidad de WebRTC. Se presentarán los diversos requisitos, así como el E escenario real a simular. Se plantearán las diversas alternativas que se consideraron al comenzar el trabajo, así como las razones para descartar su uso, terminando esta sección con la implementación propuesta que finalmente se llevó a laboratorio.

3.1 Requisitos y escenario

3.1.1 Requisitos

3.1.1.1 Requisitos funcionales La realización de la aplicación de este proyecto se ha basado en desarrollar los siguientes requisitos para cumplir el objetivo de crear una aplicación con funcionalidad. Los requisitos que se ha decidido establecer son: Tabla 3–1. RQF-00 Mostrar página de inicio y bienvenida

RQF-00 Mostrar página de inicio y bienvenida

Dependencias Ninguna

Descripción El sistema deberá mostrar una página previa a la página de llamada

Importancia Baja

Comentarios Ninguno

36 Implementación del escenario WebRTC

Tabla 3–2. RQF-01 Registrar usuario

RQF-01 Registrar usuario

Dependencias • RQF-00

Descripción El sistema tiene que mostrar en la página de inicio un formulario sencillo para introducir el nombre de usuario.

Importancia Alta

Comentarios Ninguno

Tabla 3–3. RQF-02 Redirigir al usuario a la sala de llamada

RQF-02 Redirigir al usuario a la sala de llamada

Dependencias • RQF-00 • RQF-01

Descripción El sistema tiene que redirigir al usuario a la sala de llamada una vez se registre en el sistema.

Importancia Alta

Comentarios Ninguno

Tabla 3–4. RQF-03 Establecer un socket de conexión

RQF-03 Establecer un socket de conexión

Dependencias Ninguno

Descripción El sistema tiene que poder crear un socket de conexión con un servidor de señalización para poder lanzar eventos a todos los usuarios conectados.

Importancia Alta

Comentarios Ninguno

Tabla 3–5. RQF-04 Realizar llamada

RQF-04 Realizar llamada

Dependencias • RQF-02

Descripción El sistema permitirá que los usuarios puedan enviarse señales de llamada entre pares

Importancia Alta

Comentarios Ninguno

Tabla 3–6. RQF-05 Autoaceptación llamada

RQF-05 Autoaceptación de llamada

Dependencias • RQF-02 • RQF-04

Descripción El sistema permitirá que los usuarios reciban llamadas de forma automática sin tener que aceptar de forma explícita

Importancia Alta

Comentarios Ninguno

Tabla 3–7. RQF-06 Selección de códec

RQF-06 Selección de codec

Dependencias • RQF-02 • RQF-04

Descripción El sistema permitirá que los usuarios elegir el códec que quieren utilizar desde un formulario con diversas opciones.

Importancia Alta

Comentarios Necesitaremos esta función para comprobar la calidad con los diversos códecs.

38 Implementación del escenario WebRTC

Tabla 3–8. RQF-07 Finalizar la llamada

RQF-07 Finalizar la llamada

Dependencias • RQF-02 • RQF-04

Descripción El sistema permitirá que los usuarios cierren la conexión a voluntad.

Importancia Media

Comentarios Ninguno

Tabla 3–9. RQF-08 Carga de audios

RQF-08 Carga de audio

Dependencias • RQF-02 • RQF-04

Descripción El sistema permitirá que los usuarios carguen ficheros en formato WAV para su reproducción en la llamada.

Importancia Alta

Comentarios Es necesaria la carga de audio para realizar nuestra batería de pruebas teniendo siempre datos de entrada sin diferencias entre las distintas repeticiones.

3.1.1.2 Requisitos no funcionales Los requisitos no funcionales son aquellos que describen las propiedades que la aplicación tiene que cumplir, en ningún momento expresan funcionalidad del sistema, se refieren a todos los requisitos que no describen información a guardar, ni funciones a realizar, sino características de funcionamiento que tiene que tener el sistema, en nuestro caso pensamos en el uso de la aplicación tanto por parte de usuario como por parte de una herramienta automatizada. Esta aplicación tiene los siguientes requisitos no funcionales con respecto a eficiencia, usabilidad y portabilidad:

Tabla 3–10. RQNF-00 Interfaz de usuario simple e intuitiva

RQNF-00 Interfaz de usuario simple e intuitiva

Descripción El sistema tiene que tener una interfaz de usuario simple e intuitiva. La interfaz tiene que guiar al usuario. Los elementos que componen la interfaz deben ser claros para optimizar la usabilidad de la aplicación.

Importancia Alta

Comentarios Ninguno

Tabla 3–11. RQNF-01 Interfaz de usuario responsiva

RQNF-01 Interfaz de usuario responsiva

Descripción El sistema tiene que tener una interfaz de usuario responsiva que se adapte a distintos tamaños de la pantalla y a distintos dispositivos.

Importancia Media

Comentarios Ninguno

Tabla 3–12. RQNF-02 Ejecución correcta de la aplicación en varios navegadores

RQNF-02 Ejecución correcta de la aplicación en varios navegadores

Descripción El sistema tiene que ejecutarse de forma correcta en varios navegadores compatibles con WebRTC tanto navegadores web de escritorio como navegadores web móvil.

Importancia Media

Comentarios Como mínimo tiene que ser compatible con el navegador web Google Chrome.

40 Implementación del escenario WebRTC

Tabla 3–13. RQNF-03Múltiples sesiones concurrentes

RQNF-03 Múltiples sesiones concurrentes

Descripción El sistema debe ser capaz de operar adecuadamente con múltiples usuarios con sesiones concurrentes.

Importancia Media

Comentarios Ninguno

Tabla 3–14. RQNF-04 Seguridad en las comunicaciones

RQNF-04 Seguridad en las comunicaciones

Descripción Todas las comunicaciones externas entre servidores de datos, aplicación y cliente del sistema deben estar encriptadas

Importancia Alta

Comentarios Ninguno

Tabla 3–15. RQNF-05 Pruebas de software

RQNF-05 Pruebas de software

Descripción Las pruebas de software se ejecutarán utilizando Selenium y Python como herramienta y lenguaje Scripting para automatización de software testing

Importancia Media

Comentarios Ninguno

3.1.2 Escenario

Es necesario conocer el escenario real que se ha pretendido simular; en la figura que se muestra a continuación se muestra un esquema simplificado del mismo.

Figura 3.1 Escenario real a simular

Básicamente se desea recrear una red cableada que de acceso a varios terminales para que realicen llamadas de voz hacia otros terminales unidos mediante la utilización de un switch. Se podría observar como una red interna de oficina sobre la que se realizan las llamadas de voz entre los distintos usuarios.

3.2 Alternativas de implementación

Durante la construcción del entorno se valoraron distintas posibilidades para los distintos aspectos del proyecto: herramientas, servidores, formato de presentación, etc. En este apartado se presentarán las posibilidades que existían para llevar a cabo diferentes tareas, y en el próximo apartado, cuáles son las razones que llevaron a la implementación finalmente realizada y los componentes que la forman. Se hablará de las siguientes decisiones: • Manera de utilizar la tecnología WebRTC • Servidor web que utilizar • Forma de señalización que implementar • Alimentación de audio a la aplicación

42 Implementación del escenario WebRTC

3.2.1 Manera de utilizar la tecnología WebRTC

Para el uso de la tecnología WebRTC se nos presentan diversas posibilidades, desde el uso directo de las APIs nativas facilitadas por el proyecto WebRTC hasta librerías de APIs externas al proyecto principal que permiten facilitar el despliegue de las aplicaciones. Algunas de las opciones que se consideraron fueron las siguientes:

3.2.1.1 SimpleWebRTC Esta API open source de WebRTC fue creado por la empresa &yet con el objetivo de facilitar el trabajo a los desarrolladores previendo un aumento en la adopción de dicha tecnología. [69] Se trata de una API potente y versátil que es actualizada de forma regular por parte de &yet. [70] SimpleWebRTC se compone de un montón de pequeños módulos independientes además de los oficiales de WebRTC para ofrecer sus prestaciones, algunos de ellos son: • Webrtcsupport: permite comprobar las capacidades del navegador y utilizar constructores apropiados para crear objetos RTCPeerConnection y RTCSessionDescription, así como comprobar la posibilidad de uso del canal de datos. • getScreenMedia: Extiende las capacidades de getUserMedia para conseguir acceso a la pantalla para compartirla mediante la API. &yet ofrece de forma gratuita un servicio grupal utilizando SimpleWebRTC que permite transmisión de video, audio, compartir pantalla y servicio de chat en talky.io [71]

Figura 3.2 Talky.io

3.2.1.2 EasyRTC EasyRTC se trata de una librería para navegadores de cliente escrita en JavaScript. Este cliente maneja la señalización y aísla en gran medida las aplicaciones de los cambios que se realicen en la API de WebRTC. EasyRTC también incluye un servidor de señalización basado en Node.js, lo que le permite correr en dispositivos tan pequeños como una Raspberry hasta servidores en cloud. [72] Gracias a estos dos componentes, es posible escribir una aplicación en pocas líneas de código, ya sea para conferencias de video o para compartir ficheros entre los usuarios. Desde su página web se pueden encontrar gran cantidad de códigos de ejemplo para entender el funcionamiento de su API, referenciando también en que navegadores funcionarán dichas demos. [73] Se pueden observar gran cantidad de capacidades que nos ofrece, desde las ya mencionadas a otras como la captura de pantalla, chat de baja latencia o la posibilidad de grabar las conversaciones que se realizan con su API. Una empresa que utiliza EasyRTC sería Tawk, que permite incluir chat de forma sencilla en páginas web. [74]

3.2.2 Servidor web que utilizar

La elección del servidor web inicialmente se guió por el conocimiento adquirido durante los años de estudio de Grado, por ello, en primera instancia se propuso la utilización de los servidores web más expandidos: Apache o Nginx, aunque finalmente la elección final no fuera esta debido a la mayor complejidad y a los problemas de portabilidad que pudieran presentarse. Dicho esto, ambos son servidores web que considerar para un despliegue real de una aplicación que utilice WebRTC:

3.2.2.1 Apache El servidor HTTP Apache es un servidor web HTTP de código abierto, desarrollado y mantenido por una comunidad de usuarios bajo la supervisión de la Apache Software Foundation dentro del proyecto HTTP Server (httpd). La arquitectura del servidor Apache es muy modular. El servidor consta de una sección core y diversos módulos que aportan mucha de la funcionalidad que podría considerarse básica para un servidor web. Apache es usado principalmente para enviar páginas web estáticas y dinámicas en la World Wide Web. Muchas aplicaciones web están diseñadas asumiendo como ambiente de implantación a Apache, o que utilizarán características propias de este servidor web. Apache tiene amplia aceptación en la red: desde 1996, Apache, es el servidor HTTP más usado, y este jugó un papel fundamental en el desarrollo fundamental de la World Wide Web.

3.2.2.2 Nginx Nginx es un servidor web HTTP de código abierto que también incluye servicios de correo electrónico con acceso al Internet Message Protocol (IMAP) y al servidor Post Office Protocol (POP). Además, nginx está listo para ser utilizado como un proxy inverso. En este modo, nginx se utiliza para equilibrar la carga entre los servidores. Nginx se destaca por su conjunto de principales características asociadas con el rendimiento, la escalabilidad y la eficiencia de costes. De acuerdo con el estudio de Julio de 2014 de Netcraft [75], nginx es el segundo servidor web más usado en dominios activos superando a Microsoft Information Server. Además, pasó la marca de ser usado en más de 100 millones de sitios. Es software libre y de código abierto, también existe una versión comercial distribuida bajo el nombre de nginx plus. Empresas como la compañía de TV online Hulu utilizan nginx por su estabilidad y simple configuración. Otros usuarios, como Facebook y WordPress.com, lo utilizan porque la arquitectura asíncrona del servidor web deja una pequeña huella de memoria y bajo consumo de recursos, haciéndolo ideal para el manejo de múltiples y cambiantes activas páginas Web. [76]

Figura 3.3 Cuota de mercado de diferentes servidores web

44 Implementación del escenario WebRTC

3.2.3 Forma de señalización que implementar

Como ya se comentó en los capítulos anteriores, WebRTC no define ni recomienda ninguna forma de señalización, por ello, cada equipo que implemente una solución tiene la libertad de elegir ya sea por sencillez, conocimiento previo, o limitaciones debido a conexión con otro tipo de sistemas. Esta fue también una de las decisiones que hubo que tomar durante la realización del proyecto, y estas fueron algunas de las opciones que se sopesaron.

3.2.3.1 SIP sobre WebSockets Este enfoque utiliza la tecnología de WebSockets que se presentó anteriormente, pero en vez de utilizar mensajes propietarios creados por nosotros, se introducen mensajes SIP. Inicialmente se planteó esta solución por la propuesta de utilizar teléfonos VoIP en el laboratorio, y de esta forma, serían necesarios mensajes SIP para conseguir el funcionamiento óptimo. Por parte de la comunidad existe una división clara con respecto al uso de SIP para señalización en WebRTC, por un lado, la industria de las telecomunicaciones, defendiendo esta necesidad para conectar con sus equipos antiguos; y por otra parte los desarrolladores web, queriendo dejar atrás los protocolos de la red telefónica. [77] Finalmente, debido a estas últimas recomendaciones, se abandonó esta aproximación.

Tabla 3–16. Opciones de señalización para WebRTC [78]

Técnica ¿Por qué?

SIP sobre Websockets Permite conectar con la red PSTN y con los equipos ya desplegados que utilicen SIP como forma de señalización.

XMPP/Jingle Igual que en el caso de SIP, permite comunicación con aquellos dispositivos que utilicen el protocolo XMPP.

WebSockets Se trata de la mayor y mejor innovación en la comunicación cliente-servidor web según la comunidad de desarrolladores web.

XHR/Comet Señalización web clásica, soportada en la mayoría de navegadores.

DataChannel WebRTC Posibilidad aún por explorar que nos ofrece baja latencia y poco tráfico a nuestros servidores, ayudando a la escalabilidad.

3.2.3.2 DataChannel de WebRTC WebRTC cuenta con un canal de datos, una vez que la conexión inicial se ha llevado a cabo entre los dos extremos, se puede utilizar este canal para comunicar mensajes de comunicación en lugar de mediante un servidor. Esta posibilidad ha sido levemente investigada, pero nos ofrece algunos beneficios: • Baja latencia de los mensajes de señalización, ya que no existe un servidor intermedio que tenga que analizar y reenviar dichos mensajes. • Mejora la escalabilidad del servidor, ya que tiene que procesar menos cantidad de mensajes por cada navegador conectado. Debido a la escasa documentación relativa a esta solución, se abandonó dicha línea de investigación.

3.2.4 Alimentación de audio a la aplicación

Uno de los últimos puntos que salieron como problema fue alimentar el audio a nuestra aplicación. Ya que nuestro objetivo es medir la calidad que ofrece esta tecnología, es necesario utilizar siempre el mismo set de audios sin la existencia de cambios entre cada una de las pruebas. De esta forma podremos recabar datos útiles y significativos para apoyar las conclusiones. Uno de los principales casos de uso de esta tecnología es el uso de la API getUserMedia para obtener acceso al micrófono del usuario para su posterior envío mediente la conexión creada con la API RTCPeerConnection, pero, al tratarse de un test automatizado, la opción de utilizar un micrófono queda totalmente descartada. Para seguir utilizando dicha API getUserMedia, inicialmente se propuso la siguiente solución: utilizar cables de audio virtuales que redirigieran los sonidos de altavoz a un micrófono virtual gracias al uso de la tarjeta de audio. Esta solución ya había sido investigada, pero con otro propósito, la grabación del audio recibido. Para esta labor se planteó la reproducción del audio en un altavoz virtual, para redirigirlo a un micrófono virtual que sería captado mediante getUserMedia, enviando al otro extremo el audio, y, el audio recibido sería redirigido desde los altavoces hasta un micrófono virtual que sería utilizado encada ordenador para grabar el audio recibido por parte del otro extremo. Esta solución llevaría al siguiente escenario:

Figura 3.4 Estructura con cables de audio virtuales

En este escenario se necesitarían gran cantidad de cables virtuales en ambos ordenadores, con los problemas que estos presentan: sería necesario indicar a cada uno de los componentes cuál es su cable de entrada y de salida, necesitando investigación tanto en la selección de medios de getUserMedia como la redistribución de audio de forma específica al altavoz virtual por parte del sistema; la estructura de escenario sería mucho más compleja y costosa, la mayoría de software que permite la utilización de cables virtuales solo permite la utilización de un cable, y en este escenario sería necesario al menos dos cables por equipo, casuística que algunos programas ofrecen pero intercalando su publicidad en el uso, hecho que invalidaría nuestras pruebas de raíz. Dicha implementación se inició enviando únicamente audio en uno de los sentidos de la comunicación dando buenos resultados, pero al intentar una implementación completa se encontraron los problemas que acabamos de plantear. Dicha solución es viable, pero no parece muy acertada en nuestra situación. Tras sopesar estos problemas se llegó a la conclusión de que la relación esfuerzo-resultado necesaria para utilizar la API getUserMedia, no era suficiente.

46 Implementación del escenario WebRTC

3.3 Implementación propuesta

Ya hemos presentados todas las opciones que se plantearon pero que finalmente no se eligieron para llevar a cabo la implementación de nuestro escenario WebRTC, en esta sección se presenta la implementación que finalmente se propuso y se llevó a laboratorio para la realización de las pruebas pertinentes.

• Uso de la tecnología: API Nativa Finalmente, para utilizar la tecnología se eligió el uso de la API nativa proporcionada por el proyecto WebRTC. Esta API cuenta con una gran cantidad de documentación por parte tanto del propio proyecto WebRTC como por parte del IETF y del W3C, así como por parte de la comunidad de desarrollo web. Otra de las razones que llevaron a la utilización de la API nativa fue la excesiva simplicidad que ofrecían las APIs desarrolladas por terceros para WebRTC, dichas APIs, para conseguir la sencillez en el desarrollo enmascaran el proceso de negociación de SDPs, haciendo imposible la visualización de los mensajes de señalización en los cuales se declaran los medios de cada equipo. Por ello, no era posible establecer la prioridad de uso de los códecs, algo totalmente necesario para poder realizar un estudio de la calidad ofrecida. Por estas razones se terminó utilizando la API Nativa, específicamente la vertiente de la API para el navegador Google Chrome. [79]

• Servidor Web utilizado: Express (Node.js) Node.js es un entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa del servidor (pero no limitándose a ello) basado en el lenguaje de programación ECMAScript, fue creado con el enfoque de ser útil en la creación de programas de red altamente escalables, como, por ejemplo, servidores web. Express es una infraestructura de aplicaciones web Node.js mínima y flexible que proporciona un conjunto sólido de características para las aplicaciones web y móviles. El éxito de express radica en lo sencillo de uso, y en nuestro caso concreto nos permite levantar de forma sencilla un servidor HTTPS, además al estar ligado a Node.js significa que en cualquier OS que permita instalar Node podremos levantar nuestro servidor web con un único comando. [80] La sencillez de utilización de este framework, así como la fácil portabilidad que nos aporta Node.js fueron los principales motivos para su utilización.

• Forma de señalización: Websockets con mensajes propietarios Como ya se ha comentado anteriormente WebSocket es una tecnología que proporciona un canal de comunicación bidireccional y full-duplex sobre un único socket TCP. Está diseñada para ser implementada en navegadores y servidores web, pero puede utilizarse por cualquier aplicación cliente/servidor, proporcionando baja latencia en la comunicación cliente-servidor. Esta tecnología también se puede integrar dentro del servidor Node.js, permitiendo integrar en nuestro servidor la señalización y el despliegue web, consiguiendo, como ya se mencionó fácil portabilidad. Se definen por los mensajes que los clientes intercambiarán con el servidor websockets, estando los mismos codificados en JSON, así como el comportamiento que el servidor tendrá en respuesta a dichos mensajes.

• Alimentación de Audio a la aplicación: WebAudio La Web Audio API es una forma de alto nivel de crear y manipular sonido directamente en el navegador a través de JavaScript. Permite ya sea generar audio desde cero o cargar y manipular cualquier archivo de audio. Gracias a esta API JavaScript se puede cargar directamente audios que se encuentran en nuestro servidor y mandarlos mediante la conexión RTCPeerConnection. Desde la página de llamada existe un campo donde podemos introducir la ruta del archivo que queremos utilizar, dicho audio será cargado gracias a una petición XMLHttpRequest [81], el audio cargado quedará a la espera de que se realice o se reciba una llamada y se comenzará a reproducir automáticamente cuando alguno de esos eventos se dé. De esta manera, además de solventar el problema de la carga de audio a la aplicación, también solucionamos otro problema, la sincronización de los audios en ambos extremos, evitando retrasos entre la reproducción de los audios.

• Adaptación del escenario al laboratorio:

Figura 3.5 Escenario de laboratorio planteado

Es necesario señalar que, debido a las limitaciones de tiempo y equipos disponibles, se optó por emplear únicamente un par de equipos para el escenario entre los que se estableció la comunicación. En el escenario final contamos con un equipo servidor, desde donde se ofrece tanto la página web a utilizar como el servidor de señalización WebSockets y dos equipos finales que servirán como clientes, unidos todos en red mediante la utilización de un switch. Todos los equipos del escenario corren sobre Windows 7 Ultimate SP1, SO donde poder ejecutar correctamente Node.js y las herramientas de automatización que se presentan en el próximo capítulo.

48 Implementación del escenario WebRTC

4 PRUEBAS Y RESULTADOS

Silence is Golden. - Ari Gold -

na vez hemos planteado el escenario físico y hemos implementado la solución con WebRTC planteada en el capítulo anterior, Es momento de realizar las pruebas en un escenario real de laboratorio. En este U capítulo se presenta el conjunto de pruebas que se utiliza para medir la calidad que ofrece WebRTC. Se define el conjunto de pruebas a presentar y las herramientas que utilizadas para llevarlas a cabo y, finalmente, los resultados obtenidos.

4.1 Batería de pruebas

El objetivo principal durante el desarrollo del trabajo fue utilizar el mayor número de códecs posibles para comparar las estadísticas obtenidas, pero debido a restricciones del software no todos pudieron ser probados.

4.1.1 Códecs

Finalmente se pudieron utilizar exclusivamente OPUS y G.711(PCMA) en nuestras pruebas:

• G.711 es un estándar de codificación digital para representar una señal de audio en frecuencias de la voz humana, mediante palabras de 8 bits de resolución, con una tasa de 8000 muestras por segundo. Por tanto, el codificador G.711 proporciona un flujo de datos de 64 Kbit/s. [82]

Para conseguir una relación señal a ruido optimizada para señales de voz humana, se utiliza un método de compresión antes de codificar la señal. Cuando la señal es decodificada en el receptor se realiza la operación inversa, es decir, una expansión, para así recuperar la señal original. [83]

• Opus soporta tasas de bits constantes y variables de 6 kbps a 510 kbps, tamaños de trama de 2,5 ms a 120 ms y cinco tasas de muestreo desde 8 kHz (4 kHz audibles) hasta 48 kHz (20 kHz audibles, cubriendo todo el espectro audible).

Opus tiene un algoritmo con un retraso muy bajo (26,5 ms), lo que es muy importante para usarlo como formato de audio en enlaces de comunicaciones, que necesitan una latencia muy baja para permitir la conversación natural en eventos en directo. [84]

50 Pruebas y resultados

4.1.2 Medidas de QoS

La evaluación perceptual de la calidad del habla es una familia de estándares que proporcionan una metodología para la evaluación automática de la calidad de la llamada tal y como la percibiría un usuario del sistema de telefonía. Estas medidas emplean muestras reales de voz como señales para la evaluación de la calidad. Con el objetivo de caracterizar la calidad tal y como la percibiría un usuario humano, es de gran importancia probar los sistemas de telecomunicación con señales de voz reales. Dependiendo de la información que emplea el algoritmo, los algoritmos de testeo de calidad de voz pueden clasificarse en dos categorías principalmente: • Los algoritmos “full reference” (FR) que utilizan una señal de referencia para realizar una comparación con la señal obtenida tras atravesar el sistema de telefonía. Las medidas que ofrecen son las más precisas, pero solo pueden ser aplicadas para test dedicados en redes reales. • Los algoritmos “no reference” (NR) que solo utilizan la señal degradada para la estimación de la calidad de servicio sin tener una referencia de la señal original. Estos algoritmos proporcionan estimaciones de poca precisión ya que las características originales de la voz, como el ruido de fondo o la ausencia de voz en la fuente son completamente desconocidas. Los resultados que proporcionan se miden en la escala MOS (Mean Opinion Score). Esta que mide la calidad experimentada de la llamada escala va desde 1 (mala calidad) hasta 5 (calidad excelente).

Tabla 4–1. Escala MOS para calidad de audio

Nota MOS Calidad Deficiencia

5 Excelente Imperceptible

4 Buena Perceptible pero no molesta

3 Media Levemente molesta

2 Pobre Molesta

1 Mala Muy molesta

Para nuestro estudio utilizaremos dos de los algoritmos de la ITU-T para la evaluación perceptual, uno de ellos “full reference”, P.862, también conocido como PESQ [85] y otro “no reference”, siendo este último P.563 [86].

4.1.2.1 P.563 Se trata de un método de un solo extremo para la evaluación objetiva de la calidad vocal en aplicaciones de telefonía, por lo que emplea algoritmos NR. La implementación que se empleó para evaluar la calidad de servicio de las llamadas es la desarrollada por la propia ITU. Se trata de un programa escrito en C que puede encontrarse en el CD adjunto en la ruta /Software/ T-REC-P.563-200405-I!!SOFT-ZST-E. Este software incluye un conjunto de grabaciones de prueba y un pdf con el desarrollo de la norma que se consultó previamente para la preparación de las muestras de voz a utilizar para la evaluación. El enfoque utilizado en P.563 puede visualizarse como un experto que escucha una llamada real con un dispositivo de prueba, tal como un microteléfono convencional conectado en paralelo a la línea. Esta visualización permite explicar la principal aplicación y permite al usuario clasificar las puntuaciones obtenidas mediante P.563. La puntuación de calidad que se predice mediante P.563 está relacionada con la calidad percibida conectando un microteléfono convencional en el punto de medida. El algoritmo descrito está diseñado exclusivamente para evaluar la voz humana. No puede utilizarse para la evaluación de música, ruido u otras señales de audio no vocales. Aún no se ha validado la aplicabilidad del mismo para una señal vocal cantando transmitida sobre una conexión telefónica. Los requisitos principales que deben cumplir las muestras de voz son los siguientes:

• Frecuencia de muestreo de 8KHz (en el caso de emplear frecuencias mayores es necesario utilizar un filtro paso bajo previamente). • La resolución de amplitud de los audios tiene que ser de 16 bits • Debe haber un mínimo periodo de actividad vocal en la grabación de 3s. • La grabación no debe superar los 20 segundos. • El ratio de habla en la grabación debe superar el 25%. • El ratio de habla en la grabación debe ser inferior al 75%.

Previamente se analizó el audio para comprobar que el ratio de habla estaba dentro de los límites establecidos. Una vez que se obtienen las muestras para su análisis, se ejecuta el programa con el siguiente comando: p563 audiofile.wav –out outfile donde audiofile.wav es el fichero de audio preparado para su evaluación y outfile el fichero en el que se desean volcar los resultados del análisis. Con el objetivo de automatizar las pruebas se codificó un script de bash para realizar la estimación de la calidad de servicio de todas las conversaciones en ambos extremos. Puede encontrarse en el CD adjunto en la ruta /Software/Evaluacion/P563.

4.1.2.2 P.862 Se trata de un método de dos extremos para la evaluación objetiva de la calidad vocal en aplicaciones de telefonía, por lo que emplea algoritmos FR. La implementación que se empleó para evaluar la calidad de servicio de las llamadas es la desarrollada por la propia ITU. Se trata de un programa escrito en C que puede encontrarse en el CD adjunto en la ruta /Software/T- REC-P.862-200511-I!Amd2!SOFT-ZST-E. Este software incluye un conjunto de grabaciones de prueba y un pdf con el desarrollo de la norma que se consultó previamente para la preparación de las muestras de voz a utilizar para la evaluación.

52 Pruebas y resultados

Los requisitos principales que deben cumplir las muestras de voz son los siguientes: • Duración máxima del fichero de audio de 20 segundos. • Duración mínima (recomendada) del fichero de audio de 8 segundos. • El ratio de habla en la grabación debe superar el 40%. • El ratio de habla en la grabación debe ser inferior al 80%. • El formato preferido para el almacenamiento de señales iniciales y degradadas es el de una velocidad de muestreo de 8 kHz, MIC lineal de 16 bits. Previamente se analizó el audio para comprobar que el ratio de habla estaba dentro de los límites establecidos. Una vez que se obtienen las muestras para su análisis, se ejecuta el programa con el siguiente comando: PESQ +8000 reference.wav degraded.wav donde reference.wav es el fichero de audio de referencia, degraded.wav el fichero de audio grabado en uno de los extremos y +8000 indica que la frecuencia de muestreo es de 8KHz (también puede funcionar con frecuencia de muestreo de 16KHz). Con el objetivo de automatizar las pruebas y al igual que en el caso anterior, se codificó un script de bash para realizar la estimación de la calidad de servicio de todas las conversaciones en ambos extremos. Puede encontrarse en el CD adjunto en la ruta /Software/Evaluacion/P862.

Figura 4.1 Diferencias entre métodos de análisis

4.1.3 Audios utilizados

Las conversaciones empleadas proceden de un banco de conversaciones adquirido por el departamento de telemática: Linguistic Data Consortium de la Universidad de Pennsylvania. Se dispone de 3 grabaciones de 30 minutos por parte de dos extremos [87]. Las grabaciones cumplen los requisitos marcados por P.563 y P.862 con respecto a porcentajes de habla y de silencio en la gran mayoría de su duración. Para no sobrecargar el navegador se dividen las grabaciones en fragmentos de 1 minuto para su posterior reproducción en las pruebas. Cabe recordar que para realizar las pruebas de calidad hay que utilizar audios de como máximo 20 segundos, en este caso contamos con 6 grabaciones de 30 minutos, eso nos reportará material para realizar 540 tests de calidad con cada uno de los códecs.

Figura 4.2 Primera conversación mostrada con Audacity

4.2 Obtención de resultados

En este apartado se introduce la herramienta utilizada para automatizar las pruebas, así como el funcionamiento de las mismas. También se hablará de la preparación previa necesaria a realizar sobre los audios recibidos con objeto de realizar las pruebas de calidad correctamente. Todos los scripts de automatización pueden encontrarse en el Anexo B, así como en el CD adjunto en la ruta /Software/Evaluacion/

54 Pruebas y resultados

4.2.1 Software de automatización

Para la automatización de las pruebas se utilizó la herramienta Selenium Webdriver: Selenium WebDriver es el sucesor de anterior producto, Selenium RC. Selenium WebDriver acepta comandos y los envía a un navegador. Esto se implementa a través de un controlador del navegador específico para cada navegador que envía los comandos y trae los resultados de regreso. La mayoría de los controladores del navegador lanzan y acceden a la aplicación de navegador (como Mozilla Firefox o Internet Explorer), en Selenium WebDriver no se requiere de un servidor especial para ejecutar las pruebas, en vez de ello WebDriver inicia una instancia del navegador y lo controla. Desde inicios de 2012, Simon Stewart de Google (inventor del WebDriver) y David Burns de la Fundación Mozilla se encuentran negociando con el W3C que WebDriver se convierta en un estándar de Internet. Selenium-WebDriver está completamente implementado y soportado en Java, Ruby, Python y C#. Selenium intenta proveer de los bloques de construcción básicos con los cuales los desarrolladores puedan programar su propio lenguaje específico de dominio. [88] En nuestro caso específico utilizamos Selenium mediante el lenguaje de scripting Python con el controlador de navegador específico para Google Chrome. Existen 3 scripts distintos para nuestras pruebas, 1 para PCMA y otro para OPUS, para el ordenador emisor de la llamada, y un script para el usuario receptor de la llamada. Los scripts son iguales hasta cierto punto en el cual el que realiza la llamada tiene que realizar ciertos pasos más, a continuación, se describe el proceso que se lleva a cabo en pseudocódigo:

Figura 4.3 Pseudocódigo de automatización

Este proceso se realizará en bucle 90 veces alternando entre los 30 audios que componen cada grabación para los 3 audios distintos en los dos extremos. 54

Se recuerda que no es necesario la aceptación de la llamada ya que nuestra aplicación realiza automáticamente dicha aceptación. Para realizar la grabación de la llamada se utilizó el software Virtual Audio Cable [89] para redirigir la salida de los altavoces al micrófono. Posteriormente fue grabado con la utilidad SoundRecorder.exe incluida en el sistema Windows 7 y accesible en C:/Windows/System32/SoundRecorder.exe. Aunque los audios enviados son de 60 segundos se graban 70 en cada caso por los posibles retrasos que se puedan producir. Los audios grabados se guardarán en el mismo lugar desde donde se lancen los scripts de automatización, en este caso por comodidad se utilizó el editor PyCharm Community Edition para poder editar directamente los scripts y ejecutarlos con facilidad.

4.2.2 Preparación de audios y ejecución de análisis.

Una vez ya recolectadas todas las grabaciones de los ordenadores es necesario preparar los audios para su posterior análisis con P.563 y P.862. Los ficheros grabados tenían el formato recibidoX_Y.wav donde X es el audio al que pertenecen e Y la parte del mismo. Todas las preparaciones que se realizan sobre los audios se realizaron utilizando el programa Sound eXchange (sox), un software multiplataforma gratuito de línea de comando [90] y automatizado su uso mediante script de bash (.sh) o de Python (.py). Primeramente, se necesita cortar dichos ficheros en partes de 20 segundos, máxima duración permitida por nuestros softwares de medida de calidad. Para dicha tarea existe el script cortarecibidos.sh que lo pasará al formato recibido_Z.wav donde Z es el número del 1 al 90 de dicho conjunto de audios. Este script debe ser modificado para cada conjunto de X. Una vez tenemos el conjunto de 90 audios correspondiente a un audio de 30 minutos completo y con el formato recibido_Z.wav, se debe pasar el audio de formato estéreo, en el que se graba por defecto en Windows 7, a mono, y también es necesario aplicar un filtro paso bajo a 8Khz. Para esta tarea existen los scripts stereo_mono.py y cambioa8k.py que ejecutados en ese orden realizarán los cambios pertinentes y mantendrá el formato de nombre. Es necesario también comprobar que todos los ficheros utilizados se encuentran muestreados a 16 bits, en nuestro caso los ficheros recibidos ya se encontraban en dicho formato, pero si fuera necesario se puede comprobar este hecho con el comando: soxi fichero_a_analizar.wav Con ello se desplegará toda la información del fichero del cual se necesite conocer características. Si tras ello fuera necesario cambiar el fichero a 16 bits se podría llevar a cabo mediante el comando: sox input.wav -b 16 output.wav Una vez que ya los ficheros están convenientemente adaptados, solamente quedaría la realización de los análisis sobre los ficheros. Para P.563 existe el script de bash P563.sh que se encarga de analizar todos los audios con formato recibido_Z.wav y de depositar los resultados en un fichero de texto plano llamado resultados.txt. Para P.862 existe el fichero PESQ.sh. En este caso al tratarse de un algoritmo Full-Reference es necesario que estén todos los audios originales que fueron enviados para poder realizar el análisis. El script espera encontrar, además de los ficheros recibido_Z.wav, los ficheros originales correspondientes con el formato originalZ.wav donde Z de nuevo es el número del 1 al 90 correspondiente a cortar los audios de 30 minutos en partes de 20 segundos. Una vez se ejecute el script el resultado completo de la ejecución estará en el fichero resultados.txt, para conseguir una fácil lectura de los datos se recomienda utilizar el comando: grep PESQ_MOS resultados.txt > nombredeseado.txt Que eliminará todo el texto introducido por el software dejando solamente el resultado en la escala MOS.

56 Pruebas y resultados

4.3 Estadísticas obtenidas

Este apartado se centrará en el análisis de los resultados obtenidos tras la realización de las pruebas, con el objetivo de obtener estadísticas y parámetros que nos permitan determinar la calidad ofrecida por la API WebRTC en la realización de llamadas de voz.

4.3.1 P.563

Tras analizar los ficheros de salida generados por el script P.563.sh y exportar sus datos a un documento de Excel se pudo observar que las gráficas obtenidas no reflejaban el comportamiento esperado y observado, a pesar de haber seleccionado fragmentos de audio que cumplían con las especificaciones requeridas. Se realizaron pruebas tomando los mismos recortes del audio original, y en algunos casos se ofrecían valores aceptables mientras que en otros casos los valores eran completamente erróneos. Debido a la falta de tiempo se decidió no indagar más a cerca de una posible solución para centrar todo el esfuerzo en los demás apartados. Como ya se comentó, P.563 es un algoritmo sin referencia, estos algoritmos proporcionan estimaciones de poca precisión ya que las características originales de la voz, como el ruido de fondo o la ausencia de voz en la fuente son completamente desconocidas. Se sospecha que puede guardar alguna relación con el nivel de volumen de las señales procesadas, lo cual se asumía que sería ajustado por el propio software de la ITU. Es probable también que dichos problemas sean debido a la gran cantidad de ruido presente en las grabaciones y a la poca calidad de los mismos. Dichos problemas no se presentaron en el algoritmo Full-Reference P.862, hecho que apoya esta última posibilidad.

Figura 4.4 Ejemplo de notas obtenidas con P.563 para un audio

4.3.2 P.862

En comparación a los resultados anteriores, las pruebas con P.862 o PESQ si arrojaron resultados consistentes para ambos códecs utilizados.

Las gráficas que se presentan en este apartado corresponden al segundo de los audios enviados por parte del ordenador que realiza la llamada, se utiliza el mismo en los dos casos para facilitar la comparación.

4.3.2.1 OPUS Para el códec OPUS se obtuvieron los siguientes resultados con respecto a la nota MOS: • Media: 4,150953704 • Varianza: 0,076554159 • Desviación Estándar: 0,276684222

Figura 4.5 Notas obtenidas con P.862 y códec OPUS

Dichas notas nos presentan un buen resultado, ya que las notas más altas que se pueden obtener se suponen alrededor del 4,5 [91]. En el gráfico se observa el comportamiento esperado alrededor de la media, con algunas bajadas, debido a que en dichas secciones de audio no se cumplen los requisitos de tiempo de habla por un pequeño margen.

58 Pruebas y resultados

4.3.2.2 PCMA Para el códec PCMA o G.711 se obtuvieron los siguientes resultados con respecto a la nota MOS: • Media: 4,21685 • Varianza: 0,081825883 • Desviación Estándar: 0,286052238

Figura 4.6 Notas obtenidas con P.862 y códec PCMA

De nuevo las notas obtenidas nos presentan notas cercanas al límite de 4,5 y las mismas bajadas de nota ya explicadas para el caso de OPUS al tratarse del mismo audio analizado.

4.3.2.3 Resultados generales Considerando toda la población de muestras tanto de OPUS como de PCMA se consiguen los siguientes resultados:

• Media: 4,183901852 • Varianza: 0,080275601 • Desviación Estándar: 0,283329493 A continuación, se ofrecen los resultados de media y varianza para todos los audios analizados:

Tabla 4–2. Resultados para cada audio

Media OPUS Varianza OPUS Media PCMA Varianza PCMA

Receptor Audio 1 4,1849 0,062604 4,2694 0,070310

Receptor Audio 2 4,1565 0,073120 4,2317 0,071661

Receptor Audio 3 4,2090 0,038326 4,2464 0,044705

Emisor Audio 1 4,0345 0,155045 4,1382 0,173748

Emisor Audio 2 4,1767 0,043859 4,2190 0,050896

Emisor Audio 3 4,1441 0,067541 4,1964 0,06917

60 Pruebas y resultados

5 CONCLUSIONES Y LÍNEAS DE AVANCE

Education is an admirable thing, but it is well to remember from time to time that nothing that is worth knowing can be taught. - Oscar Wilde -

na vez realizada la exposición y el análisis de los resultados obtenidos tras ser procesados con el software adecuado, llega el momento de recapitular y mostrar las conclusiones obtenidas, así como, presentar las U líneas de avance que se podrían plantear para el futuro.

5.1 Conclusiones

Este proyecto se planteó inicialmente como un procedimiento de evaluación de calidad y de rendimiento de la API WebRTC en diversos escenarios, sin embargo, la fase de investigación se alargó bastante más de lo esperado, principalmente debido a la gran cantidad de opciones existentes para la implementación, así como por el desarrollo una aplicación web que cumpliera todos los requisitos necesarios para nuestras pruebas. El desarrollo de la aplicación web resultó más largo de lo esperado debido a dos problemas principales, el tratamiento de los SDP para poder elegir códec en un entorno web y por la forma de alimentar audio a la aplicación. Estas dificultades tuvieron como consecuencia una reducción en el alcance del proyecto, ya que inicialmente se pretendía utilizar varios terminales en paralelo sobre una red con tráfico simulado. Teniendo en cuenta los problemas y limitaciones encontradas, se ha intentado simplificar al máximo el proceso de instalación del servidor, así como el procedimiento de recogida de datos. Esta simplicidad se ha buscado con el objetivo de que los experimentos se puedan repetir en el futuro con varios terminales sin la necesidad de realizar grandes cambios. En cuanto a las conclusiones principales del proyecto se pueden señalar las siguientes: La tecnología WebRTC permite la comunicación en tiempo entre pares y entre múltiples usuarios, compartir recursos y permite integrarla fácilmente en cualquier sistema con una arquitectura cliente-servidor. Brinda al programador las herramientas necesarias para acceder los recursos de la máquina y realizar aplicaciones de conexión punto a punto y/o en broadcast entre usuarios. Desde el punto de vista del usuario esta tecnología es transparente y muy usable puesto que no se tienen que instalar plugins ni programas adicionales, solo necesita un navegador o una aplicación compatible con WebRTC. La implantación de esta tecnología en arquitecturas PaaS es muy sencilla y su implementación en distintos lenguajes de programación es irrelevante porque el proceso de señalización es el mismo para configurar los servicios de WebRTC. WebRTC se puede integrar en plataformas Node.js, Java, Python, .NET... en cualquier tecnología que permita la integración de Sockets.

62 Conclusiones y líneas de avance

Esta tecnología cuenta con apoyo por parte de la industria de desarrollo web y de los organismos de normalización, y cada vez más, por parte de la industria de las telecomunicaciones, pieza clave en la implantación a gran escala. La gran cantidad de casos de uso en todos los ámbitos también avala la expansión del uso de WebRTC para suplir sus necesidades con bajo coste, ya sea en ámbitos ya explorados como la telemedicina o en otros campos como la industria del videojuego. Con respecto a la calidad de servicio de la aplicación se han obtenido notas, en la escala MOS, cercanas al 4,2, calidad cercana a la máxima alcanzable para los códecs utilizados. Implicando buena calidad con cambios sobre el audio percibibles, pero no molestos. Como valoración subjetiva, al realizar una escucha de los audios originales y recibidos tras las pruebas, no se apreciaron diferencias remarcables entre ellos. Estas notas también sirven para defender el uso de la tecnología en aquellos ámbitos donde lo transmitido sea voz humana, así pues, WebRTC se presenta como una buena alternativa en una gran cantidad aplicaciones, consiguiendo resultados como los que se conseguirían con una alternativa de pago, pero de forma gratuita y con la ventaja de no necesitar instalación ya sea de plugins o aplicaciones. Todavía es necesario que la tecnología madure, ya que se trata una tecnología joven, y que se afiance el conocimiento en la industria, con desarrolladores expertos que permitan que esta implantación se lleve a cabo. Con todo esto, WebRTC cumple los requisitos de calidad necesarios para avanzar, ya solo es necesario que se deposite confianza en ella.

5.2 Líneas de avance

Como se comentó en el apartado anterior, debido a las dificultades que fueron surgiendo, hay partes del proyecto que no se han podido desarrollar, por ello, se detallan a continuación una serie de puntos que se podrían llevar a cabo en el futuro:

• Repetir las pruebas con más códecs, especialmente para probar las diferencias al utilizar diferentes frecuencias como podrían ser G.729 o iLBC para banda estrecha, G.722 para banda ancha e iSAC para banda ancha y superancha.

• Una investigación podría ser ampliar el número de terminales realizando llamadas de voz de forma simultánea dentro de la misma red, pudiéndose ampliar esta también con equipos conectados de forma inalámbrica. La complejidad debería residir en la sincronización de los relojes de los equipos para conseguir la ejecución de los scripts de forma simultánea.

• Dentro de los avances en la red del sistema se podría utilizar tráfico simulado en la red para reproducir de forma fiel un ambiente productivo real, de esta forma sería posible probar la solidez de la tecnología frente a la escasez de recursos de red, permitiendo con ello también medir, por ejemplo, los ajustes realizados por el códec OPUS es estos casos.

• Podría resultar de gran ayuda la grabación o adquisición de un uno banco de audio para realizar las pruebas, ya que, aunque para metodologías Full-Reference como P.862 no presente problemas el banco actual en la mayoría de muestras, las metodologías No-Reference como P.563 ven su funcionamiento alterado debido a que en los audios hay una gran cantidad de ruido de fondo y las voces grabadas tampoco son de la mejor calidad.

• No todas las herramientas que ofrece WebRTC han sido probadas, se podría utilizar en profundidad también los otros elementos como getUserMedia, así como el canal de datos que se nos ofrece, pudiendo estudiarse la selección y utilización de diversos recursos de forma conjunta, así como el uso del canal de datos para el envío de ficheros.

• En el planteamiento inicial del proyecto también se meditó la utilización de teléfonos VoIP, para ello sería necesario un cambio en la señalización a SIP mediante websockets o la utilización de una pasarela de señalización que transformara los mensajes al formato SIP.

• Si la expansión de esta tecnología finalmente sucede, será importante realizar estudios de seguridad sobre la misma, aunque ya existen algunos estudios [92] [93] la tecnología seguirá avanzando, así como nuevas formas de comprometer la seguridad de los componentes relacionados.

• En nuestro caso solamente se utilizó una red local para la realización de las pruebas, eso elimina una tecnología normalmente asociada a WebRTC, los servidores STUN y TURN, el escenario de pruebas podría modificarse también para utilizar NATs y con ello probar el funcionamiento y las limitaciones de dichas tecnologías.

64 Conclusiones y líneas de avance

REFERENCIAS

[1] M. H. Rahaman, «A Survey on Real-Time Communication for Web,» Scientific Research Journal (SCIRJ), Volume III, Issue VII, July 2015 , 2015.

[2] D. Cassel, «JavaScript Popularity Surpasses Java, PHP in the Stack Overflow Developer Survey,» [En línea]. Available: https://thenewstack.io/javascript-popularity-surpasses-java-php-stack-overflow- developer-survey/.

[3] T. Hösli. [En línea]. Available: https://blog.talkbase.com/en/why-webrtc-is-so-important-for-unified- communications/.

[4] Tech Faq, «How to Measure Sound Quality,» [En línea]. Available: http://www.tech-faq.com/how-to- measure-sound-quality.html.

[5] «Wikipedia,» [En línea]. Available: https://en.wikipedia.org/wiki/Global_IP_Solutions.

[6] S. Dutton, «HTML5Rocks,» [En línea]. Available: https://www.html5rocks.com/en/tutorials/webrtc/basics/.

[7] T. Levent-Levi, «BlogGeek,» [En línea]. Available: https://bloggeek.me/webrtc/.

[8] S. Håkansson, «Ericsson,» [En línea]. Available: https://www.ericsson.com/research-blog/context-aware- communication/beyond-html5-peer-peer-conversational-video/.

[9] «Wiki WHATWG,» [En línea]. Available: https://wiki.whatwg.org/wiki/FAQ.

[10] H. Alvestrand, «lists.w3.org,» 1 Junio 2011. [En línea]. Available: http://lists.w3.org/Archives/Public/public-webrtc/2011May/0022.html.

[11] «IETF,» [En línea]. Available: https://datatracker.ietf.org/wg/rtcweb/charter/.

[12] W3C. [En línea]. Available: https://www.w3.org/TR/webrtc/.

[13] W3C. [En línea]. Available: https://www.w3.org/2011/04/webrtc/.

[14] «Wikipedia,» [En línea]. Available: https://en.wikipedia.org/wiki/WebRTC.

[15] T. Levent-Levi, «Bloggeek,» [En línea]. Available: https://bloggeek.me/webrtc-market-2017/.

[16] «TechTarget,» [En línea]. Available: http://searchunifiedcommunications.techtarget.com/essentialguide/Understand-WebRTC-basics-to- maximize-deployment-and-adoption#guideSection2.

[17] T. IO. [En línea]. Available: http://iswebrtcreadyyet.com/.

[18] IETF, «RFC 7478,» [En línea]. Available: https://tools.ietf.org/html/rfc7478.

66 Referencias

[19] IETF, «RFC 7675,» [En línea]. Available: https://tools.ietf.org/html/rfc7675.

[20] IETF, «RFC 7742,» [En línea]. Available: https://tools.ietf.org/html/rfc7742.

[21] IETF, «RFC 7874,» [En línea]. Available: https://tools.ietf.org/html/rfc7874.

[22] IETF, «RFC 7875,» [En línea]. Available: https://tools.ietf.org/html/rfc7875.

[23] W3C, «W3C WebRTC,» [En línea]. Available: https://www.w3.org/standards/techs/webrtc#w3c_all.

[24] «Twilio WebRTC,» [En línea]. Available: https://www.twilio.com/webrtc.

[25] «Veeting Rooms WebRTC,» [En línea]. Available: https://www.veeting.com/en/.

[26] T. Levent-Levi, «Blogeek,» [En línea]. Available: https://bloggeek.me/webrtc-business-online/ch11/.

[27] «Regroup Therapy,» [En línea]. Available: https://www.regrouptherapy.com/about-us.

[28] «TruClinic,» [En línea]. Available: https://www.truclinic.com/platform/.

[29] J. Mourer, «https://getkey.eu/blog/ WebRTC Gaming Article,» [En línea]. Available: https://getkey.eu/blog/5862b0cf/webrtc:-the-future-of-web-games.

[30] «news.ycombinator.com WebRTC gaming discussion,» [En línea]. Available: https://news.ycombinator.com/item?id=13264952.

[31] A. Zakai, «BananaBrain,» [En línea]. Available: http://kripken.github.io/misc-js- benchmarks/banana/index.html.

[32] N. Beauvais, «WebRTC Snake,» [En línea]. Available: http://nicolas-beauvais.com/Snake/.

[33] A. M. Øygard, «headtrackr,» [En línea]. Available: https://github.com/auduno/headtrackr/.

[34] T. Levent-Levi, «Blogeek Gaming,» [En línea]. Available: https://bloggeek.me/webrtc-gaming/.

[35] «XyrSys,» [En línea]. Available: https://xirsys.com/.

[36] «About Solaborate,» [En línea]. Available: https://www.solaborate.com/public/AboutSite.

[37] «Peer5 FAQ,» [En línea]. Available: https://www.peer5.com/faq.

[38] «WebRTC School FAQ,» [En línea]. Available: https://www.webrtcschool.com/faqs.

[39] S. Anderson, «Is it Wrong to Compare Skype to WebRTC?,» [En línea]. Available: http://conferencing.tmcnet.com/topics/conferencing/articles/420417-it-wrong-compare-skype- webrtc.htm.

[40] «300 Monthly Million Users Skype,» [En línea]. Available: https://mspoweruser.com/skype-300-million- monthly-active-users/.

[41] «Skype Bussiness,» [En línea]. Available: https://www.skype.com/es/business/.

[42] «Skype for Linux WebRTC,» [En línea]. Available: https://community.skype.com/t5/Linux/Skype-for- Linux-Alpha-and-calling-on-Chrome-amp-Chromebooks/td-p/4434299.

[43] «Presentación Opus por Skype,» [En línea]. Available: https://blogs.skype.com/stories/2012/09/12/skype- and-a-new-audio-codec/.

[44] «iDataLabs Skype,» [En línea]. Available: https://idatalabs.com/tech/products/skype#.

[45] «Flash Video Encoding,» [En línea]. Available: https://en.wikipedia.org/wiki/Flash_Video#Encoding.

[46] «Adobe Flash Player CVE Page,» [En línea]. Available: http://www.cvedetails.com/product/6761/Adobe- Flash-Player.html?vendor_id=53.

[47] «Vulnerabilidad Adobe Flash Ejecución Codigo Remoto,» [En línea]. Available: http://www.securityfocus.com/bid/35759.

[48] «Kaspersky 3Q 2012 Security Report,» [En línea]. Available: https://securelist.com/it-threat-evolution- q3-2012/36692/.

[49] S. Jobs, «Thoughts on Flash,» April 2010. [En línea]. Available: https://www.apple.com/hotnews/thoughts-on-flash/.

[50] J. Vincent, «Facebook's new chief security officer wants to set a date to kill Flash,» Julio 2015. [En línea]. Available: https://www.theverge.com/2015/7/13/8948459/adobe-flash-insecure-says-facebook-cso.

[51] S. Dutton, «WebRTC in the real world: STUN, TURN and signaling,» [En línea]. Available: https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/#what-is-signaling.

[52] V. Cerf, Y. Dalal y C. Sunshine, «SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM,» [En línea]. Available: https://tools.ietf.org/html/rfc675.

[53] «RFC The WebSocket Protocol,» [En línea]. Available: https://tools.ietf.org/html/rfc6455.

[54] «HTML Living Standard Websockets,» [En línea]. Available: https://html.spec.whatwg.org/multipage/web-sockets.html#network.

[55] M. U. a. E. Kitamura, «Introducción a los WebSockets: incorporación de sockets a la Web,» [En línea]. Available: https://www.html5rocks.com/es/tutorials/websockets/basics/.

[56] «www.websocket.org : About HTML5 WebSocket,» [En línea]. Available: https://www.websocket.org/aboutwebsocket.html.

[57] L. Slattery, «The impact of Google’s new Chrome security policy on WebRTC,» [En línea]. Available: https://tokbox.com/blog/the-impact-of-googles-new-chrome-security-policy-on-webrtc/.

[58] IETF, «Session Traversal Utilities for NAT (STUN) RFC,» [En línea]. Available: https://tools.ietf.org/html/rfc5389.

[59] IETF, «Traversal Using Relays around NAT (TURN) RFC,» [En línea]. Available:

68 Referencias

https://www.ietf.org/rfc/rfc5766.txt.

[60] «Guia de libjingle para construir aplicaciones peer-to-peer,» [En línea]. Available: https://developers.google.com/talk/libjingle/important_concepts#candidates.

[61] IETF, « Interactive Connectivity Establishment (ICE) RFC,» [En línea]. Available: https://tools.ietf.org/html/rfc5245.

[62] M. F. Pérez, EVALUACIÓN Y OPTIMIZACIÓN DEL CONSUMO DE RECURSOS EN VoWIFI, 2016.

[63] IETF, «The Secure Real-time Transport Protocol (SRTP) RFC,» [En línea]. Available: https://tools.ietf.org/html/rfc3711.

[64] O'Reilly Media, Inc, «Acquiring Audio and Video with getusermedia,» [En línea]. Available: https://hpbn.co/webrtc/#acquiring-audio-and-video-with-getusermedia.

[65] IETF, «Stream Control Transmission Protocol,» [En línea]. Available: https://tools.ietf.org/html/rfc4960.

[66] O'Reilly Media, Inc, «WebRTC Datachannel,» [En línea]. Available: https://hpbn.co/webrtc/#datachannel.

[67] WebRTC, «WebRTC Native APIs y diagramas de flujo,» [En línea]. Available: https://webrtc.org/native- code/native-apis/.

[68] W3C, «Call Flow Browser to Browser - W3C,» [En línea]. Available: https://www.w3.org/TR/webrtc/#call-flow-browser-to-browser.

[69] A. Brault, «Introducing SimpleWebRTC.js and conversat.io,» [En línea]. Available: https://blog.andyet.com/2013/02/22/introducing-simplewebrtcjs-and-conversatio/.

[70] andyet, «GitHub de SimpleWebRTC,» [En línea]. Available: https://github.com/andyet/SimpleWebRTC.

[71] andyet, «Talky.io,» [En línea]. Available: https://talky.io/.

[72] «Documentación EasyRTC,» [En línea]. Available: https://easyrtc.com/docs/easyrtc_gettingStarted.php#what-is-easyrtc-opensource.

[73] «Demos EasyRTC,» [En línea]. Available: https://demo.easyrtc.com/demos/index.html.

[74] «Tawk,» [En línea]. Available: https://www.tawk.to/.

[75] Netcraft, «Estudio sobre servidores web Netcraft Julio 2014,» [En línea]. Available: https://news.netcraft.com/archives/2014/07/31/july-2014-web-server-survey.html.

[76] «Nginx, alternativa a apache,» [En línea]. Available: https://blog.desdelinux.net/nginx-una-interesante- alternativa-a-apache/.

[77] T. Sheffler, «Futuro de SIP en WebRTC,» [En línea]. Available: http://www.sightcall.com/future-of-sip- in-webrtc/.

[78] T. Levent-Levi, «Protocolos de señalización para WebRTC,» [En línea]. Available: https://bloggeek.me/siganling-protocol-webrtc/.

[79] WebRTC, «Notas de interoperabilidad de WebRTC,» [En línea]. Available: https://webrtc.org/web- apis/interop/.

[80] Fundación Node.js, «Express,» [En línea]. Available: http://expressjs.com/es/.

[81] Mozilla Foundation, «API XMLHttpRequest,» [En línea]. Available: https://developer.mozilla.org/en- US/docs/Web/API/XMLHttpRequest.

[82] ITU-T, «Recomendación G.711,» [En línea]. Available: http://www.itu.int/rec/T-REC-G.711/es.

[83] VoipFoto, «Funcionamiento de un codec - G711,» [En línea]. Available: http://www.voipforo.com/codec/codec-g711--ley.php.

[84] IETF, «https://tools.ietf.org/html/rfc6716,» [En línea]. Available: https://tools.ietf.org/html/rfc6716.

[85] ITU-T, «Recomendación P.862 (PESQ),» [En línea]. Available: http://www.itu.int/rec/T-REC-P.862/es.

[86] ITU-T, «Recomendación P.563,» [En línea]. Available: http://www.itu.int/rec/T-REC-P.563/es.

[87] [En línea]. Available: https://www.ldc.upenn.edu/.

[88] Seleniumhq, «Selenium Webdriver,» [En línea]. Available: http://www.seleniumhq.org/projects/webdriver/.

[89] [En línea]. Available: http://www.vb-audio.com/Cable/index.htm.

[90] C. Bagwell. [En línea]. Available: http://sox.sourceforge.net/.

[91] VoiceHost, «Measuring VoIP Call Quality,» [En línea]. Available: https://www.voicehost.co.uk/help/call- quality-mos-or-mean-opinion-scores.

[92] NTT Communication, «A Study of WebRTC Security,» [En línea]. Available: http://webrtc- security.github.io/.

[93] Altanai Bisht, «WebRTC Security,» [En línea]. Available: https://telecom.altanai.com/2015/04/24/webrtc-security/.

70 Referencias

ANEXO A: CONFIGURACIÓN Y USO DEL ENTORNO

A.1 Configuración del Servidor.

A.1.1) Servidor Web

Para desplegar nuestro servidor Web primeramente tenemos que instalar el framework Node.js sobre el que se sustentará.

Para el equipo servidor se puede utilizar cualquier sistema operativo donde sea posible instalar Node.js, el instalador correspondiente a cada SO se puede encontrar en https://nodejs.org/es/download/ , en nuestro caso particular se ha trabajado con la versión 6.9.2 de Node.js.

Para que la aplicación funcione es necesario modificar el fichero client.js dentro de la carpeta Servidor:

Figura A.1 Configuración IP señalización

En la línea resaltada es necesario modificar la dirección IP que aparece con la del equipo Servidor, de esta forma, el javascript cliente se conectará con el servidor Websocket de nuestra aplicación. Con nuestra configuración correcta, procedemos a desplazarnos desde el Símbolo del sistema hasta la carpeta Servidor, donde para iniciarlo solamente es necesario ejecutar lo siguiente:

Figura A.2 Inicio del Servidor

72 ANEXO A: CONFIGURACIÓN Y USO DEL ENTORNO

A.1.2) Uso de la Web

Se enseña el uso de la aplicación para realizar una llamada a otro usuario:

Desde el navegador Google Chrome navegamos hasta https://direccionIpServidor:8000 y tras aceptar los problemas relativos a certificados se mostrará la siguiente página de registro:

Figura A.3 Página registro

En esta página se introduce el nombre deseado y pulsa Sign in tras lo cual se mostrará la página principal de la aplicación:

Figura A.4 Página de llamada

En esta página es posible cambiar el códec elegido para las pruebas, estando elegido por defecto Opus, al hacer click sobre este, se desplegarán las opciones de códec configuradas.

Para realizar una llamada es necesario introducir el nombre del usuario registrado a llamar en el campo username to call, en el campo Audio to play se introduce la ruta del audio elegido, estos audios se encuntrarán dentro de la carpeta Servidor en el equipo que actua como tal y con base en dicha carpeta, por ejemplo, si el audio se encuentra en la ruta /home/prueba/Servidor/audio/canal1/audio.wav es necesario introducir lo siguiente: audio/canal1/audio.wav.

Tras elegir el audio, es necesario pulsar el botón Carga Audio y esperar en función al tamaño del audio seleccionado, tras ello, al pulsar el botón Call se inicia la llamada con el usuario elegido

A.1.3) Modificación de códecs para pruebas

En caso de necesitar modificar los códecs disponibles se pude hacer de forma sencilla modificando el fichero index.html:

Figura A.5 Codecs disponibles

Solo es necesario introducir un nuevo campo de opciones y en el campo value introducir correctamente la identificación del códec deseado, para ver los códecs soportados por el navegador en la página de llamada hacemos click derecho en una zona vacia de la página, pulsamos en Inspeccionar y en el menú que se nos despliega elegir la pestaña Consola, cuando iniciemos una llamada se nos mostrará el SDP intercambiado de la siguiente forma:

Figura A.6 Codecs soportados De esta forma podemos observar por ejemplo OPUS identificado como opus, G.722 como G722 etc, obteniendo la correcta selección de códec.

74 ANEXO A: CONFIGURACIÓN Y USO DEL ENTORNO

A.2 Configuración de los clientes.

Para los clientes se ha utilizado Windows 7 Service Pack 1 para las pruebas debido a la existencia del programa Soundrecorder, utilizable por línea de comando en C:/Windows/System32/SoundRecorder.exe A.2.1) Instalación de Python. Es necesaria la instalación de Python 3 de 32 bits para la realización de las pruebas, dicho instalador se encuentra disponible en: https://www.python.org/downloads/ , pudiendo realizarse la instalación simple:

Figura A.7 Instalacion Python 3

A.2.2) Instalación de Selenium y descarga de Chromedriver. Para poder controlar correctamente el navegador en orden de automatizar las pruebas necesitaremos instalar Selenium para Python y descargar la versión de Chromedriver correspondiente a la versión de Google Chrome que tengamos instalada. Para instalar selenium solamente tendremos que ejecutar el siguiente comando en el símbolo del sistema:

Figura A.8 Instalacion Selenium

Con este comando el gestor de paquetes de Python (pip) realizará la instalación. La versión de Chromedriver se encuentra en https://chromedriver.storage.googleapis.com/index.html , en la cual se nos muestran las distintas versiones del mismo las compatible de Chrome. Este fichero debe localizarse en el mismo lugar desde donde se ejecutarán los scripts de automatización de las pruebas.

A.2.3) Instalación y configuración de Virtual Audio Cable:

Para poder realizar la grabación correcta del audio recibido, es necesario el uso de un cable virtual que redirija el audio desde los altavoces de forma digital para conseguir la menor degradación posible.

En nuestro caso se utiliza Virtual Audio Cable, software gratuito disponible para su descarga en: http://www.vb- audio.com/Cable/

Una vez realizada la instalación como administrador y tras reiniciar el ordenador aparecerán nuevos dispositivos de reproducción y grabación:

Figura A.9 Cables virtuales

Otro dispositivo de la misma clase aparecerá en la pestaña Grabar, tendremos que seleccionarlos y predeterminarlos, de esta forma, nuestros cables virtuales estarán correctamente configurados para comenzar a grabar el audio recibido.

76 ANEXO A: CONFIGURACIÓN Y USO DEL ENTORNO

A.2.4) Ejecución de las pruebas:

Una vez tenemos ya toda la configuración realizada en ambos clientes podemos comenzar las pruebas.

Contamos con 3 scripts distintos para la realización de las pruebas, dos para el cliente emisor, siendo cada uno de ellos para uno de los códecs utilizados, y uno para el cliente receptor.

En la siguiente figura se observa el pseudocódigo que siguien estos scripts:

Figura A.10 Pseudocódigo de automatización

Para el usuario emisor existen los ficheros: Conexión log y llamada PCMA.py y Conexión log y llamada.py , siendo este último aquel correspondiente al códec OPUS.

Para el usuario receptor existe el fichero Conexión y log en página.py

Dichos scripts deben ser modificados para recuperar la página correspondiente a la dirección IP donde se encuentra desplegado el Servidor.

Una vez se ejecuten dichos scripts de forma sincronizada en ambos equipos, se comenzarán a ejecutar las pruebas y los audios recibidos se almacenarán el en directorio desde donde se ejecuten los mismos.

A.2.5) Modificación de los scripts:

Estos scripts de automatización pueden ser cambiados de forma sencilla para adecuarlos a la IP del servidor y para elegir distintos códecs:

Para cambiar la IP del servidor solo es necesario cambiar la siguiente dirección IP a la deseada:

Figura A.11 Cambio IP scripts Para cambiar el códec que se selecciona en el lado emisor solo es necesario poner el valor deseado en el campo select_by_value:

Figura A.12 Cambio Codec scripts

78 ANEXO A: CONFIGURACIÓN Y USO DEL ENTORNO

GLOSARIO

AMF: Action Message Format. 17 API: Application Programming Interfaces. 2 CPaaS: Communication Platform as Service. 9 CSS: Cascading Style Sheets. 2 FLV: Flash Video. 17 GIF: Graphics Interchange Format. 17 GIPS: Global IP solutions. 5 HTML: Hypertext Markup Language 2 HTTP: Hypertext Transfer Protocol 1 ICE: Interactive Connectivity Establishment. 19 IETF: Internet Engineering Task Force. 6 iLBC: Internet Low Bitrate Codec. 5 iSAC: Internet Speech Audio Codec. 5 JPEG: Joint Photographic Experts Group. 17 JSON: JavaScript Object Notation. 17 MOS: Mean Opinion Score. 50 NAT: Network Address Translation. 13 P2P: Peer to Peer. 11 PBX: Private Brand Exchange. 12 PNG: Portable Network Graphics. 17 RTC: Real Time Communication 1 SaaS: Service as Service. 13 SDP: Session Description Protocol. 19 SFW: Small Web Format. 17 SIP: Session Initiation Protocol. 12 SRTP: Secure Real-time Transport Protocol. 19 STUN: Session Traversal Utilities for NAT. 8 TCP: Transmission Control Protocol. 19 TURN: Traversal Using Relays around NAT. 19 UDP: User Datagram Protocol. 19 W3C: World Wide Web Consortium. 6 XML: Extensible Markup Language. 17