Memoria PDF

PROJECTE FINAL DE CARRERA
Diseo de aplicaciones sobre VoIP con

mecanismos de geoposicionamiento
Estudis:
Enginyeria de Telecomunicaci
Autor:
Laura Duarte Domingo
Director/a: Marcel Fernndez Muoz

Any:
2014
A Isaac y a mi familia,
por la infinita paciencia que han
demostrado a lo largo de este viaje
II
Resumen
la VoIP se ha ido introduciendo cada vez en ms aspectos

de nuestra vida cotidiana. Este proyecto nace de la intencin de explorar las
posibilidades que sta nos ofrece. Con la decisin de trabajar siempre con tecnologa
open source se opta por utilizar dos tecnologas en auge en este momento. Asterisk,
utilizada cada vez en ms empresas por su facilidad de implantacin y flexibilidad.
No slo ofrece la posibilidad de implementar una centralita de telefona con VoIP de
forma econmica, sino que adems integra algunos servicios de valor aadido como los
ofrecidos por las ms potentes centralitas comerciales. Android, que ha experimentado
un gran crecimiento desde su aparicin, siendo uno de los dos sistemas operativos ms
utilizado para smartphones y que nos permite crear aplicaciones de forma gratuita y
con un gran abanico de posibilidades a nuestra disposicin.
N LOS LTIMOS AOS ,
El objetivo final es conseguir un proyecto que englobe estas tecnologas, con lo

que se realiza una plataforma de VoIP pensada para su utilizacin en una residencia
de ancianos (aunque la idea puede extrapolarse a otros escenarios). Utilizando
Asterisk como un servidor de VoIP, se crea adems una centralita de telefona con
reconocimiento de voz para la recepcin del centro, que comunicar las llamadas
del exterior con los diferentes departamentos. Utilizando Android se disean dos
softphones para los smartphones de los miembros de la residencia. Adems de las caractersticas bsicas, los softphones de los residentes estn diseados para controlar la
ubicacin de los mismos si se alejan demasiado de la residencia. De la misma manera,
los softphones de los trabajadores incluyen un sistema de comprobacin de la ubicacin
de los residentes en estos casos, as como la posibilidad de comprobar el sistema de
batera de los terminales de los residentes para que estas alertas no queden inutilizadas.
El desarrollo de este proyecto nos ha servido para darnos cuenta de la potencia que
tienen las herramientas que hemos utilizado y las amplias posibilidades que ofrecen
para proyectos futuros.
iii
IV
CONTENIDO
1 Introduccin
1.1 P LATAFORMA DE V O IP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 C ASOS DE USO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
10
11
2 Conceptos Generales
2.1 V O IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Q U ES LA V O IP? . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 A RQUITECTURA . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2.1 C OMPONENTES FUNDAMENTALES DE UNA RED V O IP .
2.1.2.2 T RANSMISIN DE LA V O IP POR LA RED . . . . . . . .
2.1.3 C DECS DE AUDIO . . . . . . . . . . . . . . . . . . . . . . . .
2.1.4 P ROTOCOLOS . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.4.1 SIP . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.4.1.1 E JEMPLO DE UNA COMUNICACIN SIP/RTP
2.1.4.2 H.323 . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.4.3 IAX . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 A STERISK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Q U ES A STERISK ? . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 C ONCEPTOS BSICOS . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 A RQUITECTURA . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3.1 S ERVICIOS Y FUNCIONALIDADES QUE OFRECE . . . . .
2.2.4 I NTEGRACIN CON LA RED CONMUTADA DE TELEFONA . . . . .
2.2.4.1 TARJETAS ANALGICAS . . . . . . . . . . . . . . . . .
2.2.4.2 TARJETAS DIGITALES . . . . . . . . . . . . . . . . . .
2.3 A NDROID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Q U ES A NDROID ? . . . . . . . . . . . . . . . . . . . . . . . .
13
13
13
14
14
15
16
17
17
18
20
20
21
21
22
23
25
26
26
26
27
27
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
2.3.7
2.3.8
2.3.1.1 A RQUITECTURA . . . . . . . . . . . . . .
2.3.1.2 A PLICACIONES . . . . . . . . . . . . . .
2.3.1.2.1 A NATOMA DE UNA APLICACIN
2.3.1.2.2 A NDROID M ANIFEST . . . . . .
A CTIVIDADES . . . . . . . . . . . . . . . . . . . .
2.3.2.1 C ICLO DE VIDA DE UNA A CTIVIDAD . . .
I NTENTS . . . . . . . . . . . . . . . . . . . . . . .
I NTERFAZ DE U SUARIO . . . . . . . . . . . . . . .
2.3.4.1 C OMPONENTES DE LA PANTALLA . . . . .
2.3.4.1.1 V ISTAS . . . . . . . . . . . . .
2.3.4.1.2 L AYOUTS . . . . . . . . . . . .
2.3.4.2 M ENS . . . . . . . . . . . . . . . . . .
2.3.4.3 D ILOGOS . . . . . . . . . . . . . . . . .
2.3.4.4 N OTIFICACIONES . . . . . . . . . . . . .
S ERVICIOS . . . . . . . . . . . . . . . . . . . . . .
B ROADCAST R ECEIVERS . . . . . . . . . . . . . .
P ERSISTENCIA DE D ATOS . . . . . . . . . . . . . .
2.3.7.1 S HARED P REFERENCES . . . . . . . . . .
2.3.7.2 B ASE DE DATOS LOCAL . . . . . . . . . .
LBS (L OCATION B ASED S ERVICES ) . . . . . . . .
3 Implementacin de la Centralita
3.1 O BJETIVO . . . . . . . . . . . . . . . . . .
3.2 E NTORNO DE SIMULACIN . . . . . . . . .
3.3 I NSTALACIN DEL ENTORNO . . . . . . . .
3.3.1 TARJETA D IGIUM TDM808 . . . . .
3.3.2 C ANCELADOR DE ECO O SLEC . . . .
3.3.3 G ESTOR DE CORREO . . . . . . . .
3.3.4 R ECONOCIMIENTO DE VOZ . . . . .
3.3.5 S OFTPHONE . . . . . . . . . . . . .
3.4 C ONFIGURACIONES . . . . . . . . . . . . .
3.4.1 TARJETA D IGIUM Y C ANCELADOR DE
3.4.2 C ANALES DAHDI . . . . . . . . . .
3.4.3 A STERISK . . . . . . . . . . . . . .
3.4.3.1 U SUARIOS . . . . . . . . .
3.4.3.2 D IALPLAN . . . . . . . . .
3.4.3.3 M SICA EN ESPERA . . . .
3.4.3.4 B UZN DE VOZ . . . . . .
3.4.3.5 F OLLOW M E . . . . . . .
3.4.3.6 S ALA DE C ONFERENCIAS .
3.4.3.7 C OLAS . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
ECO O SLEC
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
28
29
30
31
31
32
33
33
33
34
35
35
36
36
37
37
37
37
38
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
39
40
41
41
42
42
42
43
43
46
47
47
48
50
50
50
51
51
3.4.3.8 T RANSFERENCIA Y PARKING DE LLAMADAS .

C ENTRALITA PBX . . . . . . . . . . . . . . . . . . . .
3.4.4.1 I NTEGRACIN DEL RECONOCIMIENTO DE VOZ
3.4.5 E JECUCIN . . . . . . . . . . . . . . . . . . . . . . .
3.4.4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Implementacin de los Softphones

4.1 O BJETIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 I NSTALACIN Y CONFIGURACIN DEL ENTORNO DE TRABAJO . . . . .
4.2.1 D ESARROLLO DE APLICACIONES A NDROID . . . . . . . . . . .
4.2.2 B ASE DE DATOS REMOTA . . . . . . . . . . . . . . . . . . . .
4.2.2.1 E STRUCTURA DE LA BASE DE DATOS . . . . . . . . .
4.2.2.2 S CRIPTS PHP . . . . . . . . . . . . . . . . . . . . .
4.2.3 E XTENSIONES DE EMERGENCIA EN A STERISK . . . . . . . . .
4.3 D ESARROLLO DE LAS APLICACIONES . . . . . . . . . . . . . . . . . .
4.3.1 S OFTPHONE BSICO . . . . . . . . . . . . . . . . . . . . . . .
4.3.1.1 I NTEGRACIN DE LA V O IP EN LA APLICACIN . . . .
4.3.1.1.1 S ERVICE SIP . . . . . . . . . . . . . . . . .
4.3.1.1.2 C ALL R ECEIVER SIP . . . . . . . . . . . . .
4.3.1.1.3 S ERVICE B INDER . . . . . . . . . . . . . .
4.3.2 S OFTPHONE PARA RESIDENTES . . . . . . . . . . . . . . . . .
4.3.2.1 A LERTAS DE BATERA . . . . . . . . . . . . . . . . .
4.3.2.2 A LERTAS DE POSICIONAMIENTO . . . . . . . . . . .
4.3.2.2.1 A LERTS S ERVICE . . . . . . . . . . . . . .
4.3.3 S OFTPHONE PARA LA RECEPCIN DEL CENTRO . . . . . . . . .
4.3.3.1 C OMPROBACIN DE ALERTAS DE BATERA . . . . . .
4.3.3.2 C OMPROBACIN DE ALERTAS DE POSICIONAMIENTO
4.3.3.2.1 S HOW L OCATION M AP . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
52
55
56
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
65
65
66
67
67
68
70
70
71
75
76
83
84
84
86
86
88
92
93
95
97
5 Conclusiones y lneas de futuro

107
5.1 VALORACIN PERSONAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6 Bibliografa
111
A Instalaciones y configuraciones relacionadas con Asterisk

A.1 Instalaciones relacionadas con Asterisk . . . . . . . . . .
A.1.1 P RERREQUISITOS . . . . . . . . . . . . . . . . . .
A.1.2 DAHDI . . . . . . . . . . . . . . . . . . . . . . .
A.1.3 LIB PRI . . . . . . . . . . . . . . . . . . . . . . . .
A.1.4 A STERISK . . . . . . . . . . . . . . . . . . . . . .
A.1.5 C ANCELADOR DE ECO O SLEC . . . . . . . . . . . .
A.1.6 R ECONOCIMIENTO DE VOZ . . . . . . . . . . . . .
A.2 Archivos de configuracin Asterisk . . . . . . . . . . . .
113
113
113
113
114
114
116
116
117
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A.2.1
A.2.2
A.2.3
A.2.4
A.2.5
A.2.6
A.2.7
A.2.8
A.2.9
C ANALES DAHDI . . . . . . .
U SUARIOS . . . . . . . . . . .
D IALPLAN . . . . . . . . . . .
M SICA EN ESPERA . . . . . .
B UZN DE VOZ . . . . . . . .
A.2.5.1 G ESTOR DE CORREO
F OLLOW M E . . . . . . . . . .
S ALA DE C ONFERENCIAS . . .
C OLAS . . . . . . . . . . . . .
T RANSFERENCIA Y PARKING DE
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
LLAMADAS
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
117
118
119
125
125
126
127
127
127
127
B Instalaciones y configuraciones relacionadas con las aplicaciones Android 129

B.1 I NSTALACIN ENTORNO DE DESARROLLO PARA A NDROID . . . . . . . . . . 129
B.2 B ASE DE DATOS REMOTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
B.2.1 I NSTALACIN Y CONFIGURACIN . . . . . . . . . . . . . . . . . . . 135
B.2.2 S CRIPTS PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
B.2.2.1 S OFTPHONE RESIDENTES . . . . . . . . . . . . . . . . . . 141
B.2.2.2 S OFTPHONE RECEPCIN . . . . . . . . . . . . . . . . . . 144
B.3 E XTENSIONES DE EMERGENCIA A STERISK . . . . . . . . . . . . . . . . . . 147
LISTA DE FIGURAS
1.1 Plataforma de VoIP implementada para la residencia. . . . . . . . . . . .
11
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Principales componentes de una red VoIP. . . . . . . . . . . . . . . . . .

Trapezoide SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tramas SIP y RTP de una llamada telefnica de VoIP. . . . . . . . . . . .
Arquitectura modular de Asterisk. . . . . . . . . . . . . . . . . . . . . . .
Esquema de la arquitectura del sistema Android. . . . . . . . . . . . . .
Ciclo de vida de una actividad. . . . . . . . . . . . . . . . . . . . . . . .
Ejemplo de un Linear Layout con las vistas ms comunes y los dos tipos
de mens existentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
18
19
23
29
32
Esquema del entorno de simulacin. . . . . . . . . . . . . . . . . . . . .

Diagrama de flujo de la centralita (Inicio). . . . . . . . . . . . . . . . . .
Diagrama de flujo de la extensin 0 de la centralita (Recepcin). . . . .
Diagrama de flujo de la extensin 1 de la centralita (Trabajadora Social).
Diagrama de flujo de la extensin 2 de la centralita (Enfermera). . . . .
Diagrama de flujo de la extensin 3 de la centralita (Direccin). . . . . .
Diagrama de flujo de la extensin 4 de la centralita (Psicloga). . . . . .
Diagrama de flujo de la extensin 6 de la centralita (Men privado). . .
40
58
59
60
61
62
63
64
4.1 Tablas de la base de datos ubicada en el servidor. . . . . . . . . . . . . .

4.2 Men tab de la aplicacin con: a) Pantalla principal de la aplicacin. b)
Lista de contactos. c) Registro de llamadas. . . . . . . . . . . . . . . . .
4.3 a) Men principal de la aplicacin para los residentes. b) Dilogo que
aparece al cerrar las aplicaciones. . . . . . . . . . . . . . . . . . . . . . .
4.4 a) Listado de cuentas con men abierto. b) Men context de una cuenta
(opciones de la cuenta). . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
34
72
73
74
LISTA DE FIGURAS
4.5 Pantalla mostrada durante las llamadas en las aplicaciones. . . . . . . . 75
4.6 a) Notificacin que aparece cuando no hay ninguna cuenta activa. b)
Notificacin permanente que aparece cuando hay una cuenta logada en
el servidor SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.7 a) Notificacin que aparece al no poder registrar la cuenta especificada
en el servidor SIP. b) Notificacin que indica la existencia de llamadas
perdidas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.8 Listado de cuentas con acceso protegido por contrasea. . . . . . . . . . 85
4.9 Men principal del softphone para la recepcin del centro. . . . . . . . . 93
4.10 a) Notificacin de alertas de batera. b) Listado de alertas de batera. . . 95
4.11 a) Mapa de alertas con 2 usuarios (mostrando la informacin de uno de
ellos). b) Mapa con 2 usuarios fuera de la zona permitida (rojos) y un
usuario en seguimiento (verde). . . . . . . . . . . . . . . . . . . . . . . . 98
4.12 Dilogo mostrado cuando no hay alertas de posicionamiento en el mapa. 100
4.13 a) Men del mapa de alertas. b) Dilogo para iniciar un seguimiento. . . 104
B.1 Pantalla inicial del Android Manager. . . . . . . . . . . . . . . . . . . . .
B.2 Pantalla del Android Manager con todos los paquetes disponibles para
instalar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3 Pantalla del Android Manager para instalar licencias. . . . . . . . . . . .
B.4 Ventana para instalar el plugin ADT en Eclipse. . . . . . . . . . . . . . .
B.5 Pantalla con los paquetes necesarios para instalar el plugin ADT. . . . . .
B.6 Pantalla para aceptar las licencias de los paquetes del plugin ADT. . . . .
B.7 Pantalla de Eclipse con las opciones del Android SDK instaladas. . . . . .
B.8 Definicin de la ubicacin de la base de datos con usuario y contrasea.
B.9 Pantalla inicial del cliente grfico MySQL Navigator. . . . . . . . . . . . .
B.10 Pantalla de creacin de la tabla de alertas MyAlerts. . . . . . . . . . . . .
B.11 Pantalla de creacin de la tabla de coordenadas MyCoordinates. . . . . .
B.12 Base de datos Alcatraz con sus dos tablas: MyAlerts y MyCoordinates. . .
131
131
132
132
133
134
135
136
137
138
139
140
LISTA DE TABLAS
2.1 Cdecs de audio y protocolos soportados en Asterisk. . . . . . . . . . . .

2.2 Versiones de Android. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
28
3.1 Listado de usuarios SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.1 Clases e interfaz incluidos en la API SIP de Android.
76
. . . . . . . . . . .
LISTA DE TABLAS
1
Introduccin
la utilizacin de la VoIP ha tenido un gran crecimiento en el
mbito de las telecomunicaciones, pasando de ser algo lejano a ser una tecnologa
utilizada a diario. Sus mltiples caractersticas y ventajas son las que nos inspiraron
para realizar este proyecto, aunque los objetivos del mismo fueron cambiando y
amplindose a medida que avanzaba el proyecto.
N LOS LTIMOS AOS ,
La idea principal era realizar un proyecto basado en VoIP, cosa que se ha mantenido
a lo largo de todo el desarrollo. En principio, se empez con el estudio de Asterisk
con la idea de desarrollar una centralita telefnica, por ejemplo, para una empresa y
utilizarla como punto de partida. Al estudiar las posibilidades de Asterisk se decidi
realizar un cambio de direccin y crear algo que pudiera aprovechar el trabajo ya
realizado. Fue entonces cuando se decidi implementar una aplicacin Android que
utilizara la VoIP, como un softphone. Una vez terminada la aplicacin, se pens en
conseguir un valor aadido para el mismo, que acabara de redondear el proyecto y
que unificara la idea de la centralita con el softphone realizado.
Como ltimamente casi todas las aplicaciones Android utilizan de una forma u otra
la ubicacin del usuario, se decidi que el valor aadido de las aplicaciones estara
relacionado con el sensor GPS del smartphone. Para ello se enfoc el proyecto a un
hipottico caso real: una residencia de ancianos. Algunas residencias y centros de
da permiten a sus residentes salir a pasear o a comprar por sus alrededores. Como
algunos de ellos pueden perderse o desorientarse una vez en el exterior, se desea
mantener su ubicacin controlada cuando se alejan demasiado de la residencia.
As es como se consigui el proyecto final: una plataforma de VoIP diseada especialmente para su utilizacin en una residencia de ancianos. La centralita realizada
en Asterisk se convirti en la centralita de la residencia de ancianos. Por ltimo, a
partir del softphone inicial, se crearon dos softphones con distintas caractersticas: uno
CAPTULO 1. I NTRODUCCIN
diseado para los residentes del centro y el otro diseado especficamente para los
trabajadores, concretamente para el personal de la recepcin.
Los objetivos finales son:
* Implantacin de Asterisk.
* Centralita Asterisk con reconocimiento de voz para utilizar en la residencia de
ancianos. Se le aaden servicios de valor aadido como son: buzn de voz,
msica en espera, etc.
* Softphone para los residentes: softphone con un sistema de alertas de posicionamiento y de batera baja.
* Softphone para la recepcin del centro: softphone con un sistema que permita
gestionar las alertas generadas por los residentes.
* Implantacin de una base de datos LAMP para los sistemas de alertas.
Hoy en da, el sector de las telecomunicaciones es un mundo de evolucin rpida
y constante. Nuevas ideas y tecnologas salen al mercado en intervalos de tiempo
muy cortos. El desarrollo open source es mucho ms capaz de adaptarse a los rpidos
cambios tecnolgicos, lo que le proporciona una enorme ventaja competitiva. Por ese
motivo, todo el proyecto est basado en tecnologa open source.
1.1
P LATAFORMA
DE
V O IP
La plataforma de VoIP implementada para la residencia se puede ver en la figura 1.1

y consta de:
* Asterisk: se utiliza como servidor de VoIP (protocolo SIP) y servidor de media. En
Asterisk se implementa la centralita de telefona que se utilizar para las llamadas
entrantes a la residencia.
* LAMP: servidor y base de datos. Esta base de datos se utiliza para guardar y
consultar informacin sobre los residentes del centro (localizacin y estado de la
batera del telfono).
* Smartphones con sensor GPS: donde se instalan las aplicaciones desarrolladas
en Android.
10
1.2. C ASOS
DE USO
FIGURA 1.1: Plataforma de VoIP implementada para la residencia.
La comunicacin entre Asterisk y las aplicaciones instaladas en los smartphones se

realiza mediante el protocolo SIP. Las aplicaciones y la base de datos se comunican
mediante HTML. Las aplicaciones realizan peticiones HTML contra Apache, que ejecuta
los scripts PHP correspondientes, accediendo a la base de datos MySQL y devolviendo
los resultados obtenidos en formato JSON. No existe comunicacin entre Asterisk y la
base de datos.
1.2
C ASOS
DE USO
Residente sale de la zona permitida

Cuando un residente se aleja demasiado de la residencia, la aplicacin del residente
realiza de forma automtica una llamada SIP (perdida) a una extensin especial de
Asterisk. Entonces, Asterisk pone en contacto, mediante otra llamada SIP, al residente
con el softphone de recepcin para informar del evento. A la vez, la aplicacin del
residente empieza a enviar las coordenadas GPS del dispositivo a la base de datos.
Cuando se cuelga la llamada, el softphone de recepcin muestra un mapa de los
alrededores de la residencia con la ubicacin de los residentes que se encuentran fuera
de la zona permitida. La informacin mostrada en el mapa se obtiene de la base
de datos y se va actualizando de forma peridica. En caso de que el softphone de
11
CAPTULO 1. I NTRODUCCIN
recepcin est ocupado y no se pueda atender la llamada, se muestra igualmente el
mapa con las coordenadas.
Residente entra en la zona permitida
Cuando el residente vuelve a acercarse a la residencia, la aplicacin del residente
realiza de forma automtica una llamada SIP (perdida) a una extensin especial de
Asterisk. Entonces, Asterisk pone en contacto, mediante otra llamada, al residente
con el softphone de recepcin para informar del evento. A la vez, la aplicacin del
residente deja de enviar sus coordenadas GPS.
Cuando se cuelga la llamada, la aplicacin de recepcin muestra un mapa de los
alrededores de la residencia. Si quedan residentes fuera de la zona permitida, se
siguen mostrando sus coordenadas en el mapa. Si era el nico residente fuera de la
zona, aparece un dilogo en la pantalla informando de que no hay ningn residente
que localizar.
Recepcin pide un seguimiento
Desde la aplicacin de recepcin se puede solicitar la ubicacin de un residente que
no est fuera de la zona permitida. Al hacer la peticin, la aplicacin de recepcin
lanza una llamada a una extensin especial de Asterisk, especificando la identificacin
del residente que se quiere seguir. Entonces, Asterisk realiza una llamada perdida al
softphone del residente, que sirve para que ste empiece a enviar sus coordenadas
GPS a la base de datos. En el mapa de la aplicacin de recepcin se muestran tanto la
ubicacin de este residente como las de los que estn fuera de la zona permitida.
Cuando se desea finalizar el seguimiento, la aplicacin de recepcin lanza una
llamada a otra extensin especial de Asterisk indicando, igual que antes, el identificador del residente. Entonces, Asterisk realiza una llamada perdida al softphone
del residente, que sirve para que ste deje de enviar sus coordenadas a la base de datos.
Alerta de batera baja
Cuando el smartphone del residente detecta que el nivel de batera est por debajo del
15%, la aplicacin registra este hecho en la base de datos. La aplicacin de recepcin
comprueba, de forma peridica, la informacin sobre las alertas de batera en la base
de datos. Si hay alguna, muestra un listado de los residentes que se encuentran en esta
situacin.
12
2
Conceptos Generales
2.1
2.1.1
V O IP
Q U ES LA V O IP?
VoIP (Voice Over Internet Protocol) se refiere a los protocolos de comunicacin,

tecnologas, metodologas y tcnicas de transmisin involucradas en la transmisin de
comunicaciones de voz y sesiones multimedia sobre redes IP.
La red de telefona tradicional PSTN1 se basa en la conmutacin de circuitos para
establecer las comunicaciones y transportar la seal de voz y la sealizacin de un
extremo al otro. Las redes IP, en cambio, estn basadas en la conmutacin de paquetes.
Por tanto, para poder transportar la seal de voz sobre este tipo de redes, sta debe ser
digitaliza, codificada y empaquetada.
La utilizacin de la VoIP aporta mltiples ventajas, entre las cuales se destacan:
* Reduccin significativa de costes de gestin, administracin y mantenimiento al
aprovechar la red IP. Llamadas gratuitas entre miembros de redes VoIP puras (sin
enrutar llamadas a travs de la PSTN).
* Los datos y la voz se integran en una misma infraestructura. No hay necesidad de
utilizar redes diferentes para su transmisin.
* Posibilidad de transmitir ms de una llamada sobre la misma lnea telefnica.
* Ofrece servicios de valor aadido que suelen conllevar un cargo extra sobre la
PSTN o que incluso no se encuentran disponibles en algunos pases, como son la
identificacin de llamada, el voicemail, las conferencias, etc.
1
Public Switched Telephone Network
13
CAPTULO 2. C ONCEPTOS G ENERALES

* Proporciona total portabilidad. Mientras el usuario disponga de un telfono que
soporte VoIP conectado a la red, puede estar siempre localizable, sin importar su
ubicacin.
* Permite la integracin con otros servicios disponibles en Internet, incluyendo
videoconferencias, mensajera instantnea, etc.
Por otra parte, uno de los principales inconvenientes al utilizar conmutacin de
paquetes para VoIP es la dificultad de ofrecer QoS. La transmisin de voz tiene que ser
en tiempo real, por lo que es necesario que los paquetes lleguen de forma ordenada,
sin prdidas y garantizando una mnima tasa de transmisin (los retrasos superiores a
150 milisegundos afectan a la conversacin). Existen varios mecanismos que ayudan
a lograr estos objetivos, entre los que se encuentran: la supresin de silencios para
aprovechar mejor el ancho de banda, la compresin de cabeceras aplicando los
estndares RTP/RTCP y la priorizacin de los paquetes que requieran menor latencia.
2.1.2
A RQUITECTURA
2.1.2.1
C OMPONENTES
FUNDAMENTALES DE UNA RED
V O IP
La figura 2.1 muestra los elementos fundamentales de una red VoIP.

* Terminales: telfonos IP que pueden ser software o hardware.
Hardware: terminales fsicos con soporte VoIP nativo que pueden conectarse
directamente a una red IP.
Software: aplicaciones que simulan un telfono con soporte VoIP. Pueden
correr sobre cualquier dispositivo que disponga de conexin a la red (ordenadores, mviles, etc.).
* Servidor: provee el manejo y funciones administrativas para soportar el enrutamiento de llamadas a travs de la red. Este elemento recibe distintos nombres
en funcin del protocolo de sealizacin que se utilice. En un sistema basado en
H.323, el servidor recibe el nombre de Gatekeeper. En cambio, en un sistema SIP,
el servidor se conoce simplemente por Servidor SIP.
* Gateway: dispositivo que hace de enlace con la telefona fija tradicional. Acta de
forma transparente al usuario.
* Red IP: provee conectividad entre todos los terminales. La red IP puede ser una
red IP privada, una Intranet o Internet.
14
2.1. V O IP
FIGURA 2.1: Principales componentes de una red VoIP.
2.1.2.2
T RANSMISIN
DE LA
V O IP
POR LA RED
Los paquetes de VoIP se transmiten sobre la red IP utilizando el modelo TCP/IP con
algunas diferencias. Estas diferencias residen en los protocolos utilizados en cada capa
por los paquetes de datos y los paquetes de VoIP. En algunas capas se utilizan los
mismos para ambos; en otras, se utilizan protocolos propios para cada tipo.
A continuacin se detallan las funciones de las cinco capas del modelo TCP/IP con
los protocolos utilizados en los paquetes de VoIP:
* Aplicacin: Asegura la calidad y entregabilidad de los paquetes VoIP. Se utilizan
los siguientes protocolos:
NTP: Network Time Protocol. Permite sincronizacin, lo que nos asegura que
las seales son transmitidas y recibidas en el margen de tiempo adecuado
para asegurar calidad.
RTP: Real-time Transport Protocol. Proporciona funciones de transporte de
red extremo-a-extremo para las seales de voz digitales encapsuladas en los
paquetes VoIP.
RTCP: Real-time Transport Control Protocol. Monitoriza la entrega de las
seales de voz y proporciona funciones mnimas de control para asegurar la
entrega de los paquetes.
* Transporte: El protocolo UDP2 transporta los paquetes desde el origen al destino.
2
User Data Protocol
15

Aunque este protocolo no garantiza la entrega de los paquetes en destino, se
utiliza porque es ms rpido que TCP y en aplicaciones en tiempo real, como es
la voz, se prioriza la velocidad por encima de la fiabilidad.
* Red: Se aade la direccin IP al paquete. Esta direccin es la que utilizan los
dispositivos de enrutamiento para direccionar los paquetes durante la llamada y
es nica y propia de cada dispositivo (PC o telfono IP).
* Interfaz: Se aade la direccin fsica MAC3 al paquete. Esta direccin se obtiene
de la tarjeta NIC4 del propio dispositivo.
* Fsica: Se convierten los paquetes en seales elctricas o electro-pticas para
que se puedan transportar por la red.
2.1.3
C DECS DE AUDIO
Los cdecs5 son los medios por los cuales se puede convertir la seal de voz analgica a
digital para poder transportarla por la red. Se pueden definir como modelos matemticos usados para codificar y comprimir digitalmente informacin de audio analgica.
La mayora tienen en cuenta la capacidad del cerebro humano de interpretar la
informacin recibida a pesar de que est incompleta. Los algoritmos de compresin de
voz se aprovechan de nuestra tendencia a interpretar lo que creemos que debemos or
en vez de lo que realmente omos. El propsito de los algoritmos de codificacin es
encontrar un equilibrio entre eficiencia y calidad.
En VoIP se pueden utilizar una gran variedad de cdecs de audio. La eleccin para
cada caso vara en funcin de los requerimientos de calidad de sonido, ancho de banda
necesario y carga computacional. A continuacin se enumeran y describen algunos de
los ms utilizados.
G.711 Cdec fundamental de la PSTN estandarizado por la ITU en 1972. Tiene una
frecuencia de muestreo de 8 kHz y utiliza la modulacin PCM6 . Existen dos
mtodos de compansin7 : law en Amrica del Norte y Japn y a law en
el resto del mundo. La principal diferencia radica en el nmero de muestras
3
Medium Access Control

