Mul is eaming de ideo y audio en una ed
ad hoc de disposi i os mó iles co ien es
Mul is eaming o ideo and audio in an ad-hoc ne wo k o
common mobile de ices
Daniel Al a o Mi anda (GII)
Luis Pozas Palomo (GII)
TRABAJO DE FIN DE GRADO
G ado en Ingenie ía In o má ica
Facul ad de In o má ica
Di igido po :
Simon Pickin
Cu so 2020/21
Ag adecimien os
Que emos ag adece oda la comp ensión y el apoyo b indado po nues os a-
milia es y amigos, sin los cuales no hab íamos llegado a es a donde es amos.
También g acias a la Fundación Shu lewo h [1], po la concesión de un "Flash
G an "que ha pe mi ido la comp a de los elé onos mó iles pa a hace es e abajo,
así como a And ew Lamb, ellow de la Fundación Shu lewo h que ecomendó la
concesión de dicha inanciación.
G acias a nues o u o Simon Pickin, po su paciencia y colabo ación en es e
abajo y su g an desempeño como p o eso du an e el g ado.
Po úl imo, que emos des aca la apo ación de los c eado es de la biblio eca
libs eaming [2], el cual nos aho o mucho iempo y si ió de g an ayuda pa a es e
y muchos o os p oyec os.
ii
Índice gene al
Ag adecimien os ii
Palab as Cla e ii
Keywo ds iii
Resumen ix
Abs ac x
1. In oducción 1
1.1. Mo i ación................................. 1
1.2. Obje i os ................................. 2
1.3. Plande abajo.............................. 4
2. In oduc ion 5
2.1. Mo i a ion................................. 5
2.2. Goals.................................... 6
2.3. Wo kplan................................. 8
3. An eceden es 9
3.1. ComunicaciónDTD............................ 9
3.1.1. Blue oo h ............................. 10
3.1.2. Wi i ................................ 10
3.1.3. Wi iAd-hocmode ........................ 11
3.1.4. Wi iDi ec ............................ 12
3.1.5. Mi acas .............................. 13
3.1.6. Wi iAwa e ............................ 13
3.1.7. LTEDi ec ............................ 14
3.1.8. NFC................................ 15
3.2. P o ocolos de in e és . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1. SCTP ............................... 15
3.2.2. RTP-RTCP ........................... 16
3.2.3. RTSP ............................... 16
3.2.4. SDP ................................ 17
3.2.5. HLS (HTTP Li e S eaming) . . . . . . . . . . . . . . . . . . 17
3.2.6. PPSPP (Pee - o-Pee S eaming Pee P o ocol) . . . . . . . . 18
3.2.7. RIST................................ 18
3.3. So wa e de in e és (én asis en so wa e lib e) . . . . . . . . . . . . . . 18
3.3.1. WebRTC ............................. 18
3.3.2. VLC................................ 19
iii

Índice gene al
3.3.3. FFmpeg .............................. 19
3.3.4. Gs eame ............................. 19
3.3.5. Libs eaming ........................... 20
4. Elección de ecnologías 21
4.1. And oid .................................. 21
4.2. WiFiAwa e................................ 21
4.3. Ja a .................................... 21
4.4. And oidS udio .............................. 21
4.5. RTPsob eUDP.............................. 22
4.6. RTSPySDP ............................... 22
4.7. Libs eaming ............................... 23
4.8. LibVLC .................................. 23
4.9. BalsamiqWi e ames........................... 23
4.10.Gi Hub .................................. 23
4.11.LaTeXyO e lea ............................. 24
5. Especi icación 25
5.1. Requisi os................................. 26
5.2. P o o ipo ................................. 27
6. Diseño 34
6.1. In e azg á ica .............................. 34
6.2. Ges ión de las conexiones RTSP, RTP y RTCP . . . . . . . . . . . . 35
6.3. Funcionamien o de Wi i Awa e . . . . . . . . . . . . . . . . . . . . . . 38
6.3.1. C eación de conexiones con Wi i Awa e . . . . . . . . . . . . . 39
6.3.2. Ges ión de Wi i Awa e . . . . . . . . . . . . . . . . . . . . . . 39
6.4. Diseño o ien ado al Mul ihopping . . . . . . . . . . . . . . . . . . . . 40
6.4.1. Iden i icación de los s eams en la ed dis ibuida . . . . . . . 40
6.4.2. Ges ión cen alizada de los s eams en el disposi i o . . . . . . 41
6.5. Aplicación del bo ón de pánico . . . . . . . . . . . . . . . . . . . . . 41
7. Implemen ación 44
7.1. RTSP, RTP y libs eaming . . . . . . . . . . . . . . . . . . . . . . . . 44
7.1.1. Análisis de libs eaming y o ien ación de la implemen ación . 44
7.1.1.1. Es ado de libs eaming . . . . . . . . . . . . . . . . . 44
7.1.1.2. Cambios en libs eaming po los alumnos de 2018/19 45
7.1.1.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . 46
7.1.2. Adap ación de libs eaming a IP 6 . . . . . . . . . . . . . . . 47
7.1.3. Ag upa el acceso a los lujos mul imedia . . . . . . . . . . . . 48
7.1.4. T ansmisión múl iple del lujo mul imedia . . . . . . . . . . . 49
7.1.4.1. Implemen ación de modalidades RTSP . . . . . . . . 50
7.1.4.2. Adap ación del se ido pa a la ansmisión múl iple 51
7.1.4.3. Adap ación del clien e pa a la ansmisión múl iple . 52
7.2. Wi iAwa e ................................ 52
i
Índice gene al
8. Conclusiones y abajo u u o 55
8.1. Recapi ulación y e aluación . . . . . . . . . . . . . . . . . . . . . . . 55
8.2. T abajo u u o .............................. 57
8.3. Obse aciones inales . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
9. Conclusions and u u e wo k 60
9.1. Summa y and e alua ion . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.2. Fu u ewo k................................ 62
9.3. Concluding ema ks............................ 63
10.Apo ación de los pa icipan es 64
10.1. Daniel Al a o Mi anda . . . . . . . . . . . . . . . . . . . . . . . . . . 64
10.1.1.In es igación ........................... 64
10.1.2.Desa ollo............................. 64
10.1.3.Memo ia.............................. 65
10.2.LuisPozasPalomo ............................ 65
10.2.1.In es igación ........................... 65
10.2.2.Desa ollo............................. 66
10.2.3.Memo ia.............................. 66
A. De alles del diseño 68
A.1. In es igación y análisis inicial . . . . . . . . . . . . . . . . . . . . . . 68
A.1.1. P oyec o 2018/19 . . . . . . . . . . . . . . . . . . . . . . . . . 68
A.1.2. P oyec o 2020/21 . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.1.3.Conclusiones ........................... 70
A.2. Elección de modalidad RTSP . . . . . . . . . . . . . . . . . . . . . . 71
A.3. C eación de conexiones con Wi i Awa e . . . . . . . . . . . . . . . . . 72
B. De alles de implemen ación 74
B.1. Es ado de libs eaming y los cambios en el cu so 2018/19 . . . . . . . 74
B.1.1. Es ado de libs eaming . . . . . . . . . . . . . . . . . . . . . . 74
B.1.2. Cambios en libs eaming po los alumnos de 2018/19 . . . . . 74
B.2. En ío del lujo mul imedia a mas de un des ino . . . . . . . . . . . . 76
B.3. Adap ación de se ido y clien e RTSP a Wi i Awa e . . . . . . . . . 78
B.4.Ges ióndeWi iAwa e .......................... 79
Índice de igu as
1.1. Plande abajo............................... 4
5.1. P o o ipo de la pan alla de selección del modo de uso. . . . . . . . . . 29
5.2. P o o ipo de la pan alla de inicio. . . . . . . . . . . . . . . . . . . . . 30
5.3. P o o ipo de la pan alla de na egación. . . . . . . . . . . . . . . . . . 31
5.4. P o o ipo de la pan alla de la cáma a. . . . . . . . . . . . . . . . . . 32
5.5. P o o ipo de la pan alla de gale ía. . . . . . . . . . . . . . . . . . . . 33
6.1. Diseño comunicación RTSP, RTP y RTCP . . . . . . . . . . . . . . . 37
6.2. P oceso de conexión de disposi i os con Wi i Awa e. [7] . . . . . . . . 39
6.3. Diag ama mul ihopping. . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.4. Diag ama pa a la ges ión de los s eams. . . . . . . . . . . . . . . . . 42
6.5. Bo óndepánico. ............................. 43
10.1.Diag amadeGan ............................. 67
i
Palab as Cla e
Wi i Awa e
D2D
And oid
RTSP
Libs eaming
Redes Ad hoc mó iles (MANETs)
s eaming de ídeo
di usión múl iple de ídeo
ii
In oducción
pod ían se ejecuciones o ac os con a los de echos humanos, los cuales se ían
ú iles g aba los pa a su denuncia in e nacional.”
O o escena io de uso de la aplicación, pa ecido al que se ha llamado Humani a-
ian, que se nos ha ocu ido es pa a eme gencias en zonas aisladas que nunca ienen
cobe u a de ele onía mó il (es deci , la al a de ed no se debe a un ca ás o e
na u al). Un ejemplo pod ía se un acciden e de escalada en una zona aislada de la
sie a de G edos.
Los obje i os iniciales de es e abajo son los siguien es:
Comp oba la idoneidad pa a nues a aplicación, de en e las opciones exis-
en es, del sis ema Wi i Awa e [7] del Wi i Alliance pa a la comunicación D2D
en e elé onos mó iles y pa a la c eación de una ed ad hoc compues a de
elé onos mó iles.
Comp oba la idoneidad pa a nues a aplicación, de en e las opciones exis-
en es, de la biblio eca de so wa e lib e libs eaming [2] pa a o ma la base
de la implemen ación del s eaming de la cáma a de ídeo y del mic ó ono de
un elé ono mó il, lo que implica ía desca a la posibilidad de basa nues a
aplicación en la implemen ación cons uida en el TFG del cu so 2020/21.
Comp oba la con eniencia pa a nues a aplicación de inco po a y adap a
las ex ensiones de libs eaming implemen ados en el TFG del cu so 2018/19
y, de es e modo, pa i de una base más adecuada pa a nues os ines que la
biblio eca o iginal.
Suponiendo la idoneidad de las ecnologías Wi i Awa e y libs eaming pa a o -
ma la base de nues a aplicación, y la con eniencia de inco po a y adap a las
ex ensiones de libs eaming implemen ados en el TFG del cu so 2018/19, los obje-
i os p incipales de es e abajo son los siguien es:
Adap a la biblio eca libs eaming a Wi i Awa e (que incluye su adap ación a
IP 6 ya que Wi i Awa e equie e es a e sión del p o ocolo IP).
Diseña e implemen a el mul ihopping de s eams en una ed ad hoc de elé-
onos mó iles c eados con Wi i Awa e.
Diseña e implemen a el en ío de s eams a múl iples des inos de una ed ad
hoc de elé onos mó iles c eados con Wi i Awa e.
Diseña e implemen a an o en el disposi i o o igen de un s eam que ansi a
po una ed de elé onos mó iles c eados con Wi i Awa e como en cualquie
disposi i o de la ed que lo ecibe (posiblemen e simul áneamen e con la e-
cepción de o os s eams) la posibilidad de isualiza lo en pan alla.
Diseña e implemen a an o en el disposi i o o igen de un s eam que ansi a
po una ed de elé onos mó iles c eados con Wi i Awa e como en cualquie
3

