Transmisión del flujo generado por la
cámara y el micrófono de un móvil por una

red ad-hoc de móviles

Transmission of the stream generated by the camera and
microphone of a mobile device through an ad-hoc network of

mobile devices.

TRABAJO DE FIN DE GRADO
Grado en Ingeniería Informática
Facultad de Informática

Autora:

Jingru Zhao

Dirigido por:
Simon Pickin

Codirigido por:
Daniel Alfaro Miranda

Curso 2022/23





Agradecimientos

Me gustaría agradecer toda la paciencia, comprensión y apoyo incondicional brin-
dado por familiares y amigos. Sus palabras de aliento y ánimo han sido un impulso
invaluable para mí. Sin vosotros, no habría podido llegar tan lejos :D.

Quiero dedicar este espacio también para los profesores que me han ayudado
en el camino. La calidad del trabajo ha mejorado notablemente gracias al feedback
aportado.

Quiero agradecer al Prof. Daniel Báscones García y por su valiosa contribución
en la revisión de esta memoria. Sus comentarios y sugerencias fueron de gran ayuda
para mejorar la calidad y profesionalidad de este trabajo. Del mismo modo, gracias al
Prof. Luis María Costero Valero por dedicar su tiempo en aportar unos comentarios
para mejorar la calidad de la redacción del TFG.

Agradecimientos a la Fundación Shuttleworth [1], por la concesión de un “Flash
Grant” que ha permitido la compra de los teléfonos móviles utilizados en este trabajo,
así como a Andrew Lamb, fellow de la Fundación Shuttleworth que recomendó la
concesión de dicha financiación.

Gracias a Simon Pickin, mi director de TFG, por su colaboración y guía durante
el trayecto. Del mismo modo, a Daniel Alfaro Miranda, mi codirector de TFG, quien
ha sido de gran importancia para el enriquecimiento y desarrollo del proyecto.

Por último, quiero destacar la aportación de los creadores de la biblioteca
libstreaming [2], y Guardian Project [3] por proporcionar varias de las herramientas
que se usaron en la realización de este proyecto.

ii





Índice general

Agradecimientos ii

Palabras Clave vii

Keywords viii

Resumen ix

Abstract x

1. Introducción 1
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Plan de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Introduction 8
2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Work Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3. Estado del arte 14
3.1. Comunicación D2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1. Ambient awareness y ProSe . . . . . . . . . . . . . . . . . . . 15
3.2. MANET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2. NFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.3. Wifi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.4. Wifi Direct . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.5. Wifi Aware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3. Protocolos de interés . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.1. HLS/MPEG-DASH . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.2.1. RTCP-RTP . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.3. SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.4. RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4. Software de interés (énfasis en software libre) . . . . . . . . . . . . . . 21
3.4.1. Libstreaming . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.2. LibVLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.3. Exiftools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.4. OpenPGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.5. ProofMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

iii



Índice general

4. Elección de tecnologías 24
4.1. Tecnologías determinadas por proyectos anteriores . . . . . . . . . . . 24

4.1.1. Wi-Fi Aware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2. RTP sobre UDP . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.3. RTSP con SDP . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.4. Libstreaming . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2. Tecnologías elegidas para este proyecto . . . . . . . . . . . . . . . . . 25
4.2.1. Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.2. Guardian Project: ProofMode . . . . . . . . . . . . . . . . . . 26
4.2.3. Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.4. Dagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.5. LaTeX y Overleaf . . . . . . . . . . . . . . . . . . . . . . . . . 27

5. Especificación 28
5.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.1.1. Pruebas seguras: Autenticidad e integridad . . . . . . . . . . . 29

6. Implementación 30
6.1. Investigación inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.1.1. Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1.2. Wi-Fi Aware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1.3. Libstreaming . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.3.1. Estado inicial de libstreaming . . . . . . . . . . . . . 31
6.1.3.2. Cambios realizados por los alumnos de 2018/19 . . . 32
6.1.3.3. Cambios realizados por los alumnos de 2020/21 . . . 33

6.2. Proyecto de 2020/21 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2.1. Cuestiones encontradas . . . . . . . . . . . . . . . . . . . . . . 36

6.3. Separación de Wi-Fi Aware y RTSP . . . . . . . . . . . . . . . . . . . 36
6.3.1. Localización de las partes afectada . . . . . . . . . . . . . . . 36
6.3.2. Implementación de la separación . . . . . . . . . . . . . . . . . 37
6.3.3. Realización de pruebas: Conexión directa mediante IP . . . . . 38

6.4. Transmisión de metadatos . . . . . . . . . . . . . . . . . . . . . . . . 39
6.4.1. Integridad y autenticidad en la transmisión de metadatos . . . 39

6.4.1.1. Hash . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.4.1.2. Firma electrónica . . . . . . . . . . . . . . . . . . . . 40

6.4.2. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.5. Generación y transmisión de pruebas mediante ProofMode . . . . . . 42
6.6. Inyección de dependencias para la configuración dinámica de la red . 44

6.6.1. Patrón de diseño: Inyección de dependencias . . . . . . . . . . 44
6.6.2. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.7. Shared Secret Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.8. Accesibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7. Conclusiones y trabajo futuro 49
7.1. Recapitulación y evaluación . . . . . . . . . . . . . . . . . . . . . . . 49
7.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7.3. Observaciones finales . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

iv



Índice general

8. Conclusions and future work 54
8.1. Recap and evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.2. Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.3. Final Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

A. Detalles del diseño 59
A.1. Investigación y análisis inicial . . . . . . . . . . . . . . . . . . . . . . 59

A.1.1. Proyecto 2018/19: D2D . . . . . . . . . . . . . . . . . . . . . . 59
A.1.2. Proyecto 19/20: Crowdstreaming . . . . . . . . . . . . . . . . 60
A.1.3. Firma digital . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

B. Resolución de cuestiones encontradas 63
B.1. Elementos de la lista de streams llevan al mismo stream . . . . . . . . 63

Acrónimos 69

v



Índice de figuras

1.1. Diagrama de la separación entre WFA y RTSP para facilitar la intro-
ducción de nuevas tecnologías . . . . . . . . . . . . . . . . . . . . . . 4

1.2. Plan de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1. Diagram illustrating the separation between WFA and RTSP to faci-
litate the introduction of new technologies . . . . . . . . . . . . . . . 11

2.2. Work Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1. Ilustración obtenida de [24] donde muestra la relación entre el ancho
de banda, rango de alcance y latencia de las distintas redes móviles . 14

6.1. Modos de funcionamiento de WiFi Aware . . . . . . . . . . . . . . . . 31
6.2. Diagrama de clases. Relación Worker-Selector . . . . . . . . . . . . . 33
6.3. Diagrama de clases con los cambios realizados por los alumnos de

20/21. Verde representa adición y rojo borrado . . . . . . . . . . . . . 34
6.4. Diagrama del multihopping creado por los alumnos de 2020/21 . . . . 35
6.5. Diagrama simplificado de los roles de WifiAwareNetwork y RTSPSer-

verWFAModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.6. Inyección de dependencias . . . . . . . . . . . . . . . . . . . . . . . . 46
6.7. Modo Shared Secret mediante SHA de una contraseña . . . . . . . . . 47
6.8. Modo Shared Secret mediante clave simétrica establecida mediante el

algoritmo Diffie-Hellman . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.9. Funcionamiento del algoritmo Diffie-Hellman. Obtenido de [73] . . . 48

A.1. Diagrama de clases que muestra las relaciones con los Packetizer . . 60

vi



Palabras Clave

Wifi Aware

D2D

Android

RTSP

Libstreaming

Redes Ad hoc móviles (MANETs)

streaming de vídeo

multicast de vídeo

vii



Keywords

Wifi Aware

D2D

Android

RTSP

Libstreaming

Mobile Ad hoc Networks (MANETs)

video streaming

multicast streaming

viii



Resumen

El ámbito del multicast en las MANET es una vertiente poco explorada en la
actualidad. El objetivo del presente trabajo consiste en ampliar la funcionalidad de
una aplicación de transmisión de contenido audiovisual en directo caracterizada por
su naturaleza descentralizada y expansiva, con el fin de sobrepasar las limitaciones
físicas que impiden al dispositivo establecer comunicación con el resto del mundo.

Este proyecto constituye la continuación del TFG “Multistreaming de video y
audio en una red ad hoc de dispositivos móviles corrientes” [4], en donde imple-
mentaron las bases necesarias para definir la naturaleza de esta aplicación. En el
presente proyecto, se pretende mejorar la adaptabilidad de la aplicación para que
se ajuste a las diferentes necesidades y especificaciones de los dispositivos. Con ello,
mejorar el aislamiento de las capas de la aplicación para que estas sean fácilmente
desacoplables y sustituibles. Además, se pretende fortalecer el contenido audiovisual
para que en el futuro pueda utilizarse como evidencia en la denuncia de crímenes.
Para lograrlo, se explorará el tema de la seguridad en las MANET y se investigarán
formas de proteger los datos enviados a través de esta red.

El código fuente de este proyecto está alojado en el siguiente repositorio público
de GitHub: https://github.com/JingRZ/MANET_2223

ix

https://github.com/JingRZ/MANET_2223


Abstract

The field of multicast in MANETs is currently an underexplored area. The ob-
jective of this study is to expand the functionality of a live audiovisual content
streaming application characterized by its decentralized and expansive nature, ai-
ming to overcome the physical limitations that hinder devices from establishing
communication with the rest of the world.

This project is a continuation of the Bachelor’s Thesis titled “Multistreaming
of video and audio in an ad-hoc network of common mobile devices” [4], where
the necessary foundations were laid to define the nature of this application. In this
project, the aim is to improve the adaptability of the application to accommodate
the different needs and specifications of the devices. This involves enhancing the
isolation of the application layers to make them easily decoupled and replaceable.
Furthermore, the objective is to strengthen the audiovisual content so that it can
be used as evidence in the future for crime reporting. To achieve this, the topic
of security in MANETs will be explored, investigating ways to protect the data
transmitted through this network.

The source code of this project is hosted in the following public GitHub reposi-
tory:https://github.com/JingRZ/MANET_2223

x

https://github.com/JingRZ/MANET_2223




1. Introducción

1.1. Motivación

La base sobre la que se asienta este proyecto, esbozado por los alumnos del año
2018/19, retocado por los alumnos del año 19/20 y perfilado por los alumnos del año
2020/21, consiste en una red descentralizada o MANET (Mobile Ad-hoc NETwork),
donde los usuarios pueden establecer comunicación directa entre sí sin la intervención
de una estación central de control. Los nodos de esta red tienen total libertad para
desplazarse, lo que flexibiliza el rango de alcance, y no dependen de ningún nodo
“master” para funcionar. Este tipo de red puede resultar útil en situaciones donde
la infraestructura red ha sido bloqueada, ya sea debido a un desastre natural o de
forma artificial.

Escenario Witness: Un posible caso de uso sería la documentación y di-
fusión de casos de violación de derechos humanos, lo cual es especialmente
valioso en situaciones de crisis o conflictos donde las comunicaciones con el
exterior han quedado bloqueadas para proteger los intereses de unos pocos. El
objetivo en este contexto es hacer que el stream, es decir, el contenido audiovi-
sual, viaje de un dispositivo a otro hasta salir de la zona de bloqueo, ocultando
al mismo tiempo la identidad del denunciante y los nodos por los que ha pasa-
do, garantizando así la protección de los denunciantes y evitando represalias
injustas a los nodos involucrados. Si la red logra evadir la censura, los vídeos
podrán ser transmitidos a una custodia segura, provisional o permanente como
Witness, una organización que se dedica a la custodia y promoción de vídeos
de este tipo. Para la custodia segura de vídeos, también existe el sistema Secu-
reDrop [5], diseñado y desarrollado por Aaron Swartz y otros, específicamente
para garantizar la seguridad y confidencialidad en la custodia de vídeos. Su
propósito es permitir a los periodistas cargar documentos y vídeos de forma
anónima en un servidor alojado en la red Tor [6], una red anónima que per-
mite a los usuarios navegar por Internet de forma segura y privada al cifrar y
redirigir su tráfico a través de múltiples nodos voluntarios en todo el mundo,
ocultando así su identidad y ubicación. Esto garantiza que la identidad de los
periodistas y las fuentes se mantenga protegida durante el proceso de entrega
de los archivos.

Escenario Humanitarian: Una aplicación de red móvil ad hoc sería de
gran utilidad en escenarios donde un desastre natural de gran magnitud ha
interrumpido las comunicaciones con el exterior en una zona aislada. En tales
situaciones de emergencia, es crucial informar al mundo sobre la situación y
solicitar asistencia [7] [8] [9]. Esta herramienta permitiría transmitir mensajes
de socorro de un dispositivo a otro, formando una cadena de comunicación que
se extiende desde la zona aislada hasta un lugar donde sea posible establecer

1



Introducción

contacto con el exterior, superando las limitaciones de las infraestructuras
de comunicación dañadas en el área afectada. La flexibilidad y adaptabilidad
de una red móvil ad hoc permitirían establecer comunicaciones incluso en
entornos caóticos y desafiadores, facilitando así la coordinación de los esfuerzos
de socorro y la movilización de recursos para asistir a las personas afectadas.

A partir de ahora se hará mención a los 2 escenarios anteriores como Witness
y Humanitarian, respectivamente.

El presente proyecto trata de una continuación y ampliación del TFG del año
20/21 [4], por ende, utiliza una gran parte de las tecnologías que se determinaron en
dicho trabajo. Entre ellas, se encuentra WiFi Aware, una tecnología basada en WiFi
que permite establecer una MANET mediante su capacidad de descubrimiento de
vecinos por proximidad. No obstante, el uso limitado de WiFi Aware en dispositivos
móviles actuales plantea desafíos significativos en términos de flexibilidad y adapta-
bilidad de la aplicación Android desarrollada por los alumnos en el año 20/21. La
falta de documentación exhaustiva sobre esta tecnología relativamente reciente ha
dificultado su integración en proyectos actuales, y su escasa adopción en dispositivos
móviles podría ser una de las principales razones de su baja popularidad en el mer-
cado actual. De hecho, los dispositivos con Wifi Aware que se han usado en los TFG
de 19/20, 20/21 y el presente proyecto se adquirieron gracias a una beca concedida
por la Fundación Shuttleworth [1].

Es fundamental enfrentar estos desafíos y superar las barreras que restringen la
adopción generalizada de WiFi Aware. El objetivo de este proyecto, al igual que sus
predecesores, es demostrar el potencial y la viabilidad de esta tecnología. No solo se
busca mejorar su flexibilidad y adaptabilidad en diversos dispositivos, sino también
abrir nuevas oportunidades para el desarrollo de aplicaciones móviles innovadoras
en el futuro.

Una de las desventajas de las MANET reside en la ausencia de un sistema de
seguridad centralizada. Esto las hace vulnerables a ataques cibernéticos de todo tipo
como ataque de intermediario [10], denegación de servicio [11], o en el caso de esta
aplicación, inyección de flujos con contenido inadecuado, como pornografía infantil,
o modificado, tratando de hacerse pasar por un flujo real y original. Estos ataques
conciernen sobre todo al escenario Witness, que implica la recopilación de pruebas
para la denuncia de crímenes, ya que la información transmitida es altamente sensible
y, por lo tanto, de gran valor.