Network Interface Card
5
Abreviatura de codificador decodificador, aunque actualmente tambin se utiliza como abreviatura de compresor-decompresor.
6
Pulse Code Modulation.
7
Mtodo aplicable a seales para mejorar la transmisin de las mismas en canales limitados. Est
formado por dos procesos: compresin y expansin.
4
16
2.1. V O IP
por palabra (de 8 bits) que se utilizan: 14 muestras ( law) y 13 muestras a law. Ambos tienen un bit rate de 64 kbps. G.711 es el cdec base del
que derivan todos los dems y es el que conlleva una menor carga computacional.
G.729A Este cdec presenta una calidad de sonido muy buena teniendo en cuenta
el poco ancho de banda que utiliza, slo 8 kbps. Para ello utiliza el mtodo de
compresin de habla CS-ACELP8 . Debido a patentes, este cdec no se puede usar
sin pagar una licencia. Adems, la carga computacional de este algoritmo es
bastante elevada.
GSM9 Este cdec, que opera a 13 kbps, es el preferido de Asterisk. No requiere licencia
y ofrece un gran rendimiento en relacin a los requerimientos de CPU. La calidad
de sonido se considera ligeramente peor que la obtenida con G.729A.
2.1.4
P ROTOCOLOS
Los protocolos propios de las redes IP no fueron diseados para soportar streaming
en tiempo real. Los terminales de estas redes suelen esperar la recepcin de paquetes
perdidos, piden retransmisiones o simplemente los ignoran. Obviamente, la forma en
la que hablamos es totalmente incompatible con la manera en que los protocolos de
Internet transportan los datos: no se puede aceptar la prdida de letras o palabras o
los retrasos apreciables entre emisor y receptor.
El mecanismo para llevar a cabo una conexin de VoIP consta de una serie de
intercambios de sealizacin entre los terminales (y gateways intermedios) que
culminan en dos flujos de media continuos que transportan la conversacin (uno para
cada direccin). Manejar esto es el objetivo de los protocolos de VoIP. A continuacin
se definen los ms relevantes y utilizados.
2.1.4.1
SIP10
Protocolo desarrollado por el IETF11 para establecer, modificar y terminar sesiones multimedia. Estas sesiones incluyen llamadas de voz y vdeo, conferencias multimedia, etc.
8
Conjugate-Structure Algebraic-Code-Excited Linear Prediction. Mtodo de compresin del habla

que consiste en enviar cdigos correspondientes a los sonidos en vez del sonido muestreado real.
9
Global System for Mobile Communications
10
Session Initiation Protocol
11
Internet Engineering Task Force
17

FIGURA 2.2: Trapezoide SIP.
SIP es un protocolo de sealizacin de la capa de aplicaciones diseado especialmente para ser independiente de la capa de transporte; puede funcionar con los
protocolos UDP y TCP indistintamente. Est basado en texto, con una sintaxis similar
a la de otras familias de protocolos como HTTP y SMTP. La premisa de SIP es que cada
terminal de una conexin es un par; se utiliza una estructura cliente/servidor basada
en un modelo de peticin/respuesta para autenticar a sus usuarios.
Este protocolo utiliza el puerto 5060 para la sealizacin. No transporta medios
(voz y/o vdeo) entre extremos, para ello se utiliza el protocolo RTP. Se necesitan dos
puertos RTP para cada conexin (normalmente entre el 10.000 y el 20.000). Una
tipologa corriente para ilustrar la utilizacin de estos dos protocolos, conocida como
Trapezoide SIP, se puede observar en la figura 2.2. Cuando se desea realizar una
llamada de A a B, el establecimiento de la llamada y toda su sealizacin se realiza a
travs de servidores proxy mediante el protocolo SIP. En cuanto se inicia la llamada,
los terminales se comunican directamente entre ellos (si es posible), utilizando el
protocolo RTP, para que los datos no consuman recursos de los proxys. Debido a esta
separacin, SIP da problemas en infraestructuras de red con NAT12 y se suele necesitar
un servidor STUN para solucionarlos.
Las ventajas de este protocolo residen en su gran nivel de aceptacin y su arquitectura flexible. Actualmente, SIP ha reemplazado a H.323 como protocolo de eleccin
para la negociacin del transporte VoIP.
2.1.4.1.1 E JEMPLO DE UNA COMUNICACIN SIP/RTP

Para facilitar la comprensin del uso de los protocolos SIP y RTP en una comunicacin, se analiza a continuacin una llamada telefnica entre dos clientes SIP. En este
12
Network Address Translation. Proceso consistente en modificar la direccin IP de la informacin en

las cabeceras IP de los paquetes mientras estn en transito a travs de un dispositivo de enrutamiento
de trfico.
18
2.1. V O IP
FIGURA 2.3: Tramas SIP y RTP de una llamada telefnica de VoIP.
ejemplo hay tres agentes a tener en cuenta: los clientes 501 (IP 192.168.1.33) y 202
(IP 192.168.1.34), siendo el primero el que inicia y finaliza la llamada; y el servidor de
VoIP (IP 192.168.1.38). En la figura 2.3 se muestran las tramas ms relevantes de esta
llamada.
* Tramas 1-4: se realiza la negociacin inicial entre el llamante y el servidor. El
cliente 501 realiza una peticin al servidor (INVITE) para iniciar una comunicacin con el cliente 202. En esta peticin se especifica tambin la informacin
de la sesin: tipo de medio que se transportar (audio), puerto (4002) y protocolo (RTP), entre otros. El servidor confirma al cliente 501 la posibilidad de la
conexin (OK) especificando a su vez la informacin de la sesin: audio, puerto
11706 y protocolo RTP.
* Tramas 5-7: se realiza la negociacin entre el servidor y el llamado. El servidor
indica al cliente 202 que el cliente 501 quiere establecer una comunicacin con
l mediante otro INVITE con informacin de sesin: audio, puerto 14046 y protocolo RTP. El cliente 202 recoge esta peticin y cuando est preparado lo indica
al servidor comunicando su estado (Ringing). En este momento, el telfono del
cliente 202 empieza a sonar.
* Tramas 8-9: El cliente 202 descuelga el telfono. Esto se indica al servidor mediante un paquete (OK) con la informacin de la sesin: audio, puerto 4006 y
protocolo RTP. A partir de este momento, se inicia la conversacin.
* Tramas 10-17: Estas tramas representan el intercambio de datos (audio) entre los
dos terminales. Como se ha indicado antes, el protocolo utilizado para ello es el
RTP.
19

* Tramas 18-21: El cliente 501 cuelga el telfono, enviando al servidor una peticin
(BYE) para que comunique al cliente 202 que se va a finalizar la comunicacin.
El servidor confirma la peticin al cliente 501 e informa al otro cliente de la
finalizacin de la comunicacin, enviando otra peticin (BYE) especificando el
motivo de la finalizacin (normal clearing).
2.1.4.2
H.323
Protocolo desarrollado por la ITU13 en 1996 como medio para transmitir comunicaciones de voz, vdeo, datos y fax sobre redes IP manteniendo conectividad con la PSTN.
Originalmente, fue diseado para proporcionar un mecanismo de transporte IP para
videoconferencias y desde entonces ha evolucionado para cubrir todas las necesidades
de la VoIP. La sealizacin de llamadas est basada en el protocolo Q.391 de la ITU-T
y es adecuada para transmitir llamadas a travs de redes utilizando una mezcla de IP,
PSTN y ISDN.
H.323 es un protocolo relativamente seguro que no necesita elementos de seguridad adicionales a los requeridos por cualquier conexin va Internet. Igual que SIP,
utiliza el protocolo RTP para transportar las comunicaciones de medios y por tanto,
presenta los mismos problemas en topologas de red con NAT. Uno de los factores de
su poca popularidad reside en su complejidad.
2.1.4.3
IAX14
Protocolo abierto desarrollado por Digium con el propsito de establecer comunicaciones entre servidores Asterisk. Pese a ello, IAX no est limitado slo a Asterisk:
cualquiera puede usarlo y es soportado por varios proyectos de telecomunicaciones
open source.
Su objetivo principal es minimizar el ancho de banda usado en las transmisiones de
datos, voz y vdeo sobre IP y proporcionar soporte nativo para ser transparente a NAT.
Con ese fin, IAX multiplexa la sealizacin de canal y el flujo de datos sobre un nico
stream UDP entre los extremos, utilizando el puerto 4569.
El protocolo IAX original ha quedado obsoleto en favor de su nueva versin, IAX2.
Este permite la utilizacin de un gran nmero de cdecs de audio y puede transportar
cualquier tipo de datos. Adems, est considerado uno de los protocolos ms sencillos
13
14
International Telecommunication Union

Inter-Asterisk eXchange
20
2.2. A STERISK
para implementar en redes seguras.
2.2
2.2.1
A STERISK
Q U ES A STERISK ?
Asterisk es un software open source que implementa las funciones de una central
telefnica PBX15 . Este proyecto de comunicaciones fue creado en 1999 por Mark
Spencer, miembro fundador de la compaa Digium, principal desarrolladora de
Asterisk. Est publicado como open source bajo la licencia GNU GPL16 . Aunque
originalmente fue diseado para funcionar en Linux, tambin existen versiones para
otros sistemas operativos como BSD, Mac OS X, Solaris y Windows.
El proyecto Asterisk, en combinacin con el proyecto de telefona Zapata17 , ha
evolucionado con los aos, pasando de simplemente conectar llamadas de telfono
a convertirse en una plataforma que puede manejar voz, vdeo y texto a travs de
docenas de interfaces tanto fsicos como virtuales.
El poder de Asterisk reside en su naturaleza customizable. Es muy flexible, dando al
usuario la libertad de decidir lo que quiere implementar en funcin de sus necesidades.
Separa las funcionalidades y caractersticas de varias PBXs en componentes que pueden
interconectarse de manera que cada usuario puede customizar su solucin como mejor
le convenga. Esto diferencia a Asterisk de otras soluciones corporativas cerradas que
aportan una solucin nica, dejando muchas veces funcionalidades deseadas fuera.
Asterisk cuenta con toda una comunidad, liderada por Digium, que lo desarrolla y
soporta. Esta comunidad ha sido valorada como factor clave para en el crecimiento de
la VoIP. Entre sus miembros se encuentran profesionales del mbito de las telecomunicaciones, de redes y de tecnologas de la informacin.
15
Private Branch eXchange.

GNU General Public License.
17
Zapata Telephony Project: proyecto concebido por Jim Dixon, basado en la creacin de sistemas
telefnicos ms econmicos utilizando tarjetas PCI con la electrnica bsica para comunicarse con un
circuito de telefona. En vez de tener componentes caros en la tarjeta, el procesado de la seal digital
(DSP) se maneja en la CPU, por software. Fue la base para la creacin del interfaz DAHDI, que se
explicar ms adelante.
16
21
2.2.2
C ONCEPTOS BSICOS
Canales
Los canales son las conexiones que realizan una llamada entrante o saliente a la PBX
Asterisk. Cada llamada se realiza o recibe mediante un canal distinto. Asterisk no
hace ninguna distincin entre ellos. Entre los canales soportados ms importantes se
encuentran: SIP, IAX2, H323, MGCP, Console y DAHDI.
Dialplan
El dialplan es el corazn de Asterisk. Todos los canales que llegan al sistema pasan
por el dialplan, que contiene los scripts de flujo de llamadas que determinan el
manejo de las llamadas entrantes y salientes. Est dividido en secciones llamadas
contextos. Dentro de estos contextos encontramos las extensiones y la definicin de
las actuaciones o pasos que debe realizar el sistema al recibir una llamada para cada
extensin.
El dialplan puede escribirse de tres formas distintas: utilizando la sintaxis
tradicional de Asterisk (editanto extensions.conf); usando AEL18 (modificando
extensions.ael); o utilizando LUA (editando extensions.lua).
Contextos
Un contexto es, bsicamente, una coleccin de extensiones. Cuando se crean canales,
estos siempre deben ubicarse en un contexto. Esto implica que las llamadas originadas
desde ese canal se ubicarn en dicho contexto.
El objetivo ms importante de los contextos es ofrecer seguridad, evitando que las
diferentes secciones del dialplan interacten entre ellas. Los canales slo podrn
realizar llamadas hacia las extensiones incluidas en su contexto o acceder a funcionalidades propias del mismo.
Existen dos contextos especiales: general (define configuraciones generales para
todos los contextos) y globals (contiene variables disponibles para todo el dialplan).
Extensiones
Al contrario que en los sistemas telefnicos convencionales, donde las extensiones
se asocian a terminales, interfaces, mens, etc., en Asterisk las extensiones se
asocian a un listado de instrucciones a ejecutar. Estas instrucciones pueden tanto
llamar a un nmero de telfono como acceder al buzn de voz o cualquier otra funcin.
18
Asterisk Extension Logic
22
2.2. A STERISK
FIGURA 2.4: Arquitectura modular de Asterisk.
Cada paso o instruccin dentro de una extensin se compone de tres componentes:

nombre (o nmero) de la extensin; prioridad (cada extensin puede incluir varios
pasos, el numero de paso se llama prioridad); la aplicacin (o instruccin) que se debe
ejecutar en cada paso. Por tanto, la forma de definir una instruccin en el dialplan es
la siguiente:
exten name, priority, application().
2.2.3
A RQUITECTURA
Asterisk est formado por un conjunto de bloques o mdulos que el usuario tiene
a su disposicin para crear aplicaciones de comunicacin. Por este motivo se hace
referencia a Asterisk con los trminos tool-kit o plataforma de desarrollo.
Estos mdulos son componentes que proporcionan una funcionalidad especfica,
por ejemplo, un driver para un canal o un recurso que permite la conexin con una
tecnologa externa. Estos pueden aadirse al sistema en funcin de las necesidades
del usuario/desarrollador. Los mdulos que se quieran utilizar suelen definirse en el
momento de la instalacin, aunque tambin pueden aadirse a posteriori, especificndolos en el archivo de configuracin adecuado.
En la figura 2.4 se representan los tipos de mdulos que se pueden encontrar en
Asterisk. A continuacin se incluye un listado con una breve descripcin de cada uno
de ellos y algunos ejemplos.
* Applications: Aplicaciones del dialplan. Se utilizan en el fichero extensions.conf
23

para definir las diversas acciones que se pueden aplicar a una llamada. Por ejemplo: marcar un nmero, transferir una llamada, acceder al buzn de voz, etc.
* Bridging modules: Realizan bridging de canales en la nueva Bridging API. Cada
uno proporciona funcionalidades diferentes, dependiendo de las necesidades del
canal.
* CDR modules (Call Detail Recording): Diseados para facilitar tantos mtodos
de guardar detalles de las llamadas como sea posible. Estos detalles pueden
guardarse en un archivo (por defecto), una base de datos, RADIUS o syslog.
* CEL modules (Channel Event Logging): Proporcionan control sobre los informes de
actividad de una llamada. El uso de estos mdulos requiere una planificacin del
dialplan ms cuidadosa.
* Channel drivers: Necesarios para realizar llamadas. Cada driver es especfico para
el protocolo o tipo de canal que soporta (SIP, IAX2, ISDN, DAHDI, etc.). Este
mdulo acta como un gateway con el ncleo de Asterisk. La lista de protocolos
soportados por Asterisk se puede ver en la tabla 2.1.
* Codec translators: Permiten la conversin de formatos de streams de audio entre
llamadas. Por ejemplo: convertir una llamada que proviene de una canal que
utiliza G.711 a otro que utiliza el cdec G.729. El listado de cdecs que Asterisk
soporta se puede ver en la tabla 2.1.
* Format interpreters: Realizan la misma funcin que los codec translators pero en
archivos, en vez de canales. Por ejemplo: cambiar el formato a una grabacin de
un men en GSM para que se pueda reproducir en un canal que no soporte este
formato.
* Dialplan functions: Complementan a las aplicaciones del dialplan. Proporcionan
mejoras para diversas funcionalidades de Asterisk, como el manejo de cadenas,
conectividad a bases de datos, acceso a la blacklist, etc.
* PBX modules: Mdulos perifricos que proporcionan mecanismos de control y
configuracin mejorados.
* Resource modules: Integran a Asterisk con recursos externos. Por ejemplo: permitir la operatividad con bases de datos ODBC, la utilizacin de la msica en espera,
grabar una llamada, etc.
* Addons modules: Mdulos desarrollados por la comunidad con usos o derechos
de distribucin diferentes de los del cdigo principal. Figuran en un directorio
diferente y no se compilan e instalan por defecto.
24
2.2. A STERISK
TABLA 2.1: Cdecs de audio y protocolos soportados en Asterisk.
Cdecs de audio
Protocolos
G.711 (a-law y u-law), G.726, G.723.1, G.729A, GSM, iLBC, Speex,

ADPCM, Linear, MP3
SIP, H.323, IAX e IAX2, MGCP, SCCP, UNISTIM
* Test modules: Se utilizan por el equipo de desarrollo de Asterisk para validar

cdigo nuevo. Estn cambiando y aadindose nuevos de forma constante.
2.2.3.1
S ERVICIOS
Y FUNCIONALIDADES QUE OFRECE
Como se ha comentado anteriormente, Asterisk permite la implementacin de los

mismos servicios que una PBX clsica, aadiendo nuevas funcionalidades. Se puede
colocar delante de una PBX convencional para que acte como gateway, o detrs de
ella, para utilizarlo como servidor de aplicaciones perifrico.
Algunos de los servicios que ofrece se listan a continuacin:
* Manejo de llamadas entrantes y generacin de llamadas salientes.
* Buzn de voz.
* Msica en espera (desde archivos o desde emisoras de radio por Internet).
* Gestin de colas de llamadas entrantes.
* Transferencia y desvo de llamadas.
* Salas de conferencia con dos o ms usuarios.
* Gestin de listas negras.
* Grabacin y monitorizacin de llamadas en curso.
* Implementacin de AA (Automatic Attendants) y IVR (Interactive Voice
Response).
* Manejo de llamadas externo en cualquier lenguaje de programacin o scripting a
travs de AGI (Asterisk Gateway Interface).
* Notificacin de eventos e integracin CTI va AMI (Asterisk Manager Interface).
* Integracin con bases de datos y servicios web.
25

* Sintetizacin del habla (text-to-speech) en varios idiomas y dialectos utilizando
programas de terceros.
* Reconocimiento de voz en varios idiomas usando motores de reconocimiento de
voz de terceros.
2.2.4
I NTEGRACIN CON LA RED CONMUTADA DE TELEFONA
Asterisk es capaz de comunicarse con diferentes tecnologas. Normalmente, esta

comunicacin se efecta mediante conexiones de red. Sin embargo, conexiones con
tecnologas mas tradicionales, como la red conmutada de telefona, requieren un
hardware especfico.
2.2.4.1
TARJETAS
ANALGICAS
Las tarjetas analgicas permiten conectar el servidor Asterisk con la red conmutada de
telefona y/o con telfonos analgicos. Existen dos tipos:
* FXO (Foreign eXchange Office): permiten interactuar con los portadores de la red
de telefona.
* FXS (Foreign eXchange Station): permiten interactuar con telfonos analgicos.
Las tarjetas analgicas diseadas por Digium reciben el nombre de TDM y pueden
interactuar tanto con lneas externas como con telfonos analgicos en funcin de
los mdulos presentes en la tarjeta. Al inspeccionar visualmente estas tarjetas, se
diferencian los tipos de mdulos por el color: FXO (rojos); FXS (verdes).
2.2.4.2
TARJETAS
DIGITALES
Las tarjetas digitales permiten conectar Asterisk con una red digital RDSI. De esta clase
de tarjetas se encuentran dos tipos:
* Bsicas (BRI): cada puerto BRI tiene dos canales de voz ms uno de sealizacin,
permitiendo mantener dos conversaciones de forma simultnea.
* Primarios (PRI): cada primario tiene 30 canales de voz ms uno de sealizacin,
permitiendo establecer unas 30 conversaciones simultneas.
En un sistema Asterisk que requiera el uso de estas tarjetas para conectarse a la red
telefnica ser necesaria la instalacin de:
26
2.3. A NDROID
* DAHDI19 : Interfaz utilizado para controlar una gran cantidad de tarjetas analgicas y/o digitales.
* LibPRI: librera que implementa sealizacin para ISDN-PRI e ISDN-BRI, necesaria para las tarjetas digitales.
2.3
2.3.1
A NDROID
Q U ES A NDROID ?
Android es un sistema operativo basado en Linux para dispositivos mviles como

smartphones y tablets. Est desarrollado por la Open Handset Alliance20 , encabezada
por Google. Inicialmente desarrollado por Android, Inc., fue comprado por Google en
2005 como parte de su estrategia para entrar en el mercado de los mviles.
Su cdigo est publicado bajo la licencia de cdigo abierto Apache, por lo que
cualquiera que quiera trabajar con Android puede descargarlo y editarlo. Esta cualidad
hace de Android un producto muy atractivo, ya que permite competir con el gran
despliegue y xito que el iPhone de Apple est teniendo en el mercado.
Este SO est basado en un sistema intuitivo que permite a los usuarios navegar
por los distintos mens y aplicaciones del terminal de forma sencilla, sin necesidad de
recurrir a un manual de instrucciones que, a veces, es incluso inexistente.
A lo largo de su historia, Android ha pasado por diversas versiones. En la tabla 2.2
se recogen las principales.
Para la realizacin de este proyecto se ha escogido la versin 2.3.3 (Gingerbread) ya
que, al inicio del proyecto, es la que tena una mayor distribucin entre los terminales
Android.
2.3.1.1
A RQUITECTURA
El sistema operativo Android est dividido en cinco secciones distribuidas dentro de

cuatro capas principales representadas en la figura 2.5.
19
Digium Asterisk Hardware Device Interface

Open Handset Alliance: consorcio de 86 compaas en los sectores de hardware, software y telecomunicaciones, dedicados a fomentar estndares abiertos para los dispositivos mviles.
20
27

TABLA 2.2: Versiones de Android.
Versin
Nombre
Nivel API
1.5
Cupcake
3
1.6
Donut
4
2.1
Eclair
7
2.2
Froyo
8
2.3 - 2.3.2
Gingerbread
9
2.3.3 - 2.3.7
10
3.1
Honeycomb
12
3.2
13
4.0 - 4.0.2 Ice Cream Sandwich
14
4.0.3 - 4.0.4
15
4.1.x
Jelly Bean
16
4.2.x
17
4.3
18
4.4
KitKat
19
* Linux Kernel: kernel en el que se basa Android. Esta capa contiene todos los
drivers de bajo nivel para los componentes hardware de un terminal.
* Libreras: contiene todo el cdigo que proporciona las caractersticas principales
del SO Android.
* Android Runtime: Contiene una conjunto de libreras que permiten a los desarrolladores escribir aplicaciones Android usando el lenguaje Java. Tambin incluye
la mquina virtual Dalvik, que est diseada y optimizada especficamente para
terminales Android.
* Application Framework: expone las diversas capacidades del SO Android a los
desarrolladores para que puedan utilizarlas en sus aplicaciones.
* Aplicaciones: todas las aplicaciones instaladas en un terminal: aplicaciones incluidas en el propio terminal (telfono, contactos, navegador, etc.), aplicaciones
descargadas e instaladas a travs de Google Play (antiguo Android Market) y
aplicaciones desarrolladas por el propio usuario.
2.3.1.2
A PLICACIONES
Las aplicaciones Android se escriben en lenguaje Java. Las herramientas Android SDK
compilan el cdigo, junto con los datos y archivos necesarios, en un paquete Android
(archivo con extensin .apk). Este archivo es lo que utilizan los dispositivos Android
28
2.3. A NDROID
FIGURA 2.5: Esquema de la arquitectura del sistema Android.
para instalar la aplicacin.

El sistema Android implementa el principio del mnimo privilegio. Es decir, cada
aplicacin tiene acceso slo a los componentes que requiere para ejecutarse y a nada
ms. Esto crea un entorno seguro en el que una aplicacin no puede tener acceso a
partes del sistema para el que no tenga permisos.
2.3.1.2.1 A NATOMA DE UNA APLICACIN

La estructura de una proyecto para una aplicacin Android est formada por las
siguientes carpetas:
* src: contiene todos los archivos de cdigo .java.
* Android 2.3.3 library: contiene el archivo android.jar donde se encuentran todas las libreras necesarias.
29

* gen: contiene el archivo R.java, que referencia todos los recursos del proyecto.
No hay que modificarlo ya que se regenera cada vez que se realiza una compilacin.
* assets: contiene todos los bienes de la aplicacin: HTML, archivos de texto, bases
de datos, etc.
* res: contiene todos los recursos de la aplicacin: imgenes, layouts, strings, etc.
En la carpeta res/layout se encuentran los archivos XML, donde se definen las
IUs de las distintas actividades de la aplicacin.
* AndroidManifest.xml: archivo muy importante que contiene informacin detallada de la aplicacin. En l se especifican varios aspectos de la misma: los
permisos, las actividades involucradas y los intent-filters, entre otros.
2.3.1.2.2 A NDROID M ANIFEST

Toda aplicacin debe tener un archivo con el nombre AndroidManifest.xml. En
l se define la informacin detallada sobre la aplicacin que el sistema Android debe
tener antes de poder ejecutar cualquier cdigo de la misma.
Los aspectos ms importantes que deben especificarse en el AndroidManifest son:
* Nombre del paquete Java para la aplicacin.
* Nivel mnimo de la API Android que la aplicacin requiere para ejecutarse.
* Descripcin de todos los componentes de la aplicacin: actividades, servicios,
broadcast receivers y content providers. Para cada componente se especifica: el
nombre de la clase que los implementa y lo que pueden hacer.
* Permisos que requiere la aplicacin para acceder a partes protegidas de la API e
interactuar con otras aplicaciones.
* Aspectos de hardware y software usados o requeridos por la aplicacin.
* Libreras que la aplicacin necesita (aparte de las propias del framework de
Android).
30
2.3. A NDROID
2.3.2
A CTIVIDADES
La actividad es el componente fundamental de la mayora de aplicaciones Android. El

concepto de actividad va ligado a la idea de interfaz de usuario (IU). Cada actividad
nos muestra una interfaz de usuario y nos permite interactuar con ella, programando
el comportamiento de la aplicacin segn la interaccin del usuario.
Una aplicacin consiste, normalmente, en varias actividades relacionadas de alguna
manera entre ellas. Para completar la aplicacin se pueden utilizar otros componentes
como los servicios, los broadcast receivers, etc. Aunque no es comn, si la aplicacin
no requiere de intervencin por parte del usuario, puede no tener ninguna actividad.
2.3.2.1
C ICLO
DE VIDA DE UNA
A CTIVIDAD
La clase Actividad define una serie de mtodos imprescindibles que gobiernan su ciclo
de vida y cuya implementacin es crucial para desarrollar aplicaciones flexibles y
robustas.
El ciclo de vida de una actividad y los mtodos que lo definen pueden observarse en
la figura 2.6.
* onCreate(): se llama cuando una actividad se crea por primera vez. Aqu se
deben inicializar los componentes esenciales de la actividad, as como especificar
el layout que se usar como IU. Este mtodo tambin recupera el estado previo
de la actividad, en caso de haber sido guardado en una ejecucin anterior.
* onStart(): se llama cuando la actividad aparece en la pantalla del usuario.
* onResume(): se llama cuando la actividad empieza a interactuar con el usuario.
En este estado, la actividad est activa, al frente de la pantalla.
* onPause(): se llama cuando la actividad actual se pausa y se reanuda la actividad anterior. En este estado la actividad actual sigue viva, mantiene su estado
y su informacin, pero puede destruirse por el sistema en caso de problemas de
memoria. Aqu se debe guardar cualquier cambio que se haya hecho y que se
quiera conservar, en caso de que la actividad sea destruida. Tambin se deben
detener animaciones u otras cosas que puedan consumir CPU.
* onStop(): se llama cuando la actividad deja de ser visible por el usuario. En este
estado, igual que onPause(), el sistema puede destruir la actividad en caso de
necesitar la memoria ocupada por sta.
31

FIGURA 2.6: Ciclo de vida de una actividad.
* onDestroy(): se llama cuando la actividad es destruida por el sistema. Esto puede

ocurrir de forma voluntaria (desde la propia programacin de la aplicacin) o de
forma involuntaria (cuando el sistema necesita conservar memoria).
* onRestart(): se llama cuando la actividad se haba parado y es reanudada de
nuevo.
2.3.3
I NTENTS
El intent es un concepto nico y muy importante en Android. Se puede definir como

una declaracin de necesidad, una descripcin abstracta de una operacin que se
quiere realizar. Se utiliza principalmente para: lanzar una actividad/servicio/broadcast
receiver o hacer que una actividad/servicio existente haga algo nuevo.
32
2.3. A NDROID
En funcin de las necesidades del usuario, los objetos de tipo Intent pueden
utilizarse para pasar informacin necesaria al componente que los recibe o al sistema
Android.
Los parmetros principales son los siguientes:
* component name: nombre del componente que recibir el intent (componente
que se quiere lanzar).
* action: descripcin de la accin que se quiere realizar.
* data: la informacin requerida para realizar la accin, expresada en forma de Uri.
* extras: pares de tipo key/value para pasar informacin adicional al componente
que recibir el intent.
Por otra parte, el intent filter sirve para especificar los tipos de intents que un
componente puede recibir. Estos filtros no se definen en el cdigo, sino en el Android
Manifest. Los parmetros principales son: action, category y data.
Todas las categoras aadidas a un objeto Intent tienen que coincidir con el Intent
Filter para que el componente deseado pueda ser invocado.
2.3.4
I NTERFAZ DE U SUARIO
Una actividad, por si misma, no tiene presencia en la pantalla, sino que debe dibujar
los elementos de la IU utilizando objetos de tipo View (vistas) y ViewGroup (layouts).
Normalmente, la IU se define mediante un archivo XML, donde se especifican todos sus
componentes. Dependiendo de las necesidades del usuario, la IU puede programarse
dinmicamente, en tiempo de ejecucin.
2.3.4.1
C OMPONENTES
DE LA PANTALLA
2.3.4.1.1 V ISTAS
Una vista es un widget que tiene presencia en la pantalla. Una ViewGroup proporciona el layout en el que se ordenan todas las vistas que aparecen en la pantalla de una
actividad. A travs de las vistas, el usuario es capaz de interactuar con la actividad.
Las vistas ms comunes son:
* TextView: se utiliza para mostrar texto al usuario.
* EditText: muestra texto y permite al usuario editar su contenido.
33