In oducción
disposi i o de la ed que lo ecibe (posiblemen e simul áneamen e con la ecep-
ción de o os s eams) la posibilidad de gua da lo en iche o pa a su pos e io
isualización.
Diseña e implemen a alguna o algunas de las ex ensiones que pod ían se
ú iles en uno de los escena ios de uso mencionados an e io men e.
1.3. Plan de abajo
Pa a pode lle a a cabo el p oyec o y consegui los obje i os p opues os, hemos
ealizado la plani icación que se mues a en la Figu a 1.1.
Figu a 1.1: Plan de abajo.
4
2. In oduc ion
2.1. Mo i a ion
In MANETs, nea by use s communica e di ec ly by con igu ing hei in e aces
in ad-hoc mode, o he pu pose o da a ans e , ei he di ec ly o h ough a ansi
node o edi ec a ic o o he nodes in he ne wo k. In many si ua ions such as
disas e s o eme gencies, whe e ne wo k in as uc u es p o ided by ne wo k ope-
a o s a e no a ailable, his kind o ne wo k is an ideal solu ion because i o e s
decen alized en i onmen s.
As obse ed in Sec ion 1.1 o [3], “an ad hoc ne wo k could be o med o pass
ideos and/o help messages om one de ice o ano he , un il a de ice is ound
ha has access o he in e ne , and in his way he da a sen om an a ea wi hou
connec ion will be published on he in e ne and each hei des ina ion.
Ano he possible use case o an applica ion like he one we p opose could be
o gi e he possibili y o ansmi ing ideos o dis an de ices in coun ies whe e
human igh s c imes a e commi ed, in such a way ha he ideo would pass om
one de ice o ano he bypassing he con ol and censo ship ha coun ies like hese
es ablish in con en ional ne wo ks, in addi ion o gi ing he possibili y o hiding he
o igin o he ansmission, in such a way ha he complainan can no be iden i ied.
Fo his eason, in addi ion, he applica ion should no lea e aces o he ideos,
nei he in he issuing mobiles no in hose ha edis ibu e hem. I he ne wo k is
able o c oss he censo ship zone, he ideos could be published on he in e ne wi h
he help o o ganiza ions such as Wi ness [5] ha a e dedica ed o p omo ing he
c ea ion and cus ody o ideos o his ype.”.
In pa icula , o ideo cus ody he e is he Secu eD op [6] sys em, designed
o jou nalis s o upload hei documen s o ideos o a se e on he To ne wo k
anonymously.
Mobile ad hoc ne wo ks a e becoming an impo an pa o he nex gene a ion
ne wo ks, due o hei lexibili y, sel -con igu abili y, lack o in as uc u e, ease o
main enance, sel -managemen capabili y and low cos . In his con ex , he las wo
decades ha e seen a g ea deal o esea ch in he academic communi y ega ding
mobile ne wo ks. One o he a eas o esea ch in his ield is da a ansmission o e
MANETs, his is due o he inc ease in compu a ional capaci y o sma phones and
hei g ea popula i y in oday’s socie y.
I is impo an o men ion he challenge o p o iding a ce ain quali y in he
sha ed wi eless medium and in he dynamic opology o MANETs in ela ion o he
suppo o ideo s eaming se ices in mobile ad-hoc ne wo ks. The main issues a e
5
In oduc ion
dynamic ou ing (due o mobile nodes), QoS (quali y o se ice), he need o low
ene gy use and inally secu i y o dec ease ulne abili y o a acks.
In he cou se 2019/2020 a bachelo ’s deg ee inal p ojec [4] wi h he same goal as
ou s was p oposed using Wi i Awa e o es ablish he communica ion, his p ojec did
no use a con ol p o ocol which caused la ency and a loss o quali y in he s eaming,
in addi ion o only being able o pe o m mul icas communica ion be ween pai s o
de ices so ou ing p oblems we e no con empla ed.
In he cou se 2018/2019 a bachelo ’s deg ee inal p ojec [3] was p oposed wi h
he same goal bu using Wi i Di ec , his echnology ga e p oblems in he imple-
men a ion o he desc ibed unc ionali ies bu managed o pe o m a mul icas com-
munica ion wi h con ol p o ocol be ween pai s o de ices. Wi h ou p ojec we will
sol e hese p oblems by es ablishing communica ions using Wi i Awa e, adap ing
o hese communica ions he implemen a ion o he libs eaming lib a y, oge he
wi h he modi ica ions in oduced in he bachelo ’s deg ee inal p ojec o 2018/19,
and pe o m mul ihopping and mul icas o c ea e a wide ne wo k, in addi ion o
sol ing he p oblems o he loops ha can a ise in his con ex .
2.2. Goals
The goal o he p ojec in which con ex his bachelo ’s deg ee inal p ojec and
hose o he p e ious wo yea s men ioned in Sec ion 2.1 ha e been ca ied ou is
desc ibed in Sec ion 1.2 o [3] as ollows: “design and implemen an applica ion o
mobile de ices capable o connec ing de ices o each o he wi hou using he ne wo k
in as uc u e o elecommunica ion ope a o s. Once he link be ween de ices is
c ea ed, he applica ion mus be able o s eam li e ideo om one mobile o ano he ,
which mus in u n be able o ecei e ha ideo and –play i back,” (i.e, display i
on sc een) “i he use wan s o– while being able o e ansmi he ideo o o he
de ices o which i is connec ed, hus ac ing as a ansi o y node be ween de ices
no di ec ly connec ed o each o he .”
The usage scena ios o he applica ion being de eloped h ough bachelo ’s deg ee
inal p ojec s, o which he p esen p ojec is he mos ecen , a e desc ibed in Sec ion
1.2 o [4] as ollows: “Gi en he di e en possible modes o use o he applica ion,
we ha e decided o dis inguish wo ele an scena ios depending on he en i onmen
whe e i is o be used. These a e:
Humani a ian: This scena io ocuses on cases whe e he e is no in e ne
connec ion due o non-human ac ions such as na u al disas e s o acciden al
powe ou ages. Allowing he in o ma ion o be ansmi ed om he sou ces
o such a scena io o poin s whe e he e is co e age, whe e you can ask o
help o sha e he ideos wi h he media.
Wi ness: This scena io would be ocused on si ua ions in which an opp essi e
egime limi s o censo s communica ions. Examples o such scena ios could be
6
In oduc ion
execu ions o ac s agains human igh s, which would be use ul o eco d o
in e na ional denuncia ion.”
Ano he usage scena io o he applica ion, simila o he one called Humani a ian,
ha we ha e come up wi h is o eme gencies in isola ed a eas ha ne e ha e cell
phone co e age (i.e. he lack o ne wo k is no due o a na u al disas e ). An example
could be a climbing acciden in an isola ed a ea o he G edos moun ain ange.
The ini ial goals o his wo k a e he ollowing:
Check he sui abili y o ou applica ion, among he exis ing op ions, o he
Wi i Alliance’s Wi i Awa e [7] sys em o D2D communica ion be ween cell
phones and o he c ea ion o an ad hoc ne wo k composed o cell phones.
Check he sui abili y o ou applica ion, among he exis ing op ions, o he
open-sou ce so wa e lib a y libs eaming [2] o o m he basis o he s eaming
implemen a ion o he ideo came a and mic ophone o a cell phone, which
would imply uling ou he possibili y o basing ou applica ion on he imple-
men a ion buil in he bachelo ’s deg ee inal p ojec o he 2020/21 cou se.
Check he sui abili y o ou applica ion o inco po a ing and adap ing he
libs eaming ex ensions implemen ed in he bachelo ’s deg ee inal p ojec o
he 2018/19 academic yea and, hus, s a ing om a base mo e sui able o
ou pu poses han he o iginal lib a y.
Assuming he sui abili y o Wi i Awa e and libs eaming echnologies o o m
he basis o ou applica ion, and he con enience o inco po a ing and adap ing he
libs eaming ex ensions implemen ed in he 2018/19 bachelo ’s deg ee inal p ojec ,
he main goals o his wo k a e he ollowing:
Adap he libs eaming lib a y o Wi i Awa e (which includes i s adap a ion
o IP 6 since Wi i Awa e equi es his e sion o he IP p o ocol).
Design and implemen mul ihopping o s eams in an ad hoc ne wo k o cell
phones c ea ed wi h Wi i Awa e.
Design and implemen mul icas s eaming o e an ad hoc ne wo k o cell
phones c ea ed wi h Wi i Awa e.
Design and implemen bo h in he sou ce de ice o a s eam ha ansi s
h ough a ne wo k o cell phones c ea ed wi h Wi i Awa e and in any de ice
o he ne wo k ha ecei es i (possibly simul aneously wi h he ecep ion o
o he s eams) he possibili y o displaying i on he sc een.
Design and implemen bo h in he sou ce de ice o a s eam ha ansi s
h ough a ne wo k o cell phones c ea ed wi h Wi i Awa e and in any de ice
o he ne wo k ha ecei es i (possibly simul aneously wi h he ecep ion o
o he s eams) he possibili y o sa ing i in a ile o u u e iewing.
Design and implemen one o some ex ensions ha could be use ul in one o
he abo e men ioned usage scena ios.
7
In oduc ion
2.3. Wo k plan
In o de o ca y ou he p ojec and achie e he p oposed goals, we de ined he
p ojec plan shown in Figu e 1.1.
8

3. An eceden es
3.1. Comunicación DTD
La comunicación De ice- o-De ice (DTD) es un ipo de comunicación di ec a
en e dos disposi i os mó iles, que in e cambian in o mación sin ene que a a esa
edes cen alizadas o es aciones de ele onía mó il (Base S a ions). El é mino ha
e olucionado de al o ma que se asocia a los in en os po las ope ado as de ele onía
de desconges iona y mejo a sus edes. En las edes mó iles adicionales odas
las comunicaciones deben a a esa una es ación de ele onía (BS), incluso si los
disposi i os implicados en la comunicación se encuen an p óximos.
La ecnología DTD iene un g an po encial pa a mejo a la e iciencia en el uso
de la ene gía y el espec o de ecuencias, ap o echándose de es a p oximidad en e
disposi i os. Las comunicaciones se pueden es ablece en el espec o de ecuencias
u ilizado ac ualmen e po las edes mó iles o ue a de es e, lo que ae dis in os
aspec os a ene en cuen a a la ho a de su implemen ación.
En gene al la comunicación DTD p ome e ganancias en la eu ilización del es-
pec o elec omagné ico, conec i idad a una mayo dis ancia de las es aciones de
ele onía, independencia con espec o a las edes cen alizadas y la desconges ión
de la ed g acias a los nue os caminos pa a alcanza a los disposi i os, en e o as.
Los ope ado es es án in e esados en usa es a comunicación pa a la úl ima pa e de
la conexión en si uaciones de conges ión local, po ejemplo, un e en o depo i o.
Median e el D2D se pod ía ges iona el á ico de una zona conges ionada a base de
es aciones que no es án en es a zona. P ecisamen e, si hay mucho uso de la ed de
elé ono mó il en una zona conc e a, hay muchos nodos en es a zona que pod ían
usa se pa a la comunicación D2D.
Ac ualmen e se es á in es igando cómo a on a los p oblemas [8] elacionados
con la comunicación DTD, siendo las ope ado as de ele onía mó il las más in e e-
sadas. En e ellos enemos:
La búsqueda con inua de disposi i os y se icios median e Wi i o Blue oo h
LE. U iliza medios de sinc onización pa a hace un consumo e icien e de la
ba e ía.
La adminis ación del nue o escena io de in e e encias causadas po las cone-
xiones DTD. La in oducción de es as conexiones no debe ía deg ada el uso
adicional cen alizado de la ed y es necesa io ene en cuen a que es as edes
adicionales pueden a ec a a la calidad del se icio eque ido po las DTD.
La educción del consumo ene gé ico en las a eas de descub imien o de se i-
cios y o os disposi i os.
9
An eceden es
La in eg ación de las edes DTD con las cen alizadas y su ap o echamien o
pa a ex ende el alcance de las es aciones de ele onía y añadi posibles caminos
pa a desconges iona la in aes uc u a ac ual. U ilizando disposi i os a modo
de puen e se pod ían conec a o os ue a de ango con la in aes uc u a
p incipal, algo bas an e necesa io en la ecnología 5G, que iene p oblemas
con cobe u a.
Dis inción en e disposi i os públicos y de conexión p i ada con es icciones,
así como segu idad y p i acidad en las comunicaciones.
Si se log a a soluciona es os p oblemas, es a ecnología se ía un g an apo e
pa a su uso en á eas como IoT, comunicaciones de eme gencia sin in aes uc u a o
5G incluso. A con inuación, se mues a una isión ac ual de ecnologías basadas en
la comunicación DTD.
3.1.1. Blue oo h
Es un es ánda de ecnología inalámb ica, man enido po la o ganización Blue-
oo h SIG, pa a el in e cambio de da os en e disposi i os a co a dis ancia y la
c eación de edes de á ea pe sonal (WPAN). U iliza ondas de adio de al a ecuen-
cia (UHF) en las bandas ISM (no come ciales) de 2,4GHz. Especi ica un p o ocolo
basado en paque es, con una a qui ec u a maes o/escla o que pe mi e conec a
como máximo 7 escla os a un maes o, en lo que se llama una picone .
La úl ima e sión Blue oo h 5.x pe mi e un ango de has a 500 m [9] y una elo-
cidad máxima de 2 Mbi /s [10], a un ango mucho meno . In oduce ca ac e ís icas
en ocadas al á ea del IoT [11], cen adas en la educción de consumo ene gé ico Low
Ene gy (LE) y uncionalidad o ien ada a se icios sin conexión, como se icios de
na egación en e o os. Además in oduce “Blue oo h LE Audio” [12] (2020) que in-
en a mejo a la calidad de sonido y la e iciencia ene gé ica en e los disposi i os que
se conec an pa a unciones de audio, además de pe mi i su ans e encia a a ios
disposi i os a la ez.
Es a ecnología se e ela inadecuada pa a la ansmisión de ideo y audio po
su insu icien e ancho de banda y su adio de alcance limi ado.
3.1.2. Wi i
Es una amilia de p o ocolos de ed inalámb ica pa a la capa de enlace y la capa
ísica del modelo OSI, pensados p incipalmen e pa a conec a disposi i os o mando
una WLAN. Es án basados en la amilia de es ánda es IEEE 802.11. Las conexiones
Wi i u ilizan p o ocolos de segu idad pa a e i a que se conec en e ce os a la ed
inalámb ica y pode enc ip a los da os. La más segu a y des acada en la ac ualidad
es WPA2, aunque siguen en uso o os es ánda es menos segu os como WEP o WPA.
En 2009 su gió el es ánda 802.11n, que pe mi e la comunicación a a és de
ecuencias de 2.4 y de 5GHz. Es a úl ima, al unciona en una ecuencia supe io ,
10
An eceden es
iene un meno alcance, pe o ambién pe mi e al disposi i o ope a a una mayo
elocidad, la cual oscila en e 72 y 600 Mbi /s [13]. El siguien e a ance ecnológico
ocu ió en 2014 con 802.11ac, nomb ado Wi i 5 po la Wi i Alliance, que ope a a
5Ghz o eciendo una asa de bi s de has a 6933 Mbi /s [14]. En 2019 la Wi i Alliance
publicó el bo ado de un nue o es ánda , 802.11ax, llamado Wi i 6, que p ome e
ope a en las bandas de 2.4, 5 y 6 GHz o eciendo asas de bi s en e 600 y 9680
Mbi /s, además de inco po a nue os p o ocolos de segu idad más obus os como
WPA3 [15]. Es á pendien e de se ap obado po la IEEE ac ualmen e (2020), aunque
ya exis en disposi i os que lo implemen an.
Pa a la ealización de es e p oyec o que emos c ea una ed ad-hoc en la que los
disposi i os se comuniquen di ec amen e en e sí, sin necesidad de u iliza un pun o
de acceso. Pa a ello el uso de los p o ocolos Wi i nos pa ece lo más adecuado po
sus capacidades ísicas y de di usión.
El é mino ‘Wi i’ desc ibe unos p o ocolos que pe mi en la comunicación he zia-
na en e dos disposi i os, una especie de E he ne po el ai e. Pe o el uso p incipal
de Wi i es con un pun o de acceso, o bien domés ico, o bien público. En el caso
del pun o de acceso domés ico, suelen es a combinado es unciones en un único
apa a o:
1. Pun o de acceso: po un lado, se conec a con disposi i os indi iduales po Wi i
y po o o lado, se conec a con o a(s) ed(es) (en es e caso, In e ne ) po cable
o ib a óp ica.
2. Swi ch (de una ed de á ea local, o LAN, con opología es ella): cuando e-
cibe un mensaje de un disposi i o conec ado di ec amen e al apa a o cuyo
des ina a io es o o disposi i o ambién conec ado di ec amen e al apa a o, lo
en ía al des ina a io co ec o. Si odos los nodos de la ed local se comunican
con el swi ch po Wi i, la LAN es una LAN inalámb ica (o "wi eless LAN", o
WLAN).
3. Rou e : encamina los mensajes en iados hacía, y ecibidos desde, o as edes
(LANs, WANs,...) de In e ne .
En el caso de un pun o de acceso público, no suele es a incluida la uncionalidad
de swi ch.
3.1.3. Wi i Ad-hoc mode
Es una es uc u a de ed inalámb ica basada en la ecnología Wi i, donde los
disposi i os pueden comunica se di ec amen e en e sí. Pe enece a una ca ac e ís-
ica adicional que se especi ica en la amilia de es ánda es 802.11, conocido como
conjun o de se icios básicos independien es (IBSS).
El modo Ad-hoc elimina la necesidad de u iliza un pun o de acceso, pe mi iendo
la comunicación di ec a en e disposi i os. Es e modo es u ilizado pa a si uaciones
donde es necesa io una comunicación ápida y e icien e, se suele usa en g upos
11
An eceden es
pequeños donde el p opósi o p incipal de la conexión es compa i a chi os. Es e
ipo de edes descen alizadas son ípicamen e más obus as, debido a los múl iples
caminos que o ecen pa a anspo a in o mación. La p obabilidad de que se caiga
la ed po un allo en un pun o se educe signi ica i amen e. Cuen a además con
mayo lexibilidad y escalabilidad que edes cen alizadas, al no ene una opología
ija.
Es as es uc u as aún se encuen an en desa ollo y no ienen un uso muy ex-
endido debido a los e os que plan ean, como una mayo complejidad en la comu-
nicación, posibles educciones en el endimien o a causa de la opología dinámica,
un excesi o uso de ene gía en e o as. Po es as azones y po la p og amación a
más bajo ni el que da ía p oblemas con ac ualizaciones del sis ema ope a i o y el
descub imien o ine icien e, no es ú il pa a el desa ollo de es e p oyec o.
Es ánda es como Wi i Di ec y Wi i Awa e buscan supe a es as limi aciones
haciendo uso de es e modo pa a c ea conexiones inalámb icas Pee o Pee en e
disposi i os mó iles, o mando MANETs, Mobile Ad hoc ne wo ks.
3.1.4. Wi i Di ec
Es un es ánda diseñado pa a la comunicación Pee o Pee , en el que los usua ios
pueden in e cambia a chi os de o ma inalámb ica sin necesidad de un en u ado
cen al pa a o ganiza el á ico y ansmi i los paque es. A di e encia de Blue oo h,
el in e cambio de da os se ealiza a g an elocidad, pudiendo se has a diez eces
más ápido.
Es a ecnología si e pa a la imp esión inalámb ica, e ansmisión de u pan alla
en o o disposi i o, compa ición de pan alla o incluso pa a explo a al máximo las
uncionalidades del NFC pa a el p oceso de descub imien o y de ección de o os
disposi i os.
La ecnología de Wi i Di ec o ece a los disposi i os compa ibles una o ma de
descub i y conec a se de o ma segu a median e WPS y WPA2. Cuando a ios dis-
posi i os se conec an o man un g upo, el cual iene un P opie a io de G upo que
ac úa como swi ch (y posiblemen e ambién como pun o de acceso y ou e ) de una
WLAN con opología es ella o mado po odos los disposi i os del g upo. Solamen-
e el P opie a io de G upo necesi a implemen a el es ánda pa a que sea posible la
conexión, ambién puede hace la unción de puen e con edes con in aes uc u a y
así do a de acceso a in e ne a los disposi i os del g upo.
En 2011, Google implemen ó Wi i Di ec en And oid 4.0 de o ma na i a po lo
que cualquie disposi i o And oid en la ac ualidad dispone de es a ecnología. Wi i
Di ec pa ece una buena solución pa a abaja con MANETs, po su asa de bi s
y su inco po ación en la mayo ía de disposi i os mó iles, pe o conside amos que no
lo es pa a nues a aplicación de s eaming.
12
An eceden es
de ideo, sob e los p incipales na egado es web, como Sa a i, Ch ome, Fi e ox, e c.
Sopo a ídeo, oz y con enido mul imedia, que pe mi e a los usua ios inco po a i-
deocon e encias a cualquie se icio web y c ea po en es soluciones de colabo ación
de ídeo basadas en la ecnología WebRTC.
Pa a que es e p o ocolo ans ie a da os en iempo eal, es os deben se ci ados
con an e io idad median e DTLS (Da ag am T anspo Laye Secu i y), que es á di-
señado pa a p o ege la p i acidad de las comunicaciones e in eg ado en la mayo ía
de los na egado es que sopo an WebRTC . Además los da os de ídeo y audio am-
bién se enc ip an usando o o mé odo llamado SRTP (Secu e Real-Time P o ocol).
De es a mane a se ga an iza una comunicación segu a en iempo eal.
En la ac ualidad es a ecnología pe mi e a a los lujos de ídeo y audio en un
na egado mode no sin ene la necesidad de usa una aplicación especi ica, además
es á ganando e eno muy ápidamen e y se p opone e oluciona los es ánda es de
comunicación.
Finalmen e, es eseñable menciona que WebRTC sin na egado cons i uye o a
al e na i a pa a nues o p oyec o. Google dis ibuye la lib e ía libweb c, aunque
desde el p incipio de 2020 no lo hace de o ma p ecompilada pa a And oid [27]. Hay
a ias emp esas o eciendo SDKs pa a usa WebRTC en And oid sin na egado ,
muchas de es as o e as es án basadas en libweb c [28].
3.3.2. VLC
Es un ep oduc o mul imedia de código abie o [29] con e siones pa a muchos
sis emas ope a i os, capaz de ep oduci dis in os o ma os de ídeo sin la necesidad
de ins alación de códecs ex e nos.
Pa a emi i un s eam RTP incluye una lib e ía llamada Li eMedia de un g upo
denominado Li e555, pe o es a lib e ía es inmadu a y no exis e implemen ación en
And oid. Además, las páginas de Li e555 es án ue a de se icio desde hace años
[30].
3.3.3. FFmpeg
FFmpeg es una colección de so wa e lib e desa ollada en GNU/Linux que puede
se compilada casi po cualquie sis ema ope a i o que pe mi e g aba , con e i y
hace s eaming de ídeo y audio. La pa e que concie ne a la emisión de s eams
es á bas an e poco desa ollada [31] y con poca documen ación [32].
3.3.4. Gs eame
GS eame es un amewo k mul imedia esc i o en el lenguaje de p og amación
C que pe mi e ep oduci lujos de ídeo y audio en e o as. Aunque exis e en
And oid, la pa e que concie ne a la emisión de s eams es á muy poco documen ada,
en pa icula , el uso de SDP.
19