El crecimiento exponencial de la inteligencia artificial en los últimos años ha
popularizado el término "deepfake"(combinación de "deep learning 2"fake"). Este
término se refiere a la creación de contenido falso, como voces, imágenes e incluso
vídeos, utilizando una amplia base de datos y muestras variadas disponibles en
Internet [12] [13] [14] [15]. La tecnología deepfake ha alcanzado un nivel de realismo
notable, incluyendo la sincronización precisa de los movimientos de los labios (lip
sync), lo cual puede engañar fácilmente a un público poco exigente que no verifica
las fuentes de los contenidos que consumen en línea [16] [17].

2



Introducción

Los alumnos del año 2019/20 plantearon más escenarios enfocados es obstruir
el funcionamiento normal en el escenario Witness [ [18], 1.3] tales como inyección
de flujos inapropiados, modificación y reemisión del video para hacerle pasar por
una emisión original o ataques de denegación de servicio (DoS). En este contexto,
resulta crucial contar con evidencias sólidas que respalden y demuestren la autenti-
cidad de las pruebas audiovisuales transmitidas entre diferentes dispositivos. Cabe
mencionar que con el rápido avance de la tecnología, se está haciendo cada vez más
fácil manipular o editar datos y hacer que parezcan legítimos e inalterados ante ojos
inexpertos. En consecuencia, la demanda por un servicio de verificación ha sufrido
un crecimiento exponencial, lo que desembocará en el crecimiento del volumen de
negocio para las agencias de verificación. [19] [20]

Si bien la capacidad de transmitir dichos contenidos es esencial para su supervi-
vencia y expansión, contar con pruebas verificables se vuelve igualmente importante.
Estas evidencias contribuirán a establecer la veracidad de los contenidos en un en-
torno donde los deepfakes están cada vez más presentes.

1.2. Objetivos

El presente proyecto tiene por meta ampliar la funcionalidad del proyecto realiza-
do en el TFG del año 20/21, descrita en la sección 1.2 de su memoria [4], centrándose
en 2 focos principales:

La separación entre capas de la aplicación para facilitar la sustitución de las
tecnologías empleadas por otras, resultando en una aplicación fácilmente adap-
table a las tecnologías que cada dispositivo dispone y actualizable para incor-
porar nuevas tecnologías que se desarrollarán en el futuro.

La incorporación de pruebas a la transmisión del stream, pudiendo así demos-
trar su autenticidad e integridad y en consecuencia se tenga en consideración
como una evidencia. Esto resulta de gran valor para el escenario Witness en
la denuncia de crímenes, pero también cobra importancia para el escenario
Humanitarian al poder localizar las víctimas gracias a estas pruebas.

Este proyecto aborda esta primera problemática mediante el aislamiento y la en-
capsulación de WiFi Aware, que tras finalizar el proyecto del año 20/21, su funciona-
miento dependía completamente de otra tecnología imposibilitando la introducción
de nuevas tecnologías. Este enfoque facilitará el proceso para sustituir las tecnolo-
gías actuales y abrirá oportunidades para el desarrollo de aplicaciones innovadoras
y eficientes en la transmisión de datos en tiempo real con la incorporación de nue-
vas tecnologías en el futuro. En la Figura 1.1 se ilustra una versión simplificada del
objetivo descrito.

Para ello, se han planteado los siguientes pasos:

1. Comprensión del problema planteado: Obtener una comprensión completa del
problema, la arquitectura existente y las tecnologías involucradas en el pro-
yecto anterior.

3



Introducción

2. Investigación sobre posibles soluciones: Explorar diferentes enfoques y solucio-
nes, tanto parciales como completas, para abordar el problema identificado.
Esta fase de investigación ayudará a determinar el mejor curso de acción.

3. Localización de las clases afectadas: Identificar las clases y componentes especí-
ficos que deben separarse para lograr la modularidad y adaptabilidad deseadas.

4. Diseñar e implementar nuevas clases para gestionar las funcionalidades a se-
parar, además de rediseñar las ya existentes para ajustarse a los cambios.

5. Realización de pruebas sin WiFi Aware, lo que incluye:

Diseño e implementación de una red rudimentaria que sustituya el proceso
de establecimiento de conexión entre 2 dispositivos que proporciona WiFi
Aware.

Diseño e implementación de un servicio para reintentar la conexión tras
un tiempo para los destinos con los que no se ha podido establecer cone-
xión todavía para dinamizar la red.

Figura 1.1: Diagrama de la separación entre WFA y RTSP para facilitar la
introducción de nuevas tecnologías

Por otro lado, es fundamental garantizar la protección tanto del stream en sí como
de las pruebas asociadas que respaldan su autenticidad e integridad. Esto implica
la transmisión de datos adicionales junto con el stream, los cuales demuestran de
manera inequívoca el dispositivo origen que ha generado el stream y garantizan
la integridad tanto del contenido audiovisual transmitido como de las pruebas que
validan su autenticidad.

Para ello, se han planteado los siguientes pasos:

1. Comprobar el uso y conveniencia de la incorporación de ProofMode en el
proyecto.

4



Introducción

2. Incorporación de la herramienta en el proyecto. Dónde y cuándo usarla.

3. Transmisión de los resultados generados de un dispositivo a otro, acompañando
al stream al que hace referencia.

4. Guardar esos datos en un dispositivo cuando el usuario decide guardar el
stream.

Para la gestión de las tareas de este proyecto, se ha utilizado la metodología
ágil kanban [21], basada en la entrega incremental. Implica la división del proyecto
en iteraciones o sprints más pequeños, donde se realizan reuniones regulares para
establecer tareas y prioridades en función de los requisitos cambiantes. Y un enfo-
que basado en componentes, mediante la reutilización de componentes y módulos
preexistentes, como frameworks y bibliotecas, para aprovechar las funcionalidades
predefinidas.

En resumen, este trabajo tiene por objetivos:

1. Implementar la separación entre capas para facilitar la incorporación de dife-
rentes tecnologías en la aplicación, permitiendo así su adaptación en disposi-
tivos con diferentes especificaciones en el futuro.

2. Realizar un fork de la biblioteca libstreaming con los cambios realizados en
la capa RTSP (Real Time Streaming Protocol) que se explicará más adelante
3.3.4 y publicar un proyecto de software libre.

3. Introducir la posibilidad de que el contenido multimedia captado por la apli-
cación pueda usarse en situaciones diversas, ya sean pruebas en un juicio en
el escenario Witness, o bien datos para localizar geográficamente a los afec-
tados por un desastre natural en el escenario Humanitarian. Centrándose en
el escenario Witness, resulta imprescindible proteger el anonimato del denun-
ciante y los nodos colaboradores en la transmisión del stream. Por ende, debe
considerarse la seguridad tanto de los nodos como de los datos transmitidos.

Uno de los usos que se le pueden dar a este proyecto, debido a su naturaleza
expansiva y el amplio rango que puede cubrir en una zona densamente poblada, sería
la retransmisión de mensajes de emergencia de uso gubernamental. Se espera con
ello contribuir al ámbito de las redes descentralizadas, ofreciendo una herramienta
que ayudará a proteger los derechos humanos y a alcanzar un futuro mejor.

1.3. Plan de trabajo

Para lograr la ejecución exitosa del proyecto y alcanzar los objetivos propuestos,
se ha realizado una planificación detallada en la Figura 1.2. Para visualizar de ma-
nera clara y organizada las actividades y su programación en el tiempo, se puede
ver el diagrama de Gantt en la Figura 1.3.

5



Introducción

Figura 1.2: Plan de trabajo

6



Introducción

F
ig

ur
a

1.
3:

D
ia

gr
am

a
de

G
an

tt

7



2. Introduction

2.1. Motivation

The foundation on which this project is based, outlined by the students of the
2018/19 academic year, shaped by the students of the 19/20 academic year, and
refined by the students of the 2020/21 academic year, consists of a decentralized
network or MANET [see Glossary], where users can establish direct communication
with each other without the intervention of a central control station. The nodes
in this network have complete freedom of movement, which enhances the range
of coverage, and they do not depend on any "master"node to function. This type
of network can be useful in situations where the network infrastructure has been
disrupted, either due to a natural disaster or artificially.

Witness Scenario: One potential use case would be the documentation and
dissemination of human rights violations, which is especially valuable in cri-
sis or conflict situations where external communications have been blocked to
protect the interests of a few. The goal in this context is to make the stream,
i.e., the audiovisual content, travel from one device to another until it exits
the blocked zone, while simultaneously hiding the identity of the whistleblo-
wer and the nodes it has passed through, thus ensuring the protection of the
whistleblowers and preventing unjust retaliation against the involved nodes. If
the network successfully evades censorship, the videos can be transmitted to
a secure, temporary, or permanent custody such as Witness, an organization
dedicated to the custody and promotion of such videos. For the secure custody
of videos, there is also the SecureDrop system [5], designed and developed by
Aaron Swartz and others, specifically to ensure security and confidentiality
in the custody of videos. Its purpose is to enable journalists to anonymously
upload documents and videos to a server hosted on the Tor network [6], an
anonymous network that allows users to browse the Internet securely and pri-
vately by encrypting and redirecting their traffic through multiple volunteer
nodes worldwide, thus hiding their identity and location. This ensures that the
identity of journalists and sources remains protected during the file delivery
process.

Humanitarian Scenario: A mobile ad hoc network application would be ex-
tremely useful in scenarios where a large-scale natural disaster has disrupted
communications with the outside world in an isolated area. In such emergency
situations, it is crucial to inform the world about the situation and request
assistance [7] [8] [9]. This tool would enable the transmission of distress mes-
sages from one device to another, forming a communication chain that extends
from the isolated zone to a location where contact with the outside world can

8



Introduction

be established, overcoming the limitations of damaged communication infras-
tructures in the affected area. The flexibility and adaptability of a mobile ad
hoc network would allow for communication establishment even in chaotic and
challenging environments, thereby facilitating the coordination of relief efforts
and mobilization of resources to assist the affected individuals.

From now on, the two previous scenarios will be referred to as Witness and
Humanitarian, respectively.

The present project builds upon and extends the thesis from the year 20/21 [4],
utilizing a significant portion of the technologies determined in that work. Among
them is WiFi Aware, a technology based on WiFi that establishes a MANET through
its proximity-based neighbor discovery capability. However, the limited usage of Wi-
Fi Aware in current mobile devices poses significant challenges in terms of flexibility
and adaptability of the Android application developed by the students in the year
20/21. The lack of comprehensive documentation on this relatively new technology
has hindered its integration into current projects, and its low adoption in mobile
devices may be one of the main reasons for its limited popularity in the current
market. In fact, the devices with WiFi Aware used in the TFGs of 19/20, 20/21,
and the present project were acquired through a grant awarded by the Shuttleworth
Foundation [1].

It is crucial to address these challenges and overcome the barriers that restrict the
widespread adoption of WiFi Aware. The goal of this project, like its predecessors,
is to demonstrate the potential and viability of this technology. The aim is not only
to enhance its flexibility and adaptability across different devices but also to open
up new opportunities for the development of innovative mobile applications in the
future.

One of the disadvantages of MANETs is the absence of a centralized security
system. This makes them vulnerable to various types of cyber attacks such as man-
in-the-middle attacks [10], denial-of-service attacks [11], or in the case of this appli-
cation, injection of streams with inappropriate content, such as child pornography,
or modified streams attempting to impersonate real and original content. These
attacks are particularly concerning in the Witness scenario, which involves collec-
ting evidence for the reporting of crimes, as the transmitted information is highly
sensitive and therefore of great value.

The exponential growth of artificial intelligence in recent years has popularized
the term "deepfake"(a combination of "deep learning.and "fake"). This term refers
to the creation of fake content, such as voices, images, and even videos, using a vast
database and diverse samples available on the internet [12] [13] [14] [15]. Deepfake
technology has reached a remarkable level of realism, including precise lip synchro-
nization (lip sync), which can easily deceive an unsuspecting audience that does not
verify the sources of the content they consume online [16] [17].

The students of the 2019/20 academic year presented additional scenarios aimed

9



Introduction

at disrupting normal operations in the Witness scenario [ [18], 1.3], such as injection
of inappropriate streams, modification and retransmission of videos to make them
appear as original broadcasts, or denial-of-service (DoS) attacks. In this context,
it is crucial to have solid evidence that supports and demonstrates the authenti-
city of the audiovisual evidence transmitted between different devices. It should be
noted that with the rapid advancement of technology, it is becoming increasingly
easy to manipulate or edit data and make it appear legitimate and unaltered to
inexperienced eyes. As a result, the demand for a verification service has experien-
ced exponential growth, leading to a corresponding increase in business volume for
verification agencies [19] [20].

While the ability to transmit such content is essential for its survival and expan-
sion, having verifiable evidence becomes equally important. These pieces of evidence
will help establish the authenticity of the content in an environment where deepfakes
are increasingly prevalent.

2.2. Goals

The main objective of this project is to expand the functionality of the project
carried out in the project of the year 20/21, as described in Section 1.2 of the thesis
document [4]. The project focuses on two main areas:

The separation between application layers to facilitate the replacement of the
technologies used with others, resulting in an application that can easily adapt
to the available technologies on each device and can be updated to incorporate
new technologies developed in the future.

The inclusion of proof in the stream transmission, allowing for the demons-
tration of its authenticity and integrity. This feature is particularly valuable
in the Witness scenario for the reporting of crimes, but it is also important in
the Humanitarian scenario for locating victims based on this evidence.

This project addresses the first issue by isolating and encapsulating WiFi Awa-
re. In the previous project from 20/21, its functionality was entirely dependent
on another technology, which made it difficult to introduce new technologies. This
approach will simplify the process of replacing current technologies and create op-
portunities for the development of innovative and efficient applications for real-time
data transmission, allowing for the incorporation of new technologies in the future.
In Figure 1.1, a simplified version of the described objective is illustrated.

To achieve this, the following steps have been proposed:

1. Understand the problem at hand: Gain a comprehensive understanding of the
problem statement, the existing architecture, and the technologies involved in
the previous project.

10



Introduction

2. Conduct research on possible solutions: Explore different approaches and so-
lutions, both partial and complete, to address the identified problem. This
research phase will help in identifying the best course of action.

3. Identify the affected classes: Determine the specific classes and components
that need to be separated to achieve the desired modularity and adaptability.

4. Design and implement new classes: Create new classes that will handle the
functionalities to be separated. Redesign the existing classes to accommodate
the changes and ensure compatibility with the new architecture.

5. Conduct testing without WiFi Aware:

Develop a rudimentary network that replaces the connection establish-
ment process provided by WiFi Aware.

Implement a service that retries connection attempts to previously un-
successful destinations to optimize the network.

Figura 2.1: Diagram illustrating the separation between WFA and RTSP to
facilitate the introduction of new technologies

On the other hand, it is crucial to ensure the protection of both the stream itself
and the associated evidence that supports its authenticity and integrity. This invol-
ves the transmission of additional data along with the stream, which unequivocally
demonstrates the originating device that generated the stream and ensures the in-
tegrity of both the transmitted audiovisual content and the evidence validating its
authenticity.

To achieve this, the following steps have been proposed:

1. Verify the use and suitability of incorporating ProofMode into the project.

2. Integration of the tool into the project. Where and when to use it.

11



Introduction

3. Transmission of the generated results from one device to another, accompan-
ying the referenced stream.

4. Save this data on a device when the user chooses to save the stream.

For the management of tasks in this project, the agile Kanban methodology [21]
has been used, based on incremental delivery. It involves dividing the project into
smaller iterations or sprints, where regular meetings are held to establish tasks
and priorities based on changing requirements. It also follows a component-based
approach, utilizing the reuse of existing components and modules such as frameworks
and libraries to leverage predefined functionalities.

In summary, this work aims to:

1. Implement the separation between layers to facilitate the incorporation of dif-
ferent technologies into the application, thereby allowing its adaptation on
devices with different specifications in the future.

2. Fork the libstreaming library with the changes made in the RTSP (Real Time
Streaming Protocol) layer, which will be further explained in Section 3.3.4,
and publish it as an open-source project.

3. Introduce the possibility for the multimedia content captured by the appli-
cation to be used in various situations, such as evidence in a courtroom in
the Witness scenario or data for geolocating individuals affected by a natural
disaster in the Humanitarian scenario. Focusing on the Witness scenario, it is
essential to protect the anonymity of the whistleblower and the collaborating
nodes in the stream transmission. Therefore, the security of both the nodes
and the transmitted data must be considered.

One of the potential uses of this project, given its expansive nature and the
wide range it can cover in a densely populated area, would be the retransmission of
emergency messages for governmental use. It is expected that this will contribute
to the field of decentralized networks by offering a tool that helps protect human
rights and achieve a better future.

2.3. Work Plan

In order to achieve the successful execution of the project and accomplish the
proposed objectives, a detailed planning has been carried out as shown in Figu-
re 2.2. In order to visualize activities and their scheduled timeline clearly and in an
organized manner, the Gantt chart can be observed in Figure 1.3.

12



Introduction

Figura 2.2: Work Plan

13



3. Estado del arte

3.1. Comunicación D2D

La comunicación Device-to-Device (D2D) se refiere a la tecnología que permite el
establecimiento de comunicación directa entre dispositivos sin la necesidad de utilizar
una estación o red centralizada (Base Stations). Esta tecnología ha ganado relevancia
en el contexto de las redes de telefonía móvil, ya que se ha explorado como una opción
de enrutamiento para el tráfico de datos. En este enfoque, los dispositivos actúan
como “relay” o puntos de retransmisión, permitiendo una transferencia más eficiente
de datos y aliviando la carga en las redes celulares existentes. En consecuencia, el
D2D se ha considerado como una solución para el “cellular data offloading” [22] [23],
donde los dispositivos pueden comunicarse directamente entre sí sin pasar por la
infraestructura celular tradicional, lo que puede resultar en una mejor calidad de
servicio y un uso más eficiente de los recursos de red.

Debido a su capacidad para operar sin depender de una infraestructura de red,
esta tecnología se presenta como una solución prometedora para abordar algunos
de los desafíos inherentes a las redes 5G. Uno de estos desafíos se relaciona con su
operación en frecuencias altas (High-band 5G), que oscilan entre los 25-39 GHz. Esto
implica que su rango de cobertura es más limitado y su capacidad de penetración es
menor en comparación con las tecnologías que utilizan frecuencias más bajas. [24]

Figura 3.1: Ilustración obtenida de [24] donde muestra la relación entre el ancho
de banda, rango de alcance y latencia de las distintas redes móviles

En consecuencia, para lograr la misma cobertura que las redes que emplean fre-
cuencias más bajas, se requiere una mayor cantidad de estaciones, lo cual puede tener
efectos negativos en el medio ambiente, como la contaminación visual, y resultar en

14



Estado del arte

un costo mayor debido a la instalación y mantenimiento.

3.1.1. Ambient awareness y ProSe

El término “ambient awareness” se refiere a la capacidad de detectar y registrar
información de manera pasiva sobre el entorno físico y social en el que se utiliza.
Esta información puede incluir datos como la geolocalización, la actividad en redes
sociales y la presencia de otros dispositivos inalámbricos cercanos. Debido a ello, esta
tecnología está presente en diferentes campos, desde el marketing hasta la gestión
de emergencias y seguridad pública. Sin embargo, ya que trata con información de
carácter personal, también plantea preocupaciones en relación a la privacidad y la
protección de datos personales. [25]

“Proximity Services” (ProSe) es un conjunto de servicios que aprovechan las capa-
cidades de proximidad de las redes 5G para habilitar la comunicación D2D. Una de
sus características clave es el servicio de descubrimiento, que permite a los dispositi-
vos identificar y localizar otros dispositivos cercanos con los que puedan interactuar.
Esto facilita una variedad de aplicaciones y casos de uso, como la formación de redes
ad hoc, la colaboración entre dispositivos para compartir recursos o la comunicación
directa sin la necesidad de una conexión a Internet. Además, los servicios de ProSe
también tienen aplicaciones en entornos de Internet de las Cosas (IoT), donde los
dispositivos cercanos pueden colaborar y compartir información de manera eficiente
sin tener que pasar por una red centralizada. Esto es especialmente útil en casos
en los que se requiere baja latencia y alta confiabilidad, como en aplicaciones de
seguridad o automatización industrial.

Esta tecnología resulta relevante debido a su capacidad de descubrimiento de
vecinos por cercanía, pudiendo considerarse así una alternativa para sustituir WiFi
Aware en un futuro.

3.2. MANET

Las redes móviles ad hoc, también conocidas como MANET (Mobile Ad-hoc
NETworking), consisten en una red inalámbrica donde los nodos pueden establecer
una comunicación directa sin la presencia de una infraestructura de control centra-
lizada. Estas redes permiten una mayor flexibilidad y adaptabilidad a situaciones
cambiantes debido a que los nodos pueden desplazarse libremente. Es por ello que
se utilizan comúnmente en aplicaciones militares [26], en situaciones en donde las
comunicaciones han sido interrumpidas, ya sea por un desastre natural o de forma
artificial.

Existen diferentes protocolos de enrutamiento utilizados en las redes MANET,
entre los que se incluyen los proactivos, como DSDV [27] y OLSR [28], que mantienen
la información actualizada de todos los nodos de la red, repercutiendo en un alto
consumo energético y carga en la red. También están los reactivos, como AODV [29]
y DSR [30], que establecen la ruta solo cuando se necesita, lo que reduce el consumo

15



Estado del arte

y la carga, pero puede aumentar el tiempo de descubrimiento de la ruta y retrasar la
entrega del paquete. Los protocolos híbridos, como ZRP [31] y HWMP [32], dividen
la red en zonas y utilizan un enfoque proactivo dentro de cada zona y reactivo entre
las zonas.

En una red MANET, los nodos pueden transmitir información de ubicación y
actividad a otros nodos cercanos, lo que permite que los usuarios tengan una idea
del contexto en el que se encuentran los otros nodos de la red. Esto puede ser útil
en situaciones en las que los usuarios necesitan colaborar o coordinarse en tiempo
real sin tener que realizar una comunicación explícita. [33]

A diferencia de otros artículos que se centran en el enrutamiento hacia un des-
tino específico en una red MANET [34] [35], este proyecto aborda la situación del
broadcast/multicast. Con este enfoque, surgen interrogantes relacionadas con el en-
rutamiento, como la prevención de bucles en la transmisión, evitar la saturación de
la red seleccionando el nodo óptimo, y qué política o métrica utilizar para deter-
minar ese nodo. Entre las métricas a considerar, se debe plantear si se prioriza la
distancia, la potencia del nodo, obtenida previamente mediante el intercambio de
información entre nodos, la carga actual de saturación, etc. Con el fin de que la
información escape de la zona aislada y alcance un dispositivo seguro que pueda
custodiarla.

Es importante destacar que estas tecnologías están en constante evolución y ac-
tualización, lo que puede influir en su aplicación y funcionalidad. A continuación, se
presenta una visión de tecnologías que utilizan la comunicación D2D en la actuali-
dad.

3.2.1. Bluetooth

Bluetooth es una tecnología inalámbrica que se utiliza comúnmente en redes
de área personal (PAN) para establecer conexiones inalámbricas entre dispositivos
cercanos. Es un protocolo de radio inalámbrico de baja potencia que transmite datos
mediante una banda de frecuencia sin licencia de 2.4GHz. Según se cita en su página
web [36].

«Bluetooth technology uses the 2.4 GHz ISM spectrum band (2400 to 2483.5
MHz).»

«Radio spectrum stretches from 30 Hz to 300 GHz. The lower the frequency
the longer the range. However, the lower the frequency the lower the data rate
it can support.»

Esta tecnología es capaz de soportar la comunicación entre dispositivos P2P a
través de 79 canales y se utiliza principalmente para la transmisión inalámbrica de
audio. En este sentido, Bluetooth Classic se ha convertido en el estándar de protocolo
de radio [37] [38] para dispositivos inalámbricos de audio, tales como altavoces, auri-
culares y sistemas de entretenimiento para automóviles. Adicionalmente, Bluetooth

16



Estado del arte

Classic permite aplicaciones de transferencia de datos, como la impresión móvil, lo
que aumenta su versatilidad.

Cabe mencionar Bluetooth Low Energy o BLE, una variante de Bluetooth dise-
ñada específicamente para aplicaciones que requieren bajo consumo energético como
dispositivos portátiles, sensores y dispositivos IoT (Internet de las cosas). Tiene una
menor velocidad de transferencia de datos que Bluetooth Classic (hasta 3 Mbps
teóricos para Classic y entre 1 Mbps y 2 Mbps para Low Energy), por lo que se usa
principalmente en dispositivos que transfieren pequeñas cantidades de información
como sensores.

Si bien esta tecnología ha sido ampliamente utilizada para la transmisión de
audio, archivos y sincronización de dispositivos, su ancho de banda limitado la con-
vierte en una opción ineficiente para la transmisión de vídeo en directo. Sin embargo,
es importante tener en cuenta que Bluetooth sigue evolucionando y mejorando con
cada nueva versión, lo que puede traer mejoras en términos de rendimiento y capa-
cidades de transmisión.

3.2.2. NFC

NFC (Near Field Communication) [39] es una tecnología inalámbrica de cor-
to alcance, generalmente a menos de 10 centímetros de distancia. Esta tecnología
funciona mediante la emisión de una señal de radio de corto alcance desde un dis-
positivo NFC, que puede ser leída por otro dispositivo NFC cercano. Esto permite
una transferencia rápida de información de pequeño tamaño, como el intercambio
de contactos o la realización de pagos móviles.

Sin embargo, debido a que NFC es una tecnología de corto alcance y baja velo-
cidad de transferencia de datos, resulta inadecuada e ineficiente para la transmisión
de vídeo.

3.2.3. Wifi

Wi-Fi (Wireless Fidelity) [40] se basa en el estándar IEEE 802.11, que establece
las especificaciones y protocolos para la comunicación inalámbrica. Mediante la im-
plementación de puntos de acceso inalámbricos y dispositivos compatibles, los usua-
rios pueden conectarse a una red Wi-Fi y compartir información, acceder a servicios
en línea, comunicarse a través de aplicaciones de mensajería y realizar activida-
des en línea en sus dispositivos habilitados para Wi-Fi, como teléfonos inteligentes,
computadoras portátiles, tabletas y otros dispositivos electrónicos.

Wi-Fi utiliza varios protocolos de seguridad para garantizar la protección de las
redes inalámbricas y los datos transmitidos: WEP (Wired Equivalent Privacy) fue
el primer protocolo de seguridad utilizado en redes Wi-Fi. Sin embargo, se considera
obsoleto y se ha demostrado que es vulnerable a ataques de seguridad. Por otro
lado, WPA (Wi-Fi Protected Access) reemplazó a WEP y mejoró significativamente

17



Estado del arte

la seguridad. Incluye dos versiones: WPA-Personal (WPA-PSK) y WPA-Enterprise.
WPA utiliza claves de cifrado dinámicas y un mecanismo de autenticación más se-
guro que WEP. Posteriormente, apareció WPA2 (Wi-Fi Protected Access 2), una
versión mejorada de WPA y se considera el estándar de seguridad más utilizado en
redes Wi-Fi en la actualidad. Utiliza el protocolo de cifrado AES (Advanced Encry-
ption Standard) y proporciona una mayor protección contra ataques de seguridad.
La versión más reciente de los protocolos de seguridad Wi-Fi, WPA3 (Wi-Fi Pro-
tected Access 3), introduce características como el cifrado individualizado de datos
y una autenticación más robusta.

Opera en dos capas del modelo OSI: la capa física y la capa de enlace de datos,
pero también existen protocolos que se encargan de gestionar funciones pertenecien-
tes a otras capas de este modelo, como la segmentación y reensamblado de datos
(capa de transporte), el enrutamiento (capa de red) y la gestión de sesiones (capa
de sesión).

Debido a la naturaleza descentralizada de este proyecto, centrado en la comunica-
ción directa P2P sin pasar por una estación base, esta tecnología resulta inadecuada.

3.2.4. Wifi Direct

Wi-Fi Direct [41] es una tecnología D2D desarrollada por Wi-Fi Alliance. Fue
publicada por primera vez en octubre de 2010 y posteriormente fue incorporada por
Google en dispositivos Android a partir de la versión 4.0, lo que impulsó su adopción
en el mercado. Esta tecnología se utiliza ampliamente en dispositivos móviles, como
smartphones y tabletas, así como en televisores inteligentes, impresoras y cámaras
digitales.

A diferencia de otras tecnologías de comunicación inalámbrica, Wi-Fi Direct per-
mite que los dispositivos establezcan una conexión directa entre sí sin necesidad de
una infraestructura de red centralizada. No obstante, Wi-Fi Direct presenta algunas
limitaciones. Por un lado, su topología se basa en una estructura en estrella, lo que
significa que todas las comunicaciones deben pasar a través de un dispositivo que
actúa como "group leader". Además, la especificación de Wi-Fi Direct contempla
la posibilidad de que un dispositivo pueda ser miembro de más de un grupo, pero
esta característica no es obligatoria y muchos fabricantes, en particular Google en el
sistema Android, han optado por no implementarla, haciendo totalmente impráctica
la implementación con Wifi Direct del ’multihopping’, un aspecto crucial de nuestra
aplicación. En consecuencia, resulta inadecuado para este proyecto.

A pesar de estas limitaciones, Wi-Fi Direct sigue siendo una opción popular
debido a su flexibilidad y eficiencia en la compartición de archivos y datos. Es es-
pecialmente útil en entornos donde no hay una infraestructura de red disponible o
donde la conectividad a través de una red centralizada puede ser limitada o poco
práctica.

18



Estado del arte

3.2.5. Wifi Aware

Wi-Fi Aware [42] es una tecnología D2D basada en el estándar IEEE 802.11 Wi-
Fi, lo que la hace compatible con una amplia gama de dispositivos al no requerir
hardware adicional para su funcionamiento.

Es una extensión del estándar Wi-Fi que agrega una nueva capa en el modelo de
referencia OSI, conocida como capa de servicio de descubrimiento (Service Discovery
Layer). Esta capa se encuentra entre la capa de enlace de datos y la capa de red
y proporciona funcionalidades para descubrir y conectar dispositivos cercanos sin
necesidad de una infraestructura de red centralizada. Permite a los dispositivos Wi-
Fi Aware descubrir servicios y recursos disponibles en otros dispositivos cercanos,
establecer conexiones directas entre ellos y compartir información de manera rápida
y eficiente.

Debido a su capacidad para operar sin depender de una infraestructura de red,
esta tecnología se presenta como una solución prometedora para abordar algunos de
los desafíos inherentes a las redes móviles actuales, como la necesidad de una mayor
eficiencia energética y la reducción del costo de implementación de infraestructura.

3.3. Protocolos de interés

3.3.1. HLS/MPEG-DASH

El protocolo HTTP Live Streaming (HLS) [43] fue desarrollado por Apple Inc.
y se ha convertido en un estándar ampliamente adoptado en la transmisión de con-
tenido multimedia en línea. Una de las ventajas clave de HLS es su capacidad de
adaptación dinámica de la velocidad de bits (ABR), lo que significa que puede ajus-
tar la calidad de transmisión en tiempo real según la capacidad de ancho de banda
del usuario.

HLS utiliza el concepto de listas de reproducción (playlists) y segmentos para
organizar y entregar el contenido multimedia. Las listas de reproducción son archi-
vos de texto que contienen información sobre los segmentos de vídeo disponibles y
su ubicación. Los segmentos son archivos de vídeo pequeños, normalmente de 10
segundos, y autónomos que se descargan progresivamente mientras se reproduce el
contenido.

Cuando se transmite un vídeo a través de HLS, el vídeo se divide en peque-
ños segmentos de corta duración. Cada uno de estos segmentos está codificado en
diferentes velocidades de bits, lo que significa que hay varias versiones del mismo
segmento, pero con diferentes calidades de vídeo. Cuando comienza la reproducción
del vídeo, el reproductor evalúa la velocidad de la conexión y, en función de eso,
selecciona la versión del segmento que mejor se ajuste al ancho de banda disponible.

Una característica interesante de HLS es su capacidad para superar obstáculos de

19



Estado del arte

red, como firewalls y proxies, al utilizar el puerto estándar 80 para la comunicación
HTTP. Esto permite una transmisión más fluida y evita bloqueos o restricciones
impuestas por ciertos sistemas de seguridad.

MPEG-DASH (Dynamic Adaptive Streaming over HTTP) es un estándar desa-
rrollado por el grupo MPEG que se ha adoptado ampliamente en diferentes plata-
formas y dispositivos como iOS, Android o Windows. Su funcionamiento es similar
a HLS, que divide los vídeos en fragmentos más pequeños y los codifica en diferen-
tes niveles de calidad. Sin embargo, su adaptación no se ha limitado a productos
Apple, sino también en diferentes plataformas y dispositivos como iOS, Android o
Windows.

3.3.2. RTP

RTP (Real Time Transport Protocol) es un protocolo no orientado a conexión de
la capa de transporte definido en el RFC 3550 [44], utilizado para transmitir datos
en tiempo real, como audio y video, a través de redes IP. Al emplear el protocolo
UDP, se convierte en una opción idónea para aplicaciones en las que la velocidad
de transmisión y la sincronización son críticas (QoS), en este caso, transmisiones en
vivo. Además, RTP proporciona información de tiempo y secuencia, lo que permite
que el receptor reconstruya de manera precisa el flujo de datos

3.3.2.1. RTCP-RTP

RTCP (Real Time Transport Control Protocol) es un protocolo de control, defi-
nido en el RFC 3550 [44] junto con RTP, utilizado en conjunto con RTP. En otras
palabras, mientras que RTP se encarga de enviar los datos multimedia, RTCP envía
paquetes de control. Estos paquetes de control carecen de cifrado o autenticación
por sí mismo, lo que los hace vulnerables a ataques “Man-in-the-Middle Packet Mo-
dification”, por ejemplo. Para protegerse de estos ataques, RTCP se puede utilizar
en combinación con Secure Real-time Transport Protocol (SRTP) para agregar me-
canismos de seguridad.

En resumen, RTCP y RTP trabajan juntos para proporcionar una transmisión
de audio y video en tiempo real. Mientras RTP se encarga de enviar los datos multi-
media, RTCP se utiliza para el control y la recopilación de estadísticas importantes
para garantizar una transmisión fluida y de calidad.

3.3.3. SDP

SDP (Session Description Protocol) es un protocolo definido en el RFC 4566 [45],
perteneciente a la capa de aplicación. Se utiliza para describir información acerca
de una sesión multimedia, como por ejemplo la descripción de los tipos de medios
que se utilizarán, la dirección IP y puerto de origen y destino, la tasa de bits, entre
otros detalles.

Es empleado comúnmente junto con otros protocolos de transmisión de medios,

20



Estado del arte

como RTP y RTSP, para establecer y controlar sesiones multimedia en tiempo real,
como videollamadas, transmisiones en vivo y videoconferencias.

3.3.4. RTSP

RTSP (Real Time Streaming Protocol) es un protocolo no orientado a conexión
perteneciente a la capa de aplicación definido en el RFC 2326 [46]. Su función es la
configuración y el control de la entrega de datos en tiempo real, como puede ser la
solicitud de un flujo multimedia, por lo que es comúnmente utilizado en combinación
con otros protocolos de transmisión de flujo, como el RTP.

RTSP establece dos modalidades de comunicación, las cuales se describen a con-
tinuación:

Publicación (PUBLISH): El nodo cliente RTSP solicita activamente al no-
do servidor RTSP que acepte su stream y lo distribuya a otros nodos. Para
ello, el cliente envía un mensaje ANNOUNCE donde se describen los canales
multimedia que ofrece. A continuación, se envía un mensaje SETUP por cada
canal multimedia (audio y/o vídeo) para establecer los puertos de comunica-
ción, seguido de un mensaje RECORD que indica al servidor que comience la
transmisión.

Reproducción (PLAY): El cliente RTSP solicita un stream al servidor
RTSP, el cual puede ser producido por la cámara y micrófono del propio servi-
dor o por otro dispositivo mediante la modalidad anterior. Para ello, el cliente
envía un mensaje DESCRIBE en el que se especifica la URI del contenido
multimedia y el servidor responde con información detallada sobre el stream
asociado. A continuación, el cliente envía un mensaje SETUP por cada ca-
nal multimedia que le interese, especificando cómo se realizará la transmisión.
Finalmente, se envía un mensaje PLAY para notificar al servidor RTSP que
puede comenzar a enviar el flujo solicitado.

3.4. Software de interés (énfasis en software libre)

3.4.1. Libstreaming

«libstreaming is an API that allows you, with only a few lines of code, to
stream the camera and/or microphone of an android powered device using
RTP over UDP.» [2]

Libstreaming es una biblioteca de código abierto que proporciona funcionalidades
para la transmisión de vídeo en tiempo real desde un dispositivo Android. Esta
biblioteca se basa en la API de MediaCodec y utiliza los protocolos de transmisión
estándar como RTSP (Real-Time Streaming Protocol) y RTP (Real-Time Transport
Protocol) sobre UDP para la transmisión de vídeo.

21



Estado del arte

Al usar la licencia Apache 2.0 [47], permite libertad de uso del software, mante-
niendo todos los derechos de autor y patentes asociadas a este. Es decir, libre uso
comercial, libertad de modificación y distribución siempre y cuando se reconozca la
autoría.

3.4.2. LibVLC

LibVLC [48] es una biblioteca de software libre y de código abierto, bajo licen-
cia LGPL2.1, desarrollada por el proyecto VideoLAN. Se basa en el reproductor
multimedia VLC y proporciona una API que permite integrar las capacidades de
reproducción multimedia de VLC en las aplicaciones.

3.4.3. Exiftools

Exiftools [49] es una herramienta de software libre y código abierto que permite
leer y escribir metadatos de archivos digitales, como fotografías, videos y archivos
de audio. Fue desarrollada por Phil Harvey y se distribuye bajo la Licencia GPL.

Se ha usado para visualizar los metadatos asociados a los streams que se han
guardado en el dispositivo en forma de archivos multimedia en formato mp4.

3.4.4. OpenPGP

OpenPGP (Open Pretty Good Privacy) [50] es un estándar de cifrado de datos de
código abierto ampliamente utilizado para garantizar la privacidad y la autenticidad
en las comunicaciones electrónicas. Para lograrlo, ofrece un servicio de creación de
claves de cifrado, las cuales pueden ser simétricas o asimétricas. Las claves simétricas
utilizan la misma clave para cifrar y descifrar la información. Por otro lado, las claves
asimétricas generan un par de claves, una para cifrar y otra para descifrar. Este par
de claves consisten en una clave pública, que como su nombre indica, es la que se
puede hacer pública, y otra privada, que es la que el usuario tendrá que proteger.

El par de claves, conocido como clave de cifrado público-privada, tiene diferentes
usos dependiendo de la clave que se utilice para cifrar:

Si se cifra con la clave privada, se busca demostrar la autenticidad e integridad
del archivo firmado. El destinatario utilizará la clave pública del emisor para
descifrarlo, lo que demuestra que el archivo no ha sido manipulado durante el
proceso y permite conocer la identidad del firmante.

Si se cifra con la clave pública, logrará cifrar los datos durante el proceso de
entrega. Sin embargo, esto supone una amenaza para proteger el anonimato
del emisor, ya que para que el receptor sea capaz de descifrar el mensaje,
necesitará disponer de la clave privada del emisor.

En la sección A.1.4 se realiza un análisis más detallado de la aplicación de esta
herramienta en este proyecto.

22



Estado del arte

3.4.5. ProofMode

«ProofMode is a system that enables authentication and verification of multi-
media content, particularly captured on a smartphone, from point of capture
at the source to viewing by a recipient.» [51]

Desarrollado por Guardian Project, es un reboot de otra aplicación de la misma
empresa, CameraV [52]. Funciona como un servicio en segundo plano que agrega
automáticamente datos de prueba digital a todas las fotos y videos capturados por
el usuario en el dispositivo. Estas pruebas incluyen datos contextuales del disposi-
tivo, como la geolocalización, la zona horaria y el ID del hardware, que permiten
identificar de manera inequívoca el dispositivo utilizado, el momento y el lugar de
la captura. Además, para asociar estos datos al contenido multimedia, se guarda el
SHA256 del mismo como parte de las pruebas. Mantiene el mismo enfoque de Came-
raV, que consiste en el uso de OpenPGP para ofrecer un sistema de cifrado y firma
digital, y lo usa para proteger los datos recopilados para asegurar su autenticidad e
integridad.

En el escenario Witness, es primordial la protección de la identidad del denun-
ciante. Por tanto, se debería aplicar otra forma de cifrado para asegurar su ano-
nimato. Un ejemplo podría ser el caso donde el remitente obtiene la clave pública
del destinatario y la usa para cifrar los datos a transmitir. Esto asegura que sólo el
destinatario puede descifrarlo con su clave privada. Sin embargo, no se puede verifi-
car el origen de estos datos, quedando vulnerable ante un ataque de intermediario.
Para solucionarlo, el remitente podría firmar también con su clave pública. Pero
tendría que ser capaz de hacer llegar su clave privada a las autoridades para que
estos puedan comprobar su autenticidad, lo cual también implica ciertos riesgos.

23



4. Elección de tecnologías

El presente trabajo se construye sobre el proyecto “Multistreaming de video y
audio en una red ad hoc de dispositivos móviles corriente” [4] realizado en el curso
académico 2020/21. En ese proyecto, se determinó un conjunto de tecnologías que se
utilizaron para lograr los objetivos establecidos. Con el fin de ampliar el alcance de
mencionado proyecto y aprovechar lo logrado en el trabajo anterior, se ha continuado
utilizando esas mismas tecnologías en este proyecto. No obstante, se han incorporado
nuevas tecnologías. A continuación se listan las más relevantes.

4.1. Tecnologías determinadas por proyectos ante-
riores

4.1.1. Wi-Fi Aware

Wifi Aware3.2.5, de ahora en adelante WFA, es una tecnología que permite el
descubrimiento de servicios para conectar dispositivos de manera fácil y rápida, sin
necesidad de un punto de acceso o de datos móviles. Esto es posible gracias a que
utiliza señales de radiofrecuencia para detectar dispositivos cercanos que también
estén habilitados con WFA.

Además, una de las principales ventajas de esta tecnología es su bajo gasto
energético, lo que lo convierte en una opción ideal para dispositivos móviles que
necesitan optimizar su uso de batería. Por otro lado, WFA también puede funcionar
en segundo plano, lo que significa que los dispositivos pueden seguir conectados y
comunicándose entre sí sin que el usuario tenga que estar activamente usando una
aplicación o realizando una tarea específica.

En resumen, WFA es una tecnología que ofrece un descubrimiento de servicio
sencillo y eficiente para conectar dispositivos, al mismo tiempo que ofrece un bajo
consumo de energía y la posibilidad de funcionar en segundo plano.

4.1.2. RTP sobre UDP

En un proyecto de transmisión multimedia en vivo en ausencia de una red cen-
tralizada, la elección de los protocolos es fundamental para garantizar, no solo una
experiencia satisfactoria para el usuario, sino cumplir con el objetivo planteado. El
protocolo RTP3.3.2 es uno de los sistemas de retransmisión audiovisual más utili-
zados debido a su capacidad para transmitir de forma eficiente flujos de datos en
tiempo real.

24



Elección de tecnologías

Por otro lado, se utiliza UDP como protocolo de transporte debido a que se
prioriza la rapidez y expansión del stream, lo que es fundamental para evitar retrasos
en la transmisión y garantizar una experiencia fluida para el usuario. Aunque TCP
también es una opción, sus mecanismos de control de congestión pueden ralentizar
el proceso de entrega de los paquetes, lo que no es ideal en una transmisión en vivo
donde la prioridad es la velocidad y la fluidez del stream.

4.1.3. RTSP con SDP

Para la transmisión de vídeo y audio decidieron utilizar RTSP3.3.4 con RTP
sobre UDP, donde se prioriza la rapidez de transmisión y sincronización. Esto es
debido a que la naturaleza del proyecto consiste en darle el mayor alcance posible al
stream para que pueda viajar de dispositivo en dispositivo hasta alcanzar uno con
acceso a Internet.

RTSP utiliza SDP para la negociación de los parámetros para la entrega de flujo
de video y audio. De esta manera, RTSP con SDP permite una mayor flexibilidad
en la transmisión de contenidos multimedia, ya que los clientes pueden adaptarse a
diferentes configuraciones de red y requisitos de calidad de transmisión.

4.1.4. Libstreaming

Se partirá de una nueva versión de la biblioteca libstreaming3.4.1, adaptada por
los alumnos de 2020/21, para trabajar sobre la separación de capas. Más concre-
tamente, el desacoplamiento del código relacionado con Wi-Fi Aware del propio de
RTSP.

A pesar de las ventajas que ofrecen HLS y MPEG-DASH como ABR, esta carac-
terística implicaría producir múltiples streams con diferentes bit rate, aumentando
significativamente la carga del dispositivo. Del mismo modo, tras viajar por unos
nodos, la calidad del vídeo queda limitado por la calidad que puede soportar el
dispositivo menos potente de la cadena, lo que prácticamente garantiza una bajada
grande de calidad en cada uso.

Por las razones previamente mencionadas, se decidió utilizar libstreaming debido
a la popularidad del protocolo RTSP y las funcionalidades que proporciona esta
biblioteca de software libre.

4.2. Tecnologías elegidas para este proyecto

4.2.1. Android Studio

Android Studio es el entorno de desarrollo oficial para proyectos Android y es
el framework de desarrollo principal del proyecto. Una de sus características más
destacadas es su capacidad para permitir la depuración simultánea entre diferentes
dispositivos, ya sea mediante la conexión por cable o inalámbrico. Esta característica
ha permitido facilitar la comprensión sobre el flujo de las llamadas a nivel de código,

25



Elección de tecnologías

al igual que la tarea de localizar los errores y problemas que han ido surgiendo en
la aplicación a medida que se desarrollaba el proyecto.

4.2.2. Guardian Project: ProofMode

Según se cita en la página de ProofMode [51]:

«Turn your photos and videos into secure, signed visual evidence.»

«ProofMode is a system that enables authentication and verification of multi-
media content...»

Esta herramienta permite asociar una serie de datos a la captura de una imagen o
video con tal de que estos puedan usarse como pruebas en un juicio. Para ello, extrae
información capturada por los sensores del dispositivo, tales como la geolocalización
o el ID de este, y los guarda en un archivo. Por último, para proteger su integridad y
asegurar su autenticidad, se firma con la clave PGP privada asociada al dispositivo.

Las funcionalidades que ofrece este proyecto de código abierto, presentada de for-
ma amigable para los desarrolladores en forma de una librería, resulta esencial para
cumplir los objetivos de este proyecto. Los datos que se recogen son de suma impor-
tancia para poder demostrar la veracidad de unas pruebas con tal de que puedan
usarse en un juicio para denunciar y exponer crímenes en el escenario Witness.

4.2.3. Trello

Trello [53] [54] es una herramienta en línea que permite gestionar proyectos y ta-
reas mediante la creación de tableros, listas y tarjetas, siguiendo la metodología ágil
Kanban. Proporciona una serie de características y herramientas integradas para
mejorar la colaboración del equipo, como comentarios, etiquetas de color y notifica-
ciones, y se integra con una variedad de herramientas de terceros para aumentar la
eficiencia del equipo.

En este caso, se ha usado como una herramienta de gestión de tareas. En las
reuniones se establecen los problemas nuevos y se revisan los completados. Poste-
riormente, se dividen estos problemas en tareas, las cuales quedarán representadas
en las columnas o fases de desarrollo.

4.2.4. Dagger

Citando un extracto del github de Dagger [55]:

«Dagger is a compile-time framework for dependency injection. It uses no
reflection or runtime bytecode generation, does all its analysis at compile-time,
and generates plain Java source code.»

Dagger [56] es un framework de inyección de dependencias [57], o DI por sus
iniciales en inglés, desarrollado por Google y basado en el uso de anotaciones y

26



Elección de tecnologías

generación de código en tiempo de compilación, lo que garantiza la detección de
errores relacionados con DI sean detectados antes de la ejecución.

Utiliza anotaciones para marcar las clases que se deben inyectar y define módu-
los para configurar las dependencias y sus proveedores. Además, permite establecer
ámbitos de inyección para controlar la vida útil de los objetos inyectados. Propor-
cionando así una forma eficiente y robusta de gestionar las dependencias y mejorar
la modularidad y la mantenibilidad del código.

GitHub [58] [59] es una plataforma online creada en 2008, utilizada para alojar
y compartir código fuente de proyectos de software. Esta herramienta se basa en el
sistema de control de versiones Git, que permite a los desarrolladores mantener un
historial completo de los cambios realizados en el código. Además, las ramas per-
miten la experimentación y la exploración de nuevas ideas sin afectar la estabilidad
del proyecto principal.

El desarrollo de este proyecto, que es una bifurcación (fork) del proyecto de
20/21, se llevó a cabo en GitHub utilizando el sistema de control de versiones Git y
ramas para la gestión y desarrollo del código fuente.

4.2.5. LaTeX y Overleaf

Para la maquetación de este proyecto se ha empleado Overleaf [60], una he-
rramienta de maquetación basada en LaTeX [61], un sistema de preparación de
documentos ampliamente utilizado en la escritura académica, científica y técnica.
A diferencia de los procesadores de texto tradicionales, LaTeX utiliza comandos
de marcado para estructurar el contenido del documento y darle formato, lo que
permite crear documentos bien estructurados y estilizados de manera consistente.

27



5. Especificación

5.1. Requisitos

Este proyecto se centra en dos ideas principales. En primer lugar, se busca se-
parar el funcionamiento de WFA (Wi-Fi Aware) de RTSP (Real-Time Streaming
Protocol), de manera que estas dos tecnologías no dependan estrechamente una de
la otra para su funcionamiento. Para lograr este objetivo, se requiere aislar RTSP de
los componentes de WFA, permitiendo que operen de forma independiente a nivel
de código.

En segundo lugar, se busca incorporar metadatos a la transmisión del stream, lo
que permitirá su uso como pruebas para demostrar su autenticidad en un juicio o
para obtener la geolocalización del emisor en caso de verse involucrado en un desastre
natural. A lo largo del desarrollo del proyecto, este último objetivo ha evolucionado
para convertirse en la transmisión de pruebas que puedan demostrar la autenticidad
e integridad de los datos, con el propósito de utilizarlos en un juicio en el escenario
Witness.

Con estas dos ideas principales, el proyecto busca lograr la independencia entre
WFA y RTSP, permitiendo un funcionamiento más eficiente y flexible de estas tec-
nologías. Además, la incorporación de pruebas en la transmisión del stream brinda
la capacidad de validar la autenticidad de los datos y utilizarlos como pruebas sóli-
das en situaciones legales (Witness) o de emergencia (Humanitarian), dándole más
importancia al primer caso debido a la sensibilidad de los datos transmitidos.

Siguiendo la metodología ágil basada en historias de usuario empleada por los
alumnos de 2020/21, se definen los siguientes requisitos:

Siguiendo la metodología ágil basada en historias de usuario empleada por los
alumnos de 2020/21, se definen los siguientes requisitos:

“Funcionamiento en ausencia de WiFi Aware”:
Como usuario, quiero poder usar la aplicación aun si mi dispositivo no dispone
del hardware necesario para ejecutar WFA.
Como usuario, dispondré de una lista de IPs de los destinatarios deseados de
los streams que salen de mi dispositivo.

“Pruebas en un juicio”:
Como usuario, quiero que mi stream pueda usarse como prueba en un juicio.
Como usuario, quiero que estas pruebas estén protegidas de modificaciones
externas para asegurar su integridad y fiabilidad.

28



Especificación

5.1.1. Pruebas seguras: Autenticidad e integridad

La integridad y autenticidad de las pruebas son fundamentales para garantizar
la confiabilidad y la credibilidad de cualquier evidencia que se utilice en un juicio.
En el caso de los streams, estos se utilizan para demostrar la ocurrencia de un hecho
o una acción en particular. Sin embargo, si no se puede garantizar su integridad y
autenticidad, es muy probable que la validez de la evidencia sea cuestionada y, por
lo tanto, su utilidad en el juicio se vea comprometida.

Por lo tanto, es imprescindible que se tomen medidas para asegurar que la eviden-
cia de los streams sea íntegra y auténtica. Esto implica recopilar información sobre
el dispositivo origen, garantizar que los datos recopilados no hayan sido alterados o
manipulados de ninguna manera, y que la fuente de los datos pueda ser verificada.
Solo de esta manera se puede confiar en que los streams se puedan utilizar como
evidencia en un juicio.

En resumen, la integridad y autenticidad de las pruebas son fundamentales para
garantizar la validez y la credibilidad de la evidencia presentada en un juicio, y es
especialmente importante en el caso de los streams ya que, por su naturaleza digital,
son más propensos a la manipulación y la alteración. En el siguiente apartado se ex-
plicará cómo se ha abordado este problema, junto con los otros objetivos planteados
en este TFG.

29



6. Implementación

6.1. Investigación inicial

Antes de comenzar la implementación de este proyecto, se llevó a cabo una inves-
tigación inicial sobre las tecnologías involucradas. Los alumnos de años anteriores
realizaron este estudio para comprender y familiarizarse con las tecnologías nece-
sarias para el desarrollo del proyecto. Sin embargo, es importante tener en cuenta
que esta investigación se centra más en cómo se han utilizado estas tecnologías en
el proyecto en lugar de proporcionar una descripción detallada de las tecnologías en
sí.

6.1.1. Android Studio

Al inicio del proyecto, se enfrentó al desafío de trabajar con el framework Andro-
id Studio sin experiencia previa. Fue necesario dedicar tiempo a investigar sobre la
herramienta y comprender su funcionamiento. A través de este proceso de aprendi-
zaje, se adquirieron las habilidades necesarias para trabajar de manera efectiva con
el framework y llevar a cabo el proyecto. Más detalles en la sección A.1.1.

6.1.2. Wi-Fi Aware

Se pueden distinguir 2 modos según quién tiene el papel activo en el descubri-
miento:

Subscriber activo - Publisher pasivo: El subscriber pregunta regularmente
si hay algún publisher en su rango que ofrezca el servicio que busca. Figura
6.1a.

Publisher activo - Subscriber pasivo: El publisher publica regularmente
los servicios que ofrece, esperando que algún subscriber dentro de su rango que
busque ese servicio le conteste. Figura 6.1b.

30



Implementación

(a) Subscriber activo con Publisher pasivo

(b) Publisher activo con Subscriber pasivo

Figura 6.1: Modos de funcionamiento de WiFi Aware

6.1.3. Libstreaming

6.1.3.1. Estado inicial de libstreaming

La librería libstreaming proporciona la implementación de un cliente RTSP con
la modalidad publicar y un servidor RTSP con la modalidad reproducir. No obs-

31



Implementación

tante, es importante tener en cuenta que estas funciones se aplican únicamente a
los streams generados por el mismo dispositivo. En otras palabras, el nodo cliente
tiene la capacidad de transmitir un stream generado por la cámara y el micrófono
del dispositivo al servidor. Por otro lado, el nodo servidor solo puede proporcionar
al cliente un stream generado por el propio dispositivo.

Es importante destacar que el cliente y el servidor proporcionados por la biblio-
teca libstreaming no son compatibles entre sí y no pueden trabajar conjuntamente.
Esto significa que no es posible utilizar el cliente y el servidor de libstreaming en la
misma implementación. Esta librería facilita, por un lado, la transmisión de streams
desde un dispositivo cliente hacia un servidor RTSP compatible, como Wowza Me-
dia Server, o por otro lado, un servidor RTSP para recibir y atender solicitudes de
streams provenientes de clientes.

6.1.3.2. Cambios realizados por los alumnos de 2018/19

En este proyecto, uno de los objetivos principales fue la adaptación de libstrea-
ming para lograr la interoperabilidad entre el cliente y el servidor RTSP que ofrece
la librería libstreaming. Para que ambos puedan trabajar conjuntamente, por una
parte el servidor RTSP debía ser capaz de recibir la retransmisión de otro disposi-
tivo y por otra, reenviarla como si se tratase de un repetidor. Para solventar estos
problemas, implementaron la modalidad de publicación en el servidor y modificaron
la modalidad de reproducir respectivamente.

Incorporaron la capacidad de visualizar las transmisiones utilizando la biblioteca
libVLC. Mediante la obtención de la URI correspondiente a la transmisión RTSP
deseada dentro del servidor RTSP, se utilizó el cliente RTSP de libVLC para solicitar
y presentar dicha transmisión en la pantalla.

En este sentido, es importante destacar que se logró llevar a cabo el primer salto,
es decir, el paso de datos de un nodo de la red a otro, mediante la modalidad publicar,
lo cual permitió transmitir el stream del cliente al servidor. Además, se implementó
un segundo salto mediante la modalidad reproducir, que permitió visualizar el stream
solicitado al servidor. Sin embargo, no llegaron a adaptar la modalidad reproducir
del servidor libstreaming para streams con origen en el mismo dispositivo, y por
ende, se quedó inutilizada. Más adelante, los alumnos de 20/21 lo recuperarán y
adaptarán en su proyecto.

En su proyecto, implementaron un par de Selector-Worker para gestionar un
aspecto de la comunicación y retransmisión del stream, como se ilustra en la la
Tabla 6.1 y Figura 6.2.

32



Implementación

ClientSelector
ClientWorker Establece conexión con el ip y puerto indicado y procesa

los datos recibidos, pero no reenvía.
ServerSelector
ServerWorker Escucha y acepta peticiones de conexión y procesa los

datos recibidos y reenviarlos.
RTSPServerSelector
RTSPServerWorker

Establecer las conexiones y procesar las peticiones
RTSP.

UDPServerSelector
EchoWorker Retransmisión de los paquetes RTP que se están reci-

biendo en los puertos UDP.

Tabla 6.1: El par Worker-Selector y sus funciones

Figura 6.2: Diagrama de clases. Relación Worker-Selector

6.1.3.3. Cambios realizados por los alumnos de 2020/21

Los alumnos del curso 2020/2021 siguieron con la utilización de WFA, introdu-
cido por sus predecesores del curso 19/20 [18], debido a las limitaciones que ofrecían
WiFi Direct. Para ello, tuvieron que realizar ajustes en la biblioteca libstreaming
para adaptarla a IPv6 además de IPv4, lo que permitió su uso en conjunto con
WFA. Ver Figura 6.3. Además, lograron extender la funcionalidad de libstreaming
para implementar el multihopping. Figura 6.4.

Por otro lado, introdujeron la capacidad de recibir flujos de múltiples emisores
y reenviarlos a múltiples receptores. Es decir, adaptaron el servidor para que sea
capaz de recibir y gestionar más de 1 stream por cliente, y por su lado, que el cliente
sea capaz de enviar más de un stream al servidor y reaccione a los cambios en su
disponibilidad. Asimismo, recuperaron la modalidad reproducir en el servidor RTSP
para streams con origen en el mismo dispositivo.

Como se describe en [ [4], 7.1.4.2], también solucionaron el problema de los bucles
en la transmisión de los streams comprobando si una petición RECORD ya había

33



Implementación

sido registrada por otro cliente RTSP.

(a) Cambios en RtspClient

(b) Cambios en RTSPServerWorker

Figura 6.3: Diagrama de clases con los cambios realizados por los alumnos de
20/21. Verde representa adición y rojo borrado

34



Implementación

Figura 6.4: Diagrama del multihopping creado por los alumnos de 2020/21

6.2. Proyecto de 2020/21

A continuación se describen los puntos más importantes del proyecto de los
alumnos de 2020/21 [4]:

Adaptar libstreaming a IPv6 para que pudiera funcionar sobre WFA.

Adaptar libstreaming para que pudiera retransmitir un stream recibido. Para
ello, debían adaptar la modalidad publish en el cliente RTSP mediante la
implementación de la clase StreamingRecord y listeners correspondientes.

Se realizaron ajustes en el cliente RTSP para que pudiera enviar más de un
stream al servidor. Además, se adaptó el servidor RTSP para que pudiera
recibir y gestionar múltiples streams provenientes de un mismo cliente.

Se implementó la clase CameraController para permitir la transmisión a más
de un receptor. Esto permitió que los streams pudieran ser enviados y recibidos
por varios dispositivos de forma simultánea.

Se estableció una red privada WFA para cada par de dispositivos involucrados
en la transmisión de streams. Esto permitió la comunicación directa entre los
dispositivos sin necesidad de una infraestructura de red externa.

Para la identificación de los streams en la MANET (red de área metropolitana
móvil), se utilizó el estándar UUIDv4. Este identificador único se incluyó en
las URI de RTSP para garantizar la correcta identificación y gestión de los
streams.

35



Implementación

6.2.1. Cuestiones encontradas

Fuerte dependencia entre WFA y RTSP: El código pertinente a WFA
está fuertemente integrada a RTSP, dificultando la introducción de nuevas
tecnologías para sustituir las actuales. Este es uno de los temas centrales a
desarrollar en este proyecto.

Limitaciones del stream como evidencia en juicios: El stream no está
acompañado de metadatos o pruebas que demuestren de manera inequívoca
su origen y la temporalidad precisa de su captura en un lugar específico. Esta
falta de información puede plantear dudas sobre la autenticidad y la veracidad
del vídeo en el contexto de un testimonio en el escenario Witness. Esta cuestión
se desarrollará en la Sección 6.4 y 6.5.

Bug de visualización de streams : Todos los elementos de la lista de streams
que el dispositivo recibe llevan a la misma retransmisión sin importar cuál elija.
Detallado y solucionado en en Apéndice B.1.

En las siguientes secciones se detallará cómo se han solventado estas cuestiones.

6.3. Separación de Wi-Fi Aware y RTSP

6.3.1. Localización de las partes afectada

A continuación se analizará el proyecto de los alumnos del año 20/21 para loca-
lizar las clases donde mezcla la funcionalidad de RTSP con WiFi Aware.

El cliente RTSP, RtspClient, incluía funcionalidades para gestionar una cone-
xión WFA, además de las ya mencionadas. Estas funcionalidades abarcan desde
solicitar una sesión de WFA, publicar y suscribirse a servicios, hasta asociar la aper-
tura de sockets con la red WFA utilizando la instancia Network devuelta por el
callback onAvailable(). A continuación, se enumeran las instancias responsables de
estas funcionalidades:

ConnectivityManager: Encargado de solicitar la red WFA mediante request-
Network(), utilizando NetworkRequest y WifiAwareNetworkCallback.

Network: Almacena la instancia de red devuelta por el callback onAvailable(),
utilizada para establecer la apertura de sockets en la red WFA en lugar de la
red predeterminada.

NetworkCapabilities: Proporciona información sobre la red activa.

mTotalNetworkRequests : Lleva un recuento de las peticiones realizadas a la
API de WFA. Si la petición ConectionManager.requestNetwork() falla, au-
menta el contador y se reintenta hasta un límite de intentos.

36



Implementación

Con todo ello, se necesita crear una clase que se encargue de gestionar el esta-
blecimiento de las conexiones de la red de WFA: WiFiAwareNetwork.

Por otro lado, RTSPServerSelector es una clase que se encarga de la lectura y
escritura de los datos de cada cliente. Este poseía 2 mapas:

Map<PeerHandle, Connection>: Para localizar los parámetros de la conexión,
almacenados en la clase Connection, asociados a un Peerhandle, que repre-
senta el identificador del par de WFA asociado a la conexión.

Map<ServerSocketChannel, Connection>: Localiza los parámetros de la co-
nexión asociados a un ServerSocketChannel.

Tanto el PeerHandle como la clase interna Connection están estrechamente re-
lacionados con los parámetros y la gestión de WFA. El PeerHandle se utiliza como
identificador para asociar los parámetros de conexión específicos de WFA. La clase
interna Connection se encarga de almacenar y gestionar estos parámetros para cada
conexión. Además, la clase interna WifiAwareNetworkCallback se utiliza para reco-
ger los callbacks al solicitar la red WFA a través de la función requestNetwork(). Esta
clase permite manejar y responder a los eventos relacionados con la disponibilidad
y el estado de la red WFA.

Se necesitaría una clase para guardar y gestionar las conexiones de WFA. Es
decir, las conexiones establecidas y los parámetros asociados: RTSPServerWFAModel.

En la clase RTSPServerWorker, a la hora de enviar la petición ANNOUNCE, la
función usa objeto Network para establecer la red de la clase ReceiveSession. Este
objeto lo obtiene llamando a la función getChannelNetwork() del ServerSelector.
Del mismo modo, en la clase UDPServerSelector, concretamente en la función
initiateConnection(), para asociar la creación de nuevos sockets a la red de WFA,
se usa la función bindProcessToNetwork(), la cual recibe como argumento un objeto
Network.

6.3.2. Implementación de la separación

Después de identificar las áreas afectadas por la separación y las funcionalidades
que debían ser aisladas, se creó la clase WifiAwareNetwork. Esta clase se encarga de
manejar todas las funcionalidades relacionadas con la red de WiFi Aware y su ciclo
de vida. En otras palabras, se encarga de realizar las siguientes tareas:

Solicitar una sesión de WiFi Aware: Se encarga de iniciar una sesión de
WFA para establecer la comunicación entre dispositivos.

Publicar y suscribirse a un servicio: Permite publicar servicios y suscri-
birse a ellos en la red WFA, lo que facilita la comunicación y el descubrimiento
de dispositivos.

Cerrar la sesión de WiFi Aware: Gestiona el cierre adecuado de la sesión
de WiFi Aware cuando ya no es necesaria.

37



Implementación

Además, WifiAwareNetwork mantiene una lista de conexiones establecidas uti-
lizando la clase RTSPServerWFAModel, responsable de administrar múltiples mapas
relacionados con las conexiones establecidas a través de WFA. Su función princi-
pal es permitir que WifiAwareNetwork agregue o elimine conexiones de estas listas,
verificar si una conexión ya está establecida y proporcionar toda la información
relevante de una conexión utilizando su PeerHandle o el ServerSocketChannel
correspondiente.

Por otro lado, WifiAwareViewModel, creada por los alumnos de 20/21, es una
clase utilizada para actualizar la interfaz de usuario (UI) con el estado de la red
WFA y manejar las conexiones entre parejas de dispositivos. Sin embargo, en la
versión actual, su función ha pasado a ser la de un intermediario, ya que la gestión
de conexiones se ha trasladado a la clase WifiAwareNetwork.

Figura 6.5: Diagrama simplificado de los roles de WifiAwareNetwork y
RTSPServerWFAModel

6.3.3. Realización de pruebas: Conexión directa mediante IP

Análogo a las clases creadas para gestionar la red de WFA, para comprobar el
correcto funcionamiento de la aplicación y la adecuada separación de capas, se ha
creado la clase DefaultNetwork. Esta clase gestionará una red rudimentaria para
conectar dispositivos mediante socket, omitiendo el proceso de descubrimiento de
vecinos. Del mismo modo, la clase RTSPServerModel llevará los mapas para guardar
las conexiones establecidas.

Para comprobar el correcto funcionamiento de la aplicación y verificar la ade-
cuada separación de la misma, se ha implementado la clase DefaultViewModel.
Esta clase crea una instancia de DefaultNetwork y la para inicializar las instancias
de cliente y servidor y establecer la conexión con los dispositivos que recibirán los
streams del dispositivo, ya sean estos redirigidos o generados por el mismo disposi-
tivo.

38



Implementación

Es necesario responder a la pregunta de cómo localizar los dispositivos a los que
se deberá conectar. En una primera instancia, la aplicación lee una lista de IPs de un
archivo de texto interno en la aplicación. Posteriormente, se hizo esta funcionalidad
más accesible permitiendo al usuario establecer dichas IPs. Esta funcionalidad se
implementó añadiendo un campo de texto EditTextPreference en el xml usado
para la pantalla de configuración de preferencias del usuario, SettingFragment,
creado por los alumnos de 20/21.

Para reemplazar la funcionalidad de descubrimiento de vecinos, en este caso, se
reintentará conectarse a las direcciones que habían fallado en establecerse cada n
segundos. Mediante el uso de un handler, se establece un offset o retraso para su
ejecución. Cuando termina de ejecutarse, vuelve a llamarse a sí mismo, logrando
así un servicio en segundo plano que se ejecuta de forma regular. DefaultNetwork
comprobará el estado de la conexión con las IPs de la lista de destinos. Si la conexión
no se ha establecido, volverá a intentar establecerla.

Se utiliza una superclase BasicViewModel para encapsular atributos y métodos
comunes a DefaultViewModel y WifiAwareViewModel. Esto permite un mayor reuso
de código y una mejor organización de las clases, lo que facilita la mantenibilidad y
escalabilidad del código. Además, si en un futuro se quisiera agregar otra subclase,
sería más fácil integrarla en el diseño al existir una superclase común.

Análogo al funcionamiento de la clase WifiAwareViewModel, al iniciar la apli-
cación, DefaultViewModel iniciará el servidor RTSP, permitiendo enviar streams
locales a otros dispositivos mediante la modalidad publish o reenviar streams ori-
ginados por otros dispositivos. Además, DefaultViewModel intentará establecer la
conexión con los clientes RTSP mediante las IPs de los dispositivos destino, las
cuales se leerán de un fichero local.

6.4. Transmisión de metadatos

6.4.1. Integridad y autenticidad en la transmisión de meta-
datos

Debido a la facilidad en que estos datos pueden ser manipulados, se deben im-
plementar métodos y protocolos para asegurar su integridad y autenticidad en la
cadena de custodia.

6.4.1.1. Hash

Una primera aproximación sería la utilización de un hash para proteger la in-
tegridad de los datos. El hash consiste en una cadena de caracteres que identifican
inequívocamente un conjunto de datos. Existen varios algoritmos de generación de
hash como MD5 o la familia SHA (SHA-1, SHA-2 y SHA-3), cada uno de ellos con
una cantidad de bits diferente para representar el hash. Cabe destacar que en tér-
minos probabilidad de colisión de hash, es decir, que dos datos de entrada diferentes

39



Implementación

den como resultado el mismo hash, el algoritmo CRC-32 lidera la lista, seguido de
MD5 y SHA1 [62].

Sin embargo, no puede autenticar su origen. Es decir, si se produce un ataque
de intermediario, el atacante puede modificar los metadatos, generar un nuevo hash
a partir de estos y sustituirlo por el ya existente. El siguiente nodo en la cadena de
custodia no podrá percatarse del cambio, ya que verá que el hash coincide con el de
los metadatos.

6.4.1.2. Firma electrónica

Así que, para garantizar la autenticidad e integridad de los metadatos, es nece-
sario emplear un método más sólido: La firma electrónica.

Al firmar electrónicamente, se proporciona información adicional sobre el autor
de la firma, la fecha y hora, y establecer una cadena de confianza que permite verificar
la autenticidad de los datos. De esta forma, cada nodo de la cadena de custodia
únicamente añadirá su firma electrónica a las pruebas una vez haya comprobado
la autenticidad de la firma anterior. De esta manera, se establece una cadena de
confianza sólida que garantiza la integridad y autenticidad de los datos, reduciendo
así el riesgo de manipulación o falsificación de los metadatos.

No obstante, en el contexto de esta aplicación, sobre todo en el escenario Witness,
es de vital importancia la protección del anonimato de los nodos involucrados en la
transmisión del stream. Por ende, se debe plantear cuidadosamente la forma de usar
esta herramienta.

6.4.2. Desarrollo

El primer paso fue comprobar qué metadatos estaban asociados al stream reci-
bido. Tras guardar el vídeo en el dispositivo, se empleó la herramienta analizadora
de metadatos, Exiftool, para extraerlos. Sin embargo, se observó que no había nin-
gún tipo de metadato vinculado al archivo. Es posible que esto se deba a que el
contenido transmitido se trate de un stream en directo, lo que conlleva la falta de
información sobre ciertos parámetros del contenido multimedia, como la duración,
intercambiados en el momento de establecer la conexión RTSP.

Una primera aproximación para incluir metadatos en la transmisión fue incor-
porarlos en el propio contenido multimedia. Para ello, se han investigado algunas de
las herramientas más utilizadas para el tratamiento de metadatos.

ExifInterface [63]: Una clase de Android para leer y escribir etiquetas EXIF
en archivos de imagen.

MediaMetadataEditor [64]: Una clase obsoleta de Android para editar me-
tadatos en archivos multimedia. Desde API 23 se recomienda usar MediaMe-
tadata y MediaSession.

40



Implementación

MediaMetadata [65]: Una clase de Android que almacena y proporciona
metadatos asociados a medios, como archivos de audio y vídeo. Es común
utilizar esta clase en conjunción con MediaSession y MediaController para
brindar una experiencia de reproducción de medios más completa.

MediaSession [66]: Una clase de Android que proporciona una interfaz para
controlar la reproducción de audio o vídeo y manejar eventos relacionados,
como reproducción, pausa, avance rápido y control de volumen.

MediaMetadataRetriever [67]: Es una clase en Android para obtener me-
tadatos de archivos de audio y vídeo. Proporciona métodos para extraer infor-
mación relevante de un archivo multimedia, como el título, artista, duración,
resolución, entre otros.
También permite extraer fotogramas individuales de un vídeo, lo que puede
ser útil para crear miniaturas. Los alumnos de 20/21 usaron esta clase para
crear una preview de los streams guardados en el dispositivo y mostrarlas en
la galería.

Además de otras herramientas externas como exiftools [49] o mp4parser [68].

Sin embargo, las herramientas para editar metadatos en contenido multimedia
encontradas solo trabajaban sobre un archivo ya guardado en el dispositivo y no
sobre una transmisión en directo, por lo que esta idea fue descartada rápidamente.

Otra aproximación sería la inclusión de metadatos en los propios paquetes RTP
de la transmisión. Para comprobar la viabilidad de esta idea, se ha encontrado que la
empresa Parrot [69] usa esta aproximación para los metadatos de sus drones. Según
se cita en su página web [70]:

«Frame metadata, also called timed metadata, are data that vary across time,
and are synchronized with the video frames. The purpose is to allow an easy
access to image and flight data for users, by multiplexing the timed data with
the recorded video in MP4 files and RTP streams.»

Sin embargo, debido a las limitaciones de tiempo y recursos en el contexto de
este TFG, no se ha investigado en profundidad la idoneidad de esta solución, ya que
se consideró poco realista implementarla en el alcance del proyecto.

Por otro lado, para lograr la asociación de los metadatos con el contenido mul-
timedia en el mismo contexto, se utilizó el concepto de “asociar” los metadatos al
contenido mediante el envío conjunto. Para ello, se implementó una aproximación
utilizando atributos de control personalizados (“custom control attributes”) que se
pueden incluir en la descripción de sesión RTSP. Estos atributos de control per-
sonalizados permiten incluir los metadatos dentro del contexto de la sesión RTSP,
de manera que se envían y se reciben junto con el contenido multimedia. De esta
forma, se logra una asociación directa entre los metadatos y el contenido, asegu-
rando que sean recibidos y utilizados en el mismo contexto. Para ello, se añadió un
campo String en la clase SessionBuilder para que lo incluya como dato de sesión.

41



Implementación

El objeto Session que construye SessionBuilder se usará a la hora de enviar el
mensaje ANNOUNCE de cliente a servidor para describir el objeto multimedia que
desea transmitir. Esta descripción se obtiene invocando el método getSessionDes-
cription() de la clase Session, el cual construye un String en un formato específico:
una cabecera para localizar el dato en el receptor, seguido del dato. Es en este punto
donde se incluye el String asociado al metadato usando una cabecera personalizada.

String metadata = "a=my-custom-metadata:" + mGpsMetadata ...;

Cuando el mensaje llegue al receptor, la clase RTSPServerWorker empezará a
procesar su contenido. Para que sea capaz de reconocer la nueva cabecera y así
extraer el dato asociado, se ha empleado el reconocimiento de patrones mediante la
clase Pattern.

Pattern.compile("a=my-custom-metadata:(.+)", ...);

El receptor ya ha conseguido el metadato. Ahora bien, se debe asociar al conteni-
do multimedia para darle contexto. Ya que no se ha conseguido asignar el metadato
en el origen del stream, se intentará asignar una vez un nodo decida guardar la trans-
misión, añadiéndolo como metadato del vídeo. Sin embargo, este último paso no se
ha acabado de implementar debido a que no se pudo localizar el stream recién guar-
dado para asociar los metadatos al archivo mediante ninguna de las herramientas
utilizadas para su manipulación mencionadas anteriormente.

6.5. Generación y transmisión de pruebas mediante
ProofMode

Para que los streams puedan ser utilizados como evidencia en un juicio, es ne-
cesario garantizar tanto su integridad como su autenticidad. Para lograr esto, se
requiere recopilar información sobre el dispositivo que genera el stream, también
conocido como el dispositivo origen. En este proceso, la biblioteca de ProofMode
cobra gran importancia, ya que proporciona una serie de funciones que permiten
una adquisición de estos datos identificativos y contextuales de manera eficiente,
además de un sistema de firma digital mediante clave asimétrica y un sistema para
comprobar la integridad y autenticidad de los datos firmados.

Aunque no es estrictamente necesario, se recomienda encarecidamente utilizar la
versión más actualizada de la biblioteca ProofMode para garantizar la eficacia del
proceso de adquisición de datos. Sin embargo, en algunos casos como en el proyecto
en cuestión, no ha sido posible utilizar la versión más actualizada debido a que
requiere un SDK superior a 29. Una actualización podría conllevar a la inutilización
de funciones que se están usando actualmente, ya sea en el propio código del proyecto

42



Implementación

o en las bibliotecas externas empleadas. En consecuencia, se empleó la versión más
reciente que cumple con los requerimientos del proyecto.

Entre los datos relevantes que se pueden obtener del dispositivo origen se encuen-
tran la geolocalización en el momento en que se inicia la transmisión, el identificador
del dispositivo o su dirección MAC. Esta información se guarda en un archivo y se
firma con la clave privada del usuario para garantizar su integridad y autenticidad.
Sin embargo, la API que proporciona para generar estos datos requiere un archivo
existente como dato de entrada. Es decir, el archivo al cual estas pruebas estarán
relacionadas, resultando en la misma problemática encontrada en la Sección 6.4.
Para tratar de solventar este desafío, se ha procedido a generar dinámicamente, al
momento de iniciar la grabación del stream, un archivo que contiene la geolocaliza-
ción del dispositivo. Dicho archivo es el que se le proporcionará a la API para que
esta pueda funcionar correctamente y generar una carpeta que contiene todos los
datos captados y firmados.

Una vez que se obtiene la carpeta con toda la información necesaria, se procede
a transmitirla a otro dispositivo. Para ello, se ha basado en la investigación sobre
la transmisión de metadatos para concluir que estos datos se pueden transmitir
como parte de la descripción del stream en el mensaje ANNOUNCE, descrito en la
Sección 6.4.2. Ya que solo es posible incluir Strings en la descripción de la sesión,
era necesario transformar la carpeta a otro formato. Para ello, se ha convertido el
fichero en un archivo en formato zip con el fin de reducir la cantidad de ficheros a
tratar al mínimo posible y además reducir el tamaño del archivo, repercutiendo en
una menor carga y tamaño del mensaje ANNOUNCE. Finalmente, se ha cifrado el
archivo zip usando Base64 para obtener un String a partir de la secuencia de bytes
que representa el archivo, logrando así solucionar la cuestión de cómo transmitir una
carpeta mediante la descripción de la sesión.

Acompañando estas pruebas, se ha incluido también su SHA256, que se usa-
rá posteriormente como nombre del archivo si un nodo receptor decide guardar el
stream en su dispositivo.

Una vez un nodo recibe el mensaje ANNOUNCE, la clase RTSPServerWorker
procesará el mensaje y guardará una instancia de las pruebas en forma de un array
de bytes junto con su SHA256. Si el usuario decide guardar el stream, se realizará
el proceso contrario para recuperar el archivo zip y se guardará en el dispositivo
usando como nombre el SHA256 recibido.

43



Implementación

6.6. Inyección de dependencias para la configura-
ción dinámica de la red

6.6.1. Patrón de diseño: Inyección de dependencias

El patrón de diseño conocido como inyección de dependencias se refiere a una
situación donde existen dependencias entre los componentes de un sistema. Es decir,
hay código que requiere de la funcionalidad de otro código para llevar a cabo su tarea.
Por lo general, se trata de código de nivel superior que depende de código de nivel
inferior.

Con la inyección de dependencias, el entorno del código dependiente provee el
código del cual depende. Si el lenguaje permite la vinculación dinámica, incluso
se puede dejar la elección del código del cual depende en tiempo de ejecución por
parte del entorno. En el contexto de la programación orientada a objetos (POO), el
entorno proporciona los objetos de los cuales el código dependiente necesita.

Cuando un lenguaje permite el tipado mediante interfaces, se puede obtener un
nivel adicional de flexibilidad al aplicar la inyección de dependencias. Una interfaz
define un contrato o conjunto de métodos que una clase debe implementar. Al de-
pender de interfaces en lugar de implementaciones concretas, el código dependiente
no está acoplado directamente a una implementación específica, lo que facilita la
sustitución de una implementación por otra que cumpla con la misma interfaz.

Esta flexibilidad es especialmente valiosa en situaciones donde se necesite cam-
biar o ampliar las dependencias en el futuro. Si se depende de interfaces, se pueden
agregar nuevas implementaciones de esas interfaces sin afectar el código que utiliza
esas dependencias. En el caso típico de código de nivel superior que depende de códi-
go de nivel inferior, este uso de interfaces se conoce como “inversión de dependencia”,
siendo la “D” de los principios SOLID [71].

Cuando se trata de una dependencia entre código de nivel superior y código de
nivel inferior, la inyección de dependencias es una forma de lograr la separación de
código en diferentes niveles. En el caso de software organizado en capas, como el
software de redes, la inyección de dependencias permite una separación clara entre
el software perteneciente a diferentes capas de la torre de protocolos. Por lo general,
el software de la capa superior depende del software de la capa inferior.

En términos de implementación, existen dos enfoques principales para aplicar la
inyección de dependencias: el enfoque automático y el enfoque manual.

En la implementación automática, se utiliza un “dependency injection frame-
work” (marco de inyección de dependencias) que forma parte de un ”contenedor”.
Este contenedor es responsable de administrar el ciclo de vida de los objetos dentro
de él y proporcionar las dependencias necesarias al software dependiente. El fra-
mework puede realizar varias tareas, como instanciar atributos, llamar a métodos

44



Implementación

(también conocidos como “callbacks”) del software dependiente o enviar eventos que
requieran un listener.

Por lo general, el framework obtiene información sobre las dependencias requeri-
das por el software dependiente a partir de un archivo de configuración. Este archivo
de configuración contiene detalles sobre las dependencias y, en particular, sobre qué
implementación específica del código necesario debe iniciarse. De esta manera, el
framework puede resolver automáticamente las dependencias y proporcionar las ins-
tancias adecuadas al software dependiente en tiempo de ejecución.

En contraste, en la implementación manual, el entorno del software dependien-
te asume la responsabilidad de proporcionar los objetos que encapsulan el código
del cual depende. Estos objetos se pasan como parámetros a los constructores de
las clases o como argumentos de los métodos mutadores (“setters”) del software de-
pendiente. En este enfoque, es tarea del desarrollador identificar las dependencias
necesarias y proporcionar manualmente las instancias correctas al software depen-
diente.

En el caso de este TFG, el software dependiente es libstreaming y el softwa-
re/recursos del cual depende es WFA.

6.6.2. Desarrollo

Con el objetivo de mejorar la flexibilidad de la aplicación y permitir una mejor
adaptación a los dispositivos móviles actuales, así como fomentar el desacoplamien-
to de los componentes a nivel de código para facilitar el desarrollo futuro, se ha
utilizado el patrón de diseño de inyección de dependencias (DI). Para implementar
este patrón de diseño, se ha empleado el framework Dagger, descrito en la Sección
4.2.4, permitiendo así una gestión eficiente de las dependencias y una configuración
flexible de los componentes de la aplicación.

El fragmento principal de la aplicación, MainFragment, necesita una instancia de
la ViewModel de la red que la aplicación usará para inicializar, por un lado la interfaz
de usuario con los datos contextuales, y por otro, la red en sí. Se ha considerado
oportuno que la decisión del tipo de red a usar dependa de un fichero de configuración
para facilitar la tarea de configuración y posterior testeo del funcionamiento.

Al depender de un sistema de anotaciones para localizar las clases involucradas
en la inyección, se describen a continuación las anotaciones más relevantes:

@Module: Marca la clase que proporciona la dependencia.

@Provides: Marca el método del módulo que crea y retorna la dependencia.

@Component: Marca la clase que proporciona al módulo de los objetos que
necesita para crear la dependencia.

@Inject: Marca el objeto inyectable.

45



Implementación

Para empezar, se marca el objeto inyectable en MainFragment mediante @Inject
para indicar a Dagger cuál es la dependencia a tratar. En este caso, la ViewModel.
Para proporcionar a MainFragment dicha dependencia, se ha creado una nueva clase,
NetworkModule, marcado con @Module, que se encarga de leer el fichero de confi-
guración y crear la clase adecuada para ser inyectada. Después, se ha implemen-
tado la interfaz INetworkComponent, marcado con @Component, que se utilizará
para proporcionar al módulo los datos que éste necesita para crear las clases a in-
yectar. Concretamente, para crear las instancias de ViewModel, se utiliza la clase
ViewModelProvider [72], que requiere como argumento una instancia de la actividad
o fragmento que contendrá la ViewModel y al cual asociar su ciclo de vida.

Una vez implementado lo anterior, se compila el proyecto para que Dagger ge-
nere las clases necesarias y compruebe si hay errores en la implementación de la
inyección. Finalmente, en MainFragment se construye una instancia del componente
que inyectará a NetworkModule del objeto que necesita para crear la ViewModel y
a su vez, asignarse al atributo del fragmento marcado con @Inject.

Figura 6.6: Inyección de dependencias

6.7. Shared Secret Mode

Teniendo en cuenta los requisitos del escenario Witness1.1, se ha planteado el
desarrollo de un nuevo modo de funcionamiento para proteger la transmisión del
stream, dando el primer paso para ocultar la visibilidad del stream.

El funcionamiento de este modo, al menos de esta primera implementación, con-
siste en asociar el stream al SHA256 de una clave, la cual se transmitirá del mismo

46



Implementación

modo que las pruebas descritas en la Sección 6.4. Los nodos receptores comproba-
rán la coincidencia de la SHA256 recibida con la de su propia clave. Si coincide, se
mostrará el stream en la aplicación y si no, solo funcionará como un repetidor para
transmitir el stream a más dispositivos. En la Figura 6.7 se ve una representación
simplificada del proceso.

Figura 6.7: Modo Shared Secret mediante SHA de una contraseña

El objetivo final consiste en cifrar los paquetes RTP para protegerlos, restringien-
do su visibilidad a los dispositivos que poseen la clave para descifrarlos, y facilitando
la detección de modificaciones ocurridas durante la transmisión. Esto se puede lograr
utilizando una clave simétrica acordada externamente por ambos extremos de la co-
municación o mediante algoritmos de intercambio de clave como Diffie-Hellman [73].
Alternativamente, se puede emplear la clave pública del receptor cuando se utilizan
claves asimétricas. En la Figura 6.8 se ilustra un diagrama sobre la transmisión de
streams mediante el cifrado de paquetes con clave simétrica establecida mediante el
algoritmo Diffie Hellman. Figura 6.9.

El presente trabajo ha explorado la posibilidad del envío seguro de paquetes me-
diante esta primera aproximación y pretende dar el primer paso hacia la protección
de los paquetes enviados a través de una MANET.

47



Implementación

Figura 6.8: Modo Shared Secret mediante clave simétrica establecida mediante el
algoritmo Diffie-Hellman

Figura 6.9: Funcionamiento del algoritmo Diffie-Hellman. Obtenido de [73]

6.8. Accesibilidad

Por último, para mejorar la accesibilidad de la aplicación, se han recogido los
strings que se encuentran hardcodeados dentro del proyecto y se han trasladado al
archivo strings.xml para facilitar su gestión y modificación en el futuro. En este caso
particular, se ha introducido una versión traducida al español del archivo strings.xml,
creando una variante regional de strings.xml, nombrando esta variante en un formato
específico según indica la documentación [74].

48



7. Conclusiones y trabajo futuro

El ámbito de las MANET tiene una presencia e importancia notable en los dis-
positivos que usamos hoy en día. Desde auriculares Bluetooth hasta la realización
de pagos mediante la tecnología NFC, está claro que la comunicación inalámbrica
entre dispositivos móviles se ha vuelto esencial en nuestra vida cotidiana.

Este tipo de redes, gracias a su naturaleza descentralizada, puede escapar del
control de infraestructuras tradicionales y permitir una comunicación directa entre
dispositivos móviles (peer-to-peer). Esto ofrece numerosas ventajas en términos de
flexibilidad, adaptabilidad y capacidad de comunicación en entornos donde la in-
fraestructura de red convencional no está disponible o es limitada. Sin embargo,
también debe tenerse en cuenta algunas desventajas de las MANET:

Problemas de enrutamiento: Encontrar el nodo óptimo para construir la
ruta más rápida para alcanzar el destino.

Seguridad: Debido a la ausencia de una infraestructura de seguridad centra-
lizada, las MANET son más susceptibles a ataques como man-in-the-middle o
DoS.

Consumo de energía: Al asumir los dispositivos el rol del enrutador, conlleva
responsabilidades adicionales para cada nodo de la red.

7.1. Recapitulación y evaluación

Este proyecto se enfoca en proporcionar una ampliación y mejora a partir de los
resultados obtenidos en el TFG del año 2020/21 “Multistreaming de video y audio en
una red ad hoc de dispositivos móviles corrientes” [4]. En dicho TFG, se enfocaron
en la transmisión de contenido audiovisual sobre WiFi Aware (WFA), una red sin in-
fraestructura que permite a los usuarios establecer una comunicación punto a punto
(p2p) sin la necesidad de una estación base. El presente trabajo pretende flexibili-
zar la aplicación resultante del anteriormente mencionado proyecto, permitiéndole
funcionar aun si el dispositivo no dispone del hardware necesario para iniciar una
red WFA. Además, con el fin de que el contenido audiovisual documentado pueda
usarse en el futuro como pruebas para la denuncia de crímenes, se han dado los pri-
meros pasos para la inclusión de datos que demuestran la autenticidad e integridad
de este. Adicionalmente, añadir opciones de accesibilidad a la propia aplicación que
permitan que esta se adapte automáticamente al idioma del dispositivo.

Para el desarrollo de este proyecto se llevó a cabo una primera fase de inves-
tigación. No solo sobre WiFi Aware, una tecnología relativamente nueva y poco
documentada, sino también el entorno de desarrollo, Android Studio, del cual no se

49



Conclusiones y trabajo futuro

tenía experiencia previa, y todo el trayecto por el que ha pasado esta aplicación.
Desde su esbozo inicial por los alumnos de 2018/19 en su TFG “Device to Devi-
ce streaming en dispositivos móviles” [75], su retoque posterior por los alumnos de
2019/20 en su TFG “Crowdstreaming: transmisión de vídeo y audio por una red ad
hoc de teléfonos móviles” [18] y el perfilado por los alumnos de 2020/21 en su TFG
“Multistreaming de video y audio en una red ad hoc de dispositivos móviles corrien-
tes” [4]. Poniendo especial énfasis en este último TFG, ya que es el proyecto del cual
el presente trabajo parte. Todo ello, con el fin de entender el funcionamiento interno
de la aplicación a nivel de código, el uso y funcionamiento de las clases y el flujo de
información desde que inicia la aplicación hasta que esta finaliza. A continuación se
presentará una breve descripción de los proyectos anteriormente mencionados.

En cuanto al proyecto del año 18/19, fueron los pioneros que asentaron las bases
sobre las cuales se construirá la aplicación. Introdujeron el uso de la biblioteca
libstreaming para la transmisión de un stream, y la modificaron para que el cliente
y servidor que proporciona la biblioteca puedan cooperar entre sí. Como tecnología
para descubrir y conectar dispositivos, decidieron usar WiFi Direct. No obstante,
se encontraron con un obstáculo importante. Descubrieron que Google decidió no
implementar una característica opcional de WiFi Direct en Android, lo que habría
permitido que un nodo pertenezca a más de una red WiFi Direct. Como resultado, se
vieron limitados en cuanto al alcance de transmisión de información a un máximo de
dos hops (del nodo al group leader y del group leader a otro nodo de la misma red).
Introdujeron el concepto de “multi hop”, según se cita en su memoria, “donde los
dispositivos puedan ser nodos de transito(sic) del streaming” [ [75], 5.1.4] y lograron
la transmisión entre una pareja de dispositivos. Más adelante, los alumnos de 20/21
ampliarán esta funcionalidad para permitir su expansión a un rango más amplio.

Los alumnos del año 19/20 especificaron en los requisitos el uso de WiFi Aware
en lugar de WiFi Direct para superar dichas limitaciones. Sin embargo, debido a
la falta de documentación detallada sobre esta tecnología, sumado a la situación de
emergencia global y la tardanza a la hora de conseguir fondos para adquirir dispositi-
vos que podían iniciar una red WFA, tuvieron que prescindir de unas características
para centrarse en las que consideraron más realistas para el tiempo que tenían. Por
ende, al no poder solventar el problema de compatibilidad de libstreaming con IPv6,
la abandonaron a favor de utilizar el protocolo SCTP para la transmisión de vídeo y
audio. No obstante, al carecer de un protocolo de control, la calidad de la transmisión
cayó.

En cuanto a los alumnos del año 20/21, con la experiencia adquirida al analizar
los proyectos anteriores y con los dispositivos móviles a su disposición, retomaron el
uso de libstreaming para la retransmisión de flujo y, continuaron con el uso de WFA
siguiendo las indicaciones de su director de TFG. Con ello, debían realizar múltiples
cambios con tal de compatibilizar el funcionamiento de ambas tecnologías. Mejoraron
la calidad de transmisión, solucionaron el problema de los bucles planteado en el TFG
anterior e implementaron el guardado de los streams tanto en el dispositivo emisor
como en los nodos de tránsito de éste.

50



Conclusiones y trabajo futuro

En este trabajo se han planteado y alcanzado los siguientes objetivos:

Separación de WFA: Se ha conseguido aislar y encapsular el funcionamien-
to de WFA de RTSP, permitiendo la introducción de nuevas tecnologías que
sustituyan las actuales, otorgando una mayor flexibilidad y adaptabilidad a la
aplicación. Detallado en la Sección 6.3.

Testeo del funcionamiento sin WFA: Se ha implementado un sistema ru-
dimentario que conecta dispositivos mediante su dirección IP, como se explica
en la Sección 6.3.3, para sustituir las funcionalidades básicas de conexión entre
dispositivos que proporciona WFA y testear su correcto funcionamiento.

Recolección y envío de pruebas para su uso en juicios: Para ello, se ha
empleado la biblioteca proporcionada por ProofMode para su recopilación y
las técnicas aprendidas tras investigar sobre la transmisión de metadatos para
su envío, como se detalla en la Sección 6.5.

Inyección de dependencias para la configuración dinámica de la red
a utilizar por la aplicación: Mediante Dagger, se inyecta la clase encargada
de inicializar la red escogida. Detallado en la Sección 6.6.

Opciones de accesibilidad: De manera que se adapte automáticamente al
idioma del dispositivo dependiendo de las traducciones del que la aplicación
disponga. Se ha añadido la versión en español. Idiomas disponibles: [en] [es].

La principal adversidad y la tarea en la que se ha invertido la mayor parte del
tiempo de desarrollo del presente trabajo es la investigación. Tanto de las tecnologías
utilizadas para construir el proyecto como las nuevas que se introducirán para lograr
los objetivos planteados en la Sección 1.2. Con la dificultad añadida debido a falta
de experiencia para usar el framework de desarrollo principal, Android Studio.

A pesar de ello, se ha logrado cumplir una gran parte de las metas establecidas
y para las que no, se ha planteado una reflexión sobre los aspectos a tener en cuenta
o bien se ha contribuido a su desarrollo.

En la Sección 6.7 se ha planteado un modelo para proteger los paquetes RTP
enviados en la transmisión, aunque solo se ha llegado a implementar una pri-
mera versión mediante el uso de una clave compartida.

Otro de los objetivos planteados pero que no se ha llegado a cumplir debido
a la falta de tiempo es realizar un fork de la biblioteca libstreaming con los
cambios realizados hasta la versión actual y la publicación del presente trabajo
como un proyecto de software libre.

7.2. Trabajo futuro

Con respecto al futuro de este proyecto, en este TFG se ha logrado facilitar la
introducción de nuevas tecnologías para sustituir las existentes en el futuro, además

51



Conclusiones y trabajo futuro

de implementar avances para el posible futuro uso de la aplicación para la docu-
mentación y denuncia de crímenes en el escenario Witness, o bien para localizar una
víctima de un desastre natural en el escenario Humanitarian.

Se proponen los siguientes puntos o retos como trabajo a desarrollar en versiones
posteriores de la aplicación:

Cifrado de paquetes RTP: Como medio para comprobar su integridad,
autenticación de origen, al mismo tiempo que protege el anonimato del nodo
emisor. Con la propuesta presentada en la Sección 6.7, se propone un sistema
de cifrado mediante clave para proteger los paquetes del stream, los cuales por
ahora viajan como texto claro en la MANET. Se deberá considerar si usar una
clase simétrica o asimétrica y los requisitos para implementar cada uno.

• Con la clave simétrica, se protege el anonimato del nodo que origina el
stream al no requerir de ningún dato vinculante a su persona, pero se
hace necesario el establecimiento de un protocolo para el intercambio de
claves como Diffie-Hellman ante la posibilidad de que no les sea posible
a los nodos el intercambio por medios convencionales.

• Con la clave asimétrica, se compromete la identidad del nodo emisor al
requerir de una de su par de claves para el descifrado. Se debe considerar
qué datos asociar al par de claves en el momento de su creación para
poder usarse para su posterior autenticación de origen.

Asociación de los datos captados por ProofMode a la retransmisión
en directo: Se debe investigar una forma de identificar un stream en directo,
preferiblemente a través de un archivo, para poder usarse en conjunción con
ProofMode. Esto implicaría encontrar un método para relacionar los datos
capturados, como metadatos o evidencia grabada, con el stream correspon-
diente. Esta asociación permitiría que los datos capturados se utilicen como
pruebas para respaldar la autenticidad del contenido audiovisual en un juicio.

Adaptación de libstreaming a RTSP 2.0: Actualizar el protocolo por su
versión más reciente, adaptando el proyecto para usar la modalidad reproducir
en la transmisión de streams en lugar de la modalidad publicar. Para ello, se
deberá adaptar el cliente RTSP para que use esta modalidad, ya que el servi-
dor RTSP ya posee esta funcionalidad. Sin embargo, al prescindir del modelo
que permite anunciar los streams que el dispositivo ofrece, se hace necesario
implementar un método para hacer llegar al cliente RTSP el contenido multi-
media que el servidor ofrece. Los alumnos de 20/21 propusieron implementar
una directiva DESCRIBE especial para proporcionar la lista de streams o un
stream concreto dependiendo de la URI solicitada. Por ejemplo, si la URI so-
licitada es inválida, el servidor responde con la lista completa. O bien a través
de los mensajes intercambiados en la fase de establecimiento de la conexión
entre publisher y subscriber de WFA.

52



Conclusiones y trabajo futuro

7.3. Observaciones finales

A pesar de no haber podido cumplir con todas de las metas establecidas, la
aplicación resultante constituye un paso más para demostrar la viabilidad del con-
cepto de broadcast en una MANET, mejorando su flexibilidad y funcionalidad. Se
espera que este proyecto construya una base sólida sobre la cual permitir la intro-
ducción de nuevas tecnologías y brindar ideas para la transmisión segura de streams,
contribuyendo así a la seguridad de las MANET.

53



8. Conclusions and future work

The field of MANETs has a remarkable presence and importance in the devices
we use today. From Bluetooth headphones to making payments through NFC tech-
nology, it is clear that wireless communication between mobile devices has become
essential in our daily lives.

This type of network, thanks to its decentralized nature, can evade the control of
traditional infrastructures and enable direct communication between mobile devices
(peer-to-peer or p2p). This offers numerous advantages in terms of flexibility, adap-
tability, and communication capability in environments where conventional network
infrastructure is unavailable or limited. However, it is also important to consider
some disadvantages of MANETs:

Routing issues: Finding the optimal node to build the fastest route to reach
the destination.

Security: Due to the absence of a centralized security infrastructure, MANETs
are more susceptible to attacks such as man-in-the-middle or DoS.

Energy consumption: Assuming the devices take on the role of the router
entails additional responsibilities for each node in the network.

8.1. Recap and evaluation

This project focuses on providing an extension and improvement based on the
results obtained in the 2020/21 Bachelor’s Thesis titled “Multistreaming de video
y audio en una red ad hoc de dispositivos móviles corrientes” [4]. In that Bache-
lor’s Thesis, the focus was on the transmission of audiovisual content over WiFi
Aware (WFA), an infrastructure-less network that allows users to establish peer-to-
peer communication without the need for a base station. The present work aims to
enhance the resulting application from the aforementioned project, enabling it to
function even if the device lacks the necessary hardware to initiate a WFA network.
Additionally, in order for the documented audiovisual content to be used as evidence
for crime reporting in the future, initial steps have been taken to include data that
demonstrates its authenticity and integrity. Furthermore, options for accessibility
will be added to the application itself, allowing it to automatically adapt to the
device’s language.

For the development of this project, a first phase of research was carried out. This
involved not only studying WiFi Aware, a relatively new and poorly documented
technology, but also the development environment, Android Studio, which had no
previous experience, and the entire journey that this application has gone through. It

54



Conclusions and future work

started with its initial outline by the students of the 2018/19 Bachelor’s Thesis titled
“Device to Device streaming en dispositivos móviles” [75], then further refined by
the students of the 2019/20 Bachelor’s Thesis titled “Crowdstreaming: transmisión
de vídeo y audio por una red ad hoc de teléfonos móviles” [18] and finally shaped
by the students of the 2020/21 Bachelor’s Thesis titled “Multistreaming de video y
audio en una red ad hoc de dispositivos móviles corrientes” [4]. Special emphasis was
given to the last mentioned Bachelor’s Thesis, as it is the project from which the
present work builds upon. All of this was done in order to understand the internal
workings of the application at the code level, the usage and functioning of classes,
and the flow of information from the application’s initiation to its termination. A
brief description of the aforementioned projects will be presented below.

Regarding the project of the year 18/19, they were the pioneers who laid the
foundations upon which the application will be built. They introduced the use of
the libstreaming library for streaming and modified it to enable cooperation between
the client and server provided by the library. They decided to use WiFi Direct as
the technology for discovering and connecting devices. However, they encountered a
significant obstacle. They discovered that Google chose not to implement an optional
feature of WiFi Direct in Android, which would have allowed a node to belong to
multiple WiFi Direct networks. As a result, they were limited in terms of the scope
of expansion for stream they could transmit. They introduced the concept of “multi-
hop” as cited in their report, “donde los dispositivos puedan ser nodos de transito(sic)
del streaming” [ [75], 5.1.4], and achieved streaming transmission between a pair of
devices. In the future, the students of the 20/21 project will further enhance this
functionality to enable its expansion to a wider range.

The students in the 19/20 academic year specified the use of WiFi Aware instead
of WiFi Direct to overcome the limitations mentioned. However, due to the lack
of detailed documentation on this technology, coupled with the global emergency
situation and the delay in securing funds to acquire devices capable of initiating a
WFA network, they had to forego certain features and focus on those they deemed
more realistic within the available time frame. As a result, since they were unable
to resolve the compatibility issue of libstreaming with IPv6, they abandoned it and
opted to use the SCTP protocol for video and audio transmission. However, lacking
a control protocol, the transmission quality was compromised.

Regarding the students in the 2020/21 academic year, they capitalized on the
knowledge acquired through the analysis of previous projects and the availability of
mobile devices at their disposal. They resumed the use of libstreaming for stream
broadcasting and continued to utilize WFA as directed by their Bachelor’s Thesis
supervisor. This required making multiple modifications to ensure compatibility bet-
ween both technologies. They improved the transmission quality, resolved the loop
issue raised in the previous Bachelor’s Thesis, and implemented stream storage on
both the transmitting device and the transit nodes.

In this work, the following objectives have been proposed and achieved:

55



Conclusions and future work

Separation of WFA: The isolation and encapsulation of WFA functionality
from RTSP have been achieved, allowing for the introduction of new technolo-
gies to replace the current ones, providing greater flexibility and adaptability
to the application. Detailed in Section 6.3.

Testing of functionality without WFA: A rudimentary system has been
implemented that connects devices using their IP address, as explained in
Section 6.3.3, to replace the basic device connection features provided by WFA
and to test its proper functioning.

Collection and submission of evidence for use in legal proceedings:
The ProofMode library has been employed for evidence collection, and tech-
niques for transmitting metadata have been investigated and implemented, as
detailed in Section 6.5.

Dependency injection for dynamic configuration of the network used
by the application: Using Dagger, the class responsible for initializing the
chosen network is injected. Detailed in Section 6.6.

Accessibility options: The application automatically adapts to the devi-
ce’s language based on the available translations. A Spanish version has been
added. Available languages: [en] [es].

The main challenge and the task that has consumed the majority of the develop-
ment time in this work is research. This includes studying the technologies used to
build the project and the new ones that will be introduced to achieve the objectives
outlined in Section 1.2. The added difficulty arises from the lack of experience in
using the main development framework, Android Studio.

Despite these challenges, a significant portion of the set goals has been accom-
plished, and for those that haven’t, reflection has been provided on the aspects to
consider or contributions have been made towards their development.

In Section 6.7 a model has been proposed to protect the RTP packets sent in
the transmission, although only a preliminary version has been implemented
using a shared key.

Another objective that was not achieved due to time constraints is to fork
the libstreaming library with the changes made up to the current version and
publish this work as an open-source project.

8.2. Future work

Regarding the future of this project, in this Bachelor’s Thesis, progress has been
made in facilitating the introduction of new technologies to replace the existing
ones in the future. Additionally, advancements have been implemented for the po-
tential future use of the application in scenarios such as Witness, for documenting
and reporting crimes, or in Humanitarian scenarios, for locating victims of natural
disasters.

56



Conclusions and future work

The following points or challenges are proposed as future work to be developed
in subsequent versions of the application:

RTP Packet Encryption: As a means to ensure integrity and source authen-
tication while protecting the anonymity of the transmitting node. With the
proposal presented in Section 6.7, a key-based encryption system is suggested
to protect the packets of the stream, which currently travel as plaintext in the
MANET. The choice between symmetric or asymmetric encryption should be
considered, along with the requirements for implementing each approach.

• With symmetric key encryption, the anonymity of the node originating
the stream is protected as it does not require any personally identifiable
information. However, it becomes necessary to establish a protocol for
key exchange, such as Diffie-Hellman, in case the nodes are unable to
exchange keys through conventional means.

• With asymmetric key encryption, the identity of the emitting node is
compromised as one of its key pairs is required for decryption. It is ne-
cessary to consider what data to associate with the key pair at the time
of its creation in order to be used for source authentication.

Association of ProofMode-captured data with the live stream: It is
necessary to investigate a way to identify a live stream, preferably through a
file, in order to be used in conjunction with ProofMode. This would involve
finding a method to link the captured data, such as metadata or recorded
evidence, with the corresponding live stream. This association would allow
the captured data to be used as evidence to support the authenticity of the
audiovisual content in a legal proceeding.

Adaptation of libstreaming to RTSP 2.0: Update the protocol to its latest
version, adapting the project to use the “PLAY” mode for streaming instead of
the “publish” mode. To achieve this, the RTSP client needs to be modified to
support this mode, as the RTSP server already has this functionality. However,
since the model for announcing the available streams offered by the device is
no longer used, it becomes necessary to implement a method for delivering the
multimedia content offered by the server to the RTSP client. The students of
20/21 proposed implementing a special DESCRIBE directive to provide the list
of streams or a specific stream depending on the requested URI. For example,
if the requested URI is invalid, the server responds with the complete list.
Alternatively, this can be done through the exchanged messages during the
connection establishment phase between the WFA publisher and subscriber.

8.3. Final Remarks

Despite not being able to achieve all the set goals, the resulting application
represents a further step in demonstrating the feasibility of the broadcast concept
in a MANET, improving its flexibility and functionality. It is expected that this
project will build a solid foundation to enable the introduction of new technologies

57



Conclusions and future work

and provide ideas for secure stream transmission, thus contributing to the security
of MANETs.

58



A. Detalles del diseño

A.1. Investigación y análisis inicial

A.1.1. Proyecto 2018/19: D2D

El proyecto se planteó como objetivo crear una red ad hoc entre dispositivos
móviles cercanos y así poder transmitir video en streaming sin depender de los
operadores de telecomunicaciones. Esta idea permeará a lo largo de los proyectos
siguientes, convirtiéndose en la idea central de la aplicación y asentando las bases
sobre las cuales proyectos de años siguientes implementarán nuevas funcionalidades.

En primer lugar, eligieron Android como sistema operativo debido a su alta
prevalencia en el mercado de dispositivos móviles. Citando statista [76]:

«Según cifras de marzo de 2023, Android mantiene en la actualidad su posición
como sistema operativo móvil líder a nivel mundial, con una cuota de mercado
del 71 %»

Consideraron dos opciones de tecnología de conexión: WiFi Direct y WiFi Aware.
Debido a la falta de documentación y disponibilidad de dispositivos, se optó por
WiFi Direct. Sin embargo, se encontraron limitaciones en la implementación de
WiFi Direct en Android, lo que dificultó la creación de la red ad hoc.

Incluyeron una biblioteca de código abierto, libstreaming, que se ajustaba a
los requisitos del proyecto, pero presentaba limitaciones como la imposibilidad de
transmitir a múltiples dispositivos simultáneamente.

Para solucionar el problema de la transmisión simultánea a múltiples destinos,
primero implementaron las clases AudioPacketizerDispatcher y
VideoPacketizerDispatcher. Estas clases se encargan de leer los datos de los pe-
riféricos, como la cámara y el micrófono, y luego los codifican utilizando un com-
ponente llamado MediaCodec. Los datos codificados se transfieren a Packetizers
suscritos a estas clases, que son los encargados de crear paquetes de transmisión
RTP y enviarlos.

Cuando se inicia una nueva sesión, las clases AudioStream y VideoStream deben
suscribir sus Packetizers a los Dispatchers correspondientes. Los Dispatchers
crean un nuevo ByteBufferInputStream para cada Packetizer y lo asignan como
la fuente de los datos.

Los Dispatchers se encargan de obtener los datos de los periféricos, codificarlos
y distribuirlos a los Packetizers correspondientes. Los Packetizers, a su vez,

59



Detalles del diseño

utilizan los datos recibidos para crear los paquetes de transmisión y enviarlos a los
dispositivos receptores.

Figura A.1: Diagrama de clases que muestra las relaciones con los Packetizer

Ahora bien, la aplicación no solo debía ser capaz de enviar el stream a múltiples
destinos, sino también actuar como un repetidor y retransmitirlos (Multihop). Para
ello, implementaron las clases ReceiveSession, para encapsular el stream recibido de
otro dispositivo, y RebroadcastSession, para encapsular el stream reenviado. Estas
clases trabajan a nivel de la capa de transporte en conjunto con los protocolos RTP
y RTCP. No obstante, la implementación del reenvío de flujos a través de RTSP
quedó incompleta al requerir la extensión del servidor y cliente RTSP para enviar
múltiples flujos a múltiples destinos.

A.1.2. Proyecto 19/20: Crowdstreaming

Este proyecto tiene como objetivo implementar la transmisión de flujos de vi-
deo y audio a través de una red ad-hoc de dispositivos móviles, basándose en los
resultados obtenidos en el proyecto anterior del año 2018/19, sustituyendo WiFi
Aware por WiFi Direct debido a la inadecuación de Wifi Direct para los fines del
“crowdstreaming”, que dicho proyecto había puesto de relieve. Uno de esos proble-
mas fue la implementación de un nodo de tránsito, que no se pudo resolver debido
a limitaciones de Wifi Direct en Android. Sin embargo, la tecnología Wifi Aware ha
proporcionado la funcionalidad necesaria para abordar estos problemas. Mencionan
la dificultad añadida que supuso la falta de documentación sobre el desarrollo con
Wifi Aware, pero se pudo superar gracias a proyectos en Github que sirvieron como
base para la aplicación.

Otra dificultad fue la disponibilidad de dispositivos compatibles con Wifi Aware,
lo que retrasó el inicio del desarrollo. Debido a la tardanza para obtener dispositivos
compatibles con esta tecnología, esto limitó el alcance del proyecto obligándoles a
prescindir de algunos requisitos como la seguridad y anonimato de los usuarios en el
modo Witness. Además, la situación provocada por la pandemia del COVID-19 y la
falta de tiempo les llevaron a tener que enfocarse en los requisitos más importantes

60



Detalles del diseño

y prescindir de ciertas funcionalidades, como un protocolo de control sobre el flujo
de video.

También quedaron pendientes algunas restricciones relacionadas con el anonima-
to y la seguridad de los usuarios, así como la opción de difuminar las caras. Además,
surgió la idea de implementar un nodo tránsito como repetidor múltiple, lo que per-
mitiría compartir múltiples emisiones simultáneamente, pero esto planteaba desafíos
adicionales, como el problema de ciclos y el rendimiento de la red.

Dejaron como trabajo futuro y puntos a tratar para mejorar la aplicación la
posibilidad de poner un título a las emisiones, seleccionar la cámara frontal o tra-
sera para la transmisión de video, mostrar el número de espectadores y cifrar las
emisiones.

A.1.3. Firma digital

En el contexto de este TFG, la firma con la clave pública se convierte en una ba-
rrera efectiva contra los intentos de manipulación del stream transmitido por parte
de atacantes. Esto se debe a que el atacante desconoce la identidad del nodo receptor
del stream y, por lo tanto, no tiene conocimiento de la clave pública necesaria para
cifrar el contenido y hacerlo pasar como legítimo. Sin embargo, es importante des-
tacar que esta solución plantea desafíos que podrían comprometer el anonimato del
emisor, lo cual es una característica esencial en el escenario Witness. Por lo tanto,
se requiere una cuidadosa consideración de los aspectos de seguridad y privacidad
al implementar esta metodología.

En el escenario Witness, uno de los objetivos consiste en conseguir autenticidad
de origen, pero sin comprometer el anonimato del emisor. En el momento de creación
de la clave de cifrado, se piden datos identificativos del propietario de la clave. Sin
embargo, no realiza una comprobación de si la información proporcionada es verídica.
No obstante, asociar un pseudónimo o datos falsos a la clave de cifrado se vuelve una
espada de doble filo, ya que ninguna parte, sean maliciosos o no, puedan localizar
al emisor, opacando la autenticidad de origen.

Por lo tanto, lo que el emisor puede hacer es crear su par de claves de cifrado
asimétrico sea o no con datos falsos, y de algún modo, intercambiar las claves públicas
con el/los destinatarios o custodiantes finales. Es decir, el emisor conoce la clave
pública del receptor y viceversa. Así el emisor, podrá aplicar 2 capas de firmas, una
del emisor usando su clave privada, y otra del receptor, usando su clave pública. Así,
el destinatario usará su clave privada para descifrar la primera capa y la clave pública
del emisor para descifrar la segunda. Con esto se consigue asegurar la integridad de
datos recibidos y autenticación de origen. Solo el destinatario final podrá conocer
los datos asociados a la entidad que ha firmado el stream, los cuales pueden o no
contener datos reales. Lo que es seguro es que podrá asociar el stream a unos datos
de autenticación fijos. Es decir, todos los streams que el emisor A le envía estarán
asociados a los datos de autenticación del emisor A. Solo el emisor A posee la clave

61



Detalles del diseño

privada, así que para comprobar que alguien es realmente el emisor de esas pruebas,
solo deberá proporcionarle un archivo cifrado con la clave pública para que éste lo
descifre con su clave privada.

Así el receptor desconoce la identidad del emisor. Solo puede asociar las pruebas
a una clave pública.

62



B. Resolución de cuestiones encontradas

B.1. Elementos de la lista de streams llevan al mis-
mo stream

Durante el análisis del código pertinente a la creación de la lista de streams que
el dispositivo recibe, se pudo observar que los elementos de la lista llevaban al mismo
stream independientemente de cuál de ellos sea seleccionado.

En específico, en el callback correspondiente a la generación de los elementos
de la lista (onBindViewHolder() en la clase StreamListAdapter), se empleaba una
instancia de StreamDetail, la cual era almacenada en la clase y reasignada al nue-
vo stream cada vez que el mencionado callback era invocado. Asimismo, el botón
destinado a la descarga del stream usa la instancia de StreamDetail anteriormente
mencionada para iniciar o finalizar la descarga. Por ende, debido a que el objeto
StreamDetail era reasignado cada vez que el callback era ejecutado, el mismo se
encontraba siempre asociado al último elemento de la lista que dicho callback creaba.

Para abordar este inconveniente, se ha procedido a eliminar de la clase el atributo
StreamDetail y a instanciarla de manera local en el callback onBindViewHolder().

63



Bibliografía

[1] Shuttleworth Foundation. url: https://www.shuttleworthfoundation.
org/.

[2] fyhertz. libstreaming. url: https://github.com/fyhertz/libstreaming
(Último acceso: 25-05-2023).

[3] Guardian Project. Guardian Project. url: https://guardianproject.info/
(Último acceso: 25-05-2023).

[4] Daniel Alfaro Miranda y Luis Pozas Palomo. «Multistreaming de video y audio
en una red ad hoc de dispositivos móviles corrientes». thesis. UCM, 2020-2021.
url: https://eprints.ucm.es/id/eprint/66862/1/Alfaro%20Miranda%
2083166_Daniel_Alfaro_Miranda_Multistreaming_784051_937851.pdf
(Último acceso: 12-06-2021).

[5] Freedom of the Press Foundation. SecureDrop. url: https://securedrop.
org/.

[6] Tor Project. Tor Project. 2023. url: https://www.torproject.org (Último
acceso: 25-05-2023).

[7] Wikipedia. Terremoto de Haití de 2010. url: https://es.wikipedia.org/
wiki/Terremoto_de_Hait%C3%AD_de_2010 (Último acceso: 25-05-2023).

[8] Wikipedia. Huracán Katrina. url: https : / / es . wikipedia . org / wiki /
Hurac%C3%A1n_Katrina (Último acceso: 25-05-2023).

[9] Wikipedia. Huracán Laura. url: https://es.wikipedia.org/wiki/Hurac%
C3%A1n_Laura (Último acceso: 25-05-2023).

[10] TechTarget. Man-in-the-middle attack (MitM). url: https://www.techtarget.
com/iotagenda/definition/man-in-the-middle-attack-MitM (Último
acceso: 25-05-2023).

[11] Palo Alto Networks. What is a Denial of Service (DoS) Attack? url: https:
/ / www . paloaltonetworks . com / cyberpedia / what - is - a - denial - of -
service-attack-dos (Último acceso: 25-05-2023).

[12] Wikipedia. Deepfake. url: https://es.wikipedia.org/wiki/Deepfake
(Último acceso: 25-05-2023).

[13] SEON. Deepfake. url: https://seon.io/es/recursos/glosario/deepfake/
(Último acceso: 25-05-2023).

[14] Time. How to Spot Deepfake Pope. url: https://time.com/6266606/how-
to-spot-deepfake-pope/ (Último acceso: 25-05-2023).

[15] Fakeyou. Fakeyou. url: https://fakeyou.com (Último acceso: 25-05-2023).

64

https://www.shuttleworthfoundation.org/
https://www.shuttleworthfoundation.org/
https://github.com/fyhertz/libstreaming
https://guardianproject.info/
https://eprints.ucm.es/id/eprint/66862/1/Alfaro%20Miranda%2083166_Daniel_Alfaro_Miranda_Multistreaming_784051_937851.pdf
https://eprints.ucm.es/id/eprint/66862/1/Alfaro%20Miranda%2083166_Daniel_Alfaro_Miranda_Multistreaming_784051_937851.pdf
https://securedrop.org/
https://securedrop.org/
https://www.torproject.org
https://es.wikipedia.org/wiki/Terremoto_de_Hait%C3%AD_de_2010
https://es.wikipedia.org/wiki/Terremoto_de_Hait%C3%AD_de_2010
https://es.wikipedia.org/wiki/Hurac%C3%A1n_Katrina
https://es.wikipedia.org/wiki/Hurac%C3%A1n_Katrina
https://es.wikipedia.org/wiki/Hurac%C3%A1n_Laura
https://es.wikipedia.org/wiki/Hurac%C3%A1n_Laura
https://www.techtarget.com/iotagenda/definition/man-in-the-middle-attack-MitM
https://www.techtarget.com/iotagenda/definition/man-in-the-middle-attack-MitM
https://www.paloaltonetworks.com/cyberpedia/what-is-a-denial-of-service-attack-dos
https://www.paloaltonetworks.com/cyberpedia/what-is-a-denial-of-service-attack-dos
https://www.paloaltonetworks.com/cyberpedia/what-is-a-denial-of-service-attack-dos
https://es.wikipedia.org/wiki/Deepfake
https://seon.io/es/recursos/glosario/deepfake/
https://time.com/6266606/how-to-spot-deepfake-pope/
https://time.com/6266606/how-to-spot-deepfake-pope/
https://fakeyou.com


Bibliografía

[16] Unite.ai. Google’s LipSync3D Offers Improved Deepfaked Mouth Movement
Synchronization. url: https://www.unite.ai/googles-lipsync3d-offers-
improved-deepfaked-mouth-movement-synchronization/ (Último acceso:
25-05-2023).

[17] Becoming Human. Deepfake Audio with Wav2Lip. url: https://becominghuman.
ai/deepfake-audio-with-wav2lip-263f0f0e84bc (Último acceso: 25-05-2023).

[18] Francisco Calero Velasco, Sergio Manzanaro Caraballo y David Salido Cama-
cho. «Crowdstreaming: transmisión de vídeo y audio por una red ad hoc de
teléfonos móviles». thesis. UCM, 2019-2020. url: https://eprints.ucm.es/
id/eprint/61913/1/SALIDO_CAMACHO_Crowdstreaming_transmision_de_
video_y_audio_por_una_red_ad_hoc_de_telefonos_moviles_4398577_
1858548838.pdf (Último acceso: 12-06-2021).

[19] FoxID. FoxID. url: https://foxid.eu (Último acceso: 25-05-2023).

[20] Stripe. Stripe Identity. url: https://stripe.com/es-gb/identity (Último
acceso: 25-05-2023).

