diseño de aplicaciones sobre voip con mecanismos de

PROJECTE FINAL DE CARRERA

Diseño de aplicaciones sobre VoIP con mecanismos de geoposicionamiento

Estudis: Enginyeria de Telecomunicació

Autor: Laura Duarte Domingo

Director/a:Marcel Fernández Muñoz

Any: 2014

A Isaac y a mi familia,por la infinita paciencia que han

demostrado a lo largo de este viaje

Resumen

EN LOS ÚLTIMOS AÑOS, la VoIP se ha ido introduciendo cada vez en más aspectosde nuestra vida cotidiana. Este proyecto nace de la intención de explorar las

posibilidades que ésta nos ofrece. Con la decisión de trabajar siempre con tecnologíaopen source se opta por utilizar dos tecnologías en auge en este momento. Asterisk,utilizada cada vez en más empresas por su facilidad de implantación y flexibilidad.No sólo ofrece la posibilidad de implementar una centralita de telefonía con VoIP deforma económica, sino que además integra algunos servicios de valor añadido como losofrecidos por las más potentes centralitas comerciales. Android, que ha experimentadoun gran crecimiento desde su aparición, siendo uno de los dos sistemas operativos másutilizado para smartphones y que nos permite crear aplicaciones de forma gratuita ycon un gran abanico de posibilidades a nuestra disposición.

El objetivo final es conseguir un proyecto que englobe estas tecnologías, con loque se realiza una plataforma de VoIP pensada para su utilización en una residenciade ancianos (aunque la idea puede extrapolarse a otros escenarios). UtilizandoAsterisk como un servidor de VoIP, se crea además una centralita de telefonía conreconocimiento de voz para la recepción del centro, que comunicará las llamadasdel exterior con los diferentes departamentos. Utilizando Android se diseñan dossoftphones para los smartphones de los miembros de la residencia. Además de las ca-racterísticas básicas, los softphones de los residentes están diseñados para controlar laubicación de los mismos si se alejan demasiado de la residencia. De la misma manera,los softphones de los trabajadores incluyen un sistema de comprobación de la ubicaciónde los residentes en estos casos, así como la posibilidad de comprobar el sistema debatería 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 quetienen las herramientas que hemos utilizado y las amplias posibilidades que ofrecenpara proyectos futuros.

iii

CONTENIDO

1 Introducción 91.1 PLATAFORMA DE VOIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 CASOS DE USO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Conceptos Generales 132.1 VOIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1 ¿QUÉ ES LA VOIP? . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.2 ARQUITECTURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.2.1 COMPONENTES FUNDAMENTALES DE UNA RED VOIP . . . 142.1.2.2 TRANSMISIÓN DE LA VOIP POR LA RED . . . . . . . . . . 15

2.1.3 CÓDECS DE AUDIO . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.4 PROTOCOLOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.4.1 SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.4.1.1 EJEMPLO DE UNA COMUNICACIÓN SIP/RTP . . 18

2.1.4.2 H.323 . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.1.4.3 IAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2 ASTERISK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.1 ¿QUÉ ES ASTERISK? . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.2 CONCEPTOS BÁSICOS . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.3 ARQUITECTURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.3.1 SERVICIOS Y FUNCIONALIDADES QUE OFRECE . . . . . . . 252.2.4 INTEGRACIÓN CON LA RED CONMUTADA DE TELEFONÍA . . . . . . . 26

2.2.4.1 TARJETAS ANALÓGICAS . . . . . . . . . . . . . . . . . . . 262.2.4.2 TARJETAS DIGITALES . . . . . . . . . . . . . . . . . . . . 26

2.3 ANDROID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.1 ¿QUÉ ES ANDROID? . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1

2.3.1.1 ARQUITECTURA . . . . . . . . . . . . . . . . . . . . . . . 272.3.1.2 APLICACIONES . . . . . . . . . . . . . . . . . . . . . . . 28

2.3.1.2.1 ANATOMÍA DE UNA APLICACIÓN . . . . . . . . . 292.3.1.2.2 ANDROID MANIFEST . . . . . . . . . . . . . . . 30

2.3.2 ACTIVIDADES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.2.1 CICLO DE VIDA DE UNA ACTIVIDAD . . . . . . . . . . . . 31

2.3.3 INTENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.3.4 INTERFAZ DE USUARIO . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3.4.1 COMPONENTES DE LA PANTALLA . . . . . . . . . . . . . . 332.3.4.1.1 VISTAS . . . . . . . . . . . . . . . . . . . . . . 332.3.4.1.2 LAYOUTS . . . . . . . . . . . . . . . . . . . . . 34

2.3.4.2 MENÚS . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3.4.3 DIÁLOGOS . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3.4.4 NOTIFICACIONES . . . . . . . . . . . . . . . . . . . . . . 36

2.3.5 SERVICIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.3.6 BROADCAST RECEIVERS . . . . . . . . . . . . . . . . . . . . . . . 372.3.7 PERSISTENCIA DE DATOS . . . . . . . . . . . . . . . . . . . . . . . 37

2.3.7.1 SHARED PREFERENCES . . . . . . . . . . . . . . . . . . . 372.3.7.2 BASE DE DATOS LOCAL . . . . . . . . . . . . . . . . . . . 37

2.3.8 LBS (LOCATION BASED SERVICES) . . . . . . . . . . . . . . . . . 38

3 Implementación de la Centralita 393.1 OBJETIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2 ENTORNO DE SIMULACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . 393.3 INSTALACIÓN DEL ENTORNO . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3.1 TARJETA DIGIUM TDM808 . . . . . . . . . . . . . . . . . . . . . . 413.3.2 CANCELADOR DE ECO OSLEC . . . . . . . . . . . . . . . . . . . . . 413.3.3 GESTOR DE CORREO . . . . . . . . . . . . . . . . . . . . . . . . . 423.3.4 RECONOCIMIENTO DE VOZ . . . . . . . . . . . . . . . . . . . . . . 423.3.5 SOFTPHONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4 CONFIGURACIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.4.1 TARJETA DIGIUM Y CANCELADOR DE ECO OSLEC . . . . . . . . . . 433.4.2 CANALES DAHDI . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.4.3 ASTERISK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4.3.1 USUARIOS . . . . . . . . . . . . . . . . . . . . . . . . . . 473.4.3.2 DIALPLAN . . . . . . . . . . . . . . . . . . . . . . . . . . 483.4.3.3 MÚSICA EN ESPERA . . . . . . . . . . . . . . . . . . . . . 503.4.3.4 BUZÓN DE VOZ . . . . . . . . . . . . . . . . . . . . . . . 503.4.3.5 FOLLOW ME . . . . . . . . . . . . . . . . . . . . . . . . 503.4.3.6 SALA DE CONFERENCIAS . . . . . . . . . . . . . . . . . . 513.4.3.7 COLAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2

3.4.3.8 TRANSFERENCIA Y PARKING DE LLAMADAS . . . . . . . . 523.4.4 CENTRALITA PBX . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.4.4.1 INTEGRACIÓN DEL RECONOCIMIENTO DE VOZ . . . . . . . 553.4.5 EJECUCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4 Implementación de los Softphones 654.1 OBJETIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.2 INSTALACIÓN Y CONFIGURACIÓN DEL ENTORNO DE TRABAJO . . . . . . . . 65

4.2.1 DESARROLLO DE APLICACIONES ANDROID . . . . . . . . . . . . . . 664.2.2 BASE DE DATOS REMOTA . . . . . . . . . . . . . . . . . . . . . . . 67

4.2.2.1 ESTRUCTURA DE LA BASE DE DATOS . . . . . . . . . . . . 674.2.2.2 SCRIPTS PHP . . . . . . . . . . . . . . . . . . . . . . . . 68

4.2.3 EXTENSIONES DE EMERGENCIA EN ASTERISK . . . . . . . . . . . . 704.3 DESARROLLO DE LAS APLICACIONES . . . . . . . . . . . . . . . . . . . . . 70

4.3.1 SOFTPHONE BÁSICO . . . . . . . . . . . . . . . . . . . . . . . . . . 714.3.1.1 INTEGRACIÓN DE LA VOIP EN LA APLICACIÓN . . . . . . . 75

4.3.1.1.1 SERVICESIP . . . . . . . . . . . . . . . . . . . . 764.3.1.1.2 CALLRECEIVERSIP . . . . . . . . . . . . . . . . 834.3.1.1.3 SERVICEBINDER . . . . . . . . . . . . . . . . . 84

4.3.2 SOFTPHONE PARA RESIDENTES . . . . . . . . . . . . . . . . . . . . 844.3.2.1 ALERTAS DE BATERÍA . . . . . . . . . . . . . . . . . . . . 864.3.2.2 ALERTAS DE POSICIONAMIENTO . . . . . . . . . . . . . . 86

4.3.2.2.1 ALERTSSERVICE . . . . . . . . . . . . . . . . . 884.3.3 SOFTPHONE PARA LA RECEPCIÓN DEL CENTRO . . . . . . . . . . . . 92

4.3.3.1 COMPROBACIÓN DE ALERTAS DE BATERÍA . . . . . . . . . 934.3.3.2 COMPROBACIÓN DE ALERTAS DE POSICIONAMIENTO . . . 95

4.3.3.2.1 SHOWLOCATIONMAP . . . . . . . . . . . . . . . 97

5 Conclusiones y líneas de futuro 1075.1 VALORACIÓN PERSONAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6 Bibliografía 111

A Instalaciones y configuraciones relacionadas con Asterisk 113A.1 Instalaciones relacionadas con Asterisk . . . . . . . . . . . . . . . . . . . 113

A.1.1 PRERREQUISITOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 113A.1.2 DAHDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113A.1.3 LIBPRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114A.1.4 ASTERISK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114A.1.5 CANCELADOR DE ECO OSLEC . . . . . . . . . . . . . . . . . . . . . 116A.1.6 RECONOCIMIENTO DE VOZ . . . . . . . . . . . . . . . . . . . . . . 116

A.2 Archivos de configuración Asterisk . . . . . . . . . . . . . . . . . . . . . 117

3

A.2.1 CANALES DAHDI . . . . . . . . . . . . . . . . . . . . . . . . . . . 117A.2.2 USUARIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118A.2.3 DIALPLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119A.2.4 MÚSICA EN ESPERA . . . . . . . . . . . . . . . . . . . . . . . . . . 125A.2.5 BUZÓN DE VOZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

A.2.5.1 GESTOR DE CORREO . . . . . . . . . . . . . . . . . . . . 126A.2.6 FOLLOW ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127A.2.7 SALA DE CONFERENCIAS . . . . . . . . . . . . . . . . . . . . . . . 127A.2.8 COLAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127A.2.9 TRANSFERENCIA Y PARKING DE LLAMADAS . . . . . . . . . . . . . . 127

B Instalaciones y configuraciones relacionadas con las aplicaciones Android 129B.1 INSTALACIÓN ENTORNO DE DESARROLLO PARA ANDROID . . . . . . . . . . 129B.2 BASE DE DATOS REMOTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

B.2.1 INSTALACIÓN Y CONFIGURACIÓN . . . . . . . . . . . . . . . . . . . 135B.2.2 SCRIPTS PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

B.2.2.1 SOFTPHONE RESIDENTES . . . . . . . . . . . . . . . . . . 141B.2.2.2 SOFTPHONE RECEPCIÓN . . . . . . . . . . . . . . . . . . 144

B.3 EXTENSIONES DE EMERGENCIA ASTERISK . . . . . . . . . . . . . . . . . . 147

4

LISTA DE FIGURAS

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

2.1 Principales componentes de una red VoIP. . . . . . . . . . . . . . . . . . 152.2 Trapezoide SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3 Tramas SIP y RTP de una llamada telefónica de VoIP. . . . . . . . . . . . 192.4 Arquitectura modular de Asterisk. . . . . . . . . . . . . . . . . . . . . . . 232.5 Esquema de la arquitectura del sistema Android. . . . . . . . . . . . . . 292.6 Ciclo de vida de una actividad. . . . . . . . . . . . . . . . . . . . . . . . 322.7 Ejemplo de un Linear Layout con las vistas más comunes y los dos tipos

de menús existentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1 Esquema del entorno de simulación. . . . . . . . . . . . . . . . . . . . . 403.2 Diagrama de flujo de la centralita (Inicio). . . . . . . . . . . . . . . . . . 583.3 Diagrama de flujo de la extensión 0 de la centralita (Recepción). . . . . 593.4 Diagrama de flujo de la extensión 1 de la centralita (Trabajadora Social). 603.5 Diagrama de flujo de la extensión 2 de la centralita (Enfermería). . . . . 613.6 Diagrama de flujo de la extensión 3 de la centralita (Dirección). . . . . . 623.7 Diagrama de flujo de la extensión 4 de la centralita (Psicóloga). . . . . . 633.8 Diagrama de flujo de la extensión 6 de la centralita (Menú privado). . . 64

4.1 Tablas de la base de datos ubicada en el servidor. . . . . . . . . . . . . . 684.2 Menú tab de la aplicación con: a) Pantalla principal de la aplicación. b)

Lista de contactos. c) Registro de llamadas. . . . . . . . . . . . . . . . . 724.3 a) Menú principal de la aplicación para los residentes. b) Diálogo que

aparece al cerrar las aplicaciones. . . . . . . . . . . . . . . . . . . . . . . 734.4 a) Listado de cuentas con menú abierto. b) Menú context de una cuenta

(opciones de la cuenta). . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5

LISTA DE FIGURAS

4.5 Pantalla mostrada durante las llamadas en las aplicaciones. . . . . . . . 754.6 a) Notificación que aparece cuando no hay ninguna cuenta activa. b)

Notificación permanente que aparece cuando hay una cuenta logada enel servidor SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.7 a) Notificación que aparece al no poder registrar la cuenta especificadaen el servidor SIP. b) Notificación que indica la existencia de llamadasperdidas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.8 Listado de cuentas con acceso protegido por contraseña. . . . . . . . . . 854.9 Menú principal del softphone para la recepción del centro. . . . . . . . . 934.10 a) Notificación de alertas de batería. b) Listado de alertas de batería. . . 954.11 a) Mapa de alertas con 2 usuarios (mostrando la información de uno de

ellos). b) Mapa con 2 usuarios fuera de la zona permitida (rojos) y unusuario en seguimiento (verde). . . . . . . . . . . . . . . . . . . . . . . . 98

4.12 Diálogo mostrado cuando no hay alertas de posicionamiento en el mapa. 1004.13 a) Menú del mapa de alertas. b) Diálogo para iniciar un seguimiento. . . 104

B.1 Pantalla inicial del Android Manager. . . . . . . . . . . . . . . . . . . . . 131B.2 Pantalla del Android Manager con todos los paquetes disponibles para

instalar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131B.3 Pantalla del Android Manager para instalar licencias. . . . . . . . . . . . 132B.4 Ventana para instalar el plugin ADT en Eclipse. . . . . . . . . . . . . . . 132B.5 Pantalla con los paquetes necesarios para instalar el plugin ADT. . . . . . 133B.6 Pantalla para aceptar las licencias de los paquetes del plugin ADT. . . . . 134B.7 Pantalla de Eclipse con las opciones del Android SDK instaladas. . . . . . 135B.8 Definición de la ubicación de la base de datos con usuario y contraseña. 136B.9 Pantalla inicial del cliente gráfico MySQL Navigator. . . . . . . . . . . . . 137B.10 Pantalla de creación de la tabla de alertas MyAlerts. . . . . . . . . . . . . 138B.11 Pantalla de creación de la tabla de coordenadas MyCoordinates. . . . . . 139B.12 Base de datos Alcatraz con sus dos tablas: MyAlerts y MyCoordinates. . . 140

6

LISTA DE TABLAS

2.1 Códecs de audio y protocolos soportados en Asterisk. . . . . . . . . . . . 252.2 Versiones de Android. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

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

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

7

LISTA DE TABLAS

8

1Introducción

EN LOS ÚLTIMOS AÑOS, la utilización de la VoIP ha tenido un gran crecimiento en elámbito de las telecomunicaciones, pasando de ser algo lejano a ser una tecnología

utilizada a diario. Sus múltiples características y ventajas son las que nos inspiraronpara realizar este proyecto, aunque los objetivos del mismo fueron cambiando yampliándose a medida que avanzaba el proyecto.

La idea principal era realizar un proyecto basado en VoIP, cosa que se ha mantenidoa lo largo de todo el desarrollo. En principio, se empezó con el estudio de Asteriskcon la idea de desarrollar una centralita telefónica, por ejemplo, para una empresa yutilizarla como punto de partida. Al estudiar las posibilidades de Asterisk se decidiórealizar un cambio de dirección y crear algo que pudiera aprovechar el trabajo yarealizado. Fue entonces cuando se decidió implementar una aplicación Android queutilizara la VoIP, como un softphone. Una vez terminada la aplicación, se pensó enconseguir un valor añadido para el mismo, que acabara de redondear el proyecto yque unificara la idea de la centralita con el softphone realizado.

Como últimamente casi todas las aplicaciones Android utilizan de una forma u otrala ubicación del usuario, se decidió que el valor añadido de las aplicaciones estaríarelacionado con el sensor GPS del smartphone. Para ello se enfocó el proyecto a unhipotético caso real: una residencia de ancianos. Algunas residencias y centros dedía permiten a sus residentes salir a pasear o a comprar por sus alrededores. Comoalgunos de ellos pueden perderse o desorientarse una vez en el exterior, se deseamantener su ubicación controlada cuando se alejan demasiado de la residencia.

Así es como se consiguió el proyecto final: una plataforma de VoIP diseñada espe-cialmente para su utilización en una residencia de ancianos. La centralita realizadaen Asterisk se convirtió en la centralita de la residencia de ancianos. Por último, apartir del softphone inicial, se crearon dos softphones con distintas características: uno

9

CAPÍTULO 1. INTRODUCCIÓN

diseñado para los residentes del centro y el otro diseñado específicamente para lostrabajadores, concretamente para el personal de la recepción.

Los objetivos finales son:

* Implantación de Asterisk.

* Centralita Asterisk con reconocimiento de voz para utilizar en la residencia deancianos. Se le añaden servicios de valor añadido como son: buzón de voz,música en espera, etc.

* Softphone para los residentes: softphone con un sistema de alertas de posi-cionamiento y de batería baja.

* Softphone para la recepción del centro: softphone con un sistema que permitagestionar las alertas generadas por los residentes.

* Implantación de una base de datos LAMP para los sistemas de alertas.

Hoy en día, el sector de las telecomunicaciones es un mundo de evolución rápiday constante. Nuevas ideas y tecnologías salen al mercado en intervalos de tiempomuy cortos. El desarrollo open source es mucho más capaz de adaptarse a los rápidoscambios tecnológicos, lo que le proporciona una enorme ventaja competitiva. Por esemotivo, todo el proyecto está basado en tecnología open source.

1.1 PLATAFORMA DE VOIP

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

* Asterisk: se utiliza como servidor de VoIP (protocolo SIP) y servidor de media. EnAsterisk se implementa la centralita de telefonía que se utilizará para las llamadasentrantes a la residencia.

* LAMP: servidor y base de datos. Esta base de datos se utiliza para guardar yconsultar información sobre los residentes del centro (localización y estado de labatería del teléfono).

* Smartphones con sensor GPS: donde se instalan las aplicaciones desarrolladasen Android.

10

1.2. CASOS DE USO

FIGURA 1.1: Plataforma de VoIP implementada para la residencia.

La comunicación entre Asterisk y las aplicaciones instaladas en los smartphones serealiza mediante el protocolo SIP. Las aplicaciones y la base de datos se comunicanmediante HTML. Las aplicaciones realizan peticiones HTML contra Apache, que ejecutalos scripts PHP correspondientes, accediendo a la base de datos MySQL y devolviendolos resultados obtenidos en formato JSON. No existe comunicación entre Asterisk y labase de datos.

1.2 CASOS DE USO

Residente sale de la zona permitida

Cuando un residente se aleja demasiado de la residencia, la aplicación del residenterealiza de forma automática una llamada SIP (perdida) a una extensión especial deAsterisk. Entonces, Asterisk pone en contacto, mediante otra llamada SIP, al residentecon el softphone de recepción para informar del evento. A la vez, la aplicación delresidente empieza a enviar las coordenadas GPS del dispositivo a la base de datos.Cuando se cuelga la llamada, el softphone de recepción muestra un mapa de losalrededores de la residencia con la ubicación de los residentes que se encuentran fuerade la zona permitida. La información mostrada en el mapa se obtiene de la basede datos y se va actualizando de forma periódica. En caso de que el softphone de

11

CAPÍTULO 1. INTRODUCCIÓN

recepción esté ocupado y no se pueda atender la llamada, se muestra igualmente elmapa con las coordenadas.

Residente entra en la zona permitida

Cuando el residente vuelve a acercarse a la residencia, la aplicación del residenterealiza de forma automática una llamada SIP (perdida) a una extensión especial deAsterisk. Entonces, Asterisk pone en contacto, mediante otra llamada, al residentecon el softphone de recepción para informar del evento. A la vez, la aplicación delresidente deja de enviar sus coordenadas GPS.Cuando se cuelga la llamada, la aplicación de recepción muestra un mapa de losalrededores de la residencia. Si quedan residentes fuera de la zona permitida, sesiguen mostrando sus coordenadas en el mapa. Si era el único residente fuera de lazona, aparece un diálogo en la pantalla informando de que no hay ningún residenteque localizar.