FIGURA 2.7: Ejemplo de un Linear Layout con las vistas ms comunes y los dos tipos
de mens existentes.
* Button: representa un botn pulsable. Al pulsar, se ejecuta la accin que se le

haya programado.
* ToggleButton: botn con dos estados (on/off) que se muestran con un indicador
de luz.
* ListView: muestra una lista de elementos.
El aspecto de la mayora de estas vistas se puede observar en la pantalla mostrada
en la figura 2.7.
2.3.4.1.2 L AYOUTS
Los layouts son la arquitectura de la IU en una actividad: definen la estructura de la
pantalla y la posicin de los elementos que la componen (vistas).
Los layouts ms comunes son:
* Linear Layout: organiza las vistas en un sola fila o columna.
34
2.3. A NDROID
* Table Layout: agrupa las vistas en forma de tabla (filas y columnas).
* Relative Layout: permite especificar la posicin de las vistas en relacin a otras o
al propio layout.
En la prctica, es comn combinar varios layouts en un sola actividad para disear
la apariencia deseada para la IU.
No todos los componentes de la interfaz de usuario deben construirse mediante
objetos View y ViewGroup. Dentro de una aplicacin, Android proporciona varios
componentes que tienen un layout estndar predefinido de manera que el usuario slo
necesita definir su contenido, sin preocuparse de la forma. Entre estos componentes se
encuentran: los mens, los dilogos y las notificaciones.
2.3.4.2
M ENS
Los mens se utilizan en las actividades para mostrar opciones adicionales que no se
ven directamente en la IU. En Android nos encontramos con dos tipos:
* Options menu: muestra opciones relacionadas con la actividad actual. En la versin de Android 2.3 o inferior, este men se muestra en la parte baja de la pantalla
al pulsar la tecla MENU del terminal. A partir de la versin 3.0, estas opciones
se muestran en la Action Bar, que es una barra situada permanentemente en la
parte superior de la actividad. En esta barra aparecen accesos directos del men
y un listado de opciones.
* Context menu: muestra opciones relacionadas con una vista especfica de la actividad. Este men se activa al mantener pulsada una vista de la IU. Aparece como
una lista flotante de opciones en la pantalla. Se puede definir un context menu
diferente para cada elemento de la IU.
El aspecto de estos mens se puede observar en la pantalla mostrada en la figura 2.7.
2.3.4.3
D ILOGOS
Un dilogo es una ventana pequea que aparece al frente de la actividad actual. Los
dilogos interrumpen la actividad para notificar algo al usuario o para realizar algunas
tareas relacionadas con la actividad en curso.
Los tipos ms utilizados son:
* Alert Dialog: se usa desde las actividades para obtener una confirmacin del
usuario antes de ejecutar una accin.
35

* Progress Dialog: se usa para mostrar algn progreso relativo a la actividad, como
por ejemplo, el estado de una descarga.
2.3.4.4
N OTIFICACIONES
Las notificaciones se utilizan para informar al usuario de un evento ocurrido en la

aplicacin. Algunas notificaciones pueden ser simplemente avisos, otras pueden
requerir una interaccin por parte del usuario.
Los tipos de notificaciones ms utilizados son:
* Toast Notification: un mensaje en forma de pop up que aparece en la pantalla
durante unos segundos. Esta notificacin no acepta ningn tipo de interaccin
por parte del usuario.
* Status Notification: aparece en la barra de estado del sistema, en la zona marcada
como Notificaciones. Muestra un icono y un mensaje. Su aparicin puede
indicarse mediante una alerta sonora o de vibracin. Si se necesita que el usuario
realice una accin, se puede programar el lanzamiento de un intent al pulsar
sobre el mensaje.
2.3.5
S ERVICIOS
Un servicio es un componente de la aplicacin que corre en background, sin necesidad

de interactuar con el usuario. Se utiliza para aplicaciones que necesiten realizar operaciones sin mostrar una interfaz de usuario, por ejemplo, la descarga de contenidos de
una pgina web.
Un servicio puede ser de dos formas:
* Started: cuando un componente de la aplicacin lanza el servicio con el mtodo
StartService(). Al iniciar el servicio, ste corre indefinidamente, incluso si se cierra
la aplicacin que lo haba iniciado. Al finalizar la tarea requerida, se debe detener
el servicio lo antes posible para liberar los recursos que est utilizando.
* Bound: cuando uno o ms componentes de la aplicacin se enlazan con el servicio. Un bound service permite a los componentes interactuar con el servicio,
utilizando sus mtodos pblicos. Este tipo de servicio sigue corriendo hasta que
no hay ningn componente enlazado a l.
Como en el caso de este proyecto, puede crearse un servicio que combine estos dos
tipos: inicializado por un componente y con varios componentes enlazados.
36
2.3. A NDROID
2.3.6
B ROADCAST R ECEIVERS
Un broadcast receiver es un componente de la aplicacin que permite recibir eventos

emitidos u originados por el sistema y/o por otras aplicaciones. Estos avisos se reciben
en forma de intents.
Normalmente, este componente se utiliza como una puerta hacia otros componentes y se pretende que haga el mnimo trabajo posible: recibe el evento y activa
otro componente para que lo maneje. Aunque la aplicacin no est funcionando, el
broadcast receiver puede continuar escuchando por si llegan nuevos eventos.
2.3.7
P ERSISTENCIA DE D ATOS
Android proporciona diversas opciones para guardar datos de la aplicacin. La opcin

que se escoja depender de las necesidades que se tengan (si los datos deben ser
privados o accesibles para otras aplicaciones) y del tamao requerido.
2.3.7.1
S HARED P REFERENCES
Esta opcin consiste en un mecanismo ligero que permite guardar datos simples de
la aplicacin, por ejemplo, las preferencias de usuario. El objeto SharedPreferences
guarda, de forma automtica, en un archivo XML, los datos que se especifiquen con
el formato de pares key/value. Estos datos persisten aunque se finalice la aplicacin
(tanto de forma manual como forzada por el sistema).
2.3.7.2
B ASE
DE DATOS LOCAL
Android ofrece tambin la posibilidad de guardar informacin en una base de datos,

usando el sistema SQLite database. Esta base de datos local es propia de cada aplicacin
y, por tanto, es accesible desde cualquier clase de la misma, pero no desde fuera de la
aplicacin.
La base de datos local puede crearse en tiempo de ejecucin (como es el caso
de este proyecto) o en la etapa de diseo de la aplicacin. Para esto ltimo existen
herramientas como el SQLite Database Browser.
37
2.3.8
LBS (L OCATION B ASED S ERVICES )
La aparicin de los GPS en los smartphones ha propiciado una demanda de servicios

relacionados con este dispositivo. Con este fin, Google permite la utilizacin de su
programa Google Maps para mostrar mapas y datos relacionados en las aplicaciones
Android.
Android, por su parte, proporciona una serie de herramientas de localizacin
que permiten obtener datos de posicionamiento que el usuario puede utilizar segn
convenga: mostrar en mapas, alertas de posicin, etc.
Las principales funciones que se pueden realizar con los LBS en Android son las
siguientes:
* Mostrar mapas, navegar por ellos, hacer zoom y cambiar de vista (satlite, callejero, trfico).
* Navegar a una localizacin especfica.
* Obtener la localizacin pulsada en un mapa.
* Geocoding y geocoding inverso.
* Aadir objetos que se dibujen encima del mapa, como por ejemplo, marcadores o
letreros.
* Obtener datos de localizacin del terminal de distintos proveedores: receptor
GPS, red de telefona y red WiFi.
* Determinar la localizacin del terminal y obtener actualizaciones peridicas de la
misma.
* Monitorizar una localizacin: mediante alertas de proximidad, puede programarse el comportamiento de una aplicacin al acercarse o alejarse de una localizacin concreta.
Si se desea utilizar Google Maps hay que especificarlo en la build target del proyecto,
ya que Google Maps no forma parte del Android SDK estndar.
38
3
Implementacin de la Centralita
3.1
O BJETIVO
en la introduccin de este documento, uno de los objetivos del proyecto es la implantacin de un sistema de telefona VoIP con la
implementacin de una centralita telefnica para la residencia de ancianos. Para ello
se ha escogido Asterisk, ya que permite, de forma sencilla, construir una PBX en un
ordenador convencional.
OMO SE HA COMENTADO
3.2
E NTORNO
DE SIMULACIN
del sistema de VoIP y la PBX de la residencia se realiza en un

entorno de simulacin donde se ejecutarn todas las pruebas necesarias para comprobar su correcto funcionamiento. En la figura 3.1 se puede observar un esquema de
este entorno, que consta de los siguientes elementos:
A IMPLEMENTACIN
* Un ordenador convencional con sistema operativo Ubuntu 10.04 que se utiliza

como servidor con la IP pblica 147.83.39.132.
* Una tarjeta Digium TDM808 que se utiliza para conectar Asterisk a la red de
telefona. En este caso, la tarjeta se conecta a Ibercom, que es una red privada
virtual de Movistar utilizada en el mbito de las comunicaciones de empresa.
* Dos cables de telfono que conectan los puertos 1 y 2 de la tarjeta con las extensiones internas 17479 y 17480 de la red Ibercom.
* Un telfono analgico conectado a la extensin interna 54081 que se utiliza para
comprobar el funcionamiento de la PBX.
39
CAPTULO 3. I MPLEMENTACIN
DE LA
C ENTRALITA
FIGURA 3.1: Esquema del entorno de simulacin.
3.3
I NSTALACIN
DEL ENTORNO
L PRIMER PASO PARA LA IMPLEMENTACIN
de la centralita es instalar el software y
hardware necesario en el servidor.
Normalmente, Asterisk se suele instalar conjuntamente con otros dos paquetes:

DAHDI y libPRI. Si se deseara implementar una centralita que utilizara solamente
VoIP, con el paquete Asterisk tendramos suficiente. En este caso, al disponer de una
tarjeta para conectar con la red de telefona, debemos instalar los controladores de
harware de DAHDI. Adems, tambin instalamos la librera para puertos primarios
libPRI. Aunque de momento no se desea conectar con una red RDSI, se recomienda su
instalacin antes que Asterisk por si se quiere utilizar en un futuro.
Las ltimas versiones estables de estos paquetes se pueden encontrar y descargar
desde la pgina web oficial de Asterisk: http://www.asterisk.org/downloads. En la
ultima actualizacin de este proyecto, las versiones utilizadas fueron:
* Asterisk 10.0.0
* DAHDI Complete 2.5.0.2 + 2.5.0.2
* libPRI 1.4.12
40
3.3. I NSTALACIN
DEL ENTORNO
Una vez descargados estos archivos, se guardan y se descomprimen en el directorio

/usr/src de Linux. Los pasos a seguir para su instalacin se pueden ver en el anexo A.1.
Adems de estos paquetes bsicos, tambin se instalarn otros que servirn para
aadir funcionalidades y mejorar la calidad de los servicios ofrecidos por la centralita.
Estos paquetes son:
* Oslec, un cancelador de eco software para las llamadas de la red analgica.
* SSMTP, un gestor de correo electrnico para utilizar con el buzn de voz.
* CMUSphinx, un programa de reconocimiento de voz para integrar en el funcionamiento de la centralita.
* SFLphone, un softphone para poder hacer las simulaciones.
3.3.1
TARJETA D IGIUM TDM808
Para comunicar Asterisk con la red de telefona se instala en el servidor una tarjeta
analgica de Digium, la TDM808. Las tarjetas de la serie 800 soportan hasta ocho
conexiones por tarjeta utilizando sus ocho puertos. Estos puertos pueden tener dos
tipos de interfaces diferentes y se distinguen visualmente por su color: FXO (rojo) y
FXS (verde). La TDM808 est compuesta por ocho mdulos rojos, de tipo FXO.
Despus de instalar la tarjeta, se comprueba el listado de los dispositivos detectados por el bus PCI para ver si la tarjeta es detectada correctamente con el siguiente
comando:
> lspci -n
La deteccin de la tarjeta se confirma al aparecer en el listado un dispositivo con el

identificador de Digium d161 seguido del identificador de la tarjeta 800.
07:04.0 0200: d161 :0800 ( rev 11)
3.3.2
C ANCELADOR DE ECO O SLEC
Por defecto, el cancelador de eco software para las lneas analgicas que maneja
DAHDI es el mg2. Dado que el rendimiento del cancelador por defecto no es
demasiado bueno, se decide utilizar Oslec en su lugar. Oslec es un cancelador de
eco de lnea open source de alto rendimiento que, aunque no viene incluido en el
paquete DAHDI, se puede integrar de forma fcil para que funcione con DAHDI. A
continuacin se detallarn los pasos a seguir para instalar Oslec en el sistema. La
41
DE LA
C ENTRALITA
posterior configuracin e integracin con DAHDI se explicar ms adelante. Los pasos

seguidos para su instalacin se pueden observar en el anexo A.1.5.
3.3.3
G ESTOR DE CORREO
SSMTP es un programa que sirve para enviar correos electrnicos desde un ordenador
local a un host de correo configurado (mailhub). Uno de sus principales usos es el
reenvo de correos electrnicos automatizados desde el ordenador a una direccin de
correo externa.
Este programa se utiliza con la funcionalidad de buzn de voz de Asterisk. Al
configurar las cuentas de buzn de voz, se especifica una direccin de correo electrnico para cada usuario. Al dejar un mensaje en el buzn de voz, se enva de forma
automtica un correo electrnico a esa direccin para avisar al usuario de que tiene
un mensaje nuevo. Este correo incluye adems un archivo de audio adjunto con el
mensaje de voz.
Para instalar SSMTP en el servidor, se utiliza el gestor de paquetes Synaptic incluido
en el sistema operativo.
3.3.4
R ECONOCIMIENTO DE VOZ
El men principal de la centralita permite la introduccin de la extensin deseada

por dos medios distintos: teclado del telfono y reconocimiento de voz. Como
se ha comentado anteriormente, Asterisk no incluye ninguna herramienta para el
reconocimiento de voz, pero permite la utilizacin de motores de reconocimiento de
terceros. Por este motivo se utiliza en el servidor el proyecto CMUSphinx.
CMUSphinx es un toolkit de reconocimiento de voz que incluye varias herramientas
para construir aplicaciones de reconocimiento. De estas herramientas slo se utilizarn
dos: Pocketsphinx (librera de reconocimiento) y Sphinxbase (librera de soporte). Los
paquetes necesarios para instalar estas libreras se pueden descargar desde la pgina
del proyecto: http://cmusphinx.sourceforge.net/. La instalacin de estas libreras
se puede observar en el anexo A.1.6.
3.3.5
S OFTPHONE
Un softphone es un programa que simula el comportamiento de un telfono y que

se utiliza para realizar llamadas VoIP desde un ordenador. En este proyecto se ha
42
3.4. C ONFIGURACIONES
utilizado para simular a los diversos usuarios conectados al servidor Asterisk.
Se escoge el softphone SFLphone para Linux, principalmente, porque es de cdigo
abierto y dispone de una comunidad muy activa, facilitando as la resolucin de
cualquier duda o problema que pueda surgir. Adems, permite la utilizacin de
mecanismos de securizacin (como SRTP) por si se quieren aadir en un futuro. Para
instalarlo en el servidor, se utiliza el gestor de paquetes Synaptics.
3.4
C ONFIGURACIONES
instalado en el servidor, ya se pueden realizar las configuraciones necesarias que permitirn poner en marcha todo el sistema de VoIP de
la residencia. Como en cualquier empresa, este sistema consta de una parte interna
(residentes y trabajadores de la residencia) y de una parte externa (PBX para las
llamadas procedentes del exterior).
ON TODO LO NECESARIO
3.4.1
TARJETA D IGIUM Y C ANCELADOR DE ECO O SLEC
El primer paso para poder poner la PBX en funcionamiento es la configuracin del

entorno para poder comunicar el servidor con el mundo exterior (la red de telefona).
Con ese fin, hay que configurar el interfaz DAHDI para que trabaje con la tarjeta
instalada y con el cancelador de eco Oslec.
Sabiendo que el servidor detecta correctamente la tarjeta Digium TDM808, se
puebla el fichero /etc/dahdi/system.conf escribiendo la siguiente instruccin en un
terminal:
> dahdi_genconf
Esta instruccin comprueba las tarjetas disponibles en el ordenador y configura el

fichero system.conf con la informacin que obtiene de dichas tarjetas. Al inspeccionar
el archivo despus de ejecutar este comando, vemos el nombre de la tarjeta detectada
y dos lneas por cada mdulo detectado (ocho en este caso). Para cada mdulo se
especifica el tipo y sealizacin (fxsks1 ) y el cancelador de eco asociado. Tambin hay
dos lneas especificando el pas de utilizacin para los tonos. Se cambia el cancelador
de eco por defecto (mg2) por el que se ha instalado (Oslec) y el pas de utilizacin a
Espaa.
1
Los mdulos FXO se definen con la nomenclatura contraria fxs. Estos mdulos usan sealizacin
ks (Kewlstart Signalling), que corresponde a sealizacin loopstart con supervisin de desconexin.
43
DE LA
C ENTRALITA
Finalmente, el fichero /etc/dahdi/system.conf tiene este aspecto:

# Span 1: WCTDM /0 " Wildcard TDM800P Board 1" ( MASTER )
fxsks =1
echocanceller = oslec ,1
fxsks =2
fxsks =3
fxsks =4
fxsks =5
fxsks =6
fxsks =7
fxsks =8
# Global data
loadzone
defaultzone
= es
= es
A continuacin hay que cargar los drivers de DAHDI en el kernel mediante la siguiente instruccin. El driver adecuado para la serie 800 es el wctdm24xxp.
> cd / etc / dahdi
> modprobe wctdm24xxp
Para habilitar el cancelador de eco Oslec, hay que modificar las siguientes lneas en
dos archivos ubicados en el directorio /etc/dahdi del sistema:
> nano / etc / dahdi / init . conf
# Descomentamos esto :
DAHDI_UNLOAD_MODULES = " dahdi echo "
# If you use OSLEC
> nano / etc / dahdi / genconf_parameters

# Descomentamos esto :
echo_can
oslec
Algunas tarjetas Digium incluyen un cancelador de eco hardware (HWEC) que

aparece configurado por defecto y que puede utilizarse en combinacin con Oslec. De
todas formas, si se deseara deshabilitar el cancelador hardware, debe modificarse la
siguiente lnea del archivo /etc/modprobe.d/dahdi.conf:
> vi / etc / modprobe . d / dahdi . conf
options wctdm24xxp vpmsupport =0
44
Las configuraciones de sealizacin y los cdigos utilizados para los tonos en la red
de telefona varan en funcin de la zona o el pas en el que nos encontremos. Por eso
hay que realizar unos cambios para conseguir que la configuracin de la tarjeta sea la
adecuada para operar en Espaa. Con este fin, se hacen las siguientes modificaciones
en estos archivos:
> nano / etc / asterisk / indications . conf
country = es
> nano / etc / modprobe . d / dahdi . conf
options wctdm24xxp opermode = SPAIN
Por ltimo, se verifica que la configuracin de los mdulos de la tarjeta sea la correcta y que se hayan aplicado correctamente todos los cambios. Para ello se utiliza
una instruccin que muestra por pantalla un resumen de los puertos de la tarjeta y su
configuracin.
> dahdi_cfg - vvv
DAHDI Tools Version - 2.5.0.2
DAHDI Version : 2.5.0.2
Echo Canceller ( s ) : HWEC , OSLEC
Configuration
======================
Channel map :
Channel 01: FXS Kewlstart ( Default ) ( Echo
Canceler :
Canceler :
Canceler :
Canceler :
Canceler :
Canceler :
Canceler :
Canceler :
oslec ) ( Slaves :
oslec ) ( Slaves :
oslec ) ( Slaves :
oslec ) ( Slaves :
oslec ) ( Slaves :
oslec ) ( Slaves :
oslec ) ( Slaves :
oslec ) ( Slaves :
01)
02)
03)
04)
05)
06)
07)
08)
8 channels to configure .
Setting
Setting
Setting
Setting
Setting
Setting
Setting
Setting
echocan
echocan
echocan
echocan
echocan
echocan
echocan
echocan
for
for
for
for
for
for
for
for
channel
channel
channel
channel
channel
channel
channel
channel
1
2
3
4
5
6
7
8
to
to
to
to
to
to
to
to
oslec
oslec
oslec
oslec
oslec
oslec
oslec
oslec
Se hace una ltima comprobacin mediante la instruccin dmesg, que lista el buffer
de mensajes del ncleo, y se buscan las lneas relativas a las configuraciones que se han
45
DE LA
C ENTRALITA
llevado a cabo. A continuacin se muestran estas lneas, donde vemos que se detecta
la tarjeta Digium con los puertos de tipo FXO configurados para funcionar con los tonos
de Espaa y que se han encontrado tambin los dos canceladores de eco: hardware
(HWEC VPMADT032) y software (Oslec).
wctdm24xxp 0000:07:04.0: Freed a Wildcard
wctdm24xxp 0000:07:04.0: PCI INT A disabled
dahdi : Telephony Interface Unloaded
dahdi : Telephony Interface Registered on major 196
dahdi : Version : 2.5.0.2
wctdm24xxp 0000:07:04.0: PCI INT A -> GSI 20 ( level , low ) -> IRQ 20
wctdm24xxp 0000:07:04.0: Port 1: Installed -- AUTO FXO ( SPAIN mode )
wctdm24xxp 0000:07:04.0: Booting VPMADT032
wctdm24xxp 0000:07:04.0: VPM present and operational ( Firmware
version 125)
wctdm24xxp 0000:07:04.0: Found a Wildcard TDM : Wildcard TDM800P (0
BRI spans , 8 analog channels )
wctdm24xxp 0000:07:04.0: Freed a Wildcard
wctdm24xxp 0000:07:04.0: PCI INT A disabled
dahdi : Telephony Interface Unloaded
dahdi : Telephony Interface Registered on major 196
dahdi : Version : 2.5.0.2
wctdm24xxp 0000:07:04.0: PCI INT A -> GSI 20 ( level , low ) -> IRQ 20
wctdm24xxp 0000:07:04.0: Found a Wildcard TDM : Wildcard TDM800P (0
BRI spans , 8 analog channels )
dahdi_echocan_oslec : Registered echo canceler ' OSLEC '
3.4.2
C ANALES DAHDI
El ltimo paso relativo a la configuracin de la parte externa es la modificacin del

archivo chan_dahdi.conf que se encuentra ubicado en el directorio /etc/asterisk.
Este archivo es la capa de configuracin entre DAHDI y Asterisk y sirve para definir las
caractersticas esenciales de los canales relativos a la tarjeta instalada.
46
El archivo chan_dahdi.conf consta de dos partes: la definicin de las opciones

generales de los canales y la definicin de los propios canales. Las caractersticas generales de los canales incluyen, por ejemplo: la utilizacin de identificacin de llamada, la
posibilidad de aparcar y transferir llamadas, la utilizacin del cancelador de eco, tipos
de sealizacin utilizados, etc. A continuacin hay que definir los canales relativos a
los mdulos de la tarjeta para que Asterisk sea capaz de reconocerlos y utilizarlos. En
este caso, la definicin de los canales se realiza de la siguiente forma:
; FXO Modules
group =1
callgroup =1
pickupgroup =1
signalling = fxs_ks
callerid = asreceived
context = from - pstn
channel = > 1 -8
Se definen los ocho canales disponibles dentro de un nico grupo (1), por lo
tanto, todos los canales tendrn las mismas caractersticas. Se especifica el tipo de
sealizacin (fxs_ks) y que el identificador de llamada de estos canales venga marcado
por el obtenido de la red telefnica. Tambin se define el contexto que utilizarn todos
los canales ([f rom pstn]). Esto quiere decir que todas las llamadas que utilicen estos
canales (entrantes desde la red telefnica) ejecutarn las instrucciones del dialplan
correspondientes a este contexto. Como se puede deducir, el contexto [f rom pstn] es
donde se ubica la definicin de la centralita (PBX).
La configuracin completa de este archivo puede encontrarse en el anexo A.2.1.
3.4.3
A STERISK
En este apartado se detalla la configuracin del sistema de telefona VoIP que se ha

implementado para el escenario de la residencia. Para ello se detallarn los archivos
de configuracin relativos a los mdulos de Asterisk que se han utilizado. Todos estos
ficheros se encuentran en el directorio /etc/asterisk.
3.4.3.1
U SUARIOS
La definicin de los clientes SIP que se pueden registrar en el servidor de VoIP se

realiza en el archivo /etc/asterisk/sip.conf. Cada usuario (cliente SIP) debe tener
un nombre que lo identifique y una clave de acceso para poder registrarse. Tambin
deben especificarse otros aspectos, como los cdecs que pueden utilizar y el contexto
47
DE LA
C ENTRALITA
TABLA 3.1: Listado de usuarios SIP.

Residentes
[PermisosResidentes]
200, 201, 202

501 (recepcin)
502 (trabajadora social)
503 - 505 (gerocultoras)
506 (despacho directora)
Trabajadores [PermisosTrabajadores]
507 (mvil directora)
508 (casa directora)
509 (psicloga)
500 (jefa de enfermeras)
que tratar las llamadas.

Para realizar las simulaciones se han definido una serie de clientes que representan
a los posibles usuarios del sistema implementado en la residencia de ancianos. Se
diferencian dos tipos: los residentes y los trabajadores. A cada tipo se le asigna un
contexto diferente ya que no todos podrn acceder a las mismas extensiones en el
dialplan. A todos los usuarios se les habilita el cdec G.711 en sus dos versiones (a-law
y u-law).
En la tabla 3.1 se encuentra un resumen de los usuarios creados. La definicin
completa de estos usuarios se puede encontrar en el anexo A.2.2.
3.4.3.2
D IALPLAN
El dialplan es el ncleo del sistema Asterisk. En l se indica el manejo de todas las

llamadas que llegan al servidor. La descripcin del dialplan se realiza en el archivo
/etc/asterisk/extensions.conf. Este fichero se estructura en contextos, y esos
contextos, a su vez, en extensiones.
En este caso se han definido una serie de contextos que permitirn realizar una serie
de acciones dependiendo del tipo de usuario o del punto de acceso. A continuacin se
listan los contextos utilizados y se resumen sus funciones:
* [usuarios]: este contexto contiene las extensiones que permiten: acceder a la
macro de llamadas para todos los usuarios (trabajadores y residentes) y acceder
a la sala de conferencias 101 (que se explicar ms adelante).
* [macroU naExten]: las macros son contextos especiales que se pueden reutilizar
en otros contextos. Este contexto slo contiene la extensin s, que es modificada
48
en los consiguientes contextos por el nmero de extensin que invoca. En este
caso, se utiliza una macro para realizar las llamadas locales (entre los usuarios
internos). Se comprueba que la extensin no est en la lista negra, si hay desvos
activos y entonces se realiza el marcado. Si no hay respuesta, salta el buzn de
voz.
* [Buzon_de_voz]: contiene la extensin 99, que da acceso al buzn de voz para
que los usuarios puedan escuchar sus mensajes.
* [grabadora]: contiene las extensiones que permiten grabar las locuciones de voz
para la PBX en formato WAV. Los archivos de audio grabados se guardan en el
directorio /var/lib/asterisk/sounds/custom.
* [android_V A]: contiene las extensiones que se utilizarn para notificar a los
usuarios internos de las alertas originadas por los softphones implementados en
Android. Su contenido se detalla en el captulo 4.
* [P C_a_RT C]: permite a los usuarios internos realizar llamadas a nmeros externos marcando previamente 00. Estas llamadas se transmiten por una de las lneas
analgicas conectadas a la tarjeta TMD808.
* [f rom pstn]: trata todas las llamadas entrantes procedentes del exterior.
Este contexto, junto con [centralita_ASR] y [menu privado] se explicarn
detalladamente ms adelante.
Asterisk permite el anidamiento de contextos, es decir, contextos dentro de contextos. Esto se utiliza para restringir el acceso a algunas funcionalidades dependiendo del usuario. Con este fin se crean los contextos [P ermisosResidentes] y
[P ermisosT rabajadores], que dan acceso a los contextos cuyas extensiones se pueden
utilizar por los diferentes usuarios:
* [P ermisosResidentes]: contexto donde se tratan las llamadas de los residentes
(usuarios 200, 201 y 202). ste da acceso a los contextos: [usuarios],
[Buzon_de_voz] y [Android_V A].
* [P ermisosT rabajadores]: contexto donde se tratan las llamadas de los trabajadores (usuarios del 500 al 509). ste da acceso a los contextos: [usuarios],
[Buzon_de_voz], [grabadora], [Android_V A], [P C_a_RT C] y [parkedcalls] (necesaria para poder transferir y aparcar llamadas). Tambin incluye las extensiones
que permiten activar/desactivar el desvo de llamadas y el acceso a la sala de
conferencias 600 (limitada a 3 usuarios y slo para empleados).
La configuracin completa del dialplan se puede encontrar en el anexo A.2.3.
49
3.4.3.3
M SICA
DE LA
C ENTRALITA
EN ESPERA
Asterisk ofrece la posibilidad de utilizar msica en espera cuando un usuario queda a