An eceden es
3.3.5. Libs eaming
Libs eaming [2] es una lib e ía que nos pe mi e ealiza ácilmen e la ansmisión
de ídeo y audio de un disposi i o con And oid usando el p o ocolo RTP sob e UDP.
Además, incluye codi icado es compa ibles como H.264 (pa a el ídeo) y AAC (pa a
el audio).
Es no able menciona que ningún o o so wa e lib e de es e ipo ha enido el
uso ex endido que ha enido libs eaming. U iliza una licencia Apache 2.0 lo cual
nos pe mi e la libe ad de usa es e so wa e pa a cualquie p opósi o, dis ibui lo,
modi ica lo y dis ibui e siones modi icadas de es e.
20
4. Elección de ecnologías
4.1. And oid
Como el desa ollo de es e p oyec o es una aplica-
ción pa a disposi i os mó iles, la cual equie e un g an
núme o de nodos pa a consegui un ánsi o adecuado
del s eam y de es a mane a que pueda cumpli con su
p opósi o, hemos op ado po usa And oid ya que según
los da os de mediados de 2020 se pe cibe una asa de
u ilización del 86.1 % [33], además de la amplia docu-
men ación que podemos encon a sob e ello.
Po consiguien e, el sis ema ope a i o que u iliza-
emos es And oid 9+ que da sopo e con su API a la
ecnología WiFi Awa e y es el que u ilizan los disposi i os con los que amos a
ealiza las p uebas, lo que acili a el desa ollo de es e p oyec o.
4.2. WiFi Awa e
Hemos elegido WiFi Awa e po a ias azones, la p ime a es que añade a la
conexión Wi i es ánda la posibilidad de comunica se y busca o os disposi i os
apo ándonos más acilidad y un bajo consumo de ene gía. O a de las azones
es que que emos mejo a la aplicación que ealiza on nues os compañe os el año
pasado usando es a ecnología e in en a soluciona los p oblemas que plan ea on.
4.3. Ja a
Ja a es un lenguaje de p og amación mul ipla a o ma y o ien ado a obje os. Al
igual que Ko lin, es uno de los lenguajes más usados pa a el desa ollo de aplica-
ciones And oid ya que unciona en p ác icamen e cualquie disposi i o, además nos
p opo ciona mayo obus ez ya que nos o ece manejo au omá ico de la memo ia.
Una de las p incipales azones po la cual nos hemos decan ado a usa Ja a es
po la eno me can idad de uncionalidad base que disponemos pa a se u ilizada,
además de que la mayo pa e de in o mación que disponemos sob e Wi i Awa e
es á disponible en es e lenguaje.
4.4. And oid S udio
21
Elección de ecnologías
Debido a la u ilización de And oid como sis ema
ope a i o pa a el desa ollo del p oyec o, hemos elegido
And oid S udio, que es el en o no de desa ollo o icial
de aplicaciones And oid. Además de pode p oba la
aplicación de o ma i ual y en nues os disposi i os í-
sicos que disponemos pa a el p oyec o, nos p opo ciona
ambién la posibilidad de c eación de in e aces g á icas
de o ma isual. Todo es o nos p opo ciona una g an
acilidad a la ho a de desa olla la aplicación de es e
p oyec o.
4.5. RTP sob e UDP
RTP es el p o ocolo de anspo e de lujos mul imedia en iempo eal que u iliza-
mos. Hemos elegido es e p o ocolo debido a que es de los más u ilizados en sis emas
de e ansmisión de ídeo y audio. Además es e p o ocolo es usado po la lib e ía
“libs eaming” que ha sido la elegida pa a la ealización del p oyec o.
TCP es un es ánda pa a el uso de RTP pe o en es e caso no hemos decidido
u iliza lo po que debido a los mecanismos de con ol de conges ión que es e ealiza,
nos alen iza á la ansmisión del s eam, po es e mo i o hemos elegido UDP ya
que en se icios de s eaming la pé dida de algún paque e del en ío es insigni ican e
y nos demo a a menos la en ega de da os.
4.6. RTSP y SDP
Pa a el en ío de in o mación en e clien e y se ido , hemos decidido usa RTSP
con RTP sob e UDP pa a in en a consegui una ansmisión de ídeo y audio lo
más e icien e posible con olando es os lujos de mane a sinc onizada. Las pe iciones
RTSP que se ealizan son:
OPTIONS: Suele en ia se al inicio pa a es ablece los pa áme os necesa ios
como el núme o que se asigna, la e sión del se ido o los mé odos sopo ados
po es e.
DESCRIBE: Se enca ga de inicializa la sesión u ilizando la desc ipción del
lujo necesa io pa a la ep oducción.
SETUP: Especi ica los pa áme os de anspo e como los pue os y el p o-
ocolo a u iliza .
PLAY: Indica cuándo se debe inicia la ansmisión de da os u ilizando los
pa áme os especi icados en el SETUP.
PAUSE: De iene de o ma empo al el lujo de da os.
TEARDOWN: De iene po comple o el lujo de da os y libe a los ecu sos.
22
Elección de ecnologías
GET_PARAMETER ySET_PARAMETER: Se u iliza pa a ecupe a
o es ablece algún pa áme o del lujo de ideo o audio que se es á ansmi-
iendo.
REDIRECT: Se u iliza pa a in o ma al clien e que el se ido ha cambiado
de di ección.
Cabe menciona que RTSP u iliza SDP pa a ealiza la negociación de los pa á-
me os pa a la en ega de los lujos de ídeo y audio, po ese mo i o u iliza emos
es e p o ocolo pa a desempeña la unción mencionada an e io men e.
4.7. Libs eaming
Hemos decidido u iliza es a lib e ía ya que nos pe mi e con pocas líneas de
código ealiza la ansmisión, además implemen a pa e del p o ocolo RTSP y pa -
imos del código que ealiza on los alumnos de 2018/2019, los cuales hicie on algu-
nas ex ensiones muy ú iles que pod emos ap o echa pa a nues a aplicación. Las
o as al e na i as mencionadas en la sección an e io no ealizan bien la emisión de
s eams.
4.8. LibVLC
Pa a ges iona el con enido mul imedia, amos a
u iliza libVLC, que nos p opo ciona una g an cali-
dad y lexibilidad a la ho a de ep oduci y gua da
los s eams. Es a biblio eca de código abie o iene una
licencia LGPL2.1.
Hemos desca ado FFmpeg ya que es á a más bajo
ni el (VLC u iliza FFmpeg) y espec o a GS eame , es
debido a que nos ha esul ado más ácil la in eg ación
de VLC en el p oyec o.
4.9. Balsamiq Wi e ames
Balsamiq Wi e ames es una he amien a que nos pe mi e c ea el diseño de las
in e aces de usua io de o ma ápida y sencilla pa a nues a aplicación, además nos
o ece un complemen o pa a Google D i e pa a pode usa la de o ma colabo a i a.
4.10. Gi Hub
23
Elección de ecnologías
Gi Hub es una de las p incipales pla a o mas pa a
la c eación de p oyec os de so wa e lib e que se ca ac-
e iza po sus unciones colabo a i as que pe mi en a
los usua ios apo a ideas o modi icaciones sob e ellos.
La web u iliza el sis ema de con ol de e siones Gi
que acili a a los desa ollado es adminis a su p oyec-
o, lle ando un egis o de cambios en los a chi os que
pe mi e e las di e encias en e ellos e incluso usiona
las dis in as e siones.
Pa a el desa ollo de es e p oyec o hemos u ilizado un eposi o io alojado en
Gi Hub pa a pode abaja de o ma colabo a i a educiendo de es a mane a el
núme o de con lic os que puedan ocasiona se.
4.11. LaTeX y O e lea
LaTeX es un sis ema de composición de ex os,
o ien ado especialmen e a la c eación de lib os, a ícu-
los y documen os cien í icos p opo cionando una al a
calidad p o esional. Una de las p incipales en ajas es-
pec o a o os edi o es más con encionales es que nos
pe mi e sepa a cla amen e el con enido y el o ma o
del documen o, además de p opo ciona nos g an ayuda
pa a la ges ión del índice y la bibliog a ía.
O e lea es un edi o colabo a i o basado en la nube que se u iliza pa a esc ibi y
edi a documen os en LaTeX, compila el código de mane a au omá ica mos ando los
esul ados simul áneamen e y no necesi a la ins alación de paque es. Po odas es as
acilidades que nos p opo cionan es as dos ecnologías, hemos decidido u iliza las
pa a la ealización de es a memo ia.
24