Recepción pide un seguimiento

Desde la aplicación de recepción se puede solicitar la ubicación de un residente queno esté fuera de la zona permitida. Al hacer la petición, la aplicación de recepciónlanza una llamada a una extensión especial de Asterisk, especificando la identificacióndel residente que se quiere seguir. Entonces, Asterisk realiza una llamada perdida alsoftphone del residente, que sirve para que éste empiece a enviar sus coordenadasGPS a la base de datos. En el mapa de la aplicación de recepción se muestran tanto laubicación de este residente como las de los que están fuera de la zona permitida.Cuando se desea finalizar el seguimiento, la aplicación de recepción lanza unallamada a otra extensión especial de Asterisk indicando, igual que antes, el identi-ficador del residente. Entonces, Asterisk realiza una llamada perdida al softphonedel residente, que sirve para que éste deje de enviar sus coordenadas a la base de datos.

Alerta de batería baja

Cuando el smartphone del residente detecta que el nivel de batería está por debajo del15%, la aplicación registra este hecho en la base de datos. La aplicación de recepcióncomprueba, de forma periódica, la información sobre las alertas de batería en la basede datos. Si hay alguna, muestra un listado de los residentes que se encuentran en estasituación.

12

2Conceptos Generales

2.1 VOIP

2.1.1 ¿QUÉ ES LA VOIP?

VoIP (Voice Over Internet Protocol) se refiere a los protocolos de comunicación,tecnologías, metodologías y técnicas de transmisión involucradas en la transmisión decomunicaciones de voz y sesiones multimedia sobre redes IP.

La red de telefonía tradicional PSTN1 se basa en la conmutación de circuitos paraestablecer las comunicaciones y transportar la señal de voz y la señalización de unextremo al otro. Las redes IP, en cambio, están basadas en la conmutación de paquetes.Por tanto, para poder transportar la señal de voz sobre este tipo de redes, ésta debe serdigitaliza, codificada y empaquetada.

La utilización de la VoIP aporta múltiples ventajas, entre las cuales se destacan:

* Reducción significativa de costes de gestión, administración y mantenimiento alaprovechar la red IP. Llamadas gratuitas entre miembros de redes VoIP puras (sinenrutar llamadas a través de la PSTN).

* Los datos y la voz se integran en una misma infraestructura. No hay necesidad deutilizar redes diferentes para su transmisión.

* Posibilidad de transmitir más de una llamada sobre la misma línea telefónica.

* Ofrece servicios de valor añadido que suelen conllevar un cargo extra sobre laPSTN o que incluso no se encuentran disponibles en algunos países, como son laidentificación de llamada, el voicemail, las conferencias, etc.

1Public Switched Telephone Network

13

CAPÍTULO 2. CONCEPTOS GENERALES

* Proporciona total portabilidad. Mientras el usuario disponga de un teléfono quesoporte VoIP conectado a la red, puede estar siempre localizable, sin importar suubicación.

* Permite la integración con otros servicios disponibles en Internet, incluyendovideoconferencias, mensajería instantánea, etc.

Por otra parte, uno de los principales inconvenientes al utilizar conmutación depaquetes para VoIP es la dificultad de ofrecer QoS. La transmisión de voz tiene que seren tiempo real, por lo que es necesario que los paquetes lleguen de forma ordenada,sin pérdidas y garantizando una mínima tasa de transmisión (los retrasos superiores a150 milisegundos afectan a la conversación). Existen varios mecanismos que ayudana lograr estos objetivos, entre los que se encuentran: la supresión de silencios paraaprovechar mejor el ancho de banda, la compresión de cabeceras aplicando losestándares RTP/RTCP y la priorización de los paquetes que requieran menor latencia.

2.1.2 ARQUITECTURA

2.1.2.1 COMPONENTES FUNDAMENTALES DE UNA RED VOIP

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

* Terminales: teléfonos IP que pueden ser software o hardware.

– Hardware: terminales físicos con soporte VoIP nativo que pueden conectarsedirectamente a una red IP.

– Software: aplicaciones que simulan un teléfono con soporte VoIP. Puedencorrer sobre cualquier dispositivo que disponga de conexión a la red (orde-nadores, móviles, etc.).

* Servidor: provee el manejo y funciones administrativas para soportar el en-rutamiento de llamadas a través de la red. Este elemento recibe distintos nombresen función del protocolo de señalización que se utilice. En un sistema basado enH.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 telefonía fija tradicional. Actúa deforma transparente al usuario.

* Red IP: provee conectividad entre todos los terminales. La red IP puede ser unared IP privada, una Intranet o Internet.

14

2.1. VOIP

FIGURA 2.1: Principales componentes de una red VoIP.

2.1.2.2 TRANSMISIÓN DE LA VOIP POR LA RED

Los paquetes de VoIP se transmiten sobre la red IP utilizando el modelo TCP/IP conalgunas diferencias. Estas diferencias residen en los protocolos utilizados en cada capapor los paquetes de datos y los paquetes de VoIP. En algunas capas se utilizan losmismos para ambos; en otras, se utilizan protocolos propios para cada tipo.

A continuación se detallan las funciones de las cinco capas del modelo TCP/IP conlos protocolos utilizados en los paquetes de VoIP:

* Aplicación: Asegura la calidad y entregabilidad de los paquetes VoIP. Se utilizanlos siguientes protocolos:

– NTP: Network Time Protocol. Permite sincronización, lo que nos asegura quelas señales son transmitidas y recibidas en el margen de tiempo adecuadopara asegurar calidad.

– RTP: Real-time Transport Protocol. Proporciona funciones de transporte dered extremo-a-extremo para las señales de voz digitales encapsuladas en lospaquetes VoIP.

– RTCP: Real-time Transport Control Protocol. Monitoriza la entrega de lasseñales de voz y proporciona funciones mínimas de control para asegurar laentrega de los paquetes.

* Transporte: El protocolo UDP2 transporta los paquetes desde el origen al destino.2User Data Protocol

15


Aunque este protocolo no garantiza la entrega de los paquetes en destino, seutiliza porque es más rápido que TCP y en aplicaciones en tiempo real, como esla voz, se prioriza la velocidad por encima de la fiabilidad.

* Red: Se añade la dirección IP al paquete. Esta dirección es la que utilizan losdispositivos de enrutamiento para direccionar los paquetes durante la llamada yes única y propia de cada dispositivo (PC o teléfono IP).

* Interfaz: Se añade la dirección física MAC3 al paquete. Esta dirección se obtienede la tarjeta NIC4 del propio dispositivo.

* Física: Se convierten los paquetes en señales eléctricas o electro-ópticas paraque se puedan transportar por la red.

2.1.3 CÓDECS DE AUDIO

Los códecs5 son los medios por los cuales se puede convertir la señal de voz analógica adigital para poder transportarla por la red. Se pueden definir como modelos matemáti-cos usados para codificar y comprimir digitalmente información de audio analógica.La mayoría tienen en cuenta la capacidad del cerebro humano de interpretar lainformación recibida a pesar de que esté incompleta. Los algoritmos de compresión devoz se aprovechan de nuestra tendencia a interpretar lo que creemos que debemos oíren vez de lo que realmente oímos. El propósito de los algoritmos de codificación esencontrar un equilibrio entre eficiencia y calidad.

En VoIP se pueden utilizar una gran variedad de códecs de audio. La elección paracada caso varía en función de los requerimientos de calidad de sonido, ancho de bandanecesario y carga computacional. A continuación se enumeran y describen algunos delos más utilizados.

G.711 Códec fundamental de la PSTN estandarizado por la ITU en 1972. Tiene unafrecuencia de muestreo de 8 kHz y utiliza la modulación PCM6. Existen dosmétodos de compansión7: µ − law en América del Norte y Japón y a − law enel resto del mundo. La principal diferencia radica en el número de muestras

3Medium Access Control4Network Interface Card5Abreviatura de codificador – decodificador, aunque actualmente también se utiliza como abre-

viatura de compresor-decompresor.6Pulse Code Modulation.7Método aplicable a señales para mejorar la transmisión de las mismas en canales limitados. Está

formado por dos procesos: compresión y expansión.

16

2.1. VOIP

por palabra (de 8 bits) que se utilizan: 14 muestras (µ − law) y 13 mues-tras a − law. Ambos tienen un bit rate de 64 kbps. G.711 es el códec base delque derivan todos los demás y es el que conlleva una menor carga computacional.

G.729A Este códec presenta una calidad de sonido muy buena teniendo en cuentael poco ancho de banda que utiliza, sólo 8 kbps. Para ello utiliza el método decompresión de habla CS-ACELP8. Debido a patentes, este códec no se puede usarsin pagar una licencia. Además, la carga computacional de este algoritmo esbastante elevada.

GSM9 Este códec, que opera a 13 kbps, es el preferido de Asterisk. No requiere licenciay ofrece un gran rendimiento en relación a los requerimientos de CPU. La calidadde sonido se considera ligeramente peor que la obtenida con G.729A.

2.1.4 PROTOCOLOS

Los protocolos propios de las redes IP no fueron diseñados para soportar streamingen tiempo real. Los terminales de estas redes suelen esperar la recepción de paquetesperdidos, piden retransmisiones o simplemente los ignoran. Obviamente, la forma enla que hablamos es totalmente incompatible con la manera en que los protocolos deInternet transportan los datos: no se puede aceptar la pérdida de letras o palabras olos retrasos apreciables entre emisor y receptor.

El mecanismo para llevar a cabo una conexión de VoIP consta de una serie deintercambios de señalización entre los terminales (y gateways intermedios) queculminan en dos flujos de media continuos que transportan la conversación (uno paracada dirección). Manejar esto es el objetivo de los protocolos de VoIP. A continuaciónse definen los más relevantes y utilizados.

2.1.4.1 SIP10

Protocolo desarrollado por el IETF11 para establecer, modificar y terminar sesiones mul-timedia. Estas sesiones incluyen llamadas de voz y vídeo, conferencias multimedia, etc.

8Conjugate-Structure Algebraic-Code-Excited Linear Prediction. Método de compresión del hablaque consiste en enviar códigos correspondientes a los sonidos en vez del sonido muestreado real.

9Global System for Mobile Communications10Session Initiation Protocol11Internet Engineering Task Force

17


FIGURA 2.2: Trapezoide SIP.

SIP es un protocolo de señalización de la capa de aplicaciones diseñado espe-cialmente para ser independiente de la capa de transporte; puede funcionar con losprotocolos UDP y TCP indistintamente. Está basado en texto, con una sintaxis similara la de otras familias de protocolos como HTTP y SMTP. La premisa de SIP es que cadaterminal de una conexión es un par; se utiliza una estructura cliente/servidor basadaen un modelo de petición/respuesta para autenticar a sus usuarios.

Este protocolo utiliza el puerto 5060 para la señalización. No transporta medios(voz y/o vídeo) entre extremos, para ello se utiliza el protocolo RTP. Se necesitan dospuertos RTP para cada conexión (normalmente entre el 10.000 y el 20.000). Unatipología corriente para ilustrar la utilización de estos dos protocolos, conocida comoTrapezoide SIP, se puede observar en la figura 2.2. Cuando se desea realizar unallamada de A a B, el establecimiento de la llamada y toda su señalización se realiza através de servidores proxy mediante el protocolo SIP. En cuanto se inicia la llamada,los terminales se comunican directamente entre ellos (si es posible), utilizando elprotocolo RTP, para que los datos no consuman recursos de los proxys. Debido a estaseparación, SIP da problemas en infraestructuras de red con NAT12 y se suele necesitarun servidor STUN para solucionarlos.

Las ventajas de este protocolo residen en su gran nivel de aceptación y su arquitec-tura flexible. Actualmente, SIP ha reemplazado a H.323 como protocolo de elecciónpara la negociación del transporte VoIP.

2.1.4.1.1 EJEMPLO DE UNA COMUNICACIÓN SIP/RTPPara facilitar la comprensión del uso de los protocolos SIP y RTP en una comuni-

cación, se analiza a continuación una llamada telefónica entre dos clientes SIP. En este

12Network Address Translation. Proceso consistente en modificar la dirección IP de la información enlas cabeceras IP de los paquetes mientras están en transito a través de un dispositivo de enrutamientode tráfico.

18

2.1. VOIP

FIGURA 2.3: Tramas SIP y RTP de una llamada telefónica 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 deVoIP (IP 192.168.1.38). En la figura 2.3 se muestran las tramas más relevantes de estallamada.

* Tramas 1-4: se realiza la negociación inicial entre el llamante y el servidor. Elcliente 501 realiza una petición al servidor (INVITE) para iniciar una comuni-cación con el cliente 202. En esta petición se especifica también la informaciónde la sesión: tipo de medio que se transportará (audio), puerto (4002) y proto-colo (RTP), entre otros. El servidor confirma al cliente 501 la posibilidad de laconexión (OK) especificando a su vez la información de la sesión: audio, puerto11706 y protocolo RTP.

* Tramas 5-7: se realiza la negociación entre el servidor y el llamado. El servidorindica al cliente 202 que el cliente 501 quiere establecer una comunicación conél mediante otro INVITE con información de sesión: audio, puerto 14046 y pro-tocolo RTP. El cliente 202 recoge esta petición y cuando está preparado lo indicaal servidor comunicando su estado (Ringing). En este momento, el teléfono delcliente 202 empieza a sonar.

* Tramas 8-9: El cliente 202 descuelga el teléfono. Esto se indica al servidor me-diante un paquete (OK) con la información de la sesión: audio, puerto 4006 yprotocolo RTP. A partir de este momento, se inicia la conversación.

* Tramas 10-17: Estas tramas representan el intercambio de datos (audio) entre losdos terminales. Como se ha indicado antes, el protocolo utilizado para ello es elRTP.

19


* Tramas 18-21: El cliente 501 cuelga el teléfono, enviando al servidor una petición(BYE) para que comunique al cliente 202 que se va a finalizar la comunicación.El servidor confirma la petición al cliente 501 e informa al otro cliente de lafinalización de la comunicación, enviando otra petición (BYE) especificando elmotivo de la finalización (normal clearing).

2.1.4.2 H.323

Protocolo desarrollado por la ITU13 en 1996 como medio para transmitir comunica-ciones de voz, vídeo, datos y fax sobre redes IP manteniendo conectividad con la PSTN.Originalmente, fue diseñado para proporcionar un mecanismo de transporte IP paravideoconferencias y desde entonces ha evolucionado para cubrir todas las necesidadesde la VoIP. La señalización de llamadas está basada en el protocolo Q.391 de la ITU-Ty es adecuada para transmitir llamadas a través de redes utilizando una mezcla de IP,PSTN y ISDN.

H.323 es un protocolo relativamente seguro que no necesita elementos de seguri-dad adicionales a los requeridos por cualquier conexión vía Internet. Igual que SIP,utiliza el protocolo RTP para transportar las comunicaciones de medios y por tanto,presenta los mismos problemas en topologías de red con NAT. Uno de los factores desu poca popularidad reside en su complejidad.

2.1.4.3 IAX14

Protocolo abierto desarrollado por Digium con el propósito de establecer comunica-ciones entre servidores Asterisk. Pese a ello, IAX no está limitado sólo a Asterisk:cualquiera puede usarlo y es soportado por varios proyectos de telecomunicacionesopen source.

Su objetivo principal es minimizar el ancho de banda usado en las transmisiones dedatos, voz y vídeo sobre IP y proporcionar soporte nativo para ser transparente a NAT.Con ese fin, IAX multiplexa la señalización de canal y el flujo de datos sobre un únicostream UDP entre los extremos, utilizando el puerto 4569.

El protocolo IAX original ha quedado obsoleto en favor de su nueva versión, IAX2.Este permite la utilización de un gran número de códecs de audio y puede transportarcualquier tipo de datos. Además, está considerado uno de los protocolos más sencillos

13International Telecommunication Union14Inter-Asterisk eXchange

20

2.2. ASTERISK

para implementar en redes seguras.

2.2 ASTERISK

2.2.1 ¿QUÉ ES ASTERISK?

Asterisk es un software open source que implementa las funciones de una centraltelefónica PBX15. Este proyecto de comunicaciones fue creado en 1999 por MarkSpencer, miembro fundador de la compañía Digium, principal desarrolladora deAsterisk. Está publicado como open source bajo la licencia GNU GPL16. Aunqueoriginalmente fue diseñado para funcionar en Linux, también existen versiones paraotros sistemas operativos como BSD, Mac OS X, Solaris y Windows.

El proyecto Asterisk, en combinación con el proyecto de telefonía Zapata17, haevolucionado con los años, pasando de simplemente conectar llamadas de teléfonoa convertirse en una plataforma que puede manejar voz, vídeo y texto a través dedocenas de interfaces tanto físicos como virtuales.

El poder de Asterisk reside en su naturaleza customizable. Es muy flexible, dando alusuario la libertad de decidir lo que quiere implementar en función de sus necesidades.Separa las funcionalidades y características de varias PBXs en componentes que puedeninterconectarse de manera que cada usuario puede customizar su solución como mejorle convenga. Esto diferencia a Asterisk de otras soluciones corporativas cerradas queaportan una solución única, dejando muchas veces funcionalidades deseadas fuera.

Asterisk cuenta con toda una comunidad, liderada por Digium, que lo desarrolla ysoporta. Esta comunidad ha sido valorada como factor clave para en el crecimiento dela VoIP. Entre sus miembros se encuentran profesionales del ámbito de las telecomuni-caciones, de redes y de tecnologías de la información.

15Private Branch eXchange.16GNU General Public License.17Zapata Telephony Project: proyecto concebido por Jim Dixon, basado en la creación de sistemas

telefónicos más económicos utilizando tarjetas PCI con la electrónica básica para comunicarse con uncircuito de telefonía. En vez de tener componentes caros en la tarjeta, el procesado de la señal digital(DSP) se maneja en la CPU, por software. Fue la base para la creación del interfaz DAHDI, que seexplicará más adelante.

21


2.2.2 CONCEPTOS BÁSICOS

Canales

Los canales son las conexiones que realizan una llamada entrante o saliente a la PBXAsterisk. Cada llamada se realiza o recibe mediante un canal distinto. Asterisk nohace ninguna distinción entre ellos. Entre los canales soportados más importantes seencuentran: SIP, IAX2, H323, MGCP, Console y DAHDI.

Dialplan

El dialplan es el corazón de Asterisk. Todos los canales que llegan al sistema pasanpor el dialplan, que contiene los scripts de flujo de llamadas que determinan elmanejo de las llamadas entrantes y salientes. Está dividido en secciones llamadascontextos. Dentro de estos contextos encontramos las extensiones y la definición delas actuaciones o pasos que debe realizar el sistema al recibir una llamada para cadaextensión.

El dialplan puede escribirse de tres formas distintas: utilizando la sintaxistradicional de Asterisk (editanto extensions.conf); usando AEL18 (modificandoextensions.ael); o utilizando LUA (editando extensions.lua).

Contextos

Un contexto es, básicamente, una colección de extensiones. Cuando se crean canales,estos siempre deben ubicarse en un contexto. Esto implica que las llamadas originadasdesde ese canal se ubicarán en dicho contexto.El objetivo más importante de los contextos es ofrecer seguridad, evitando que lasdiferentes secciones del dialplan interactúen entre ellas. Los canales sólo podránrealizar llamadas hacia las extensiones incluidas en su contexto o acceder a funcionali-dades propias del mismo.

Existen dos contextos especiales: general (define configuraciones generales paratodos los contextos) y globals (contiene variables disponibles para todo el dialplan).

Extensiones

Al contrario que en los sistemas telefónicos convencionales, donde las extensionesse asocian a terminales, interfaces, menús, etc., en Asterisk las extensiones seasocian a un listado de instrucciones a ejecutar. Estas instrucciones pueden tantollamar a un número de teléfono como acceder al buzón de voz o cualquier otra función.

18Asterisk Extension Logic

22

2.2. ASTERISK

FIGURA 2.4: Arquitectura modular de Asterisk.

Cada paso o instrucción dentro de una extensión se compone de tres componentes:nombre (o número) de la extensión; prioridad (cada extensión puede incluir variospasos, el numero de paso se llama prioridad); la aplicación (o instrucción) que se debeejecutar en cada paso. Por tanto, la forma de definir una instrucción en el dialplan esla siguiente:exten⇒ name, priority, application().

2.2.3 ARQUITECTURA

Asterisk está formado por un conjunto de bloques o módulos que el usuario tienea su disposición para crear aplicaciones de comunicación. Por este motivo se hacereferencia a Asterisk con los términos tool-kit o plataforma de desarrollo.

Estos módulos son componentes que proporcionan una funcionalidad específica,por ejemplo, un driver para un canal o un recurso que permite la conexión con unatecnología externa. Estos pueden añadirse al sistema en función de las necesidadesdel usuario/desarrollador. Los módulos que se quieran utilizar suelen definirse en elmomento de la instalación, aunque también pueden añadirse a posteriori, especificán-dolos en el archivo de configuración adecuado.