la espera durante una llamada. Tambin se puede reproducir msica en substitucin
de los tonos de marcado.
La configuracin de la msica en espera se realiza en el archivo
/etc/asterisk/musiconhold.conf y se puede encontrar en el anexo A.2.4. En
este fichero se especifican la localizacin y el modo de reproduccin de los archivos
de audio. En este caso existen dos posibilidades: dos archivos de audio en formato
WAV y una emisora de radio gratuita shoutcast (Big B Radio). La emisora de radio es
la msica en espera por defecto en todas las extensiones de la PBX. Los archivos de
audio, que se reproducen de forma aleatoria, se utilizan para el resto de los casos.
3.4.3.4
B UZN
DE VOZ
El servicio de voicemail que ofrece Asterisk es similar al de cualquier buzn de voz

aadiendo ms funcionalidades. La ms destacable es la capacidad de enviar un
correo electrnico al usuario para avisarle de que tiene nuevos mensajes. Este correo
electrnico incluye, adems, un fichero adjunto con el mensaje de voz en el formato
especificado. Como se ha comentado anteriormente, para utilizar esta funcionalidad, el
servidor debe contar con un gestor de correo, en este caso, el SSMTP. La configuracin
de este gestor se encuentra en el anexo A.2.5.1.
La configuracin de los buzones de voz se realiza en el archivo
/etc/asterisk/voicemail.conf y se puede encontrar en el anexo A.2.5. En
este fichero se definen todas las cuentas de voicemail, asociando a cada usuario un
nombre, una cuenta de correo electrnico para recibir los mensajes y una contrasea
para acceder al buzn de voz desde el telfono. En este caso se define una cuenta para
cada usuario definido en sip.conf. Tambin se pueden configurar varias opciones
generales para todas las cuentas, como por ejemplo: especificar el cuerpo del correo
electrnico, el formato del archivo de audio enviado o el tamao y duracin del
mensaje. Para evitar que el buzn de voz bloquee la lnea demasiado tiempo, se ha
modificado la longitud mxima de los mensajes y el tiempo de silencio antes de parar
la grabacin a 30 y 10 segundos respectivamente.
3.4.3.5
F OLLOW M E
La funcionalidad Follow Me sirve para intentar localizar a un usuario llamando a

distintas localizaciones (en serie o en paralelo). La configuracin de este servicio
50
se realiza en el archivo /etc/asterisk/followme.conf. En l se especifican, por
orden, las extensiones a las que llamar y el tiempo que se debe esperar hasta pasar a
la siguiente destinacin. En este caso se utiliza en la extensin de la centralita que
contacta con la directora del centro. Primero se intenta en el despacho, y si no hay
respuesta, se llama al mvil y por ltimo, a su casa.
La configuracin completa del protocolo de seguimiento se puede encontrar en el
anexo A.2.6.
3.4.3.6
S ALA
DE
C ONFERENCIAS
Las salas de conferencia permiten crear conversaciones entre mltiples usuarios como
si estuvieran todos en una misma localizacin fsica. Algunas de las principales
caractersticas de este servicio incluyen: la creacin de varias salas distintas con
acceso protegido por contrasea, la posibilidad de regular el nmero de participantes
(fijando un nmero mximo, echando usuarios o bloqueando la sala), la capacidad de
enmudecer a uno o varios participantes, etc.
En este caso se crean dos salas de conferencias con diferentes contraseas. La sala
nmero 600 slo es accesible por los trabajadores de la residencia. La sala nmero
101 permite el acceso a usuarios tanto internos como externos. El acceso exterior se
encuentra en una extensin del men privado de la centralita. El acceso interior se
encuentra en el contexto [usuarios] disponible tanto para los residentes como para los
trabajadores.
La configuracin de las salas de conferencias se realiza en el archivo
/etc/asterisk/meetme.conf y se puede encontrar en el anexo A.2.7.
3.4.3.7
C OLAS
La distribucin automtica de llamadas, o cola de llamadas, proporciona a la PBX una

forma de encolar llamadas entrantes de un grupo de usuarios. En este caso se utiliza
desde la extensin de la centralita que contacta con la jefa de enfermeras. Al marcar la
extensin, si no se consigue contactar con la jefa enfermeras se coloca la llamada en la
cola, donde se mantendr hasta que sea atendida por alguna gerocultora o se alcance
el tiempo mximo de espera en cola.
La configuracin de la cola de llamadas se realiza en el archivo
/etc/asterisk/queues.conf y se puede encontrar en el anexo A.2.8. En este
fichero se especifican los miembros que atendern la cola de llamadas por orden de
51
DE LA
C ENTRALITA
prioridad. En este caso, los miembros sern las gerocultoras (usuarios 503, 504 y
505, en este orden). Tambin se pueden fijar varias opciones, como por ejemplo: tipo
de anuncios que se hacen al llamante mientras est en cola, msica que se escucha
mientras se espera a ser atendido, nmero de reintentos, tiempo mximo de espera en
cola, etc.
3.4.3.8
T RANSFERENCIA
Y PARKING DE LLAMADAS
La transferencia y el aparcado de llamadas son funcionalidades tpicas de las PBX.

La transferencia de llamadas permite redireccionar una llamada desde la extensin
que la est atendiendo a cualquier otra. El parking de llamadas consiste en dejar una
llamada en espera en una extensin y recogerla en cualquier otra. Estas funciones
estn disponibles por todos los usuarios internos del sistema.
La configuracin de stas y otras funcionalidades se realiza en el archivo
/etc/asterisk/features.conf y se puede encontrar en el anexo A.2.9. En este
archivo se pueden especificar, entre otras cosas, las extensiones en las que pueden
aparcarse las llamadas o las secuencias DMTF que hay que marcar para poder transferir
llamadas. Las transferencias pueden ser de dos tipos: ciegas (se transfiere la llamada
sin ms) o guiadas (primero se contacta con la extensin deseada y luego se realiza la
transferencia).
3.4.4
C ENTRALITA PBX
Todas las llamadas entrantes procedentes de la red de telefona (exterior) llegan a

la centralita que se ha implementado y son recibidas por una operadora virtual que
las direccionar a la extensin deseada. Como se ha avanzado en la explicacin
del dialplan, los contextos que se utilizan para la configuracin de la PBX son:
[f rom pstn] (entrada a la centralita), [centralita_ASR] (definicin de las extensiones
de la centralita) y [menu privado] (definicin de las extensiones del men privado de
la centralita).
Las llamadas entrantes exteriores son tratadas por el contexto [f rom pstn]. En
l se encuentra la puerta de entrada a la centralita. Si la llamada se recibe dentro del horario de recepcin, se pasa la llamada al contexto [centralita_ASR] dando
acceso al men de la PBX. Si no, se enva la llamada al buzn de voz de recepcin (501).
En el contexto [centralita_ASR] se encuentra la definicin de la parte pblica de
la PBX. Mediante locuciones de voz grabadas, se da la bienvenida al llamante y se le
informa de las posibles extensiones a las que puede acceder (0 a 5). Las extensiones
52
pueden introducirse de forma oral (mediante reconocimiento de voz) o mediante el
teclado del telfono. Se dan dos oportunidades para especificar la extensin deseada
por voz. Si no se reconoce una extensin vlida, se pide la introduccin va teclado y
si no, se redirige la llamada a recepcin (extensin 0) para que se le pueda atender
o redireccionar a la extensin adecuada. Los pasos que sigue una llamada entrante
desde que llega a la centralita hasta que se escoge una extensin vlida se pueden ver
en el diagrama de la figura 3.2.
A continuacin se hace un breve resumen de las extensiones disponibles desde este
contexto y su funcionamiento:
* Extensin 0: Recepcin. Se realiza una llamada al usuario recepcin (501).
Desde aqu se puede atender la llamada y transferirla a la extensin o usuario
adecuados. A esta extensin se puede llegar directamente desde el men o al
agotar el nmero mximo de intentos de introducir una extensin vlida. Su
funcionamiento se puede observar en el diagrama de la figura 3.3.
* Extensin 1: Trabajadora social. Se realiza una llamada a la trabajadora social
(502). Si no est disponible, se pasa la llamada al buzn de voz, como se puede
ver en el diagrama de la figura 3.4.
* Extensin 2: Enfermera. Se realiza una llamada a la jefa de enfermeras (500)
y si est ocupada se pasa la llamada a la cola donde ser atendida por alguna de
las gerocultoras, como se puede ver en el diagrama de la figura 3.5.
* Extensin 3: Direccin. Se realiza una llamada al despacho de la directora del
centro (506). Si no hay respuesta, se inicia el protocolo de seguimiento follow
me para intentar ubicarla en otros emplazamientos (el mvil y su casa). Se pide
el nombre del llamante para anunciarlo al llamado en cada ubicacin. Si no se
consigue contactar con la directora, se dirige la llamada al buzn de voz correspondiente. Este comportamiento se puede ver en el diagrama de la figura 3.6.
* Extensin 4: Psicloga. Se realiza una llamada a la psicloga del centro (509).
La psicloga puede redirigir su telfono a la recepcin si no quiere ser molestada
durante las sesiones. Primero se comprueba si hay una redireccin y despus se
llama a la extensin adecuada, como se puede ver en el diagrama de la figura 3.7.
* Extensin 5: Llamada exterior. Permite llamar a cualquier nmero del exterior
pasando por Asterisk. En este caso, el nmero debe tener un mximo de 5 cifras.
* Extensin 6: Men privado. Permite el acceso al men privado, que se explicar
ms adelante. Esta extensin no se nombra en el men de inicio ya que est
pensada para que slo trabajadores autorizados de la residencia puedan acceder.
53
DE LA
C ENTRALITA
De todas formas, aunque se entrara por error, el acceso est protegido por una
contrasea.
* Extensin #: Colgado. Despus de pasar por cualquier extensin, todas las llamadas son dirigidas a sta. Aqu se despide al llamante mediante una locucin
de voz y se cuelga la llamada.
* Extensin i: Extensin incorrecta. Se llega a esta extensin de forma automtica
al marcar una extensin incorrecta (no existente). Despus de informar del
error, se reenva la llamada al men de extensiones del inicio. Si se ha alcanzado el nmero mximo de errores, se enva la llamada a recepcin (extensin 0).
En el contexto [menu privado] se encuentra la definicin de la parte privada de
la PBX. El men privado est pensado para uso exclusivo de la directora del centro
y permite entrar en la sala de conferencias 101 y realizar escuchas desde cualquier
telfono exterior a la residencia. El acceso est controlado mediante contrasea
para que nadie pueda entrar por error. Se dan tres oportunidades de introducir la
contrasea correcta, si no, se cuelga la llamada automticamente. Al acceder a esta
zona, se reproduce la locucin de voz que informa de las opciones del men privado
y se espera la introduccin por teclado de la extensin deseada. Su funcionamiento se
puede ver en el diagrama de la figura 3.8.
Las extensiones disponibles en este contexto son las siguientes:
* Extensin 1: Sala de conferencias. Da acceso a la sala de conferencias 101
mediante la contrasea correspondiente. A esta sala tambin tienen acceso los
usuarios internos. Se especifican las siguientes opciones: se reproduce msica si
slo hay una persona en la sala y se puede salir de ella pulsando la tecla #.
* Extensin 2: Escucha de llamadas. Permite espiar cualquier conversacin que
se est realizando entre extensiones internas de la residencia. Pulsando la tecla *
se detiene el espionaje del canal actual y se cambia a una conversacin diferente.
Pulsando la tecla # se sale de la extensin de escuchas y se llega a la extensin
de colgado de la centralita.
* Extensin i: Extensin incorrecta. Se llega a esta extensin de forma automtica
al marcar una extensin incorrecta (no existente). Despus de informar del error,
se reenva la llamada al men de extensiones privado.
La configuracin completa de la PBX se puede encontrar en el anexo A.2.3.
54
3.4.4.1
I NTEGRACIN
DEL RECONOCIMIENTO DE VOZ
El reconocimiento de voz se usa para seleccionar la extensin deseada en el men

principal de la centralita. Para ello se utiliza el proyecto CMUSphinx. Este proyecto
ofrece una aplicacin llamada pocketsphinx_continuous que se lanza desde un
terminal y que hace el reconocimiento de voz de la entrada del micro. Tambin incluye
la posibilidad de utilizar como entrada del reconocimiento un fichero de audio en
formato WAV.
La utilizacin de esta aplicacin en Asterisk se hace mediante el script asr2.sh. A
continuacin se muestra el cdigo de la PBX donde se utiliza el reconocimiento de voz
y se explica su funcionamiento detalladamente:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
exten = > s ,1 , Answer ()

same = > 2 , Background ( custom / asr_bienvenida )
same = > 3 , Set ( k =1)
same = > 4 , While ( $ [ $ { k } <3])
same = > n , Background ( custom / asr_extension_voz )
same = > n , Background ( custom / asr_menu )
same = > n , Record ( custom / recon / voz . wav , ,5)
same = > n , System (/ var / lib / asterisk / sounds / custom / recon / asr2 . sh )
same = >
n , Set ( num = $ { FILE (/ var / lib / asterisk / sounds / custom / recon / num . txt ,0 ,1) })
same = > n , NoOp ( num = $ { num })
same = > n , GotoIf ( $ [ " $ { num } " = " " ]? null )
same = > n , GotoIf ( $ [ $ { num } <0 | $ { num } >6]?: ok )
same = > n , Set ( num = i )
same = > n ( ok ) , Goto ( $ { num } ,1)
same = > n ( null ) , Set ( k = $ [ $ { k }+1])
same = > n , EndWhile
same = > n , Background ( custom / asr_extension & beep )
same = > n , WaitExten (15 , m ( radio ) )
same = > n ( max ) , PlayBack ( custom / asr_max_intentos )
same = > n , Goto (0 ,1)
Despus de escuchar la locucin de voz que informa del men de extensiones

principal, se pide al llamante que diga la extensin que desea. La respuesta se graba
en un archivo de audio (voz.wav) mediante la instruccin Record() (lnea 7). A
continuacin, se lanza el script encargado de hacer el reconocimiento de la respuesta
grabada utilizando la instruccin System() (lnea 8). Por ltimo, se guarda el nmero
de extensin obtenido del reconocimiento en la variable num del dialplan (lnea 9). El
valor de esta variable se utiliza para dirigir la llamada a la extensin deseada mediante
la instruccin Goto() (lnea 14).
El shell script asr2.sh utiliza la aplicacin pocketsphinx_continuous para hacer el
reconocimiento de la siguiente manera:
55
DE LA
C ENTRALITA
# ! / bin / sh
dir = " / var / lib / asterisk / sounds / custom / recon "
pocketsphinx_continuous - hmm en / tidigits - lm en / tidigits . DMP - dict
en / tidigits . dic - infile $ { dir }/ voz . wav - samprate 8000 | tail -c +12
> $ { dir }/ out . txt
cat $ { dir }/ numbers . txt | agrep -f $ { dir }/ out . txt | head -c 1 >
$ { dir }/ num . txt
Primero se realiza el reconocimiento de voz del fichero voz.wav mediante la aplicacin pocketsphinx_continuous, utilizando el modelo acstico y diccionario tidigits.
Este diccionario permite el reconocimiento de dgitos del 0 al 9 en ingls. La salida del
reconocimiento devuelve mucha informacin y con la instruccin tail se obtiene slo
el dato deseado, el nombre del dgito reconocido, que se guarda en el archivo out.txt.
Por ltimo se obtiene el dgito reconocido en formato numrico para que Asterisk
pueda utilizarlo para especificar la extensin. Esto se hace con la ayuda del fichero
numbers.txt, convirtiendo el nombre del nmero en su dgito correspondiente y
guardando el resultado en el fichero num.txt. El fichero numbers.txt es simplemente
un archivo de texto que contiene once lneas (una para cada palabra posible) con la
siguiente nomenclatura:
(nmero) (nombre del nmero)

Todos los archivos utilizados para el reconocimiento de voz se encuentran ubicados
en el directorio /var/lib/asterisk/sounds/custom/recon.
3.4.5
E JECUCIN
Una vez instalados y configurados todos los componentes necesarios se debe poner en
marcha todo el sistema. Para ello hay que iniciar los servicios DAHDI y Asterisk (en ese
orden) mediante las siguientes instrucciones:
> service dahdi start
> service asterisk start
Para acceder a la consola propia de Asterisk (CLI) se escribe la siguiente lnea en un

terminal:
> asterisk - rvvvvvvvvvvvvvvvv
En la CLI se puede observar el log de las actividades que se producen en Asterisk
56
en tiempo real, como por ejemplo: logado/deslogado de usuarios en el servidor,
instrucciones ejecutadas en el dialplan, errores producidos, etc.
Despus de realizar cualquier cambio en los archivos de configuracin se deben
volver a cargar los mdulos afectados para que Asterisk opere con la versin ms
actual de los mismos. Esto puede hacerse con los comandos adecuados en la consola
CLI o reiniciando el servicio Asterisk desde cualquier terminal.
57
DE LA
FIGURA 3.2: Diagrama de flujo de la centralita (Inicio).
58
C ENTRALITA
FIGURA 3.3: Diagrama de flujo de la extensin 0 de la centralita (Recepcin).
59
DE LA
C ENTRALITA
FIGURA 3.4: Diagrama de flujo de la extensin 1 de la centralita (Trabajadora Social).
60
FIGURA 3.5: Diagrama de flujo de la extensin 2 de la centralita (Enfermera).
61
DE LA
C ENTRALITA
FIGURA 3.6: Diagrama de flujo de la extensin 3 de la centralita (Direccin).
62
FIGURA 3.7: Diagrama de flujo de la extensin 4 de la centralita (Psicloga).
63
DE LA
C ENTRALITA
FIGURA 3.8: Diagrama de flujo de la extensin 6 de la centralita (Men privado).
64
4
Implementacin de los Softphones
4.1
O BJETIVO
en la introduccin de este documento, uno de los objetivos

del proyecto es la implementacin de dos aplicaciones Android para utilizar el
sistema de VoIP implantado en la residencia. Estas aplicaciones son dos softphones:
uno para uso de los residentes y el otro para la recepcin del centro. Aunque se
podra utilizar cualquier softphone disponible en el mercado, se decide implementar
aplicaciones propias con el propsito de aadir funcionalidades extras y exclusivas
para los residentes y trabajadores del centro.
OMO SE HA COMENTADO
A lo largo de este captulo se irn explicando, en profundidad, los pasos seguidos

para implementar estas aplicaciones y su funcionamiento.
4.2
I NSTALACIN
Y CONFIGURACIN DEL ENTORNO DE
TRABAJO
del proyecto se requiere la instalacin y configuracin de

una serie de elementos que se explicarn en este apartado:
ARA REALIZAR ESTA PARTE
* Un entorno de programacin adecuado formado por Eclipse, Android SDK y el

plugin ADT, necesarios para la implementacin de cualquier aplicacin Android.
* Una base de datos en el servidor, para lo que se instala LAMP, y una serie de
scripts PHP que servirn para acceder, consultar y modificar esta base de datos
desde las aplicaciones Android.
65
DE LOS
S OFTPHONES
* Unas extensiones especiales en Asterisk que servirn para comunicar las situaciones de emergencia entre los residentes y la recepcin. Estas extensiones estn
definidas en el dialplan de Asterisk bajo el contexto [android_V A].
4.2.1
D ESARROLLO DE APLICACIONES A NDROID
Para poder implementar cualquier aplicacin Android hay que instalar el entorno
de programacin y simulacin adecuado. Todas las herramientas necesarias para
desarrollar aplicaciones Android son gratuitas (libres) y estn disponibles para todas
las plataformas (Linux, Mac, Windows). En este caso se utilizarn las herramientas
recomendadas en Android Developers: Eclipse + Android SDK + ADT.
Eclipse
El primer paso para desarrollar cualquier aplicacin es obtener un entorno de desarrollo integrado (IDE). Un IDE es un programa compuesto por un conjunto de
herramientas de programacin y normalmente consiste en: un editor de cdigo,
herramientas de compilacin y un depurador. En el caso de aplicaciones Android,
el IDE recomendado es Eclipse, un entorno de programacin multi-lenguaje con un
extensible sistema de plug-in. La ltima versin disponible al iniciar este proyecto, y
por tanto la versin instalada, es la Helios.
Android SDK
El SDK1 es un conjunto de herramientas de desarrollo que permite a un programador
crear aplicaciones para un sistema concreto, por ejemplo ciertos paquetes de software,
frameworks, plataformas de hardware, videoconsolas, sistemas operativos, etc. Es
algo tan sencillo como una interfaz de programacin de aplicaciones (API) creada
para permitir el uso de cierto lenguaje de programacin, o puede, tambin, incluir
hardware sofisticado para comunicarse con un determinado sistema embedido.
El Android SDK contiene un depurador, libreras, un emulador, documentacin,
ejemplos de cdigo y tutoriales. Se puede descargar desde la pgina web de Android
Developers: http://developer.android.com/sdk/index.html. La versin instalada es
la 14.
ADT
El plug-in ADT2 para Eclipse es una extensin del entorno de desarrollo que permite la
creacin y depuracin de aplicaciones Android. Gracias a este plugin se puede hacer
1
2
Kit de Desarrollo de Software

Android Development Tools
66
4.2. I NSTALACIN
Y CONFIGURACIN DEL ENTORNO DE TRABAJO
lo siguiente: crear proyectos para aplicaciones Android, acceder a las herramientas de

emuladores Android, compilar y debugar aplicaciones, crear paquetes APK (ejecutables
de Android), crear certificados digitales para firmar los APKs, entre otras cosas. Su
instalacin se realiza directamente desde Eclipse.
Una vez instalado esto hay que crear una ADV 3 para poder testear las aplicaciones
que se van a programar. Esta mquina virtual emula el comportamiento de un
smartphone con las caractersticas que se le especifiquen. Sin embargo, debido a
la naturaleza de este proyecto, la mayora de las pruebas se han realizado directamente sobre dispositivos fsicos (smartphones con sistema operativo Android 2.3,
Gingerbread).
La gua completa para instalar estos componentes se encuentra en el anexo B.1.
4.2.2
B ASE DE DATOS REMOTA
Se instala una base de datos en el servidor que se utilizar para los sistemas de alerta
de los residentes: de posicionamiento y batera baja. Para crear la base de datos se
instala el paquete LAMP4 en el servidor. Con la idea de facilitar la tarea de creacin
y gestin de la base de datos, se instala tambin el programa MySQL Navigator, que
permite manejar la base de datos mediante una interfaz grfica.
El acceso desde las aplicaciones Android a esta base de datos se hace de la siguiente
manera: las aplicaciones hacen peticiones HTTP contra Apache, que ejecuta los
script PHP correspondientes, accediendo a la base de datos MySQL y devolviendo los
resultados obtenidos en formato JSON a las aplicaciones.
La instalacin del paquete LAMP, y la creacin de la base de datos mediante MySQL
Navigator se encuentra en el anexo B.2.1.
4.2.2.1
E STRUCTURA
DE LA BASE DE DATOS
Como puede verse en la figura 4.1, la base de datos est formada por dos tablas:
MyAlerts y MyCoordinates.
* MyAlerts: Esta tabla se utiliza para controlar el estado de los residentes. Al dar
3
Android Virtual Machine

LAMP: Acrnimo referido a la primera letra de Linux (sistema operativo), Apache HTTP (servidor), MySQL (software de base de datos) y PHP (software de scripting), componentes principales para
construir un web server.
4
67
DE LOS
S OFTPHONES
FIGURA 4.1: Tablas de la base de datos ubicada en el servidor.
de alta a un residente en el sistema, se crea una entrada con el nmero y nombre

de usuario y dos flags de alerta desactivados. El flag alert_flag se utiliza para
controlar la ubicacin del residente: mientras ste permanezca dentro de la zona
permitida, el flag se mantendr a 0; si sale de dicha zona, el flag cambiar a 1.
Del mismo modo, battery_flag se utiliza para controlar el estado de batera del
dispositivo del residente: si la batera baja del 15%, el flag se pone a 1.
* MyCoordinates: Esta tabla se utiliza para controlar la ubicacin de los residentes
que estn fuera de la zona permitida. Mientras el residente se encuentre
fuera de esta zona, se van almacenando en la tabla sus coordenadas GPS para
poder localizarlo. Para ello se crean entradas con el nmero de usuario, y las
coordenadas en formato (latitud, longitud).
4.2.2.2
S CRIPTS PHP
El acceso a la base de datos MySQL se hace mediante scripts PHP. Estos scripts permiten
realizar consultas y/o modificar los atributos de la base de datos desde las aplicaciones
Android.
A continuacin se explica la funcin y utilizacin de los scripts implementados en
este proyecto, diferenciando los utilizados por cada aplicacin. El cdigo de estos
scripts se encuentra en el anexo B.2.2.
Softphone A: residentes
68
4.2. I NSTALACIN
Y CONFIGURACIN DEL ENTORNO DE TRABAJO
insert_alert_user.php , get_alert_user.php , update_alert_user.php ,

delete_alert_user.php
Se utilizan desde la gestin de cuentas de la aplicacin y afectan nicamente a la tabla
de alertas MyAlerts. Insertan, borran, o modifican los datos del usuario en la base de
datos (nombre y nmero de cuenta, nicamente).
update_alert_flag.php
Se utiliza desde el servicio de alertas de localizacin de la aplicacin y afecta
nicamente a la tabla de alertas MyAlerts. Actualiza el valor del flag de alerta de
posicionamiento del usuario que lo ejecuta.
update_battery_flag.php
Se utiliza desde el broadcast receiver de alerta de batera de la aplicacin y afecta
nicamente a la tabla de alertas MyAlerts. Actualiza el valor del flag de alerta por
batera baja del usuario que lo ejecuta.
insert_coordinates.php
Se utiliza desde el servicio de alertas de localizacin de la aplicacin y afecta nicamente a la tabla de coordenadas MyCoordinates. Inserta una coordenada GPS (latitud,
longitud) en la base de datos, indicando el nmero del usuario al que pertenece.
Softphone B: recepcin del centro
get_alert_coordinates.php
Se utiliza desde el mapa de localizacin de la aplicacin y afecta a ambas tablas. Obtiene un listado con todos los residentes que se encuentran en estado de alerta (fuera
de la zona permitida, con alert_flag=1) y la ltima coordenada GPS introducida por
cada uno de ellos.
get_user_coordinates.php
Se utiliza desde el mapa de localizacin de la aplicacin y afecta a ambas tablas. Obtiene la ltima coordenada introducida en la base de datos por el usuario especificado.
check_battery_alert.php
Se utiliza desde un servicio de la aplicacin y afecta a la tabla de alertas MyAlerts.
Comprueba si hay alguna alerta de batera baja activada (battery_flag=1).
get_battery_alerts.php
Se utiliza desde el listado de alertas de batera de la aplicacin y afecta a la tabla de
alertas MyAlerts. Obtiene un listado con todos los residentes que se encuentran en
estado de alerta por batera baja (nmero y nombre de usuario) ordenados por nombre.
69
4.2.3
DE LOS
S OFTPHONES
E XTENSIONES DE EMERGENCIA EN A STERISK
Como se ha explicado en la introduccin, se utilizan unas extensiones especiales

en el servidor SIP para avisar a las aplicaciones de que deben iniciar una serie de
acciones. Estas extensiones estn definidas en el dialplan de Asterisk bajo el contexto
[android_V A].
Las aplicaciones de los residentes y la recepcin se comunican entre ellas (de forma
interna) mediante llamadas perdidas a estas extensiones especiales, de forma invisible
a los usuarios. Para ello se lanzan o reciben llamadas procedentes de estas extensiones,
marcadas como de emergencia, que se deben procesar de forma diferente al resto, ya
que se utilizarn como disparador para que las aplicaciones ejecuten ciertas acciones.
La utilidad de stas se explicar con ms detalle para cada aplicacin en los siguientes
apartados.
* Extensin 033: Alerta de localizacin. Esta extensin se marca automticamente desde el softphone de un residente al salir/entrar de la zona permitida. Se
origina entonces una llamada entre la recepcin y el llamante, informando a la
recepcin, al descolgar, del nmero de usuario del residente que ha generado la
alerta.
* Extensin 034: Peticin de inicio de seguimiento. Esta extensin se marca
automticamente desde el softphone de recepcin al solicitarse el seguimiento
de la ubicacin de un residente. Esto genera una llamada perdida al usuario
pertinente, que empezar a enviar sus coordenadas de posicin a la base de datos.
* Extensin 035: Peticin de finalizacin de seguimiento. Esta extensin
se marca automticamente desde el softphone de recepcin al solicitarse la
finalizacin del seguimiento de un residente. Opera de la misma forma que la
anterior, generando una llamada perdida al usuario pertinente, que en este caso
detendr el envo de coordenadas a la base de datos.
La definicin de estas extensiones se encuentra detallado en el anexo B.3.
4.3
D ESARROLLO
DE LAS APLICACIONES
consisten en dos softphones: uno para los residentes y

otro para la recepcin del centro, que tambin pueden utilizar los trabajadores del
AS APLICACIONES FINALES
70
4.3. D ESARROLLO
DE LAS APLICACIONES
mismo.
Primero se ha desarrollado un softphone bsico, con unas prestaciones que
cualquier softphone en el mercado puede ofrecer: realizar y recibir llamadas, listado
de cuentas y contactos, registro de llamadas, etc. Aunque esta aplicacin tambin
puede instalarse en un terminal, se ha declarado como librera para facilitar la herencia
en las otras dos aplicaciones.
Las otras aplicaciones heredan de este softphone bsico, aadiendo funcionalidades
y caractersticas diferentes para cada una de ellas:
* Softphone A: destinado para el uso de los residentes del centro. Aade dos funcionalidades: sistema de alerta en caso de batera baja y sistema de alerta en
caso de que el residente salga de una zona permitida (se aleje demasiado de la
residencia) utilizando el sensor GPS del dispositivo fsico.
* Softphone B: destinado para el uso de la recepcin del centro. Aade tres
funcionalidades: mapa con la ubicacin de los residentes que estn fuera de la
zona permitida, peticin de seguimiento de cualquier residente (ubicacin del
residente) y comprobacin de alertas por batera baja en los softphones de los
residentes.
La interaccin entre las dos aplicaciones se realiza mediante las extensiones de