5. Especi icación
La idea p incipal de la aplicación es consegui ealiza una ansmisión de ídeo
y audio en e dos o más disposi i os mó iles, c eando una ed ad-hoc median e Wi i
Awa e sin pasa po una in aes uc u a ija que nos pe mi a compa i el s eam
has a un disposi i o que enga conexión a in e ne o que pueda cus odia el ídeo
con segu idad.
Pa a pode ealiza una ansmisión enemos que de ini es ipos de modos que
son los que usa án los disposi i os conec ados pa a pode in e acciona con el es o:
Modo “emiso ”: Se enca ga de ansmi i el ídeo y audio p oducido po la
cáma a y mic ó ono del p opio disposi i o a a és de la ed c eada median e
Wi i Awa e.
Modo “ ecep o ”: Se enca ga de ecibi el s eam de la MANET.
Modo “dual”: Se enca ga de ealiza la unción de un ou e básico, es deci ,
ecibe un s eam y simul áneamen e lo emi e hacia un e ce disposi i o.
Pa a pode cumpli con los obje i os del p oyec o, y dado que amos a usa un
p o ocolo dis in o al que idea on los miemb os del p oyec o del TFG del año pasado,
debemos con empla los siguien es hi os en los que se di idi á nues a aplicación.
T ansmisión de ídeo y audio a a és de Wi i Awa e (modo emiso ).
Recepción de ídeo y audio (modo ecep o ).
T ansmisión de ídeo y audio ecibido de o o disposi i o hacia un e ce dis-
posi i o (modo dual).
T ansmisión de ídeo y audio ecibido de o o disposi i o hacia múl iples dis-
posi i os ( ou e simple).
Recepción y ansmisión de múl iples lujos de ídeo a múl iples disposi i os
( ou e comple o).
Pe mi i la isualización de los s eams.
Gua da los s eams en la memo ia del disposi i o, pa a una pos e io isua-
lización.
Emisión del ídeo y audio a un pun o de acceso Wi i o a una es ación base de
la ed de ele onía mó il.
25
Especi icación
5.1. Requisi os
En cuan o a los equisi os de la aplicación debemos conside a ambos escena ios
pa a los que puede unciona nues a aplicación:
“Humani a ian”: Pa a casos de desas e y de eme gencia emo a en los que
no es posible conec a se a la in aes uc u a de ed po azones imp e is as.
“Wi ness”: En ocado en denuncia iolaciones o ac os op esi os de los de-
echos humanos en luga es donde no es aconsejable accede po que pod ía
aca ea un iesgo pa a la segu idad de la pe sona o un e ce o impide el ac-
ceso a la in aes uc u a de ed. En es e escena io la p i acidad del usua io es
esencial pa a su segu idad. No se pueden ansmi i me ada os que pe mi an
iden i ica al c eado del s eam.
Pa a de ini los equisi os amos a u iliza una me odología ágil basada en his-
o ias de usua io. Pa a cen a nos en odas las uncionalidades comunes que puede
ene nues a aplicación en ambos escena ios, amos a di idi los en los siguien es
apa ados:
Inicio de la aplicación:
Como usua io, quie o pode comp oba la disponibilidad de Wi i Awa e en mi
disposi i o mó il pa a pode usa la aplicación.
Como usua io quie o concede los pe misos que sean necesa ios pa a pode
u iliza la aplicación.
T ansmisión del s eam:
Como usua io, quie o ab i el mic ó ono y la cáma a del disposi i o pa a inicia
una e ansmisión de ídeo y audio
Como usua io, quie o inicia el s eam pa a di undi lo po la ed ad-hoc de
Wi i Awa e.
Nodo de ansi o:
Como usua io, quie o que los s eams ecibidos se een íen a o os nodos pa -
icipan es
Visualiza un s eam que se ha ecibido:
Como usua io, quie o e un lis ado de los lujos de ídeo y audio disponibles
que he ecibido de o os usua ios.
Como usua io, quie o ab i un s eam pa a p ocede a isualiza lo.
Gua da el s eam cap u ado en el disposi i o:
Como usua io, quie o gua da los s eams que he ealizado, si lo conside o
opo uno, pa a ene una copia de ellos en el disposi i o mó il.
Gua da el s eam ecibido de o o disposi i o:
Como usua io, quie o gua da los s eams que he ecibido, si lo conside o
opo uno, pa a ene una copia de ellos en el disposi i o mó il.
26
Especi icación
S eams gua dados:
Como usua io, quie o e un lis ado de los s eams que he gua dado.
Como usua io, quie o selecciona un s eam de los que se han gua dado pa a
pode isualiza lo.
Como usua io quie o elimina de ini i amen e un s eam de los que se han
gua dado.
Subi el s eam a in e ne :
Como usua io con conexión a in e ne , quie o subi los s eams que es oy e-
cibiendo a in e ne .
Como usua io con conexión a in e ne , quie o subi los s eams que he gua -
dado en mi disposi i o mó il a in e ne .
A con inuación mos amos los equisi os uncionales que ca ac e izan a cada
escena io:
1. “Humani a ian”:
Como usua io, quie o pixela las ca as pa a p o ege la iden idad de las pe -
sonas que es oy g abando.
Como usua io, quie o selecciona un des ino pa a en ia el s eam a un dispo-
si i o conc e o.
2. “Wi ness”:
Como usua io, quie o pode ocul a mi iden idad en odo momen o pa a e i a
u u as epe cusiones.
Bo ón de pánico:
Como usua io, quie o elimina los da os almacenados en la aplicación
median e la acción de un bo ón ex e no.
Como usua io, quie o sali y elimina de ecien es la aplicación median e
la acción de un bo ón ex e no.
Como usua io, quie o elimina de ini i amen e la aplicación median e la
acción de un bo ón ex e no.
5.2. P o o ipo
En cuan o al diseño de la aplicación, as la ealización de los boce os en papel
hemos c eado un diseño de mayo calidad de la is a de la in e az g á ica que
mos amos en es a sección. Decidimos segui una se ie de p incipios que desc ibimos
a con inuación pa a c ea una expe iencia de usua io sa is ac o ia.
En la is a inicial de la aplicación se mues an los dos escena ios de uso pa a la
aplicación, una ez seleccionado el conside ado apa ece la is a p incipal donde se
mues an los lujos de ídeo y audio disponibles, donde hemos aplicado el p incipio
de igualdad [34] pa a des aca una de las uncionalidades p incipales de la aplicación,
mos ando los s eams que compa en an o colo es como amaño y o ma, de es a
mane a des acamos es e con enido po encima del es o dándoles un colo más i o
27
Especi icación
y un amaño dis in o. Además hemos aplicado el p incipio de cie e cuando exis en
demasiados s eams, es os elemen os no se mues an comple os y el usua io puede
llega a imagina como son, comple ando la in o mación isual que al a. Finalmen e
usando el p incipio de p oximidad podemos e es bloques que son: la in o mación
del disposi i o, los lujos de ídeo y audio comen ados an e io men e y el bo ón de
inicia un s eam, donde el usua io los pe cibi á po sepa ado.
En cuan o al menú de la aplicación hemos decidido aplica el p incipio de di ec-
ción común debido a que los elemen os cons uyen un pa ón y lujo idén ico, es os
se pe ciben como un conjun o y nos pe mi e da le una je a quía y una cohesión al
con enido.
Finalmen e hemos c eado las is as de g abación donde según el modo de uso
seleccionado, se solici a á el nomb e del s eam o no an es de inicia la g abación,
además de las is as de gale ía y ajus es que nos pe mi en isualiza los lujos de
ídeo y audio que hemos ido gua dando en el disposi i o y gua da las p e e encias
del usua io espec i amen e.
28
Diseño
Se ingF agmen : Se enca ga de mos a al usua io las p e e encias de
la aplicación pe mi iendo su edición. En ellas des acamos las del bo ón
de pánico, que se explica en más de alle en la Sección 6.5, el cual nos
pe mi e sali y qui a la aplicación de ecien es, elimina odos los da os
de es a o desins ala oda la aplicación.
In oF agmen : Se enca ga de mos a al usua io la in o mación de uso
de la aplicación.
3. S eamAc i i y: Es la ac i idad que se enca ga de mos a una p e isuali-
zación de la cáma a, así como un bo ón pa a inicia y inaliza la cap u a de
los da os de la cáma a y mic ó ono.
4. ViewS eamAc i i y: Es a ac i idad se enca ga de isualiza un s eam
usando libVLC. Es imp escindible pa a mos a an o un s eam que se es-
á ecibiendo como los que es án gua dados en el disposi i o.
5. Exi Ac i i y: Es a ac i idad se enca ga de sali de la aplicación y es u ilizada
únicamen e po el bo ón de pánico.
6.2. Ges ión de las conexiones RTSP, RTP y RTCP
Pa a ges iona las conexiones en el se ido , u ilizamos la API de Ja a NIO que
u iliza Se e Socke Channel ySocke Channel. Es as clases nos pe mi en ene
conexiones no bloquean es pa a p ocesa los da os. Además, u ilizamos la clase Ja a
NIO, Selec o , pa a ges iona las pe iciones de los clien es en un solo h ead, al con-
a io de o as me odologías que p opo cionan un h ead po clien e pa a ges iona
su comunicación.
Debido al uncionamien o de Wi i Awa e en elación con la c eación de las cone-
xiones, desc i o en la Sección 6.3.1, se necesi a u iliza un socke o canal que p ocese
e en os de ipo “accep ” po cada pa eja de disposi i os, es deci , un Se e Socke Channel
po cada disposi i o clien e.
A con inuación amos a explica el se ido RTSP que implemen a libs eaming
y que ue modi icado po los alumnos de 2018/19 c eando las siguien es clases.
La clase RTSPSe e Selec o se enca ga de c ea los Se e Socke Channel
y de egis a los en el Selec o pa a ecibi e en os de ipo “accep ”. De
es a o ma cuando un clien e se quie e conec a con el se ido , se c ea á un
Socke Channel y se egis a á en el Selec o pa a ecibi e en os de ipo
“ ead”.
La clase RTSPSe e Wo ke enca gada de a a los da os del p o ocolo RTSP
en iados po un clien e al se ido . En es a clase se u iliza un h ead pa a-
lelo pa a no añadi e a dos en las conexiones e i modi icando el es ado del
se ido según las pe iciones que se an ealizando en la comunicación RTSP.
Cabe des aca que hemos enido que modi ica el modo ep oduci sob e un
35

Diseño
s eam con o igen en el p opio disposi i o, lo cuál se ex iende en de alle en la
Sección 7.1.
En cuan o al clien e RTSP que nos p opo ciona libs eaming, solo puede u iliza
la modalidad publica , e la Sección 3.2.3, sob e un s eam con o igen en el mismo
disposi i o, po lo que hemos enido que amplia lo pa a que sea capaz de publica
un s eam p oceden e de o o disposi i o. En cuan o a la modalidad ep oduci , que
no ha sido elegida pa a la comunicación RTSP en e disposi i os de es e p oyec o,
decisión que se explica en el apéndice A.2, ampoco es á implemen ada po libs ea-
ming ni po los alumnos de 2018/19 pe o se a necesa ia pa a la isualización y/o
gua dado de los s eams. En la Sección 7.1 se explica á en de alle que modalidades
es án implemen adas en el código del que pa imos así como la adición/modi icación
de es as.
Los Se e Socke Channel y los Socke Channel se c ean de una o ma espe-
cial pa a usa los sob e Wi i Awa e. Al llama al mé odo addNewConnec ion del
se ido RTSP, con la Disco e ySession y el Pee Handle que p opo ciona la
API de Wi i Awa e pa a iden i ica al disposi i o del o o ex emo, se c ea á un
Se e Socke Channel pa a a ende le. Es a o ma de conexión es á desc i a en la
Sección 6.3.1. El diag ama UML de las clases desc i as an e io men e se puede ob-
se a en la Figu a 6.1.
U ilizamos dis in as clases como la Recei eSession yReb oadcas Session que
nos p opo ciona on los alumnos de 2018/19 y hemos enido que adap a las a IP 6,
además de modi ica el obje o Session que nos p opo ciona libs eaming pa a que
pueda u iliza se de o ma múl iple con a ios des inos. Es as clases se u ilizan pa a
ep esen a y con ola los en íos de un lujo mul imedia basado en RTP y RTCP.
Dependiendo del o igen y el des ino u ilizamos una u o a:
Session:Des inada al en ío del lujo de ídeo y audio gene ado po el dispo-
si i o.
Recei eSession:Des inada a la ecepción de un lujo de ídeo y audio gene-
ado po o o disposi i o.
Reb oadcas Session:Des inada al een ió de un lujo de ídeo y audio ge-
ne ado po o o disposi i o.
La Recei eSession o ece el se icio de usa los se ido es UDP mos ados en
el diag ama de la Figu a 6.1 pa a el een ío de los lujos ecibidos. Cuando se c ea
y con igu a, ecibe en sus socke s el lujo mul imedia y, median e los se ido es
UDP que u iliza, p opo ciona mé odos pa a añadi socke s y een ia les el lujo. La
Reb oadcas Session hace uso de es e se icio.
36
Diseño
Figu a 6.1: Diseño comunicación RTSP, RTP y RTCP
37
Diseño
6.3. Funcionamien o de Wi i Awa e
Wi i Awa e es una ecnología que pe mi e la conec i idad de ice- o-de ice en e
disposi i os mó iles sin la necesidad de conexión a una in aes uc u a de ed a a és
de un pun o de acceso wi i o una es ación base de ele onía mó il. La ecnología se
enca ga de descub i au omá icamen e disposi i os y se icios de o ma con inua en
segundo plano. Los disposi i os pueden es ima de o ma p ecisa la dis ancia con
espec o a o os y ealiza acciones au omá icas en base a esa es imación, como un
in e cambio de da os basado en el p o ocolo IP.
Wi i Awa e dis ingue a los disposi i os que publican un se icio, los publishe s,
y los que se susc iben a uno, los subsc ibe s. Un nodo hace “publish” pa a anuncia
un se icio y “subsc ibe” pa a encon a un se icio. Una ez es ablecida la conexión
se pueden in e cambia mensajes usando la API de Wi i Awa e o es ablece una
conexión basada en IP 6. Además, un disposi i o puede se publishe ysubsc ibe
a la ez, lo que pe mi e asociaciones en e disposi i os más complejas.
Pa a conec a disposi i os en e sí, el se icio en segundo plano de Wi i Awa e
pasa po 3 e apas que desc ibimos a con inuación y podemos e en la Figu a 6.2:
1. Descub imien o de disposi i os ecinos: Un disposi i o con Wi i Awa e
descub e a o os e in e cambian in o mación en e ellos.
2. Sinc onización: El disposi i o c ea o se une a un g upo de o os disposi i os
pa a sinc oniza el en ío de mensajes en e ellos. La comunicación se ija a
pe iodos de iempo y canales especí icos pa a educi el consumo ene gé ico.
3. Descub imien o de se icios: Una aplicación en el disposi i o c ea una
sesión de subsc ibe pa a encon a se icios y/o una sesión de publishe pa a
publica su p esencia y se icios. Se puede ealiza de dos mane as que amos
a explica a con inuación:
“Ac i e subsc ibe - solici ed publish”: El subsc ibe en ía mensajes de bús-
queda de se icio, mien as el publishe escucha los mensajes y con es a
a los que buscan un se icio, que ma chea con el se icio que él o ece.
Es o se puede en ende mejo median e la siguien e analogía:
Subsc ibe : “¿Hay un médico en la sala? ”
Publishe : “Sí, aquí es oy”
“Passi e subsc ibe - unsolici ed publish”: El publishe en ía mensajes de
anuncio de se icio, mien as el subsc ibe escucha los mensajes y con es a
a los que anuncian un se icio que ma chea con el se icio que él busca.
Es o se puede en ende mejo median e la siguien e analogía:
Publishe : “El cha a e o, el cha a e o...”
Subsc ibe : “Pa a, pa a, engo algo pa a í”
38
Diseño
(a) Descub imien o de
clus e (b) Sinc onización
(c) Descub imien o de
se icio
Figu a 6.2: P oceso de conexión de disposi i os con Wi i Awa e. [7]
6.3.1. C eación de conexiones con Wi i Awa e
Pa a c ea una conexión clien e-se ido en e disposi i os mó iles a a és de
Wi i Awa e hemos c eado una sesión publishe de Wi i Awa e en el disposi i o donde
ejecu a á un se ido RTSP (es deci , es e disposi i o o ece el se icio: se ido -
RTSP-en-modalidad-publica lis o pa a ecibi s eams) y una sesión subsc ibe Wi i
Awa e en el disposi i o donde ejecu a á un clien e RTSP (es deci , es e disposi i o
quie e usa el se icio se ido -RTSP-en-modalidad-publica que o ece el publishe
Wi i Awa e pa a pode en ia s eams a es e se ido RTSP), de es a o ma cuando
se ealice el p oceso de descub imien o el clien e puede en ia el s eam al se ido
con la modalidad publica , la cual se ha explicado en de alle en la Sección 3.2.3. El
p oceso que hay que segui en de alle pa a la c eación de la conexión se explica en
apéndice A.3.
6.3.2. Ges ión de Wi i Awa e
Pa a con ola oda la conec i idad en elación con Wi i Awa e, hemos c eado
una clase llamada Wi iAwa eViewModel. Es a clase nos o ece p incipalmen e una
in e az pa a publica y susc ibi nos a se icios de Wi i Awa e. También, como Wi i
Awa e puede cambia su disponibilidad en unción de la ac i ación de la ubicación y
el Wi i, incluimos un callback pa a no i ica a la GUI u o as clases de es os cambios.
La clase Wi iAwa eViewModel se enca ga además de ges iona las conexiones
en e pa ejas de disposi i os de mane a secuencial, ya que se encon ó un p oblema al
no lle a un con ol sob e es o. Es a ges ión secuencial de las conexiones se ex ende á
en la Sección 7.2. Los mensajes que se in e cambian los publishe s ysubsc ibe s a la
ho a de publica y susc ibi se a se icios se desc ibe en de alle en el apéndice B.4.
Pa a pode ealiza el en ió múl iple, o mul icas , es necesa io c ea un se ido
RTSP en el publishe y c ea clien es RTSP en los subsc ibe s según se conec en
a o os publishe s. Una ez el subsc ibe descub e un publishe , iniciamos odo el
p oceso de conexión especi ico de Wi i Awa e, desc i o en de alle en el apéndice A.3,
cuya lógica es á implemen ada den o del se ido y clien e RTSP.
39
Diseño
6.4. Diseño o ien ado al Mul ihopping
En es a sección se explica el diseño que hemos implemen ado pa a consegui que
un disposi i o sea capaz de ecibi un s eam y een ia lo a odos los disposi i os de
los que es á susc i o, de es a mane a conseguimos que el s eam ci cule po la ed
ad-hoc.
Pa a consegui el mul ihopping, conside amos necesa io que cada disposi i o en-
ga una sesión de publishe ysubsc ibe de Wi i Awa e como se obse a en la Figu-
a 6.3.
Figu a 6.3: Diag ama mul ihopping.
Siguiendo es e diseño, el disposi i o unciona como se ido RTSP y clien e RTSP
a la ez pa a pode ansmi i el s eam en la modalidad publica (Sección 6.3.1).
La sesión de publishe iene asociado un se ido RTSP. Cuando una sesión de
subsc ibe de o o disposi i o descub e la de publishe , in en a á c ea una conexión
de Wi i Awa e. Si es a conexión se es ablece co ec amen e, se c ea un clien e RTSP
pa a comunica se con el se ido del publishe .
6.4.1. Iden i icación de los s eams en la ed dis ibuida
En las edes dis ibuidas como las MANETs, la iden i icación de ecu sos com-
pa idos no se puede esol e de la misma o ma que en una ed cen alizada. En es e
ipo de edes no enemos un pun o cen alizado donde publica nues os ecu sos y
40