En la figura 2.4 se representan los tipos de módulos que se pueden encontrar enAsterisk. A continuación se incluye un listado con una breve descripción de cada unode 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 ejem-plo: marcar un número, transferir una llamada, acceder al buzón de voz, etc.

* Bridging modules: Realizan bridging de canales en la nueva Bridging API. Cadauno proporciona funcionalidades diferentes, dependiendo de las necesidades delcanal.

* CDR modules (Call Detail Recording): Diseñados para facilitar tantos métodosde guardar detalles de las llamadas como sea posible. Estos detalles puedenguardarse en un archivo (por defecto), una base de datos, RADIUS o syslog.

* CEL modules (Channel Event Logging): Proporcionan control sobre los informes deactividad de una llamada. El uso de estos módulos requiere una planificación deldialplan más cuidadosa.

* Channel drivers: Necesarios para realizar llamadas. Cada driver es específico parael protocolo o tipo de canal que soporta (SIP, IAX2, ISDN, DAHDI, etc.). Estemódulo actúa como un gateway con el núcleo de Asterisk. La lista de protocolossoportados por Asterisk se puede ver en la tabla 2.1.

* Codec translators: Permiten la conversión de formatos de streams de audio entrellamadas. Por ejemplo: convertir una llamada que proviene de una canal queutiliza G.711 a otro que utiliza el códec G.729. El listado de códecs que Asterisksoporta se puede ver en la tabla 2.1.

* Format interpreters: Realizan la misma función que los codec translators pero enarchivos, en vez de canales. Por ejemplo: cambiar el formato a una grabación deun menú en GSM para que se pueda reproducir en un canal que no soporte esteformato.

* Dialplan functions: Complementan a las aplicaciones del dialplan. Proporcionanmejoras para diversas funcionalidades de Asterisk, como el manejo de cadenas,conectividad a bases de datos, acceso a la blacklist, etc.

* PBX modules: Módulos periféricos que proporcionan mecanismos de control yconfiguración mejorados.

* Resource modules: Integran a Asterisk con recursos externos. Por ejemplo: permi-tir la operatividad con bases de datos ODBC, la utilización de la música en espera,grabar una llamada, etc.

* Addons modules: Módulos desarrollados por la comunidad con usos o derechosde distribución diferentes de los del código principal. Figuran en un directoriodiferente y no se compilan e instalan por defecto.

24

2.2. ASTERISK

TABLA 2.1: Códecs de audio y protocolos soportados en Asterisk.

G.711 (a-law y u-law), G.726, G.723.1, G.729A, GSM, iLBC, Speex,Códecs de audio

ADPCM, Linear, MP3Protocolos SIP, H.323, IAX e IAX2, MGCP, SCCP, UNISTIM

* Test modules: Se utilizan por el equipo de desarrollo de Asterisk para validarcódigo nuevo. Están cambiando y añadiéndose nuevos de forma constante.

2.2.3.1 SERVICIOS Y FUNCIONALIDADES QUE OFRECE

Como se ha comentado anteriormente, Asterisk permite la implementación de losmismos servicios que una PBX clásica, añadiendo nuevas funcionalidades. Se puedecolocar delante de una PBX convencional para que actúe como gateway, o detrás deella, para utilizarlo como servidor de aplicaciones periférico.

Algunos de los servicios que ofrece se listan a continuación:

* Manejo de llamadas entrantes y generación de llamadas salientes.

* Buzón de voz.

* Música en espera (desde archivos o desde emisoras de radio por Internet).

* Gestión de colas de llamadas entrantes.

* Transferencia y desvío de llamadas.

* Salas de conferencia con dos o más usuarios.

* Gestión de listas negras.

* Grabación y monitorización de llamadas en curso.

* Implementación de AA (Automatic Attendants) y IVR (Interactive VoiceResponse).

* Manejo de llamadas externo en cualquier lenguaje de programación o scripting através de AGI (Asterisk Gateway Interface).

* Notificación de eventos e integración CTI vía AMI (Asterisk Manager Interface).

* Integración con bases de datos y servicios web.

25


* Sintetización del habla (text-to-speech) en varios idiomas y dialectos utilizandoprogramas de terceros.

* Reconocimiento de voz en varios idiomas usando motores de reconocimiento devoz de terceros.

2.2.4 INTEGRACIÓN CON LA RED CONMUTADA DE TELEFONÍA

Asterisk es capaz de comunicarse con diferentes tecnologías. Normalmente, estacomunicación se efectúa mediante conexiones de red. Sin embargo, conexiones contecnologías mas tradicionales, como la red conmutada de telefonía, requieren unhardware específico.

2.2.4.1 TARJETAS ANALÓGICAS

Las tarjetas analógicas permiten conectar el servidor Asterisk con la red conmutada detelefonía y/o con teléfonos analógicos. Existen dos tipos:

* FXO (Foreign eXchange Office): permiten interactuar con los portadores de la redde telefonía.

* FXS (Foreign eXchange Station): permiten interactuar con teléfonos analógicos.

Las tarjetas analógicas diseñadas por Digium reciben el nombre de TDM y puedeninteractuar tanto con líneas externas como con teléfonos analógicos en función delos módulos presentes en la tarjeta. Al inspeccionar visualmente estas tarjetas, sediferencian los tipos de módulos 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 clasede tarjetas se encuentran dos tipos:

* Básicas (BRI): cada puerto BRI tiene dos canales de voz más uno de señalización,permitiendo mantener dos conversaciones de forma simultánea.

* Primarios (PRI): cada primario tiene 30 canales de voz más uno de señalización,permitiendo establecer unas 30 conversaciones simultáneas.

En un sistema Asterisk que requiera el uso de estas tarjetas para conectarse a la redtelefónica será necesaria la instalación de:

26

2.3. ANDROID

* DAHDI19: Interfaz utilizado para controlar una gran cantidad de tarjetas analógi-cas y/o digitales.

* LibPRI: librería que implementa señalización para ISDN-PRI e ISDN-BRI, nece-saria para las tarjetas digitales.

2.3 ANDROID

2.3.1 ¿QUÉ ES ANDROID?

Android es un sistema operativo basado en Linux para dispositivos móviles comosmartphones y tablets. Está desarrollado por la Open Handset Alliance20, encabezadapor Google. Inicialmente desarrollado por Android, Inc., fue comprado por Google en2005 como parte de su estrategia para entrar en el mercado de los móviles.

Su código está publicado bajo la licencia de código abierto Apache, por lo quecualquiera que quiera trabajar con Android puede descargarlo y editarlo. Esta cualidadhace de Android un producto muy atractivo, ya que permite competir con el grandespliegue 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 navegarpor los distintos menús y aplicaciones del terminal de forma sencilla, sin necesidad derecurrir 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.2se recogen las principales.

Para la realización de este proyecto se ha escogido la versión 2.3.3 (Gingerbread) yaque, al inicio del proyecto, es la que tenía una mayor distribución entre los terminalesAndroid.

2.3.1.1 ARQUITECTURA

El sistema operativo Android está dividido en cinco secciones distribuidas dentro decuatro capas principales representadas en la figura 2.5.

19Digium Asterisk Hardware Device Interface20Open Handset Alliance: consorcio de 86 compañías en los sectores de hardware, software y teleco-

municaciones, dedicados a fomentar estándares abiertos para los dispositivos móviles.

27


TABLA 2.2: Versiones de Android.

Versión Nombre Nivel API1.5 Cupcake 31.6 Donut 42.1 Eclair 72.2 Froyo 8

2.3 - 2.3.2 Gingerbread 92.3.3 - 2.3.7 - 10

3.1 Honeycomb 123.2 - 13

4.0 - 4.0.2 Ice Cream Sandwich 144.0.3 - 4.0.4 - 15

4.1.x Jelly Bean 164.2.x - 174.3 - 184.4 KitKat 19

* Linux Kernel: kernel en el que se basa Android. Esta capa contiene todos losdrivers de bajo nivel para los componentes hardware de un terminal.

* Librerías: contiene todo el código que proporciona las características principalesdel SO Android.

* Android Runtime: Contiene una conjunto de librerías que permiten a los desarro-lladores escribir aplicaciones Android usando el lenguaje Java. También incluyela máquina virtual Dalvik, que está diseñada y optimizada específicamente paraterminales Android.

* Application Framework: expone las diversas capacidades del SO Android a losdesarrolladores para que puedan utilizarlas en sus aplicaciones.

* Aplicaciones: todas las aplicaciones instaladas en un terminal: aplicaciones in-cluidas en el propio terminal (teléfono, contactos, navegador, etc.), aplicacionesdescargadas e instaladas a través de Google Play (antiguo Android Market) yaplicaciones desarrolladas por el propio usuario.

2.3.1.2 APLICACIONES

Las aplicaciones Android se escriben en lenguaje Java. Las herramientas Android SDKcompilan el código, junto con los datos y archivos necesarios, en un paquete Android(archivo con extensión .apk). Este archivo es lo que utilizan los dispositivos Android

28

2.3. ANDROID

FIGURA 2.5: Esquema de la arquitectura del sistema Android.

para instalar la aplicación.

El sistema Android implementa el principio del mínimo privilegio. Es decir, cadaaplicación tiene acceso sólo a los componentes que requiere para ejecutarse y a nadamás. Esto crea un entorno seguro en el que una aplicación no puede tener acceso apartes del sistema para el que no tenga permisos.

2.3.1.2.1 ANATOMÍA DE UNA APLICACIÓN

La estructura de una proyecto para una aplicación Android está formada por lassiguientes carpetas:

* src: contiene todos los archivos de código .java.

* Android 2.3.3 library: contiene el archivo android.jar donde se encuentran to-das las librerías 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 compi-lación.

* assets: contiene todos los bienes de la aplicación: HTML, archivos de texto, basesde datos, etc.

* res: contiene todos los recursos de la aplicación: imágenes, layouts, strings, etc.En la carpeta res/layout se encuentran los archivos XML, donde se definen lasIUs de las distintas actividades de la aplicación.

* AndroidManifest.xml: archivo muy importante que contiene información deta-llada de la aplicación. En él se especifican varios aspectos de la misma: lospermisos, las actividades involucradas y los intent-filters, entre otros.

2.3.1.2.2 ANDROID MANIFEST

Toda aplicación debe tener un archivo con el nombre AndroidManifest.xml. Enél se define la información detallada sobre la aplicación que el sistema Android debetener antes de poder ejecutar cualquier código de la misma.

Los aspectos más importantes que deben especificarse en el AndroidManifest son:

* Nombre del paquete Java para la aplicación.

* Nivel mínimo de la API Android que la aplicación requiere para ejecutarse.

* Descripción de todos los componentes de la aplicación: actividades, servicios,broadcast receivers y content providers. Para cada componente se especifica: elnombre de la clase que los implementa y lo que pueden hacer.

* Permisos que requiere la aplicación para acceder a partes protegidas de la API einteractuar con otras aplicaciones.

* Aspectos de hardware y software usados o requeridos por la aplicación.

* Librerías que la aplicación necesita (aparte de las propias del framework deAndroid).

30

2.3. ANDROID

2.3.2 ACTIVIDADES

La actividad es el componente fundamental de la mayoría de aplicaciones Android. Elconcepto de actividad va ligado a la idea de interfaz de usuario (IU). Cada actividadnos muestra una interfaz de usuario y nos permite interactuar con ella, programandoel comportamiento de la aplicación según la interacción del usuario.

Una aplicación consiste, normalmente, en varias actividades relacionadas de algunamanera entre ellas. Para completar la aplicación se pueden utilizar otros componentescomo los servicios, los broadcast receivers, etc. Aunque no es común, si la aplicaciónno requiere de intervención por parte del usuario, puede no tener ninguna actividad.

2.3.2.1 CICLO DE VIDA DE UNA ACTIVIDAD

La clase Actividad define una serie de métodos imprescindibles que gobiernan su ciclode vida y cuya implementación es crucial para desarrollar aplicaciones flexibles yrobustas.

El ciclo de vida de una actividad y los métodos que lo definen pueden observarse enla figura 2.6.

* onCreate(): se llama cuando una actividad se crea por primera vez. Aquí sedeben inicializar los componentes esenciales de la actividad, así como especificarel layout que se usará como IU. Este método también recupera el estado previode la actividad, en caso de haber sido guardado en una ejecución 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 activi-dad anterior. En este estado la actividad actual sigue viva, mantiene su estadoy su información, pero puede destruirse por el sistema en caso de problemas dememoria. Aquí se debe guardar cualquier cambio que se haya hecho y que sequiera conservar, en caso de que la actividad sea destruida. También se debendetener animaciones u otras cosas que puedan consumir CPU.

* onStop(): se llama cuando la actividad deja de ser visible por el usuario. En esteestado, igual que onPause(), el sistema puede destruir la actividad en caso denecesitar 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 puedeocurrir de forma voluntaria (desde la propia programación de la aplicación) o deforma involuntaria (cuando el sistema necesita conservar memoria).

* onRestart(): se llama cuando la actividad se había parado y es reanudada denuevo.

2.3.3 INTENTS

El intent es un concepto único y muy importante en Android. Se puede definir comouna declaración de necesidad, una descripción abstracta de una operación que sequiere realizar. Se utiliza principalmente para: lanzar una actividad/servicio/broadcastreceiver o hacer que una actividad/servicio existente haga algo nuevo.

32

2.3. ANDROID

En función de las necesidades del usuario, los objetos de tipo Intent puedenutilizarse para pasar información necesaria al componente que los recibe o al sistemaAndroid.

Los parámetros principales son los siguientes:

* component name: nombre del componente que recibirá el intent (componenteque se quiere lanzar).

* action: descripción de la acción que se quiere realizar.

* data: la información requerida para realizar la acción, expresada en forma de Uri.

* extras: pares de tipo key/value para pasar información adicional al componenteque recibirá el intent.

Por otra parte, el intent filter sirve para especificar los tipos de intents que uncomponente puede recibir. Estos filtros no se definen en el código, sino en el AndroidManifest. Los parámetros principales son: action, category y data.

Todas las categorías añadidas a un objeto Intent tienen que coincidir con el IntentFilter para que el componente deseado pueda ser invocado.

2.3.4 INTERFAZ DE USUARIO

Una actividad, por si misma, no tiene presencia en la pantalla, sino que debe dibujarlos 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 suscomponentes. Dependiendo de las necesidades del usuario, la IU puede programarsedinámicamente, en tiempo de ejecución.

2.3.4.1 COMPONENTES DE LA PANTALLA

2.3.4.1.1 VISTAS

Una vista es un widget que tiene presencia en la pantalla. Una ViewGroup propor-ciona el layout en el que se ordenan todas las vistas que aparecen en la pantalla de unaactividad. A través de las vistas, el usuario es capaz de interactuar con la actividad.

Las vistas más 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 más comunes y los dos tiposde menús existentes.

* Button: representa un botón pulsable. Al pulsar, se ejecuta la acción que se lehaya programado.

* ToggleButton: botón con dos estados (on/off) que se muestran con un indicadorde luz.

* ListView: muestra una lista de elementos.

El aspecto de la mayoría de estas vistas se puede observar en la pantalla mostradaen la figura 2.7.

2.3.4.1.2 LAYOUTS

Los layouts son la arquitectura de la IU en una actividad: definen la estructura de lapantalla y la posición de los elementos que la componen (vistas).

Los layouts más comunes son:

* Linear Layout: organiza las vistas en un sola fila o columna.

34

2.3. ANDROID

* Table Layout: agrupa las vistas en forma de tabla (filas y columnas).

* Relative Layout: permite especificar la posición de las vistas en relación a otras oal propio layout.

En la práctica, es común combinar varios layouts en un sola actividad para diseñarla apariencia deseada para la IU.

No todos los componentes de la interfaz de usuario deben construirse medianteobjetos View y ViewGroup. Dentro de una aplicación, Android proporciona varioscomponentes que tienen un layout estándar predefinido de manera que el usuario sólonecesita definir su contenido, sin preocuparse de la forma. Entre estos componentes seencuentran: los menús, los diálogos y las notificaciones.

2.3.4.2 MENÚS

Los menús se utilizan en las actividades para mostrar opciones adicionales que no seven directamente en la IU. En Android nos encontramos con dos tipos:

* Options menu: muestra opciones relacionadas con la actividad actual. En la ver-sión de Android 2.3 o inferior, este menú se muestra en la parte baja de la pantallaal pulsar la tecla MENU del terminal. A partir de la versión 3.0, estas opcionesse muestran en la Action Bar, que es una barra situada permanentemente en laparte 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 específica de la activi-dad. Este menú se activa al mantener pulsada una vista de la IU. Aparece comouna lista flotante de opciones en la pantalla. Se puede definir un context menudiferente para cada elemento de la IU.

El aspecto de estos menús se puede observar en la pantalla mostrada en la figura 2.7.

2.3.4.3 DIÁLOGOS

Un diálogo es una ventana pequeña que aparece al frente de la actividad actual. Losdiálogos interrumpen la actividad para notificar algo al usuario o para realizar algunastareas relacionadas con la actividad en curso.

Los tipos más utilizados son:

* Alert Dialog: se usa desde las actividades para obtener una confirmación delusuario antes de ejecutar una acción.

35


* Progress Dialog: se usa para mostrar algún progreso relativo a la actividad, comopor ejemplo, el estado de una descarga.

2.3.4.4 NOTIFICACIONES

Las notificaciones se utilizan para informar al usuario de un evento ocurrido en laaplicación. Algunas notificaciones pueden ser simplemente avisos, otras puedenrequerir una interacción por parte del usuario.

Los tipos de notificaciones más utilizados son:

* Toast Notification: un mensaje en forma de pop up que aparece en la pantalladurante unos segundos. Esta notificación no acepta ningún tipo de interacciónpor parte del usuario.

* Status Notification: aparece en la barra de estado del sistema, en la zona marcadacomo Notificaciones. Muestra un icono y un mensaje. Su aparición puedeindicarse mediante una alerta sonora o de vibración. Si se necesita que el usuariorealice una acción, se puede programar el lanzamiento de un intent al pulsarsobre el mensaje.

2.3.5 SERVICIOS

Un servicio es un componente de la aplicación que corre en background, sin necesidadde interactuar con el usuario. Se utiliza para aplicaciones que necesiten realizar opera-ciones sin mostrar una interfaz de usuario, por ejemplo, la descarga de contenidos deuna página web.

Un servicio puede ser de dos formas:

* Started: cuando un componente de la aplicación lanza el servicio con el métodoStartService(). Al iniciar el servicio, éste corre indefinidamente, incluso si se cierrala aplicación que lo había iniciado. Al finalizar la tarea requerida, se debe detenerel servicio lo antes posible para liberar los recursos que esté utilizando.

* Bound: cuando uno o más componentes de la aplicación se enlazan con el ser-vicio. Un bound service permite a los componentes interactuar con el servicio,utilizando sus métodos públicos. Este tipo de servicio sigue corriendo hasta queno hay ningún componente enlazado a él.

Como en el caso de este proyecto, puede crearse un servicio que combine estos dostipos: inicializado por un componente y con varios componentes enlazados.

36

2.3. ANDROID

2.3.6 BROADCAST RECEIVERS

Un broadcast receiver es un componente de la aplicación que permite recibir eventosemitidos u originados por el sistema y/o por otras aplicaciones. Estos avisos se recibenen forma de intents.

Normalmente, este componente se utiliza como una puerta hacia otros compo-nentes y se pretende que haga el mínimo trabajo posible: recibe el evento y activaotro componente para que lo maneje. Aunque la aplicación no esté funcionando, elbroadcast receiver puede continuar escuchando por si llegan nuevos eventos.

2.3.7 PERSISTENCIA DE DATOS

Android proporciona diversas opciones para guardar datos de la aplicación. La opciónque se escoja dependerá de las necesidades que se tengan (si los datos deben serprivados o accesibles para otras aplicaciones) y del tamaño requerido.

2.3.7.1 SHARED PREFERENCES

Esta opción consiste en un mecanismo ligero que permite guardar datos simples dela aplicación, por ejemplo, las preferencias de usuario. El objeto SharedPreferencesguarda, de forma automática, en un archivo XML, los datos que se especifiquen conel formato de pares key/value. Estos datos persisten aunque se finalice la aplicación(tanto de forma manual como forzada por el sistema).

2.3.7.2 BASE DE DATOS LOCAL

Android ofrece también la posibilidad de guardar información en una base de datos,usando el sistema SQLite database. Esta base de datos local es propia de cada aplicacióny, por tanto, es accesible desde cualquier clase de la misma, pero no desde fuera de laaplicación.

La base de datos local puede crearse en tiempo de ejecución (como es el casode este proyecto) o en la etapa de diseño de la aplicación. Para esto último existenherramientas como el SQLite Database Browser.

37


2.3.8 LBS (LOCATION BASED SERVICES)

La aparición de los GPS en los smartphones ha propiciado una demanda de serviciosrelacionados con este dispositivo. Con este fin, Google permite la utilización de suprograma Google Maps para mostrar mapas y datos relacionados en las aplicacionesAndroid.

Android, por su parte, proporciona una serie de herramientas de localizaciónque permiten obtener datos de posicionamiento que el usuario puede utilizar segúnconvenga: mostrar en mapas, alertas de posición, etc.

Las principales funciones que se pueden realizar con los LBS en Android son lassiguientes:

* Mostrar mapas, navegar por ellos, hacer zoom y cambiar de vista (satélite, calle-jero, tráfico).

* Navegar a una localización específica.

* Obtener la localización pulsada en un mapa.

* Geocoding y geocoding inverso.

* Añadir objetos que se dibujen encima del mapa, como por ejemplo, marcadores oletreros.

* Obtener datos de localización del terminal de distintos proveedores: receptorGPS, red de telefonía y red WiFi.

* Determinar la localización del terminal y obtener actualizaciones periódicas de lamisma.

* Monitorizar una localización: mediante alertas de proximidad, puede progra-marse el comportamiento de una aplicación al acercarse o alejarse de una locali-zación 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 estándar.

38

3Implementación de la Centralita

3.1 OBJETIVO

COMO SE HA COMENTADO en la introducción de este documento, uno de los ob-jetivos del proyecto es la implantación de un sistema de telefonía VoIP con la

implementación de una centralita telefónica para la residencia de ancianos. Para ellose ha escogido Asterisk, ya que permite, de forma sencilla, construir una PBX en unordenador convencional.

3.2 ENTORNO DE SIMULACIÓN

LA IMPLEMENTACIÓN del sistema de VoIP y la PBX de la residencia se realiza en unentorno de simulación donde se ejecutarán todas las pruebas necesarias para com-

probar su correcto funcionamiento. En la figura 3.1 se puede observar un esquema deeste entorno, que consta de los siguientes elementos:

* Un ordenador convencional con sistema operativo Ubuntu 10.04 que se utilizacomo servidor con la IP pública 147.83.39.132.

* Una tarjeta Digium TDM808 que se utiliza para conectar Asterisk a la red detelefonía. En este caso, la tarjeta se conecta a Ibercom, que es una red privadavirtual de Movistar utilizada en el ámbito de las comunicaciones de empresa.

* Dos cables de teléfono que conectan los puertos 1 y 2 de la tarjeta con las exten-siones internas 17479 y 17480 de la red Ibercom.

* Un teléfono analógico conectado a la extensión interna 54081 que se utiliza paracomprobar el funcionamiento de la PBX.

39

CAPÍTULO 3. IMPLEMENTACIÓN DE LA CENTRALITA

FIGURA 3.1: Esquema del entorno de simulación.

3.3 INSTALACIÓN DEL ENTORNO

EL PRIMER PASO PARA LA IMPLEMENTACIÓN de la centralita es instalar el software yhardware 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 solamenteVoIP, con el paquete Asterisk tendríamos suficiente. En este caso, al disponer de unatarjeta para conectar con la red de telefonía, debemos instalar los controladores deharware de DAHDI. Además, también instalamos la librería para puertos primarioslibPRI. Aunque de momento no se desea conectar con una red RDSI, se recomienda suinstalación antes que Asterisk por si se quiere utilizar en un futuro.

Las últimas versiones estables de estos paquetes se pueden encontrar y descargardesde la página web oficial de Asterisk: http://www.asterisk.org/downloads. En laultima actualización 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

http://www.asterisk.org/downloads

3.3. INSTALACIÓN 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 instalación se pueden ver en el anexo A.1.

Además de estos paquetes básicos, también se instalarán otros que servirán paraañadir 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 analógica.

* SSMTP, un gestor de correo electrónico para utilizar con el buzón de voz.

* CMUSphinx, un programa de reconocimiento de voz para integrar en el fun-cionamiento de la centralita.

* SFLphone, un softphone para poder hacer las simulaciones.

3.3.1 TARJETA DIGIUM TDM808

Para comunicar Asterisk con la red de telefonía se instala en el servidor una tarjetaanalógica de Digium, la TDM808. Las tarjetas de la serie 800 soportan hasta ochoconexiones por tarjeta utilizando sus ocho puertos. Estos puertos pueden tener dostipos de interfaces diferentes y se distinguen visualmente por su color: FXO (rojo) yFXS (verde). La TDM808 está compuesta por ocho módulos rojos, de tipo FXO.

Después de instalar la tarjeta, se comprueba el listado de los dispositivos detecta-dos por el bus PCI para ver si la tarjeta es detectada correctamente con el siguientecomando:

> lspci -n

La detección de la tarjeta se confirma al aparecer en el listado un dispositivo con elidentificador de Digium d161 seguido del identificador de la tarjeta 800.

07:04.0 0200: d161 :0800 (rev 11)

3.3.2 CANCELADOR DE ECO OSLEC

Por defecto, el cancelador de eco software para las líneas analógicas que manejaDAHDI es el mg2. Dado que el rendimiento del cancelador por defecto no esdemasiado bueno, se decide utilizar Oslec en su lugar. Oslec es un cancelador deeco de línea open source de alto rendimiento que, aunque no viene incluido en elpaquete DAHDI, se puede integrar de forma fácil para que funcione con DAHDI. Acontinuación se detallarán los pasos a seguir para instalar Oslec en el sistema. La

41


posterior configuración e integración con DAHDI se explicará más adelante. Los pasosseguidos para su instalación se pueden observar en el anexo A.1.5.

3.3.3 GESTOR DE CORREO

SSMTP es un programa que sirve para enviar correos electrónicos desde un ordenadorlocal a un host de correo configurado (mailhub). Uno de sus principales usos es elreenvío de correos electrónicos automatizados desde el ordenador a una dirección decorreo externa.

Este programa se utiliza con la funcionalidad de buzón de voz de Asterisk. Alconfigurar las cuentas de buzón de voz, se especifica una dirección de correo elec-trónico para cada usuario. Al dejar un mensaje en el buzón de voz, se envía de formaautomática un correo electrónico a esa dirección para avisar al usuario de que tieneun mensaje nuevo. Este correo incluye además un archivo de audio adjunto con elmensaje de voz.

Para instalar SSMTP en el servidor, se utiliza el gestor de paquetes Synaptic incluidoen el sistema operativo.

3.3.4 RECONOCIMIENTO DE VOZ

El menú principal de la centralita permite la introducción de la extensión deseadapor dos medios distintos: teclado del teléfono y reconocimiento de voz. Comose ha comentado anteriormente, Asterisk no incluye ninguna herramienta para elreconocimiento de voz, pero permite la utilización de motores de reconocimiento deterceros. Por este motivo se utiliza en el servidor el proyecto CMUSphinx.

CMUSphinx es un toolkit de reconocimiento de voz que incluye varias herramientaspara construir aplicaciones de reconocimiento. De estas herramientas sólo se utilizarándos: Pocketsphinx (librería de reconocimiento) y Sphinxbase (librería de soporte). Lospaquetes necesarios para instalar estas librerías se pueden descargar desde la páginadel proyecto: http://cmusphinx.sourceforge.net/. La instalación de estas libreríasse puede observar en el anexo A.1.6.

3.3.5 SOFTPHONE

Un softphone es un programa que simula el comportamiento de un teléfono y quese utiliza para realizar llamadas VoIP desde un ordenador. En este proyecto se ha

42

http://cmusphinx.sourceforge.net/

3.4. CONFIGURACIONES

utilizado para simular a los diversos usuarios conectados al servidor Asterisk.

Se escoge el softphone SFLphone para Linux, principalmente, porque es de códigoabierto y dispone de una comunidad muy activa, facilitando así la resolución decualquier duda o problema que pueda surgir. Además, permite la utilización demecanismos de securización (como SRTP) por si se quieren añadir en un futuro. Parainstalarlo en el servidor, se utiliza el gestor de paquetes Synaptics.

3.4 CONFIGURACIONES

CON TODO LO NECESARIO instalado en el servidor, ya se pueden realizar las configu-raciones necesarias que permitirán 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 lasllamadas procedentes del exterior).

3.4.1 TARJETA DIGIUM Y CANCELADOR DE ECO OSLEC

El primer paso para poder poner la PBX en funcionamiento es la configuración delentorno para poder comunicar el servidor con el mundo exterior (la red de telefonía).Con ese fin, hay que configurar el interfaz DAHDI para que trabaje con la tarjetainstalada y con el cancelador de eco Oslec.

Sabiendo que el servidor detecta correctamente la tarjeta Digium TDM808, sepuebla el fichero /etc/dahdi/system.conf escribiendo la siguiente instrucción en unterminal:

> dahdi_genconf

Esta instrucción comprueba las tarjetas disponibles en el ordenador y configura elfichero system.conf con la información que obtiene de dichas tarjetas. Al inspeccionarel archivo después de ejecutar este comando, vemos el nombre de la tarjeta detectaday dos líneas por cada módulo detectado (ocho en este caso). Para cada módulo seespecifica el tipo y señalización (fxsks1) y el cancelador de eco asociado. También haydos líneas especificando el país de utilización para los tonos. Se cambia el canceladorde eco por defecto (mg2) por el que se ha instalado (Oslec) y el país de utilización aEspaña.

1Los módulos FXO se definen con la nomenclatura contraria ’fxs’. Estos módulos usan señalización’ks’ (Kewlstart Signalling), que corresponde a señalización loopstart con supervisión de desconexión.

43


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 = es

defaultzone = es

A continuación hay que cargar los drivers de DAHDI en el kernel mediante la si-guiente instrucción. 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 líneas endos 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) queaparece configurado por defecto y que puede utilizarse en combinación con Oslec. Detodas formas, si se deseara deshabilitar el cancelador hardware, debe modificarse lasiguiente línea del archivo /etc/modprobe.d/dahdi.conf:

> vi /etc/modprobe.d/dahdi.conf

options wctdm24xxp vpmsupport =0

44


Las configuraciones de señalización y los códigos utilizados para los tonos en la redde telefonía varían en función de la zona o el país en el que nos encontremos. Por esohay que realizar unos cambios para conseguir que la configuración de la tarjeta sea laadecuada para operar en España. Con este fin, se hacen las siguientes modificacionesen 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 configuración de los módulos de la tarjeta sea la co-rrecta y que se hayan aplicado correctamente todos los cambios. Para ello se utilizauna instrucción que muestra por pantalla un resumen de los puertos de la tarjeta y suconfiguración.

> 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: oslec)(Slaves: 01)








8 channels to configure.

Setting echocan for channel 1 to oslec








Se hace una última comprobación mediante la instrucción dmesg, que lista el bufferde mensajes del núcleo, y se buscan las líneas relativas a las configuraciones que se han

45


llevado a cabo. A continuación se muestran estas líneas, donde vemos que se detectala tarjeta Digium con los puertos de tipo FXO configurados para funcionar con los tonosde España y que se han encontrado también 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 CANALES DAHDI

El último paso relativo a la configuración de la parte externa es la modificación delarchivo chan_dahdi.conf que se encuentra ubicado en el directorio /etc/asterisk.Este archivo es la capa de configuración entre DAHDI y Asterisk y sirve para definir lascaracterísticas esenciales de los canales relativos a la tarjeta instalada.

46


El archivo chan_dahdi.conf consta de dos partes: la definición de las opcionesgenerales de los canales y la definición de los propios canales. Las características gene-rales de los canales incluyen, por ejemplo: la utilización de identificación de llamada, laposibilidad de aparcar y transferir llamadas, la utilización del cancelador de eco, tiposde señalización utilizados, etc. A continuación hay que definir los canales relativos alos módulos de la tarjeta para que Asterisk sea capaz de reconocerlos y utilizarlos. Eneste caso, la definición 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 lotanto, todos los canales tendrán las mismas características. Se especifica el tipo deseñalización (fxs_ks) y que el identificador de llamada de estos canales venga marcadopor el obtenido de la red telefónica. También se define el contexto que utilizarán todoslos canales ([from− pstn]). Esto quiere decir que todas las llamadas que utilicen estoscanales (entrantes desde la red telefónica) ejecutarán las instrucciones del dialplancorrespondientes a este contexto. Como se puede deducir, el contexto [from− pstn] esdonde se ubica la definición de la centralita (PBX).

La configuración completa de este archivo puede encontrarse en el anexo A.2.1.

3.4.3 ASTERISK

En este apartado se detalla la configuración del sistema de telefonía VoIP que se haimplementado para el escenario de la residencia. Para ello se detallarán los archivosde configuración relativos a los módulos de Asterisk que se han utilizado. Todos estosficheros se encuentran en el directorio /etc/asterisk.

3.4.3.1 USUARIOS

La definición de los clientes SIP que se pueden registrar en el servidor de VoIP serealiza en el archivo /etc/asterisk/sip.conf. Cada usuario (cliente SIP) debe tenerun nombre que lo identifique y una clave de acceso para poder registrarse. Tambiéndeben especificarse otros aspectos, como los códecs que pueden utilizar y el contexto

47


TABLA 3.1: Listado de usuarios SIP.

Residentes [PermisosResidentes] 200, 201, 202501 (recepción)502 (trabajadora social)503 - 505 (gerocultoras)506 (despacho directora)507 (móvil directora)508 (casa directora)509 (psicóloga)

Trabajadores [PermisosTrabajadores]

500 (jefa de enfermeras)

que tratará las llamadas.

Para realizar las simulaciones se han definido una serie de clientes que representana los posibles usuarios del sistema implementado en la residencia de ancianos. Sediferencian dos tipos: los residentes y los trabajadores. A cada tipo se le asigna uncontexto diferente ya que no todos podrán acceder a las mismas extensiones en eldialplan. A todos los usuarios se les habilita el códec G.711 en sus dos versiones (a-lawy u-law).

En la tabla 3.1 se encuentra un resumen de los usuarios creados. La definicióncompleta de estos usuarios se puede encontrar en el anexo A.2.2.

3.4.3.2 DIALPLAN

El dialplan es el núcleo del sistema Asterisk. En él se indica el manejo de todas lasllamadas que llegan al servidor. La descripción del dialplan se realiza en el archivo/etc/asterisk/extensions.conf. Este fichero se estructura en contextos, y esoscontextos, a su vez, en extensiones.

En este caso se han definido una serie de contextos que permitirán realizar una seriede acciones dependiendo del tipo de usuario o del punto de acceso. A continuación selistan los contextos utilizados y se resumen sus funciones:

* [usuarios]: este contexto contiene las extensiones que permiten: acceder a lamacro de llamadas para todos los usuarios (trabajadores y residentes) y accedera la sala de conferencias 101 (que se explicará más adelante).

* [macro−UnaExten]: las macros son contextos especiales que se pueden reutilizaren otros contextos. Este contexto sólo contiene la extensión s, que es modificada

48


en los consiguientes contextos por el número de extensión que invoca. En estecaso, se utiliza una macro para realizar las llamadas locales (entre los usuariosinternos). Se comprueba que la extensión no esté en la lista negra, si hay desvíosactivos y entonces se realiza el marcado. Si no hay respuesta, salta el buzón devoz.

* [Buzon_de_voz]: contiene la extensión 99, que da acceso al buzón de voz paraque los usuarios puedan escuchar sus mensajes.

* [grabadora]: contiene las extensiones que permiten grabar las locuciones de vozpara la PBX en formato WAV. Los archivos de audio grabados se guardan en eldirectorio /var/lib/asterisk/sounds/custom.

* [android_V A]: contiene las extensiones que se utilizarán para notificar a losusuarios internos de las alertas originadas por los softphones implementados enAndroid. Su contenido se detalla en el capítulo 4.

* [PC_a_RTC]: permite a los usuarios internos realizar llamadas a números exter-nos marcando previamente 00. Estas llamadas se transmiten por una de las líneasanalógicas conectadas a la tarjeta TMD808.

* [from − pstn]: trata todas las llamadas entrantes procedentes del exterior.Este contexto, junto con [centralita_ASR] y [menu − privado] se explicarándetalladamente más adelante.

Asterisk permite el anidamiento de contextos, es decir, contextos dentro de con-textos. Esto se utiliza para restringir el acceso a algunas funcionalidades depen-diendo del usuario. Con este fin se crean los contextos [PermisosResidentes] y[PermisosTrabajadores], que dan acceso a los contextos cuyas extensiones se puedenutilizar por los diferentes usuarios:

* [PermisosResidentes]: 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].

* [PermisosTrabajadores]: contexto donde se tratan las llamadas de los traba-jadores (usuarios del 500 al 509). Éste da acceso a los contextos: [usuarios],[Buzon_de_voz], [grabadora], [Android_V A], [PC_a_RTC] y [parkedcalls] (nece-saria para poder transferir y aparcar llamadas). También incluye las extensionesque permiten activar/desactivar el desvío de llamadas y el acceso a la sala deconferencias 600 (limitada a 3 usuarios y sólo para empleados).

La configuración completa del dialplan se puede encontrar en el anexo A.2.3.

49


3.4.3.3 MÚSICA EN ESPERA

Asterisk ofrece la posibilidad de utilizar música en espera cuando un usuario queda ala espera durante una llamada. También se puede reproducir música en substituciónde los tonos de marcado.

La configuración de la música en espera se realiza en el archivo/etc/asterisk/musiconhold.conf y se puede encontrar en el anexo A.2.4. Eneste fichero se especifican la localización y el modo de reproducción de los archivosde audio. En este caso existen dos posibilidades: dos archivos de audio en formatoWAV y una emisora de radio gratuita shoutcast (Big B Radio). La emisora de radio esla música en espera por defecto en todas las extensiones de la PBX. Los archivos deaudio, que se reproducen de forma aleatoria, se utilizan para el resto de los casos.

3.4.3.4 BUZÓN DE VOZ

El servicio de voicemail que ofrece Asterisk es similar al de cualquier buzón de vozañadiendo más funcionalidades. La más destacable es la capacidad de enviar uncorreo electrónico al usuario para avisarle de que tiene nuevos mensajes. Este correoelectrónico incluye, además, un fichero adjunto con el mensaje de voz en el formatoespecificado. Como se ha comentado anteriormente, para utilizar esta funcionalidad, elservidor debe contar con un gestor de correo, en este caso, el SSMTP. La configuraciónde este gestor se encuentra en el anexo A.2.5.1.

La configuración de los buzones de voz se realiza en el archivo/etc/asterisk/voicemail.conf y se puede encontrar en el anexo A.2.5. Eneste fichero se definen todas las cuentas de voicemail, asociando a cada usuario unnombre, una cuenta de correo electrónico para recibir los mensajes y una contraseñapara acceder al buzón de voz desde el teléfono. En este caso se define una cuenta paracada usuario definido en sip.conf. También se pueden configurar varias opcionesgenerales para todas las cuentas, como por ejemplo: especificar el cuerpo del correoelectrónico, el formato del archivo de audio enviado o el tamaño y duración delmensaje. Para evitar que el buzón de voz bloquee la línea demasiado tiempo, se hamodificado la longitud máxima de los mensajes y el tiempo de silencio antes de pararla grabación a 30 y 10 segundos respectivamente.

3.4.3.5 FOLLOW ME

La funcionalidad Follow Me sirve para intentar localizar a un usuario llamando adistintas localizaciones (en serie o en paralelo). La configuración de este servicio

50


se realiza en el archivo /etc/asterisk/followme.conf. En él se especifican, pororden, las extensiones a las que llamar y el tiempo que se debe esperar hasta pasar ala siguiente destinación. En este caso se utiliza en la extensión de la centralita quecontacta con la directora del centro. Primero se intenta en el despacho, y si no hayrespuesta, se llama al móvil y por último, a su casa.

La configuración completa del protocolo de seguimiento se puede encontrar en elanexo A.2.6.

3.4.3.6 SALA DE CONFERENCIAS

Las salas de conferencia permiten crear conversaciones entre múltiples usuarios comosi estuvieran todos en una misma localización física. Algunas de las principalescaracterísticas de este servicio incluyen: la creación de varias salas distintas conacceso protegido por contraseña, la posibilidad de regular el número de participantes(fijando un número máximo, echando usuarios o bloqueando la sala), la capacidad deenmudecer a uno o varios participantes, etc.

En este caso se crean dos salas de conferencias con diferentes contraseñas. La salanúmero 600 sólo es accesible por los trabajadores de la residencia. La sala número101 permite el acceso a usuarios tanto internos como externos. El acceso exterior seencuentra en una extensión del menú privado de la centralita. El acceso interior seencuentra en el contexto [usuarios] disponible tanto para los residentes como para lostrabajadores.

La configuración 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 COLAS

La distribución automática de llamadas, o cola de llamadas, proporciona a la PBX unaforma de encolar llamadas entrantes de un grupo de usuarios. En este caso se utilizadesde la extensión de la centralita que contacta con la jefa de enfermeras. Al marcar laextensión, si no se consigue contactar con la jefa enfermeras se coloca la llamada en lacola, donde se mantendrá hasta que sea atendida por alguna gerocultora o se alcanceel tiempo máximo de espera en cola.

La configuración 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 estefichero se especifican los miembros que atenderán la cola de llamadas por orden de

51


prioridad. En este caso, los miembros serán las gerocultoras (usuarios 503, 504 y505, en este orden). También se pueden fijar varias opciones, como por ejemplo: tipode anuncios que se hacen al llamante mientras está en cola, música que se escuchamientras se espera a ser atendido, número de reintentos, tiempo máximo de espera encola, etc.

3.4.3.8 TRANSFERENCIA Y PARKING DE LLAMADAS