[21] Kanbanize. ¿Qué es Kanban? url: https://kanbanize.com/es/recursos-
de-kanban/primeros-pasos/que-es-kanban (Último acceso: 25-05-2023).

[22] Wikipedia. Mobile data offloading. url: https://en.wikipedia.org/wiki/
Mobile_data_offloading (Último acceso: 25-05-2023).

[23] TechPrevue. Data Offloading Defined. url: https://www.techprevue.com/
data-offloading-defined/ (Último acceso: 25-05-2023).

[24] Conectrónica. Despliegue a gran escala de la tecnología 5G mmWave. url:
https://www.conectronica.com/noticias/despliegue-a-gran-escala-
de-la-tecnologia-5g-mmwave (Último acceso: 25-05-2023).

[25] Mohd Hirzi Adnan y Zuriati Ahmad Zukarnain. «Device-To-Device Commu-
nication in 5G Environment: Issues, Solutions, and Challenges». En: issn:
2073-8994. url: https://www.mdpi.com/2073-8994/12/11/1762.

[26] Mohit Kumar y Rashmi Mishra. Overview of MANET: History, Challenges
and Applications. PDF document. 2012. url: https://shorturl.at/auw37
(Último acceso: 25-05-2023).

[27] Charles E. Perkins y Pravin Bhagwat. Highly dynamic Destination-Sequenced
Distance-Vector routing (DSDV) for mobile computers. 1997. url: https:
//dl.acm.org/doi/10.1145/190314.190336 (Último acceso: 25-05-2023).