Diseño
donde gene a un iden i icado único eniendo en cuen a los que ya exis an en la ed.
En nues o caso pa a iden i ica cada s eam u ilizamos un UUID, Uni e sal Unique
Iden i ie , que es un núme o de 128 bi s gene ado de al o ma que la p obabilidad
de que se c een dos idén icos es an baja que es desp eciable.
Exis en ac ualmen e a ias e siones de UUID. En la e sión 1 y 2 se u iliza la
di ección MAC del disposi i o y la echa y ho a, en la e sión 3 y 5 se gene an a
pa i de aplica una unción hash a un nomb e, MD5 y SHA1 espec i amen e, y en
la e sión 4 se gene a de o ma alea o ia. La e sión que u ilizamos es la 4, ya que la
1 y la 2 pod ían comp ome e la con idencialidad del modo “Wi ness” (Sección 5.1),
al pode ex ae la di ección MAC, la echa y la ho a pa a iden i ica al c eado del
s eam. Es e iden i icado lo u ilizamos en las URI del p o ocolo RTSP pa a que el
clien e o el se ido iden i iquen el s eam en sus mensajes.
6.4.2. Ges ión cen alizada de los s eams en el disposi i o
Pa a consegui implemen a el een ío de los s eams siguiendo nues a in aes-
uc u a de ed, es con enien e ag upa la ges ión de los s eams ecibidos po el
se ido RTSP de un disposi i o, más el s eam gene ado po la cáma a y mic ó ono
del p opio disposi i o, en su caso, en una sola clase, con el in de acili a el acceso
a ellos po pa e de los dis in os clien es RTSP del disposi i o. Pa a ello c eamos
una clase llamada S eamingReco d, que se a a usa con o me al pa ón Single on
y con iene una ep esen ación de los s eams con odo lo necesa io pa a een ia los
a o o disposi i o o isualiza los. En ella se almacenan los iden i icado es únicos de
cada uno de ellos jun o con, en el caso de los s eams ecibidos una Recei eSession
y en el caso del s eam c eado en el disposi i o un obje o SessionBuilde pa a
c ea obje os Session.
En la clase S eamingReco dObse e es án de inidos callbacks pa a no i ica de
los cambios de disponibilidad en los s eams. Al implemen a es a in e az, los clien es
RTSP, se án no i icados de la exis encia de nue os s eams que a ecibiendo el
se ido y pod án een ia los. Podemos obse a el diag ama UML en la Figu a 6.4.
6.5. Aplicación del bo ón de pánico
En cuan o a la aplicación del bo ón de pánico, ealizamos un o k de “Ripple”, un
p oyec o de un g upo de desa ollado es (Gua dian P ojec ) que c ean aplicaciones
mó iles segu as y de código uen e abie o. Ripple es un “bo ón de pánico” que en ía
mensajes de ac i ación a cualquie aplicación que sea un “ espondedo de pánico”
las cuales pueden eacciona a es os e en os.
El bo ón de pánico es de g an u ilidad en el escena io de uso wi ness, donde
en caso de eme gencia como la cap u a del disposi i o po pa e del égimen op e-
si o, se pe mi e al usua io deshace se de cualquie as o que pueda inc imina lo,
espaldando así su segu idad.
41
Diseño
Figu a 6.4: Diag ama pa a la ges ión de los s eams.
Noso os hemos adap ado la aplicación pa a es e p oyec o, añadiendo una in e -
az más simple e in ui i a como se puede obse a en la Figu a 6.5 sin necesidad de
con igu ación p e ia, ya que es a se ealiza en la aplicación espondedo a de e en os,
que en nues o caso es “Mul is eaming”. Los di e en es e en os a los que esponde
nues a aplicación cuando se en ía el mensaje de ac i ación desde el bo ón de pánico
son los siguien es:
Sali y elimina la aplicación de ecien es.
Elimina odos los da os almacenados.
Desins ala oda la aplicación.
La con igu ación de es as acciones se ealiza a a és del menú de ajus es de
“Mul is eaming” median e unos bo ones de ac i ación.
42
Diseño
Figu a 6.5: Bo ón de pánico.
43
7. Implemen ación
En es a sección amos a p esen a la implemen ación de nues o p oyec o, di-
idida en capas según los p o ocolos usados. En es a e apa hemos in es igado y
a on ado nume osas di icul ades y decisiones, las cuales es án explicadas en de alle
en el apéndice B, pa a simpli ica y acili a la comp ensión de es e apa ado.
7.1. RTSP, RTP y libs eaming
An es de empeza con la implemen ación, u imos que in es iga an o el código
de los alumnos de años an e io es, como libs eaming y su posible adap ación a
Wi i Awa e. En el apéndice A.1, desa ollamos oda nues a in es igación y en el
apéndice A.1.3 las azones po las que omamos algunas de las siguien es decisiones.
La decisión más impo an e que omamos ue la de adap a libs eaming a Wi i
Awa e.
Como imos en la Sección 3.2.3, RTSP iene dos modalidades de ans-
misión. Noso os nos decan amos po u iliza únicamen e la modalidad
publica pa a ansmi i los s eams en e los disposi i os. Las azones y
sus implicaciones es án expues as en el apéndice A.2.
Como es a de inido en la Sección 5.1 de especi icación, nues o obje i o es que
cada disposi i o pueda:
C ea un s eam y ansmi i lo a múl iples disposi i os, con la capacidad de
isualiza lo y/o gua da lo mien as se c ea.
Recibi s eams de múl iples disposi i os y een ia los a múl iples disposi i os,
con la capacidad de isualiza lo y/o gua da lo mien as se ecibe/ een ía.
Pa a la implemen ación de es a capa, pa imos del código de libs eaming
con los cambios que hicie on los alumnos del p oyec o de 2018/19.
7.1.1. Análisis de libs eaming y o ien ación de la implemen-
ación
7.1.1.1. Es ado de libs eaming
En p ime luga , libs eaming p opo ciona la implemen ación de un clien e RTSP
en modalidad publica y un se ido RTSP en modalidad ep oduci , en ambos casos
aplicando la modalidad solamen e a s eams con o igen en el mismo disposi i o que
hace uso de la biblio eca, es deci , en el clien e RTSP solo se puede publica un s eam
44
Implemen ación
El se ido puede u iliza la modalidad ep oduci sob e s eams con
o igen en o o disposi i o, uncionalidad implemen ada po los alumnos de
2018/19. Es a modalidad es la que se u iliza pa a isualiza y/o gua da un s eam en
el disposi i o con libVLC. Po lo an o, con es a pa e de la modalidad, solamen e
se pueden isualiza /gua da los s eams que ienen de o o disposi i o.
Pa a pode gua da el s eam en el disposi i o en el que se g aba, es su-
icien e con adap a la implemen ación de la modalidad ep oduci en el
se ido pa a gua da lo con libVLC. Es a pa e de la modalidad ep oduci es aba
implemen ada y e a usada en libs eaming, pe o con los cambios que ealiza on los
alumnos de 2018/19, al no necesi a la, la deja on en desuso y no la ac ualiza on a
los cambios que ealiza on en el se ido RTSP. Las adap aciones necesa ias es án
p incipalmen e elacionadas con la es uc u a de las URI y las acciones en el se ido
RTSP pa a encon a el s eam solici ado.
G acias a la implemen ación del en ió múl iple del lujo mul imedia local, expli-
cada al inicio de es a sección y a la de la Sección 7.1.3 y basándonos en el p o ocolo
u ilizado en la o a pa e de la modalidad ep oduci del se ido RTSP, conseguimos
implemen a lo sin p oblemas.
En el clien e RTSP, solo es aba implemen ada la modalidad publi-
ca pa a en ia los s eams c eados localmen e. Pa a pode een ia los
s eams ecibidos en el disposi i o eníamos que comple a la modalidad
publica .
Al igual que con el se ido RTSP, g acias a la implemen ación del een ío múl-
iple del lujo mul imedia p o enien e de o os disposi i os, explicada al inicio de
la sección y a la de la Sección 7.1.3 y basándonos en el p o ocolo u ilizado en el la
o a pa e de la modalidad publica del clien e RTSP, pa a en ia los lujos c eados
localmen e, comple amos es a pa e.
T as habe comple ado es as modalidades, el p o ocolo RTSP es aba
comple o pa a ealiza la ansmisión múl iple. El disposi i o que g aba u ili-
za la modalidad publica pa a en ia lo a o o y es e a su ez puede een ia lo con la
modalidad publica y/o isualiza lo/gua da lo con la modalidad ep oduci , como
se menciono an e io men e, haciendo uso del clien e RTSP de libVLC a a és de la
di ección de loopback IP 4.
7.1.4.2. Adap ación del se ido pa a la ansmisión múl iple
El se ido RTSP es aba p ác icamen e lis o pa a la ansmisión múl iple. Aña-
dimos el uso del S eamingReco d, explicado en la Sección 7.1.3. Al p ocesa el
mé odo RTSP RECORD, po el que el clien e RTSP indica al se ido RTSP que
a a comenza a ansmi i , comp obamos que el s eam no haya sido egis ado en
el S eamingReco d po o o clien e y lo añadimos como s eam disponible pa a el
een ío. En el caso de que ya es é en el S eamingReco d, espondemos al clien e
con un código RTSP de echazo del s eam. Siguiendo es e mé odo, e i amos los
p oblemas con los bucles di ec amen e, al solo ene en cuen a como o igen inme-
51