La transferencia y el aparcado de llamadas son funcionalidades típicas de las PBX.La transferencia de llamadas permite redireccionar una llamada desde la extensiónque la está atendiendo a cualquier otra. El parking de llamadas consiste en dejar unallamada en espera en una extensión y recogerla en cualquier otra. Estas funcionesestán disponibles por todos los usuarios internos del sistema.

La configuración 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 estearchivo se pueden especificar, entre otras cosas, las extensiones en las que puedenaparcarse las llamadas o las secuencias DMTF que hay que marcar para poder transferirllamadas. Las transferencias pueden ser de dos tipos: ciegas (se transfiere la llamadasin más) o guiadas (primero se contacta con la extensión deseada y luego se realiza latransferencia).

3.4.4 CENTRALITA PBX

Todas las llamadas entrantes procedentes de la red de telefonía (exterior) llegan ala centralita que se ha implementado y son recibidas por una operadora virtual quelas direccionará a la extensión deseada. Como se ha avanzado en la explicacióndel dialplan, los contextos que se utilizan para la configuración de la PBX son:[from− pstn] (entrada a la centralita), [centralita_ASR] (definición de las extensionesde la centralita) y [menu− privado] (definición de las extensiones del menú privado dela centralita).

Las llamadas entrantes exteriores son tratadas por el contexto [from − pstn]. Enél se encuentra la puerta de entrada a la centralita. Si la llamada se recibe den-tro del horario de recepción, se pasa la llamada al contexto [centralita_ASR] dandoacceso al menú de la PBX. Si no, se envía la llamada al buzón de voz de recepción (501).

En el contexto [centralita_ASR] se encuentra la definición de la parte pública dela PBX. Mediante locuciones de voz grabadas, se da la bienvenida al llamante y se leinforma 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 elteclado del teléfono. Se dan dos oportunidades para especificar la extensión deseadapor voz. Si no se reconoce una extensión válida, se pide la introducción vía teclado ysi no, se redirige la llamada a recepción (extensión 0) para que se le pueda atendero redireccionar a la extensión adecuada. Los pasos que sigue una llamada entrantedesde que llega a la centralita hasta que se escoge una extensión válida se pueden veren el diagrama de la figura 3.2.

A continuación se hace un breve resumen de las extensiones disponibles desde estecontexto y su funcionamiento:

* Extensión 0: Recepción. Se realiza una llamada al usuario recepción (501).Desde aquí se puede atender la llamada y transferirla a la extensión o usuarioadecuados. A esta extensión se puede llegar directamente desde el menú o alagotar el número máximo de intentos de introducir una extensión válida. Sufuncionamiento se puede observar en el diagrama de la figura 3.3.

* Extensión 1: Trabajadora social. Se realiza una llamada a la trabajadora social(502). Si no está disponible, se pasa la llamada al buzón de voz, como se puedever en el diagrama de la figura 3.4.

* Extensión 2: Enfermería. 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 delas gerocultoras, como se puede ver en el diagrama de la figura 3.5.

* Extensión 3: Dirección. Se realiza una llamada al despacho de la directora delcentro (506). Si no hay respuesta, se inicia el protocolo de seguimiento followme para intentar ubicarla en otros emplazamientos (el móvil y su casa). Se pideel nombre del llamante para anunciarlo al llamado en cada ubicación. Si no seconsigue contactar con la directora, se dirige la llamada al buzón de voz corres-pondiente. Este comportamiento se puede ver en el diagrama de la figura 3.6.

* Extensión 4: Psicóloga. Se realiza una llamada a la psicóloga del centro (509).La psicóloga puede redirigir su teléfono a la recepción si no quiere ser molestadadurante las sesiones. Primero se comprueba si hay una redirección y después sellama a la extensión adecuada, como se puede ver en el diagrama de la figura 3.7.

* Extensión 5: Llamada exterior. Permite llamar a cualquier número del exteriorpasando por Asterisk. En este caso, el número debe tener un máximo de 5 cifras.

* Extensión 6: Menú privado. Permite el acceso al menú privado, que se explicarámás adelante. Esta extensión no se nombra en el menú de inicio ya que estápensada para que sólo trabajadores autorizados de la residencia puedan acceder.

53


De todas formas, aunque se entrara por error, el acceso está protegido por unacontraseña.

* Extensión #: Colgado. Después de pasar por cualquier extensión, todas las lla-madas son dirigidas a ésta. Aquí se despide al llamante mediante una locuciónde voz y se cuelga la llamada.

* Extensión i: Extensión incorrecta. Se llega a esta extensión de forma automáticaal marcar una extensión incorrecta (no existente). Después de informar delerror, se reenvía la llamada al menú de extensiones del inicio. Si se ha alcan-zado el número máximo de errores, se envía la llamada a recepción (extensión 0).

En el contexto [menu − privado] se encuentra la definición de la parte privada dela PBX. El menú privado está pensado para uso exclusivo de la directora del centroy permite entrar en la sala de conferencias 101 y realizar escuchas desde cualquierteléfono exterior a la residencia. El acceso está controlado mediante contraseñapara que nadie pueda entrar por error. Se dan tres oportunidades de introducir lacontraseña correcta, si no, se cuelga la llamada automáticamente. Al acceder a estazona, se reproduce la locución de voz que informa de las opciones del menú privadoy se espera la introducción por teclado de la extensión deseada. Su funcionamiento sepuede ver en el diagrama de la figura 3.8.

Las extensiones disponibles en este contexto son las siguientes:

* Extensión 1: Sala de conferencias. Da acceso a la sala de conferencias 101mediante la contraseña correspondiente. A esta sala también tienen acceso losusuarios internos. Se especifican las siguientes opciones: se reproduce música sisólo hay una persona en la sala y se puede salir de ella pulsando la tecla #.

* Extensión 2: Escucha de llamadas. Permite espiar cualquier conversación quese esté realizando entre extensiones internas de la residencia. Pulsando la tecla *se detiene el espionaje del canal actual y se cambia a una conversación diferente.Pulsando la tecla # se sale de la extensión de escuchas y se llega a la extensiónde colgado de la centralita.

* Extensión i: Extensión incorrecta. Se llega a esta extensión de forma automáticaal marcar una extensión incorrecta (no existente). Después de informar del error,se reenvía la llamada al menú de extensiones privado.

La configuración completa de la PBX se puede encontrar en el anexo A.2.3.

54


3.4.4.1 INTEGRACIÓN DEL RECONOCIMIENTO DE VOZ

El reconocimiento de voz se usa para seleccionar la extensión deseada en el menúprincipal de la centralita. Para ello se utiliza el proyecto CMUSphinx. Este proyectoofrece una aplicación llamada pocketsphinx_continuous que se lanza desde unterminal y que hace el reconocimiento de voz de la entrada del micro. También incluyela posibilidad de utilizar como entrada del reconocimiento un fichero de audio enformato WAV.

La utilización de esta aplicación en Asterisk se hace mediante el script asr2.sh. Acontinuación se muestra el código de la PBX donde se utiliza el reconocimiento de vozy se explica su funcionamiento detalladamente:

1 exten => s,1,Answer ()

2 same => 2,Background(custom/asr_bienvenida)

3 same => 3,Set(k=1)

4 same => 4,While($[${k}<3])

5 same => n,Background(custom/asr_extension_voz)

6 same => n,Background(custom/asr_menu)

7 same => n,Record(custom/recon/voz.wav ,,5)

8 same => n,System (/var/lib/asterisk/sounds/custom/recon/asr2.sh)

9 same =>

n,Set(num=${FILE(/var/lib/asterisk/sounds/custom/recon/num.txt ,0,1)})

10 same => n,NoOp(num = ${num})

11 same => n,GotoIf($["${num}"=""]?null)

12 same => n,GotoIf($[${num}<0 | ${num} >6]?:ok)

13 same => n,Set(num=i)

14 same => n(ok),Goto(${num},1)

15 same => n(null),Set(k=$[${k}+1])

16 same => n,EndWhile

17 same => n,Background(custom/asr_extension&beep)

18 same => n,WaitExten (15,m(radio))

19 same => n(max),PlayBack(custom/asr_max_intentos)

20 same => n,Goto (0,1)

Después de escuchar la locución de voz que informa del menú de extensionesprincipal, se pide al llamante que diga la extensión que desea. La respuesta se grabaen un archivo de audio (voz.wav) mediante la instrucción Record() (línea 7). Acontinuación, se lanza el script encargado de hacer el reconocimiento de la respuestagrabada utilizando la instrucción System() (línea 8). Por último, se guarda el númerode extensión obtenido del reconocimiento en la variable num del dialplan (línea 9). Elvalor de esta variable se utiliza para dirigir la llamada a la extensión deseada mediantela instrucción Goto() (línea 14).

El shell script asr2.sh utiliza la aplicación pocketsphinx_continuous para hacer elreconocimiento de la siguiente manera:

55


#! /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 apli-cación pocketsphinx_continuous, utilizando el modelo acústico y diccionario tidigits.Este diccionario permite el reconocimiento de dígitos del 0 al 9 en inglés. La salida delreconocimiento devuelve mucha información y con la instrucción tail se obtiene sóloel dato deseado, el nombre del dígito reconocido, que se guarda en el archivo out.txt.Por último se obtiene el dígito reconocido en formato numérico para que Asteriskpueda utilizarlo para especificar la extensión. Esto se hace con la ayuda del ficheronumbers.txt, convirtiendo el nombre del número en su dígito correspondiente yguardando el resultado en el fichero num.txt. El fichero numbers.txt es simplementeun archivo de texto que contiene once líneas (una para cada palabra posible) con lasiguiente nomenclatura:

(número) (nombre del número)

Todos los archivos utilizados para el reconocimiento de voz se encuentran ubicadosen el directorio /var/lib/asterisk/sounds/custom/recon.

3.4.5 EJECUCIÓN

Una vez instalados y configurados todos los componentes necesarios se debe poner enmarcha todo el sistema. Para ello hay que iniciar los servicios DAHDI y Asterisk (en eseorden) mediante las siguientes instrucciones:

> service dahdi start

> service asterisk start

Para acceder a la consola propia de Asterisk (CLI) se escribe la siguiente línea en unterminal:

> 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.

Después de realizar cualquier cambio en los archivos de configuración se debenvolver a cargar los módulos afectados para que Asterisk opere con la versión másactual de los mismos. Esto puede hacerse con los comandos adecuados en la consolaCLI o reiniciando el servicio Asterisk desde cualquier terminal.

57


FIGURA 3.2: Diagrama de flujo de la centralita (Inicio).

58


FIGURA 3.3: Diagrama de flujo de la extensión 0 de la centralita (Recepción).

59


FIGURA 3.4: Diagrama de flujo de la extensión 1 de la centralita (Trabajadora Social).

60


FIGURA 3.5: Diagrama de flujo de la extensión 2 de la centralita (Enfermería).

61


FIGURA 3.6: Diagrama de flujo de la extensión 3 de la centralita (Dirección).

62


FIGURA 3.7: Diagrama de flujo de la extensión 4 de la centralita (Psicóloga).

63


FIGURA 3.8: Diagrama de flujo de la extensión 6 de la centralita (Menú privado).

64

4Implementación de los Softphones

4.1 OBJETIVO

COMO SE HA COMENTADO en la introducción de este documento, uno de los objetivosdel proyecto es la implementación 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 recepción del centro. Aunque sepodría utilizar cualquier softphone disponible en el mercado, se decide implementaraplicaciones propias con el propósito de añadir funcionalidades extras y exclusivaspara los residentes y trabajadores del centro.

A lo largo de este capítulo se irán explicando, en profundidad, los pasos seguidospara implementar estas aplicaciones y su funcionamiento.

4.2 INSTALACIÓN Y CONFIGURACIÓN DEL ENTORNO DE

TRABAJO

PARA REALIZAR ESTA PARTE del proyecto se requiere la instalación y configuración deuna serie de elementos que se explicarán en este apartado:

* Un entorno de programación adecuado formado por Eclipse, Android SDK y elplugin ADT, necesarios para la implementación de cualquier aplicación Android.

* Una base de datos en el servidor, para lo que se instala LAMP, y una serie descripts PHP que servirán para acceder, consultar y modificar esta base de datosdesde las aplicaciones Android.

65

CAPÍTULO 4. IMPLEMENTACIÓN DE LOS SOFTPHONES

* Unas extensiones especiales en Asterisk que servirán para comunicar las situa-ciones de emergencia entre los residentes y la recepción. Estas extensiones estándefinidas en el dialplan de Asterisk bajo el contexto [android_V A].

4.2.1 DESARROLLO DE APLICACIONES ANDROID

Para poder implementar cualquier aplicación Android hay que instalar el entornode programación y simulación adecuado. Todas las herramientas necesarias paradesarrollar aplicaciones Android son gratuitas (libres) y están disponibles para todaslas plataformas (Linux, Mac, Windows). En este caso se utilizarán las herramientasrecomendadas en Android Developers: Eclipse + Android SDK + ADT.

Eclipse

El primer paso para desarrollar cualquier aplicación es obtener un entorno de de-sarrollo integrado (IDE). Un IDE es un programa compuesto por un conjunto deherramientas de programación y normalmente consiste en: un editor de código,herramientas de compilación y un depurador. En el caso de aplicaciones Android,el IDE recomendado es Eclipse, un entorno de programación multi-lenguaje con unextensible sistema de plug-in. La última versión disponible al iniciar este proyecto, ypor tanto la versión instalada, es la Helios.

Android SDK

El SDK1 es un conjunto de herramientas de desarrollo que permite a un programadorcrear aplicaciones para un sistema concreto, por ejemplo ciertos paquetes de software,frameworks, plataformas de hardware, videoconsolas, sistemas operativos, etc. Esalgo tan sencillo como una interfaz de programación de aplicaciones (API) creadapara permitir el uso de cierto lenguaje de programación, o puede, también, incluirhardware sofisticado para comunicarse con un determinado sistema embedido.

El Android SDK contiene un depurador, librerías, un emulador, documentación,ejemplos de código y tutoriales. Se puede descargar desde la página web de AndroidDevelopers: http://developer.android.com/sdk/index.html. La versión instalada esla 14.

ADT

El plug-in ADT2 para Eclipse es una extensión del entorno de desarrollo que permite lacreación y depuración de aplicaciones Android. Gracias a este plugin se puede hacer

1Kit de Desarrollo de Software2Android Development Tools

66

http://developer.android.com/sdk/index.html

4.2. INSTALACIÓN Y CONFIGURACIÓN DEL ENTORNO DE TRABAJO

lo siguiente: crear proyectos para aplicaciones Android, acceder a las herramientas deemuladores Android, compilar y debugar aplicaciones, crear paquetes APK (ejecutablesde Android), crear certificados digitales para firmar los APKs, entre otras cosas. Suinstalación se realiza directamente desde Eclipse.

Una vez instalado esto hay que crear una ADV3 para poder testear las aplicacionesque se van a programar. Esta máquina virtual emula el comportamiento de unsmartphone con las características que se le especifiquen. Sin embargo, debido ala naturaleza de este proyecto, la mayoría de las pruebas se han realizado directa-mente sobre dispositivos físicos (smartphones con sistema operativo Android 2.3,Gingerbread).

La guía completa para instalar estos componentes se encuentra en el anexo B.1.

4.2.2 BASE DE DATOS REMOTA

Se instala una base de datos en el servidor que se utilizará para los sistemas de alertade los residentes: de posicionamiento y batería baja. Para crear la base de datos seinstala el paquete LAMP4 en el servidor. Con la idea de facilitar la tarea de creacióny gestión de la base de datos, se instala también el programa MySQL Navigator, quepermite manejar la base de datos mediante una interfaz gráfica.

El acceso desde las aplicaciones Android a esta base de datos se hace de la siguientemanera: las aplicaciones hacen peticiones HTTP contra Apache, que ejecuta losscript PHP correspondientes, accediendo a la base de datos MySQL y devolviendo losresultados obtenidos en formato JSON a las aplicaciones.

La instalación del paquete LAMP, y la creación de la base de datos mediante MySQLNavigator se encuentra en el anexo B.2.1.

4.2.2.1 ESTRUCTURA 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 dar3Android Virtual Machine4LAMP: Acrónimo referido a la primera letra de Linux (sistema operativo), Apache HTTP (servi-

dor), MySQL (software de base de datos) y PHP (software de scripting), componentes principales paraconstruir un web server.

67


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 número y nombrede usuario y dos flags de alerta desactivados. El flag alert_flag se utiliza paracontrolar la ubicación del residente: mientras éste permanezca dentro de la zonapermitida, 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 batería deldispositivo del residente: si la batería baja del 15%, el flag se pone a 1.

* MyCoordinates: Esta tabla se utiliza para controlar la ubicación de los residentesque están fuera de la zona permitida. Mientras el residente se encuentrefuera de esta zona, se van almacenando en la tabla sus coordenadas GPS parapoder localizarlo. Para ello se crean entradas con el número de usuario, y lascoordenadas en formato (latitud, longitud).

4.2.2.2 SCRIPTS PHP

El acceso a la base de datos MySQL se hace mediante scripts PHP. Estos scripts permitenrealizar consultas y/o modificar los atributos de la base de datos desde las aplicacionesAndroid.

A continuación se explica la función y utilización de los scripts implementados eneste proyecto, diferenciando los utilizados por cada aplicación. El código de estosscripts se encuentra en el anexo B.2.2.

Softphone A: residentes

68

4.2. INSTALACIÓN Y CONFIGURACIÓN DEL ENTORNO DE TRABAJO

insert_alert_user.php , get_alert_user.php , update_alert_user.php ,delete_alert_user.php

Se utilizan desde la gestión de cuentas de la aplicación y afectan únicamente a la tablade alertas MyAlerts. Insertan, borran, o modifican los datos del usuario en la base dedatos (nombre y número de cuenta, únicamente).

update_alert_flag.php

Se utiliza desde el servicio de alertas de localización de la aplicación y afectaúnicamente a la tabla de alertas MyAlerts. Actualiza el valor del flag de alerta deposicionamiento del usuario que lo ejecuta.

update_battery_flag.php

Se utiliza desde el broadcast receiver de alerta de batería de la aplicación y afectaúnicamente a la tabla de alertas MyAlerts. Actualiza el valor del flag de alerta porbatería baja del usuario que lo ejecuta.

insert_coordinates.php

Se utiliza desde el servicio de alertas de localización de la aplicación y afecta única-mente a la tabla de coordenadas MyCoordinates. Inserta una coordenada GPS (latitud,longitud) en la base de datos, indicando el número del usuario al que pertenece.

Softphone B: recepción del centro

get_alert_coordinates.php

Se utiliza desde el mapa de localización de la aplicación y afecta a ambas tablas. Ob-tiene un listado con todos los residentes que se encuentran en estado de alerta (fuerade la zona permitida, con alert_flag=1) y la última coordenada GPS introducida porcada uno de ellos.

get_user_coordinates.php

Se utiliza desde el mapa de localización de la aplicación y afecta a ambas tablas. Ob-tiene la última coordenada introducida en la base de datos por el usuario especificado.

check_battery_alert.php

Se utiliza desde un servicio de la aplicación y afecta a la tabla de alertas MyAlerts.Comprueba si hay alguna alerta de batería baja activada (battery_flag=1).

get_battery_alerts.php

Se utiliza desde el listado de alertas de batería de la aplicación y afecta a la tabla dealertas MyAlerts. Obtiene un listado con todos los residentes que se encuentran enestado de alerta por batería baja (número y nombre de usuario) ordenados por nombre.

69


4.2.3 EXTENSIONES DE EMERGENCIA EN ASTERISK

Como se ha explicado en la introducción, se utilizan unas extensiones especialesen el servidor SIP para avisar a las aplicaciones de que deben iniciar una serie deacciones. Estas extensiones están definidas en el dialplan de Asterisk bajo el contexto[android_V A].

Las aplicaciones de los residentes y la recepción se comunican entre ellas (de formainterna) mediante llamadas perdidas a estas extensiones especiales, de forma invisiblea 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, yaque se utilizarán como disparador para que las aplicaciones ejecuten ciertas acciones.La utilidad de éstas se explicará con más detalle para cada aplicación en los siguientesapartados.

* Extensión 033: Alerta de localización. Esta extensión se marca automática-mente desde el softphone de un residente al salir/entrar de la zona permitida. Seorigina entonces una llamada entre la recepción y el llamante, informando a larecepción, al descolgar, del número de usuario del residente que ha generado laalerta.

* Extensión 034: Petición de inicio de seguimiento. Esta extensión se marcaautomáticamente desde el softphone de recepción al solicitarse el seguimientode la ubicación de un residente. Esto genera una llamada perdida al usuariopertinente, que empezará a enviar sus coordenadas de posición a la base de datos.

* Extensión 035: Petición de finalización de seguimiento. Esta extensiónse marca automáticamente desde el softphone de recepción al solicitarse lafinalización del seguimiento de un residente. Opera de la misma forma que laanterior, generando una llamada perdida al usuario pertinente, que en este casodetendrá el envío de coordenadas a la base de datos.

La definición de estas extensiones se encuentra detallado en el anexo B.3.

4.3 DESARROLLO DE LAS APLICACIONES

LAS APLICACIONES FINALES consisten en dos softphones: uno para los residentes yotro para la recepción del centro, que también pueden utilizar los trabajadores del

70