[28] Internet Engineering Task Force. Optimized Link State Routing Protocol (OLSR).
2003. url: https://datatracker.ietf.org/doc/html/rfc3626 (Último
acceso: 25-05-2023).

[29] Internet Engineering Task Force. Ad hoc On-Demand Distance Vector (AODV)
Routing. 2003. url: https://datatracker.ietf.org/doc/html/rfc3561
(Último acceso: 25-05-2023).

[30] Internet Engineering Task Force. The Dynamic Source Routing Protocol (DSR)
for Mobile Ad Hoc Networks for IPv4. 2007. url: https://datatracker.
ietf.org/doc/html/rfc4728 (Último acceso: 25-05-2023).

65

https://www.unite.ai/googles-lipsync3d-offers-improved-deepfaked-mouth-movement-synchronization/
https://www.unite.ai/googles-lipsync3d-offers-improved-deepfaked-mouth-movement-synchronization/
https://becominghuman.ai/deepfake-audio-with-wav2lip-263f0f0e84bc
https://becominghuman.ai/deepfake-audio-with-wav2lip-263f0f0e84bc
https://eprints.ucm.es/id/eprint/61913/1/SALIDO_CAMACHO_Crowdstreaming_transmision_de_video_y_audio_por_una_red_ad_hoc_de_telefonos_moviles_4398577_1858548838.pdf
https://eprints.ucm.es/id/eprint/61913/1/SALIDO_CAMACHO_Crowdstreaming_transmision_de_video_y_audio_por_una_red_ad_hoc_de_telefonos_moviles_4398577_1858548838.pdf
https://eprints.ucm.es/id/eprint/61913/1/SALIDO_CAMACHO_Crowdstreaming_transmision_de_video_y_audio_por_una_red_ad_hoc_de_telefonos_moviles_4398577_1858548838.pdf
https://eprints.ucm.es/id/eprint/61913/1/SALIDO_CAMACHO_Crowdstreaming_transmision_de_video_y_audio_por_una_red_ad_hoc_de_telefonos_moviles_4398577_1858548838.pdf
https://foxid.eu
https://stripe.com/es-gb/identity
https://kanbanize.com/es/recursos-de-kanban/primeros-pasos/que-es-kanban
https://kanbanize.com/es/recursos-de-kanban/primeros-pasos/que-es-kanban
https://en.wikipedia.org/wiki/Mobile_data_offloading
https://en.wikipedia.org/wiki/Mobile_data_offloading
https://www.techprevue.com/data-offloading-defined/
https://www.techprevue.com/data-offloading-defined/
https://www.conectronica.com/noticias/despliegue-a-gran-escala-de-la-tecnologia-5g-mmwave
https://www.conectronica.com/noticias/despliegue-a-gran-escala-de-la-tecnologia-5g-mmwave
https://www.mdpi.com/2073-8994/12/11/1762
https://shorturl.at/auw37
https://dl.acm.org/doi/10.1145/190314.190336
https://dl.acm.org/doi/10.1145/190314.190336
https://datatracker.ietf.org/doc/html/rfc3626
https://datatracker.ietf.org/doc/html/rfc3561
https://datatracker.ietf.org/doc/html/rfc4728
https://datatracker.ietf.org/doc/html/rfc4728