Implemen ación
dia o del s eam al p ime nodo que inició la ansmisión y desca a odos aquellos
que lleguen a con inuación po o os caminos.
Dejamos pa a el abajo u u o op imiza la ecepción del s eam po el mejo
nodo. Se pod ían ene en cuen a mé icas mas óp imas.
7.1.4.3. Adap ación del clien e pa a la ansmisión múl iple
Al con a io que con el se ido , u imos que ehace p ác icamen e odo el
clien e RTSP pa a hace posible la ansmisión múl iple. En libs eaming, el
clien e RTSP solamen e negociaba con el se ido RTSP el en ío del
lujo de la cáma a local (modalidad publica ). Noso os necesi ábamos un
clien e que pudie a ges iona el en ío de más de un lujo mul imedia y que
una ez conec ase con el se ido se man u ie a a la espe a de que in odujé amos
nue os s eams en el S eamingReco d pa a en ia los.
Cambiamos odo el p oceso del clien e, ap o echando solo el código del p o ocolo
RTSP usado pa a en ia el lujo local de la cáma a y mic ó ono. Una ez iniciado
el clien e, es ablece conexión con el se ido y se man iene a la espe a de la llegada
de s eams al se ido RTSP del mismo disposi i o pa a pode manda los, en iando
mensajes de ipo OPTIONS de RTSP cada cie o iempo. Si no se en ían es os
mensajes la conexión de Wi i Awa e se pie de e en ualmen e.
Implemen amos la in e az S eamingReco dObse e , pa a ecibi callbacks de
los cambios de disponibilidad de los s eams del disposi i o. Cuando ecibe el call-
back de s eam disponible, negocia con el se ido su en ío, y cuando deja de es a
disponible, le en ía un mensaje de ipo TEARDOWN pa a cesa su ansmisión.
En ando en de alle sob e la ges ión de los en íos en el clien e:
Pa a los s eams gene ados localmen e c eamos un obje o Session con el
SessionBuilde ecibido en el callback decla ado en el S eamingReco dOb-
se e y aplicamos los mé odos del p o ocolo RTSP que enía la implemen a-
ción o iginal de libs eaming.
Pa a el een ío de los s eams ecibidos en el disposi i o, c eamos un obje o
Reb oadcas Session a pa i de la Recei eSession que de uel e el callback,
como comen amos en la Sección B.2. Tu imos que adap a los mé odos de libs-
eaming que implemen an la pa e clien e del p o ocolo RTSP (en modalidad
publica ), pa a que, además de en ia el lujo local con igu ado con el obje o
Session, pudie a en ia el lujo con igu ado con la Reb oadcas Session.
7.2. Wi i Awa e
Pa a ges iona la API de Wi i Awa e y sus conexiones implemen amos
la clase Wi iAwa eViewModel, que unciona a modo de con olado . Con es a
52
Implemen ación
clase podemos inicia una sesión de Wi i Awa e, la cual pe mi e c ea a su ez
sesiones de publishe y/o subsc ibe .
Al comenza la aplicación se inicia una sesión de publishe y o a de
subsc ibe ,siguiendo la in aes uc u a de ed de inida en la Sección 6.4. Toda la
lógica que sigue la sesión de publishe y la de subsc ibe es a de inida den o del
con olado . Es a lógica sigue el p ocedimien o explicado en el apéndice A.3, pa a
c ea conexiones clien e-se ido en e cada pa eja de subsc ibe -publishe .
En conc e o, el publishe inicia el se ido RTSP del disposi i o y cuan-
do un subsc ibe es ablece conexión con el, no i ica al se ido pa a que
c ee un socke y se comunique con el o o disposi i o.
El subsc ibe ac úa de o ma con a ia, po cada publishe que en-
cuen e y al que se conec e, se c ea un clien e RTSP y se inicia al clien e
de o ma que c ee un socke con el o o disposi i o.
La c eación de es os socke s y su a amien o es especial pa a Wi i
Awa e y u imos que modi ica an o el se ido como el clien e pa a
u iliza los. Es as modi icaciones es án desa olladas en de alle en el apéndice B.3.
Cabe des aca que, la c eación de una conexión de Wi i Awa e en e una
pa eja de disposi i os se complica cuando hay a ios disposi i os in en-
ando conec a se a la ez. En la documen ación solamen e se especi ica como
conec a dos disposi i os [38], pe o no menciona como ges iona a ios in en os si-
mul áneos de conexión. Si no se lle a un con ol sob e es a concu encia, descub imos
que, en ocasiones, se p oducen e o es que impiden a los disposi i os conec a se.
Noso os a amos es e p oblema secuencializando las conexiones en-
e pa ejas de disposi i os. Aun con es o, aunque mucho menos p obables, se
p oducen allos de conexión. Según nues a in aes uc u a de ed y eniendo imple-
men ado mul ihopping y el en ío múl iple, el que alle la conexión en e un publishe
y un subsc ibe no a ec a al co ec o uncionamien o de la aplicación.
En And oid 12 se an a in oduci mejo as pa a Wi i Awa e [39], que puede que
mi iguen es e p oblema o pod ía in es iga se o a o ma de a a es a concu en-
cia en un u u o. Pa a más de alle sob e como es a implemen ada es a ges ión de
conexiones, e e i se al apéndice B.4.
El elación con el p oblema de las sesiones que indican los alumnos del
p oyec o de 2019/20, el cual explicamos en el apéndice A.1.2, comp obamos
que es aban equi ocados en cuan o a su eo ía de que el es ado del Wi i
y la ubicación enía que es a siemp e ac i o, ya que si se desac i aba alguno
se ce aba la sesión de Wi i Awa e y más a de no podía c ea se una nue a.
Pa a soluciona lo, en el con olado ecogemos un callback de la API
53
Implemen ación
de Wi i Awa e que indica si Wi i Awa e deja de es a disponible. En ese
caso ce amos la sesión ac ual, jun o con la sesion de publishe y su se ido y la de
subsc ibe y sus clien es, y no i icamos al usua io. Cuando uel a a es a disponible,
po eac i a el Wi i o ubicación, podemos c ea o a sesión pa a con inua con el
uso no mal de la aplicación, al con a io de lo que indicaban los alumnos de 2019/20.
54
8. Conclusiones y abajo u u o
La c eación y ges ión de edes sin in aes uc u a en e disposi i os mó iles es un
á ea que es á ac ualmen e en in es igación y que p ome e muchas en ajas, an o
pa a la gen e que no enga posibilidad de conec a se a la habi ual in aes uc u a
de ed, como pa a los ope ado es de ele onía mó il e in e ne , pa a desconges iona
sus edes o llega a luga es con escasa cobe u a, po ejemplo.
Con es e p oyec o hemos aplicado un en oque o ien ado a la ansmisión de
ídeo y audio sob e es e ipo de edes. Con es e en oque buscamos implemen a una
aplicación que ue a ú il a la gen e en si uaciones de iesgo en las que no es posible
accede a la ed con encional. Hemos dis inguido dos escena ios de uso, un escena io
o ien ado a ansmi i ídeo y audio en acciden es o si uaciones de eme gencia en
las que no se iene acceso a la ed, y o o o ien ado a denuncia c ímenes y ac os
con a ios a los de echos humanos en luga es donde accede a la ed pod ía se
pelig oso.
8.1. Recapi ulación y e aluación
Pa a es e p oyec o pa imos de la expe iencia de los dos p oyec os de los cu -
sos 2018/19 y 2019/20. En el p oyec o de 2018/19 implemen a on su aplicación de
s eaming sob e la ecnología D2D, Wi i Di ec . Como cuen an en su memo ia, en el
capi ulo 5.1.3 [3], descub ie on cie as limi aciones en la ecnología que les impedía
ansmi i en e los disposi i os, ya que un disposi i o “maes o” cen alizaba las
comunicaciones (es deci , una opología en es ella). O os disposi i os ce canos po-
d ían ene un disposi i o maes o di e en e, lo que di idía a los disposi i os en edes
ad hoc aisladas. A pesa de es as di icul ades consiguie on in eg a en su p oyec o
la biblio eca libs eaming pa a la ansmisión de lujos mul imedia. Consiguie on
mejo a la implemen ación de la biblio eca, como se cuen a en la Sección 7.1, lo cual
nos b indo una buena base pa a nues o p oyec o.
En cuan o al p oyec o del cu so de 2019/20, usa on la ecnología Wi i Awa e
como medio de comunicación D2D. Es a ecnología p ome ía supe a las limi aciones
de Wi i Di ec así como mejo a la calidad de la ed ad hoc. Es una ecnología
muy emp ana con muy poca documen ación y apenas ejemplos de uncionamien o,
sumado a que po azones ajenas a su olun ad no pudie on consegui los mó iles a
iempo, no pudie on cumpli con la mayo ía de sus obje i os. Debido al poco iempo
no pudie on adap a libs eaming a Wi i Awa e, se encon a on cie os p oblemas,
e Sección A.1.2 pa a más de alles, que, sumados a la poca documen ación, les lle ó
a in en a o as al e na i as. Finalmen e decidie on ansmi i los lujos u ilizando
el p o ocolo SCTP sin p o ocolo de con ol.
55
Conclusiones y abajo u u o
Noso os pa a es e p oyec o, basándonos en las in es igaciones de los años an-
e io es, decidimos in en a adap a libs eaming a Wi i Awa e. Wi i Awa e es una
ecnología en desa ollo que p ome e mucho más pa a las comunicaciones D2D que
Wi i Di ec . A pa e de supe a las limi aciones de Wi i Di ec , es á ecibiendo a en-
ción po pa e de Google y ya se espe an mejo as en la ecnología pa a la p óxima
e sión de And oid [39]. Libs eaming po su pa e, es una biblio eca pa a s eaming
bas an e accesible en cuan o a modi icación se e ie e, lo que nos pe mi e cen a nos
más en la in es igación de Wi i Awa e.
Como obje i os que p opusimos y que hemos conseguido implemen a enemos
los siguien es:
Adap ación libs eaming a IP 6 y a Wi i Awa e: Conseguimos que la
biblio eca pudie a c ea conexiones basadas en Wi i Awa e, as una cos osa
in es igación an o del código de libs eaming como del uncionamien o de Wi i
Awa e. Además, añadimos a la biblio eca la capacidad de ansmi i s eams
sob e IP 4 o IP 6, ya que Wi i Awa e necesi aba ansmi i sob e IP 6. En la
Sección 7.1.2 se explican es os cambios en de alle.
Mul ihopping:En base al código de los alumnos de 2018/19, que consiguie on
una ansmisión en e una pa eja de disposi i os, ampliamos la implemen ación
de la biblio eca libs eaming pa a consegui más de un sal o en la ansmisión,
como se desa olla en las Secciones 7.1.3 y 7.1.4.1.
En ío del s eam a múl iples disposi i os: Noso os sol en amos los p o-
blemas de los bucles como se explica en la Sección 7.1.4.2, y mas adelan e en
es a sección p oponemos ex ende es a solución pa a pode mejo a el ou ing
según o as mé icas.
Gua da los s eams en cualquie disposi i o pa icipan e de la co-
municación pa a una pos e io isualización: Modi icando en el se ido
RTSP la modalidad ep oduci y haciendo uso localmen e del clien e RTSP
en modalidad ep oduci de libVLC, conseguimos la capacidad de isuali-
za /gua da los s eams an o en el disposi i o o igen como el disposi i o que
es un nodo de ánsi o o ecep o inal.
Emisión del s eam a un pun o de acceso Wi i o es ación base de
la ed de ele onía mó il: Noso os lo hemos conseguido g acias al mul i-
hopping. Cualquie disposi i o pa icipan e de la comunicación con acceso a
in e ne es capaz de emi i el s eam.
En cuan o al es o de las p opues as que ealiza on los alumnos del cu so 2019/20,
p opusie on do a a la ed de una mayo segu idad, pa a ello hemos di idido la
aplicación en dos modos de ope ación según los escena ios de uso, en el Humani a io
se da la opción de pone un iden i icado al s eam, así como el nomb e u o os da os
del emiso , en el escena io Wi ness es a uncionalidad se es inge conse ando en
odo momen o el anonima o del emiso , además hemos c eado una aplicación auxilia
56

Conclusiones y abajo u u o
de bo ón de pánico (Sección 6.5) pa a elimina los da os de ella y do a de más
segu idad a la aplicación.
En lo que espec a a las ad e sidades que nos han su gido en la ealización
de es e p oyec o, uno de los p incipales p oblemas ha sido la poca documen ación
que eníamos pa a el desa ollo de Wi i Awa e, aunque disponíamos de algunos
ejemplos de los alumnos del cu so 2019/2020, no e a su icien e pa a pode ealiza
un desa ollo exhaus i o.
O o p oblema ue la ges ión de múl iples conexiones simul áneas con Wi i Awa-
e, ya que en la documen ación solamen e se especi ica como conec a dos disposi i-
os [38], pe o no menciona como ges iona a ios in en os simul áneos de conexión.
Si no se lle a un con ol sob e es a concu encia, descub imos que, en ocasiones, se
p oducen e o es que impiden a los disposi i os conec a se. Es a ges ión e a unda-
men al pa a consegui el en ío múl iple de s eams po la ed y pa a soluciona lo
ealizamos la secuencialización de dichas conexiones como mencionamos en la Sec-
ción B.4.
8.2. T abajo u u o
En elación con el u u o de la aplicación, hemos conseguido una base obus a en
cuan o a la comunicación sob e la in aes uc u a descen alizada y a la ansmisión
de s eams con la biblio eca libs eaming, lo que pe mi e con inua el desa ollo
u u o de es e p oyec o más cen ado en a ances elacionados con los escena ios de
uso Humani a io y Wi ness, como la segu idad de la MANET, o la pixelación de las
ca as, po ejemplo.
Como p opues as pa a el abajo u u o, en cuan o a las uncionalidades básicas
enemos las siguien es:
Op imiza la ecepción del s eam po el mejo nodo: Se pod ían ene
en cuen a mé icas como la dis ancia o el núme o de sal os, la cual in luye
bas an e en el e aso del s eam. En es e caso, como solución al e na i a a la
nues a pa a p oblema de los bucles, se pod ían ene en cuen a las me odolo-
gías aplicadas po o os p o ocolos de ou ing en edes ad hoc como OLSR [40]
y en DTNs (Delay Tole an Ne wo ks) [41].
Adap ación de libs eaming a RTSP 2.0: Se end ía que adap a la bi-
blio eca pa a hace uso de la modalidad ep oduci en la ansmisión de los
s eams en e disposi i os, ya que la modalidad publica en es a e sión des-
apa ece. Pa a ello se ia necesa io implemen a en el clien e RTSP, que ac ual-
men e u iliza la modalidad publica pa a en ia sus s eams al se ido , la
modalidad ep oduci pa a solici a y ecibi s eams de los se ido es RTSP.
En es e caso solo ha ía al a implemen a en el clien e RTSP las di ec i as del
57
Conclusiones y abajo u u o
p o ocolo RTSP en modalidad ep oduci , ya que el se ido RTSP ya imple-
men a la modalidad ep oduci y el en ío del lujo po RTP y RTCP ya es á
implemen ado.
Con es e modelo de comunicación su ge el p oblema de hace llega a los
clien es RTSP el lis ado de iden i icado es de los s eams disponibles pa a
solici a al se ido RTSP, ya que en RTSP no hay ningún p ocedimien o pa a
ob ene es a in o mación y el clien e RTSP iene que conoce p e iamen e el
iden i icado de un s eam pa a solici a lo. Como solución se pod ía hace una
dis inción de casos en la di ec i a DESCRIBE del se ido RTSP po la que,
en unción de la URI solici ada, se esponda al clien e RTSP la desc ipción
de un s eam en conc e o o una lis a de los iden i icado es de los s eams
que dispone el se ido RTSP, pa a una pos e io solici ud. O a opción se ía
ansmi i la lis a de iden i icado es de s eams, p e iamen e al en ío de la
di ec i a DESCRIBE de RTSP, a a és de la API de mensajes de Wi i Awa e.
Como p opues as pa a el abajo u u o, en cuan o a las uncionalidades especí-
icas de cada escena io de uso, enemos las siguien es:
1. Escena io Humani a io:
Pixelación de ca as, ap o echando o os códigos de so wa e lib e como
el de Obscu aCam [42].
Posibilidad de añadi un des ino inal suge ido al s eam.
Conside aciones de los me ada os pa a hace los más obus os y segu os,
además de asegu a que incluyen las coo denadas es ilo GPS.
2. Escena io Wi ness:
a)Segu idad:
La ed pod ía se suscep ible a a aques como, la inyección de s eams
que cons i uyen una ac i idad c iminal, como la po nog a ía in an il,
o con el in de mon a un a aque DDoS y la a ibución, modi ica-
ción o ansmisión de s eams suplan ando la iden idad del emiso .
Como de ensas con a es os a aques se pod ía hace uso de una cla-
e de g upo p e iamen e aco dada, pa a enc ip a los s eams que
ci culan po la ed y de es a mane a solo los usua ios con la cla e
puedan ansmi i los y isualiza los, siguiendo de alguna o ma el
p o ocolo GDOI [43]. Pa a es o se pod ía ap o echa el código de
In o maCam [44].
Pa a asegu a la au en icidad de los s eams se pod ía u iliza
H.264/SVC como o ma o de codi icación de ídeo. Se pod ía u i-
liza pa a ello la biblio eca s cAu h [45] pa a Ja a, que pe mi e la
e i icación de odos los s eams ansmi idos.
b)Cadena de cus odia: Realiza una conexión con una implemen ación
de Secu eD op (diseñado y desa ollado po Aa on Swa z [46] jun o con
Ke in Poulsen) ía To pa a en ia s eams almacenados.
58
Conclusiones y abajo u u o
c)P i acidad:
Enc ip ado de s eams gua dados en iche os haciendo uso de cla es
c eadas po el p opio usua io.
Elimina de los me ada os ansmi idos cualquie in o mación que
pueda dela a al au o del ídeo.
8.3. Obse aciones inales
Finalmen e, con el desa ollo de es e p oyec o hemos hecho una con ibución
impo an e a la implemen ación de es a aplicación y, po an o, al obje i o del
p oyec o en que se enma ca es e TFG de cons ui y dis ibui una aplicación de
so wa e lib e que pod á ene una g an u ilidad social. Además, es amos ba ajando
hace un o k del p oyec o libs eaming llamado mul is eaming que con end á oda
la nue a uncionalidad con la cual hemos ex endido es a bien conocida lib e ía.
59
9. Conclusions and u u e wo k
The c ea ion and managemen o in as uc u e- ee ne wo ks be ween mobile
de ices is an a ea ha is cu en ly unde in es iga ion and holds g ea p omise,
bo h o people who do no ha e he possibili y o connec ing o he usual ne wo k
in as uc u e, and o cell phone and in e ne ope a o s, o ease conges ion in hei
ne wo ks o each places wi h poo co e age, o example.
Wi h his p ojec we ha e applied an app oach o ien ed o he ansmission
o ideo and audio o e his ype o ne wo ks. Wi h his app oach we sough o
implemen an applica ion ha would be use ul o people in isk si ua ions whe e
i is no possible o access he con en ional ne wo k. We ha e dis inguished wo
usage scena ios, one scena io o ien ed o ansmi ideo and audio in acciden s o
eme gency si ua ions whe e he e is no ne wo k access, and ano he o ien ed o
epo c imes and ac s con a y o human igh s in places whe e ne wo k access
could be dange ous.
9.1. Summa y and e alua ion
Fo his p ojec we s a om he expe ience o he wo p ojec s o he academic
yea s 2018/19 and 2019/20. The s uden s o he 2018/19 p ojec implemen ed hei
s eaming applica ion on he D2D echnology, Wi i Di ec . As hey ecoun in Sec ion
5.1.3 o hei inal epo [3], hey disco e ed ce ain limi a ions in he echnology
ha p e en ed hem om s eaming be ween de ices, due o all he communica ions
ha ing o pass h ough a “mas e ” de ice (i.e. a s a opology). O he nea by de ices
migh ha e a di e en mas e de ice, which di ided he de ices in o isola ed ad
hoc ne wo ks. Despi e hese di icul ies hey managed o in eg a e he libs eaming
lib a y o mul imedia s eaming in o hei p ojec . They managed o imp o e he
implemen a ion o he lib a y, as epo ed in Sec ion 7.1, which ga e us a good basis
o ou p ojec .
As o he 2019/20 cou se p ojec , hey used Wi i Awa e echnology as a means
o D2D communica ion. This echnology p omised o o e come he limi a ions o
Wi i Di ec as well as imp o e he quali y o he ad hoc ne wo k. I is a e y ea ly
echnology wi h e y li le documen a ion and ha dly any wo king examples, added
o he ac ha o easons beyond hei con ol hey could no ge he cell phones
in ime, so ha hey could no mee mos o hei goals. Due o he lack o ime hey
could no adap libs eaming o Wi i Awa e, hey encoun e ed ce ain p oblems, see
Sec ion A.1.2 o mo e de ails, which, added o he lack o documen a ion, led hem
o y o he al e na i es. They inally decided o ansmi he s eams using he
SCTP p o ocol wi hou con ol p o ocol.
60
Apo ación de los pa icipan es
Figu a 10.1: Diag ama de Gan .
67