4.3. DESARROLLO DE LAS APLICACIONES

mismo.

Primero se ha desarrollado un softphone básico, con unas prestaciones quecualquier softphone en el mercado puede ofrecer: realizar y recibir llamadas, listadode cuentas y contactos, registro de llamadas, etc. Aunque esta aplicación tambiénpuede instalarse en un terminal, se ha declarado como librería para facilitar la herenciaen las otras dos aplicaciones.

Las otras aplicaciones heredan de este softphone básico, añadiendo funcionalidadesy características diferentes para cada una de ellas:

* Softphone A: destinado para el uso de los residentes del centro. Añade dos fun-cionalidades: sistema de alerta en caso de batería baja y sistema de alerta encaso de que el residente salga de una zona permitida (se aleje demasiado de laresidencia) utilizando el sensor GPS del dispositivo físico.

* Softphone B: destinado para el uso de la recepción del centro. Añade tresfuncionalidades: mapa con la ubicación de los residentes que estén fuera de lazona permitida, petición de seguimiento de cualquier residente (ubicación delresidente) y comprobación de alertas por batería baja en los softphones de losresidentes.

La interacción entre las dos aplicaciones se realiza mediante las extensiones deemergencia de Asterisk y la base de datos remota (ubicada en el servidor). Estas dosaplicaciones acceden y modifican el contenido de esta base datos para los eventosrelacionados con las alertas de posicionamiento y batería.

A continuación se ofrece una explicación más detallada de la estructura y elfuncionamiento de estas aplicaciones, con ejemplos de código cuando sea relevante.

4.3.1 SOFTPHONE BÁSICO

La primera aplicación desarrollada, llamada LDDSoftphoneLibrary, consiste en unsoftphone básico. Esta aplicación tiene el funcionamiento de un softphone conprestaciones muy básicas: recepción y emisión de llamadas VoIP, agenda de contactos,lista de cuentas SIP (clientes SIP) con las que poder logarse en el servidor de VoIPy listado de registro de llamadas. En el transcurso de una llamada se dispone de:función de altavoz y acceso a un teclado para mandar códigos DTMF (por ejemplo,para el buzón de voz).

71


FIGURA 4.2: Menú tab de la aplicación con: a) Pantalla principal de la aplicación. b)Lista de contactos. c) Registro de llamadas.

Los datos de la agenda de contactos y la lista de cuentas SIP se guardan en unabase de datos interna (en el dispositivo físico). También se guardan en ella los datosde las llamadas del registro de llamadas. Esta base de datos, de tipo SQLite, es propiade cada aplicación 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 hanencapsulado en una clase llamada DBAdapter, facilitando así el acceso desde cualquierclase de la aplicación que lo requiera.

El aspecto que presenta la aplicación al iniciarla se puede observar en lafigura 4.2(a). Como se aprecia en dicha figura, la pantalla principal consta de un menútipo TAB con tres pestañas. Estos menús tienen la siguiente apariencia: una barra conpestañas en la parte superior de la pantalla y en el resto, una zona donde aparece laactividad relativa a cada pestaña. En la primera aparece el teclado que permite realizarllamadas 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 aplicación, con laposibilidad de realizar una marcación directa al pulsar sobre cada uno de ellos. En latercera se encuentra el registro de llamadas, donde se muestran los datos de todas lasllamadas realizadas y recibidas: número llamante, número llamado, tipo de llamada

72


FIGURA 4.3: a) Menú principal de la aplicación para los residentes. b) Diálogo queaparece al cerrar las aplicaciones.

(entrante, saliente, perdida), fecha, hora y duración de la llamada, como se puede veren la figura 4.2(c). Al pulsar sobre una llamada del registro, se ofrece la posibilidad derellamar o devolver una llamada a ese número 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, añadir un nuevo contacto y cerrar la aplicación. Laaplicación puede cerrarse de dos formas: mediante la tecla BACK del dispositivo omediante la opción Cerrar del menú. La primera opción permite seguir recibiendollamadas SIP aunque la aplicación no sea visible en pantalla. La segunda, en cambio,cierra por completo la aplicación y por tanto no se pueden recibir llamadas. Por eso,al cerrar la aplicación desde el menú, se muestra al usuario un diálogo de advertenciainformándole de este hecho (figura 4.3(b)).

La lista de cuentas aparece en la figura 4.4(a) y muestra los datos de las cuentasSIP (número y nombre) que el usuario puede utilizar para registrarse en el servidorde VoIP. Los datos que se guardan para cada cuenta son: número y nombre deusuario, dirección del servidor de VoIP y contraseña requerida por el servidor paralogarse. Desde esta pantalla pueden crearse cuentas nuevas, así como modificar o

73


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 aplicación está programada para logarseautomáticamente en el servidor con la última cuenta que se utilizó, por lo que si elusuario desea cambiar de cliente SIP (cambiar la cuenta activa), debe hacerlo desdeesta pantalla, mediante el menú context de la figura 4.4(b).

Al realizar o recibir una llamada, aparecerá en el dispositivo la pantalla de lafigura 4.5, donde se muestra el número o identificador del llamante/llamado y variosbotones que permiten: descolgar/colgar la llamada, activar/desactivar la función dealtavoz 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 elbuzón de voz. La aplicación utiliza el sensor de proximidad del terminal físico parabloquear y apagar la pantalla si ésta se acerca demasiado a la cara. Este mecanismo seutiliza para evitar tocar los botones de la pantalla con la cara o la oreja durante unallamada.

Las notificaciones son muy importantes en esta aplicación, ya que informan alusuario del estado del softphone y de las posibles incidencias relacionadas con elservidor SIP, permitiendo la interacción del mismo para solventarlas. Al abrir la apli-

74


FIGURA 4.5: Pantalla mostrada durante las llamadas en las aplicaciones.

cación, aparece una notificación en la barra de estado con el nombre de la aplicaciónLDDSoftphone y la cuenta con la que se ha logado el terminal al servidor SIP (cuentaactiva). Esta notificación es permanente y sólo desaparece al cerrarse la aplicaciónmediante la opción Cerrar del menú principal. Si no hay una cuenta activa (no se hapodido logar en el servidor SIP o no existen los datos de esa cuenta), se informa alusuario mediante otra notificación que le permite ir directamente al listado de cuentaspara realizar las modificaciones pertinentes. También aparece una notificación parainformar al usuario de que tiene llamadas perdidas, con acceso directo al registro dellamadas para poder comprobarlas.

4.3.1.1 INTEGRACIÓN DE LA VOIP EN LA APLICACIÓN

La integración de la VoIP en la aplicación se consigue gracias a la utilización de la APISIP nativa de Android. Esta API se encuentra disponible en todas las versiones a partirde la 2.3 (Gingerbread). Su integración permite añadir características de telefoníaVoIP basada en el protocolo SIP en los softphones desarrollados. De esta forma, sepuede 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


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

Clase / Interfaz DescripciónSipAudioCall Maneja las llamadas SIP.SipAudioCall.Listener Listener para eventos relacionados con llamadas SIP.SipErrorCode Define códigos de error retornados durante acciones SIP.SipManager Proporciona APIs para tareas SIP, como iniciar conexiones

SIP, y proporciona acceso a servicios SIP relacionados.SipProfile Define un perfil SIP, incluyendo información de una cuenta

SIP, dominio y servidor.SipProfile.Builder Clase de ayuda para crear un SipProfile.SipSession Representa una sesión SIP asociada a una diálogo SIP o a

una transacción independiente fuera del diálogo.SipSession.Listener Listener para eventos relacionados con sesiones SIP.SipSession.State Define estados de la sesión SIP.SipRegistrationListener Interface, listener para eventos del registro SIP.

API SIP de Android.

Para integrar esta API en las aplicaciones desarrolladas se crean tres clases que seencargarán 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 actúa como puente entre el servicio ServiceSIP

y el resto de clases de la aplicación.

A continuación se explica el desarrollo y funcionamiento de estas clases másdetalladamente.

4.3.1.1.1 SERVICESIPEste servicio es el alma de la aplicación y la clase más importante de la misma. En

él se encuentra todo el código relacionado con la API SIP de Android y contiene, portanto, todos los métodos que permiten a la aplicación interactuar con el servidor SIP.Sus funciones principales son: registrar/desregistrar una cuenta SIP en el servidor yrealizar llamadas. Las clases de la aplicación que necesiten interactuar con el servidorSIP (para realizar/colgar llamadas, logar/deslogar un cliente SIP, etc.) pueden hacerloa través de este servicio mediante la clase ServiceBinder.

76


El servicio ServiceSIP se lanza al abrir la aplicación y no se detiene hasta que elusuario sale de la misma mediante la opción Cerrar del menú principal. Si se sale de laaplicación con la tecla BACK, el servicio sigue activo, ya que se deben seguir recibiendollamadas SIP y eventos relacionados con la aplicación aunque ésta no esté visible en lapantalla del dispositivo.

Lo primero que se hace al crearse el servicio es especificar el broadcast receiver quese encargará de recibir las llamadas entrantes (CallReceiverSIP, en este caso), cuyofuncionamiento se explicará más 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, propiode la API SIP de Android y se registra la cuenta de usuario (cliente SIP) que se va autilizar para logarse en el servidor SIP. A través de este objeto se podrán realizar lassiguientes acciones: iniciar sesiones SIP, realizar y recibir llamadas, registrar/desregis-trar cuentas SIP en el servidor y verificar la conectividad de la sesión.

Para registrar la cuenta de usuario SIP en el servidor se utiliza el métodoinitiateLocalProfile, cuyas variables de entrada son los datos de la cuenta (nombreo número, dirección del servidor y contraseña de acceso). Al iniciar la aplicación,se intenta recuperar la información de la última cuenta utilizada para registrarse denuevo. Si no es posible, se muestra la notificación de la figura 4.6(a) para informar alusuario de que no hay cuenta activa y no se ejecuta este método. Hasta que el usuariono especifique una cuenta válida para registrarse en el servidor SIP, la aplicación nopodrá enviar ni recibir llamadas SIP.

Al utilizar la API SIP, cada cuenta SIP está representada por un objeto de tipoSipProfile. 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 continuación, se habilita el perfil creado (se da la orden de registro de la cuenta enel servidor) para que se puedan enviar/recibir llamadas SIP, especificando de nuevo,

77


FIGURA 4.6: a) Notificación que aparece cuando no hay ninguna cuenta activa. b)Notificación 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 lasllamadas entrantes.

manager.open(me, pi, null);

Finalmente, se crea un listener que se encargará de manejar los eventos relacionadoscon 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


FIGURA 4.7: a) Notificación que aparece al no poder registrar la cuenta especificadaen el servidor SIP. b) Notificación 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 servidorSIP, se actualiza la notificación permanente en la barra de estado con los datos(número@servidor) de la cuenta activa, como se puede ver en la figura 4.6(b). Apartir de este momento, la aplicación está lista para poder enviar/recibir llamadas SIP.En caso de no poderse registrar (porque no se dispone de conectividad con el servidorSIP, la cuenta es incorrecta, etc.), se informa al usuario mediante la notificación de lafigura 4.7(a) para que pueda solventar el problema.

Si ya no se desea utilizar más el perfil actual (se quiere cambiar de cuenta activa

79


o se cierra la aplicación), se utiliza el método closeLocalProfile para deslogarse delservidor. Si no se está cerrando la aplicación, se muestra una notificación para informaral usuario de que no hay ninguna cuenta logada en el servidor (figura 4.6(a)) y desdeese momento no se pueden enviar ni recibir llamadas SIP en la aplicación.

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 losmétodos relacionados con la API SIP de Android, que el resto de clases de la aplicaciónutilizan para realizar distintas acciones como: realizar/colgar una llamada SIP,activar/desactivar el altavoz del dispositivo durante una llamada, enviar tonos DTMFe introducir una llamada en el registro de llamadas. De estos métodos se destacanlos dos más importantes: realizar una llamada SIP y crear una nueva entrada en elregistro de llamadas.

Para realizar una llamada SIP se utiliza el método 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


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 método se necesitan tres cosas: un SipProfile local registrado(cuenta activa del softphone logada correctamente al servidor SIP), una dirección SIPválida para recibir la llamada y un objeto de tipo SipManager.

Primero se crea un listener de tipo SipAudioCall.Listener que se encarga demonitorizar y manejar los eventos relacionados con la llamada SIP saliente. Como severá más adelante, el listener encargado de las llamadas entrantes se encuentra en elbroadcast receiver CallReceiverSIP. En este listener se define el comportamiento dela aplicación al establecer y colgar la llamada. Al establecerse la llamada, se guardan

81


datos para el registro de llamadas (tiempo de inicio y fecha) y a continuación se activael audio de la llamada. Al colgarse la llamada, se guarda el tiempo de finalización dela llamada y se lanza el broadcast que activará el registro de la llamada.

Una vez definido el listener, se realiza la llamada mediante el método makeAudioCalldel objeto SipManager, utilizando los siguientes parámetros: perfil local SIP (cuentallamante), dirección 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 elmétodo entradaRegistro que se encarga de añadir una nueva entrada al registro dellamadas en la base de datos local. En esta tabla se guardan, para cada llamada, lossiguientes datos: tipo de llamada (saliente, entrante, perdida), número de clienteSIP llamante, número de cliente SIP llamado, fecha y hora de inicio y duración de lallamada. Si se trata de una llamada perdida, se muestra una notificación en la barrade estado para informar al usuario, como se puede ver en la figura 4.7(b).

El servicio ServiceSIP se detiene al salir de la aplicación mediante la opción Cerrardel menú principal. En este caso deben realizarse una serie de acciones para asegurarsede que se corta todo contacto con el servidor SIP: se desloga la cuenta SIP activa delservidor, se desactiva el broadcast receiver (para que no se puedan recibir llamadas) yse cancelan todas las notificaciones que estén 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.1.1.2 CALLRECEIVERSIPComo se ha visto en el apartado anterior, el servicio ServiceSIP sirve para preparar

la aplicación para utilizar SIP, realizar llamadas salientes y manejar las llamadasen curso. Para recibir llamadas entrantes, se crea este broadcast receiver, que seejecuta de manera automática cada vez que el terminal recibe una llamada SIP.CallReceiverSIP procesa todas las llamadas SIP entrantes, las recoge y las cedea la actividad CallDisplay, que se encarga de manejarlas mediante los métodoscontenidos en el servicio ServiceSIP.

De forma análoga al caso de la generación de una llamada saliente, lo primero quese hace es definir un listener de tipo SipAudioCall.Listener que se encarga de moni-torizar y manejar los eventos relacionados con la llamada SIP entrante. En este casosólo es necesario definir el comportamiento al colgar la llamada: se envía el broadcastpara añadir 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 continuación se recoge la llamada mediante el método takeAudioCall del objetoSipManager, utilizando los siguientes parámetros: intent perteneciente a la llamada en-trante y listener definido antes. Como los broadcast receivers no pueden conectarse a losservicios 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 elterminal. Se debe aclarar que recoger la llamada no implica descolgarla. Esto sólosignifica que la llamada ha llegado al terminal y que en el otro extremo ya se recibetono.

83


incomingCall = sipService.manager.takeAudioCall(intent , listener);

Una vez recogida, se pasa la llamada al servicio, se obtiene el identificador de lla-mada y se lanza la actividad CallDisplay, cuya pantalla es la que permitirá al usuariointeractuar con la llamada entrante (colgar/descolgar la llamada, activar/desactivaraltavoz, etc.). Esta pantalla es la mostrada en la figura 4.5.

La aplicación está programada de manera que sólo se puede llevar a cabo unaconversación a la vez. Si se recibe una nueva llamada entrante cuando ya hay una encurso, la nueva llamada se cuelga automáticamente (desviando al llamante al buzónde voz correspondiente) y no se refleja en el registro de llamadas.

4.3.1.1.3 SERVICEBINDER

Como se ha comentado en la explicación de ServiceSIP, la mayoría de los métodosdeclarados en este servicio se utilizan desde otras clases de la aplicación. Esto esposible mediante la utilización de binders, que permiten a las clases conectarse con elservicio e interactuar con él, pudiendo así utilizar sus métodos, como: realizar unallamada, colgar/descolgar, logar/deslogar una cuenta SIP, etc.

Con este fin se crea la clase de ayuda ServiceBinder, que actúa como claseintermedia y se encarga de crear el enlace (bind) entre el servicio y la clase que lonecesite. Por otra parte, algunas clases necesitan realizar ciertas acciones una vezestablecida la conexión con el servicio (por ejemplo, realizar una llamada). Estasacciones se definen también en esta clase, evitando así que se intente acceder alservicio antes de que se haya realizado el enlace.

4.3.2 SOFTPHONE PARA RESIDENTES

La aplicación LDDSoftphoneA está desarrollada específicamente para su utilización porparte de los residentes del centro. Su funcionamiento base es el mismo que el delsoftphone básico, con las siguientes características añadidas:

* Por motivos de seguridad, se quiere evitar que los residentes se alejen demasiadodel centro. Para ello se crea un sistema de alertas que utiliza el sensor GPS delterminal físico para determinar la ubicación del usuario y alertar a la residenciasi éste sale de una zona concreta.

* También se quiere evitar que los residentes se queden sin batería en el terminal,dejando totalmente inutilizado el sistema de alertas anterior. Por ese motivo secrea también un mecanismo para que los trabajadores de la residencia puedan

84


FIGURA 4.8: Listado de cuentas con acceso protegido por contraseña.

saber si el nivel de batería del terminal de un residente desciende del 15%.

Los cambios de estado de los residentes (alertas activadas/desactivadas) así comolas coordenadas de posicionamiento se guardan en la base de datos remota. El accesoa esta base de datos así como todas las peticiones que se pueden realizar sobre ellase han encapsulado en una clase llamada DBRemoteHelperA, facilitando así el accesodesde cualquier clase de la aplicación que lo requiera.

Cada residente tiene una entrada en la tabla de alertas (MyAlerts) que se crea, deforma automática, al asignarle una cuenta SIP en el listado de cuentas de la aplicación.A partir de ese momento, se puede monitorizar al usuario del terminal. Cada cambioque se realice sobre el listado de cuentas (añadir, editar o borrar una cuenta) quedareflejado también en la base de datos remota. Por ese motivo, el acceso al listadode cuentas de esta aplicación está protegido por contraseña, de forma que sólo lostrabajadores del centro pueden acceder a ella, como se puede ver en la figura 4.8. Asíse evita que los residentes puedan realizar cualquier modificación sobre las cuentasSIP (como cambiar la cuenta con la que están logados o eliminarla). De esta forma, seevita también que puedan modificar los datos relativos a la cuenta (nombre y número)que constan en la base de datos remota y que sirven a los trabajadores del centro paraidentificarlos.

85


4.3.2.1 ALERTAS DE BATERÍA

El sistema Android genera dos eventos relacionados con el nivel de batería delterminal: cuando la batería está baja (por debajo del 15%) y cuando la batería seencuentra en proceso de carga (cargando y por encima del 20% de su capacidad). Enesta aplicación se capturan estos eventos y se actúa acorde a la situación, evitando asíque la aplicación tenga que monitorizar el nivel de batería del dispositivo de formacontinua, lo que resulta ineficiente.