Bibliografía

[31] Internet Engineering Task Force. Zone Routing Protocol (ZRP). 2001. url:
https://datatracker.ietf.org/doc/html/draft-ietf-manet-zone-
zrp/ (Último acceso: 25-05-2023).

[32] Internet Engineering Task Force. Scalable Hybrid Wireless Mesh Protocol (SHWMP).
2022. url: https : / / datatracker . ietf . org / doc / html / draft - rfc -
editor-shwmp-00 (Último acceso: 25-05-2023).

[33] Jose Angel Leon Calvo, Rheinisch-Westfalische y Rudolf Mathar. «Wireless
powering of drone-based MANETs for disaster zones». En: (2017). url: https:
//ieeexplore.ieee.org/abstract/document/8124900.

[34] Ankur O. Bang y Prabhakar L. Ramteke. MANET: History, Challenges, And
Applications. 2013. url: https : / / shorturl . at / fgkxF (Último acceso:
25-05-2023).

[35] Rashmi Mishra Mohit Kumar. An Overview of MANET: History, Challenges
and Applications. PDF document. 2012. url: https://shorturl.at/vwEGR
(Último acceso: 25-05-2023).

[36] Bluetooth. Range. url: https : / / www . bluetooth . com / learn - about -
bluetooth/key-attributes/range/ (Último acceso: 25-05-2023).