A. De alles del diseño
A.1. In es igación y análisis inicial
Nues o p ime paso en el desa ollo del p oyec o ue in es iga los p oyec os
an e io es, lee sus memo ias, en ende sus decisiones, a ances y p oblemas y analiza
su código. En unción de es o decidimos como o ien a nues o abajo.
A.1.1. P oyec o 2018/19
Comenzamos con el p oyec o De ice o De ice S eaming en disposi i os
mó iles [3] del cu so 2018/19. Sus obje i os e an los mismos que los nues os y
decidie on desa olla su p oyec o apoyándose en la lib e ía de código abie o libs-
eaming pa a la ansmisión de cáma a y ídeo po RTSP, RTP y RTCP y de
Wi i Di ec como medio de conexión D2D en e disposi i os.
En cuan o a la biblio eca libs eaming, u ie on que adap a las clases que u i-
lizaba pa a ansmi i del lujo de la cáma a y el ídeo, ya que la biblio eca es aba
pensada pa a ansmi i el lujo a un único disposi i o y enían con lic os con el
ha dwa e a la ho a de ansmi i a ios lujos (Como se explica en el capi ulo 6.5.1
de su memo ia [3], es o no lo soluciona on comple amen e). También u ie on que
adap a su se ido RTSP, ya que el clien e RTSP solo podía abaja con la moda-
lidad publica y el se ido solo con la modalidad ep oduci . El clien e RTSP
de libs eaming es aba pensado pa a ansmi i a un se ido RTSP como Wowza
Media Se e y el se ido RTSP de libs eaming es aba pensado pa a se u ilizado
con un clien e RTSP con la modalidad ep oduci como libVLC. Implemen a on
la modalidad publica en el se ido RTSP de libs eaming pa a u iliza lo
con el clien e RTSP de libs eaming, log ando implemen a mul ihopping (capi ulo
6.5.2 de [3]).
Pa a u iliza Wi i Di ec implemen a on un con olado y clases pa a au oma iza
la búsqueda y conexión de los disposi i os. T as ealiza p uebas encon a on una
limi ación pa a su aplicación a causa de que Wi i Di ec abaja asociando a los
disposi i os po g upos aislados y necesi aban que el nodo de ánsi o u ie a que
cambia con inuamen e de uno a o o pa a ansmi i (capi ulo 5.1.3 de [3]).
Un a ance suyo ambién des acable es la esolución de unos p oblemas de
con igu ación de libVLC que hacía que la imagen se ie a gi ada y pequeña al
ep oduci . P obando la aplicación nos dimos cuen a de que aun así necesi aba
e oques si nos decidíamos a usa lo, ya que la esolución no e a la misma que
la pan alla y apa ecía un cuad ado neg o en la pa e supe io y que al modi ica la
68
De alles del diseño
con igu ación de libs eaming pa a u iliza la cáma a on al, al hace s eaming se
eía la imagen al e és. Encon amos o o p oblema elacionado con la cáma a y es
que es a no en ocaba bien, lo que se no aba mucho ya que u ilizaban una calidad
baja de ansmisión y no se podían lee ex os.
A.1.2. P oyec o 2020/21
Nues o siguien e paso ue es udia el p oyec o C owds eaming: ansmisión
de ídeo y audio po una ed ad hoc de elé onos mó iles [4] del cu so
2019/20. Hay que ema ca que po ci cuns ancias ue a de su con ol, no u ie on
los disposi i os mó iles has a p incipios de ma zo del 2020, lo que supuso un e aso
en sus in es igaciones. Pa a es e p oyec o se a iesga on a u iliza Wi i Awa e
en ez de Wi i Di ec pa a la conec i idad, aún con la poca documen ación y
ejemplos. Conside a on el p oblema de los g upos de Wi i Di ec , capi ulo 5.1.3 de [3],
un impedimen o muy g ande pa a consegui su aplicación. Pa a la ansmisión de
ídeo y audio decidie on in en a adap a libs eaming a Wi i Awa e donde
se encon a on con los siguien es p oblemas:
1. E a necesa io ene el Wi i y la ubicación del disposi i o ac i ados
an es de inicia la aplicación pa a c ea una sesión de Wi i Awa e. Es a
sesión pe mi ía c ea las conexiones en e los disposi i os y los alumnos asegu-
a on que la sesión debía de c ea se obliga o iamen e al inicio de la aplicación
y no se podía ol e a c ea una nue a más adelan e.
2. Wi i Awa e u iliza di ecciones IP 6 y libs eaming solo es aba im-
plemen ado pa a u iliza IP 4. Ellos in en a on adap a libs eaming, ha-
ciendo que el clien e RTSP ecibie a los socke s c eados con la API de Wi i
Awa e, pe o no les unciono po azones desconocidas.
Finalmen e, decidie on desis i de libs eaming y ealiza la ansmisión po
medio del p o ocolo SCTP, incluido como u ilidad en la API de Wi i Awa e, aun
sabiendo que no u iliza ían p o ocolo de con ol del s eaming, espe ando implemen-
a lo más adelan e.
U iliza on libVLC pa a la ep oducción del s eaming.Ya que no u ili-
zaban p o ocolo de con ol u ie on que u iliza un bu e HTTP en un socke local,
lo que in oducía e asos en la ep oducción, sumado a la pé dida de calidad po
no u iliza p o ocolo de con ol.
En el capi ulo 6.6.1 de su memo ia [4], se ci a lo siguien e:
«No obs an e, dado que no es amos usando ningún p o ocolo de con ol de se-
siones de ídeo en nues a implemen ación, implemen amos un bu e a a és de un
p oxy HTTP local, el cual nos pe mi ía ans o ma el lujo del socke a un lujo le-
gible pa a la lib e ía libVLC. Aunque es o p o oca un pequeño e aso en el s eam,
ga an iza que no se p oduzcan co es.»
69
De alles del diseño
A des aca , implemen a on el almacenamien o del s eaming en el dis-
posi i o y una gale ía pa a e los, consiguie on hace pasa el s eaming a a és
de un nodo in e medio (aunque noso os no conseguimos e i ica lo al p oba su
aplicación). El p oblema de los bucles en la ansmisión no lo con empla on al solo
pode hace una única ansmisión desde un disposi i o.
A.1.3. Conclusiones
Po lo mencionado en el apa ado 4 de elección de ecnologías, conside amos
que Wi i Awa e es la más ap opiada pa a nues a aplicación, a pesa de
ene poca documen ación. El hecho de ene es e año los mó iles pa a p oba Wi i
Awa e desde el p incipio nos pe mi ía dedica le más iempo a in es iga .
En cuan o a la ansmisión de ídeo y audio conside amos que la p opues a
del año pasado de usa SCTP sin p o ocolo de con ol no enía mucho u u o. A
pa e de empeo a la calidad po no usa p o ocolo de con ol, no es un es ánda
de ac o en el mundo del s eaming. Es mejo u iliza p o ocolos popula es, ya que
segu amen e an a es a más op imizados y a a habe más código compa ible con
él, como libVLC, que puede ep oduci un s eaming dis ibuido po RTSP. Po
es as azones empezamos a es udia si podíamos adap a o o so wa e lib e como
libs eaming pa a manipulación de lujos mul imedia.
Una opción que in es igamos ue VLC media playe , que eemplaza el an iguo
VideoLan Se e , y se puede usa como clien e y se ido pa a c ea s eamings en
múl iples pla a o mas y con dis in os códecs de audio y ídeo. El en ío de lujos
mul imedia lo ealizan po medio de la biblio eca Li e555 en C++, que implemen a
el p o ocolo RTSP, RTP y RTCP. U iliza VLC media playe o di ec amen e Li e555
mejo a ía bas an e el a amien o mul imedia de la aplicación, al es a muy es u-
diado e implemen ado en C++, aunque eque i ía mucho abajo de in es igación y
adap ación.
No se puede usa di ec amen e una biblio eca pa a ansmi i el s eaming debido
a que no es án adap adas pa a u iliza la API de Wi i Awa e. Es a API equie e
c ea los socke s de una mane a especial, como se explica en la Sección A.3.
A pesa de oda la in es igación u imos que echaza la p opues a po que descu-
b imos que VLC no sopo a IP 6 pa a los s eamings po RTSP [47]. Es á adap ado
en su mayo ía a IP 6, pe o la pa e de RTSP que iene de Li e555, po el momen-
o no. En gene al el s eaming con IP 6 suele ealiza se sob e HTTP, pe o su uso
sob e p o ocolos especí icos de s eaming como RTSP no es á muy ex endido po el
momen o, y mucho menos pa a And oid. Po ello in en a adap a libs eaming
a IP 6 cada ez nos pa ecía una mejo opción. A des aca , WebRCT u iliza
SRTP sob e IP 6 y pod ía se una buena al e na i a de desa ollo.
Elegimos in en a adap a libs eaming po las siguien es azones:
70
De alles del diseño
El código es más accesible que o as al e na i as. Los socke s de Wi i Awa e
ienen que c ea se de una o ma especial y solo hay documen ación pa a hace lo
en Ja a. Pensa en u iliza una biblio eca en C++ pod ía supone mucho
iempo in e ido en in es igación.
Tenemos más ejemplos de uso en o as aplicaciones.
Los alumnos del p oyec o de 2018/19 implemen a on pa cialmen e la ex ensión
de la biblio eca pa a inclui el mul ihopping y el en ío múl iple, lo que nos
pod ía aho a bas an e abajo.
A.2. Elección de modalidad RTSP
En la Sección 3.2.3, p esen amos las modalidades que de ine RTSP. Con es as
modalidades eníamos las siguien es opciones de implemen ación pa a mul ihopping:
1. U iliza solamen e la modalidad RTSP publica . En es a modalidad, el
clien e RTSP es el emiso del s eam y se lo o ece ac i amen e a los se ido es.
2. U iliza solamen e la modalidad RTSP ep oduci . En es a modalidad,
el se ido RTSP es el emiso del s eam y espe a a que los clien es se lo pidan.
3. Al e na en e las dos modalidades según algún c i e io.
Noso os decidimos u iliza la p ime a, solamen e la modalidad publica
pa a ansmi i los lujos mul imedia en e disposi i os. Conside amos que iene más
sen ido pa a la inalidad de nues a aplicación al ene un ca ác e de p opagación
más ac i o, en el escena io Wi ness (Sección 5.1) in e esa subi el s eam en un nodo
con in e ne lo an es posible y en el Humani a ian (Sección 5.1) a isa a eme gencias
ápidamen e. U iliza la segunda o e ce a implica ía ene que implemen-
a la modalidad ep oduci en el clien e RTSP de libs eaming, apa e de
in oduci complejidad innecesa ia a la comunicación. Con complejidad nos
e e imos a que, u ilizando es a modalidad, el clien e end ía que conoce p e iamen-
e los s eams disponibles en el se ido pa a pedi le la ansmisión de uno. RTSP
no implemen a ningún mensaje en el p o ocolo pa a ansmi i es a in o mación y
end ía que hace se de o ma ajena a es e.
Pa a implemen a es e modelo de ansmisión ideamos la in aes uc u a de ed
explicada en la Sección 6.4.
Cabe des aca que, en libs eaming, es a implemen ado RTSP 1.0. En
cie o momen o de la implemen ación nos dimos cuen a de que en RTSP 2.0, la
modalidad publica es eliminada. En el RFC 7826 [48], se ci a lo siguien e:
«The ollowing p o ocol elemen s we e emo ed in RTSP 2.0 compa ed o RTSP
1.0:»
« he RECORD and ANNOUNCE me hods and all ela ed unc ionali y (in-
cluding 201 (C ea ed) and 250 (Low On S o age Space) s a us codes);»
71
De alles del diseño
Es o supone que, en un u u o se end ía que sus i ui el uso de la mo-
dalidad publica en nues a aplicación con odo lo que ello conlle a. En la
Sección 8 de abajo u u o, se comen a en de alle como se pod ía sus i ui es a
modalidad.
A.3. C eación de conexiones con Wi i Awa e
Pa a c ea una conexión clien e-se ido en e disposi i os a a és de Wi i Awa e
se ienen que segui los siguien es pasos:
1. En un disposi i o, el p og ama que quie e o ece un se icio, que llama emos
el publishe (en nues o caso, el publishe implemen a á un se ido -RTSP-en-
modalidad-publica ), in oca el mé odo publish de la clase Wi iAwa eSession.
En o o disposi i o, el p og ama que quie e usa el se icio, que llama emos
el subsc ibe (en nues o caso, el subsc ibe implemen a un se ido -RTSP-en-
modalidad-publica ), in oca el mé odo subsc ibe de la clase Wi iAwa eSession.
En los dos disposi i os, el obje o Wi iAwa eSession se c ea con un nomb e de
se icio, que si e pa a que Wi i Awa e case el se icio que o ece el publishe
con el que busca el subsc ibe .
2. Cuando el sis ema de Wi i Awa e descub e un publishe del se icio que un
subsc ibe busca, no i ica al subsc ibe en cues ión con un callback que iene
como a gumen o el obje o Pee Handle del publishe . Cuando el subsc ibe
ecibe el callback de descub imien o, puede usa el obje o Pee Handle del
publishe pa a en ia le un mensaje.
3. Cuando el publishe ecibe un callback que iene como a gumen o el ob-
je o Pee Handle del subsc ibe y que si e pa a no i ica le que ha llegado
un mensaje de un subsc ibe que quie e usa el se icio que o ece, c ea un
Se e Socke , o Se e Socke Channel si u ilizamos Ja a NIO, y gua da el
núme o de su pue o.
4. El publishe puede usa el API de And oid con el obje o Disco e ySession,
ob enido al publica su se icio, el obje o Pee Handle del subsc ibe y el pue o
del Se e Socke pa a c ea un obje o Ne wo kReques . Es e obje o si e
pa a solici a un obje o Ne wo k que pe mi e incula (bind)socke s a una
de las edes que iene disponible el disposi i o, como puede se Wi i, 4G o
Wi i Awa e. Es a inculación si e pa a que la esolución de di ecciones IP
y el en ío de paque es se ealice a a és de la ed seleccionada. La API de
And oid p opo ciona una clase llamada Socke Fac o y pa a c ea Socke s
asociados a una ed o, median e la clase Conec i i yManage , la asociación
del h ead en e o a la ed pa a que en la c eación de cualquie ipo de socke
y canal se incule in e namen e al obje o Ne wo k [49]. Una ez solici ado el
obje o Ne wo k, podemos ecibi callbacks cuando la ed es é o no disponible
o cuando es a se pie da.
5. Cuando el publishe haya solici ado el obje o Ne wo k debe en ia un mensaje
al subsc ibe pa a a isa le.
72