Con este objetivo, se crea BatteryLevelReceiver, un broadcast receiver que seencargará de manejar las alertas de batería generadas por el propio terminal. Paraque la aplicación sea capaz de capturar estos eventos, se define el broadcast receiveren el AndroidManifest de la siguiente manera, indicando el nombre de los even-tos 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 batería (batería 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, puedenocurrir cuando la aplicación 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 ALERTAS DE POSICIONAMIENTO

Esta aplicación está diseñada para utilizar el sensor GPS del terminal físico donde estáinstalada para controlar la ubicación de su usuario (en este caso, el residente) y evitarasí que éste salga de una zona marcada como segura o permitida. También se añadela opción de monitorizar la ubicación de un residente en el interior de esta zona demanera temporal, referido en este documento como seguimiento. Los pasos seguidospara lograr esto se detallan a continuación.

Para poner en marcha las alertas de posicionamiento ha sido necesario modi-ficar parte del softphone básico así como añadir un nuevo servicio a la aplicación,

86


AlertsService, que se encarga de manejar las alertas de posicionamiento y que seexplicará más adelante.

El sistema Android proporciona una serie de herramientas de localización que seutilizan en este caso para monitorizar la posición del usuario de la aplicación y activarlas alertas de posicionamiento cuando convenga. Estas alertas, que permiten saber siel usuario entra/sale de la zona permitida, se activan mediante este método, que seejecuta al iniciarse la aplicación:

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 delterminal. Para activar las alertas se utiliza el método addProximityAlert, que generauna alerta de proximidad al salir/entrar el usuario de la zona especificada por lossiguientes parámetros: latitud y longitud (punto central), radio que delimita la zonaalrededor del punto central, duración de la alerta (siempre encendida) y clase quemanejará la alerta (AlertsService). En este caso, las coordenadas (latitud, longitud)pertenecen a las coordenadas de la residencia y el radio está definido en unos 100metros (aunque al no disponer de conexión de datos en el terminal de prueba, el radioutilizado es de sólo 10 metros). Al cerrar la aplicación se eliminan estas alertas deproximidad para que no se activen una vez cerrada.

Las peticiones de seguimiento, que también maneja el servicio AlertsService,se reciben en esta aplicación a través de llamadas procedentes de las extensiones deseguimiento de Asterisk. El encargado de lanzar el servicio en este caso, por tanto, esel broadcast receiver que maneja las llamadas entrantes y hay que modificarlo para quetrate de forma diferente este tipo de llamadas. Si el identificador de la llamada recibidapertenece a una de las extensiones de seguimiento de Asterisk definidas anteriormente(034 o 035), se inicia/detiene el protocolo de seguimiento. Estas llamadas deben pasardesapercibidas 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


la llamada, se utiliza el siguiente método que, análogamente, inicia/detiene el servicioAlertsService 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, también se realizan modificaciones en el servicio ServiceSIP,concretamente, se añaden dos métodos nuevos que se utilizarán desde el servicioAlertsService. El método initiateLostCall realiza una llamada perdida a la extensiónde emergencia de Asterisk (033, alerta de localización) para notificar a la recepcióndel centro que ha habido un evento (entrada/salida de la zona permitida). Este tipode llamadas se realizan de forma automática, sin conocimiento por parte del usuariodel terminal y, por tanto, no aparecen en el registro de llamadas. El método whoAmIse usa para obtener el número de usuario de la cuenta SIP con la que está logado elresidente al servidor SIP.

4.3.2.2.1 ALERTSSERVICE

El servicio AlertsService es la clase más importante de esta aplicación y se encargade manejar las alertas de posicionamiento y las peticiones de seguimiento de losresidentes por parte de la recepción del centro.

Este servicio se lanza al producirse una de estas dos situaciones: al generarse unaalerta 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 dónde se haejecutado la llamada (cuál de estas situaciones ha ocurrido) y se actúa en consecuencia.

Para diferenciar entre estas situaciones, se utiliza el parámetro extra contenido enel objeto intent que se le pasa al servicio, de forma automática, al iniciarlo. Al pro-ducirse una alerta de localización, se inicia este servicio añadiendo un extra. Este ex-tra es un booleano (LocationManager.KEY_PROXIMITY_ENTERING) que toma diferentevalor en función de si se ha producido una entrada (true) o una salida (false) de la zonapermitida. En caso de haberse solicitado un seguimiento, este extra no existe.

88


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 función del tipo dealerta (entrada/salida o seguimiento) y del estado anterior del servicio. Esto últimose tiene en cuenta a fin de corregir los errores derivados de la utilización de lascoordenadas GPS obtenidas del dispositivo, que pueden generar varias alertas delmismo tipo seguidas, debiendo actuar sólo 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), seprepara el servicio para que monitorice los cambios de posicionamiento del dispositivo.Como se ha comentado anteriormente, la obtención de las coordenadas GPS del termi-nal se realiza mediante un objeto de tipo LocationManager. Este objeto dispone de unmétodo (requestLocationUpdates) que permite realizar acciones siempre que se produz-can cambios de posicionamiento definidos con los siguientes parámetros: proveedor delocalización (GPS), intervalo mínimo entre notificaciones en milisegundos (30.000) ymetros (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


isAlreadyOn = true;

}

}

Como se ha visto en el código anterior, el objeto de tipo LocationListener es elencargado de actuar cada vez que se produce un cambio en las coordenadas GPS deldispositivo. En este caso se ha implementado una clase propia (MyLocationListener)que permite definir el comportamiento deseado para esta aplicación. Aunque hay quedefinir todos los métodos de la clase, sólo se implementa el método onLocationChange:al detectarse un cambio de posición, se envían las nuevas coordenadas al servidor,insertándolas 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 continuación, se realiza de forma automática una llamada a la extensión de emer-gencia de Asterisk (033, alerta de localización). Esta llamada pondrá en contacto al re-sidente que ha generado la alarma con el softphone de recepción mediante una llamada

90


SIP. Mientras tanto, se activa el flag de alerta de la base de datos remota y se envíala primera coordenada. De esta forma, se asegura que siempre habrá una coordenadaintroducida en la base de datos para ese residente, evitando problemas al obtener lascoordenadas desde el softphone de recepción (si se intentan obtener coordenadas antesde 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 aplicación estará introduciendo la ubicación del residente en la base de datos remota.

Cuando el residente entra en la zona permitida, se vuelve a realizar una lla-mada a la extensión de emergencia de Asterisk y a continuación se desactiva el flagde alerta del usuario en la base de datos remota y se detiene el servicio. Al dete-nerse, se desactivan las actualizaciones de posicionamiento, logrando así que el serviciodeje 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 puedenobtener falsas entradas/salidas de la zona que afectarían al buen funcionamiento dela aplicación. En caso de recibirse una falsa salida (el residente ya se encuentra fuerade la zona) el servicio no hace nada. En caso de recibir una falsa entrada (el residenteya se encuentra dentro), se detiene el servicio que se acaba de iniciar y no se realizaninguna acción más.

Petición de seguimiento del residente

91


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. Elservicio debe enviar las coordenadas GPS con la posición del residente a la base dedatos remota. En este caso, se ejecuta también el método checkExitingZone, explicadoantes, que pone en marcha la actualización de posicionamiento y se inserta, igual queen 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 lanzael servicio, simplemente se ejecuta el método onDestroy del mismo, que detiene elservicio y desactiva las actualizaciones de posicionamiento, dejando de enviar lascoordenadas a la base de datos remota.

4.3.3 SOFTPHONE PARA LA RECEPCIÓN DEL CENTRO

La aplicación LDDSoftphoneB está diseñada especialmente para su utilización desde undispositivo que se encuentre en la recepción del centro. Partiendo de las característicasdel softphone básico, se añaden las siguientes funcionalidades:

* Se crea un sistema de comprobación de alertas de posicionamiento consistente enun mapa que permite monitorizar la ubicación de los residentes que se encuen-tran fuera de la zona permitida. Además, por motivos de seguridad, se añade laposibilidad de solicitar el seguimiento de un residente en concreto aunque éste seencuentre dentro de la zona permitida. Su ubicación también aparecerá marcadaen el mapa.

* Se incluye un sistema de comprobación de las alertas de batería baja generadaspor los dispositivos de los residentes. De esta manera, los trabajadores podránalertar a los residentes de éste problema y solventarlo.

Para comprobar si hay residentes en estado de alerta (de posicionamiento obatería) y obtener sus coordenadas, esta aplicación debe consultar a la base de datosremota. Por lo tanto, se crea una clase de ayuda llamada DBRemoteHelperB similar a lautilizada en la aplicación anterior, pero con peticiones a la base de datos adaptadas alas necesidades de esta aplicación.

92


FIGURA 4.9: Menú principal del softphone para la recepción del centro.

Se añaden al menú principal dos opciones que permiten al usuario acceder a laspantallas que le permitirán comprobar si hay alertas de posicionamiento o bateríaactivadas. Por tanto, el aspecto del menú de la pantalla principal de esta aplicación esel mostrado en la figura 4.9.

4.3.3.1 COMPROBACIÓN DE ALERTAS DE BATERÍA

Los terminales físicos de los residentes no deben quedarse nunca sin batería, ya queesto inutilizaría el sistema de alertas de posicionamiento detallado en la aplicaciónanterior. Para evitarlo, se diseña un mecanismo que permita a los trabajadores delcentro (en este caso, al personal de recepción) comprobar el estado de la batería delos terminales de los residentes mediante consultas a los flags de alerta battery_flag dela base de datos remota.

El sistema Android proporciona una herramienta que permite activar una especiede alarma que se utiliza, en este caso, para comprobar de forma periódica si hay alertaspor batería baja en la base de datos remota. Esta alarma se activa mediante el siguientemétodo, que se ejecuta al iniciarse la aplicación:

/** Activa una alarma cada 30 minutos que comprueba si hay alertas de

bateria baja en la DB remota */

93


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 (30s para test) */

long startTime = SystemClock.uptimeMillis () +30000;

/** tiempo de repeticion de alarma cada 30mins (1min 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, indicandoqué se debe hacer cada vez que salte (en este caso, comprobar las alertas de bateríade la base de datos remota). La alarma se activa mediante el comando setRepeating,especificando los siguientes parámetros: tipo de alarma, tiempo de inicio, cadacuánto debe repetirse y la clase que manejará la alarma (BatteryLevelChecker).Este tipo de alarmas se activan aunque la aplicación no esté corriendo, pero sedeshabilitan al reiniciar el terminal. Se debe tener en cuenta que los tiempos finalesestablecidos para esta alarma son los que se han utilizado para realizar las pruebas y,en ningún caso serían los definitivos si se decidiera utilizar esta aplicación para uso real.

El servicio BatteryLevelChecker, de tipo IntentService, se encarga de comprobarsi hay alertas de batería en la base de datos ubicada en el servidor. A diferencia de losservicios utilizados hasta ahora en las aplicaciones desarrolladas, los IntentService seutilizan para manejar peticiones asíncronas bajo demanda y se detienen por si mismosal acabar de ejecutar su código. Su funcionamiento es simple: si hay alertas de bateríabaja, muestra una notificación en la barra de estado para informar al usuario de laaplicación (a la recepción del centro), como se puede ver en la figura 4.10(a); si nohay alertas, no hace nada y, en caso de haber una notificación anterior no comprobadaen la barra de estado, la cancela.

Como interesa que la recepción del centro sepa en todo momento si los terminalesde los residentes se quedan sin batería, este servicio se ejecuta periódicamente aunquela aplicación no esté abierta. Por ello, antes de acceder a la base de datos remota, secomprueba si el terminal está conectado a la red tanto por WiFi como por conexión dedatos.

Al pulsar sobre la notificación que indica que hay alertas de batería se accede a

94


FIGURA 4.10: a) Notificación de alertas de batería. b) Listado de alertas de batería.

un listado con los nombres y números de usuario de los residentes cuyos terminalestienen un nivel de batería por debajo del 15% de su capacidad. Este listado, que semuestra en la figura 4.10(b), no se actualiza de forma automática, por lo que si sedeja visible esta pantalla por tiempo indefinido, la información mostrada puede serfalsa. Por ello se incluye, en la parte superior de la pantalla, una línea de texto dondese indica la fecha y hora de la última actualización. La actualización de los datos sepuede realizar de dos maneras: mediante la opción Actualizar listado disponible en elmenú de esta pantalla o pulsando de nuevo sobre la notificación de alerta de batería(en caso de estar presente en la barra de estado).

A este listado también se puede acceder mediante la opción Alertas Batería delmenú principal de la aplicación. Si al acceder o actualizar el listado no hay ningunaalerta activa, se muestra un diálogo informando de ello al usuario.

4.3.3.2 COMPROBACIÓN DE ALERTAS DE POSICIONAMIENTO

Como se ha explicado anteriormente en este capítulo, al producirse una entrada/salidade la zona permitida por parte de un residente, lo primero que hace la aplicación delresidente es realizar una llamada a la extensión de emergencia de Asterisk (033, alerta

95


de localización). Esta llamada hace que Asterisk ponga en contacto, mediante unallamada SIP, a estas dos partes: el residente que ha generado la alerta y la recepcióndel centro (es decir, el usuario de esta aplicación). Al finalizarse la llamada, se muestraun plano de la zona (alrededor de la residencia) con la ubicación de los residentesque se encuentran fuera de la zona permitida. De esta forma, la recepción del centropuede saber la localización del residente con el que acaba de hablar.

Con este objetivo, se crea la actividad ShowLocationMap, que muestra el planocon la ubicación de los residentes en estado de alerta o en seguimiento. La solicitudde inicio/finalización de un seguimiento se realiza también desde este plano. Elfuncionamiento concreto de esta clase se detallará más adelante.

Igual que en la aplicación diseñada para los residentes, se han realizado algunasmodificaciones respecto al softphone básico para adaptarlo a las necesidades de estaaplicación. En este caso, se destacan los cambios realizados en el broadcast receiverCallReceiverSIP y en el servicio ServiceSIP.

Como ya se ha comentado, estas aplicaciones no están diseñadas para manejarmás de una llamada a la vez. Si se recibe una llamada nueva durante una llamadaen curso, la llamada nueva se cuelga (enviándola al buzón de voz) y no consta en elregistro 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 zonacon la localización de los residentes que están en estado de alerta de posicionamiento.De esta forma, aunque no se pueda poner en contacto al residente que ha generado laalerta con la recepción del centro, sí se avisa del estado de alerta del mismo.

Para mostrar el mapa de localización en este caso, se utiliza el siguiente métododesde 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 añade un método nuevo en el servicio ServiceSIP que se utilizarádesde el mapa de localización para solicitar el inicio/finalización de un seguimiento.El método initiateFollowUpCall es muy similar al que utiliza la aplicación para realizarllamadas SIP pero con algunas modificaciones. En este caso, se realiza una llamadaperdida a la extensión de seguimiento de Asterisk indicada (034 o 035), que se encar-

96


gará de notificar al softphone del residente indicado que inicie/detenga el protocolode seguimiento (envío de las coordenadas GPS a la base de datos remota). El númerode usuario del residente al que se quiere monitorizar se indica a Asterisk al estable-cer la llamada mediantes tonos DTMF, como se puede ver en el código mostrado acontinuación. 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 SHOWLOCATIONMAP

La actividad ShowLocationMap, de tipo MapActivity, muestra un mapa de losalrededores de la residencia con la ubicación de los residentes que se encuentran fuerade la zona permitida. También permite solicitar la localización de un residente que

97


FIGURA 4.11: a) Mapa de alertas con 2 usuarios (mostrando la información de unode ellos). b) Mapa con 2 usuarios fuera de la zona permitida (rojos) y un usuario enseguimiento (verde).

esté dentro de la zona permitida (seguimiento) siempre y cuando se puedan obtenersus coordenadas GPS (se esté al aire libre). Se utilizan marcadores sobre el mapa decolores distintos para distinguir entre los dos casos: rojos (residentes en estado dealerta) y verde (residente en seguimiento). Al pulsar sobre estos marcadores, apareceen pantalla información sobre el residente al que representan: nombre y número deusuario. La información 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 dealerta (fuera de la zona permitida) y la información de uno de ellos en pantalla. En lafigura 4.11(b) se muestra, además, la posición de un usuario en estado de seguimiento.

Para poder utilizar mapas en una aplicación de Android, se debe obtener unaclave (Google Maps API key) que permita integrar Google Maps en la aplicación. Estaclave se puede conseguir en la página http://code.google.com/android/add-ons/

google-apis/mapkey.html de forma gratuita. Una vez obtenida, debe añadirse en ladefinición del layout de la actividad que utiliza el mapa, concretamente como uno delos parámetros del objeto MapView:

98

http://code.google.com/android/add-ons/google-apis/mapkey.html

http://code.google.com/android/add-ons/google-apis/mapkey.html


<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 unallamada entrante de emergencia, de forma automática; o a través de la opción MapaAlertas del menú principal de la aplicación.

Al lanzar la actividad, antes de poder mostrar el mapa, hay que configurar algunosaspectos del mismo, así como de los componentes que aparecerán en él (marcadores).Esta definición se puede ver en el código 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 100ms */

mHandler.postDelayed(mUpdateTimeTask , 100);

}

Primero se definen los marcadores que aparecerán sobre el mapa (rojos y verdes). Acontinuación se crea una referencia al mapa mapView y se especifican algunos paráme-tros de su configuración inicial: aspecto tipo satélite y nivel de zoom (17). Por último,utilizando un objeto de tipo Handler, se inicia el proceso de marcar sobre el mapa laposición de los residentes que se encuentren en estado de alerta. Los objetos Handler

99


FIGURA 4.12: Diálogo mostrado cuando no hay alertas de posicionamiento en elmapa.

permiten, entre otras cosas, programar la ejecución de un objeto Runnable cada ciertotiempo. En este caso, se utiliza el objeto mUpdateTimeTask, cuyo código se muestra acontinuación, y que refresca la información 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 30s */

mHandler.postAtTime(this , startTime + 30000);

}

};

El método updateMarkersPosition es el encargado de actualizar la posición de losmarcadores en el mapa y refrescarlo. Para ello, se comprueba la base de datos remotacon el fin de obtener la información relativa a los residentes que se encuentran fuera dela zona permitida y se muestra en el mapa su última localización disponible (últimascoordenadas introducidas en la tabla MyCoordinates para cada residente). En caso deno existir ningún usuario en estado de alerta, se muestra un diálogo informando al

100


usuario de la aplicación de este hecho y dándole la opción de solicitar un seguimiento(figura 4.12). Además, si hay algún residente en seguimiento, se muestra también suúltima localización 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


Para poder dibujar elementos encima del mapa (como los marcadores) se debe uti-lizar un objeto de tipo Overlay. Para esta aplicación, se ha creado una clase propia(MapOverlay) que extiende a una clase de tipo lista de Overlays, modificando su com-portamiento. Se crean dos constructores distintos (uno para cada tipo de marcador)que, a partir de la información obtenida de la base de datos, crearán los objetos detipo Overlay que se dibujarán encima del mapa. También se incluyen varios métodosque permiten, entre otras cosas, dibujar los marcadores (draw) y especificar el compor-tamiento 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


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 aplicación puedeiniciar/finalizar el seguimiento de la posición de un residente que no se encuentreen situación de alerta (dentro de la zona permitida). Para ello, como se ve en lafigura 4.13(a), se incluyen las opciones Iniciar Seguimiento y Finalizar Seguimiento en

103


FIGURA 4.13: a) Menú del mapa de alertas. b) Diálogo para iniciar un seguimiento.

el menú de esta pantalla.

Al seleccionar Iniciar Seguimiento, aparece en pantalla el diálogo de lafigura 4.13(b) solicitando el número de usuario del residente al que se quiere localizar.Al introducir el número deseado, se realiza de forma automática una llamada a la ex-tensión de inicio de seguimiento de Asterisk (034) para avisar al softphone de dichoresidente que se ha pedido un seguimiento y que por tanto debe empezar a enviar suscoordenadas GPS a la base de datos remota. Por último, se fuerza una actualización dela información 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 automática una llamadaa la extensión de finalización de seguimiento de Asterisk (035) para avisar al softphonedel residente que ya puede dejar de enviar sus coordenadas a la base de datos remota.

104


Por último, como en el caso anterior, se fuerza una actualización 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 información mostrada sobre el mapa seactualiza de forma automática cada 30 segundos. De todos modos, si se desea forzaruna actualización en un momento concreto, se puede hacer desde la opción Actualizardisponible en el menú de esta pantalla.

105


106

5Conclusiones y líneas de futuro

LLEGADOS A ESTE PUNTO y después de revisar los objetivos planteados en la introduc-ción de esta memoria, podemos decir que se han cumplido los objetivos definidos

para este proyecto.

Hay que recalcar que, aunque este proyecto está enfocado como un caso real(implementación de una plataforma VoIP en una residencia de ancianos), no estárealmente desarrollado para su utilización inmediata, sería más bien como una pruebapiloto.

Se ha realizado todo el trabajo posible con los recursos disponibles (que a vecesresultaron limitadores) tanto a la hora de desarrollar el proyecto como de realizar laspruebas correspondientes. A continuación se comentan los principales problemas yfactores que habría que mejorar en revisiones futuras:

* Para este proyecto se buscó una forma de integrar la VoIP en una aplicaciónAndroid, utilizando el protocolo SIP, que es el más extendido entre los usuariosde VoIP. Al final se decidió utilizar la API SIP nativa que proporciona el propioAndroid. De todas formas, esta API está muy limitada y, aunque fue suficientepara la realización de este proyecto, se ha descubierto que no es la más apro-piada 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 APIpara congraciarse con las operadoras de telefonía móvil. En este caso, se tuvieronque rootear los dos terminales de pruebas para poder desbloquear su utilización.Además, esta API no soporta la utilización conjunta con servidores STUN, con loque no se han podido solucionar los problemas de NAT (inherentes a SIP) queya se comentaron en el capítulo 2. También se descubrió que, aunque no seespecificaba de ninguna manera en la documentación de la API, su utilización

107

CAPÍTULO 5. CONCLUSIONES Y LÍNEAS DE FUTURO

con conexión de datos no es automática: hay que modificar archivos internos delsmartphone a los que, en principio, un usuario normal no debería tener acceso.

Por estos motivos, si se deseara utilizar los softphones desarrollados en un entornopráctico, habría que buscar otra API SIP externa e integrarla en las aplicaciones.

* El softphone de recepción consulta la base de datos cada cierto tiempo para versi hay alertas de batería activadas, método que resulta ineficiente. La decisión decontrolar el nivel de batería de los dispositivos de los residentes se tomó una vezfinalizada la programación de las aplicaciones, por lo que se buscó una soluciónrápida que permitiera obtener los resultados requeridos, pero sin tener que estu-diar opciones fuera del conocimiento que se tenía en aquel momento. Se deberíabuscar una alternativa para evitar que la aplicación realice accesos y comproba-ciones innecesarias a la base de datos, mejorando así la autonomía del dispositivo.

* Añadir securización en Asterisk utilizando el protocolo de seguridad SRTP(Secure Real-time Transport Protocol). Debido a la evolución que sufrió elproyecto, esta funcionalidad quedó en un segundo plano y queda entonces pararevisiones futuras.