[37] Bluetooth. Tech Overview. url: https : / / www . bluetooth . com / learn -
about-bluetooth/tech-overview/ (Último acceso: 25-05-2023).

[38] CasaDomótica. Tecnología Bluetooth aumentará en los próximos cinco años,
según estudio. 2021. url: https : / / www . casadomo . com / 2021 / 05 / 20 /
tecnologia-bluetooth-aumentara-proximos-cinco-anos-segun-estudio-
actualizacion-mercado-2021 (Último acceso: 25-05-2023).

[39] NFC Forum. NFC Forum. url: https://nfc-forum.org (Último acceso:
25-05-2023).

[40] Wi-Fi Alliance. Wi-Fi Alliance. url: https://www.wi- fi.org (Último
acceso: 25-05-2023).

[41] Wi-Fi Alliance. Wi-Fi Direct. url: https://www.wi-fi.org/discover-wi-
fi/wi-fi-direct (Último acceso: 25-05-2023).

[42] Wi-Fi Alliance. Wi-Fi Aware. url: https://www.wi-fi.org/discover-wi-
fi/wi-fi-aware (Último acceso: 25-05-2023).

[43] Apple Developer. HTTP Live Streaming. url: https://developer.apple.
com/streaming/ (Último acceso: 25-05-2023).