De alles del diseño
6. Cuando el subsc ibe eciba el mensaje, debe c ea un Ne wo kReques de la
misma o ma que en el publishe , pe o sin especi ica pue o.
7. Cuando el subsc ibe eciba el callback onA ailable de la Ne wo kReques ,
el cual p opo ciona el obje o Ne wo k solici ado, puede ob ene la di ección
IP 6 y pue o del se ido y c ea un socke con él. T as ecibi el callback
onA ailable, se ecibe siemp e el callback onCapabili iesChanged, el cual,
incluye como pa áme o un obje o de la clase Ne wo kCapabili ies del que
se pueden ob ene la IP 6, y el pue o en caso de c ea se la Ne wo kReques
en el pun o 4 incluyendo el pue o, del o o ex emo de la conexión.
8. Una ez las conexiones se cie en es impo an e elimina el Ne wo kReques
del sis ema pa a e i a pé didas de memo ia [50].
Es os pasos se basan en la documen ación de And oid sob e la c eación de cone-
xiones de Wi i Awa e [38].
73
B. De alles de implemen ación
B.1. Es ado de libs eaming y los cambios en el cu -
so 2018/19
En es a sección comen a emos en de alle la implemen ación de libs eaming y
los cambios que in oduje on los alumnos del cu so 2018/19 pa a su p oyec o.
B.1.1. Es ado de libs eaming
Libs eaming p opo ciona la implemen ación de un clien e RTSP en modalidad
publica y un se ido RTSP en modalidad ep oduci , en ambos casos aplicando
la modalidad solamen e a s eams con o igen en el mismo disposi i o que hace uso
de la biblio eca, es deci , en el clien e RTSP solo se puede publica un s eam y
al se ido RTSP solo se le puede solici a un s eam que se es e cap u ando en el
mismo disposi i o.
El se ido RTSP es a de inido en la clase R spSe e y el clien e RTSP en
la clase R spClien . La clase R spSe e ex iende la clase Se ice de And oid e
in e namen e es a compues o po un h ead que a iende las pe iciones de conexión y
c ea un nue o h ead pa a a ende a cada clien e que se conec e. La implemen ación
del se ido es a o ien ada a que un clien e, según la in o mación que ansmi a en
la URI del s eam que quie e, ije los pa áme os de la cáma a y códecs de audio
y ídeo pa a que el se ido inicie la cap u a de audio y ídeo y le ansmi a los
da os. Es o supone un p oblema al a ende a a ios clien es, ya que no se maneja
la posibilidad de que a ios clien es solici en dis in os pa áme os en la URI, lo que
gene a un con lic o en el uso de la cáma a. Además, como se e a en de alle en el
apéndice B.2, la clase Session, que lee los da os de la cáma a y mic ó ono y los
empaque a y en ía po RTP y RTCP, no es a implemen ada pa a pode u iliza se
con mas de una ins ancia a la ez, lo que imposibili a en ia el mismo lujo a mas
de un clien e.
La implemen ación del clien e RTSP pe mi e publica un solo s eam a un único
se ido RTSP. El en ió del lujo mul imedia se hace de la misma o ma que en
el se ido , median e un obje o Session, a di e encia de que es e obje o no es a
con igu ado según la URI, si no según unos pa áme os con igu ados al c ea una
ins ancia del clien e.
B.1.2. Cambios en libs eaming po los alumnos de 2018/19
Los alumnos de 2018/19, o ien a on pa e del p oyec o a adap a libs eaming
pa a que su clien e y se ido RTSP pudie an abaja jun os. Pa a ello, añadie-
74
De alles de implemen ación
on en el se ido RTSP la implemen ación de la modalidad publica , pa a pode
ecibi s eams de o os disposi i os, y modi ica on la modalidad ep oduci pa a
que pudie a een ia los s eams ecibidos de o os disposi i os con la modalidad
publica . Es a implemen ación de la modalidad ep oduci , nos pe mi e isualiza
y/o gua da los s eams ecibidos en el disposi i o median e el uso del clien e RTSP
de libVLC.
La implemen ación de libs eaming de la modalidad ep oduci en el se ido
RTSP, pa a en ia un s eam con o igen en el mismo disposi i o, decidie on no
adap a la a los cambios que hicie on en el se ido , sob e odo en cuan o al uso de
la URI pa a e e i se a un s eam, y quedo en desuso. Noso os necesi amos es a
uncionalidad pa a pode gua da el s eam del usua io mien as se cap u a en el
mismo disposi i o.
Al implemen a odos es os cambios ees uc u a on el código del se ido RTSP.
Di idie on la pa e de a amien o de las conexiones y clien es en la clase
RTSPSe e Selec o y odo el p o ocolo RTSP y la c eación de s eams a la clase
RTSPSe e Wo ke . En la clase RTSPSe e Selec o se leen los da os de cada clien-
e, el RTSPSe e Wo ke los p ocesa y la clase RTSPSe e Selec o los esc ibe. El
a amien o de los clien es en la clase RTSPSe e Selec o cambió, con espec o a
la implemen ación de libs eaming, de un h ead po clien e pa a lee y esc ibi sus
da os, a un único h ead que a e an o la pe iciones de nue a conexión como las
lec u as y esc i u as de odos los clien es, u ilizando la API de Ja a NIO. U ilizaban
en conc e o la clase Selec o de Ja a NIO y cabe des aca que libs eaming no
u ilizaba Ja a NIO.
Además, c ea on dos clases, Recei eSession yReb oadcas Session. La clase
Recei eSession es la enca gada de ecibi los da os de un lujo mul imedia po
RTP y RTCP y een ia los a los des inos que se le indiquen, como un se ido UDP
que e ansmi e los da os que ecibe. La clase Reb oadcas Session es u ilizada pa a
een ia un lujo mul imedia ecibido con una Recei eSession. Al c ea una ins ancia
se le pasa una ins ancia de una Recei eSession. Al ija un des ino pa a el een ío
del lujo, añade el socke des ino de los da os al se ido de la Recei eSession pa a
que los een íe.
Además de es os cambios, añadie on uncionalidad pa a pode isualiza un
s eam haciendo uso de libVLC. Una ez conseguían la URI, basada en IP 4, que
iden i icaba el s eam RTSP que que ían isualiza den o del se ido RTSP, c ea-
ban una ins ancia de la biblio eca pasándole la URI, y el clien e RTSP de libVLC,
que implemen a la modalidad ep oduci , le solici aba el s eam al se ido RTSP
de libs eaming y lo p esen aba en la pan alla.
En la implemen ación de libs eaming el código pa a con igu a y con ola la
cáma a es a mezclado con el código pa a ansmi i s eams, lo que según se in es igo
po los alumnos de 2018/29, imposibili a el en ió múl iple (mul icas ) del s eam.
Ellos empeza on la implemen ación de una solución pe o no log a on esol e es e
75
De alles de implemen ación
p oblema. Noso os pa imos de un código con el que podemos en ia desde el clien e
RTSP un solo s eam a un único se ido RTSP y podemos ecibi solamen e un
s eam po clien e en el se ido RTSP.
Los cambios que in oduje on ue on la c eación de dos clases que siguen el pa-
ón Single on,VideoPacke ize Dispa che yAudioPacke ize Dispa che . Ya
que las clases enca gadas de codi ica el audio y ídeo no pueden lee a la ez del
ha dwa e al gene a con lic os de lec u a, es as nue as clases ac úan de in e media-
io, almacenando los da os de ídeo y audio y copiándolo a cada clase codi icado a.
Es as clases codi icado as ienen que se modi icadas pa a susc ibi se al en ió de
in o mación de es as nue as clases. Los alumnos de 2018/19 solo adap a on la cla-
se que codi ica el o ma o de ídeo H264 y el o ma o de audio AAC, las demás
queda on en desuso.
Aun así, queda po esol e o o p oblema po el cual no es posible el en ió
múl iple, po que en libs eaming la con igu ación y con ol de la cáma a es án con-
enidos en el obje o Session, el cual se c ea cada ez que se quie a en ia el lujo
mul imedia a un clien e. Al c ea a ios obje os Session hay un con lic o con la
cáma a y deja de unciona la ansmisión.
B.2. En ío del lujo mul imedia a mas de un des ino
En es e pun o amos a desa olla en p o undidad como adap amos libs eaming
pa a pode en ia el lujo de la cáma a y mic ó ono a mas de un des ino. Dis in-
guimos dos casos, el een ió de un lujo ecibido y el en ió de un lujo
gene ado localmen e.
El een ió de un lujo ecibido a múl iples des inos, ue implemen ado
pa cialmen e po los alumnos del cu so 2018/19. Los da os se eciben po cua o
socke s UDP, RTP y RTCP de ídeo y RTP y RTCP de audio. Es os socke s de
ecepción es án con enidos en un obje o de la clase Recei eSession. A es e obje o se
le pueden añadi más socke s pa a een ia los da os ecibidos, es deci , implemen a
un se ido UDP que ecibe y een ía da os. La adición de es os socke s se hace
po medio del obje o de la clase Reb oadcas Session. Es e obje o, el cual con iene
la Recei eSession, se con igu a al negocia con el se ido RTSP, ecep o de los
s eams eemi idos, c eando cua o socke s pa a en ia los da os al se ido . Es os
socke s se añaden al se ido UDP de la Recei eSession, enca gado de een ia los
da os.
P ime o se adap ó la desc ipción SDP de los lujos de la Reb oadcas Session.
Es a, al igual que con el obje o Session, enía que se adap ada pa a desc ibi un
s eaming po IP 6, como con amos en la Sección 7.1.2.
Además, los socke s de comunicación enían que se adap ados a Wi i
Awa e. An es de c ea los socke s RTP y RTCP, an o los de ecepción como los de
en ió, asociamos el h ead que los a a c ea , al obje o Ne wo k ecibido po la API
de Wi i Awa e, el cual es di e en e pa a cada pa eja de disposi i os. En el pun o
76
Bibliog a ía
[27] O acle Co p. De eloping WebRTC-enabled And oid Applica ions.u l:h ps:
//docs.o acle.com/cd/E55119_01/doc.71/e55126/wd_and oidapps.h m#
WSEWD436 (Úl imo acceso: 12-06-2021).
[28] Google LLC. WebRTC And oid de elopmen .u l:h ps://web c.googlesou ce.
com/s c/+/ e s/heads/mas e /docs/na i e-code/and oid/index.md
(Úl imo acceso: 12-06-2021).
[29] VideoLan O g. VLC media playe .u l:h ps://www. ideolan.o g/ lc/
index.es.h ml (Úl imo acceso: 12-06-2021).
[30] VideoLan Wiki. Li e555. Ab . de 2019. u l:h ps://wiki. ideolan.o g/
Li e555/ (Úl imo acceso: 12-06-2021).
[31] Juan Na a o. «RTP (II): S eaming wi h FFmpeg». En: Ku en o Technologies
(ab . de 2019). u l:h p://www.ku en o.o g/blog/ p-ii-s eaming-
mpeg (Úl imo acceso: 12-06-2021).
[32] FFmpeg. Documen a ion.u l:h ps:// mpeg.o g/documen a ion.h ml
(Úl imo acceso: 12-06-2021).
[33] Mónica Mena Roa. «And oid e iOS dominan el me cado de los sma phones».
En: S a is a (jul. de 2020). u l:h ps://es.s a is a.com/g a ico/18920/
cuo a-de-me cado-mundial-de-sma phones-po -sis ema-ope a i o/
(Úl imo acceso: 12-06-2021).
[34] Came on Chapman. «Explo ando los P incipios Ges al del Diseño». En: Top-
al Design Blog.u l:h ps://www. op al.com/designe s/ui/explo ing-
he-ges al -p inciples-o -design (Úl imo acceso: 12-06-2021).
[35] Wikipedia. Hop (ne wo king).u l:h ps://en.wikipedia.o g/wiki/Hop_
(ne wo king) (Úl imo acceso: 12-06-2021).
[36] M. Handley, V. Jacobson y C. Pe kins. SDP: Session Desc ip ion P o ocol.
RFC 4566. In e ne Enginee ing Task Fo ce (IETF), jul. de 2006. u l:h ps:
//da a acke .ie .o g/doc/h ml/ c4566 (Úl imo acceso: 12-06-2021).
[37] And oid De elope s. Came a2.u l:h ps : / / de elope . and oid . com /
aining/came a2 (Úl imo acceso: 12-06-2021).
[38] And oid De elope s. Desc ipción gene al del econocimien o de Wi-Fi.u l:
h ps://de elope .and oid.com/guide/ opics/connec i i y/wi i-
awa e#ob ain_a_session (Úl imo acceso: 12-06-2021).
[39] And oid De elope s. Desc ipción gene al de las unciones y API.u l:h ps:
//de elope .and oid.com/abou / e sions/12/ ea u es#wi i-awa e-
enhancemen s (Úl imo acceso: 12-06-2021).
[40] T. Clausen y P. Jacque . Op imized Link S a e Rou ing P o ocol (OLSR). RFC
3626. In e ne Enginee ing Task Fo ce (IETF), oc . de 2003. u l:h ps :
//da a acke .ie .o g/doc/h ml/ c3626 (Úl imo acceso: 12-06-2021).
[41] Wikipedia. Delay- ole an ne wo king.u l:h ps://en.wikipedia.o g/
wiki/Delay- ole an _ne wo king (Úl imo acceso: 12-06-2021).
[42] Gua dian P ojec . Obscu aCam: The P i acy Came a.u l:h ps://gua dianp ojec .
in o/apps/o g.wi ness.sscphase1/ (Úl imo acceso: 12-06-2021).
83

Bibliog a ía
[43] B. Weis, S. Rowles y T. Ha djono. The G oup Domain o In e p e a ion. RFC
6407. In e ne Enginee ing Task Fo ce (IETF), oc . de 2011. u l:h ps :
//da a acke .ie .o g/doc/h ml/ c6407 (Úl imo acceso: 12-06-2021).
[44] Gua dian P ojec . Came aV app and he In o maCam Sys em.u l:h ps:
//gua dianp ojec .gi hub.io/in o macam-guide/en/In o macamGuide.
h ml (Úl imo acceso: 12-06-2021).
[45] Mohamed He eeda y Kianoosh Mokh a ian. s cAu h.u l:h ps://nsl.cs.
s u.ca/wiki/index.php/s cAu h (Úl imo acceso: 12-06-2021).
[46] Wikipedia. Aa on Swa z.u l:h ps://es.wikipedia.o g/wiki/Aa on_
Swa z (Úl imo acceso: 14-06-2021).
[47] VideoLan Wiki. Documen a ion:S eaming HowTo/S eaming o e IP 6. No . de
2014. u l:h ps : / / wiki . ideolan . o g / Documen a ion : S eaming _
HowTo/S eaming_o e _IP 6/#Limi a ions (Úl imo acceso: 12-06-2021).
[48] H. Schulz inne, A. Rao, R. Lanphie , M. Wes e lund y M. S ieme ling. Real-
Time S eaming P o ocol Ve sion 2.0. RFC 7826. In e ne Enginee ing Task
Fo ce (IETF), dic. de 2016. u l:h ps://da a acke .ie .o g/doc/
h ml/ c7826 (Úl imo acceso: 12-06-2021).
[49] And oid De elope s. Ne wo k.u l:h ps : / / de elope . and oid . com /
e e ence/and oid/ne /Ne wo k (Úl imo acceso: 12-06-2021).
[50] And oid De elope s. Connec i i yManage Ne wo kCallback.u l:h ps://
de elope .and oid.com/ e e ence/and oid/ne /Connec i i yManage .
Ne wo kCallback) (Úl imo acceso: 12-06-2021).
[51] And oid De elope s. Came aDe ice.u l:h ps : / / de elope . and oid .
com / e e ence / and oid / ha dwa e / came a2 / Came aDe ice # egula -
cap u e (Úl imo acceso: 12-06-2021).
84