Device to device streaming en dispositivos móviles

Device to Device streaming en dispositivos m´oviles Iv´ an Gulyk y Noel Jos´ e Algora Igual FACULTAD DE INFORM´ ATICA UNIVERSIDAD COMPLUTENSE DE MADRID Trabajo de fin de grado del Grado en Ingenier´ ıa Inform´ atica Director: Simon Pickin Curso 2018/2019 Este documento ha sido maquetado con L A T EX 2 Agradecimientos Queremos agradecer toda la ayuda, apoyo y ´animos recibidos por parte de nuestros familiares, compa˜neros y amigos. Tambi´en agradecemos a todos los profesores que nos dieron formaci´on y nos proporcionaron conocimientos d´ıa a d´ıa a lo largo de nuestra etapa universitaria. Especial agradecimiento a nuestro tutor, Simon Pickin, por ofrecernos este proyecto y por toda la colaboraci´on y apoyo que nos ha dado en todo momento. Por ´ultimo, queremos dar las gracias al creador de la librer´ıa libstreaming, que nos ha ahorrado mucho trabajo, y sin la cual posiblemente no habr´ıamos podido llevar a cabo este proyecto. 4 Palabras Clave •WiFI Direct •Android •Libstreaming •Streaming •RTSP •Ad hoc •P2P 5 Keywords •WiFi Direct •Android •Libstreaming •Streaming •RTSP •Ad hoc •P2P 6 ´ Indice Agradecimientos 4 Palabras Clave 5 Keywords 6 Resumen 13 Summary 14 1 Introducci´on 15 1.1 Motivaci´on............................ 15 1.2 Objetivos ............................ 17 1.3 Plandetrabajo......................... 18 1 Introduction 20 1.1 Motivation............................ 20 1.2 Goals............................... 22 1.3 Workplan ............................ 22 2 Antecedentes 25 2.1 Streaming ............................ 25 2.2 WiMAX............................. 25 2.3 Bluetooth ............................ 25 2.4 WiFi............................... 26 2.5 WiFiAdhocMode....................... 26 2.6 WiFiDirect........................... 27 2.7 WiFiAware........................... 27 2.8 TCPyUDP........................... 28 2.9 HTTPStreaming........................ 29 2.10RTPyRTCP .......................... 29 8 2.11RTSP .............................. 30 2.12 Aplicaciones parecidas . . . . . . . . . . . . . . . . . . . . . 30 2.12.1 Aplicaciones para compartir archivos . . . . . . . . . 30 2.12.2CamWimote ...................... 30 2.12.3 RTSP Camera Server . . . . . . . . . . . . . . . . . . 31 3 Elecci´on de tecnolog´ıas 32 3.1 Android ............................. 32 3.2 WiFiDirect........................... 32 3.3 Java ............................... 32 3.4 RTPsobreUDP......................... 33 3.5 RTSP .............................. 33 3.6 libstreaming........................... 34 3.7 libVLC.............................. 34 3.8 AndroidStudio ......................... 34 3.9 Gradle.............................. 35 3.10GityGithub .......................... 35 3.11Trello .............................. 35 3.12 L A T EXyOverleaf......................... 36 4 Especificaci´on 37 4.1 Requisitos............................ 37 4.1.1 Conexi´on ........................ 37 4.1.2 Transmisi´on de datos . . . . . . . . . . . . . . . . . . 37 4.1.3 Recepci´on, interpretaci´on y retransmisi´on de datos . 38 5 Dise˜no 39 5.1 Consideraciones generales de dise˜no . . . . . . . . . . . . . . 39 5.1.1 Funcionamiento de Wifi Direct . . . . . . . . . . . . 39 5.1.2 Multihop y red ad hoc con WiFi Direct . . . . . . . . 40 9 Device to Device Introducci´on Queremos realizar la retransmisi´on en streaming, en vez de una simple transferencia de ficheros de v´ıdeo, dado que para algunos de los casos de uso que tenemos en mente se puede querer emitir el v´ıdeo lo antes posible, y a veces no se podr´ıa enviar un fichero con el v´ıdeo al finalizar la grabaci´on. Secundariamente, como tambi´en puede ser ´util, queremos que se puedan transmitir archivos. Nos encontramos ligados a la conexi´on de Internet, pero en caso de una cat´astrofe natural se puede perder la infraestructura, y por tanto las conexiones a las redes convencionales. Se podr´ıa formar una red ad hoc para pasar v´ıdeos y/o mensajes de ayuda de un dispositivo a otro hasta encontrar un dispositivo que si disponga de acceso a Internet, y de esta forma los datos enviados desde una zona sin conexi´on se publicar´ıan en Internet y llegar´ıan a su destino. Otro de los posibles casos de uso para una aplicaci´on como la que proponemos podr´ıa ser el dar la posibilidad de transmitir v´ıdeos a dispositivos lejanos en pa´ıses en los que se cometen cr´ımenes contra los derechos humanos, de tal forma que el v´ıdeo pasase de un dispositivo a otro salt´andose el control y censura que pa´ıses como estos establecen en las redes convencionales, adem´as de dar la posibilidad de ocultar el origen de la transmisi´on, de tal forma que no se pueda identificar al denunciante. Por este motivo, adem´as, la aplicaci´on no deber´a dejar trazas de los v´ıdeos, ni en los m´oviles emisores ni en los que lo redistribuyen. Si la red es capaz de cruzar la zona de censura los v´ıdeos podr´ıan ser publicados en Internet con ayuda de organizaciones como Witness [1] que se dedican a promover la creaci´on y custodia de v´ıdeos de este tipo. Pero habr´ıa que tener un especial cuidado para este caso, y en general, con el tema del “deepfake”, ya que la inteligencia artificial est´a lo suficientemente desarrollada como para poder crear con su ayuda [2] v´ıdeos falsos, la difusi´on de los cuales podr´ıa provocar esc´andalos y conflictos. Se est´a investigando sobre el uso tecnolog´ıas que puedan identificar deepfakes [3], pero esto es algo muy dif´ıcil. Una tecnolog´ıa como la que pensamos desarrollar es algo bastante novedoso, y como todo lo novedoso, en un principio existen muchos factores a tener en cuenta, muchos problemas que resolver, y agujeros de seguridad que tapar. La red sobre la que pensamos hacer streaming de v´ıdeo es una red ad hoc, que no necesita utilizar ning´un tipo de infraestructura de red externa (como puede ser un router o la infraestructura de los operadores de telecomunicaciones), y por tanto el contenido que pasa por ella no es controlado por nadie m´as que el emisor del mismo; por consiguiente, el propio emisor debe hacerse responsable de lo que emite en directo. Aqu´ı nos surge un factor a tener en cuenta, que son las personas mal intencionadas, las cuales podr´ıan transmitir cualquier tipo de v´ıdeo, con contenido inapropiP´agina 16 Device to Device Introducci´on ado, como podr´ıa ser v´ıdeos de pornograf´ıa infantil. Con los avances de la tecnolog´ıa nos encontramos tambi´en con el problema de que los v´ıdeos pueden modificarse en transito, es decir, en la medida que pasan de un dispositivo a otro, y no ´unicamente desde el emisor, por lo que adem´as es necesario hacer un filtrado en tiempo real. Esto junto con la retransmisi´on de contenido inapropiado es de vital importancia en el caso de uso por los defensores de los derechos humanos, dado que se pueden intentar utilizar este tipo de ataques para intentar desacreditar la red por la que se est´an distribuyendo, as´ı como a los usuarios de esta. 1.2 Objetivos El objetivo principal de este proyecto es dise˜nar e implementar una aplicaci´on para dispositivos m´oviles capaz de conectar los dispositivos entre ellos sin utilizar la infraestructura de red de los operadores de telecomunicaciones. Una vez creado el enlace entre dispositivos, la aplicaci´on debe poder transmitir v´ıdeo en directo desde un m´ovil a otro, que debe a su vez ser capaz de recibir ese v´ıdeo –y reproducirlo, si el usuario lo quiere– siendo capaz al mismo tiempo que recibe el v´ıdeo de retransmitirlo a otros dispositivos a los que est´e conectado, actuando de esta manera como un nodo transitorio entre dispositivos no conectados directamente entre ellos. Para poder llevar a cabo el objetivo principal se debe: 1. Investigar sobre las tecnolog´ıas existentes tanto en el ´area de conexi´on entre dispositivos m´oviles –con WiFi Direct o WiFi Aware como posibles candidatos– como en el ´area de transmisi´on de v´ıdeo en directo y su reproducci´on en m´oviles. 2. Escoger las tecnolog´ıas m´as adecuadas y aplicar los conocimientos obtenidos sobre esas tecnolog´ıas para desarrollar un proyecto pr´actico. 3. Dise˜nar e implementar la aplicaci´on. 4. Detectar y estudiar los posibles problemas que podr´ıan surgir con la funcionalidad que proporciona nuestra aplicaci´on, como podr´ıa ser la transmisi´on de v´ıdeos con contenido inapropiado. Proponer soluciones efectivas a estos problemas. P´agina 17 Device to Device Introducci´on 1.3 Plan de trabajo Figure 1: Planificaci´on Para llevar a cabo el proyecto y conseguir los objetivos vamos a dividir la planificaci´on en 4 grandes bloques, cada uno dividido en tareas, como se muestra en la Figura 3 A partir del esquema anterior hemos generado un diagrama de Gantt (Figura 4) P´agina 18 Device to Device Introducci´on Figure 2: Diagrama de Gantt P´agina 19 Device to Device Introduction 1 Introduction 1.1 Motivation Nowadays, in most cases, we depend totally on the Internet connection when connecting with other devices through our applications. In this project we seek to investigate the different uses that can be achieved with applications in which we have the possibility of connecting our devices to those of others without the need to have access to any physical network infrastructure, in particular, without using the network of telecommunication operators. Even just to create an application capable of connecting to another nearby device is already really advantageous, but beyond connecting together two close devices, we seek to investigate how to create an ad hoc network through these connections. An ad hoc network does not depend on external infrastructure such as routers or access points, and is a decentralized network. In a network like this, devices connect to each other in such a way that new devices can join the network by creating a connection with any device already in it. Our application would create a ad hoc network in which the data passes from device to device, as if it were a chain, until reaching its destination. More specifically, a WANET network (Wireless Ad-hoc Network) or MANET (Mobile Ad-hoc Network) would be created, since this is an ad hoc network on mobile devices with wireless technologies. Currently virtually everyone has a mobile device and, theoretically, in areas with a certain population density it should be able to create networks by interconnecting all devices. With the new advances in technology – such as WiFi technologies, which are found in most devices – we began to have new means to establish this type of connection, opening a new range of possibilities. We believe that it is an area that has been little investigated in spite of the potential offered by such networks. More specifically, what we seek is to be able to retransmit video streams that can be captured live through the camera and microphone of our device, as well as previously recorded videos, and distribute these streaming through our own network ad hoc. Some problems that we find in a MANET network are the use of routing techniques if we need to establish a direct connection between two devices; but for the proposed goals, relay techniques of type flooding and multihopping will be used, thus avoiding those problems. We want to make a broadcast in streaming, instead of a simple transfer P´agina 20 Device to Device Introduction of video files, since for some of the use cases that we have in mind you may want to broadcast the video as soon as possible, and sometimes you can not send a file with the video at the end of the recording. Secondarily, as it can also be useful, we want to be able to transmit files. We are linked to the Internet connection, but in case of a natural catastrophe you can lose the infrastructure, and therefore the connection to conventional networks. An ad hoc network could be formed to pass videos and / or help messages from one device to another, until a device is found that has access to the Internet, and in this way the data sent from an area without connection will be published on the Internet and reach their destination. Another possible use case for an application like the one we propose could be to give the possibility of transmitting videos to distant devices in countries where human rights crimes are committed, in such a way that the video would pass from one device to another bypassing the control and censorship that countries like these establish in conventional networks, in addition to giving the possibility of hiding the origin of the transmission, in such a way that the complainant can not be identified. For this reason, in addition, the application should not leave traces of the videos, neither in the issuing mobiles nor in those that redistribute them. If the network is able to cross the censorship zone, the videos could be published on the Internet with the help of organizations such as Witness [1] that are dedicated to promoting the creation and custody of videos of this type. But we should take special care for this case, and in general, with the topic of “deepfake”, since artificial intelligence is sufficiently developed to be able to create with its help false videos, the diffusion of which could lead to scandals and conflicts. The use of technologies that can identify deepfakes [3] is being investigated, but this is very difficult issue. A technology like the one we plan to develop is something quite new and, like every novelty, there are at the beginning many factors to be taken into account, many problems to be solved, and security holes to be covered. The network on which we intend to make video streaming is an ad hoc network, which does not need to use any type of external network infrastructure (such as a router or the infrastructure of telecommunications operators), and therefore the content that passes through it is not controlled by anyone other than the issuer; therefore, the issuer itself must be responsible for what it broadcasts live. Here there is a factor we have to take into account, the malicious people, which could transmit any type of video, with inappropriate content, such as videos of child pornography. With the advances in technology, we are also faced with the problem that videos can be modified in transit, that is, as they pass from one deP´agina 21 Device to Device Introduction vice to another, and not only from the sender, so it is also necessary to make a filtering in real time. This, together with the transmission of inappropriate content, is of vital importance in the case of its use by human rights defenders, given that it is possible to try to use this type of attacks with the intention of discrediting the network through which they are being distributed, as well as the users themselves. 1.2 Goals The main objective of this project is to design and implement an application for mobile devices capable of connecting the devices between them without using the network infrastructure of telecommunication operators. Once the link between devices is created, the application must be able to transmit live video from one mobile to another, which must in turn be able to receive that video –and play it, if the user wants it– and able, at the same tiem, to relay it to other devices to which it is connected, acting in this way as a transient node between devices not directly connected between them. To be able to carry out the main objective you must: 1. Investigate existing technologies both in the area of connection between mobile devices – with WiFi Direct or WiFi Aware as possible candidates – as in the area of live video transmission and its reproduction on mobile phones. 2. Choose the most appropriate technologies, and apply the knowledge obtained on these technologies to develop a practical project. 3. Design and implement the application. 4. Detect and study the possible problems that could arise with the functionality provided by our application, such as the transmission of videos with inappropriate content. And to propose effective solutions to these problems. 1.3 Workplan To carry out the project and achieve the objectives we will divide the planning into 4 large blocks each with their tasks as shown in the Figure 3 From the previous scheme we have generated a Gantt chart (Figure 4) P´agina 22 Device to Device Introduction Figure 3: Planificaci´on P´agina 23 Device to Device Introduction Figure 4: Diagrama de Gantt P´agina 24 Device to Device Antecedentes 2 Antecedentes 2.1 Streaming Streaming consiste en crear un flujo sin interrupci´on de contenido multimedia trav´es de una red de manera que un usuario puede reproducir lo retransmitido a la vez que se descarga. El streaming puede ser ”live”, en directo, o de audio y/o v´ıdeo ya existentes. Normalmente cuando se retransmite audio y v´ıdeo a la vez, estos se transmiten por separado en dos flujos distintos los cuales deben ir sincronizados por lo que requiere de protocolos que para controlarlo. El streaming requiere de una conexi´on por lo menos de igual ancho de banda que la tasa de bits de la transmisi´on del servicio. Tambi´en existe streaming de tasa de bits adaptable que detecta el ancho de banda de la conexi´on y la capacidad de la CPU de un usuario y ajusta la calidad de transmisi´on de multimedia en funci´on de ello. 2.2 WiMAX WiMax es una familia de protocolos de los niveles f´ısico y enlace de datos que permite conectarse a una red a trav´es de ondas electromagn´eticas en las frecuencias de 2,5 a 5,8 GHz que pueden tener una cobertura de hasta 80 km. Por su cobertura y rendimiento se suele usar conexiones en donde no es posible tener acceso a la red mediante redes tradicionales de pares de cobre o fibra ´optica pero es necesaria una infraestructura bastante grande. 2.3 Bluetooth El Bluetooth [4] es una tecnolog´ıa que se usa para la transmisi´on inal´ambrica de datos entre diferentes dispositivos que se encuentran a corta distancia, dentro de un radio de alcance que suele ser de diez metros. Consta de un conjunto de protocolos de nivel f´ısico y de enlace pero tambi´en de niveles mas altos. Esta tecnolog´ıa transmite inal´ambricamente datos a trav´es de ondas de radio en las frecuencias de 2,4 GHz. Para ello, hace uso de las Redes Inal´ambricas de ´ Area Personal. Los equipos deben encontrarse dentro de un radio de alcance corto, aunque puede variar en funci´on del aparato. Los dispositivos Bluetooth se clasifican de la siguiente manera: P´agina 25 Device to Device Elecci´on de tecnolog´ıas 3 Elecci´on de tecnolog´ıas 3.1 Android Para el desarrollo de este proyecto dado que se busca utilizar una aplicaci´on m´ovil se ha elegido desarrollarla para el sistema operativo Android a causa de que es el sistema operativo con la mayor tasa de utilizaci´on en los smartphones con un porcentaje aproximado al 74.5%[12] al comienzo del a˜no 2019. De esta forma el desarrollo para la aplicaci´on para Android tiene el alcance de llegar a muchos mas dispositivos as´ı como la posibilidad de encontrar mucha mas documentaci´on y ejemplos que si la desarroll´asemos para otros sistemas operativos como iOS o WindowsPhone. Adem´as Android da soporte con su API tanto a la tecnolog´ıa de WiFi Direct como a WiFi Aware. 3.2 WiFi Direct Hemos decido llevar el proyecto a cabo usando la Wifi Direct implementada en la API de Android dado que esta tecnolog´ıa esta presente desde la versi´on 4.0 del sistema operativo lo que significa que la gran mayor´ıa de los dispositivos tendr´an acceso a ella mientras que por lo que hemos podido comprobar incluso aunque el soporte de Android para WiFi Aware esta presente desde la versi´on Oreo (8.0), apenas existen dispositivos en el mercado con el hardware necesario para poder utilizarla. Nos habr´ıa gustado poder usar Wifi Aware porque pensamos que con esta nueva tecnolog´ıa podr´ıamos llevar el proyecto a cabo mucho mas f´acilmente y con grandes ventajas t´ecnicas pero debido a la imposibilidad de probar la aplicaci´on con dispositivos reales hemos tenido que limitarnos a Wifi Direct. El proyecto podr´ıa utilizar la tecnolog´ıa Wifi Aware en un futuro, de forma exclusiva o incluso combin´andola con WiFi Direct para continuar dando servicio a los dispositivos que no la soporten todav´ıa. 3.3 Java Java es un lenguaje de programaci´on orientado a objetos multiplataforma muy popular en la actualidad. Lo hemos elegido para el desarrollo de la aplicaci´on dado que es un lenguaje de programaci´on con el que ambos tenemos experiencia P´agina 32 Device to Device Elecci´on de tecnolog´ıas y es adem´as el lenguaje principal de desarrollo de aplicaciones en Android y por este motivo se puede encontrar mucha mas documentaci´on y ejemplos que otros lenguajes mas nuevos como Kotlin. 3.4 RTP sobre UDP Como protocolo de transmisi´on hemos escogido RTP sobre UDP ya que es un protocolo confiable orientado a la transmisi´on audio o v´ıdeo en tiempo real. Junto con RTP utilizaremos el protocolo RTCP para el control y la sincronizaci´on de los flujos multimedia. Sobre UDP porque es un protocolo m´as ligero y r´apido aun que menos fiable que TCP, pero para el servicio de streaming es mejor aun que podr´ıa haber perdida de datos que simplemente no se mostrar´an al usuario y puede que ´este ni se d´e cuenta. 3.5 RTSP Para establecer y controlar el flujo de datos entre servidor y cliente utilizamos RTSP. Este protocolo nos pareci´o el mas adecuado porque se adapta perfectamente a las necesidades de nuestro proyecto, sobre todo para la parte del servidor o emisor del streaming, ya que se encarga de controlar la conexi´on entre el servidor y el cliente y atender las peticiones del cliente aun que el cliente tambi´en puede atender algunas peticiones del servidor. Es un protocolo muy estandarizado y que m´ultiples reproductores multimedia pueden abrir como puede ser el reproductor integrado del sistema operativo Android. Respecto al inter´es para nosotros de streaming con tasa de bits adaptable, si un flujo tiene que pasar de dispositivo en dispositivo por muchos dispositivos, el efecto de usar este tipo de streaming ser´ıa que despu´es de X hops, la calidad del v´ıdeo sea la que soporta el enlace peor. Por otro lado, el hecho de tener que parar la reproducci´on durante un tiempo a la espera de m´as datos (progressive download) en los enlaces peores es menos problema que perder calidad ya que, si los mecanismos de adaptaci´on bajan demasiado la calidad (menos frames por segundo o menor resoluci´on por frame) es posible que se pierdan detalles cruciales. Por tanto, en los usos previstos para nuestra aplicaci´on, es mejor no usar streaming con tasa de bits adaptable. Adem´as, puesto que nuestra aplicaci´on no se conecta a la red de los operadores de telecomunicaciones, usar HTTP streaming tampoco dar´ıa acceso a la red de distribuci´on de contenido que existe para HTTP. Finalmente, dado que nuestra aplicaci´on cae dentro de la categor´ıa de “live streaming”, tampoco nos interesa facilitar el salto a cualquier punto de stream. P´agina 33 Device to Device Elecci´on de tecnolog´ıas Por esas razones, no nos importa usar los protocolos RTSP y RTP/RTCP, aunque sean un poco anticuados para hacer streaming, en vez de el actualmente mucho m´as popular HTTP. 3.6 libstreaming libstreaming [13] es una librer´ıa de c´odigo abierto con licencia Apache 2.0 para el sistema operativo Android que nos ofrece un API f´acil de integrar en aplicaciones con el que crear streamings desde la c´amara y micr´ofono de nuestro dispositivo utilizando el protocolo RTP sobre UDP. Mas all´a de esto la librer´ıa tambi´en implementa parte del protocolo RTSP para el control de streamings tanto en su forma de servidor como la de cliente. Brinda soporte para m´ultiples codificadores multimedia como pueden ser H.264 para el v´ıdeo y AAC para el audio. Hemos elegido esta librer´ıa para basarnos en el desarrollo de la aplicaci´on dado a la gran versatilidad que nos aporta como un punto de arranque para todo el desarrollo necesario para el proyecto. 3.7 libVLC LibVLC [14] es una potente librer´ıa para la gesti´on de contenido multimedia, puede ser integrada f´acilmente en las aplicaciones y se pueden llegar a conseguir resultados como el famoso reproductor multimedia VLC [15] dado que este est´a basado en esta. Es una librer´ıa de c´odigo abierto con licencia LGPL, adem´as posee una librer´ıa que ofrece una API sobre este core para Android con una licencia GPLv2, nosotros utilizaremos esta ultima en el proyecto. Hemos elegido usar esta librer´ıa para la reproducci´on de los streaming de v´ıdeo debido a su potencia, versatilidad y la facilidad de integraci´on de la misma para la reproducci´on de un streaming desde un servidor RTSP. 3.8 Android Studio Android Studio es el entorno de desarrollo oficial integrado (IDE) para desarrollo de aplicaciones para Android. Est´a disponible para los sistemas operativos Windows, Mac OS X y Linux. Brinda una gran cantidad de herramientas para ayudar en el desarrollo y aumentar la productividad a la hora de crear aplicaciones. Ofrece la posibilidad de crear las P´agina 34 Device to Device Elecci´on de tecnolog´ıas interfaces gr´aficas de forma visual, as´ı como la posibilidad de probar la aplicaci´on en diferentes dispositivos virtuales con diferentes versiones de Android. Hemos usado este entorno para desarrollar la gran parte del c´odigo de nuestro proyecto. 3.9 Gradle Gradle [16] es una herramienta que permite automatizar la construcci´on de proyectos, permite automatizar entre otras cosas la compilaci´on y la validaci´on del proyecto, adem´as de gestionar las dependencias de forma recursiva. Est´a basada en Groovy, un lenguaje de programaci´on muy parecido a Java y est´a incorporada en Android Studio. 3.10 Git y Github Git es un software de control de versiones dise˜nado pensando en la eficiencia y el mantenimiento de versiones de aplicaciones cuando ´estas tienen un gran n´umero de archivos de c´odigo fuente. Su prop´osito es llevar registro de los cambios en los archivos y coordinar el trabajo que varias personas realizan sobre archivos compartidos. Gracias a Git podemos trabajar de forma colaborativa con el menor numero posible de conflictos. Es un software al que los dos ya estamos acostumbrados dado a su extendido uso y que es fundamental a la hora de trabajar en equipo el desarrollo de una aplicaci´on. Hemos usado un repositorio git alojado en Github, esta plataforma que aloja miles de repositorios es la plataforma l´ıder en cuanto al alojamiento de repositorios de c´odigo siendo un referente del c´odigo abierto en la actualidad. Ofrece el alojamiento de repositorios de forma gratuita Para llevar el control de versiones del c´odigo de nuestro proyecto hemos usado un repositorio Git alojado en GitHub dado que es un sistema que nos es familiar y de uso muy extendido. 3.11 Trello Trello [17] es un software de administraci´on de proyectos con interfaz web que utiliza el m´etodo Kanban. Esta herramienta permite la creaci´on de tableros y listas de tarjetas virtuales. Las tarjetas son el representativo de tareas pendiP´agina 35 Device to Device Elecci´on de tecnolog´ıas entes y/o nuevas ideas del proyecto, y junto con las listas se van organizando de tal forma que podemos saber en cada momento cual es el progreso de los objetivos a realizar y quien es la persona asignada a dicha tarea. Es una herramienta muy interactiva y con un amplio uso para la repartici´on de tareas en proyectos desarrollados con metodolog´ıas ´agiles. 3.12 L A T E X y Overleaf L A T EX[18] es un sistema de composici´on de textos que est´a orientado especialmente a la creaci´on de documentos de alta calidad debido al gran abanico de posibilidades que nos ofrece es muy usado para la creaci´on de documentos, art´ıculos y libros cient´ıficos as´ı como trabajos de fin de grado, m´aster o tesis doctorales. Permite la f´acil modificaci´on de los estilos de todo el documento al mismo tiempo que ofrece ayudas para la gesti´on de los ´ındices y la bibliograf´ıa. L A T EX est´a organizado sobre T EX. Hemos decidido usar L A T EX por encima de Microsoft Word dada la complejidad del documento y con el objetivo de obtener una memoria del proyecto mas profesional y de mejor calidad. Como editor de L A T EX hemos usado Overleaf [19], una plataforma que ofrece la oportunidad del desarrollo de documentos sobre latex de forma colaborativa y centralizada de tal forma que varios participantes pueden estar modificando el documento simult´aneamente sin conflictos desde cualquier ubicaci´on en la que dispongan conexi´on a internet. P´agina 36 Device to Device Especificaci´on 4 Especificaci´on Tras realizar la investigaci´on sobre las posibles tecnolog´ıas que se pueden aplicar a nuestro proyecto y escoger las que mejor satisfacen las necesidades de ´este procedemos a dise˜nar y especificar nuestra aplicaci´on. 4.1 Requisitos Para cumplir los objetivos que proponemos, nuestra aplicaci´on se puede dividir en tres apartados que son: •Conexiones peer-to-peer. •Transmisi´on del streaming de v´ıdeo y audio generado por la c´amara y micr´ofono del dispositivo. •Recepci´on y reproducci´on del streaming junto con retransmisi´on del mismo como nodo de transito. 4.1.1 Conexi´on Lo primero que nuestra aplicaci´on debe hacer es poder conectarse a otro dispositivo con las tecnolog´ıas seleccionadas en el apartado de elecci´on de tecnolog´ıas. Con lo cual debe cumplir estos requisitos: •Requisito funcional: Buscar dispositivos cercanos disponibles. •Requisito funcional: Realizar una conexi´on y crear un enlace con otro dispositivo cercano. 4.1.2 Transmisi´on de datos En segundo lugar, una vez establecida la conexi´on entre dos o mas dispositivos la aplicaci´on debe: •Requisito funcional: Mostrar al usuario que desea hacer streaming lo que ve su c´amara. •Requisito funcional: Preparar los datos de la c´amara y el micr´ofono para poder ser enviados. •Requisito funcional: Identificar al destinatario. •Requisito funcional: Enviar los datos preparados, o cualquier archivo o mensaje de texto. P´agina 37 Device to Device Dise˜no •Requisito funcional: No dejar trazas en el m´ovil emisor tras realizar un streaming de v´ıdeo. 4.1.3 Recepci´on, interpretaci´on y retransmisi´on de datos Por ultimo, la aplicaci´on debe poder manejar los datos recibidos y, por tanto, cumplir los siguientes requisitos: •Requisito funcional: Recibir y tratar los datos recibidos. •Requisito funcional: Reproducir el v´ıdeo recibido si el usuario quiere. •Requisito funcional: Retransmitir los datos recibidos a otros dispositivos conectados al mismo tiempo que se est´an recibiendo. P´agina 38 Device to Device Dise˜no 5 Dise˜no 5.1 Consideraciones generales de dise˜no 5.1.1 Funcionamiento de Wifi Direct Cuando empezamos a estudiar el dise˜no de la aplicaci´on para una red con WiFi Direct nos encontramos ante varias situaciones debido a su dise˜no en el cual las conexiones de WiFi Direct crean un grupo que es muy parecido a una peque˜na red local. Esta red se crea alrededor de uno de los dispositivos involucrados en la conexi´on, que ser´a designado como Group Owner y actuar´a de forma similar a un punto de acceso como si se tratase de una red WiFi “corriente” en la que el router es el punto de acceso y centro de la red. Una vez se ha establecido la conexi´on entre dos dispositivos y se ha creado este grupo, otros dispositivos pueden conectarse a la red, bien creando una conexi´on directa al Group Owner o ya sea conect´andose a alguno de los dispositivos conectados a la red el cual nos redirigir´a al Group Owner para conectarnos a ´el. Figure 5: Conexiones WiFi Direct P´agina 39 Device to Device Dise˜no Este proceso se puede observar en la Figura 5, pero para ello necesitaremos tener dentro de alcance al Group Owner o en caso contrario no podremos conectarnos a la red. Cuando se crea esta conexi´on se lleva a cabo un proceso de negociaci´on de la conexi´on mediante el cual se establecen ciertos aspectos sobre como ser´a la red, quien ser´a el Group Owner y las IPs de los dispositivos involucrados en la misma. Cuando dos dispositivos intentan conectarse se quedan en estado “invitado” hasta que se negocia y se autoriza la conexi´on. El proceso de conexi´on suele tardar entre unos 5 y 8 segundos. 5.1.2 Multihop y red ad hoc con WiFi Direct Para crear una red ad hoc con WiFi Direct se necesita que un cliente que ya este conectado a un grupo sea capaz de conectarse a un segundo grupo de tal forma que este actu´e como nodo de enlace entre los dos grupos permitiendo conectar las redes que forman estos como podemos ver en la Figura 6. Esto tambi´en permite que cualquier dispositivo se pueda unir a la red aunque se encuentre fuera del alcance del Group Owner: el nuevo dispositivo crear´ıa un nuevo grupo en el que ´el mismo es el Group Owner y uno de los clientes de un grupo existente actuar´ıa como nodo enlace conectado como cliente tanto al Group Owner del nuevo grupo, es decir el nuevo dispositivo, como al Group Owner del grupo existente. Figure 6: M´ultiples redes WiFi Direct Uno de los problemas con el que nos encontramos al enfrentarnos a unir dos redes de WiFi Direct es que cada red no se encuentra al alcance de la P´agina 40 Device to Device Dise˜no otra. Solo el nodo de enlace tiene la posibilidad de acceder a ambas redes y es este el que tiene la responsabilidad de encaminar los paquetes para que lleguen a su destino. Por esta raz´on si se desea ser capaces de enviar paquetes directos entre dispositivos de diferentes redes se necesitan crear las rutas para el encaminamiento aunque para nuestro caso en concreto debido a que queremos retransmitir el streaming a todos los dispositivos de la red que lo acepten utilizaremos t´ecnicas de tipo flooding ymultihoping. WiFi Direct nos otorga la posibilidad de que este Group Owner sea elegido al azar o bien que nosotros designemos quien va a ser el Group Owner o la prioridad que tiene a la hora de ser nombrado el Group Owner si no esta establecido. Esto puede ser realmente beneficioso a la hora de crear una red ad hoc con WiFi Direct ya que podr´ıamos decidir observando los mapas de la red cuales deber´ıan ser los Group Owners para optimizar la red. Tambi´en nos encontramos con que es posible que a trav´es de la red de WiFi Direct los datos sean redireccionados hacia la red convencional de Internet si cualquiera de los dispositivos involucrados en la red tiene acceso las dos redes. El dispositivo conectado a ambas redes actuar´a como nodo de enlace por tanto podr´a reenviar los datos a servidores externos o bien a otros clientes que se hayan conectado a el por la red de Internet. Este paso de datos entre la red de WiFi Direct y la red de Internet debe ser implementado por la aplicaci´on que utilice WiFi Direct, as´ı como el encaminamiento de estos paquetes. 5.1.3 Limitaciones de la implementaci´on de WiFi Direct en Android Cuando hemos investigado sobre como dise˜nar nuestra aplicaci´on usando WiFi Direct nos hemos encontrado con una gran limitaci´on en la implementaci´on de la API de WiFi Direct que nos ofrece Android y que no nos ha permitido continuar el dise˜no y el desarrollo de la aplicaci´on por el camino que dese´abamos. Esta limitaci´on es que un dispositivo no puede mantener la membres´ıa en varios grupos de WiFi Direct simult´aneamente, esto nos condiciona a que no vamos a poder unir varias redes de WiFi Direct y por tanto no se podr´a conseguir crear una red ad hoc para nuestra aplicaci´on como se buscaba. Seg´un el articulo publicado por WiFi Alliance [20], que un dispositivo WiFi Direct sea capaz de pertenecer a varios grupos a la vez es una especificaci´on opcional de implementar y el sistema operativo Android nunca la llego a implementar. Algunas de las posibles soluciones que hemos encontrado son: P´agina 41 Device to Device Dise˜no 5.3.2 Streaming a varios dispositivos simult´aneamente Cuando contemplamos los posibles escenarios a la hora de realizar el streaming de v´ıdeo tanto en una red ad hoc donde es necesario hacer multihopping como en una red simple de WiFi Direct, en primer lugar tenemos las situaciones en la cual un dispositivo necesita retransmitir un streaming de v´ıdeo a varios clientes simult´aneamente. Esta situaci´on se podr´ıa dar en primer lugar si se trata del Group Owner y el centro de la red, de tal forma que puede retransmitir a todos los dispositivos que est´an conectados a ´el, dando la posibilidad a que todos esos dispositivos puedan hacer multihop mas tarde y reenviar el streaming. Adem´as, nos brinda la oportunidad de poder abastecer a toda una peque˜na red de WiFi Direct creando conexiones directas con cada dispositivo. Podemos observar estas situaciones en la Figura 10. Figure 10: Escenarios de streaming a varios dispositivos simult´aneamente Tambi´en se podr´ıa dar el caso de que un dispositivo, que es un nodo de enlace entre dos grupos de WiFi Direct, quiera retransmitir en directo. Te´oricamente si el dispositivo emisor est´a conectado a las dos redes, deber´ıa ser capaz de retransmitir a todos los dispositivos en cualquiera de estas, estableciendo conexi´on directa con cada uno de los dispositivos de cada red como observamos en el diagrama de la Figura 11. La funcionalidad de multistreaming es totalmente necesaria y ha sido nuestro primer problema a solucionar, esto es porque primero la aplicaci´on debe ser capaz de retransmitir a varios dispositivos a la vez, en caso de estar conectados a varios, para que si cualquiera de ellos act´ua como un nodo de enlace pueda retransmitir por medio de multihopping el streaming a los dispositivos del otro grupo de WiFi Direct. P´agina 48 Device to Device Dise˜no Figure 11: Escenarios de streaming a varios dispositivos simult´aneamente 5.3.3 Problema en la retransmisi´on simultanea con la librer´ıa libstreaming Nos encontramos con un serio problema de dise˜no en la librer´ıa libstreaming para implementar esta funcionalidad. Aunque esta dise˜nada para crear nuevas sesiones con cada conexi´on en el servidor, en el estado inicial de la librer´ıa era imposible dado que estas sesiones crean a su vez nuevos VideoStream y AudioStream, estas clases est´an dise˜nadas para interactuar directamente tanto con la c´amara como con el micr´ofono respectivamente existiendo el gran problema que en Android estos perif´ericos no pueden ser usados mas de una vez al mismo tiempo siendo bloqueantes las instancias. Tanto VideoStream como AudioStream intentaban crear nuevos accesos a la c´amara y al micr´ofono de tal forma que no pod´ıan acceder en el caso del audio o le ”robaban” la c´amara al VideoStream de la sesi´on anterior. Esto es un claro problema de dise˜no en la librer´ıa ya que el servidor esta implementado de tal forma que pueda mantener sesiones simultaneas con varios clientes, pero no sirve de nada poder mantener estas sesiones si no somos capaces de retransmitir el streaming a los clientes de forma simultanea. Para resolver este problema debemos modificar la librer´ıa y separar la c´amara y el micr´ofono del VideoStream y AudioStream creando una clase intermedia entre los streams y los paquetizadores que maneje estos perif´ericos, recolecte los datos de estos y se los pase a cada paquetizador que los necesite. P´agina 49 Device to Device Dise˜no 5.3.4 Nodo de transito y multihopping de streamings con WiFi Direct Para poder retransmitir el streaming en una red ad hoc encontramos en un segundo escenario en el que necesitamos que un dispositivo sea capaz de recibir y retransmitir el streaming al mismo tiempo para as´ı actuar como un nodo de transito permiti´endonos crear una red Multihop. Cabe destacar que el dispositivo que act´ua como nodo de transito tambi´en deber´ıa ser capaz de reproducir el streaming. En el caso de una red sencilla de WiFi Direct, en el que un dispositivo ofrece el servicio de streaming y otros dispositivos de la red quieren recibirlo, el emisor podr´ıa enviar el stream a todos los potenciales receptores de forma simult´anea, estableciendo conexiones directas con cada uno de ellos. Sin embargo, este procedimiento es poco escalable, dado que el streaming de los flujos de v´ıdeo en alta calidad implica transferir grandes cantidades de datos. Ser´ıa m´as eficiente que el dispositivo que ofrece un servicio de streaming lo envie al GO y el GO se encargue de retransmitirlo al resto de sus clientes, tal como se ilustra en la Figura 12. Figure 12: Escenarios streaming con multihopping Pero ya seria totalmente necesario en el caso que un cliente estuviese conectado a una segunda red y queramos retransmitir el streaming de nuevo para distribuirlo por la nueva red. Si adem´as esto se extiende a otros dispositivos que tambi´en act´uan como nodos de enlace y nos conectan con otras redes ya nos permitir´ıa distribuir el streaming por una red ad hoc. Como podemos ver en la Figura 13 aqu´ı no solo actuaria el Group Owner como nodo de transito sino que a su vez un cliente act´ua como nodo de transito para el streaming y como nodo de enlace entre ambas redes. Cabe P´agina 50 Device to Device Dise˜no Figure 13: Escenarios streaming con multihopping destacar que cualquier dispositivo conectado a la red de WiFi Direct que tambi´en disponga de una conexi´on a Internet podr´ıa actuar como nodo de enlace de ambas redes y permitir la retransmisi´on del streaming hacia las redes convencionales. Cuando queremos ampliar un servicio como el de streaming de v´ıdeo en dispositivos m´oviles algo en lo que debemos pensar adem´as es en la carga que ponemos tanto sobre el dispositivo m´ovil como sobre las conexiones de la red, cuanto mas se expande la red mas importante es optimizar las conexiones y reducir la carga para la retransmisi´on. 5.3.5 Nodo de tr´ansito y multihopping con la librer´ıa libstreaming Tal como se ha visto anteriormente, la librer´ıa libstreaming contiene una clase que implementa un cliente RTSP y una clase que implementa un servidor RTSP. Seg´un el protocolo RTSP [9], el cliente RTSP que quiere recibir (modalidad “reproducir”) un stream de un servidor RTSP utiliza las directivas: DESCRIBE, SETUP, PLAY y TEARDOWN. Primero, el cliente env´ıa la petici´on DESCRIBE a la que el servidor contesta con informaci´on de inicializaci´on, a continuaci´on el cliente debe realizar una petici´on SETUP, estableciendo el valor play para el par´ametro mode, por cada pista multimedia que se desea recibir (normalmente, uno para el audio y otro para el v´ıdeo), para finalmente enviar una petici´on PLAY indicando al servidor que se puede iniciar la transmisi´on. La petici´on TEARDOWN (una por stream, al igual que SETUP) termina la sesi´on y cierra el stream. Ver la P´agina 51 Device to Device Dise˜no Figure 14: Secuencias de peticiones en RTSP Figura 14 para una representaci´on visual de este escenario. Este es el escenario habitual cuando conectamos nuestro dispositivo con un cierto reproductor multimedia a un servidor RTSP para as´ı poder visualizar el streaming en nuestro dispositivo. Seg´un el protocolo RTSP, el cliente que quiere enviar (modalidad “publicar”) un stream a un servidor RTSP utiliza las directivas: ANNOUNCE, SETUP, RECORD y TEARDOWN. Primero, el cliente env´ıa una petici´on ANNOUNCE que contiene informaci´on sobre los stream que se quiere enviar, a continuaci´on debe realizar una petici´on SETUP, estableciendo el valor receive para el par´ametro mode, por cada pista multimedia que se desea enviar (normalmente, uno para el audio y otro para el v´ıdeo), para finalmente enviar una petici´on RECORD indicando que se va a iniciar la transmisi´on. La petici´on TEARDOWN (una por stream, al igual que SETUP) termina la sesi´on y cierra el stream. Ver la Figura 14 para una representaci´on visual de este escenario. Este es el escenario habitual cuando el cliente quiere ser el emisor del stream pero no quien lo distribuya, de esta forma env´ıa el streaming a un servidor dado para que este mas tarde lo redistribuya o bien lo guarde en un fichero. Cuando observamos las diferentes posibilidades para realizar multihopping con RTSP en el caso de la transmisi´on de un stream entre dispositivos A, B, C y D, es decir, de A a B, de B a C y de C a D, se podr´ıa hacer de P´agina 52 Device to Device Dise˜no varias maneras: La primera forma supone el uso del cliente y servidor en cada nodo de tr´ansito, usando siempre la modalidad “publicar”: 1. Un cliente RTSP de A se conecta en modalidad publicar a un servidor RTSP de B 2. El servidor RTSP de B pasa el stream a un cliente RTSP de B 3. El cliente RTSP del dispositivo B se conecta en modalidad publicar a un servidor RTSP de C 4. El servidor RTSP de C pasa el stream a un cliente RTSP de C 5. El cliente RTSP de C se conecta en modalidad publicar a un servidor RTSP de D La segunda forma supone el uso del cliente y servidor en cada nodo de tr´ansito, usando siempre la modalidad “reproducir”: 1. Un cliente RTSP de B se conecta en modalidad reproducir al servidor RTSP de A 2. El cliente RTSP de B pasa el stream a un servidor RTSP de B 3. Un cliente RTSP de C se conecta en modalidad reproducir al servidor RTSP de B 4. El cliente RTSP de C pasa el stream a un servidor RTSP de C 5. Un cliente RTSP de D se conecta en modalidad reproducir al servidor RTSP de C Y una tercera forma con cliente o servidor en cada nodo de tr´ansito y alternando entre las modalidades “publicar” y “reproducir”: 1. Un cliente RTSP de A se conecta en modalidad publicar a un servidor RTSP de B 2. El cliente RTSP 1 de C se conecta en modalidad reproducir a este servidor RTSP de B 3. El cliente RTSP 1 de C pasa el stream a cliente RTSP 2 de C 4. El cliente RTSP 2 de C se conecta en modalidad publicar a un servidor RTSP de D P´agina 53 Device to Device Dise˜no La mejor soluci´on no es trivial en una aplicaci´on como esta, para algunos de los casos de uso propuestos como el caso de la cat´astrofe natural y el caso de los derechos humanos por ejemplo queremos que el stream vaya pasando de un dispositivo a otro hasta que llegue a toda la red lo mas r´apido posible y es de suponer que los dispositivos actuaran como nodos de transito sin interacci´on del usuario, por esto la primera forma en la que solo se utiliza la modalidad “publicar” puede parecer mejor, pero en el caso de los derechos humanos donde pueden existir usuarios malintencionados que intenten saturar la red o introducir v´ıdeos con contenido no apropiado se podr´ıan aprovechar de esto por lo que la segunda forma en la que siempre se utiliza la modalidad de “reproducir” puede ser una mejor aproximaci´on d´andonos mas posibilidad de decisi´on en el nodo de transito. Tambi´en cabe decir que un implementaci´on mas completa donde se alternan como en la tercera propuesta es muy interesante, tiene la gran ventaja frente a la segunda de poder enviar con modalidad “publicar” el stream desde los nodos de transito, lo que permite enviar el stream a servidores a trav´es de Internet. Adem´as, en una alternativa donde se puedan alternar las modalidades de “publicar” y “reproducir” no siempre tendr´ıa que ser de la forma que hemos descrito y es posible que dependiendo de la configuraci´on de la aplicaci´on el transito del stream se efectu´e de formas muy diferentes, como podr´ıan ser por ejemplo la primera donde siempre se env´ıa utilizando la modalidad de “publicar” o bien la segunda forma donde siempre utilizamos la modalidad de “reproducir” dado que abrimos mucho el abanico de posibilidades. En el caso de la implementaci´on de WiFi Direct de Android, como se ha explicado en la Secci´on 5.1.3, solo se pueden hacer dos hops de manera satisfactoria. Para implementar estos dos hops, hemos decidido implementar los primeros dos pasos de la tercera opci´on (en vez de los primeros tres pasos de la primera o segunda opci´on). 5.3.6 Problemas para realizar multihopping con la librer´ıa libstreaming El primero de los problemas que hemos encontrado con la librer´ıa libstreaming para realizar el multihopping es que, siendo una librer´ıa pensada solo para distribuir los streams generados por la c´amara y del micr´ofono del propio dispositivo, solo implementa la modalidad de “publicar” en el cliente RTSP y es necesario que sea implementada en servidor RTSP tambi´en para que est´e pueda recibir el stream que le env´ıa el cliente. El segundo problema que hemos encontrado con la librer´ıa libstreaming es que, adem´as, la implementaci´on de la modalidad de “reproducir” en el servidor RTSP de la librer´ıa va ligada a sesiones para reproducir un streaming que esta produciendo el dispositivo del servidor en tiempo real P´agina 54 Device to Device Dise˜no desde la c´amara y el micr´ofono, por lo que es necesario la reimplementaci´on de las peticiones DESCRIBE, SETUP y PLAY cuando el contenido que se esta solicitando no proviene de los perif´ericos del dispositivo sino de un cliente que esta envi´andonos un streaming a nuestro servidor en modalidad ”publicar”. Esto adem´as incluye que se tenemos que crear diferentes sesiones para cada tipo de cliente que se conecte al servidor: •Session para aquellos clientes que desean reproducir el streaming producido por la camara y el micr´ofono en tiempo real. Esta clase ya esta implementada y apenas deberemos cambiar su implementaci´on sino como se gestionan estas sesiones. •ReceiveSession para aquellos cliente que desean publicar un streaming en el servidor para ser distribuido. •RebroadcastSession para aquellos clientes que desean reproducir el streaming que se ha publicado en el servidor por un tercero. Para retransmitir el streaming que se esta recibiendo en la ReceiveSession y transmitirlo al cliente de una RebroadcastSession crearemos unos servidores UDP que estar´an recibiendo los datos de cada uno de los flujos multimedia (audio y v´ıdeo) de una ReceiveSession y reenvi´andolos a todos los clientes que est´en suscritos mediante una RebroadcastSession a esta primera sesi´on. Con todo esto y debido a las grandes modificaciones que se deben hacer en el servidor RTSP tanto en las respuestas a las peticiones como en el tratamiento de estas hemos decidido utilizar nuestro paquete de conexiones y crear un nuevo servidor RTSP integrando las funcionalidades del RtspServer proporcionado por la librer´ıa y a˜nadiendo las nuevas peticiones necesarias para recibir y retransmitir el streaming as´ı como usar y diferenciar todas las sesiones. De esta forma implementaremos la clase RTSPServerSelector y RTSPServerWorker para establecer las conexiones y procesar las peticiones RTSP, tambi´en implementaremos el UDPServerSelector y el EchoWorker para realizar la retransmisi´on de los paquetes RTP que se est´an recibiendo en los puertos UDP. Podemos observar el diagrama de estas clases en la Figura 15 Con esto seremos capaces de crear el primer salto, ya que un dispositivo ser´a capaz de recibir el streaming y reenviarlo pero para la creaci´on de un segundo salto seria necesario realizar mas cambios en el servidor RTSP y cliente RTSP. Una primera forma seria extender la funcionalidad del servidor RTSP P´agina 55 Device to Device Dise˜no Figure 15: Diagrama de clases en el paquete de conexiones para que sea capaz de traspasar el streaming a un cliente RTSP en modalidad “publicar” el cual retransmitir´a el streaming que el servidor le proporciona. Esto nos permitir´ıa llevar a cabo la primera opci´on descrita en la Secci´on 5.3.5. Para llevar esto a cabo, adem´as de los cambios necesarios en el servidor, para crear este cliente y traspasarle el streaming recibido es necesario realizar una gran cantidad de cambios en el cliente RTSP para poder retransmitir en modalidad “publicar” desde un streaming que no es generado por el propio dispositivo. Por ello es incluso mas pr´actica la creaci´on de un nuevo cliente que se asociar´a con una RebroadcastSession en el servidor y utilizar´a los servidores UDP de la ReceiveSession para realizar el reenvi´o de datos. Una segunda forma seria crear un nuevo cliente RTSP el cual fuese capaz de conectarse en modalidad “reproducir” a un servidor RTSP para recibir el streaming, generando una ReceiveSession que mas tarde se traspasar´a al servidor RTSP. Con esto podr´ıamos llevar a cabo la segunda opci´on contemplada en la Secci´on 5.3.5. Es necesario implementar un nuevo cliente por completo pero cabe decir que ya se han implementado tanto la ReceiveSession que debe generar como los servidores UDP que est´an asociados a esta. Por lo tanto sin demasiados cambios en el servidor RTSP usaremos este nuevo cliente RTSP para conectarnos a otro servidor y generar una nueva ReceiveSession, a continuaci´on siguiendo el mismo proceso que acabamos de dise˜nar en esta P´agina 56 Device to Device Dise˜no secci´on, el servidor ser´a capaz de retransmitir el streaming de la ReceiveSession cuando un cliente se conecta al servidor. Implementando uno u ambos cambios seremos capaces de realizar saltos infinitos, en el caso de implementar ambos tendremos mayor versatilidad a la hora de establecer como queremos que estos saltos se realicen dependiendo de las diferentes situaciones. P´agina 57 Device to Device Implementaci´on para los otros VideoStream por lo que el resultado es que cada uno solo enviaba peque˜nos fragmentos de v´ıdeo entrecortados. El mismo problema descrito con la c´amara se aplica al micr´ofono, es necesario obtener los datos de ambos de una forma externa y despu´es distribuirla entre los distintos VideoStream y AudioStream. Desacoplar el uso de la c´amara y el micr´ofono fue un trabajo bastante laborioso por lo ligados que estaban a las clases. Finalmente lo conseguimos mediante la siguiente soluci´on aunque se han tenido que desactivar algunas interacciones que antes s´ı pod´ıan hacerse con los perif´ericos. Por ello para aislar la recogida de datos de estas clases, planteamos implementar unas clases Dispatcher las cuales ser´an las encargadas de obtener los datos tanto de la c´amara como del micr´ofono y repartirlo entre los distintos streamings activos. Para conseguir esto los streamings deber´an suscribirse a estos Dispatchers cuando quieran comenzar la retransmisi´on. Se comenz´o implementando el Dispatcher para el v´ıdeo, se han realizado dos implementaciones para este y esto es debido a que inicialmente se planteo una clase MediaCodecDispatcher, la cual deb´ıa ser capaz de leer los datos de la c´amara y transferirlos a varios MediaCodec. La ventaja de esta soluci´on era que para cada stream se pod´ıa tener una calidad distinta y adem´as ya se pod´ıa hacer stream a m´as de un dispositivo. Pero un gran inconveniente que nos ech´o para atr´as con esta soluci´on fue que cuantos m´as dispositivos se conectaban al RtspServer m´as lento empezaba a ir el v´ıdeo en cada sesi´on y esto se debe a que por cada MediaCodec nuevo el m´ovil deb´ıa codificar la imagen y el audio, y no es un proceso ligero y requiere bastante computaci´on por parte del procesador sobre todo con la parte de v´ıdeo. Investigando hemos encontrado que los m´oviles mas potentes solo pod´ıa llegar a tener hasta 8 MediaCodecs trabajando al mismo tiempo. Finalmente tuvimos que descartar esta opci´on y pensar en algo mejor. Las nuevas clases principales que creamos para la librer´ıa son AudioPacketizerDispatcher y VideoPacketizerDispatcher, estas se encargar´an de leer los datos de los perif´ericos, codificarlos con un MediaCodec y traspas´arselos a los Packetizers que se hayan suscrito a ellos. Cada AudioStream y VideoStream al iniciar el streaming llamaran a una funci´on de su respectivo Dispatcher para que este comience a abastecerle con los datos multimedia. Todos los Packetizer tanto de v´ıdeo como de audio est´an dise˜nados para leer los datos de un MediaCodecInputStream, la cual es una clase que extiende de InputStream proporcionando as´ı una interfaz est´andar de lectura. Por ello hemos creado una nueva clase ByteBufferInputStream la cual tambi´en extiende de InputStream para as´ı tener la misma interfaz de lectura que MediaCodecInputStream y poder reemplazarla. Esta clase es P´agina 64 Device to Device Implementaci´on la encargada de almacenar los datos para los distintos Packetizer. Hemos creado una clase MediaCodecBufferReader la cual implementa un hilo para leer siempre que se disponga de nuevos datos de un perif´erico a trav´es de su MediaCodecInputStream y copiarlos a todos los ByteBufferInputStream que tiene asignados en una lista. Cada Dispatcher al iniciarse creara un MediaCodecBufferReader para leer de la c´amara o micr´ofono. Ahora por cada nueva sesi´on las clases AudioStream y VideoStream deben suscribir sus Packetizers (son los encargados de crear los paquetes RTP y enviarlos) a los respectivos Dispatchers. Los Dispatchers crean un nuevo ByteBufferInputStream por cada Packetizer y lo asignan al mismo como fuente de los datos donde antes se le asignaba un MediaCodecInputStream. Adem´as se a˜nade el ByteBufferInputStream a la lista del MediaCodecBufferReader de tal forma que este ultimo empieza a copiar los datos del MediaCodec en el ByteBufferInputStream y el Packetizer puede empezar a enviar los paquetes y de esta manera conseguimos que todos los Packetizer tengan los datos multimedia sin tener que acceder a la c´amara y el micr´ofono m´ultiples veces. Figure 19: Diagrama de clases de la soluci´on multistreaming Cuando los Dispatchers se quedan sin Packetizers, es decir, no hay P´agina 65 Device to Device Implementaci´on clientes viendo el streaming en directo, se paran los MediaCodec y se cierran los distintos hilos que leen de estos para as´ı liberar los recursos, a continuaci´on se procede a terminar los Dispatchers, hasta que un nuevo cliente se conecte, evitando de esta manera gasto de recursos innecesario. Con esta soluci´on evitamos el problema de m´ultiples accesos a la c´amara y el micr´ofono o creaci´on de m´ultiples MediaCodecs y conseguimos hacer el streaming a m´ultiples dispositivos simult´aneamente. El ´unico inconveniente es que la transmisi´on en directo se hace a un calidad fija para todos los clientes aunque eso no es un problema para los casos de uso propuestos. En la Figura 19 se muestra el diagrama de clases de esta soluci´on. En el se muestran las nuevas clases nuevas y con las que est´as interact´uan. Para ver el diagrama inicial de la librer´ıa v´ease la Figura 9. 6.5.2 Retransmisi´on del streaming mediante MultiHop Para llevar acabo la solucion propuesta el Secci´on 5.3.6, lo primero que hemos hecho ha sido implementar un nuevo servidor RTSP con nuestro paquete de conexiones bas´andonos en gran parte en el RtspServer de la librer´ıa, para ello creamos las clases RTSPServerSelector y RTSPWorker donde se controlan las conexiones y procesan las peticiones respectivamente. Lo siguiente a implementar es la ReceiveSession y el servidor UDP para poder empezar a recibir la transmisi´on de un cliente en el servidor. Para ello, desarrollamos las nuevas clases UDPServerSelector y EchoWorker, donde el selector pone un socket UDP a la escucha en un puerto dado y permite que suscribamos direcciones y puertos a las que el EchoWorker reenviar´a cada vez que se reciban datos para de esta forma retransmitir los flujos multimedia que estamos recibiendo a otros clientes. Para poder crear los servidores UDP para reenviar los flujos del streaming hemos realizado cambios tanto en el AbstractSelector como en el AbstractWorker, de tal forma que estos pudiesen trabajar tanto con los SocketChannel, que es la clase para los sockets TCP en NIO, como con los DatagramChannel, que son los designados para el protocolo UDP. Para ello era necesario modificar muchas de las operaciones b´asicas del AbstractSelector como las de recibir datos o enviarlos para identificar el tipo de Channel usado. A continuaci´on, hemos tenido que crear una implementaci´on del AbstractSelector que es el UDPServerSelector el cual crea un servidor a la escucha en un puerto UDP y adem´as es capaz de tener un listado de conexiones UDP a las que se enviaran los paquetes. Tambi´en hemos desarrollado una implementaci´on de la clase AbstractWorker que es EchoWorker. Este worker no procesa los paquetes y simplemente reenv´ıa todos los datos que P´agina 66 Device to Device Implementaci´on le lleguen a todos los clientes que est´en suscritos al UDPServerSelector. De esta forma podemos crear un servidor en el cual recibiremos los flujos multimedia y al cual podremos suscribir clientes que quieren recibir estos flujos para que sean reenviados. Creamos una clase ReceiveSession la cual es capaz de contener la informaci´on de sesi´on y de cada pista multimedia creando nuevas TrackInfo para cada una, estas TrackInfo almacenan la descripci´on de los flujos multimedia a los que corresponden y son capaces de comenzar los UDPServerSelector en los puertos en lo que se van a recibir estas pistas para de esta forma poder empezar la recepci´on de los datos cuando se inicie la ReceiveSession. Despu´es es necesario reimplementar el procesamiento de peticiones del servidor para que procese las peticiones que realiza el cliente al publicar el streaming y pueda crear una nueva ReceiveSession, la primera petici´on a implementar es ANNOUNCE porque es con la que se inicia la sesi´on, en nuestro dise˜no para la gesti´on de m´ultiples streamings hemos decidido que la petici´on del ANNOUNCE debe ser llamada de forma que se identifica la sesi´on por la ruta de la petici´on (Ej: rtsp://192.168.1.49/customSession), de esta forma se crea una nueva ReceiveSession asociada a esa ruta y se almacenan las partes necesarias de la petici´on ANNOUNCE donde se describen la sesi´on y los flujos multimedia van a ser publicados para que luego mas tarde podamos crear las peticiones de retransmisi´on de forma correcta. Si todo es correcto el servidor almacena la sesi´on y procede a responder con un OK. Despu´es es necesario reimplementar la petici´on SETUP ya que esta solo esta disponible para mode=play y al publicar un cliente la env´ıa con el par´ametro mode=receive, como mapeamos las conexiones del servidor RTSP con las sesiones esto se resuelve de forma sencilla diferenciando que tipo de sesi´on tiene esa conexi´on para de esta forma si es una ReceiveSession invocar la nueva implementaci´on. En esta nueva petici´on SETUP guardaremos los puertos a los que el cliente va a enviar el flujo multimedia de v´ıdeo o audio y los asignaremos a la ReceiveSession asociada para mas tarde poder controlar las pistas. Por ultimo para el flujo del servidor es necesario implementar la funci´on RECORD donde se nos indica que se van a comenzar a enviar los flujos multimedia a los puertos establecidos en las peticiones anteriores, en este momento se inician los servidores UDP de los distintos TrackInfo de la ReceiveSession aunque todav´ıa es necesario implementar la RebroadcastSession y las peticiones asociadas con ella para poder retransmitir el streaming que estamos recibiendo. Primero creamos una RebroadcastSession la cual es capaz de almacenar la informaci´on del cliente que esta recibiendo el streaming as´ı como de P´agina 67 Device to Device Implementaci´on cada uno de los flujos que se van a retransmitir desde la ReceiveSession que lleva asociada, es la sesi´on encargada de que los servidores UDP de la ReceiveSession comiencen o dejen de reenviar los datos al cliente asociado a la sesi´on. Esta sesi´on tambi´en utiliza la ayuda de una peque˜na clase auxiliar RebroadcastTrackInfo donde almacena la informaci´on de cada flujo. A continuaci´on es necesario reimplementar cada una de las peticiones DESCRIBE, SETUP(mode=play) y PLAY, porque a pesar de que ya ven´ıan implementadas en el servidor proporcionado por la librer´ıa estas trabajan directamente con la sesi´on que crea al realizar un streaming desde la c´amara y micr´ofono. Empezamos reimplementando la petici´on DESCRIBE, esta igual que el ANNOUNCE viene asociada con una ruta para identificar que ReceiveSession se desea reproducir, en caso de estar vac´ıo se intentara crear una sesi´on para el streaming en tiempo real de nuestro dispositivo. En caso contrario se creara una RebroadcastSession y se la asociara con la ReceiveSession correspondiente, y se creara una nueva descripci´on de sesi´on utilizando los datos de los flujos almacenados anteriormente en la ReceiveSession que sera enviada al cliente. Figure 20: Diagrama de clases de la soluci´on multistreaming Despu´es ha sido necesario reimplementar la petici´on SETUP cuando P´agina 68 Device to Device Implementaci´on es llamada por una RebroadcastSession, en esta petici´on estableceremos los puertos a los que enviaremos los flujos multimedia y configuraremos las RebroadcastTrackInfo de acuerdo con esto para posteriormente comenzar a reenviar el contenido. Finalmente cuando el cliente asociado a la RebroadcastSession realice la petici´on PLAY, una nueva implementaci´on de esta petici´on suscribir´a las direcciones y puertos asociadas con los flujos a los servidores UDP de la ReceiveSession de tal forma que el cliente comenzara a recibir el streaming. Tambi´en ha sido necesario reimplementar la petici´on TEARDOWN para cada una de las sesiones de tal forma que si la env´ıa una RebroadcastSession esta cancele la suscripci´on a la ReceiveSession y deje de reenviar los flujos multimedia. En el caso de la ReceiveSession adem´as de cerrar los servidores UDP dado que el cliente dejara de emitir el streaming ha de encargarse de cerrar todas las RebroadcastSessions que estaban asociadas a esa sesi´on pues se ha terminado el streaming que estaban visualizando. Debido a nuestra limitaci´on a una peque˜na red de WiFi Direct por los motivos mencionados en la Secci´on 5.1.3, hemos establecido un sistema en el cual si el emisor del streaming es un cliente conectado al Group Owner, le enviar´a el streaming para que est´e lo distribuya al resto de clientes y si el emisor es el Group Owner entonces este simplemente retransmitir´a simult´aneamente a todos los clientes. P´agina 69 Device to Device Conclusi´on 7 Conclusi´on La idea de crear redes ad hoc en dispositivos m´oviles que se encuentren cerca unos de otros sin tener que pasar por una red de los operadores de telecomunicaciones, y hacer streaming de v´ıdeo en directo a trav´es de dicha red, es algo ambicioso y dif´ıcil de llevar a cabo. Nosotros en este proyecto hemos intentado por todos los medios posibles que esta idea se pudiese llevar a cabo analizando los distintos tipos de dispositivos m´oviles, cu´ales ser´ıan los m´as adecuados, y qu´e sistema operativo ser´ıa la mejor opci´on para hacer posible esta idea. Tras habernos decidido por los dispositivos m´oviles con sistema operativo Android, ya que ´estos son los m´as comunes y los m´as usados, con un 85.9% del total de ventas de m´oviles en 2017 frente a un 16% de iOS y 0.1% otros, seg´un un reportaje [23], nos hemos puesto a investigar las posibles tecnolog´ıas de conexi´on existentes que podr´ıamos usar para la realizaci´on de este proyecto. Tras la tarea de investigaci´on dud´abamos entre dos opciones posibles, WiFi Direct o WiFi Aware. Pero debido a que la segunda opci´on es algo bastante novedoso, la falta de la documentaci´on sobre ´esta, y la falta de disponibilidad de dispositivos con esta tecnolog´ıa para la realizaci´on de pruebas durante el desarrollo, finalmente hemos optado por la primera. Al estudiar WiFi Direct m´as a fondo descubrimos que es una tecnolog´ıa cuya implementaci´on en Android presenta ciertas limitaciones (explicadas en la Secci´on 5.1) las cuales nos impiden cumplir algunos de los objetivos importantes del proyecto, entre ellos el de creaci´on de la red ad hoc. Propusimos algunas soluciones encontradas en distintos art´ıculos acerca de la creaci´on de redes ad hoc sobre WiFi Direct, pero ninguna nos pareci´o viable para este proyecto. Estas limitaciones hacen que s´olo podamos interconectar un grupo de dispositivos que se encuentren cerca unos de otros, y por tanto hacer el streaming de v´ıdeo sobre una red peque˜na. Por otra parte, la emisi´on de v´ıdeo en directo tambi´en fue un reto bastante grande que tuvimos que abordar. Para ello nos decantamos por el uso de los protocolos RTSP y RTP/RTCP en vez HTTP, a pesar de que HTTP streaming es el m´as popular actualmente, ya que las ventajas de HTTP streaming no son relevantes en nuestro caso, como explicamos en la secci´on 3.5. Tras un proceso de investigaci´on bastante largo, hemos encontrado e incluido en nuestro proyecto una librer´ıa de c´odigo abierto cuyas caracter´ısticas y limitaciones exponemos detalladamente en la secci´on 5.3. P´agina 70 Device to Device Conclusi´on Concretamente, la principal limitaci´on observada en la librer´ıa durante la fase de dise˜no, y explicada en el apartado 5.3.2, es que no se pod´ıa hacer streaming a m´ultiples dispositivos simult´aneamente, debido a que cada retransmisi´on bloqueaba la c´amara y el micr´ofono. Para solucionar este problema, hicimos cambios en la librer´ıa para que un dispositivo pueda emitir en directo a m´ultiples dispositivos a la vez accediendo una ´unica vez a los perif´ericos. Explicamos en detalle este arreglo en el apartado 6.5.1 de la secci´on Implementaci´on. Aunque por las limitaciones de WiFi Direct no es posible la creaci´on de la red ad hoc, en la secci´on 5.3.4 de Dise˜no hemos intentado simular el escenario de una red ad hoc donde el streaming se distribuye saltando de un dispositivo a otro, y estudiado las diferentes alternativas de las que dispon´ıamos para ello. Cuando planteamos simular este escenario con la librer´ıa nos encontramos con los problemas descritos en la secci´on 5.3.6. El problema es que la librer´ıa estaba ´unicamente pensada para poder retransmitir el streaming generado por el propio dispositivo. Por ello, hemos reimplementado el servidor, y desarrollado nuevas funcionalidades para poder recibir y enviar streamings, el desarrollo de las cuales se detalla en la secci´on 6.5.2. Esto nos ha permitido crear nodos de tr´ansito capaces de reenviar el streaming al mismo tiempo que lo reciben. De esta forma somos capaces de distribuir el streaming por nuestro grupo de WiFi Direct, saltando de un dispositivo a otro. De esta manera nos acercamos m´as a la soluci´on que dese´abamos desde un principio, ya que de ser posible en un futuro la existencia de un “nodo de enlace” entre dos grupos WiFi Direct, o bien la posibilidad de crear una red ad hoc mediante otra nueva tecnolog´ıa, podr´ıamos reutilizar la soluci´on que hemos desarrollado, y distribuir el streaming por la red utilizando este m´etodo. Resumiendo, hemos desarrollado una aplicaci´on desde la cual podemos crear conexiones WiFi Direct –limitando ´estas a un solo grupo de WiFi Direct de dispositivos cercanos– a trav´es de las cuales podemos hacer streaming de v´ıdeo en directo en dos modalidades distintas. La primera modalidad es Multistreaming, consistente en realizar streaming simult´aneamente a varios dispositivos. La segunda modalidad es Multihop, que consiste en que un cliente emite a un servidor, y este ´ultimo se encarga que redistribuirlo a los dispositivos que est´an conectados con ´el. La aplicaci´on tambi´en recibe un listado de streamings disponibles, y podemos reproducirlos directamente en el m´ovil pinchando sobre uno de nuestra elecci´on. Para esta funcionalidad usamos otra librer´ıa, libvlc. P´agina 71 Device to Device Conclusion 7 Conclusion The idea of creating ad hoc networks on mobile devices that are close to each other without having to go through a network of telecommunication operators, and to stream live video through that network, is a goal ambitious and difficult to carry out. In this project we have tried by all possible means to carry out this idea, by analyzing the different types of mobile devices, which would be the most appropriate, and which operating system would be the best option to make this idea possible. After having decided on mobile devices with Android operating system, since these are the most common and most used, with 85.9% of total mobile sales in 2017 compared to 16% of iOS and 0.1% other , according to a report [23], we have started to investigate the possible existing connection technologies that we could use to carry out this project. After the research task we were hesitating between two possible options, WiFi Direct or WiFi Aware. But because the second option is something quite new, the lack of documentation on it, and the lack of availability of devices with this technology for testing during development, we have finally opted for the first. When studying WiFi Direct more thoroughly we discovered that it is a technology whose implementation in Android has certain limitations (explained in Section 5.1) which prevent us from fulfilling some of the important objectives of the project, among them the creation of the red ad hoc. We proposed some solutions found in different articles about the creation of networks ad hoc on WiFi Direct, but none of them seemed viable for this project. These limitations mean that we can only interconnect a group of devices that are close to each other, and therefore wen can only make the video streaming over a small network. On the other hand, the live video broadcast was also a very big challenge that we had to address. For this we have opted for the use of the RTSP and RTP / RTCP protocols instead of HTTP, although HTTP streaming is currently the most popular, since the advantages of HTTP streaming are not relevant in our case, as we explained in the section 3.5. After a quite long research process, we have found and included in our project an open source library whose characteristics and limitations we expose in detail in the section 5.3. Specifically, the main limitation observed in the library during the design P´agina 72 Device to Device Conclusion phase, and explained in the section 5.3.2, is that one cannot stream to multiple devices simultaneously, because each retransmission blocked the camera and microphone. To solve this problem, we made changes in the library so that a device can broadcast live to multiple devices at once by accessing the peripherals only once. We explain this arrangement in detail in the 6.5.1 section of the Implementation section. Although due to the limitations of WiFi Direct it is not possible to create the ad hoc network, in the 5.3.4 section of Design we have tried to simulate the scenario of an ad hoc network where streaming is distributes jumping from one device to another, and studied the different alternatives that we had for it. When we set out to simulate this scenario with the library, we find the problems described in the section 5.3.6. The problem is that the library was only designed to be able to retransmit the streaming generated by the device itself. For this reason, we have reimplemented the server, and developed new functionalities to receive and send streamings, the development of which is detailed in the section 6.5.2. This has allowed us to create transit nodes capable of forwarding the streaming at the same time they receive it. In this way we are able to distribute the streaming all along our WiFi Direct group, jumping from one device to another. In this way we get closer to the solution we aimed at from the beginning, because if it were possible in the future the existence of a “link node” between two WiFi Direct groups, or the possibility of creating an ad hoc network by means of another new technology, it should be possible to reuse the solution we have developed, and distribute the streaming over the network using this method. In short, we have developed an application from which we can create WiFi Direct connections - limiting these to a single group of WiFi Direct of nearby devices - through which we can stream live video in two different modes. The first modality is Multistreaming, consisting of simultaneous streaming to several devices. The second mode is Multihop, which consists of a client issuing to a server, where the latter is responsible for redistributing it to the devices that are connected to it. The application also receives a list of available streams, and we can reproduce them directly on the mobile by clicking on one of our choice. For this functionality we use another library, libvlc. P´agina 73