emergencia de Asterisk y la base de datos remota (ubicada en el servidor). Estas dos
aplicaciones acceden y modifican el contenido de esta base datos para los eventos
relacionados con las alertas de posicionamiento y batera.
A continuacin se ofrece una explicacin ms detallada de la estructura y el
funcionamiento de estas aplicaciones, con ejemplos de cdigo cuando sea relevante.
4.3.1
S OFTPHONE BSICO
La primera aplicacin desarrollada, llamada LDDSoftphoneLibrary, consiste en un

softphone bsico. Esta aplicacin tiene el funcionamiento de un softphone con
prestaciones muy bsicas: recepcin y emisin de llamadas VoIP, agenda de contactos,
lista de cuentas SIP (clientes SIP) con las que poder logarse en el servidor de VoIP
y listado de registro de llamadas. En el transcurso de una llamada se dispone de:
funcin de altavoz y acceso a un teclado para mandar cdigos DTMF (por ejemplo,
para el buzn de voz).
71
DE LOS
S OFTPHONES
FIGURA 4.2: Men tab de la aplicacin con: a) Pantalla principal de la aplicacin. b)

Lista de contactos. c) Registro de llamadas.
Los datos de la agenda de contactos y la lista de cuentas SIP se guardan en una

base de datos interna (en el dispositivo fsico). Tambin se guardan en ella los datos
de las llamadas del registro de llamadas. Esta base de datos, de tipo SQLite, es propia
de cada aplicacin y por tanto no se puede acceder a ella desde otras aplicaciones.
Su acceso, as como todas las peticiones que se pueden realizar sobre ella, se han
encapsulado en una clase llamada DBAdapter, facilitando as el acceso desde cualquier
clase de la aplicacin que lo requiera.
El aspecto que presenta la aplicacin al iniciarla se puede observar en la
figura 4.2(a). Como se aprecia en dicha figura, la pantalla principal consta de un men
tipo TAB con tres pestaas. Estos mens tienen la siguiente apariencia: una barra con
pestaas en la parte superior de la pantalla y en el resto, una zona donde aparece la
actividad relativa a cada pestaa. En la primera aparece el teclado que permite realizar
llamadas una vez logados en el servidor de VoIP. La segunda, en la figura 4.2(b),
muestra un listado de todos los contactos que hay guardados en la aplicacin, con la
posibilidad de realizar una marcacin directa al pulsar sobre cada uno de ellos. En la
tercera se encuentra el registro de llamadas, donde se muestran los datos de todas las
llamadas realizadas y recibidas: nmero llamante, nmero llamado, tipo de llamada
72
4.3. D ESARROLLO
DE LAS APLICACIONES
FIGURA 4.3: a) Men principal de la aplicacin para los residentes. b) Dilogo que
aparece al cerrar las aplicaciones.
(entrante, saliente, perdida), fecha, hora y duracin de la llamada, como se puede ver
en la figura 4.2(c). Al pulsar sobre una llamada del registro, se ofrece la posibilidad de
rellamar o devolver una llamada a ese nmero de forma directa (sin tener que marcar).
Como se puede ver en la figura 4.3(a), el men de la pantalla principal permite:
acceder al listado de cuentas SIP, aadir un nuevo contacto y cerrar la aplicacin. La
aplicacin puede cerrarse de dos formas: mediante la tecla BACK del dispositivo o
mediante la opcin Cerrar del men. La primera opcin permite seguir recibiendo
llamadas SIP aunque la aplicacin no sea visible en pantalla. La segunda, en cambio,
cierra por completo la aplicacin y por tanto no se pueden recibir llamadas. Por eso,
al cerrar la aplicacin desde el men, se muestra al usuario un dilogo de advertencia
informndole de este hecho (figura 4.3(b)).
La lista de cuentas aparece en la figura 4.4(a) y muestra los datos de las cuentas
SIP (nmero y nombre) que el usuario puede utilizar para registrarse en el servidor
de VoIP. Los datos que se guardan para cada cuenta son: nmero y nombre de
usuario, direccin del servidor de VoIP y contrasea requerida por el servidor para
logarse. Desde esta pantalla pueden crearse cuentas nuevas, as como modificar o
73
DE LOS
S OFTPHONES
FIGURA 4.4: a) Listado de cuentas con men abierto. b) Men context de una cuenta
(opciones de la cuenta).
eliminar los datos de las ya existentes. La aplicacin est programada para logarse
automticamente en el servidor con la ltima cuenta que se utiliz, por lo que si el
usuario desea cambiar de cliente SIP (cambiar la cuenta activa), debe hacerlo desde
esta pantalla, mediante el men context de la figura 4.4(b).
Al realizar o recibir una llamada, aparecer en el dispositivo la pantalla de la
figura 4.5, donde se muestra el nmero o identificador del llamante/llamado y varios
botones que permiten: descolgar/colgar la llamada, activar/desactivar la funcin de
altavoz y acceder a un teclado para poder introducir tonos DTMF durante la llamada,
permitiendo al usuario interactuar con el servidor, por ejemplo, para navegar por el
buzn de voz. La aplicacin utiliza el sensor de proximidad del terminal fsico para
bloquear y apagar la pantalla si sta se acerca demasiado a la cara. Este mecanismo se
utiliza para evitar tocar los botones de la pantalla con la cara o la oreja durante una
llamada.
Las notificaciones son muy importantes en esta aplicacin, ya que informan al
usuario del estado del softphone y de las posibles incidencias relacionadas con el
servidor SIP, permitiendo la interaccin del mismo para solventarlas. Al abrir la apli-
74
4.3. D ESARROLLO
DE LAS APLICACIONES
FIGURA 4.5: Pantalla mostrada durante las llamadas en las aplicaciones.
cacin, aparece una notificacin en la barra de estado con el nombre de la aplicacin

LDDSoftphone y la cuenta con la que se ha logado el terminal al servidor SIP (cuenta
activa). Esta notificacin es permanente y slo desaparece al cerrarse la aplicacin
mediante la opcin Cerrar del men principal. Si no hay una cuenta activa (no se ha
podido logar en el servidor SIP o no existen los datos de esa cuenta), se informa al
usuario mediante otra notificacin que le permite ir directamente al listado de cuentas
para realizar las modificaciones pertinentes. Tambin aparece una notificacin para
informar al usuario de que tiene llamadas perdidas, con acceso directo al registro de
llamadas para poder comprobarlas.
4.3.1.1
I NTEGRACIN
DE LA
V O IP
EN LA APLICACIN
La integracin de la VoIP en la aplicacin se consigue gracias a la utilizacin de la API

SIP nativa de Android. Esta API se encuentra disponible en todas las versiones a partir
de la 2.3 (Gingerbread). Su integracin permite aadir caractersticas de telefona
VoIP basada en el protocolo SIP en los softphones desarrollados. De esta forma, se
puede utilizar para establecer llamadas de voz entrantes y salientes de forma sencilla,
sin tener que manejar sesiones ni comunicaciones a nivel de transporte.
En la tabla 4.1 se puede ver un resumen de las clases y la interfaz incluidas en la
75
DE LOS
S OFTPHONES
TABLA 4.1: Clases e interfaz incluidos en la API SIP de Android.

Clase / Interfaz
SipAudioCall
SipAudioCall.Listener
SipErrorCode
SipManager
SipProfile
SipProfile.Builder
SipSession
SipSession.Listener
SipSession.State
SipRegistrationListener
Descripcin
Maneja las llamadas SIP.
Listener para eventos relacionados con llamadas SIP.
Define cdigos de error retornados durante acciones SIP.
Proporciona APIs para tareas SIP, como iniciar conexiones
SIP, y proporciona acceso a servicios SIP relacionados.
Define un perfil SIP, incluyendo informacin de una cuenta
SIP, dominio y servidor.
Clase de ayuda para crear un SipProfile.
Representa una sesin SIP asociada a una dilogo SIP o a
una transaccin independiente fuera del dilogo.
Listener para eventos relacionados con sesiones SIP.
Define estados de la sesin SIP.
Interface, listener para eventos del registro SIP.
API SIP de Android.

Para integrar esta API en las aplicaciones desarrolladas se crean tres clases que se
encargarn de lo siguiente:
* ServiceSIP: servicio que se encarga de casi todo lo relacionado con la API SIP.
* CallReceiverSIP: broadcast receiver que maneja las llamadas SIP entrantes.
* ServiceBinder: clase de ayuda que acta como puente entre el servicio ServiceSIP
y el resto de clases de la aplicacin.
A continuacin se explica el desarrollo y funcionamiento de estas clases ms
detalladamente.
4.3.1.1.1 S ERVICE SIP
Este servicio es el alma de la aplicacin y la clase ms importante de la misma. En
l se encuentra todo el cdigo relacionado con la API SIP de Android y contiene, por
tanto, todos los mtodos que permiten a la aplicacin interactuar con el servidor SIP.
Sus funciones principales son: registrar/desregistrar una cuenta SIP en el servidor y
realizar llamadas. Las clases de la aplicacin que necesiten interactuar con el servidor
SIP (para realizar/colgar llamadas, logar/deslogar un cliente SIP, etc.) pueden hacerlo
a travs de este servicio mediante la clase ServiceBinder.
76
4.3. D ESARROLLO
DE LAS APLICACIONES
El servicio ServiceSIP se lanza al abrir la aplicacin y no se detiene hasta que el

usuario sale de la misma mediante la opcin Cerrar del men principal. Si se sale de la
aplicacin con la tecla BACK, el servicio sigue activo, ya que se deben seguir recibiendo
llamadas SIP y eventos relacionados con la aplicacin aunque sta no est visible en la
pantalla del dispositivo.
Lo primero que se hace al crearse el servicio es especificar el broadcast receiver que
se encargar de recibir las llamadas entrantes (CallReceiverSIP, en este caso), cuyo
funcionamiento se explicar ms adelante.
protected void prepareReceiver () {
/* * se especifica un IntentFilter que se encargara de lanzar el
broadcast receiver CallReceiverSIP al interceptar el aviso de
recepcion de una llamada entrante */
IntentFilter filter = new IntentFilter () ;
filter . addAction ( " softphone . LDD . INCOMING_CALL " ) ;
callReceiver = new CallReceiverSIP () ;
this . registerReceiver ( callReceiver , filter ) ;
}
Al iniciar el servicio por primera vez, se crea un objeto de tipo SipManager, propio
de la API SIP de Android y se registra la cuenta de usuario (cliente SIP) que se va a
utilizar para logarse en el servidor SIP. A travs de este objeto se podrn realizar las
siguientes acciones: iniciar sesiones SIP, realizar y recibir llamadas, registrar/desregistrar cuentas SIP en el servidor y verificar la conectividad de la sesin.
Para registrar la cuenta de usuario SIP en el servidor se utiliza el mtodo
initiateLocalProfile, cuyas variables de entrada son los datos de la cuenta (nombre
o nmero, direccin del servidor y contrasea de acceso). Al iniciar la aplicacin,
se intenta recuperar la informacin de la ltima cuenta utilizada para registrarse de
nuevo. Si no es posible, se muestra la notificacin de la figura 4.6(a) para informar al
usuario de que no hay cuenta activa y no se ejecuta este mtodo. Hasta que el usuario
no especifique una cuenta vlida para registrarse en el servidor SIP, la aplicacin no
podr enviar ni recibir llamadas SIP.
Al utilizar la API SIP, cada cuenta SIP est representada por un objeto de tipo
SipProfile. Por tanto, para registrar una cuenta, primero se crea el objeto SipProfile
con los datos de las variables de entrada.
SipProfile . Builder builder = new SipProfile . Builder ( username , domain ) ;
builder . setPassword ( password ) ;
me = builder . build () ;
A continuacin, se habilita el perfil creado (se da la orden de registro de la cuenta en

el servidor) para que se puedan enviar/recibir llamadas SIP, especificando de nuevo,
77
DE LOS
S OFTPHONES
FIGURA 4.6: a) Notificacin que aparece cuando no hay ninguna cuenta activa. b)
Notificacin permanente que aparece cuando hay una cuenta logada en el servidor SIP.
mediante el pending intent (pi), el broadcast receiver que se encargar de recibir las
llamadas entrantes.
manager . open ( me , pi , null ) ;
Finalmente, se crea un listener que se encargar de manejar los eventos relacionados

con el registro del cliente SIP en el servidor.
manager . setRegistrationListener ( me . getUriString () , new
SipRegistrationListener () {
public void onRegistering ( String localProfileUri ) {
// Noop .
}
public void onRegistrationDone ( String localProfileUri , long
expiryTime ) {
/* * al registrarse la cuenta en el servidor SIP , se cancela la
notificacion de error de registro y se envia la notificacion de
cuenta activa */
NM . cancelFalloRegistro () ;
NM . showNotificationCuentaActiva ( me . getUserName () + " @ " +
me . getSipDomain () ) ;
}
78
4.3. D ESARROLLO
DE LAS APLICACIONES
FIGURA 4.7: a) Notificacin que aparece al no poder registrar la cuenta especificada

en el servidor SIP. b) Notificacin que indica la existencia de llamadas perdidas.
}) ;
public void onRegistrationFailed ( String localProfileUri , int

errorCode , String errorMessage ) {
/* * si no se puede registrar la cuenta , se envia una notificacion
de cuenta incorrecta para informar al usuario */
if ( errorCode != -4) {
NM . showNotificationFalloRegistro ( me . getUserName () + " @ " +
me . getSipDomain () ) ;
}
}
Si se ha realizado el registro de la cuenta de forma satisfactoria en el servidor

SIP, se actualiza la notificacin permanente en la barra de estado con los datos
(nmero@servidor) de la cuenta activa, como se puede ver en la figura 4.6(b). A
partir de este momento, la aplicacin est lista para poder enviar/recibir llamadas SIP.
En caso de no poderse registrar (porque no se dispone de conectividad con el servidor
SIP, la cuenta es incorrecta, etc.), se informa al usuario mediante la notificacin de la
figura 4.7(a) para que pueda solventar el problema.
Si ya no se desea utilizar ms el perfil actual (se quiere cambiar de cuenta activa
79
DE LOS
S OFTPHONES
o se cierra la aplicacin), se utiliza el mtodo closeLocalProfile para deslogarse del