[44] Internet Engineering Task Force. RTP: A Transport Protocol for Real-Time
Applications. 2003. url: https : / / www . rfc - editor . org / rfc / rfc3550
(Último acceso: 25-05-2023).

[45] Internet Engineering Task Force. SDP: Session Description Protocol. 2006.
url: https://www.rfc-editor.org/rfc/rfc4566.html (Último acceso:
25-05-2023).

[46] Internet Engineering Task Force. Real Time Streaming Protocol (RTSP). 1998.
url: https://www.rfc-editor.org/rfc/rfc2326.html (Último acceso:
25-05-2023).

66

https://datatracker.ietf.org/doc/html/draft-ietf-manet-zone-zrp/
https://datatracker.ietf.org/doc/html/draft-ietf-manet-zone-zrp/
https://datatracker.ietf.org/doc/html/draft-rfc-editor-shwmp-00
https://datatracker.ietf.org/doc/html/draft-rfc-editor-shwmp-00
https://ieeexplore.ieee.org/abstract/document/8124900
https://ieeexplore.ieee.org/abstract/document/8124900
https://shorturl.at/fgkxF
https://shorturl.at/vwEGR
https://www.bluetooth.com/learn-about-bluetooth/key-attributes/range/
https://www.bluetooth.com/learn-about-bluetooth/key-attributes/range/
https://www.bluetooth.com/learn-about-bluetooth/tech-overview/
https://www.bluetooth.com/learn-about-bluetooth/tech-overview/
https://www.casadomo.com/2021/05/20/tecnologia-bluetooth-aumentara-proximos-cinco-anos-segun-estudio-actualizacion-mercado-2021
https://www.casadomo.com/2021/05/20/tecnologia-bluetooth-aumentara-proximos-cinco-anos-segun-estudio-actualizacion-mercado-2021
https://www.casadomo.com/2021/05/20/tecnologia-bluetooth-aumentara-proximos-cinco-anos-segun-estudio-actualizacion-mercado-2021
https://nfc-forum.org
https://www.wi-fi.org
https://www.wi-fi.org/discover-wi-fi/wi-fi-direct
https://www.wi-fi.org/discover-wi-fi/wi-fi-direct
https://www.wi-fi.org/discover-wi-fi/wi-fi-aware
https://www.wi-fi.org/discover-wi-fi/wi-fi-aware
https://developer.apple.com/streaming/
https://developer.apple.com/streaming/
https://www.rfc-editor.org/rfc/rfc3550
https://www.rfc-editor.org/rfc/rfc4566.html
https://www.rfc-editor.org/rfc/rfc2326.html