* Durante el desarrollo de la centralita de telefonía aparecieron dos problemas paralos cuales, a la fecha de entrega, no se ha encontrado solución. El tratamiento deestas cuestiones queda, por tanto, pendiente para resolver en futuras revisiones.

1. Detección de colgado: Asterisk no es capaz de detectar cuando una llamadaentrante a la PBX cuelga. Si la finalización de la llamada proviene del ex-terior, Asterisk no lo detecta y sigue haciendo la rutina marcada hasta quellega a un Hangup() (Asterisk cuelga y libera la línea). Si no se llega a unHangup(), la línea queda bloqueada y para desbloquearla hay que reiniciarel servicio Asterisk. Se proporciona una solución provisional al problemahaciendo que se libere la línea en casos de bloqueo mediante timeouts.

2. Identificador de llamada: Asterisk no obtiene el CallerID de las llamadas quellegan a la PBX. Esto puede ser debido a varios motivos, entre los que sedestacan: que la red Ibercom no ofrece este servicio; o existe algún elementointermedio que elimina el CallerID. Por este motivo, no se ha utilizado estafuncionalidad en la PBX.

* El entorno de pruebas de este proyecto sería un aspecto a mejorar. Las aplica-ciones deben estar conectadas a la red en todo momento. Esto supone un pro-blema ya que el campus universitario no dispone de una red wifi uniforme entoda su extensión (hay zonas sin cobertura fuera de los edificios). Lo ideal hu-biera sido disponer de smartphones con conexión de datos para poder realizaralgunas de las pruebas, pero diversos factores (como la elección de la API SIP) nolo permitieron.

108

5.1. VALORACIÓN PERSONAL

5.1 VALORACIÓN PERSONAL

ANIVEL PERSONAL, debo decir que he aprendido mucho con este proyecto, ya quetodas las tecnologías que se han tratado en él (Android, Asterisk, bases de datos

MySQL, etc.) eran totalmente nuevas para mi.

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 páginasweb, foros de grupos y comunidades especializadas en cada una de dichas tecnologías.Esto es algo que valoro mucho, ya que es una situación habitual en el mundo laboral.

Desde que empecé a trabajar en este proyecto me he dado cuenta de que eldesarrollo de aplicaciones Android es algo que me interesa bastante y en lo que megustaría trabajar en un futuro.

En conclusión, considero que este proyecto ha resultado ser una experiencia muypositiva (aunque algo dura) de cara a mi futuro laboral y me ha permitido aprender yaplicar nuevas tecnologías que me pueden resultar muy útiles para esta nueva etapa demi vida.

109

CAPÍTULO 5. CONCLUSIONES Y LÍNEAS DE FUTURO

110

6Bibliografía

Publicaciones:

* Madsen, Leif; Van Meggelen, Jim; Bryant, Russell. Asterisk: The Definitive Guide(3rd Edition). O’Reilly, 2011.

* Digium 800 Series User Manual. Digium, 2009.

* Lee, Wei-Meng. Beginning Android Application Development. Wiley Publishing,2011.

* Murphy, Mark L. The Busy Coder’s 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 línea]. 2006.

* Margarit, Genís. Administración de sistemas Asterisk [apuntes cursillo]. 2011.

Enlaces de interés:

* www.voip-info.org

Guía de referencia para todo lo relacionado con VoIP.Wiki con documentación sobre Asterisk: consultada para la configuración de losmódulos de Asterisk y las funciones y aplicaciones utilizadas en el dialplan.

* www.asterisk.org

Página oficial de Asterisk. Contiene documentación de Asterisk y Dahdi.

111

www.voip-info.org

www.asterisk.org

CAPÍTULO 6. BIBLIOGRAFÍA

* http://stackoverflow.com

Foro para programadores tanto profesionales como amateurs.Utilizado para resolver problemas relacionados con la programación de las apli-caciones Android.

* http://developer.android.com/index.html

Página web oficial para desarrolladores de aplicaciones Android. Contienedocumentación, guías de referencia, ejemplos de código, etc.

112

http://stackoverflow.com

http://developer.android.com/index.html

AInstalaciones y configuraciones relacionadas con

Asterisk

A.1 Instalaciones relacionadas con Asterisk

A.1.1 PRERREQUISITOS

Antes de empezar, hay que verificar que se tienen instaladas en el servidor todas lasdependencias que los paquetes básicos necesitan. Para no tener que hacerlo manual-mente (uno a uno), el paquete Asterisk contiene un script que se encarga de instalartodas las dependencias y prerrequisitos necesarios. Para ejecutar el script, escribimoslas siguientes líneas 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 escri-biendo 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 algunoscambios en este paquete. Es por eso que, una vez instalado, deberá recompilarse.

113

CAPÍTULO A. INSTALACIONES Y CONFIGURACIONES RELACIONADAS CON ASTERISK

A.1.3 LIBPRI

La compilación e instalación de la librería libPRI es bastante similar al proceso seguidopara DAHDI. Con el paquete descargado y descomprimido, se escriben las siguienteslíneas en un terminal:

> cd /usr/src/libpri -1.4.12

> make

> make install

A.1.4 ASTERISK

La compilación e instalación de Asterisk es un poco más compleja que las anteriores,ya que añadiremos algunos elementos extras a su instalación básica (por defecto).

Primero se instala la compatibilidad mp3 para que Asterisk pueda manejar archivoscon este formato. Como en el caso de los prerrequisitos, el paquete Asterisk incluye unscript con este fin. Para ejecutarlo, se escriben las siguientes líneas en un terminal:

> cd /usr/src/asterisk -10.0.0

> ./ contrib/scripts/get_mp3_source.sh

> ./ contrib/scripts/get_mp3_source.sh install

A continuación, ya se puede empezar con la instalación de Asterisk. Se ejecutan losprimeros comandos en un terminal:

> cd /usr/src/asterisk -10.0.0

> ./ configure

> make menuselect

Con el último comando aparece un menú con interfaz gráfica que permite especi-ficar los módulos de Asterisk que se quieren incluir en la instalación. Los módulos dela instalación por defecto ya aparecen marcados. Además de estos, se seleccionan unasaplicaciones del dialplan que estaban incluidas por defecto en versiones anteriores y lospaquetes de sonidos (en inglés y castellano) y de música 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. INSTALACIONES RELACIONADAS CON ASTERISK

[*] 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 selección y se vuelve al terminalpulsando el botón Save and Exit.

Con todos los módulos especificados, ya se puede continuar con la compilación einstalación de Asterisk. Para ello, se escriben las siguientes líneas en el terminal:

> make

> make install

> make config

> make samples

Por último, se ejecuta el siguiente comando, que comprime los archivos tipo log quegenera Asterisk, ahorrando espacio en disco:

> make install -logrotate

115


A.1.5 CANCELADOR DE ECO OSLEC

Los archivos necesarios para descargar e instalar Oslec no se encuentran en un paquetepropio, sino que están incluidos en el kernel de Linux. Por tanto, se descarga el LinuxKernel source de la versión que hay instalada en el servidor y se descomprime. Para esteproyecto, la versión 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 continuación, se crean dentro del paquete DAHDI los directorios donde se deberánubicar los archivos obtenidos del kernel y se copian los archivos relativos a Oslec enestos 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 líneas relativas al can-celador 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 comose especifica en el apartado anterior. Verificamos que se han ejecutado los cambiosmirando el resultado de la compilación. Si aparecen las siguientes líneas, Oslec estáinstalado e integrado con DAHDI y sólo 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 RECONOCIMIENTO DE VOZ

Los paquetes necesarios para instalar las librerías Pocketsphinx (librería de re-conocimiento) y Sphinxbase (librería de soporte) se pueden descargar desde la página

116

A.2. ARCHIVOS DE CONFIGURACIÓN ASTERISK

del proyecto: http://cmusphinx.sourceforge.net/. Como se ha hecho con los otrospaquetes, se descargan, se ubican en el directorio /usr/src y se descomprimen.

Primero se instala la librería de soporte Sphinxbase en el servidor mediante lossiguientes 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 librerías correctamente, se con-figura el path para que sepa dónde buscar las librerías compartidas.

> export LD_LIBRARY_PATH =/usr/local/lib

> export PKG_CONFIG_PATH =/usr/local/lib/pkgconfig

A continuación se instala la librería Pocketsphinx, utilizando el mismo procedi-miento:

> cd /usr/src/pocketsphinx -0.7

> ./ autogen.sh

> make

> make install

Para comprobar que la instalación de ambas librerías se ha realizado correctamentese deben obtener las siguientes líneas 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 Archivos de configuración Asterisk

A.2.1 CANALES DAHDI

Se añaden las siguientes líneas al final del archivo /etc/asterisk/chan_dahdi.conf:;General options

usecallerid = yes

hidecallerid = no

callwaiting = yes

usecallingpres=yes

callwaitingcallerid=yes

threewaycalling = yes

117

http://cmusphinx.sourceforge.net/


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 USUARIOS

Se añaden las siguientes líneas 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


[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



[506](501) ;despacho directora

[507](501) ;movil directora

[508](501) ;casa directora

[509](501) ;psicologa

[500](501) ;jefa enfermeras

A.2.3 DIALPLAN

Se añaden las siguientes líneas 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


include => PC_a_RTC

include => parkedcalls

;desvio de llamadas activo de llamante a 50X

exten => _*21*50X,1,Answer ()

same => n,Set(DB(CFIM/${CALLERID(num)})=${EXTEN :-3})

same => n,Hangup ()

;desvio de llamadas de extension 50X desactivado

exten => _#21#50X,1,Answer ()

same => n,Verbose(Cancelado desvio extension ${EXTEN :-3} a

${DB_DELETE(CFIM/${EXTEN :-3})})

same => n,Hangup ()

; sala de conferencias interna limite 3 personas


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]


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)

same => n,Hangup ()


same => n,Read(num ,,3)

same => n,Set(CALLERID(num)=034)

same => n,Dial(SIP/${num},10)

same => n,Hangup ()





same => n,Hangup ()

120


[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,1,Answer ()

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


;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)

same => n,Hangup ()

;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)

same => n,Hangup ()

[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


same => n,PlayBack(custom/asr_oficina_cerrada)

same => n,VoiceMail (501) ; recepcion

same => n,Hangup ()

[centralita_ASR]

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)

;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(busy),PlayBack(tt -weasels)


;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)


123


same => n(busy),PlayBack(queue -callswaiting)

same => n,Queue(cola_enfermeria ,,,,60)

same => n,PlayBack(custom/asr_max_t_cola)


;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)


;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))

same => n,Hangup ()

;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


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 añaden las siguientes líneas 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 unaemisora 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 BUZÓN DE VOZ

Se añaden las siguientes líneas 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


[default]

; buzones de voz para los residentes

200 => 123, residente1 ,[email protected]



;buzones de voz para todos los trabajadores

501 => 123,Recepcion ,[email protected]

502 => 123, Trabajadora Social ,[email protected]

503 => 123, Gerocultora 1,[email protected]



506 => 123, Despacho Directora ,[email protected]

507 => 123, Movil Directora ,[email protected]

508 => 123,Casa Directora ,[email protected]

509 => 123,Psicologa ,[email protected]

500 => 123,Jefa Enfermeras ,[email protected]

A.2.5.1 GESTOR DE CORREO

Se configura el archivo /etc/ssmtp/ssmtp.conf añadiendo las siguientes líneas:

#

# Config file for sSMTP sendmail

#

# The person who gets all mail for userids < 1000

[email protected]

# 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

[email protected]

# Are users allowed to set their own From: address?

FromLineOverride=YES

AuthMethod=LOGIN

UseTLS=YES

UseSTARTTLS=YES

[email protected]

AuthPass=isgsbv2011

Se configura el archivo /etc/ssmtp/revaliases añadiendo las siguientes líneas:

# sSMTP aliases

#

126


# Format: local_account:outgoing_address:mailhub

#

root:[email protected]:smtp.gmail.com :587

A.2.6 FOLLOW ME

Se añaden las siguientes líneas 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 SALA DE CONFERENCIAS

Se añaden las siguientes líneas 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 COLAS

Se añaden las siguientes líneas 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 TRANSFERENCIA Y PARKING DE LLAMADAS

Se descomentan las siguientes líneas en el archivo /etc/asterisk/features.conf:

127


[general]

parkext => 700 ; What extension to dial to park

parkpos => 701 -720 ; What extensions to park calls on.

(defafult parking lot)

; These needs to be numeric , as

Asterisk starts from the start

position

; and increments with one for the next

parked call.

context => parkedcalls ; Which context parked calls are in

(default parking lot)

128

BInstalaciones y configuraciones relacionadas con

las aplicaciones Android

B.1 INSTALACIÓN ENTORNO DE DESARROLLO PARA

ANDROID

Prerrequisitos: Java JDK

El Android SDK utiliza el kit de desarrollo de Java (Java JDK), por lo tanto, eslo primero que hay que instalar en el servidor. El paquete JDK1 es necesario paradesarrollar aplicaciones y applets en Java (lenguaje que utiliza Android). Tambiénlleva incluido el JRE2, que sirve para lanzar aplicaciones y applets en Java. Sedescarga el paquete de la página 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 -6u26 -linux -x64.bin

> ./jdk -6u26 -linux -x64.bin

Eclipse

Se descarga la última versión de Eclipse en el servidor desde la página web oficial:http://www.eclipse.org/downloads/. La última versión disponible al iniciar esteproyecto, y por tanto la instalada, es la Eclipse Classic 3.6.2 (Helios). Lo colocamos enel directorio /home/ldd/Desarrollo.

1Java Development Kit2Java Runtime Environment

129

http://www.oracle.com/technetwork/java/javase/downloads/jdk-6u26-download-400750.html

http://www.oracle.com/technetwork/java/javase/downloads/jdk-6u26-download-400750.html

http://www.eclipse.org/downloads/

CAPÍTULO B. INSTALACIONES Y CONFIGURACIONES RELACIONADAS CON LAS

APLICACIONES ANDROID

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 líneas antes de la línea -vmargs:

-vm

/usr/src/jdk1 .6.0 _26/bin/java

Android SDK

Se descarga el SDK de Android de la página web oficial: http://developer.

android.com/sdk/index.html. En este caso, se elige la versión 14 para Linuxy tras aceptar la licencia, se guarda y descomprime el fichero en el directoriohome/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 líneas al finaldel 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 continuación se cierran todos los terminales abiertos, para que haga efecto el pathque se acaba de definir, se abre uno nuevo y se escribe la instrucción:

android

Con esta instrucción se accede al manager de Android, desde el que se puedeinstalar y actualizar el SDK, así como crear dispositivos virtuales para realizar laspruebas de las aplicaciones. En la figura B.1 se puede observar el aspecto del managerde Android al abrirlo.

130



B.1. INSTALACIÓN ENTORNO DE DESARROLLO PARA ANDROID

FIGURA B.1: Pantalla inicial del Android Manager.

Para instalar el SDK, se accede a la sección Available Packages y se pulsa el botónRefresh para que aparezca la lista de todos los paquetes que se pueden instalar. Lapantalla del Manager tendrá ahora el aspecto de la figura B.2. Se seleccionan todos lospaquetes y se pulsa Install Selected.

FIGURA B.2: Pantalla del Android Manager con todos los paquetes disponibles parainstalar.

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



las licencias y se pulsa el botón Install Acepted. Al acabar la instalación, se cierra elmanager y se continua con la instalación 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 pasosespecificados a continuación. Primero se abre Eclipse, y desde la pestaña Help

del menú, se escoge la opción Install New Software y se pulsa el botón Add. Enla ventana que aparece, hay que especificar el nombre del software que se quiereinstalar (Android Plugin) y la dirección 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 información en la dirección indicada, aparece en la pantalla elpaquete Developer Tools con los dos plugins que incluye: Android DDMS y Android

132

B.1. INSTALACIÓN ENTORNO DE DESARROLLO PARA ANDROID

Development, como puede verse en la figura B.5. Se selecciona todo y se pulsa el botónNext para que se comprueben las dependencias necesarias. En la pantalla siguiente(figura B.6) se aceptan los términos de la licencia y se pulsa Finish..

FIGURA B.5: Pantalla con los paquetes necesarios para instalar el plugin ADT.

133



FIGURA B.6: Pantalla para aceptar las licencias de los paquetes del plugin ADT.

Hecho esto, se empieza el proceso de descarga e instalación de los paquetesindicados antes y de todas las dependencias necesarias para que el ADT funcionecorrectamente. Al finalizar este proceso, se debe reiniciar Eclipse.

El último paso consiste en indicar a Eclipse la ubicación del Android SDK. Paraello seleccionamos la siguiente opción del menú Window > Preferences > Android ydonde pone SDK Location pulsamos el botón Browse y especificamos la carpeta dondeestá instalado el SDK de Android, que en este caso es:

/home/ldd/Desarrollo/android -sdk -linux_86

Se pulsa el botón Apply para que se cargue el Android SDK Content Loader. Unavez finalizado este proceso, aparece la pantalla de la figura B.7 en la que se ve unlistado con todo lo que se ha instalado. Con esto se consigue importar el Android SDKa Eclipse para disponer de las ayudas necesarias al escribir el código.

134

B.2. BASE DE DATOS REMOTA

FIGURA B.7: Pantalla de Eclipse con las opciones del Android SDK instaladas.

B.2 BASE DE DATOS REMOTA

B.2.1 INSTALACIÓN Y CONFIGURACIÓN

Para instalar el paquete LAMP (Linux, Apache, MySQL, PHP) en el servidor, se escribela siguiente línea en un terminal:

> tasksel install lamp -server

Para comprobar si se ha realizado correctamente la instalación, se abre un naveg-ador, se escribe la dirección 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 continuación se instala un cliente gráfico para gestionar la base de datos delservidor de forma más sencilla. Se instala el paquete mysql-navigator desde el gestorde 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



es indicar al cliente gráfico la ubicación de la base de datos (localhost en este caso),y el usuario y contraseña para acceder a la misma. Esto se hace con el menú de laventana Server que aparece al abrir el cliente, como se puede ver en la figura B.8.

FIGURA B.8: Definición de la ubicación de la base de datos con usuario y contraseña.

Al hacer esto, aparece la pantalla de la figura B.9. En el apartado Database aparecenlas bases de datos que son para la gestión interna de MySQL (information_schema,mysql). Para crear la base de datos que se va a utilizar en las aplicaciones, se clica conel botón derecho encima de Database y aparece la opción Create Database. Se escogeun nombre para la base de datos (ALCATRAZ en este caso) y ya aparece la nueva basede datos en el listado anterior.

136


FIGURA B.9: Pantalla inicial del cliente gráfico MySQL Navigator.

Por último, hay que crear las tablas que tendrá la base de datos. Como ya se hacomentado anteriormente, la base de datos del proyecto tiene dos tablas: MyAlerts yMyCoordinates. Para crear una tabla, se clica con el botón derecho encima del nombrede la base de datos (ALCATRAZ) y se escoge la opción Execute Query. Al crear lastablas, 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. Dela misma manera, en la figura B.11 se ve la query utilizada para crear la tabla decoordenadas MyCoordinates. Al ejecutar estas dos querys, se crean las dos tablas y seañaden a la base de datos ALCATRAZ tal y como se ve en la figura B.12. Con esto, yase tiene la base de datos preparada para su utilización desde las aplicaciones Android.

137



FIGURA B.10: Pantalla de creación de la tabla de alertas MyAlerts.

138


FIGURA B.11: Pantalla de creación de la tabla de coordenadas MyCoordinates.

139



FIGURA B.12: Base de datos Alcatraz con sus dos tablas: MyAlerts y MyCoordinates.

El último paso necesario es la creación de los scripts PHP que se utilizan paragestionar la base de datos.

B.2.2 SCRIPTS PHP

Los scripts PHP que se utilizan para gestionar la base de datos ALCATRAZ deben ubi-carse en el directorio de Apache, en este caso, /var/www/. Se añaden tantos scriptscomo operaciones se quieran realizar, utilizando los siguientes comandos en un termi-nal:

140


> cd /var/www/

> touch nombre_script.php

A continuación se presenta el código de todos los scripts PHP que se han utilizadoen este proyecto, diferenciando los utilizados por cada una de las aplicaciones. Pararealizar pruebas, estos scripts se pueden ejecutar directamente desde un navegadorescribiendo la instrucción con la siguiente nomenclatura en la barra de direcciones:

http :// localhost/nombre_script.php?arg1=value1&arg2=value2&arg3=value3 ...

B.2.2.1 SOFTPHONE 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



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


$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




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 ();

}



mysql_close ();

}

?>

B.2.2.2 SOFTPHONE RECEPCIÓN

• get_alert_coordinates.php

<?php



try {

$result = mysql_query("SELECT

MyCoordinates.user ,MyAlerts.name ,MyCoordinates.latitude ,

144


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



<?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. EXTENSIONES DE EMERGENCIA ASTERISK

B.3 EXTENSIONES DE EMERGENCIA ASTERISK

Las extensiones de emergencia que se utilizan en las aplicaciones se encuen-tran en el contexto [android_V A] del dialplan de Asterisk, en el archivo/etc/asterisk/extensions.conf:

[android_VA]


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)

same => n,Hangup ()





same => n,Hangup ()





same => n,Hangup ()

147



148

diseño de aplicaciones sobre voip con mecanismos de

Documents