servidor. Si no se est cerrando la aplicacin, se muestra una notificacin para informar
al usuario de que no hay ninguna cuenta logada en el servidor (figura 4.6(a)) y desde
ese momento no se pueden enviar ni recibir llamadas SIP en la aplicacin.
public void closeLocalProfile () {
/* * cancela la notificacion de cuenta activa */
NM . cancelCuentaActiva () ;
/* * si no se esta parando el servicio , informa al usuario de que
no hay cuenta activa */
if (! isOnDestroy ) {
NM . showNotificationNoHayCuenta () ;
}
/* * si no existe el manager , no hace nada */
if ( manager == null ) {
return ;
}
try {
/* * desloga la cuenta SIP */
if ( me != null ) {
manager . close ( me . getUriString () ) ;
}
} catch ( Exception ee ) {
Log . d ( " ServiceSIP / onDestroy " , " Failed to close local
profile . " , ee ) ;
}
}
Como se ha comentado anteriormente, en este servicio se encuentran todos los

mtodos relacionados con la API SIP de Android, que el resto de clases de la aplicacin
utilizan para realizar distintas acciones como: realizar/colgar una llamada SIP,
activar/desactivar el altavoz del dispositivo durante una llamada, enviar tonos DTMF
e introducir una llamada en el registro de llamadas. De estos mtodos se destacan
los dos ms importantes: realizar una llamada SIP y crear una nueva entrada en el
registro de llamadas.
Para realizar una llamada SIP se utiliza el mtodo initiateCall:
/* * Realiza una llamada saliente a la direccion especificada por
sipAddress * */
public void initiateCall ( String sipAddress ) {
try {
/* * Listener para eventos relacionados con la llamada SIP
saliente */
SipAudioCall . Listener listener = new SipAudioCall . Listener () {
/* * se ejecuta al establecer la llamada */
@Override
80
4.3. D ESARROLLO
DE LAS APLICACIONES
public void onCallEstablished ( SipAudioCall call ) {

time_ini = SystemClock . uptimeMillis () ;
date = new SimpleDateFormat ( " HH : mm
dd / MM / yy " ) . format ( new Date () ) ;
call . startAudio () ;
call . setSpeakerMode ( false ) ;
}
/* * se ejecuta cuando el otro extremo finaliza la llamada */
@Override
public void onCallEnded ( SipAudioCall call ) {
time_end = SystemClock . uptimeMillis () ;
sendBroadcast ( new Intent ( Const . CALL_ENDED ) ) ;
}
};
/* * se realiza la llamada SIP */
call = manager . makeAudioCall ( me . getUriString () , sipAddress ,
listener , 30) ;
}
catch ( Exception e ) {
Log . i ( " ServiceSIP / InitiateCall " , " Error when trying to
close manager . " , e ) ;
if ( me != null ) {
try {
/* * desloga la cuenta SIP */
manager . close ( me . getUriString () ) ;
} catch ( Exception ee ) {
Log . i ( " ServiceSIP / InitiateCall " , " Error when
trying to close manager . " , ee ) ;
ee . printStackTrace () ;
}
}
/* * si hay una llamada en curso , la cierra */
if ( call != null ) {
call . close () ;
}
}
Para ejecutar este mtodo se necesitan tres cosas: un SipProfile local registrado
(cuenta activa del softphone logada correctamente al servidor SIP), una direccin SIP
vlida para recibir la llamada y un objeto de tipo SipManager.
Primero se crea un listener de tipo SipAudioCall.Listener que se encarga de
monitorizar y manejar los eventos relacionados con la llamada SIP saliente. Como se
ver ms adelante, el listener encargado de las llamadas entrantes se encuentra en el
broadcast receiver CallReceiverSIP. En este listener se define el comportamiento de
la aplicacin al establecer y colgar la llamada. Al establecerse la llamada, se guardan
81
DE LOS
S OFTPHONES
datos para el registro de llamadas (tiempo de inicio y fecha) y a continuacin se activa

el audio de la llamada. Al colgarse la llamada, se guarda el tiempo de finalizacin de
la llamada y se lanza el broadcast que activar el registro de la llamada.
Una vez definido el listener, se realiza la llamada mediante el mtodo makeAudioCall
del objeto SipManager, utilizando los siguientes parmetros: perfil local SIP (cuenta
llamante), direccin SIP del llamado, listener definido antes y timeout en segundos.
call = manager . makeAudioCall ( me . getUriString () , sipAddress , listener ,30) ;
Al finalizar cualquier llamada (tanto entrantes, salientes o perdidas) se ejecuta el

mtodo entradaRegistro que se encarga de aadir una nueva entrada al registro de
llamadas en la base de datos local. En esta tabla se guardan, para cada llamada, los
siguientes datos: tipo de llamada (saliente, entrante, perdida), nmero de cliente
SIP llamante, nmero de cliente SIP llamado, fecha y hora de inicio y duracin de la
llamada. Si se trata de una llamada perdida, se muestra una notificacin en la barra
de estado para informar al usuario, como se puede ver en la figura 4.7(b).
El servicio ServiceSIP se detiene al salir de la aplicacin mediante la opcin Cerrar
del men principal. En este caso deben realizarse una serie de acciones para asegurarse
de que se corta todo contacto con el servidor SIP: se desloga la cuenta SIP activa del
servidor, se desactiva el broadcast receiver (para que no se puedan recibir llamadas) y
se cancelan todas las notificaciones que estn activas en la barra de estado.
/* * se ejecuta al cerrar el servicio */
@Override
public void onDestroy () {
Toast . makeText ( this , R . string . local_service_stopped ,
Toast . LENGTH_SHORT ) . show () ;
/* * si hay una llamada en curso , la finaliza */
if ( call != null ) {
call . close () ;
}
/* * desloga al usuario del servidor SIP */
isOnDestroy = true ;
closeLocalProfile () ;
/* * desregistra el broadcast receiver de las llamadas entrantes */
if ( callReceiver != null ) {
this . unregisterReceiver ( callReceiver ) ;
}
/* * cancela todas las notificaciones activas */
NM . cancelAll () ;
hasStarted = false ;
super . onDestroy () ;
}
82
4.3. D ESARROLLO
DE LAS APLICACIONES
4.3.1.1.2 C ALL R ECEIVER SIP

Como se ha visto en el apartado anterior, el servicio ServiceSIP sirve para preparar
la aplicacin para utilizar SIP, realizar llamadas salientes y manejar las llamadas
en curso. Para recibir llamadas entrantes, se crea este broadcast receiver, que se
ejecuta de manera automtica cada vez que el terminal recibe una llamada SIP.
CallReceiverSIP procesa todas las llamadas SIP entrantes, las recoge y las cede
a la actividad CallDisplay, que se encarga de manejarlas mediante los mtodos
contenidos en el servicio ServiceSIP.
De forma anloga al caso de la generacin de una llamada saliente, lo primero que
se hace es definir un listener de tipo SipAudioCall.Listener que se encarga de monitorizar y manejar los eventos relacionados con la llamada SIP entrante. En este caso
slo es necesario definir el comportamiento al colgar la llamada: se enva el broadcast
para aadir la llamada finalizada al registro de llamadas, si procede.
/* * Listener para eventos relacionados con la llamada SIP entrante */
listener = new SipAudioCall . Listener () {
/* * se ejecuta al entrar una nueva llamada */
@Override
public void onRinging ( SipAudioCall call , SipProfile caller ) {
try {
// Noop .
} catch ( Exception e ) {
e . printStackTrace () ;
}
}
/* * se ejecuta al finalizar la llamada entrante */
/* * si la linea no esta ocupada , se registra y finaliza la
llamada */
if (! noRegister ) {
setEndingTime () ;
} else {
noRegister = false ;
}
}
};
A continuacin se recoge la llamada mediante el mtodo takeAudioCall del objeto

SipManager, utilizando los siguientes parmetros: intent perteneciente a la llamada entrante y listener definido antes. Como los broadcast receivers no pueden conectarse a los
servicios mediantes binders, para poder recoger la llamada se utiliza el objeto sipService,
que es de tipo ServiceSIP y que hace referencia al servicio que est corriendo en el
terminal. Se debe aclarar que recoger la llamada no implica descolgarla. Esto slo
significa que la llamada ha llegado al terminal y que en el otro extremo ya se recibe
tono.
83
DE LOS
S OFTPHONES
incomingCall = sipService . manager . takeAudioCall ( intent , listener ) ;
Una vez recogida, se pasa la llamada al servicio, se obtiene el identificador de llamada y se lanza la actividad CallDisplay, cuya pantalla es la que permitir al usuario
interactuar con la llamada entrante (colgar/descolgar la llamada, activar/desactivar
altavoz, etc.). Esta pantalla es la mostrada en la figura 4.5.
La aplicacin est programada de manera que slo se puede llevar a cabo una
conversacin a la vez. Si se recibe una nueva llamada entrante cuando ya hay una en
curso, la nueva llamada se cuelga automticamente (desviando al llamante al buzn
de voz correspondiente) y no se refleja en el registro de llamadas.
4.3.1.1.3 S ERVICE B INDER

Como se ha comentado en la explicacin de ServiceSIP, la mayora de los mtodos
declarados en este servicio se utilizan desde otras clases de la aplicacin. Esto es
posible mediante la utilizacin de binders, que permiten a las clases conectarse con el
servicio e interactuar con l, pudiendo as utilizar sus mtodos, como: realizar una
llamada, colgar/descolgar, logar/deslogar una cuenta SIP, etc.
Con este fin se crea la clase de ayuda ServiceBinder, que acta como clase
intermedia y se encarga de crear el enlace (bind) entre el servicio y la clase que lo
necesite. Por otra parte, algunas clases necesitan realizar ciertas acciones una vez
establecida la conexin con el servicio (por ejemplo, realizar una llamada). Estas
acciones se definen tambin en esta clase, evitando as que se intente acceder al
servicio antes de que se haya realizado el enlace.
4.3.2
S OFTPHONE PARA RESIDENTES
La aplicacin LDDSoftphoneA est desarrollada especficamente para su utilizacin por

parte de los residentes del centro. Su funcionamiento base es el mismo que el del
softphone bsico, con las siguientes caractersticas aadidas:
* Por motivos de seguridad, se quiere evitar que los residentes se alejen demasiado
del centro. Para ello se crea un sistema de alertas que utiliza el sensor GPS del
terminal fsico para determinar la ubicacin del usuario y alertar a la residencia
si ste sale de una zona concreta.
* Tambin se quiere evitar que los residentes se queden sin batera en el terminal,
dejando totalmente inutilizado el sistema de alertas anterior. Por ese motivo se
crea tambin un mecanismo para que los trabajadores de la residencia puedan
84
4.3. D ESARROLLO
DE LAS APLICACIONES
FIGURA 4.8: Listado de cuentas con acceso protegido por contrasea.
saber si el nivel de batera del terminal de un residente desciende del 15%.

Los cambios de estado de los residentes (alertas activadas/desactivadas) as como
las coordenadas de posicionamiento se guardan en la base de datos remota. El acceso
a esta base de datos as como todas las peticiones que se pueden realizar sobre ella
se han encapsulado en una clase llamada DBRemoteHelperA, facilitando as el acceso
desde cualquier clase de la aplicacin que lo requiera.
Cada residente tiene una entrada en la tabla de alertas (MyAlerts) que se crea, de
forma automtica, al asignarle una cuenta SIP en el listado de cuentas de la aplicacin.
A partir de ese momento, se puede monitorizar al usuario del terminal. Cada cambio
que se realice sobre el listado de cuentas (aadir, editar o borrar una cuenta) queda
reflejado tambin en la base de datos remota. Por ese motivo, el acceso al listado
de cuentas de esta aplicacin est protegido por contrasea, de forma que slo los
trabajadores del centro pueden acceder a ella, como se puede ver en la figura 4.8. As
se evita que los residentes puedan realizar cualquier modificacin sobre las cuentas
SIP (como cambiar la cuenta con la que estn logados o eliminarla). De esta forma, se
evita tambin que puedan modificar los datos relativos a la cuenta (nombre y nmero)
que constan en la base de datos remota y que sirven a los trabajadores del centro para
identificarlos.
85
4.3.2.1
A LERTAS
DE LOS
S OFTPHONES
DE BATERA
El sistema Android genera dos eventos relacionados con el nivel de batera del
terminal: cuando la batera est baja (por debajo del 15%) y cuando la batera se
encuentra en proceso de carga (cargando y por encima del 20% de su capacidad). En
esta aplicacin se capturan estos eventos y se acta acorde a la situacin, evitando as
que la aplicacin tenga que monitorizar el nivel de batera del dispositivo de forma
continua, lo que resulta ineficiente.
Con este objetivo, se crea BatteryLevelReceiver, un broadcast receiver que se
encargar de manejar las alertas de batera generadas por el propio terminal. Para
que la aplicacin sea capaz de capturar estos eventos, se define el broadcast receiver
en el AndroidManifest de la siguiente manera, indicando el nombre de los eventos a recoger (BATTERY_LOW, BATTERY_OK) y la clase que se encargar de manejarlos
(BatteryLevelReceiver).
< receiver
android:name = " . battery . BatteryLevelReceiver " >
< intent - filter >
< action android:name = " android . intent . action . BATTERY_LOW " / >
< action android:name = " android . intent . action . BATTERY_OKAY " / >
</ intent - filter >
</ receiver >
Cuando se produce una alerta de batera (batera baja / en proceso de carga),

se activa/desactiva el flag correspondiente al residente en la base de datos remota
(battery_flag). Como estos eventos son generados por el sistema y, por tanto, pueden
ocurrir cuando la aplicacin est cerrada, se comprueba si hay conectividad a la red
(tanto por WiFi como por datos) antes de acceder a la base de datos.
4.3.2.2
A LERTAS
DE POSICIONAMIENTO
Esta aplicacin est diseada para utilizar el sensor GPS del terminal fsico donde est
instalada para controlar la ubicacin de su usuario (en este caso, el residente) y evitar
as que ste salga de una zona marcada como segura o permitida. Tambin se aade
la opcin de monitorizar la ubicacin de un residente en el interior de esta zona de
manera temporal, referido en este documento como seguimiento. Los pasos seguidos
para lograr esto se detallan a continuacin.
Para poner en marcha las alertas de posicionamiento ha sido necesario modificar parte del softphone bsico as como aadir un nuevo servicio a la aplicacin,
86
4.3. D ESARROLLO
DE LAS APLICACIONES
AlertsService, que se encarga de manejar las alertas de posicionamiento y que se

explicar ms adelante.
El sistema Android proporciona una serie de herramientas de localizacin que se
utilizan en este caso para monitorizar la posicin del usuario de la aplicacin y activar
las alertas de posicionamiento cuando convenga. Estas alertas, que permiten saber si
el usuario entra/sale de la zona permitida, se activan mediante este mtodo, que se
ejecuta al iniciarse la aplicacin:
private void alertasGPS () {
/* * inicializa el objeto que se encargara de monitorizar las
coordenadas GPS */
lm = ( LocationManager ) getSystemService ( Context . LOCATION_SERVICE ) ;
/* * especifica el servicio que se lanzara al recibir una alerta
( AlertsService ) */
AlertsPendIntent = PendingIntent . getService ( this , 0 , new
Intent ( MainLDDSoftphoneA . this , AlertsService . class ) , 0) ;
/* * activa el localizador que lanzara una alerta de proximidad al
salir / entrar de la zona especificada */
lm . addProximityAlert ( ConstA . res_latitude , ConstA . res_longitude ,
ConstA . radio , -1 , AlertsPendIntent ) ;
}
El objeto LocationManager se encarga de monitorizar las coordenadas GPS del

terminal. Para activar las alertas se utiliza el mtodo addProximityAlert, que genera
una alerta de proximidad al salir/entrar el usuario de la zona especificada por los
siguientes parmetros: latitud y longitud (punto central), radio que delimita la zona
alrededor del punto central, duracin de la alerta (siempre encendida) y clase que
manejar la alerta (AlertsService). En este caso, las coordenadas (latitud, longitud)
pertenecen a las coordenadas de la residencia y el radio est definido en unos 100
metros (aunque al no disponer de conexin de datos en el terminal de prueba, el radio
utilizado es de slo 10 metros). Al cerrar la aplicacin se eliminan estas alertas de
proximidad para que no se activen una vez cerrada.
Las peticiones de seguimiento, que tambin maneja el servicio AlertsService,
se reciben en esta aplicacin a travs de llamadas procedentes de las extensiones de
seguimiento de Asterisk. El encargado de lanzar el servicio en este caso, por tanto, es
el broadcast receiver que maneja las llamadas entrantes y hay que modificarlo para que
trate de forma diferente este tipo de llamadas. Si el identificador de la llamada recibida
pertenece a una de las extensiones de seguimiento de Asterisk definidas anteriormente
(034 o 035), se inicia/detiene el protocolo de seguimiento. Estas llamadas deben pasar
desapercibidas por el usuario del terminal, por tanto, ni se descuelgan ni se registran.
Para iniciar/detener el protocolo de seguimiento del usuario cuyo terminal recibe
87
DE LOS
S OFTPHONES
la llamada, se utiliza el siguiente mtodo que, anlogamente, inicia/detiene el servicio

AlertsService en modo seguimiento:
private void seguimiento ( String callerID ) {
if ( callerID . equals ( " 034 " ) ) {
/* * se inicia el servicio AlertsService en modo seguimiento */
Intent i = new Intent ( contexto , AlertsService . class ) ;
contexto . startService ( i ) ;
} else {
/* * se para el servicio AlertsService */
contexto . stopService ( new Intent ( contexto ,
AlertsService . class ) ) ;
}
}
Por ltimo, tambin se realizan modificaciones en el servicio ServiceSIP,

concretamente, se aaden dos mtodos nuevos que se utilizarn desde el servicio
AlertsService. El mtodo initiateLostCall realiza una llamada perdida a la extensin
de emergencia de Asterisk (033, alerta de localizacin) para notificar a la recepcin
del centro que ha habido un evento (entrada/salida de la zona permitida). Este tipo
de llamadas se realizan de forma automtica, sin conocimiento por parte del usuario
del terminal y, por tanto, no aparecen en el registro de llamadas. El mtodo whoAmI
se usa para obtener el nmero de usuario de la cuenta SIP con la que est logado el
residente al servidor SIP.
4.3.2.2.1 A LERTS S ERVICE

El servicio AlertsService es la clase ms importante de esta aplicacin y se encarga
de manejar las alertas de posicionamiento y las peticiones de seguimiento de los
residentes por parte de la recepcin del centro.
Este servicio se lanza al producirse una de estas dos situaciones: al generarse una
alerta de proximidad (entrada/salida del terminal del residente de la zona permitida);
al recibirse una llamada desde una de las extensiones de seguimiento de Asterisk
(034, inicio de seguimiento). Al iniciarse el servicio, se comprueba desde dnde se ha
ejecutado la llamada (cul de estas situaciones ha ocurrido) y se acta en consecuencia.
Para diferenciar entre estas situaciones, se utiliza el parmetro extra contenido en
el objeto intent que se le pasa al servicio, de forma automtica, al iniciarlo. Al producirse una alerta de localizacin, se inicia este servicio aadiendo un extra. Este extra es un booleano (LocationManager.KEY_PROXIMITY_ENTERING) que toma diferente
valor en funcin de si se ha producido una entrada (true) o una salida (false) de la zona
permitida. En caso de haberse solicitado un seguimiento, este extra no existe.
88
4.3. D ESARROLLO
DE LAS APLICACIONES
private void getIntentExtras ( Intent intent ) {

Bundle extras = intent . getExtras () ;
if ( extras != null ) {
/* * se ha producido una alerta de proximidad */
isEntering =
extras . getBoolean ( LocationManager . KEY_PROXIMITY_ENTERING ) ;
seguimiento = false ;
} else {
/* * se ha solicitado un seguimiento */
seguimiento = true ;
}
}
El siguiente paso es definir la forma de actuar del sistema en funcin del tipo de
alerta (entrada/salida o seguimiento) y del estado anterior del servicio. Esto ltimo
se tiene en cuenta a fin de corregir los errores derivados de la utilizacin de las
coordenadas GPS obtenidas del dispositivo, que pueden generar varias alertas del
mismo tipo seguidas, debiendo actuar slo la primera vez e ignorando las siguientes.
Alertas generadas por una alerta de proximidad (entrada/salida de la zona permitida)
Si el residente sale de la zona permitida (y este servicio no est corriendo ya), se
prepara el servicio para que monitorice los cambios de posicionamiento del dispositivo.
Como se ha comentado anteriormente, la obtencin de las coordenadas GPS del terminal se realiza mediante un objeto de tipo LocationManager. Este objeto dispone de un
mtodo (requestLocationUpdates) que permite realizar acciones siempre que se produzcan cambios de posicionamiento definidos con los siguientes parmetros: proveedor de
localizacin (GPS), intervalo mnimo entre notificaciones en milisegundos (30.000) y
metros (5) y listener para gestionar los eventos (locListener).
/* * se ejecuta si se sale de la zona permitida y el servicio no esta
corriendo ya o si se ha solicitado un seguimiento */
private void checkExitingZone () {
if (! isEntering & ! isAlreadyOn ) {
/* * crea el enlace con el servicio ServiceSIPA */
doBindService () ;
/* * inicializa el objeto que sirve para obtener las
coordenadas de localizacion */
lm = ( LocationManager )
getSystemService ( Context . LOCATION_SERVICE ) ;
/* * crea el listener que nos servira para monitorizar los
cambios de posicionamiento y definir la actuacion */
locListener = new MyLocationListener () ;
/* * se usa este metodo para que se notifiquen los cambios en
la localizacion */
lm . requestLocationUpdates ( LocationManager . GPS_PROVIDER , 30000 ,
5 , locListener ) ;
89
DE LOS
S OFTPHONES
isAlreadyOn = true ;
Como se ha visto en el cdigo anterior, el objeto de tipo LocationListener es el

encargado de actuar cada vez que se produce un cambio en las coordenadas GPS del
dispositivo. En este caso se ha implementado una clase propia (MyLocationListener)
que permite definir el comportamiento deseado para esta aplicacin. Aunque hay que
definir todos los mtodos de la clase, slo se implementa el mtodo onLocationChange:
al detectarse un cambio de posicin, se envan las nuevas coordenadas al servidor,
insertndolas en la tabla MyCoordinates de la base de datos remota.
protected class MyLocationListener implements LocationListener {
/* * se ejecuta cuando se produce un cambio en la localizacion del
dispositivo */
@Override
public void onLocationChanged ( Location location ) {
if ( location != null ) {
db . insertCoordinates ( user , getDate () ,
Double . toString ( location . getLatitude () ) ,
Double . toString ( location . getLongitude () ) ) ;
dbR . insertCoordinate ( user , location . getLatitude () ,
location . getLongitude () ) ;
}
}
/* * se ejecuta al desactivar el proveedor especificado */
@Override
public void onProviderDisabled ( String provider ) {
// Noop .
}
/* * se ejecuta al activar el proveedor especificado */
@Override
public void onProviderEnabled ( String provider ) {
// Noop .
}
/* * se ejecuta cuando hay cambios de estado en el proveedor
especificado */
@Override
public void onStatusChanged ( String provider , int status , Bundle
extras ) {
// Noop .
}
}
A continuacin, se realiza de forma automtica una llamada a la extensin de emergencia de Asterisk (033, alerta de localizacin). Esta llamada pondr en contacto al residente que ha generado la alarma con el softphone de recepcin mediante una llamada
90
4.3. D ESARROLLO
DE LAS APLICACIONES
SIP. Mientras tanto, se activa el flag de alerta de la base de datos remota y se enva
la primera coordenada. De esta forma, se asegura que siempre habr una coordenada
introducida en la base de datos para ese residente, evitando problemas al obtener las
coordenadas desde el softphone de recepcin (si se intentan obtener coordenadas antes
de que el listener haya podido insertarlas).
protected void iniciarProtocolo () {
/* * obtiene el numero de usuario que ha generado la alerta */
user = sb . getBinder () . whoAmI () ;
/* * realiza la llamada perdida a la extension de emergencia */
sb . getBinder () . initiateLostCall ( ConstA . sipEmergencyAddress ) ;
/* * si se ha producido una salida de la zona permitida , se activa
el flag de alerta del usuario en la DB remota y se envia la
ultima posicion conocida del usuario a la DB remota */
if (! isEntering ) {
dbR . updateFlag ( " alert " , user , true ) ;
sendFirstCoordinate () ;
}
/* * si se ha producido una entrada en la zona permitida , se
desactiva el flag de alerta del usuario en la DB remota y se
detiene el servicio */
else {
dbR . updateFlag ( " alert " , user , false ) ;
stopSelf () ;
}
}
A partir de este momento, y hasta que no se vuelva a entrar en la zona permitida,

la aplicacin estar introduciendo la ubicacin del residente en la base de datos remota.
Cuando el residente entra en la zona permitida, se vuelve a realizar una llamada a la extensin de emergencia de Asterisk y a continuacin se desactiva el flag
de alerta del usuario en la base de datos remota y se detiene el servicio. Al detenerse, se desactivan las actualizaciones de posicionamiento, logrando as que el servicio
deje de enviar sus coordenadas GPS a la base de datos, debido a que ya no es necesario.
Al encontrarse el usuario en el borde del radio de la zona permitida, se pueden
obtener falsas entradas/salidas de la zona que afectaran al buen funcionamiento de
la aplicacin. En caso de recibirse una falsa salida (el residente ya se encuentra fuera
de la zona) el servicio no hace nada. En caso de recibir una falsa entrada (el residente
ya se encuentra dentro), se detiene el servicio que se acaba de iniciar y no se realiza
ninguna accin ms.
Peticin de seguimiento del residente
91
DE LOS
S OFTPHONES
Si en cambio, se ha recibido una solicitud de inicio de seguimiento del residente,

el funcionamiento es muy similar al de una alerta por salida de la zona permitida. El
servicio debe enviar las coordenadas GPS con la posicin del residente a la base de
datos remota. En este caso, se ejecuta tambin el mtodo checkExitingZone, explicado
antes, que pone en marcha la actualizacin de posicionamiento y se inserta, igual que
en el caso anterior, la primera coordenada.
protected void iniciarSeguimiento () {
/* * obtiene el numero de usuario al que se quiere seguir */
user = sb . getBinder () . whoAmI () ;
/* * se envia la ultima localizacion conocida */
sendFirstCoordinate () ;
}
Si la solicitud recibida es para finalizar el seguimiento del residente, no se lanza

el servicio, simplemente se ejecuta el mtodo onDestroy del mismo, que detiene el
servicio y desactiva las actualizaciones de posicionamiento, dejando de enviar las
coordenadas a la base de datos remota.
4.3.3
S OFTPHONE PARA LA RECEPCIN DEL CENTRO
La aplicacin LDDSoftphoneB est diseada especialmente para su utilizacin desde un

dispositivo que se encuentre en la recepcin del centro. Partiendo de las caractersticas
del softphone bsico, se aaden las siguientes funcionalidades:
* Se crea un sistema de comprobacin de alertas de posicionamiento consistente en
un mapa que permite monitorizar la ubicacin de los residentes que se encuentran fuera de la zona permitida. Adems, por motivos de seguridad, se aade la
posibilidad de solicitar el seguimiento de un residente en concreto aunque ste se
encuentre dentro de la zona permitida. Su ubicacin tambin aparecer marcada
en el mapa.
* Se incluye un sistema de comprobacin de las alertas de batera baja generadas
por los dispositivos de los residentes. De esta manera, los trabajadores podrn
alertar a los residentes de ste problema y solventarlo.
Para comprobar si hay residentes en estado de alerta (de posicionamiento o
batera) y obtener sus coordenadas, esta aplicacin debe consultar a la base de datos
remota. Por lo tanto, se crea una clase de ayuda llamada DBRemoteHelperB similar a la
utilizada en la aplicacin anterior, pero con peticiones a la base de datos adaptadas a
las necesidades de esta aplicacin.
92
4.3. D ESARROLLO
DE LAS APLICACIONES
FIGURA 4.9: Men principal del softphone para la recepcin del centro.
Se aaden al men principal dos opciones que permiten al usuario acceder a las
pantallas que le permitirn comprobar si hay alertas de posicionamiento o batera
activadas. Por tanto, el aspecto del men de la pantalla principal de esta aplicacin es
el mostrado en la figura 4.9.
4.3.3.1
C OMPROBACIN
DE ALERTAS DE BATERA
Los terminales fsicos de los residentes no deben quedarse nunca sin batera, ya que
esto inutilizara el sistema de alertas de posicionamiento detallado en la aplicacin
anterior. Para evitarlo, se disea un mecanismo que permita a los trabajadores del
centro (en este caso, al personal de recepcin) comprobar el estado de la batera de
los terminales de los residentes mediante consultas a los flags de alerta battery_flag de
la base de datos remota.
El sistema Android proporciona una herramienta que permite activar una especie
de alarma que se utiliza, en este caso, para comprobar de forma peridica si hay alertas
por batera baja en la base de datos remota. Esta alarma se activa mediante el siguiente
mtodo, que se ejecuta al iniciarse la aplicacin:
/* * Activa una alarma cada 30 minutos que comprueba si hay alertas de
bateria baja en la DB remota */
93
DE LOS
S OFTPHONES
protected void checkForBatteryAlerts () {

AlarmManager aM = ( AlarmManager )
getSystemService ( Context . ALARM_SERVICE ) ;
/* * se define un pending intent con el servicio que se quiere
lanzar al saltar la alarma ( BatteryLevelChecker ) */
PendingIntent pendingIntent = PendingIntent . getService ( this , 0 ,
new Intent ( this , BatteryLevelChecker . class ) , 0) ;
/* * la primera alarma se configura para que salte al minuto de
iniciar la aplicacion (30 s para test ) */
long startTime = SystemClock . uptimeMillis () +30000;
/* * tiempo de repeticion de alarma cada 30 mins (1 min para test ) */
long repeat_alarm_every = 60000;
/* * se establece la repeticion de alarma */
aM . setRepeating ( AlarmManager . RTC_WAKEUP , startTime ,
repeat_alarm_every , pendingIntent ) ;
}
El objeto AlarmManager permite activar una alarma cada n minutos, indicando

qu se debe hacer cada vez que salte (en este caso, comprobar las alertas de batera
de la base de datos remota). La alarma se activa mediante el comando setRepeating,
especificando los siguientes parmetros: tipo de alarma, tiempo de inicio, cada
cunto debe repetirse y la clase que manejar la alarma (BatteryLevelChecker).
Este tipo de alarmas se activan aunque la aplicacin no est corriendo, pero se
deshabilitan al reiniciar el terminal. Se debe tener en cuenta que los tiempos finales
establecidos para esta alarma son los que se han utilizado para realizar las pruebas y,
en ningn caso seran los definitivos si se decidiera utilizar esta aplicacin para uso real.
El servicio BatteryLevelChecker, de tipo IntentService, se encarga de comprobar
si hay alertas de batera en la base de datos ubicada en el servidor. A diferencia de los
servicios utilizados hasta ahora en las aplicaciones desarrolladas, los IntentService se
utilizan para manejar peticiones asncronas bajo demanda y se detienen por si mismos
al acabar de ejecutar su cdigo. Su funcionamiento es simple: si hay alertas de batera
baja, muestra una notificacin en la barra de estado para informar al usuario de la
aplicacin (a la recepcin del centro), como se puede ver en la figura 4.10(a); si no
hay alertas, no hace nada y, en caso de haber una notificacin anterior no comprobada
en la barra de estado, la cancela.
Como interesa que la recepcin del centro sepa en todo momento si los terminales
de los residentes se quedan sin batera, este servicio se ejecuta peridicamente aunque
la aplicacin no est abierta. Por ello, antes de acceder a la base de datos remota, se
comprueba si el terminal est conectado a la red tanto por WiFi como por conexin de
datos.
Al pulsar sobre la notificacin que indica que hay alertas de batera se accede a
94
4.3. D ESARROLLO
DE LAS APLICACIONES
FIGURA 4.10: a) Notificacin de alertas de batera. b) Listado de alertas de batera.
un listado con los nombres y nmeros de usuario de los residentes cuyos terminales
tienen un nivel de batera por debajo del 15% de su capacidad. Este listado, que se
muestra en la figura 4.10(b), no se actualiza de forma automtica, por lo que si se
deja visible esta pantalla por tiempo indefinido, la informacin mostrada puede ser
falsa. Por ello se incluye, en la parte superior de la pantalla, una lnea de texto donde
se indica la fecha y hora de la ltima actualizacin. La actualizacin de los datos se
puede realizar de dos maneras: mediante la opcin Actualizar listado disponible en el
men de esta pantalla o pulsando de nuevo sobre la notificacin de alerta de batera
(en caso de estar presente en la barra de estado).
A este listado tambin se puede acceder mediante la opcin Alertas Batera del
men principal de la aplicacin. Si al acceder o actualizar el listado no hay ninguna
alerta activa, se muestra un dilogo informando de ello al usuario.
4.3.3.2
C OMPROBACIN
DE ALERTAS DE POSICIONAMIENTO
Como se ha explicado anteriormente en este captulo, al producirse una entrada/salida

de la zona permitida por parte de un residente, lo primero que hace la aplicacin del
residente es realizar una llamada a la extensin de emergencia de Asterisk (033, alerta
95
DE LOS
S OFTPHONES
de localizacin). Esta llamada hace que Asterisk ponga en contacto, mediante una
llamada SIP, a estas dos partes: el residente que ha generado la alerta y la recepcin
del centro (es decir, el usuario de esta aplicacin). Al finalizarse la llamada, se muestra
un plano de la zona (alrededor de la residencia) con la ubicacin de los residentes
que se encuentran fuera de la zona permitida. De esta forma, la recepcin del centro
puede saber la localizacin del residente con el que acaba de hablar.
Con este objetivo, se crea la actividad ShowLocationMap, que muestra el plano
con la ubicacin de los residentes en estado de alerta o en seguimiento. La solicitud
de inicio/finalizacin de un seguimiento se realiza tambin desde este plano. El
funcionamiento concreto de esta clase se detallar ms adelante.
Igual que en la aplicacin diseada para los residentes, se han realizado algunas
modificaciones respecto al softphone bsico para adaptarlo a las necesidades de esta
aplicacin. En este caso, se destacan los cambios realizados en el broadcast receiver
CallReceiverSIP y en el servicio ServiceSIP.
Como ya se ha comentado, estas aplicaciones no estn diseadas para manejar
ms de una llamada a la vez. Si se recibe una llamada nueva durante una llamada
en curso, la llamada nueva se cuelga (envindola al buzn de voz) y no consta en el
registro de llamadas. En este caso, si la llamada nueva es una llamada de emergencia,
aunque no se descuelgue, s que aparece en la pantalla del terminal el mapa de la zona
con la localizacin de los residentes que estn en estado de alerta de posicionamiento.
De esta forma, aunque no se pueda poner en contacto al residente que ha generado la
alerta con la recepcin del centro, s se avisa del estado de alerta del mismo.
Para mostrar el mapa de localizacin en este caso, se utiliza el siguiente mtodo
desde el broadcast receiver que maneja las llamadas entrantes:
protected void emergencyCall ( String callerID ) {
if ( callerID . equals ( " Emergency Call " ) ) {
Intent showMapIntent = new Intent ( contexto ,
ShowLocationMap . class ) ;
showMapIntent . setFlags ( Intent . FLAG_ACTIVITY_NEW_TASK ) ;
contexto . startActivity ( showMapIntent ) ;
}
}
Por ltimo, se aade un mtodo nuevo en el servicio ServiceSIP que se utilizar

desde el mapa de localizacin para solicitar el inicio/finalizacin de un seguimiento.
El mtodo initiateFollowUpCall es muy similar al que utiliza la aplicacin para realizar
llamadas SIP pero con algunas modificaciones. En este caso, se realiza una llamada
perdida a la extensin de seguimiento de Asterisk indicada (034 o 035), que se encar-
96
4.3. D ESARROLLO
DE LAS APLICACIONES
gar de notificar al softphone del residente indicado que inicie/detenga el protocolo

de seguimiento (envo de las coordenadas GPS a la base de datos remota). El nmero
de usuario del residente al que se quiere monitorizar se indica a Asterisk al establecer la llamada mediantes tonos DTMF, como se puede ver en el cdigo mostrado a
continuacin. Este tipo de llamada no se hace constar en el registro de llamadas.
public void initiateFollowUpCall ( String sipFUuser , String sipFUext ) {
/* * define la extension del servidor Asterisk a la que se
realizara la llamada */
String extension = sipFUext + " @ " + me . getSipDomain () ;
/* * fuUser = numero de usuario relacionado con el seguimiento */
fuUser = sipFUuser . toCharArray () ;
try {
/* * Listener para eventos relacionados con la llamada de
seguimiento */
SipAudioCall . Listener listenerLost = new
SipAudioCall . Listener () {
/* * se ejecuta al establecer la llamada */
@Override
public void onCallEstablished ( SipAudioCall call ) {
/* * se activa el audio y se desactiva el modo altavoz */
call . startAudio () ;
call . setSpeakerMode ( false ) ;
/* * se envia el numero de usuario al que se desea
hacer el seguimiento */
call . sendDtmf ( Character . getNumericValue ( fuUser [0]) ) ;
}
/* * se ejecuta cuando el otro extremo finaliza la llamada */
@Override
/* * no se hace nada ( no se debe registrar esta llamada ) */
// Noop .
}
};
/* * se realiza la llamada SIP */
call = manager . makeAudioCall ( me . getUriString () , extension ,
listenerLost , 30) ;
}
........
}
4.3.3.2.1 S HOW L OCATION M AP

La actividad ShowLocationMap, de tipo MapActivity, muestra un mapa de los
alrededores de la residencia con la ubicacin de los residentes que se encuentran fuera
de la zona permitida. Tambin permite solicitar la localizacin de un residente que
97
DE LOS
S OFTPHONES
FIGURA 4.11: a) Mapa de alertas con 2 usuarios (mostrando la informacin de uno

de ellos). b) Mapa con 2 usuarios fuera de la zona permitida (rojos) y un usuario en
seguimiento (verde).
est dentro de la zona permitida (seguimiento) siempre y cuando se puedan obtener

sus coordenadas GPS (se est al aire libre). Se utilizan marcadores sobre el mapa de
colores distintos para distinguir entre los dos casos: rojos (residentes en estado de
alerta) y verde (residente en seguimiento). Al pulsar sobre estos marcadores, aparece
en pantalla informacin sobre el residente al que representan: nombre y nmero de
usuario. La informacin mostrada en este mapa se actualiza cada 30 segundos.
En la figura 4.11(a) se puede ver el mapa con dos usuarios en estado de
alerta (fuera de la zona permitida) y la informacin de uno de ellos en pantalla. En la
figura 4.11(b) se muestra, adems, la posicin de un usuario en estado de seguimiento.
Para poder utilizar mapas en una aplicacin de Android, se debe obtener una
clave (Google Maps API key) que permita integrar Google Maps en la aplicacin. Esta
clave se puede conseguir en la pgina http://code.google.com/android/add-ons/
google-apis/mapkey.html de forma gratuita. Una vez obtenida, debe aadirse en la
definicin del layout de la actividad que utiliza el mapa, concretamente como uno de
los parmetros del objeto MapView:
98
4.3. D ESARROLLO
DE LAS APLICACIONES
< com . google . android . maps . MapView

android:id = " @ + id / mapView "
android:layout_width = " fill_parent "
android:layout_height = " wrap_content "
android:enabled = " true "
android:clickable = " true "
android:apiKey = " 0 _ECbuvJC9Z_29i2PIT6CYcSI4TrabnEapFsXiQ "
/>
El acceso a este mapa se puede realizar de dos formas distintas: al colgar una
llamada entrante de emergencia, de forma automtica; o a travs de la opcin Mapa
Alertas del men principal de la aplicacin.
Al lanzar la actividad, antes de poder mostrar el mapa, hay que configurar algunos
aspectos del mismo, as como de los componentes que aparecern en l (marcadores).
Esta definicin se puede ver en el cdigo siguiente:
private void defineMapSettings () {
/* * define el marcador para los usuarios en estado de alerta
( rojos ) */
marker = this . getResources () . getDrawable ( R . drawable . marker ) ;
marker . setBounds (0 , 0 , marker . getIntrinsicWidth () ,
marker . getIntrinsicHeight () ) ;
/* * define el marcador para el usuario en seguimiento ( verde ) */
gmarker = this . getResources () . getDrawable ( R . drawable . marker_green ) ;
gmarker . setBounds (0 , 0 , gmarker . getIntrinsicWidth () ,
gmarker . getIntrinsicHeight () ) ;
/* * crea una referencia al objeto mapa y lo configura en modo
vista de satelite */
mapView = ( MapView ) findViewById ( R . id . mapView ) ;
mapView . setSatellite ( true ) ;
/* * objeto MapController que permite trabajar con el mapa */
mc = mapView . getController () ;
/* * configura el nivel de zoom del mapa */
mc . setZoom (17) ;
/* * elimina todos los posts pendientes que pueda haber en cola */
mHandler . removeCallbacks ( mUpdateTimeTask ) ;
/* * programa el objeto de tipo Runnable ( mUpdateTimeTask ) para que
se ejecute su metodo run () al cabo de 100 ms */
mHandler . postDelayed ( mUpdateTimeTask , 100) ;
}
Primero se definen los marcadores que aparecern sobre el mapa (rojos y verdes). A
continuacin se crea una referencia al mapa mapView y se especifican algunos parmetros de su configuracin inicial: aspecto tipo satlite y nivel de zoom (17). Por ltimo,
utilizando un objeto de tipo Handler, se inicia el proceso de marcar sobre el mapa la
posicin de los residentes que se encuentren en estado de alerta. Los objetos Handler
99
DE LOS
S OFTPHONES
FIGURA 4.12: Dilogo mostrado cuando no hay alertas de posicionamiento en el

mapa.
permiten, entre otras cosas, programar la ejecucin de un objeto Runnable cada cierto
tiempo. En este caso, se utiliza el objeto mUpdateTimeTask, cuyo cdigo se muestra a
continuacin, y que refresca la informacin mostrada en el mapa cada 30 segundos.
private Runnable mUpdateTimeTask = new Runnable () {
public void run () {
/* * actualiza la posicion de los marcadores y refresca el
mapa */
updateMarkersPosition () ;
long startTime = SystemClock . uptimeMillis () ;
/* * programa este objeto para que ejecute su metodo run () al
cabo de 30 s */
mHandler . postAtTime ( this , startTime + 30000) ;
}
};
El mtodo updateMarkersPosition es el encargado de actualizar la posicin de los

marcadores en el mapa y refrescarlo. Para ello, se comprueba la base de datos remota
con el fin de obtener la informacin relativa a los residentes que se encuentran fuera de
la zona permitida y se muestra en el mapa su ltima localizacin disponible (ltimas
coordenadas introducidas en la tabla MyCoordinates para cada residente). En caso de
no existir ningn usuario en estado de alerta, se muestra un dilogo informando al
100
4.3. D ESARROLLO
DE LAS APLICACIONES
usuario de la aplicacin de este hecho y dndole la opcin de solicitar un seguimiento

(figura 4.12). Adems, si hay algn residente en seguimiento, se muestra tambin su
ltima localizacin disponible.
private void updateMarkersPosition () {
/* * crea un punto geografico con la ubicacion de la residencia */
p = getPoint ( ConstB . res_latitude , ConstB . res_longitude ) ;
/* * centra el mapa en el punto definido antes */
mc . animateTo ( p ) ;
/* * obtiene una lista con los datos de los usuarios en estado de
alerta y sus coordenadas mas recientes */
List < String [] > alert_points = dbR . getAlertCoordinates () ;
/* * si no hay ningun usuario en estado de alerta , muestra un
dialogo para informar de ello */
if ( alert_points . size () == 0 & ! conSeguimiento ) {
showDialog (0) ;
}
else {
/* * borra todos los marcadores que hubiera en el mapa */
mapView . getOverlays () . clear () ;
/* * si hay usuarios en estado de alerta , anade los marcadores
correspondientes utilizando el objeto MapOverlay y
definiendo el tipo de marcador y los datos que se usaran */
if ( alert_points . size () != 0) {
mapView . getOverlays () . add ( new MapOverlay ( marker ,
alert_points ) ) ;
}
/* * si hay algun usuario en seguimiento , obtiene las ultimas
coordenadas introducidas en la DB remota y anade el
marcador correspondiente en el mapa mediante el objeto
MapOverlay , definiendo el tipo de marcador y los datos que
se usaran */
if ( conSeguimiento ) {
String [] person = dbR . getUserCoordinates ( usuario ) ;
if ( person [0] == null ) {
/* * si el usuario no tiene ninguna coordenada en la DB
remota al solicitar el seguimiento , se muestra un
mensaje de espera hasta que se vuelva a refrescar
la informacion */
Toast . makeText ( getBaseContext () , " Esperando
coordenadas ... " , Toast . LENGTH_SHORT ) . show () ;
} else {
mapView . getOverlays () . add ( new MapOverlay ( gmarker ,
person ) ) ;
}
}
/* * fuerza el mapa a redibujarse */
mapView . invalidate () ;
}
}
101
DE LOS
S OFTPHONES
Para poder dibujar elementos encima del mapa (como los marcadores) se debe utilizar un objeto de tipo Overlay. Para esta aplicacin, se ha creado una clase propia
(MapOverlay) que extiende a una clase de tipo lista de Overlays, modificando su comportamiento. Se crean dos constructores distintos (uno para cada tipo de marcador)
que, a partir de la informacin obtenida de la base de datos, crearn los objetos de
tipo Overlay que se dibujarn encima del mapa. Tambin se incluyen varios mtodos
que permiten, entre otras cosas, dibujar los marcadores (draw) y especificar el comportamiento de stos al pulsar sobre ellos (onTap).
private class MapOverlay extends ItemizedOverlay < OverlayItem > {
/* * lista donde se guardan todos los objetos OverlayItem
( marcadores ) que se dibujaran sobre el mapa */
private List < OverlayItem > items = new ArrayList < OverlayItem >() ;
private Drawable marker = null ;
/* * constructor de la clase para marcadores de alertas de
proximidad
* marker = marcador rojo
* list = lista con los datos de los usuarios en situacion de
alerta */
public MapOverlay ( Drawable marker , List < String [] > list ) {
super ( marker ) ;
this . marker = marker ;
/* * recorre la lista de usuarios en estado de alerta ( list ) y
crea un objeto de tipo OverlayItem para cada usuario . Anade
todos los objetos a la lista item */
for ( int i =0; i < list . size () ; i ++) {
String [] p = list . get ( i ) ;
items . add ( new
OverlayItem ( getPoint ( Double . parseDouble ( p [0]) ,
Double . parseDouble ( p [1]) ) , p [2] , p [3]) ) ;
}
/* * crea los objetos que hay en la lista item ( mediante el
metodo createItem () ) y los dibuja en el mapa ( mediante el
metodo draw () )
* se debe llamar en cuanto se tengan objetos en la lista */
populate () ;
}
/* * constructor de la clase para el marcador de seguimiento
* marker = marcador verde
* p = datos del usuario que este en seguimiento */
public MapOverlay ( Drawable marker , String [] p ) {
super ( marker ) ;
this . marker = marker ;
/* * crea un objeto de tipo OverlayItem con los datos del
usuario en seguimiento . Anade el objeto a la lista item */
102
4.3. D ESARROLLO
DE LAS APLICACIONES
items . add ( new OverlayItem ( getPoint ( Double . parseDouble ( p [0]) ,

Double . parseDouble ( p [1]) ) , p [2] , p [3]) ) ;
/* * crea los objetos que hay en la lista item ( mediante el
metodo createItem () ) y los dibuja en el mapa ( mediante el
metodo draw () )
* se debe llamar en cuanto se tengan objetos en la lista */
populate () ;
/* * crea los objetos que hay en la lista item . Se llama desde el

metodo populate () */
@Override
protected OverlayItem createItem ( int i ) {
return ( items . get ( i ) ) ;
}
/* * dibuja un marcador para cada objeto de la lista */
@Override
public void draw ( Canvas canvas , MapView mapView , boolean shadow ) {
super . draw ( canvas , mapView , shadow ) ;
/* * centra el marcador para que apunte exactamente a la
coordenada correspondiente */
boundCenterBottom ( marker ) ;
}
/* * Devuelve el numero de objetos que hay que dibujar */
@Override
public int size () {
return ( items . size () ) ;
}
/* * Define el comportamiento al pulsar sobre un marcador en el

mapa . Identifica el marcador pulsado y muestra el numero y el
nombre de usuario al que representa */
@Override
protected boolean onTap ( int i ) {
OverlayItem item = getItem ( i ) ;
String str = item . getTitle () + " \ n \ t " + item . getSnippet () ;
Toast . makeText ( getBaseContext () , str ,
Toast . LENGTH_SHORT ) . show () ;
return ( true ) ;
}
Como se ha indicado antes, desde este mapa, el usuario de la aplicacin puede

iniciar/finalizar el seguimiento de la posicin de un residente que no se encuentre
en situacin de alerta (dentro de la zona permitida). Para ello, como se ve en la
figura 4.13(a), se incluyen las opciones Iniciar Seguimiento y Finalizar Seguimiento en
103
DE LOS
S OFTPHONES
FIGURA 4.13: a) Men del mapa de alertas. b) Dilogo para iniciar un seguimiento.
el men de esta pantalla.

Al seleccionar Iniciar Seguimiento, aparece en pantalla el dilogo de la
figura 4.13(b) solicitando el nmero de usuario del residente al que se quiere localizar.
Al introducir el nmero deseado, se realiza de forma automtica una llamada a la extensin de inicio de seguimiento de Asterisk (034) para avisar al softphone de dicho
residente que se ha pedido un seguimiento y que por tanto debe empezar a enviar sus
coordenadas GPS a la base de datos remota. Por ltimo, se fuerza una actualizacin de
la informacin del mapa.
private void startSeguimiento () {
conSeguimiento = true ;
/* * realiza una llamada a la extension de inicio de seguimiento */
sb . getBinder () . initiateFollowUpCall ( usuario , " 034 " ) ;
/* * actualiza la posicion de los marcadores en el mapa */
}
Si se selecciona Finalizar Seguimiento, se realiza de forma automtica una llamada

a la extensin de finalizacin de seguimiento de Asterisk (035) para avisar al softphone
del residente que ya puede dejar de enviar sus coordenadas a la base de datos remota.
104
4.3. D ESARROLLO
DE LAS APLICACIONES
Por ltimo, como en el caso anterior, se fuerza una actualizacin del mapa.
private void stopSeguimiento () {
if ( conSeguimiento ) {
conSeguimiento = false ;
/* * realiza una llamada a la extension de fin de seguimiento */
sb . getBinder () . initiateFollowUpCall ( usuario , " 035 " ) ;
/* * actualiza la posicion de los marcadores en el mapa */
}
}
Como se ha comentado previamente, la informacin mostrada sobre el mapa se

actualiza de forma automtica cada 30 segundos. De todos modos, si se desea forzar
una actualizacin en un momento concreto, se puede hacer desde la opcin Actualizar
disponible en el men de esta pantalla.
105
106
DE LOS
S OFTPHONES
5
Conclusiones y lneas de futuro
y despus de revisar los objetivos planteados en la introduccin de esta memoria, podemos decir que se han cumplido los objetivos definidos
para este proyecto.
LEGADOS A ESTE PUNTO
Hay que recalcar que, aunque este proyecto est enfocado como un caso real
(implementacin de una plataforma VoIP en una residencia de ancianos), no est
realmente desarrollado para su utilizacin inmediata, sera ms bien como una prueba
piloto.
Se ha realizado todo el trabajo posible con los recursos disponibles (que a veces
resultaron limitadores) tanto a la hora de desarrollar el proyecto como de realizar las
pruebas correspondientes. A continuacin se comentan los principales problemas y
factores que habra que mejorar en revisiones futuras:
* Para este proyecto se busc una forma de integrar la VoIP en una aplicacin
Android, utilizando el protocolo SIP, que es el ms extendido entre los usuarios
de VoIP. Al final se decidi utilizar la API SIP nativa que proporciona el propio
Android. De todas formas, esta API est muy limitada y, aunque fue suficiente
para la realizacin de este proyecto, se ha descubierto que no es la ms apropiada para ello.
Aunque la API SIP va incluida en todas las versiones de Android a partir de la 2.3,
se ha descubierto que algunas marcas de smartphones tienen capada esta API
para congraciarse con las operadoras de telefona mvil. En este caso, se tuvieron
que rootear los dos terminales de pruebas para poder desbloquear su utilizacin.
Adems, esta API no soporta la utilizacin conjunta con servidores STUN, con lo
que no se han podido solucionar los problemas de NAT (inherentes a SIP) que
ya se comentaron en el captulo 2. Tambin se descubri que, aunque no se
especificaba de ninguna manera en la documentacin de la API, su utilizacin
107
CAPTULO 5. C ONCLUSIONES
Y LNEAS DE FUTURO
con conexin de datos no es automtica: hay que modificar archivos internos del
smartphone a los que, en principio, un usuario normal no debera tener acceso.
Por estos motivos, si se deseara utilizar los softphones desarrollados en un entorno
prctico, habra que buscar otra API SIP externa e integrarla en las aplicaciones.
* El softphone de recepcin consulta la base de datos cada cierto tiempo para ver
si hay alertas de batera activadas, mtodo que resulta ineficiente. La decisin de
controlar el nivel de batera de los dispositivos de los residentes se tom una vez
finalizada la programacin de las aplicaciones, por lo que se busc una solucin
rpida que permitiera obtener los resultados requeridos, pero sin tener que estudiar opciones fuera del conocimiento que se tena en aquel momento. Se debera
buscar una alternativa para evitar que la aplicacin realice accesos y comprobaciones innecesarias a la base de datos, mejorando as la autonoma del dispositivo.
* Aadir securizacin en Asterisk utilizando el protocolo de seguridad SRTP
(Secure Real-time Transport Protocol). Debido a la evolucin que sufri el
proyecto, esta funcionalidad qued en un segundo plano y queda entonces para
revisiones futuras.
* Durante el desarrollo de la centralita de telefona aparecieron dos problemas para
los cuales, a la fecha de entrega, no se ha encontrado solucin. El tratamiento de
estas cuestiones queda, por tanto, pendiente para resolver en futuras revisiones.
1. Deteccin de colgado: Asterisk no es capaz de detectar cuando una llamada
entrante a la PBX cuelga. Si la finalizacin de la llamada proviene del exterior, Asterisk no lo detecta y sigue haciendo la rutina marcada hasta que
llega a un Hangup() (Asterisk cuelga y libera la lnea). Si no se llega a un
Hangup(), la lnea queda bloqueada y para desbloquearla hay que reiniciar
el servicio Asterisk. Se proporciona una solucin provisional al problema
haciendo que se libere la lnea en casos de bloqueo mediante timeouts.
2. Identificador de llamada: Asterisk no obtiene el CallerID de las llamadas que
llegan a la PBX. Esto puede ser debido a varios motivos, entre los que se
destacan: que la red Ibercom no ofrece este servicio; o existe algn elemento
intermedio que elimina el CallerID. Por este motivo, no se ha utilizado esta
funcionalidad en la PBX.
* El entorno de pruebas de este proyecto sera un aspecto a mejorar. Las aplicaciones deben estar conectadas a la red en todo momento. Esto supone un problema ya que el campus universitario no dispone de una red wifi uniforme en
toda su extensin (hay zonas sin cobertura fuera de los edificios). Lo ideal hubiera sido disponer de smartphones con conexin de datos para poder realizar
algunas de las pruebas, pero diversos factores (como la eleccin de la API SIP) no
lo permitieron.
108
5.1. VALORACIN
5.1
PERSONAL
VALORACIN
PERSONAL
debo decir que he aprendido mucho con este proyecto, ya que

todas las tecnologas que se han tratado en l (Android, Asterisk, bases de datos
MySQL, etc.) eran totalmente nuevas para mi.
NIVEL PERSONAL ,
La mayor parte del trabajo que se ve en este proyecto es fruto del auto aprendizaje,
ya sea mediante la consulta y lectura de libros, como la lectura de infinitas pginas
web, foros de grupos y comunidades especializadas en cada una de dichas tecnologas.
Esto es algo que valoro mucho, ya que es una situacin habitual en el mundo laboral.
Desde que empec a trabajar en este proyecto me he dado cuenta de que el
desarrollo de aplicaciones Android es algo que me interesa bastante y en lo que me
gustara trabajar en un futuro.
En conclusin, considero que este proyecto ha resultado ser una experiencia muy
positiva (aunque algo dura) de cara a mi futuro laboral y me ha permitido aprender y
aplicar nuevas tecnologas que me pueden resultar muy tiles para esta nueva etapa de
mi vida.
109
CAPTULO 5. C ONCLUSIONES
110
Y LNEAS DE FUTURO
6
Bibliografa
Publicaciones:
* Madsen, Leif; Van Meggelen, Jim; Bryant, Russell. Asterisk: The Definitive Guide
(3rd Edition). OReilly, 2011.
* Digium 800 Series User Manual. Digium, 2009.
* Lee, Wei-Meng. Beginning Android Application Development. Wiley Publishing,
2011.
* Murphy, Mark L. The Busy Coders Guide to Advanced Android Development.
CommonsWare, 2010.
* Kelly, Timothy. VoIP for Dummies. Wiley Publishing, 2005.
* International Development Research Centre.
Escudero-Pascual, Alberto;
Berthilson, Louise. VoIP para el desarrollo [en lnea]. 2006.
* Margarit, Gens. Administracin de sistemas Asterisk [apuntes cursillo]. 2011.
Enlaces de inters:
* www.voip-info.org
Gua de referencia para todo lo relacionado con VoIP.
Wiki con documentacin sobre Asterisk: consultada para la configuracin de los
mdulos de Asterisk y las funciones y aplicaciones utilizadas en el dialplan.
* www.asterisk.org
Pgina oficial de Asterisk. Contiene documentacin de Asterisk y Dahdi.
111
CAPTULO 6. B IBLIOGRAFA
* http://stackoverflow.com
Foro para programadores tanto profesionales como amateurs.
Utilizado para resolver problemas relacionados con la programacin de las aplicaciones Android.
* http://developer.android.com/index.html
Pgina web oficial para desarrolladores de aplicaciones Android.
documentacin, guas de referencia, ejemplos de cdigo, etc.
112
Contiene
A
Instalaciones y configuraciones relacionadas con
Asterisk
A.1
A.1.1
Instalaciones relacionadas con Asterisk

P RERREQUISITOS
Antes de empezar, hay que verificar que se tienen instaladas en el servidor todas las
dependencias que los paquetes bsicos necesitan. Para no tener que hacerlo manualmente (uno a uno), el paquete Asterisk contiene un script que se encarga de instalar
todas las dependencias y prerrequisitos necesarios. Para ejecutar el script, escribimos
las siguientes lneas en un terminal:
> cd / usr / src / asterisk -10.0.0/ contrib / scripts /
> ./ install_prereq install
A.1.2
DAHDI
Con el paquete descargado y descomprimido, compilamos e instalamos DAHDI escribiendo los siguientes comandos en un terminal:
>
>
>
>
cd / usr / src / dahdi - linux - complete -2.5.0.2+2.5.0.2

make all
make install
make config
Para poder integrar el cancelador de eco Oslec con DAHDI se deben hacer algunos
cambios en este paquete. Es por eso que, una vez instalado, deber recompilarse.
113
CAPTULO A. I NSTALACIONES
A.1.3
Y CONFIGURACIONES RELACIONADAS CON
A STERISK
LIB PRI
La compilacin e instalacin de la librera libPRI es bastante similar al proceso seguido

para DAHDI. Con el paquete descargado y descomprimido, se escriben las siguientes
lneas en un terminal:
> cd / usr / src / libpri -1.4.12
> make
> make install
A.1.4
A STERISK
La compilacin e instalacin de Asterisk es un poco ms compleja que las anteriores,

ya que aadiremos algunos elementos extras a su instalacin bsica (por defecto).
Primero se instala la compatibilidad mp3 para que Asterisk pueda manejar archivos
con este formato. Como en el caso de los prerrequisitos, el paquete Asterisk incluye un
script con este fin. Para ejecutarlo, se escriben las siguientes lneas en un terminal:
> cd / usr / src / asterisk -10.0.0
> ./ contrib / scripts / get_mp3_source . sh
> ./ contrib / scripts / get_mp3_source . sh install
A continuacin, ya se puede empezar con la instalacin de Asterisk. Se ejecutan los

primeros comandos en un terminal:
> cd / usr / src / asterisk -10.0.0
> ./ configure
> make menuselect
Con el ltimo comando aparece un men con interfaz grfica que permite especificar los mdulos de Asterisk que se quieren incluir en la instalacin. Los mdulos de
la instalacin por defecto ya aparecen marcados. Adems de estos, se seleccionan unas
aplicaciones del dialplan que estaban incluidas por defecto en versiones anteriores y los
paquetes de sonidos (en ingls y castellano) y de msica en espera en varios formatos.
Applications
[*] app_meetme
[*] app_readfile
[*] app_setcallerid
Core Sounds Packages
[*] CORE - SOUNDS - EN - WAV
[*] CORE - SOUNDS - EN - ULAW
[*] CORE - SOUNDS - EN - ALAW
[*] CORE - SOUNDS - EN - GSM
114
A.1. I NSTALACIONES
RELACIONADAS CON
A STERISK
[*] CORE - SOUNDS - EN - G729

[*] CORE - SOUNDS - EN - G722
[*]
[*]
[*]
[*]
[*]
[*]
CORE - SOUNDS - ES - WAV

CORE - SOUNDS - ES - ULAW
CORE - SOUNDS - ES - ALAW
CORE - SOUNDS - ES - GSM
CORE - SOUNDS - ES - G729
CORE - SOUNDS - ES - G722
[*]
[*]
[*]
[*]
[*]
[*]
CORE - SOUNDS - EN_AU - WAV

CORE - SOUNDS - EN_AU - ULAW
CORE - SOUNDS - EN_AU - ALAW
CORE - SOUNDS - EN_AU - GSM
CORE - SOUNDS - EN_AU - G729
CORE - SOUNDS - EN_AU - G722
Music On Hold File Packages :

[*] MOH - OPSOUND - WAV
[*] MOH - OPSOUND - ULAW
[*] MOH - OPSOUND - ALAW
[*] MOH - OPSOUND - GSM
[*] MOH - OPSOUND - G729
[*] MOH - OPSOUND - G722
Extra Sound Packages :
[*] EXTRA - SOUNDS - EN - WAV
[*] EXTRA - SOUNDS - EN - ULAW
[*] EXTRA - SOUNDS - EN - ALAW
[*] EXTRA - SOUNDS - EN - GSM
[*] EXTRA - SOUNDS - EN - G729
[*] EXTRA - SOUNDS - EN - G722
Una vez marcados los paquetes, se salva la seleccin y se vuelve al terminal

pulsando el botn Save and Exit.
Con todos los mdulos especificados, ya se puede continuar con la compilacin e
instalacin de Asterisk. Para ello, se escriben las siguientes lneas en el terminal:
>
>
>
>
make
make install
make config
make samples
Por ltimo, se ejecuta el siguiente comando, que comprime los archivos tipo log que
genera Asterisk, ahorrando espacio en disco:
> make install - logrotate
115
A.1.5
A STERISK
C ANCELADOR DE ECO O SLEC
Los archivos necesarios para descargar e instalar Oslec no se encuentran en un paquete

propio, sino que estn incluidos en el kernel de Linux. Por tanto, se descarga el Linux
Kernel source de la versin que hay instalada en el servidor y se descomprime. Para este
proyecto, la versin adecuada es la 2.6.32.
> cd / usr / src
> wget http :// kernel . org / pub / linux / kernel / v2 .6/ linux -2.6.32. tar . bz2
> tar xjf linux -2.6.32. tar . bz2
A continuacin, se crean dentro del paquete DAHDI los directorios donde se debern
ubicar los archivos obtenidos del kernel y se copian los archivos relativos a Oslec en
estos directorios.
> mkdir dahdi - linux - complete -2.5.0.2+2.5.0.2/ linux / drivers / staging
> mkdir
dahdi - linux - complete -2.5.0.2+2.5.0.2/ linux / drivers / staging / echo
> cp linux -2.6.32/ drivers / staging / echo /*
dahdi - linux - complete -2.5.0.2+2.5.0.2/ linux / drivers / staging / echo /
Para utilizar Oslec, hay que descomentar y modificar las dos lneas relativas al cancelador en el archivo Kbuild del paquete DAHDI.
> vi dahdi - linux - complete -2.5.0.2+2.5.0.2/ linux / drivers / dahdi / Kbuild
# descomentar y modificar estas lineas
obj - m += dahdi_echocan_oslec . o
obj - m += ../ staging / echo / echo . o
Para aplicar los cambios, se vuelve a compilar e instalar el paquete DAHDI como
se especifica en el apartado anterior. Verificamos que se han ejecutado los cambios
mirando el resultado de la compilacin. Si aparecen las siguientes lneas, Oslec est
instalado e integrado con DAHDI y slo hay que configurarlo.
CC [ M ]
/ usr / src / dahdi - linux - complete -2.5.0.2+2.5.0.2/ linux / drivers / dahdi /
dahdi_echocan_oslec . o
CC [ M ]
/ usr / src / dahdi - linux - complete -2.5.0.2+2.5.0.2/ linux / drivers / dahdi /
../ staging / echo / echo . o
A.1.6
R ECONOCIMIENTO DE VOZ
Los paquetes necesarios para instalar las libreras Pocketsphinx (librera de reconocimiento) y Sphinxbase (librera de soporte) se pueden descargar desde la pgina
116
A.2. A RCHIVOS
DE CONFIGURACIN
A STERISK
del proyecto: http://cmusphinx.sourceforge.net/. Como se ha hecho con los otros

paquetes, se descargan, se ubican en el directorio /usr/src y se descomprimen.
Primero se instala la librera de soporte Sphinxbase en el servidor mediante los
siguientes comandos en un terminal:
>
>
>
>
cd / usr / src / sphinxbase -0.7

./ autogen . sh
make
make install
Para asegurar que el sistema es capaz de cargar las libreras correctamente, se configura el path para que sepa dnde buscar las libreras compartidas.
> export LD_LIBRARY_PATH =/ usr / local / lib
> export PKG_CONFIG_PATH =/ usr / local / lib / pkgconfig
A continuacin se instala la librera Pocketsphinx, utilizando el mismo procedimiento:

>
>
>
>
cd / usr / src / pocketsphinx -0.7

./ autogen . sh
make
make install
Para comprobar que la instalacin de ambas libreras se ha realizado correctamente

se deben obtener las siguientes lneas al ejecutar este comando:
> pkg - config -- cflags -- libs pocketsphinx sphinxbase
-I / usr / local / include -I / usr / local / include / sphinxbase
-I / usr / local / include / pocketsphinx
-L / usr / local / lib - lpocketsphinx - lsphinxbase - lsphinxad
A.2
A.2.1
Archivos de configuracin Asterisk

C ANALES DAHDI
Se aaden las siguientes lneas al final del archivo /etc/asterisk/chan_dahdi.conf:

; General options
usecallerid = yes
hidecallerid = no
callwaiting = yes
usecallingpres = yes
callwaitingcallerid = yes
threewaycalling = yes
117
A STERISK
transfer = yes
canpark = yes
callreturn = yes
cancallforward = yes
echocancel = yes
echocancelwhenbridged = yes
echotraining = no
rxgain = 10.0
txgain = 5.0
cid_rxgain = 8.0
hanguponpolarityswitch = yes
tonezone =6
ringtimeout =8000
immediate = yes
busydetect = yes
busycount =6
usedistinctiveringdetection = yes
; FXO Modules
group =1
callgroup =1
pickupgroup =1
signalling = fxs_ks
callerid = asreceived
context = from - pstn
channel = > 1 -8
A.2.2
U SUARIOS
Se aaden las siguientes lneas al final del archivo /etc/asterisk/sip.conf:

; residentes
[200]
type = friend
secret =12345
host = dynamic
qualify = yes
canreinvite = no
context = PermisosResidentes
disallow = all
allow = ulaw
allow = alaw
[201](200)
[202](200)
; trabajadores residencia
118
A.2. A RCHIVOS
DE CONFIGURACIN
A STERISK
[501]
; recepcion
type = friend
secret =12345
host = dynamic
qualify = yes
canreinvite = no
context = PermisosTrabajadores
disallow = all
allow = ulaw
allow = alaw
[502](501)
; trabajadora social
[503](501)
; gerocultora 1
[504](501)
; gerocultora 2
[505](501)
; gerocultora 3
[506](501)
; despacho directora
[507](501)
; movil directora
[508](501)
; casa directora
[509](501)
; psicologa
[500](501)
; jefa enfermeras
A.2.3
D IALPLAN
Se aaden las siguientes lneas al final del archivo /etc/asterisk/extensions.conf:

[ usuarios ]
; para llamadas entre usuarios internos
exten = > _X0X ,1 , macro ( UnaExten )
; codigo para las llamadas de emergencia
same = > 2 , SayDigits ( $ { EXTEN })
same = > n , Goto (1)
; para entrar en la conferencia de la centralita Dahdi (101)
exten = > 101 ,1 , Answer ()
same = > n , MeetMe (101 , pM )
same = > n , Hangup ()
[ PermisosResidentes ]
include = > usuarios
include = > Buzon_de_voz
include = > android_VA
[ PermisosTrabajadores ]
include = > usuarios
include = > Buzon_de_voz
include = > grabadora
include = > android_VA
119
A STERISK
include = > PC_a_RTC

include = > parkedcalls
; desvio de llamadas activo de llamante a 50 X
exten = > _ *21*50 X ,1 , Answer ()
same = > n , Set ( DB ( CFIM / $ { CALLERID ( num ) }) = $ { EXTEN : -3})
; desvio de llamadas de extension 50 X desactivado
exten = > _ # 21#50 X ,1 , Answer ()
same = > n , Verbose ( Cancelado desvio extension $ { EXTEN : -3} a
$ { DB_DELETE ( CFIM / $ { EXTEN : -3}) })
; sala de conferencias interna limite 3 personas
exten = > 600 ,1 , Answer ()
same = > 2 , MeetMeCount (600 , count )
same = > 3 , NoOp ( $ { count })
same = > 4 , GotoIf ( $ [ $ { count } >= 3]?7)
same = > 5 , Authenticate (5678)
same = > 6 , MeetMe (600 , pM )
same = > 7 , PlayBack ( conf - kicked )
same = > 8 , Hangup ()
; pruebas centralita
exten = > 00 ,1 , Goto ( from - pstn ,s ,1)
[ android_VA ]
exten = > 033 ,1 , Answer ()
same = > n , PlayBack ( beep )
; Origina una llamada entre SIP /501 ( recepcion ) y CALLERID ( num )
llama a SIP /501 y luego ejecuta la instruccion de la extension
CALLERID ( num ) , prioridad 2
same = > n , Originate ( SIP /501 , exten , usuarios , $ { CALLERID ( num ) } ,2)
exten = > 034 ,1 , Answer ()
same = > n , Read ( num , ,3)
same = > n , Set ( CALLERID ( num ) =034)
same = > n , Dial ( SIP / $ { num } ,10)
exten = > 035 ,1 , Answer ()
120
A.2. A RCHIVOS
DE CONFIGURACIN
A STERISK
[ macro - UnaExten ]
; si no te cogen el telefono salta al buzon de voz
; comprueba primero si el numero esta en la blacklist
; comprueba si hay desvio de llamadas
; con parking de llamadas ( t / T en Dial para poder transferir )
; con grabacion de la llamada si es para 200 ( monitorizacion ) ( pruebas )
exten = > s ,2 , Set ( exten = $ { DB ( CFIM / $ { MACRO_EXTEN }) })
exten = > s ,3 , GotoIf ( $ [ " $ { exten } " = " " ]?4:5)
exten = > s ,4 , Set ( exten = $ { MACRO_EXTEN })
exten = > s ,5 , GotoIf ( $ { BLACKLIST () }? bl )
exten = > s ,6 , GotoIf ( $ [ $ { exten }=200]?:9)
exten = > s ,7 , Set ( CALLFILENAME = $ { MACRO_EXTEN } a $ { CALLERID ( num ) } $ { STRFTIME ( $ { EPOCH } , GMT -2 ,% e % b % R ) })
exten = > s ,8 , Monitor ( wav , $ { CALLFILENAME } , m )
exten = > s ,9 , Dial ( SIP / $ { exten } ,30 , t / T )
exten = > s ,n , NoOp ( $ { DIALSTATUS })
exten = > s ,n , PlayBack ( vm - nobodyavail )
exten = > s ,n , VoiceMail ( $ { exten })
exten = > s ,n , Hangup ()
exten = > s , n ( bl ) , PlayBack ( tt - somethingwrong )
exten = > s ,n , Hangup ()
[ Buzon_de_voz ]
; Consulta el buzon de voz
exten = > 99 ,1 , VoiceMailMain ()
[ grabadora ]
; para grabar las locuciones de voz de la centralita
exten = > 111 ,1 , PlayBack ( beep )
; same = > n , Record ( custom / asr_oficina_cerrada . wav )
; same = > n , Record ( custom / asr_bienvenida . wav )
; same = > n , Record ( custom / asr_extension_voz . wav )
; same = > n , Record ( custom / asr_menu . wav )
; same = > n , Record ( custom / asr_extension . wav )
; same = > n , Record ( custom / asr_max_intentos . wav )
; same = > n , Record ( custom / asr_recepcion . wav )
; same = > n , Record ( custom / asr_trabajador_social . wav )
; same = > n , Record ( custom / asr_enfermeria . wav )
; same = > n , Record ( custom / asr_no_disponible . wav )
; same = > n , Record ( custom / asr_cola . wav )
; same = > n , Record ( custom / asr_max_t_cola . wav )
; same = > n , Record ( custom / asr_directora . wav )
; same = > n , Record ( custom / asr_psicologa . wav )
; same = > n , Record ( custom / asr_desvio . wav )
; same = > n , Record ( custom / asr_exterior . wav )
; same = > n , Record ( custom / asr_despedida . wav )
121
A STERISK
; same = > n , Record ( custom / asr_opcion_incorrecta . wav )

; same = > n , Record ( custom / asr_bienvenida_privado . wav )
; same = > n , Record ( custom / asr_menu_privado . wav )
; same = > n , Record ( custom / asr_error_privado . wav )
; same = > n , Record ( custom / asr_conferencia . wav )
; same = > n , Record ( custom / asr_escucha . wav )
; para escuchar las locuciones de voz de la centralita
exten = > 112 ,1 , PlayBack (/ tmp / ivr )
; same = > n , PlayBack ( custom / asr_oficina_cerrada )
; same = > n , PlayBack ( custom / asr_bienvenida )
; same = > n , PlayBack ( custom / asr_extension_voz )
; same = > n , PlayBack ( custom / asr_menu )
; same = > n , PlayBack ( custom / asr_extension )
; same = > n , PlayBack ( custom / asr_max_intentos )
; same = > n , PlayBack ( custom / asr_recepcion )
; same = > n , PlayBack ( custom / asr_trabajador_social )
; same = > n , PlayBack ( custom / asr_enfermeria )
; same = > n , PlayBack ( custom / asr_no_disponible )
; same = > n , PlayBack ( custom / asr_cola )
; same = > n , PlayBack ( custom / asr_max_t_cola )
; same = > n , PlayBack ( custom / asr_directora )
; same = > n , PlayBack ( custom / asr_psicologa )
; same = > n , PlayBack ( custom / asr_desvio )
; same = > n , PlayBack ( custom / asr_exterior )
; same = > n , PlayBack ( custom / asr_despedida )
; same = > n , PlayBack ( custom / asr_opcion_incorrecta )
; same = > n , PlayBack ( custom / bienvenida_privado )
; same = > n , PlayBack ( custom / asr_menu_privado )
; same = > n , PlayBack ( custom / asr_error_privado )
; same = > n , PlayBack ( custom / asr_conferencia )
; same = > n , PlayBack ( custom / asr_escucha )
[ PC_a_RTC ]
; llama desde PC a un telf exterior
exten = > _00 . ,1 , Dial ( DAHDI / g1 / $ { EXTEN :2} ,10)
exten = > _00 . ,n , Hangup ()
[ from - pstn ]
; ---- ---- ---- --- ---- ---- ---- --- ---- ---- ---- ---- --- ---- ---- ---- --- ---; CENTRALITA DAHDI ( con ASR en ingles )
; ---- ---- ---- --- ---- ---- ---- --- ---- ---- ---- ---- --- ---- ---- ---- --- ---exten = > s ,1 , Answer ()
same = > n , GotoIfTime (8:00 -20:00 , mon - fri ,* ,*? centralita_ASR ,s ,1)
122
A.2. A RCHIVOS
DE CONFIGURACIN
A STERISK
same = > n , PlayBack ( custom / asr_oficina_cerrada )

same = > n , VoiceMail (501) ; recepcion
[ centralita_ASR ]
same = > 2 , Background ( custom / asr_bienvenida )
same = > 3 , Set ( k =1)
same = > 4 , While ( $ [ $ { k } <3])
same = > n , Background ( custom / asr_extension_voz )
same = > n , Background ( custom / asr_menu )
same = > n , Record ( custom / recon / voz . wav , ,5)
same = > n , System (/ var / lib / asterisk / sounds / custom / recon / asr2 . sh )
same = >
n , Set ( num = $ { FILE (/ var / lib / asterisk / sounds / custom / recon / num . txt ,0 ,1) })
same = > n , NoOp ( num = $ { num })
same = > n , GotoIf ( $ [ " $ { num } " = " " ]? null )
same = > n , GotoIf ( $ [ $ { num } <0 | $ { num } >6]?: ok )
same = > n , Set ( num = i )
same = > n ( ok ) , Goto ( $ { num } ,1)
same = > n ( null ) , Set ( k = $ [ $ { k }+1])
same = > n , EndWhile
same = > n , Background ( custom / asr_extension & beep )
same = > n , WaitExten (15 , m ( radio ) )
same = > n ( max ) , PlayBack ( custom / asr_max_intentos )
same = > n , Goto (0 ,1)
; extension Recepcion
exten = > 0 ,1 , PlayBack ( custom / asr_recepcion )
same = > n , Dial ( SIP /501 ,15 , m ( radio ) t )
same = > n , Goto ( # ,1)
; extension Trabajadora Social
exten = > 1 ,1 , PlayBack ( custom / asr_trabajador_social )
same = > n , Dial ( SIP /502 ,10 , m ( radio ) )
same = > n , NoOp ( $ { DIALSTATUS })
same = > n , GotoIf ( $ [ $ { DIALSTATUS }= BUSY ]? busy )
same = > n , Voicemail (502 , u )
same = > n , Goto ( # ,1)
same = > n ( busy ) , PlayBack ( tt - weasels )
same = > n , Goto ( # ,1)
; extension Enfermeria
exten = > 2 ,1 , PlayBack ( custom / asr_enfermeria )
same = > n , Dial ( SIP /500 ,10 , m ( radio ) )
same = > n , GotoIf ( $ [ $ { DIALSTATUS }= BUSY ]? busy )
same = > n , PlayBack ( custom / asr_no_disponible )
same = > n , Goto ( # ,1)
123
same
same
same
same
=>
=>
=>
=>
A STERISK
n ( busy ) , PlayBack ( queue - callswaiting )

n , Queue ( cola_enfermeria , , , ,60)
n , PlayBack ( custom / asr_max_t_cola )
n , Goto ( # ,1)
; extension Directora
exten = > 3 ,1 , PlayBack ( custom / asr_directora )
same = > 2 , Dial ( SIP /506 ,10 , m ( radio ) )
same = > 3 , GotoIf ( $ [ $ { DIALSTATUS }= NOANSWER ]?:5)
same = > 4 , FollowMe ( directora , san )
same = > 5 , Voicemail (506)
same = > 6 , Goto ( # ,1)
; extension Psicologa
; de momento 509 esta redirigido a 501
exten = > 4 ,1 , PlayBack ( custom / asr_psicologa )
same = > 2 , Set ( num = $ { DB ( CFIM /509) })
same = > 3 , GotoIf ( $ [ " $ { num } " = " " ]?:6)
same = > 4 , Set ( num =509)
same = > 5 , Goto (7)
same = > 6 , PlayBack ( custom / asr_desvio )
same = > 7 , Dial ( SIP / $ { num } ,10 , m ( radio ) )
same = > n , PlayBack ( custom / asr_no_disponible )
same = > n , Goto ( # ,1)
; llama desde un telefono exterior a otro pasando por Asterisk
exten = > 5 ,1 , PlayBack ( custom / asr_exterior )
same = > n , NoOp (1 , $ { CHANNEL } , $ { CALLERID ( num ) } - $ { CALLERID ( name ) })
same = > n , Read ( telf , dir - pls - enter ,5)
same = > n , Dial ( DAHDI / g1 / $ { telf } ,15 , m ( radio ) )
; extension menu privado
exten = > 6 ,1 , Goto ( menu - privado ,s ,1)
; extension para colgar
exten = > # ,1 , PlayBack ( custom / asr_despedida )
same = > 2 , Hangup ()
; extension en caso de error al introducir la extension
exten = > i ,1 , PlayBack ( custom / asr_opcion_incorrecta )
same = > 2 , GotoIf ( $ [ $ { k }=3]? s , max )
same = > 3 , Goto (s ,4)
[ menu - privado ]
exten = > s ,1 , PlayBack ( custom / asr_bienvenida_privado )
same = > 2 , Authenticate (12369 , j )
same = > 3 , Background ( custom / asr_menu_privado )
124
A.2. A RCHIVOS
DE CONFIGURACIN
A STERISK
same = > 4 , WaitExten (15 , m ( radio ) )

same = > 5 , Goto (3)
; extension para Salas de Conferencias
exten = > 1 ,1 , PlayBack ( custom / asr_conferencia )
same = > n , MeetMe (101 , pM )
same = > n , Goto ( centralita_ASR , # ,1)
; extension para efectuar espionajes
exten = > 2 ,1 , PlayBack ( custom / asr_escucha )
same = > n , Set ( SPY_EXIT_CONTEXT = centralita_ASR )
same = > n , Chanspy ( , X )
same = > n , Goto ( centralita_ASR , # ,1)
; extension en caso de error al introducir la extension
exten = > i ,1 , PlayBack ( custom / asr_opcion_incorrecta )
same = > 2 , Goto (s ,3)
A.2.4
M SICA EN ESPERA
Se aaden las siguientes lneas al final del archivo /etc/asterisk/musiconhold.conf:

[ default ]
mode = files
directory =/ var / lib / asterisk / mohlau
random = yes
[ radio ]
mode = custom
application =/ var / lib / asterisk / mohlau2 / music . sh
Se crea el archivo /var/lib/asterisk/mohlau2/music.sh que reproduce una

emisora de radio por Internet (shoutcast):
# !/ bin / bash
wget -q -T 120 -O - http ://184.95.62.170:8002 | / usr / bin / madplay -Q
-- mono -R 8000 -a -20 -o raw : - -
A.2.5
B UZN DE VOZ
Se aaden las siguientes lneas al final del archivo /etc/asterisk/voicemail.conf:

; Maximum length of a voicemail message in seconds
maxsecs =30
; You can override the default program to send e - mail if you wish , too
mailcmd =/ usr / sbin / sendmail -t
125
A STERISK
[ default ]
; buzones de voz para los residentes
200 = > 123 , residente1 , chiara2026@gmail . com
; buzones de voz para todos los trabajadores
501 = > 123 , Recepcion , chiara2026@gmail . com
502 = > 123 , Trabajadora Social , chiara2026@gmail . com
503 = > 123 , Gerocultora 1 , chiara2026@gmail . com
506 = > 123 , Despacho Directora , chiara2026@gmail . com
507 = > 123 , Movil Directora , chiara2026@gmail . com
508 = > 123 , Casa Directora , chiara2026@gmail . com
509 = > 123 , Psicologa , chiara2026@gmail . com
500 = > 123 , Jefa Enfermeras , chiara2026@gmail . com
A.2.5.1
G ESTOR
DE CORREO
Se configura el archivo /etc/ssmtp/ssmtp.conf aadiendo las siguientes lneas:

#
# Config file for sSMTP sendmail
#
# The person who gets all mail for userids < 1000
root = securebiometricvoting@gmail . com
# The place where the mail goes . The actual machine name is required
no
# MX records are consulted . Commonly mailhosts are named
mail . domain . com
mailhub = smtp . gmail . com :587
# The full hostname
hostname = securebiometricvoting@gmail . com
# Are users allowed to set their own From : address ?
FromLineOverride = YES
AuthMethod = LOGIN
UseTLS = YES
UseSTARTTLS = YES
AuthUser = securebiometricvoting@gmail . com
AuthPass = isgsbv2011
Se configura el archivo /etc/ssmtp/revaliases aadiendo las siguientes lneas:

# sSMTP aliases
#
126
A.2. A RCHIVOS
DE CONFIGURACIN
A STERISK
# Format :
local_account : outgoing_address : mailhub
#
root : securebiometricvoting@gmail . com : smtp . gmail . com :587
A.2.6
F OLLOW M E
Se aaden las siguientes lneas al final del archivo /etc/asterisk/followme.conf:

[ directora ]
musicclass = > radio
context = > usuarios
number = > 507 ,20 ; movil directora
number = > 508 ,20 ; casa directora
A.2.7
S ALA DE C ONFERENCIAS
Se aaden las siguientes lneas al final del archivo /etc/asterisk/meetme.conf:

[ rooms ]
; sala de conferencias para usuarios internos ( trabajadores )
conf = > 600 ,5678
; sala de conferencia centralita Dahdi
conf = > 101 ,14789
A.2.8
C OLAS
Se aaden las siguientes lneas al final del archivo /etc/asterisk/queues.conf:

[ cola_enfermeria ]
strategy = ringall
timeout = 10
retry = 5
periodic - announce = queue - thankyou
periodic - announce - frequency = 8
musicclass = radio
member = > SIP /503 ,1
A.2.9
T RANSFERENCIA Y PARKING DE LLAMADAS
Se descomentan las siguientes lneas en el archivo /etc/asterisk/features.conf:

127
[ general ]
parkext = > 700
parkpos = > 701 -720
( defafult parking lot )
context = > parkedcalls

( default parking lot )
A STERISK
; What extension to dial to park

; What extensions to park calls on .
; These needs to be numeric , as
Asterisk starts from the start
position
; and increments with one for the next
parked call .
; Which context parked calls are in
128
B
Instalaciones y configuraciones relacionadas con
las aplicaciones Android
B.1
I NSTALACIN
A NDROID
ENTORNO DE DESARROLLO PARA
Prerrequisitos: Java JDK

El Android SDK utiliza el kit de desarrollo de Java (Java JDK), por lo tanto, es
lo primero que hay que instalar en el servidor. El paquete JDK1 es necesario para
desarrollar aplicaciones y applets en Java (lenguaje que utiliza Android). Tambin
lleva incluido el JRE2 , que sirve para lanzar aplicaciones y applets en Java. Se
descarga el paquete de la pgina web oficial: http://www.oracle.com/technetwork/
java/javase/downloads/jdk-6u26-download-400750.html, se ubica en el directorio
/usr/src y se instala escribiendo lo siguiente en un terminal:
> cd / usr / src
> chmod + x jdk -6 u26 - linux - x64 . bin
> ./ jdk -6 u26 - linux - x64 . bin
Eclipse
Se descarga la ltima versin de Eclipse en el servidor desde la pgina web oficial:
http://www.eclipse.org/downloads/. La ltima versin disponible al iniciar este
proyecto, y por tanto la instalada, es la Eclipse Classic 3.6.2 (Helios). Lo colocamos en
el directorio /home/ldd/Desarrollo.
1
2
Java Development Kit

Java Runtime Environment
129
CAPTULO B. I NSTALACIONES
Y CONFIGURACIONES RELACIONADAS CON LAS

APLICACIONES
A NDROID
Eclipse es un ejecutable, no hay que instalarlo. Se modifica el archivo eclipse.ini

para especificar la ruta del JDK instalado antes escribiendo lo siguiente en un terminal:
> cd / home / ldd / Desarrollo / eclipse
> nano eclipse . ini
Se incluyen las siguientes lneas antes de la lnea -vmargs:

- vm
/ usr / src / jdk1 .6.0 _26 / bin / java
Android SDK
Se descarga el SDK de Android de la pgina web oficial: http://developer.
android.com/sdk/index.html. En este caso, se elige la versin 14 para Linux
y tras aceptar la licencia, se guarda y descomprime el fichero en el directorio
home/ldd/Desarrollo.
Antes de instalar nada, hay que declarar en el archivo .bashrc los paths de: android,
java y eclipse, para que el sistema los encuentre. Se incluyen las siguientes lneas al final
del archivo:
> nano ~/. bashrc
export PATH = $ { PATH }:/ home / ldd / Desarrollo / android - sdk - linux_x86 / tools
export PATH = $ { PATH }:/ usr / src / jdk1 .6.0 _26 / bin
export PATH = $ { PATH }:/ home / ldd / Desarrollo / eclipse
A continuacin se cierran todos los terminales abiertos, para que haga efecto el path
que se acaba de definir, se abre uno nuevo y se escribe la instruccin:
android
Con esta instruccin se accede al manager de Android, desde el que se puede

instalar y actualizar el SDK, as como crear dispositivos virtuales para realizar las
pruebas de las aplicaciones. En la figura B.1 se puede observar el aspecto del manager
de Android al abrirlo.
130
B.1. I NSTALACIN
A NDROID
FIGURA B.1: Pantalla inicial del Android Manager.
Para instalar el SDK, se accede a la seccin Available Packages y se pulsa el botn

Refresh para que aparezca la lista de todos los paquetes que se pueden instalar. La
pantalla del Manager tendr ahora el aspecto de la figura B.2. Se seleccionan todos los
paquetes y se pulsa Install Selected.
FIGURA B.2: Pantalla del Android Manager con todos los paquetes disponibles para
instalar.
Al hacer esto, se abre una nueva ventana, como se puede ver en la figura B.3,
para aceptar las licencias de los paquetes que se van a instalar. Se seleccionan todas
131

APLICACIONES
A NDROID
las licencias y se pulsa el botn Install Acepted. Al acabar la instalacin, se cierra el

manager y se continua con la instalacin del plugin ADT para Eclipse.
FIGURA B.3: Pantalla del Android Manager para instalar licencias.
ADT
El plugin de Android ADT se instala desde el mismo Eclipse siguiendo los pasos
especificados a continuacin. Primero se abre Eclipse, y desde la pestaa Help
del men, se escoge la opcin Install New Software y se pulsa el botn Add. En
la ventana que aparece, hay que especificar el nombre del software que se quiere
instalar (Android Plugin) y la direccin de descarga, como se puede ver en la figura B.4.
FIGURA B.4: Ventana para instalar el plugin ADT en Eclipse.
Al encontrar la informacin en la direccin indicada, aparece en la pantalla el

paquete Developer Tools con los dos plugins que incluye: Android DDMS y Android
132
B.1. I NSTALACIN
A NDROID
Development, como puede verse en la figura B.5. Se selecciona todo y se pulsa el botn
Next para que se comprueben las dependencias necesarias. En la pantalla siguiente
(figura B.6) se aceptan los trminos de la licencia y se pulsa Finish.
.
FIGURA B.5: Pantalla con los paquetes necesarios para instalar el plugin ADT.
133

APLICACIONES
A NDROID
FIGURA B.6: Pantalla para aceptar las licencias de los paquetes del plugin ADT.
Hecho esto, se empieza el proceso de descarga e instalacin de los paquetes

indicados antes y de todas las dependencias necesarias para que el ADT funcione
correctamente. Al finalizar este proceso, se debe reiniciar Eclipse.
El ltimo paso consiste en indicar a Eclipse la ubicacin del Android SDK. Para
ello seleccionamos la siguiente opcin del men W indow > P ref erences > Android y
donde pone SDK Location pulsamos el botn Browse y especificamos la carpeta donde
est instalado el SDK de Android, que en este caso es:
/ home / ldd / Desarrollo / android - sdk - linux_86
Se pulsa el botn Apply para que se cargue el Android SDK Content Loader. Una
vez finalizado este proceso, aparece la pantalla de la figura B.7 en la que se ve un
listado con todo lo que se ha instalado. Con esto se consigue importar el Android SDK
a Eclipse para disponer de las ayudas necesarias al escribir el cdigo.
134
B.2. B ASE
DE DATOS REMOTA
FIGURA B.7: Pantalla de Eclipse con las opciones del Android SDK instaladas.
B.2
B.2.1
B ASE
DE DATOS REMOTA
I NSTALACIN Y CONFIGURACIN
Para instalar el paquete LAMP (Linux, Apache, MySQL, PHP) en el servidor, se escribe
la siguiente lnea en un terminal:
> tasksel install lamp - server
Para comprobar si se ha realizado correctamente la instalacin, se abre un navegador, se escribe la direccin del servidor en la barra de direcciones (http://localhost)
y se debe obtener el siguiente resultado por pantalla:
It works !
This is the default web page for this server .
The web server software is running but no content has been added , yet .
A continuacin se instala un cliente grfico para gestionar la base de datos del

servidor de forma ms sencilla. Se instala el paquete mysql-navigator desde el gestor
de paquetes Synaptics.
Con todos los paquetes necesarios instalados, ya se puede crear la base de datos.
Para ello, se abre el cliente MySQL Navigator que se acaba de instalar. El primer paso
135

APLICACIONES
A NDROID
es indicar al cliente grfico la ubicacin de la base de datos (localhost en este caso),

y el usuario y contrasea para acceder a la misma. Esto se hace con el men de la
ventana Server que aparece al abrir el cliente, como se puede ver en la figura B.8.
FIGURA B.8: Definicin de la ubicacin de la base de datos con usuario y contrasea.
Al hacer esto, aparece la pantalla de la figura B.9. En el apartado Database aparecen

las bases de datos que son para la gestin interna de MySQL (information_schema,
mysql). Para crear la base de datos que se va a utilizar en las aplicaciones, se clica con
el botn derecho encima de Database y aparece la opcin Create Database. Se escoge
un nombre para la base de datos (ALCATRAZ en este caso) y ya aparece la nueva base
de datos en el listado anterior.
136
B.2. B ASE
DE DATOS REMOTA
FIGURA B.9: Pantalla inicial del cliente grfico MySQL Navigator.
Por ltimo, hay que crear las tablas que tendr la base de datos. Como ya se ha
comentado anteriormente, la base de datos del proyecto tiene dos tablas: MyAlerts y
MyCoordinates. Para crear una tabla, se clica con el botn derecho encima del nombre
de la base de datos (ALCATRAZ) y se escoge la opcin Execute Query. Al crear las
tablas, hay que definir su nombre, as como el nombre y tipo de todos sus atributos.
En la figura B.10 se ve la query utilizada para crear la tabla de alertas MyAlerts. De
la misma manera, en la figura B.11 se ve la query utilizada para crear la tabla de
coordenadas MyCoordinates. Al ejecutar estas dos querys, se crean las dos tablas y se
aaden a la base de datos ALCATRAZ tal y como se ve en la figura B.12. Con esto, ya
se tiene la base de datos preparada para su utilizacin desde las aplicaciones Android.
137

APLICACIONES
FIGURA B.10: Pantalla de creacin de la tabla de alertas MyAlerts.
138
A NDROID
B.2. B ASE
DE DATOS REMOTA
FIGURA B.11: Pantalla de creacin de la tabla de coordenadas MyCoordinates.
139

APLICACIONES
A NDROID
FIGURA B.12: Base de datos Alcatraz con sus dos tablas: MyAlerts y MyCoordinates.
El ltimo paso necesario es la creacin de los scripts PHP que se utilizan para
gestionar la base de datos.
B.2.2
S CRIPTS PHP
Los scripts PHP que se utilizan para gestionar la base de datos ALCATRAZ deben ubicarse en el directorio de Apache, en este caso, /var/www/. Se aaden tantos scripts
como operaciones se quieran realizar, utilizando los siguientes comandos en un terminal:
140
B.2. B ASE
DE DATOS REMOTA
> cd / var / www /

> touch nombre_script . php
A continuacin se presenta el cdigo de todos los scripts PHP que se han utilizado
en este proyecto, diferenciando los utilizados por cada una de las aplicaciones. Para
realizar pruebas, estos scripts se pueden ejecutar directamente desde un navegador
escribiendo la instruccin con la siguiente nomenclatura en la barra de direcciones:
http :// localhost / nombre_script . php ? arg1 = value1 & arg2 = value2 & arg3 = value3 ...
B.2.2.1
S OFTPHONE
RESIDENTES
insert_alert_user.php
<? php
mysql_connect ( " localhost " ," root " ," t1lq1si " ) ;
mysql_select_db ( " ALCATRAZ " ) ;
try {
$result = mysql_query ( " INSERT INTO MyAlerts ( user , name )

VALUES ( ' " . $_REQUEST [ ' user ' ]. " ',
'" . $_REQUEST [ ' name ' ]. " ') " ) ;
print ( json_encode ( $result ) ) ;
mysql_close () ;
?>
}
catch ( Exception $e ) {
print ( json_encode ( $e ) ) ;
mysql_close () ;
}
get_alert_user.php
<? php
try {
$result = mysql_query ( " SELECT id FROM MyAlerts WHERE

name = ' " . $_REQUEST [ ' name ' ]. " ' AND
141

APLICACIONES
user = ' " . $_REQUEST [ ' user ' ]. " '" ) ;

while ( $tmp = mysql_fetch_assoc ( $result ) )
$output []= $tmp ;
print ( json_encode ( $output ) ) ;
mysql_close () ;
?>
}
mysql_close () ;
}
update_alert_user.php
<? php
try {
$result = mysql_query ( " UPDATE MyAlerts SET

user = ' " . $_REQUEST [ ' user ' ]. " ',
name = ' " . $_REQUEST [ ' name ' ]. " ' WHERE
id = " . $_REQUEST [ ' id ' ]. " " ) ;
mysql_close () ;
?>
}
mysql_close () ;
}
delete_alert_user.php
<? php
try {
142
A NDROID
B.2. B ASE
DE DATOS REMOTA
$result = mysql_query ( " DELETE FROM MyAlerts WHERE

mysql_close () ;
?>
}
mysql_close () ;
}
update_alert_flag.php
<? php
try {

alert_flag = " . $_REQUEST [ ' flag ' ]. " WHERE
mysql_close () ;
?>
}
mysql_close () ;
}
update_battery_flag.php
<? php
try {

battery_flag = " . $_REQUEST [ ' flag ' ]. " WHERE
143

APLICACIONES
A NDROID

mysql_close () ;
?>
}
mysql_close () ;
}
insert_coordinates.php
<? php
try {
$result = mysql_query ( " INSERT INTO MyCoordinates ( user ,

latitude , longitude ) VALUES
( ' " . $_REQUEST [ ' user ' ]. " ', " . $_REQUEST [ ' latitude ' ]. " ,
" . $_REQUEST [ ' longitude ' ]. " ) " ) ;
mysql_close () ;
?>
B.2.2.2
}
mysql_close () ;
}
S OFTPHONE
RECEPCIN
get_alert_coordinates.php
<? php
try {
$result = mysql_query ( " SELECT

MyCoordinates . user , MyAlerts . name , MyCoordinates . latitude ,
144
B.2. B ASE
DE DATOS REMOTA
MyCoordinates . longitude FROM MyAlerts , MyCoordinates

WHERE MyAlerts . user = MyCoordinates . user AND
MyAlerts . alert_flag =1 AND
MyCoordinates . id =( SELECT MAX ( id ) FROM
MyCoordinates WHERE user = MyAlerts . user ) " ) ;
$output []= $tmp ;
mysql_close () ;
?>
}
mysql_close () ;
}
get_user_coordinates.php
<? php
try {
$result = mysql_query ( " SELECT

MyAlerts . user , MyAlerts . name , MyCoordinates . latitude ,
MyCoordinates . longitude FROM MyAlerts , MyCoordinates
WHERE MyCoordinates . user = ' " . $_REQUEST [ ' user ' ]. " '
AND MyCoordinates . id =( SELECT MAX ( id ) FROM
MyCoordinates WHERE user = MyAlerts . user ) " ) ;
$output []= $tmp ;
mysql_close () ;
?>
}
mysql_close () ;
}
check_battery_alert.php
145

APLICACIONES
A NDROID
<? php
try {
$result = mysql_query ( " SELECT COUNT (*) AS num FROM

MyAlerts WHERE battery_flag =1 " ) ;
$tmp = mysql_fetch_assoc ( $result ) ;
print ( json_encode ( $tmp [ ' num ' ] >0) ) ;
mysql_close () ;
?>
}
mysql_close () ;
}
get_battery_alerts.php
<? php
try {
$result = mysql_query ( " SELECT user , name FROM MyAlerts

WHERE battery_flag =1 ORDER BY name " ) ;
$output []= $tmp ;
?>
mysql_close () ;
}
mysql_close () ;
}
146
B.3. E XTENSIONES
B.3
DE EMERGENCIA
E XTENSIONES
A STERISK
DE EMERGENCIA
A STERISK
Las extensiones de emergencia que se utilizan en las aplicaciones se encuentran en el contexto [android_V A] del dialplan de Asterisk, en el archivo
/etc/asterisk/extensions.conf:
[ android_VA ]
exten = > 033 ,1 , Answer ()
same = > n , PlayBack ( beep )
; Origina una llamada entre SIP /501 ( r e c e p c i n ) y CALLERID ( num )
llama a SIP /501 y luego ejecuta la instruccion de la extension
CALLERID ( num ) , prioridad 2
same = > n , Originate ( SIP /501 , exten , usuarios , $ { CALLERID ( num ) } ,2)
exten = > 034 ,1 , Answer ()
exten = > 035 ,1 , Answer ()
147

APLICACIONES
148
A NDROID

Memoria PDF

Cargado por

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

Memoria PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Memoria PDF

Cargado por

Copyright:

Formatos disponibles

PROJECTE FINAL DE CARRERA

Diseo de aplicaciones sobre VoIP con

Laura Duarte Domingo

Director/a: Marcel Fernndez Muoz

la VoIP se ha ido introduciendo cada vez en ms aspectos

N LOS LTIMOS AOS ,

El objetivo final es conseguir un proyecto que englobe estas tecnologas, con lo

3.4.3.8 T RANSFERENCIA Y PARKING DE LLAMADAS .

4 Implementacin de los Softphones

5 Conclusiones y lneas de futuro

A Instalaciones y configuraciones relacionadas con Asterisk

B Instalaciones y configuraciones relacionadas con las aplicaciones Android 129

1.1 Plataforma de VoIP implementada para la residencia. . . . . . . . . . . .

Principales componentes de una red VoIP. . . . . . . . . . . . . . . . . .

Esquema del entorno de simulacin. . . . . . . . . . . . . . . . . . . . .

4.1 Tablas de la base de datos ubicada en el servidor. . . . . . . . . . . . . .

2.1 Cdecs de audio y protocolos soportados en Asterisk. . . . . . . . . . . .

3.1 Listado de usuarios SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1 Clases e interfaz incluidos en la API SIP de Android.

N LOS LTIMOS AOS ,

La plataforma de VoIP implementada para la residencia se puede ver en la figura 1.1

FIGURA 1.1: Plataforma de VoIP implementada para la residencia.

La comunicacin entre Asterisk y las aplicaciones instaladas en los smartphones se

Residente sale de la zona permitida

VoIP (Voice Over Internet Protocol) se refiere a los protocolos de comunicacin,

Public Switched Telephone Network

CAPTULO 2. C ONCEPTOS G ENERALES

FUNDAMENTALES DE UNA RED

La figura 2.1 muestra los elementos fundamentales de una red VoIP.

User Data Protocol

CAPTULO 2. C ONCEPTOS G ENERALES

Medium Access Control

Conjugate-Structure Algebraic-Code-Excited Linear Prediction. Mtodo de compresin del habla

CAPTULO 2. C ONCEPTOS G ENERALES

2.1.4.1.1 E JEMPLO DE UNA COMUNICACIN SIP/RTP

Network Address Translation. Proceso consistente en modificar la direccin IP de la informacin en

CAPTULO 2. C ONCEPTOS G ENERALES

International Telecommunication Union

Private Branch eXchange.

CAPTULO 2. C ONCEPTOS G ENERALES

Asterisk Extension Logic

Cada paso o instruccin dentro de una extensin se compone de tres componentes:

CAPTULO 2. C ONCEPTOS G ENERALES

G.711 (a-law y u-law), G.726, G.723.1, G.729A, GSM, iLBC, Speex,

* Test modules: Se utilizan por el equipo de desarrollo de Asterisk para validar

Y FUNCIONALIDADES QUE OFRECE

Como se ha comentado anteriormente, Asterisk permite la implementacin de los

CAPTULO 2. C ONCEPTOS G ENERALES

I NTEGRACIN CON LA RED CONMUTADA DE TELEFONA

Asterisk es capaz de comunicarse con diferentes tecnologas. Normalmente, esta

Android es un sistema operativo basado en Linux para dispositivos mviles como

El sistema operativo Android est dividido en cinco secciones distribuidas dentro de

Digium Asterisk Hardware Device Interface

CAPTULO 2. C ONCEPTOS G ENERALES

para instalar la aplicacin.

2.3.1.2.1 A NATOMA DE UNA APLICACIN

CAPTULO 2. C ONCEPTOS G ENERALES

2.3.1.2.2 A NDROID M ANIFEST