Bibliografía

[47] Apache Software Foundation. Apache License 2.0. url: https://www.apache.
org/licenses/LICENSE-2.0 (Último acceso: 25-05-2023).

[48] VideoLAN. libVLC - VLC’s SDK. url: https://www.videolan.org/vlc/
libvlc.html (Último acceso: 25-05-2023).

[49] Photool Inc. ExifTool. url: https : / / play . google . com / store / apps /
details?id=com.exiftool.free&hl=es&gl=US (Último acceso: 25-05-2023).

[50] OpenPGP Alliance. OpenPGP. url: https://www.openpgp.org (Último
acceso: 25-05-2023).

[51] ProofMode. About ProofMode. url: https://proofmode.org/about (Último
acceso: 25-05-2023).

[52] Guardian Project. CameraV. url: https://guardianproject.info/apps/
camerav (Último acceso: 25-05-2023).

[53] Trello. url: https://trello.com (Último acceso: 25-05-2023).

[54] Trello Use Cases. url: https://trello.com/use-cases (Último acceso:
25-05-2023).

[55] Google Dagger. url: https://github.com/google/dagger (Último acceso:
25-05-2023).

[56] Dagger. url: https://dagger.dev (Último acceso: 25-05-2023).

[57] Stackify. Dependency Injection - A Comprehensive Guide. url: https://
stackify.com/dependency-injection/ (Último acceso: 25-05-2023).

[58] GitHub. url: https://github.com/ (Último acceso: 25-05-2023).

[59] GitHub Features. url: https : / / github . com / features (Último acceso:
25-05-2023).

[60] Overleaf. url: https://es.overleaf.com (Último acceso: 25-05-2023).

[61] The LaTeX Project. url: https://www.latex-project.org (Último acceso:
25-05-2023).

[62] Wikipedia. Hash collision - Wikipedia. url: http://en.wikipedia.org/
wiki/Hash_collision (Último acceso: 25-05-2023).

[63] Android Developers. AndroidX ExifInterface - Releases. url: https://shorturl.
at/crtY2 (Último acceso: 25-05-2023).

[64] Android Developers. Android MediaMetadataEditor - Android Developers. url:
https://shorturl.at/cfIJQ (Último acceso: 25-05-2023).

[65] Android Developers. Android MediaMetadata - Android Developers. url: https:
//developer.android.com/reference/android/media/MediaMetadata
(Último acceso: 25-05-2023).

[66] Android Developers. Android MediaSession - Android Developers. url: https:
//shorturl.at/nsuxC (Último acceso: 25-05-2023).

[67] Android Developers. Android MediaMetadataRetriever - Android Developers.
url: https : / / developer . android . com / reference / android / media /
MediaMetadataRetriever (Último acceso: 25-05-2023).

67

https://www.apache.org/licenses/LICENSE-2.0
https://www.apache.org/licenses/LICENSE-2.0
https://www.videolan.org/vlc/libvlc.html
https://www.videolan.org/vlc/libvlc.html
https://play.google.com/store/apps/details?id=com.exiftool.free&hl=es&gl=US
https://play.google.com/store/apps/details?id=com.exiftool.free&hl=es&gl=US
https://www.openpgp.org
https://proofmode.org/about
https://guardianproject.info/apps/camerav
https://guardianproject.info/apps/camerav
https://trello.com
https://trello.com/use-cases
https://github.com/google/dagger
https://dagger.dev
https://stackify.com/dependency-injection/
https://stackify.com/dependency-injection/
https://github.com/
https://github.com/features
https://es.overleaf.com
https://www.latex-project.org
http://en.wikipedia.org/wiki/Hash_collision
http://en.wikipedia.org/wiki/Hash_collision
https://shorturl.at/crtY2
https://shorturl.at/crtY2
https://shorturl.at/cfIJQ
https://developer.android.com/reference/android/media/MediaMetadata
https://developer.android.com/reference/android/media/MediaMetadata
https://shorturl.at/nsuxC
https://shorturl.at/nsuxC
https://developer.android.com/reference/android/media/MediaMetadataRetriever
https://developer.android.com/reference/android/media/MediaMetadataRetriever


Bibliografía

[68] GitHub. sannies/mp4parser - GitHub. url: https://github.com/sannies/
mp4parser (Último acceso: 25-05-2023).

[69] Parrot. Parrot. url: https://www.parrot.com (Último acceso: 25-05-2023).

[70] Parrot. Parrot - Video Metadata. url: https://developer.parrot.com/
docs/pdraw/video-metadata.html (Último acceso: 25-05-2023).

[71] BMC Blogs. Solid Design Principles. url: https://www.bmc.com/blogs/
solid-design-principles (Último acceso: 25-05-2023).

[72] Google. ViewModelProvider - AndroidX Lifecycle. 2023. url: https://shorturl.
at/gP046 (Último acceso: 25-05-2023).

[73] CSIRT Comunidad Valenciana. Así funciona la seguridad de Telegram. 2023.
url: https://www.csirtcv.gva.es/es/noticias/as%C3%AD-funciona-
la-seguridad-de-telegram.html (Último acceso: 25-05-2023).

[74] Android Developers. Supporting Different Languages and Cultures. url: https:
/ / developer . android . com / training / basics / supporting - devices /
languages (Último acceso: 25-05-2023).

[75] Iván Gulyk y Noel José Algora Igual. «Device to Device Streaming en dispo-
sitivos móviles». thesis. UCM, 2018-2019. url: https://eprints.ucm.es/
id/eprint/56536/1/1138503790-303288_IV%C3%81N_GULYK_Memoria_TFG_
Device_to_Device_Streaming_en_Dispositivos_m%C3%B3viles_3940146_
1463809280.pdf (Último acceso: 12-06-2021).

[76] Sistema operativo móvil con la mayor cuota de mercado por país. Statista. url:
https://es.statista.com/grafico/29620/sistema-operativo-movil-
con-la-mayor-cuota-de-mercado-por-pais/ (Último acceso: 25-05-2023).

68

https://github.com/sannies/mp4parser
https://github.com/sannies/mp4parser
https://www.parrot.com
https://developer.parrot.com/docs/pdraw/video-metadata.html
https://developer.parrot.com/docs/pdraw/video-metadata.html
https://www.bmc.com/blogs/solid-design-principles
https://www.bmc.com/blogs/solid-design-principles
https://shorturl.at/gP046
https://shorturl.at/gP046
https://www.csirtcv.gva.es/es/noticias/as%C3%AD-funciona-la-seguridad-de-telegram.html
https://www.csirtcv.gva.es/es/noticias/as%C3%AD-funciona-la-seguridad-de-telegram.html
https://developer.android.com/training/basics/supporting-devices/languages
https://developer.android.com/training/basics/supporting-devices/languages
https://developer.android.com/training/basics/supporting-devices/languages
https://eprints.ucm.es/id/eprint/56536/1/1138503790-303288_IV%C3%81N_GULYK_Memoria_TFG_Device_to_Device_Streaming_en_Dispositivos_m%C3%B3viles_3940146_1463809280.pdf
https://eprints.ucm.es/id/eprint/56536/1/1138503790-303288_IV%C3%81N_GULYK_Memoria_TFG_Device_to_Device_Streaming_en_Dispositivos_m%C3%B3viles_3940146_1463809280.pdf
https://eprints.ucm.es/id/eprint/56536/1/1138503790-303288_IV%C3%81N_GULYK_Memoria_TFG_Device_to_Device_Streaming_en_Dispositivos_m%C3%B3viles_3940146_1463809280.pdf
https://eprints.ucm.es/id/eprint/56536/1/1138503790-303288_IV%C3%81N_GULYK_Memoria_TFG_Device_to_Device_Streaming_en_Dispositivos_m%C3%B3viles_3940146_1463809280.pdf
https://es.statista.com/grafico/29620/sistema-operativo-movil-con-la-mayor-cuota-de-mercado-por-pais/
https://es.statista.com/grafico/29620/sistema-operativo-movil-con-la-mayor-cuota-de-mercado-por-pais/


Acrónimos

ABR Adaptive bitrate. 19

MANET Mobile Ad-hoc NETwork. 1

RTCP Real Time Transport Control Protocol. 20

RTP Real Time Transport Protocol. 20

RTSP Real Time Streaming Protocol. 21

SDP Session Description Protocol. 20

69


	Portada
	Agradecimientos
	Índice general
	Índice de figuras
	Palabras Clave
	Keywords
	Resumen
	Abstract
	Introducción
	Motivación
	Objetivos
	Plan de trabajo

	Introduction
	Motivation
	Goals
	Work Plan

	Estado del arte
	Comunicación D2D
	Ambient awareness y ProSe

	MANET
	Bluetooth
	NFC
	Wifi
	Wifi Direct
	Wifi Aware

	Protocolos de interés
	HLS/MPEG-DASH
	RTP
	RTCP-RTP

	SDP
	RTSP

	Software de interés (énfasis en software libre)
	Libstreaming
	LibVLC
	Exiftools
	OpenPGP
	ProofMode


	Elección de tecnologías
	Tecnologías determinadas por proyectos anteriores
	Wi-Fi Aware
	RTP sobre UDP
	RTSP con SDP
	Libstreaming

	Tecnologías elegidas para este proyecto
	Android Studio
	Guardian Project: ProofMode
	Trello
	Dagger
	LaTeX y Overleaf


	Especificación
	Requisitos
	Pruebas seguras: Autenticidad e integridad


	Implementación
	Investigación inicial
	Android Studio
	Wi-Fi Aware
	Libstreaming
	Estado inicial de libstreaming
	Cambios realizados por los alumnos de 2018/19
	Cambios realizados por los alumnos de 2020/21


	Proyecto de 2020/21
	Cuestiones encontradas

	Separación de Wi-Fi Aware y RTSP
	Localización de las partes afectada
	Implementación de la separación
	Realización de pruebas: Conexión directa mediante IP

	Transmisión de metadatos
	Integridad y autenticidad en la transmisión de metadatos
	Hash
	Firma electrónica

	Desarrollo

	Generación y transmisión de pruebas mediante ProofMode
	Inyección de dependencias para la configuración dinámica de la red
	Patrón de diseño: Inyección de dependencias
	Desarrollo

	Shared Secret Mode
	Accesibilidad

	Conclusiones y trabajo futuro
	Recapitulación y evaluación
	Trabajo futuro
	Observaciones finales

	Conclusions and future work
	Recap and evaluation
	Future work
	Final Remarks

	Detalles del diseño
	Investigación y análisis inicial
	Proyecto 2018/19: D2D
	Proyecto 19/20: Crowdstreaming
	Firma digital


	Resolución de cuestiones encontradas
	Elementos de la lista de streams llevan al mismo stream

	Acrónimos