Embed Size (px)
Citation preview
Diseño e implementación de una aplicación Android para la configuración de una central
Asterisk
Juan Carlos Carrillo Moreno
Nelson Javier Pinzón López
Universidad Distrital Francisco José de Caldas
Facultad de ingeniería
Ingeniería de sistemas
Bogotá D.C
Abril de 2017
Diseño e implementación de una aplicación Android para la configuración de una central
Asterisk
Juan Carlos Carrillo Moreno
Nelson Javier Pinzón López
Proyecto de Grado en Calidad de Monografía para Obtener el Título de Ingenieros de
Sistemas
Tutor
Ing. Luis Felipe Wanumen Silva
Universidad Distrital Francisco José de Caldas
Facultad de ingeniería
Ingeniería de sistemas
Bogotá D.C
Abril de 2017
Tabla de Contenido
Tabla de Contenido ................................................................................................................. 4
Introducción ............................................................................................................................ 8
1. Organización, Definición y Análisis................................................................................... 9
1.1 Tema. ................................................................................................................................ 9
1.2 Titulo................................................................................................................................. 9
1.3 Objetivos .......................................................................................................................... 9
1.3.1 Objetivo general............................................................................................................. 9
1.3.2 Objetivos específicos ..................................................................................................... 9
1.4 Descripción del Problema .............................................................................................. 10
1.5 Pregunta de Investigación ............................................................................................... 11
1.6 Alcances y Limitaciones ................................................................................................. 11
1.6.1 Alcances....................................................................................................................... 11
1.6.2 Limitaciones ................................................................................................................ 12
1.7. Justificación ................................................................................................................... 12
1.8 Marco de Referencia ....................................................................................................... 13
1.8.1 Marco Histórico ........................................................................................................... 13
1.8.1. Marco Teórico ............................................................................................................ 15
1.8.1.1 Linux ......................................................................................................................... 15
1.8.1.2 VoIP .......................................................................................................................... 16
1.8.1.3Asterisk ...................................................................................................................... 17
1.8.1.4 Aplicaciones Móviles ............................................................................................... 18
1.8.1.5 SIP- Session Initiation Protocol ................................................................................ 19
1.8.1.6 RMI: Remote Method Invocation (Invocación de Método Remota)........................ 21
1.9 Marco Metodológico ...................................................................................................... 22
1.9.1 Definición del Sprint.................................................................................................... 23
1.9.2 Definición de roles....................................................................................................... 23
1.9.2.1 Team ......................................................................................................................... 23
1.9.2.2 Scrum Master ......................................................................................................... 23
1.9.2.3 Product Owner ....................................................................................................... 23
1.9.3 Definición de las reuniones.................................................................................... 23
1.9.5 Herramientas de Scrum .......................................................................................... 25
1.10 Factibilidad ................................................................................................................... 25
1.10.1 Factibilidad Técnica................................................................................................... 25
1.10.1.1 Recurso Humano .................................................................................................... 25
1.10.1.2 Recurso de Hardware.............................................................................................. 26
1.10.1.3 Recursos Tecnológicos ........................................................................................... 26
1.10.2 Factibilidad Operativa ............................................................................................... 26
1.10.3 Factibilidad Legal ...................................................................................................... 27
1.10.4 Factibilidad Económica ............................................................................................. 27
1.11 Relación Beneficio Costo....................................................................................... 30
1.12 Cronograma............................................................................................................ 33
2. Requerimientos de la aplicación ....................................................................................... 35
3 Modelado de casos de uso ................................................................................................. 36
3.1 Actores ............................................................................................................................ 37
3.2 Casos de Uso................................................................................................................... 38
3.3 Especificación de casos de uso ....................................................................................... 39
3.4 Elegir plataforma y operación ........................................................................................ 40
3.5 Conectar Framework ...................................................................................................... 40
3.6 Ejecutar operación .......................................................................................................... 41
3.7 Enviar mensaje de texto .................................................................................................. 42
3.8 Modelo de casos de uso .................................................................................................. 42
3.9 Documentación de casos de uso ..................................................................................... 44
3.10 Diagrama De Clases ..................................................................................................... 55
4. Implementación ................................................................................................................ 57
4.1 Diseño físico de la red .................................................................................................... 57
4.2 Diseño lógico de la red ................................................................................................... 57
4.3 Opciones de ejecución de Asterisk ................................................................................. 58
4.5 Selección de Operación Asterisk .................................................................................... 59
4.6 Conectar Framework ...................................................................................................... 60
4.7 Ejecutar Operación ......................................................................................................... 60
4.8 Enviar mensaje de texto .................................................................................................. 60
4.9 Descripción de la aplicación Servidor ............................................................................ 61
4.10 Descripción de la Implementación Aplicación móvil .................................................. 62
4.10.1 Integración de APIsAndroid en eclipse .................................................................... 66
4.10.2 Desarrollo de la aplicación móvil .............................................................................. 67
5 Conclusiones ..................................................................................................................... 69
6 Referencias ........................................................................................................................ 70
Lista de Tablas
Tabla 1. Recursos Tecnológicos ........................................................................................... 26
Tabla 2. Factibilidad Operativa ............................................................................................ 27
Tabla 3 Recursos Financieros ............................................................................................... 29
Tabla 4. Relación beneficio costo para una proyección de 5 años. ...................................... 32
Tabla 5. Lista de actores. ...................................................................................................... 37
Tabla 6. Lista de casos de uso .............................................................................................. 38
Tabla 7. Autenticar administrador. ....................................................................................... 44
Tabla 8. Elegir plataforma y operación. ............................................................................... 45
Tabla 9. Enviar datos. ........................................................................................................... 47
Tabla 10. Reenviar datos a framework ................................................................................. 48
Tabla 11. Conectar framework ............................................................................................. 50
Tabla 12. Ejecutar operación Asterisk. ................................................................................. 51
Tabla 13. Enviar mensaje de texto........................................................................................ 53
Tabla 14. Diseño lógico de la red. ........................................................................................ 57
Lista de Figuras
Figura 1. Actores del sistema................................................................................................ 37
Figura 2. Caso de uso para el acceso a la aplicación ............................................................ 39
Figura 3. Caso de uso para definir operación ....................................................................... 40
Figura 4. Caso de uso para la conexión del sistema móvil con Framework de telefonía. ... 41
Figura 5. Caso de uso para la ejecución de la operación Asterisk........................................ 41
Figura 6. Caso de uso para el envío de mensajes desde el dispositivo móvil. ...................... 42
Figura 7. Modelo general de casos de uso. ........................................................................... 43
Figura 8. Diagrama de clase de la aplicación. ...................................................................... 55
Figura 9. Diseño físico de la red ........................................................................................... 57
Figura 10. Configuración LAN del punto de acceso. ........................................................... 58
Figura 11. Configuración WIFI ............................................................................................ 58
Figura 12. Opciones Asterisk. .............................................................................................. 59
Figura 13. Estructura de paquetes aplicación servidor. ........................................................ 62
Figura 14. Paquetes de APIs necesarias para el proyecto. .................................................... 64
Figura 15. Paquetes extra necesarios para implementar el proyecto. ................................... 65
Figura 16. PluginAndroid para eclipse. ................................................................................ 66
Figura 17. Integración Android a eclipse. ............................................................................ 66
Figura 18. Configuración de propiedades para dispositivo virtual. ...................................... 67
Figura 19. Dispositivo Android virtual. ................................................................................ 68
8
Introducción
Desde el origen de los tiempos la necesidad de comunicación por parte de los seres
humanos ha sido inherente, como se ha evidenciado a lo largo de la historia. Muestra de
ello es el uso de diferentes tecnologías para transmitir mensajes e ideas, desde las antiguas
pinturas rupestres (Sidar.org, s.f.) hasta llegar a los tiempos actuales, con ejemplos como la
telefonía digital y análoga, así como los avances en la mensajería instantánea.
Dentro de las necesidades de la sociedad, actualmente se contempla el tema de las
comunicaciones como la posibilidad de interactuar en tiempo real con personas que se
encuentran en diferentes partes del mundo. Además los individuos han incluido en todos
los aspectos de su vida la capacidad de comunicación por diversos medios, que les permiten
compartir contenidos, ideas, pensamientos según requieran. Por esto, las redes de telefonía
se han convertido en pilares importantísimos para el funcionamiento de los procesos
comunicativos, siendo consideradas por algunos como servicios básicos. En este contexto,
y gracias a la actual presencia y facilidad de acceso de la telefonía móvil con respecto a su
contraparte fija, es que comenzamos a depender de este servicio con mayor fuerza.
En el presente proyecto se especifica el desarrollo de una aplicación para dispositivos
móviles con sistema operativo Android que permite configurar una central Asterisk. Esta
aplicación móvil es una herramienta que provee una interfaz de usuario para realizar
modificaciones al Dialplan de Asterisk, de una manera más ágil y sencilla. Durante el
desarrollo del proyecto se describen los objetivos planteados, definiendo alcances y
limitaciones para dar solución a la problemática que se definirá más adelante en este
documento.
9
1. Organización, Definición y Análisis
1.1 Tema.
Actualmente la telefonía IP, constituye una forma de convergencia en las redes, para enviar
tráfico de voz y datos por un canal común. Permitiendo utilizar una misma infraestructura
física, y evita adecuar accesorios adicionales para separar los tipos de tráfico. Una poderosa
herramienta que ha sido implementada con éxito en muchas organizaciones para soluciones
de telefonía IP es Asterisk, por su robusta unión de tecnologías de hardware y software.
Una de las características más importantes de Asterisk es el estar libre de licencias, lo cual
implica muchas ventajas con respecto a otras alternativas. En contraparte, muchos de sus
procedimientos de configuración son llevados a cabo manualmente, haciendo más lentas las
configuraciones de llamadas y el funcionamiento del sistema telefónico.
Lograr la automatización de estos procesos, aumenta el desempeño de estos sistemas
basados en Asterisk y permite mejorar los tiempos de respuesta de las operaciones. El tema
central de éste proyecto, consiste en la automatización del dialplan Asterisk, por medio de
dispositivos móviles.
1.2 Titulo.
Diseño e implementación de una aplicación Android para la configuración de una central
Asterisk.
1.3 Objetivos
1.3.1 Objetivo general
Diseñar y construir una aplicación para dispositivos móviles Android con la cual se
puede administrar automáticamente una central Asterisk, que brinde una interfaz de
fácil uso para el usuario final.
1.3.2 Objetivos específicos
Determinar los procesos y los protocolos que contendrá la aplicación para la
configuración de una central Asterisk.
10
Diseñar una interfaz gráfica de fácil uso basada en los procesos y protocolos
identificados.
Construir la aplicación móvil a partir de un modelo de análisis y diseño para la
administración de una central Asterisk.
Realizar un análisis económico que permita determinarla viabilidad del proyecto.
1.4 Descripción del Problema
Uno de los problemas críticos, de la telefonía Asterisk, es la variedad de configuraciones y
parámetros necesarios para establecer el dialplan, ya que su arquitectura permite esta
flexibilidad. Si un administrador de red no configura los contextos, no queda activo el
sistema telefónico. La configuración de contextos es una operación manual, de sintaxis
compleja, basada en funciones de programación en el lenguaje C. Se utilizan patrones,
caracteres especiales, expresiones regulares y direcciones IP. Es necesario para un
administrador de red conocer a fondo la estructura de los contextos Asterisk. Aún con un
conocimiento amplio del núcleo Asterisk, se está propenso a errores. Las operaciones
manuales son lentas, ya que es necesario realizar reinicios consecutivos, para que los
cambios tengan efecto. Es fácil modificar un contenido correcto, por equivocación. Toda la
información del sistema de archivos de telefonía es crítica, cualquier cambio involuntario
produce fallas severas en el sistema telefónico, puede detener parcial o totalmente la
funcionalidad.
La creación de líneas telefónicas, inclusión de nuevos usuarios, creación de dependencias,
hace necesario modificar múltiples archivos de configuración. Al ser operaciones
frecuentes en las organizaciones, la configuración de los módulos Asterisk es permanente,
si se realiza manualmente. Esto requiere de intervención exclusiva y especializada del
administrador de la red. Cuando se realiza la configuración de contextos Asterisk, se hace
uso de comandos de Linux los cuales quedan registrados en un historial, lo que implica que
la ejecución errónea de ellos, pueda incidir en fallas de configuración de contextos, como
en los módulos sip.conf, extensions.conf y voicemail.conf, necesarios para la funcionalidad
mínima del sistema telefónico. Cada procedimiento es potencialmente peligroso y permite
que un usuario malintencionado, ejecute comandos de sistema que puedan causar una
posible falla.
11
1.5 Pregunta de Investigación
¿Es posible la reducción de las incidencias en los procesos de configuración y
administración de la central Asterisk, por medio de la implementación de una aplicación
móvil Android?
1.6 Alcances y Limitaciones
1.6.1 Alcances
Se configurará un servidor Asterisk en intranet, con alcance WiFi 802.11b/g hacia el
dispositivo móvil, con dos líneas telefónicas habilitadas por medio de softphone en equipos
de la red LAN.
El proyecto incluye tres sistemas principales:
1 Sistema Móvil: Este módulo contendrá las opciones de configuración del
dialplan Asterisk, en una aplicación Android.
2 Sistema Web: Este módulo recibe solicitudes desde la aplicación Android,
vía WiFi, conecta el módulo Asterisk y posteriormente le envía las operaciones de
configuración a ejecutar.
3 Sistema Envió de Mensajes: Este módulo se encargara de enviar mensajes
a dispositivos móviles, cuando las llamadas no son atendidas en los teléfono IP-
fijos, tendrá interoperabilidad entre el sistema móvil y el sistema web.
4 Modulo Asterisk: Este módulo es el núcleo Asterisk, que recibe las
operaciones y por medio de la interfaz de línea de comandos ejecuta la
configuración del dialplan, en los contextos:
sip.conf
extensions.conf
voicemail.conf.
12
1.6.2 Limitaciones
La aplicación realiza configuraciones Asterisk de nivel LAN, para llamadas en
intranet, el módulo WAN se reserva para futuras versiones de la aplicación.
El tiempo estimado para la elaboración e implementación del proyecto son 6 meses.
Limitación del acceso a la información, teniendo en cuenta que Asterisk no es un
software popular por su compleja administración.
El presupuesto del proyecto se limita a $ 36.540.000 de pesos.
Los investigadores solo pueden dedicar 3 días a la semana a la investigación.
La seguridad del proyecto está limitada a la seguridad establecida por Asterisk.
1.7. Justificación
Es preciso implementar una aplicación que permita automatizar la configuración del
dialplan Asterisk, para dar solución al problema planteado, ya que permite lidiar con una
gran cantidad de operaciones y parámetros necesarios para definir el comportamiento de las
llamadas. Al brindar un entorno visual sencillo le facilita la administración del sistema
Asterisk al usuario, así mismo, las tareas de configuración son realizadas por un servicio
web, que no requiere un conocimiento profundo, de la sintaxis de comandos, expresiones
regulares, patrones ni direccionamiento IP, para la definición de contextos.
Esto significa que la presencia del administrador de la red, no es indispensable y otras
personas sin el conocimiento profundo, pueden realizar el trabajo desde la aplicación. Los
procesos de configuración, son realizados rápidamente, utilizando dispositivos móviles para
automatizar el proceso. Lo que implica ahorro de tiempo, cada vez más considerable, en la
medida que se habiliten nuevas extensiones para otros usuarios. Con esto, también se evitan
los errores de digitación manual o modificación de archivos críticos para el buen
funcionamiento de la telefonía IP.
La aplicación móvil, facilita la ejecución de las operaciones, no es necesario acceder al
servidor, para ejecutar configuraciones críticas, que puedan alterar otros procesos. Y es
posible ejecutar las operaciones dentro del alcance que permita la red WiFi de la
organización.
Además, al realizar una llamada a una extensión, si la llamada no es atendida, ante esta
situación, la aplicación enviará un mensaje al dispositivo móvil del responsable de la
extensión telefónica, para informar acerca de la llamada. Así cada mensaje de urgencia,
tiene la recepción adecuada, en el tiempo propicio.
13
1.8 Marco de Referencia
1.8.1 Marco Histórico
Para este proyecto usaremos como guía implementaciones realizadas en diferentes áreas
Caso práctico de la implantación de un sistema de Telefonía VoIP en una empresa
Este sistema desarrollado en el año 2009, en la Escuela Técnica superior de Ingeniería
informática, logra destacar la comprensión de los protocolos que se utilizan para
transmitir la voz a través de la red IP y los destinados a complementarlos en aspectos
relacionados con la seguridad, señalización y calidad del servicio. El funcionamiento de
las redes de telefonía clásica y la forma de interactuar con ellas, el dominio de sistemas
informáticos para el correcto funcionamiento de las aplicaciones (Luengo, 2009). A
través de este trabajo se proporciona una guía para que una persona con unos
conocimientos medios en las tecnologías de información se pueda iniciar en la telefonía
IP. Así, mediante la síntesis de las principales tecnologías implicadas en la VoIP y la
inclusión de numerosos ejemplos, el proceso de aprendizaje resulta mucho más liviano.
El hecho de incluir un caso práctico, explicando con todo detalle y de forma didáctica la
implantación de un sistema de comunicaciones VoIP en una empresa, brinda la
posibilidad de descubrir en un contexto real las bondades que ofrece la telefonía de
código abierto así como los problemas a los que hay que enfrentarse al utilizarla.
Asterisk y Telefonía Tradicional.
Este proyecto, desarrollado en el año 2006, consistió en el estudio e implementación de
un sistema de Telefonía IP, manteniendo la potencialidad de un PBX IP tradicional.
Además de aprovechar las características propias que nos presenta un sistema de
telefonía IP basado en GNU/Linux. (González, 2006).
En la década de los 70s, ya existía la red telefónica. Está en un principio simplemente
consistía en líneas conectadas a un concentrador o también llamado conmutador
(Central). Cada Central solo proporcionaba servicio a los usuarios que estaban
conectados a esta. En realidad cada Central estaba aislada de las demás existentes en
otras zonas, ciudades o regiones. Fue entonces que se empezó a observar que la forma
más eficiente de extender la distancia que podía cubrir una llamada telefónica era
simplemente conectando las Centrales existentes. Esto también incremento
14
enormemente las posibilidades de enrutamiento de una llamada; fue entonces que
realmente nació la primera red telefónica. Hoy en día esa red es conocida como la Red
Telefónica Publica Conmutada (RTPC) o en ingles PSTN.
Estudio y diseño de una red de telefonía de voz sobre IP para plataforma siglo XXI
Esta investigación fue realizada en el Año 2007, en Colombia; Universidad de
Pamplona.
Las comunicaciones han tenido una evolución bastante acelerada en las últimas
décadas, es un avance exitoso para toda la humanidad, ahora mismo las comunicaciones
mueven en si todas las empresas y es una herramienta indispensable para la evolución,
el sostenimiento y la producción de estas. Una de las tecnologías que está minimizando
costo y es una ventaja para cualquier institución es la telefonía IP.
Este trabajo trata del diseño de la red para la empresa Plataforma Siglo XXI, así como
de las características de los dispositivos que se utilizan, los elementos que se necesitan
para el diseño de la misma. En el proyecto de diseño de la red de telefonía IP se
incluyen los diferentes tipos de protocolos de señalización para la realización de una
llamada con sus ventajas y desventajas a su vez se escoge el protocolo que más se
acople a este diseño (Gómez, 2007).
En las últimas décadas la telefonía ha prestado un gran servicio a todas las
comunidades, empresas y demás; la telefonía por hilos o telefonía básica ha hecho un
gran aporte a la tecnología para las comunicaciones, se puede decir que es el pilar de
todas ellas como lo es para la telefonía móvil, satelital y ahora para la telefonía IP, el
sistema de comunicación analógica o la red de circuitos integrados a medida de los años
está perdiendo adeptos por los servicios que ofrece y otros tipos de comunicación han
ganado ventaja.
Creación de una Central Telefónica a través del Módulo Asterisk-Ubuntu
Esta Investigación fue realizada en el año 2007, en la Universidad Austral de Chile.
La presente tesis está enfocada principalmente a descubrir el cambio que se realizara en
las telecomunicaciones en el futuro, con una visión practica de cómo es la transmisión
de telefonía que está emergiendo y desplazara a la telefonía actual, en la parte práctica
consiste en la instalación de una central de telefonía y analizar cómo se transmite la
información de voz a través de paquetes IP. Este proyecto está enfocado a Ingenieros
15
electrónicos e ingenieros informáticos, que quieran aprender a desarrollar esta tecnología
e implementarla en forma práctica en cualquier parte que se desee, este proyecto tiene
una enorme importancia en conectividad ya que se une a través de Internet redes de
telefonía, por lo que podemos llegar a cualquier parte que se desee y este bien
implementada una red ya sea alambica e inalámbrica (Urtubia, 2007).
La utilización de una red ya existente da pie a la maximización de los recursos de esta
red, la red IP, por esto nace la implementación de esta telefonía y con esto se abaratan
costos y se otorgan mayores prestaciones a la telefonía convencional.
1.8.1. Marco Teórico
1.8.1.1 Linux
GNU/Linux es el primer sistema operativo basado en UNIX que es 100% Software Libre.
Si bien anteriormente había otros sistemas operativos de libre distribución (como MINIX),
éstos no eran totalmente Software Libre, ya que eran regidos por licencias más restrictivas.
GNU/Linux es un proyecto con muy fuertes cimientos, El sistema ha sido diseñado y
programado por multitud de programadores alrededor del mundo. El núcleo del sistema
sigue en continuo desarrollo bajo la coordinación de Linus Torvalds, la persona de la que
partió la idea de este proyecto, en 1991(Linux-es.org, 2014).Es prácticamente imposible
parar un proyecto de estas magnitudes.
Hablando técnicamente, GNU/Linux es un sistema operativo de software libre basado en
UNIX, que cumple las normas POSIX. Su base es un núcleo monolítico llamado Linux (a
secas), desarrollado originalmente por Linus Torvalds a principios de la década de los
noventa. Su estructura general es la típica de cualquier sistema UNIX (núcleo – intérprete
de comandos – aplicaciones), aunque actualmente debe de ser el más desarrollado de ellos.
Cuenta con una interfaz gráfica llamada Xfree86 (versión libre del sistema de ventanas
Xwindow original del MIT) y con muchas aplicaciones para realizar las más diversas
tareas, desde procesamiento de textos hasta montaje de servidores de red, pasando por
aplicaciones multimedia y juegos.
Paralelamente con el desarrollo de este sistema operativo, surgió la Fundación del Software
Libre, la cual fomenta, entre otras cosas, la utilización de herramientas de Software Libre
en las computadoras de todo el mundo.
16
Como afirma Héctor F. Arena (2003) cuando se habla de libertad, del software lo hacemos
en el sentido más filosófico de la palabra. Hablamos de la libertad de tener un programa
incluyendo su código fuente, la libertad de usarlo, copiarlo, modificarlo, y además poder
compartirlo con otros. Ése es el espíritu del sistema GNU/Linux (p. 21).
El software libre presenta una innumerable cantidad de ventajas para el desarrollador frente
a otros sistemas desarrollados bajo modelos cerrados. La primera y principal ventaja es que
el desarrollador obtendrá ayuda de parte de personas que quizá ni siquiera conoce, gracias a
la gran red de redes.
La segunda ventaja es que su proyecto crecerá mucho más rápido que antes gracias a la
cantidad de colaboradores que quieran sumarse a la causa (siempre que ésta sea buena).
1.8.1.2 VoIP
VoIP intenta permitir que la voz viaje en paquetes IP y a través de Internet. El concepto de
recepción de un paquete en el instante que el remitente quiere que sea recibido es complejo.
De hecho, la construcción de una red para ejecutar VoIP es compleja (Davidson, Peters y
Gracely, 2000). Sin embargo la telefonía IP conjuga dos mundos históricamente separados:
la transmisión de voz y la de datos. Se trata de transportar la voz, previamente convertida a
datos, entre dos puntos distantes. Esto posibilita utilizar las redes de datos para efectuar las
llamadas telefónicas, y desarrollar una única red convergente que se encargue de cursar
todo tipo de comunicación, ya sea voz, datos, video o cualquier tipo de información.
La voz IP, por lo tanto, no es en sí mismo un servicio, sino una tecnología que permite
encapsular la voz en paquetes para poder ser transportados sobre redes de datos sin
necesidad de disponer de los circuitos conmutados convencionales PSTN, las redes
desarrolladas a lo largo de los años para transmitir las conversaciones vocales, se basaban
en el concepto de conmutación de circuitos, o sea, la realización de una comunicación que
requiere el establecimiento de un circuito físico durante el tiempo que dura ésta, lo que
significa que los recursos que intervienen en la realización de una llamada no pueden ser
utilizados en otra hasta que la primera no finalice, incluso durante los silencios que se
suceden, dentro de una conversación típica. En cambio, la telefonía IP no utiliza circuitos
para la conversación, sino que envía múltiples de ellas (conversaciones) a través del mismo
canal, codificadas en paquetes y flujos independientes.
Cuando se produce un silencio en una conversación, los paquetes de datos de otras
conversaciones pueden ser transmitidos por la red, lo que implica un uso más eficiente de la
misma. Según esto son evidentes las ventajas que proporciona el segundo tipo de red, ya
que con la misma infraestructura podrían prestar más servicios, la calidad de servicio y la
17
velocidad serían mayores; pero existe la desventaja de la seguridad, ya que no es posible
determinar la duración del paquete dentro de la red, hasta que este llegue a su destino y
además existe la posibilidad de pérdida de paquetes, ya que el protocolo IP no cuenta con
esta herramienta.
1.8.1.3Asterisk
Asterisk es un software PBX que usa el concepto de software libre (GPL). Digium, empresa
que promueve el Asterisk, invierte en ambos aspectos, el desenvolvimiento de código
fuente y en hardware de telefonía de bajo costo que funciona con Asterisk. “El Asterisk
corre en plataforma Linux y otras plataformas Unix con o sin hardware conectado a la red
pública de telefonía, PSTN (Public Service Telephony Network)” (Goncalves, Flavio.2007.
P. 11). El Asterisk permite conectividad en tiempo real entre las redes PSTN y redes VoIP.
Con Asterisk en la red, se pueden crear actividades como:
Conectar empleados trabajando desde casa para un PBX de la oficina sobre
conexiones de banda ancha.
Conectar oficinas en varias provincias sobre IP. Esto puede ser hecho por internet o
por una red IP privada.
Construir aplicaciones de repuesta automática por voz, que puede conectarlo a un
sistema de pedidos, por ejemplo, o a otras aplicaciones internas.
Asterisk incluye muchos recursos que sólo eran encontrados en sistemas de mensajería
unificada, como:
Música en espera para clientes en fila de espera, soportando streaming de media así
como música en MP3.
Filas de llamada donde agentes de forma conjunta atienden las llamadas y
monitorean dicha fila.
Integración para sintetización de la conversación.
Registro detallado de llamadas para integración con sistemas de tarificación.
Integración con reconocimiento de voz.
Con el nacimiento de Asterisk surge una revolución:
Ya que este concepto fue revolucionario, y hacía muchas ondas en la industria, yo decidí
después nombrar la tecnología y organización como el famoso revolucionario mexicano
Emiliano Zapata. Decidí llamar a la tarjeta de hardware, la “tormenta” (Dixon, 2009).
18
1.8.1.4 Aplicaciones Móviles
Las aplicaciones móviles se han definido como los conjuntos de instrucciones lógicas,
procedimientos, reglas, documentación, datos e información asociada a estas que funcionan
específicamente en dispositivos móviles, como por ejemplo teléfonos inteligentes,
televisores inteligentes, tabletas, reloj, entre otros(UNAD, 2012).
Están desarrolladas en su mayor parte en las principales plataformas existentes IOS y
Android, lo cual tendrá una incidencia en la demanda por servicios de desarrollo y testeo de
parte de las distintas empresas que buscan consolidar un posicionamiento competitivo en la
industria.
Constantemente se realizan revisiones y actualizaciones de los principales sistemas
operativos para asegurar la compatibilidad de los dispositivos móviles con la usabilidad
esperada de parte de los usuarios, es por ello que constantemente surgen nuevas
aplicaciones que sustituyen distintos servicios disponibles en otros medios, como: banca
comercial, software corporativo, software operacional, juegos, aplicaciones de
productividad, entre otros.
La incorporación de nuevas tecnologías en los dispositivos móviles ha permitido una mayor
versatilidad de uso en cuanto a las prestaciones ofrecidas por las aplicaciones, si en un
inicio el foco de atención se fijaba en mensajería instantánea, en la actualidad el espectro de
usabilidad se ha expandido a tal punto que los usuarios pueden utilizar sus celulares o
tabletas como terminales de software de CRM(Customer Relationship Management),
procesadores de texto, administración de planillas e inventarios, editores de contenido
audiovisual, y para funciones de administración de red. Lo anterior implica un incremento
en el nivel de complejidad en los procesos de desarrollo y programación. En vista de lo
anterior, es posible corroborar que a medida que el foco de interés de los usuarios se vuelve
cada vez más específico el número de aplicaciones disponibles en el mercado se incrementa
de manera significativa cada año, así también la cantidad de descargas y utilización de
distintas plataformas de distribución de software.
En otros términos, “durante 2008 se registraron alrededor de 530 millones de descargas,
3.590 millones en 2009, 6.610 millones en 2010, 9.880 millones en 2011, 13.250 millones
en 2012, en 2013 se contabilizaron más de 16.210 millones solo en el primer semestre. ”
("World Mobile ApplicationsMarket Worth US$25 Billionby 2015", 2016) Esto referencia
las aplicaciones gratuitas y de pago sin contemplar juegos.
19
1.8.1.5 SIP- Session Initiation Protocol
Es un protocolo de control y señalización usado mayoritariamente en los sistemas de
Telefonía IP, que fue desarrollado por el IETF (RFC 3261). Dicho protocolo permite crear,
modificar y finalizar sesiones multimedia con uno o más participantes y sus mayores
ventajas recaen en su simplicidad y consistencia.
Hasta la fecha, existían múltiples protocolos de señalización tales como el H.323 de la ITU,
el SCCP de Cisco, o el MGCP, pero parece que poco a poco SIP está ganando la batalla del
estándar: Cisco está progresivamente adoptando SIP como protocolo en sus sistemas de
telefonía IP en detrimento de H.323 y SCCP, Microsoft ha elegido SIP como protocolo
para su nuevo OCS (Office Communication Server), y los operadores (de móvil y fijo)
también están implantando SIP dentro de su estrategia de convergencia, aprovechando de
este modo la escalabilidad e interoperabilidad que nos proporciona el protocolo SIP.
Funciones SIP
El protocolo SIP actúa de forma transparente, permitiendo el mapeo de nombres y la
redirección de servicios ofreciendo así la implementación de la IN (Intelligent Network) de
la PSTN o RTC.
Para conseguir los servicios de la IN el protocolo SIP dispone de distintas funciones. A
continuación se enumeran las más importantes:
Localización de usuarios (SIP proporciona soporte para la movilidad).
Capacidades de usuario (SIP permite la negociación de parámetros).
Disponibilidad del usuario
Establecimiento y mantenimiento de una sesión.
En definitiva, el protocolo SIP permite la interacción entre dispositivos, cosa que se
consigue con distintos tipos de mensajes propios del protocolo que abarca esta sección.
Dichos mensajes proporcionan capacidades para registrar y/o invitar un usuario a una
sesión, negociar los parámetros de una sesión, establecer una comunicación entre dos a más
dispositivos y, por último, finalizar sesiones.
Beneficios del protocolo SIP frente otros protocolos
En la actualidad, los protocolos más usados en ToIP son tres: SIP, H.323 y IAX2.
20
H.323 es un estándar de la ITU que provee especificaciones para ordenadores, sistemas y
servicios multimedia por redes que no proveen QoS (calidad de servicio). Como principales
características de H.323 tenemos:
Implementa QoS de forma interna.
Control de conferencias
IAX2 (Inter Asterisk eXchange) es un protocolo creado y estandarizado por Asterisk. Unas
de sus principales características son: Media y señalización viajan en el mismo flujo de
datos.
Trunking
Cifrado de datos
Una de las ventajas de este protocolo es que al enviar el “streaming” y la señalización por
el mismo flujo de datos, se evitan problemas derivados del NAT. Así pues, no es necesario
abrir rangos de puertos para el tráfico
RTP. Por último, IAX2 nos permite hacer trunking de forma que podemos enviar varias
conversaciones por el mismo flujo, lo cual supone un importante ahorro de ancho de banda.
Finalmente, veamos qué hace de SIP un protocolo cada día más sólido. Aspectos
importantes referentes a dicho protocolo se enumeran como sigue:
El control de llamadas es stateless o sin estado, y proporciona escalabilidad entre los
dispositivos telefónicos y los servidores.
SIP necesita menos ciclos de CPU para generar mensajes de señalización de forma
que un servidor podrá manejar más transacciones.
Una llamada SIP es independiente de la existencia de una conexión en la capa de
transporte.
SIP soporta autentificación de llamante y llamado mediante mecanismos HTTP.
Autenticación, criptográfica y encriptación son soportados salto a salto por
SSL/TSL pero SIP puede usar cualquier capa de transporte o cualquier mecanismo
de seguridad de HTTP, como SSH o S-HTTP.
Un proxy SIP puede controlar la señalización de la llamada y puede bifurcar a
cualquier número de dispositivos simultáneamente.
En definitiva, vemos que SIP es un protocolo con una gran escalabilidad, modular y muy
apto para convertirse en el futuro inmediato de la ToIP.
21
Arquitectura SIP
El estándar define varios componentes SIP y hay varias formas de implementarlos en un
sistema de control de llamadas.
servidores User Agent,
Proxies
Registrars,
Redirect
Location.
A menudo, estos elementos son entidades lógicas que se ubican todas juntas para conseguir
una mayor velocidad de procesamiento que dependerá a su vez de una buena configuración.
1.8.1.6 RMI: Remote Method Invocation (Invocación de Método Remota)
Es un protocolo propietario de Java que permite que métodos de objetos que existen en una
máquina virtual puedan ser invocados desde otros objetos en otra máquina virtual,
probablemente en un host distinto.
RMI sólo permite la comunicación entre tecnología Java. Si se requiere comunicar con
otras tecnologías debe usarse CORBA o SOAP.
Al estar específicamente diseñado para Java, RMI puede darse el lujo de ser muy amigable
para los programadores, proveyendo pasaje por referencia de objetos (cosa que no hace
SOAP), "recolección de basura" distribuida y pasaje de tipos arbitrarios (funcionalidad no
provista por CORBA).
Por medio de RMI un programa puede hacer disponible un objeto en la red. Otro programa
entonces podría invocar métodos de dicho objeto como si invocara métodos de objetos
propios, de un modo transparente al programador, sin tener que lidiar con sockets de bajo
nivel.
Cuando un programador invoca un método de un objeto remoto, los parámetros son
serializados (convertidos en un flujo de bytes capaz de ser enviados a través de un socket).
Luego se envían a través de la red, mientras que el método que hizo la invocación queda
esperando. El método remoto realiza el procesamiento, serializa el valor de retorno y se lo
devuelve al llamador. Esto implica que el pasaje de parámetros que no tienen interfaz
remota definida (objetos no remotos), cuando se trata de métodos remotos, es por copia.
22
Por este motivo se requiere que los parámetros del método remoto y del dato que retorna
sean de clases que se puedan serializar (en Java, que implementen la interfaz
"Serializable").
El encargado de hacer públicos los objetos remotos es el registro RMI. Se trata de un
servicio, cuyo puerto TCP por defecto es el 1099 (aunque es posible elegir otro), que
mantiene información acerca de los objetos exportados y sus correspondientes direcciones.
El servidor debe registrar en él sus objetos remotos mediante el método "Naming.bind
("dirección", objeto)" y el cliente debe solicitarlos llamando a "Naming.lookup
("dirección")".
1.9 Marco Metodológico
La metodología que mejor se acomoda a las necesidades para el desarrollo del proyecto es
SCRUM ya que se realizan entregas parciales y regulares del producto final, cuyo enfoque
esta guiado a obtener resultados prontamente, de esta manera se puede conocer el estado
del proyecto mediante la experiencia que se adquiere en cada entrega.
La metodología SCRUM es basada en sprints, que son iteraciones realizadas por el grupo
de trabajo dentro de un lapso previamente establecido, que permite entregar avances
incrementales del proyecto.
Roles:
Scrum Master
Team
Product Owner
Reuniones:
Sprint planning
Sprint review
Sprint retrospective
Daily scrum
Artefactos
Product backlog
Sprint backlog
23
1.9.1 Definición del Sprint
Se definieron los tiempos requeridos para la culminación del proyecto, en este caso se
acordó que la duración de cada Sprint será de 12 días, y que la duración de la totalidad del
proyecto incluirá 8 Sprints y una fase de configuración SCRUM donde se definirá el plan
de trabajo para el proyecto (Ver cronograma).
1.9.2 Definición de roles
1.9.2.1 Team
Para realizar el proyecto se cuenta con el equipo de trabajo conformado por Juan Carlos
Carrillo Moreno y Nelson Javier Pinzón López, quienes presentaran adelantos del proyecto
de forma iterativa e incremental; bajo la asesoría y retroalimentaciones del Ingeniero Luis
Felipe Wanumen Silva. El grupo de trabajo esta concientizado de las responsabilidades
individuales que poseen durante el desarrollo de todo el proyecto. La multifuncionalidad de
los integrantes del equipo de trabajo será vital para lograr los objetivos definidos.
1.9.2.2 Scrum Master
Por lo reducido del equipo de trabajo se ha definido que el Scrum Master por su experiencia
y conocimiento será el Ingeniero Luis Felipe Wanumen Silva.
1.9.2.3 Product Owner
El rol de Product Owner no está definido para este proyecto por el tamaño del mismo.
1.9.3 Definición de las reuniones
1.9.3.1 Daily scrum
Estas son reuniones que se efectúan a diario, es en donde el equipo se entera del estado del
proyecto esta reunión tiene unas características especiales como lo son:
La reunión comienza puntualmente a su hora.
Todos son bienvenidos, pero sólo los involucrados en el proyecto pueden hablar.
24
La reunión tiene una duración máxima de 15 minutos.
La reunión debe realizarse en el mismo sitio y a la misma hora todos los días.
Durante la reunión, cada miembro del equipo contesta a tres preguntas: ¿Qué se hizo ayer?,
¿Qué se hará hoy? y ¿Qué impedimentos tienen? (Es papel del Scrum Master recolectar
estos impedimentos).
1.9.3.2 Sprint planning
El Sprint planing se realiza al inicio de cada ciclo de Sprint, en esta reunión se selecciona el
trabajo se hará, además de preparar con el equipo el Sprint Backlog. Se estima cuánto del
trabajo se puede realizar durante el Sprint.
1.9.3.3 Sprint review
Esta reunión tiene un tiempo máximo de 3 horas en donde se realiza una demostración del
producto, la idea es que en cada presentación se demuestren nuevas funcionalidades en esta
reunión participa todo el equipo y las funcionalidades no implementadas no se presentan.
1.9.3.4 Sprint retrospective
Al finalizar de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual el Team
deja sus opiniones, se responden las preguntas ¿qué fue lo bueno del sprint? y ¿Qué se
puede mejorar?
El propósito de la retrospectiva es realizar una mejora continua del proceso.
1.9.4 Definición de artefactos
1.9.4.1 Product backlog
Es una lista priorizada de requerimientos (el Qué) definidos en un alto nivel y priorizado
por el Product Owner también es repriorizada al inicio de cada Sprint manteniéndose
durante todo el ciclo de vida.
25
1.9.4.2 Sprint backlog
Es un subconjunto del Product Backlog son los requerimientos detallados a más bajo nivel
(el Cómo), en el están definidas las tareas a realizar por requerimiento pero no son
asignadas, el equipo elige las tareas a realizar y cualquier miembro del equipo puede tomar
tareas del Sprint Backlog.
1.9.5 Herramientas de Scrum
Una de las herramientas utilizadas dentro de la metodología Scrum son las historias de
usuario, que son la especificación de un requerimiento donde se proporciona información
sobre el comportamiento que debe tener dentro de la aplicación.
Para dar un control sobre las tareas a realizar por parte de los integrantes del grupo de
trabajo, se establecerá un panel de tareas divido en tres columnas que simbolizan los
estados de cada tarea: por hacer, haciendo y terminado.
Se deben realizar pruebas de cada una de las tareas de desarrollo terminadas, validando que
se hayan solucionado completamente los requerimientos definidos en cada reunión para
cada sprint.
1.10 Factibilidad
1.10.1 Factibilidad Técnica
1.10.1.1 Recurso Humano
El proyecto será desarrollado por los estudiantes de la Universidad Distrital Francisco José
de Caldas del proyecto Curricular en Ingeniería de Sistemas, Juan Carlos Carrillo Moreno y
Nelson Javier Pinzón López, contando con la colaboración y asesoría del Ingeniero Luis
Felipe Wanumen Silva.
Este es un proyecto viable operativamente porque cuenta con los recursos Humanos
necesarios para llevarlo a cabo.
26
1.10.1.2 Recurso de Hardware
Para el desarrollo del sistema se cuenta con un equipo, el cual posee un procesador Pentium
Dual Core 2.6 GHz, disco duro de 300Gb y memoria de 4Gigas, ya que el proyecto exige
un equipo con buena capacidad de procesamiento.
1.10.1.3 Recursos Tecnológicos
La siguiente tabla indica los recursos tecnológicos necesarios.
Tabla 1. Recursos Tecnológicos
Recursos Características Tipo de Recurso
Servidor Linux Disco duro de 300 GB, 4 GB de
Memoria RAM, procesador Intel
Dual Core de 2.6 GHz.
Hardware
Debian-7.5.0-i386-netinst Sistema operativo de 32 bits. Software
Tarjeta de Telefonía Ip TDM410P / 2FXO 2FXS Hardware
Tarjeta de Red Inalámbrica Tarjeta de Red Ethernet 802.11 Hardware.
IDE Netbeans Versión 6.9.1 Software
Mysql Sistema manejador de base de
datos
Software.
Dispositivo Móvil que
soporte aplicaciones Java
MIDP 2.0, CLCD 1.0
Mínimo Android 4.0 Hardware
De acuerdo a los recursos mencionados el proyecto es factible técnicamente ya que se
cuenta con los recursos de hardware y de software para el desarrollo de este.
1.10.2 Factibilidad Operativa
El proyecto requiere de un asesor, el director del proyecto; así como un administrador de
red y un desarrollador de software (Ver tabla 2).
27
Tabla 2. Factibilidad Operativa
Función Persona Encargada
Director Proyecto Luis Felipe Wanumen Silva
Desarrollador de Software Juan Carlos Carrillo Moreno
Administrador de Red Nelson Javier Pinzón López
De acuerdo al grupo de trabajo mencionado el proyecto es factible operativamente ya que
los encargados de desarrollar e implementar la aplicación móvil, cuentan con los
conocimientos apropiados para realizar dicha labor, siendo estudiantes de ingeniería de
sistemas de la Universidad Francisco José de Caldas, conocen los temas relacio nados que
dan solución a la problemática establecida.
1.10.3 Factibilidad Legal
Las herramientas de desarrollo utilizadas en este proyecto son de licencia libre. Existe una
licencia GPL Versión 3.0 que permite la modificación de código por parte de terceros, pero
determina que cualquier desarrollo que se haga sobre el código desarrollado debe seguir
siendo de código abierto.
1.10.4 Factibilidad Económica
Para determinar el presupuesto con que se debe contar para la realización del proyecto se
efectuaron los siguientes cálculos:
Tiempo de uso del PC = 6 MESES
TUPC = Tiempo de uso del PC
TUPC = (6 MESES) *(4 Semanas mensuales)
TUPC = 24 semanas
TUPC = (24 semanas) * (4 Días a la semana)
TUPC = (96 Días) * (6 Horas)
TUPC = 576 Horas del proyecto
Valor uso Internet por hora = $1000
VUIH = Valor uso Internet por hora
28
VUIH = $1000 * TUPC
_______________________________
VUIH = $576.000
Valor depreciación hora PC = $2000
VDPC= Valor depreciación hora PC
VDPC = $2000 * TUPC
________________________________
VDPC = $1.152.000
CI = Costo de impresiones
CI = 5000 hojas * $ 100(costo por impresión)
_____________________________________
CI = $500.000
Valor Reserva Imprevistos
_________________
VRI = $3.300.000
Otros = Transportes, medios magnéticos de almacenamiento, etc.
______________________________________________
Otros = $500.000
TAT = Tiempo Asesoría Tutor
TAT = (6 MESES) *(4 Semanas mensuales)
TAT = 24 semanas
TAT = (24 semanas) * (3 Días a la semana)
TAT = (72 Días) * (4 Horas)
TAT = 288 Horas de asesoría del tutor
CAT = Costo asesoría del tutor
CAT = TAT * ($50.000 hora)
__________________________
CAT = $14.400.000
TTE = Tiempo de Trabajo Estudiantes
TTE = (6 MESES) *(4 Semanas mensuales)
TTE = 24 semanas
29
TTE = (24 semanas) * (4 Días a la semana)
TTE = (96 Días) * (6 Horas)
TTE = 576 Horas de trabajo estudiantes
CTE = Costo Trabajo Estudiantes
CTE = TTE * ($25.000 hora)
________________________
CTE = $14.400.000
Tabla 3 Recursos Financieros
Recursos Costo
Hardware
Computador
Depreciación computador
$ 2.000.000
$ 864.000
Internet
Horas de Internet $576.000
Humano
Asesorías Tutor
Trabajo estudiantes
$14.400.000
$14.400.000
Otros Papelería, fotocopias, Impresiones,
transportes, medios magnéticos de
almacenamiento.
$1.000.000
Imprevistos Imprevistos $3.300.000
El desgaste del equipo es el valor de depreciación que tiene un computador por el uso
durante el tiempo estimado del proyecto.
El costo de los recursos que son Software Libre, se atribuye al costo de la hora de internet,
que se invierte para la descarga de los programas.
El costo de las asesorías y tutorías es la relación entre el valor de la hora de trabajo del
profesor, como tutor. Este valor es de $50.000, para un total de $14.400.000, con 288 horas
de asesorías.
Costo total del proyecto = VUIH + VDPC + CI + CAT + CTE + VRI+ otros + Costo
Hardware
30
Costo total del proyecto = $ 36.540.000
Este proyecto es factible económicamente ya que se cuenta con las herramientas de
hardware y software, las asesorías del tutor son cubiertas por la Universidad Distrital
Francisco José de caldas, los demás recursos como papelería, Internet entre otros, serán
cubiertos por los ejecutores del proyecto, quienes cuentan con los recursos financieros.
1.11 Relación Beneficio Costo
El análisis de beneficio costo, permite establecer la rentabilidad al implementar el proyecto,
de esta manera se puede determinar la viabilidad del proyecto y su ejecución.
Beneficios
La aplicación móvil tiene una serie de beneficios que afectan directamente a la
organización que la implemente. A continuación se enumeran los más importantes:
Conocer los procesos utilizados con mayor frecuencia por los usuarios de la central Asterisk, mediante el número de solicitudes aplicadas a cada proceso. Esta
información es de gran utilidad en términos de trazabilidad para dar cumplimiento a las expectativas del usuario acerca de la aplicación, y dar un enfoque apropiado
hacia qué procesos se debe hacer énfasis en futuras versiones del producto.
La aplicación cuenta con una mayor cobertura geográfica ya que hace uso de redes
inalámbricas.
Procesar con mayor rapidez las solicitudes.
Los horarios de funcionamiento de la aplicación móvil pueden extenderse, ya que
no hay necesidad de tener acceso físico a los servidores Asterisk.
La aplicación permite alternar distintos flujos de trabajo sin riesgo a confusiones
permitiendo una mayor escalabilidad.
Facilidad de uso de la aplicación móvil para el usuario final, este beneficio se ve
reflejado en las horas de capacitación al personal y soporte.
Beneficios cuantificables
A efectos de contar con la información requerida para generar los cálculos, es importante
considerar y la forma en que se deben estimar los montos (Agesic.gub, 2013). Actual mente
Bogotá es la región que tiene mayor crecimiento de mipymes en el país. En Colombia hay
2,5 millones de micro, pequeñas y medianas empresas, según Confecámaras. Por regiones,
66% de este segmento productivo se concentra en Bogotá (Cantillo. Diana, 2016). Para
31
nuestro proyecto vemos un nicho de negocio en este tipo de empresas, en donde un sistema
de telefonía puede ser de gran utilidad, además los costos actuales de implementarlo puede
ser muy elevados.
Dentro de los beneficios cuantificables se establecen los siguientes:
Tiempo por concepto de traslados de personal y automatización de procesos.
Se establece que el tiempo hora-hombre por concepto de traslados y automatización
de procesos en 1.5 horas diarias.
(1.5 horas) * (6 días a la semana) = 9 Horas a la semana
(9 horas) * (4 semanas mensuales) = 36 Horas al mes
(36 oras) * (12 meses) = 432 horas al año
__________________________________________
Valor en pesos $1.241.136
Comercializar la aplicación en una tienda de Apps.
La aplicación se puede comercializar en la Play Store en donde se puede llegar a
muchos de las Mipymes del país, además de la venta de espacios publicitarios
dentro de la aplicación.
La aplicación se puede vender al usuario final a 15.000 pesos si tenemos en cuenta
que la cantidad de Mipymes en Colombia es de alrededor de 2.5 millones
estimamos una venta anual a 15000 de ellas
(1500 Mipymes)*($ 15.000)
____________________________
Valor en pesos $ 15.000.000al año
Soporte:
Haciendo uso de la aplicación móvil se disminuyen los errores de digitación al
momento de configuración de los contextos de Asterisk, debido a esto el soporte
puede reducirse considerablemente el equivalente al salario de un técnico mensual.
$1.200.000 * 12 meses
_____________________________
Valor en pesos $14.400.000 al año
Mejora la interoperabilidad del sistema Asterisk
32
Al utilizar un medio de comunicación genérico y de fácil acceso como los
dispositivos móviles permite usar dispositivos desde 400 o 500 mil pesos en
comparación con equipos de escritorio.
Valor en pesos $1.500.000
Los costos ya fueron calculados en la factibilidad económica, y después del primer año se
reducen a solamente el mantenimiento de la aplicación, la cual se estima en un 10% del
valor del costo total del proyecto, lo que muestra una disminución considerable de los
costos.
Tabla 4. Relación beneficio costo para una proyección de 5 años.
Año Beneficios Costos
1 $ 32.141.136 $ 36,540,000
2 $ 32.141.136 $ 3,654,000
3 $ 32.141.136 $ 3,654,000
4 $ 32.141.136 $ 3,654,000
5 $ 32.141.136 $ 3,654,000
$ 160.705.680 $ 51,156,000
Calculo de la elación beneficio-costo B/C
$ 160.705.680 = 3.1415
$ 51.156.000
Según el análisis beneficio-costo esta relación es mayor a 1. Lo que nos permite deducir
que el proyecto es viable en términos de rentabilidad.
33
1.12 Cronograma
34
35
2. Requerimientos de la aplicación
En esta etapa, se define cuáles son los procesos y procedimientos que se tienen en el
escenario para el cual se va a desarrollar la aplicación. Esto permite identificar los casos
concretos que debe automatizar el sistema, con el fin de aclarar el enfoque que quiere tener
el cliente con el software.
Como en cualquier proceso de desarrollo de software, es necesario definir las
especificaciones y requerimientos con las que la ap licación debe contar se establecen los
siguientes requisitos:
36
Identificador del requerimiento (RQT).
RQT- 1: Creación de un formulario de Autenticación de Usuario
Construir en la aplicación móvil un formulario con los campos usuario y contraseña, y el
botón enviar, con el fin de verificar si el usuario tiene acceso o no a la aplicación.
RQT- 2: Creación de un formulario para seleccionar la operación Asterisk
Construir un módulo en la aplicación móvil, en el cual el administrador de la red pueda
elegir alguna de las siguientes opciones Asterisk; Sip, Voice mail, Extensions, Sip show peers y Reload.
RQT- 3: Enviar Datos
Elaborar un mecanismo para reenviar la operación seleccionada desde el dispositivo móvil al Framework de telefonía.
RQT- 4: Conectar Framework
Construir un artefacto de software con el fin de integrarlo en el servicio web y lograr
comunicación con la consola Asterisk.
RQT- 5: Ejecución de comandos Asterisk
Implementar un método que permita enviar comandos desde el sistema web a la consola
Asterisk.
RQT- 6: Envío de mensajes de Texto
Construir un servicio en la aplicación móvil encargado de realizar consultas periódicas al servidor web, sobre las llamadas sin atender y posteriormente enviar un mensaje de texto al número telefónico celular que corresponda, informado al usuario que ha sido solicitado.
3 Modelado de casos de uso
Se describe un sistema en términos de sus distintas formas de utilización, cada una de las
cuales se conoce como un caso de uso (UNAD, 2015).Para este proyecto se definen los
casos de uso que representan los procesos con los que se interactúa en la aplicación, así
mismo encontramos un conjunto de actores que modelan cualquier entidad externa que
necesite intercambiar información con el sistema.
37
3.1 Actores
El administrador de la red, interactúa con el dispositivo móvil a través de una interfaz
gráfica, con opciones de plataforma Asterisk y comandos para cada plataforma. El sistema
móvil es el encargado de ejecuta el evento de enviar solicitudes al sistema web, según lo
decidido por el administrador de la red. Cuando el sistema web recibe las solicitudes, se
comunica con el Framework Telefonía, que finalmente ejecuta y despliega las operaciones
en una interfaz gráfica.
Tabla 5. Lista de actores.
Administrador de red
Sistema móvil.
Sistema web.
Framework Telefonía
Figura 1. Actores del sistema.
Fuente: elaboración propia.
uc Actores
Sistema móv il
Administrador de red
Framework telefonía
Sistema web
38
3.2 Casos de Uso
Después de haber definido a los actores del sistema, se establece la funcionalidad propia
del sistema por medio de los casos de uso.
El administrador de la red se encarga de seleccionar en la aplicación móvil, cual es la
plataforma a ejecutar. También elige la operación que desea ejecutar en esa plataforma. El
sistema móvil envía la solicitud de configuración al sistema web, el cual conecta el
Framework Telefonía y le envía los datos de plataforma y la operación a ejecutar
seleccionada por el administrador. Finalmente, el Framework conecta el dispositivo de la
plataforma indicada, ejecuta la operación y despliega el proceso en su interfaz gráfica. Las
operaciones que se pueden ejecutar en Asterisk, son; SIP, VOICEMAIL, EXTENSIONS,
SIP_SHOW_PEERS y RELOAD.
Tabla 6. Lista de casos de uso
Administrador
Autenticación del Administrador
Elegir plataforma
Seleccionar Operación
Sistema móvil
Enviar solicitudes de configuración
Sistema web
Conectar Framework Telefonía
Enviar comando y plataforma al Framework
Framework de Configuración de Telefonía
Conectar dispositivo
Ejecutar operación de configuración
La lista de operaciones incluye:
SIP
39
EXTENSIONS
VOICEMAIL
SIP_SHOW_PEERS
RELOAD
3.3 Especificación de casos de uso
Autenticar administrador
El administrador de la red ejecuta la aplicación móvil, un formulario es desplegado con los
campos usuario, contraseña y un botón enviar. El administrador ingresa sus datos de
registro, al pulsar el botón los datos son enviados al Servidor Web para realizar la
validación de usuario.
Figura 2. Caso de uso para el acceso a la aplicación.
Fuente: elaboración propia.
uc Acceso a la aplicacion
Sistema móvil
CU001 Autenticar usuario CU002 Validar datos de
autenticación
Administrador de red
«include»
40
3.4 Elegir plataforma y operación
Si la validación del usuario es correcta, la aplicación móvil despliega un segundo
formulario con opciones de configuración Asterisk. Entre las opciones se incluyen la
creación de extensiones telefónicas y buzones de correo, así como la verificación de
extensiones en uso y el reinicio de la terminal Asterisk, con el fin de guardar las
modificaciones realizadas en los archivos de configuración de la central telefónica,
producto de la interacción del administrador de red con el sistema.
Figura 3. Caso de uso para definir operación.
Fuente: elaboración propia.
3.5 Conectar Framework
La conexión al Framework consiste en una etapa intermedia entre la solicitud de
operaciones por el administrador de la red desde la aplicación móvil y el consumo del
servicio web. El Framework se encarga de lograr conectividad IP y enviar los comandos a
la consola Asterisk, así como obtener las respuestas de las operaciones y reenviarlas al
servicio web. El sistema web sólo puede reenviar la operación a ejecutar al Framework de
telefonía, hasta que reciba la operación desde el sistema móvil.
uc Definición de operación
Sistema móvil
Administrador de red
(from
Actores)
CU003 Elegir
plataforma y
operación
Operaciones que se
pueden ejecutar
-SIP
-VOICEMAIL
-EXTENSIONS
-SIP_SHOW_PEERS
-RELOAD
CU004 Env iar
operación«include»
41
Figura 4. Caso de uso para la conexión del sistema móvil con Framework de telefonía.
Fuente: elaboración propia.
3.6 Ejecutar operación
El servicio web realiza la conexión al Framework de Telefonía, el cual se encarga de
realizar la conexión de red con el servidor Asterisk, ingresar a la consola de telefonía y
ejecutar los comandos Linux. El sistema web primero debe conectar el Framework de
Telefonía, antes que éste ejecute la operación en el sistema Asterisk.
Figura 5. Caso de uso para la ejecución de la operación Asterisk.
Fuente: elaboración propia.
uc Conexion con framework
Sistema web
Sistema móv il
(from
Actores)
CU004 Env iar
operación
CU006 Reenv iar
operación
CU005 Conectar con
framework telefonía«include» «include»
uc Ejecutar operacion
Framework telefonía
Sistema web
(from
Actores)
CU005 Conectar con
framework telefonia
CU007 Ejecutar
operación Asterisk«include»
42
3.7 Enviar mensaje de texto
Un mensaje de texto es enviado si una llamada Asterisk no es atendida. El Framework de
Telefonía se encarga de verificar la recepción de las llamadas, el sistema móvil envía un
mensaje de texto al número registrado con el usuario responsable de la extensión
desatendida.
Figura 6. Caso de uso para el envío de mensajes desde el dispositivo móvil.
Fuente: elaboración propia.
3.8 Modelo de casos de uso
Inicialmente el administrador de red se autentica y elije plataforma y operación en la
aplicación móvil, esto es prerrequisito para que los datos sean enviados desde el dispositivo
móvil, hacia la aplicación web. Una vez el sistema web tiene los datos, realiza la conexión
al Framework de Telefonía y le reenvía los datos, para que finalmente, él ejecute la
operación en Asterisk. El Framework de Telefonía detecta las llamadas que no son
atendidas y comunica el evento al sistema móvil, la cual envía un mensaje de texto al
usuario de la extensión telefónica correspondiente.
uc Env io de mensajes
Framework telefonía
Sistema web
(from
Actores)
CU004 Env iar
operacion
CU008 Verificar
estado de llamada
CU009 Env iar
mensaje de texto«include» «extend»
43
Figura 7. Modelo general de casos de uso.
Fuente: elaboración propia.
uc Diagrama general
Administrador de red
(from
Actores)
CU001 Autenticar
usuario
CU002 Validar datos
de autenticacion
Sistema mov il
(from
Actores)
CU003 Elegir
plataforma y
operacion
CU004 Env iar
operacion
Sistema web
(from
Actores)
CU005 Conectar con
framework telefonia
CU006 Reenv iar
operacion
CU007 Ejecutar
operacion Asterisk
CU008 Verificar
estado de llamada
CU009 Env iar
mensaje de texto
Framework telefonia
(from
Actores)
«include»
«include»
«include»
«include»
«extend»
«include»
44
3.9 Documentación de casos de uso
Autenticar administrador.
El sistema permite habilitar y acceder a las operaciones
Tabla 7. Autenticar administrador.
Autenticar usuario
Caso de Uso: Autenticar usuario
Actores: Administrador
Descripción: El sistema valida si el usuario está registrado y que la
contraseña es la que está asignada a ese usuario, permitiendo
aprobar o denegar el acceso al Administrador de la red a las
operaciones de configuración dentro de la aplicación.
Casos de Uso
Asociados
Elegir plataforma y Operación
Flujo Principal: El sistema visualiza un formulario con los campos usuario y contraseña, además un botón ingresar que permite enviar al servidor los datos diligenciados por el
usuario.
Una vez enviada la información, el sistema comprueba si los datos del formulario de ingreso son correctos.
En caso de coincidencia el sistema permite acceso al usuario y despliega un menú con opciones de
configuración.
Si los campos diligenciados usuario o contraseña son
incorrectos el sistema informará por medio de una alerta, que el campo de texto usuario o contraseña no son
válidas.
Flujo Alternativo El sistema muestra un mensaje de validación fallida, indicando que el usuario o la contraseña no son válidas y
limpia los campos de texto para realizar un nuevo intento.
Después de 3 intentos fallidos la aplicación se cierra.
45
Propósito Permite habilitar y acceder a las operaciones de
configuración Asterisk.
Precondiciones: Ninguna.
Excepciones: E1: No es posible invocar el Método Remoto
Validacion_Usuario
Se presenta cuando no se ha desplegado el Servicio Web o
no hay comunicación con el Servidor, por lo tanto no se
puede realizar la llamada al procedimiento remoto.
Prioridad: Alta
Post-Condición: Luego de terminar el proceso de validación, el sistema
activa un menú con las opciones SIP, SIP_SHOW_PEERS,
EXTENSIONS, VOICEMAIL y RELOAD.
Complejidad: Media
Tabla 8. Elegir plataforma y operación.
Elegir Plataforma
Caso de Uso: Elegir plataforma y operación
Actores: Administrador de la red
Descripción: Otorga al administrador la función de seleccionar la
plataforma Asterisk para la ejecución de tareas.
Casos de Uso
Asociados
Enviar operación y plataforma
Flujo Principal: El sistema móvil despliega varias opciones de selección,
con las operaciones del sistema Asterisk para la
configuración del sistema.
La actividad de la aplicación móvil despliega la opción SIP con el fin de registrar un número telefónico móvil y
46
asociarlo a una extensión Asterisk.
La actividad de la aplicación móvil despliega la opción
voicemail, con el objetivo de registrar en el servidor
linux las llamadas sin atender.
La actividad de la aplicación móvil despliega la opción extensiones Asterisk, con el fin de asociar un número y nombre de extensión en la central telefónica al usuario
Asterisk.
Adicionalmente, el formulario de la aplicación móvil cuenta con la opción reload, esto con el objetivo de reiniciar la consola Asterisk y guardar los nuevos
cambios.
Finalmente, el usuario tiene la posibilidad de realizar la operación elegida pulsando el botón enviar.
Flujo Alternativo La aplicación móvil valida el orden de ejecución de las
operaciones Asterisk; Sip, extensions y voicemail, en caso que haya inconvenientes validando el orden de
ejecución, el sistema presenta una alerta informando sobre el fallo.
Únicamente se habilita la opción que debe ser diligenciada según el orden correcto.
Propósito Permite habilitar la plataforma en la que se ejecutarán las
operaciones de configuración del sistema.
Precondiciones: Pasar el proceso de autenticación.
Prioridad: Alta
Post-Condición: Luego de Elegir la plataforma Asterisk, el administrador de
la red, selecciona del dispositivo móvil una de las siguientes
opciones:
SIP
SIP_SHOW_PEERS
EXTENSIONS
VOICEMAIL
47
RELOAD
Complejidad: Media
Tabla 9. Enviar datos.
Enviar plataforma y operación
Caso de Uso: Enviar datos
Actores: Sistema Móvil
Descripción: Permite enviar los datos de plataforma y operación, desde la
aplicación móvil hacia la aplicación web.
Casos de Uso
Asociados
Elegir plataforma y operación, reenviar operación a
framework
Flujo Principal: El sistema móvil realiza la conexión al sistema web, con el
objetivo de transferir los datos necesarios para el
funcionamiento de la aplicación como dirección de alcance y
tipo de operación Asterisk.
Una vez el usuario elige la operación y pulsa el botón enviar, el sistema móvil crea un paquete SOAP con la solicitud y el nombre del método a consumir.
Adicionalmente, el sistema móvil define el tipo de
URL y la versión SOAP a utilizar para el envío de los datos.
Posteriormente, el sistema móvil, realiza el llamado al método del servicio web por medio de un objeto de
transporte.
Finalmente, el sistema móvil obtiene la respuesta del
consumo del método, en un objeto de tipo SoapPrimitive.
Flujo Alternativo Si el consumo del servicio web presenta inconvenientes, la aplicación móvil mediante una alerta informa al usuario sobre el fallo.
48
Propósito Enviar los datos seleccionados desde la aplicación móvil.
Precondiciones: El Administrador de la red debe haber elegido la plataforma
del dispositivo.
Excepciones: E1. No es posible Abrir el Socket de conexión
Se presenta cuando no se puede establecerla conexión de
socket con el dispositivo remoto. El sistema para configurar
dispositivos despliega el mensaje “No es posible establecer
Socket”.
E2. No se pueden Obtener Flujos de Entrada Salida
Se presenta cuando no se puede obtener objetos de lectura
escritura a partir del socket de comunicación.
Prioridad: Alta
Post-Condición: Se debe reenviar la información al Framework Telefonía.
Complejidad: Alta
Tabla 10. Reenviar datos al framework
Reenviar datos al Framework
Caso de Uso: Reenviar operación
Actores: Sistema Web
Descripción: El sistema web reenvía los datos de plataforma y
operación al Framework de Telefonía.
Casos de Uso
Asociados
Enviar operación y plataforma
Conectar Framework
Flujo Principal: El sistema Web recibe una petición SOAP
proveniente de la aplicación Móvil.
El sistema Web inicialmente recibe la dirección IP de alcance a conectar, así como el nombre de la
49
operación a ejecutar.
Posteriormente, se inicia un nuevo hilo de
ejecución para realizar la conexión al servidor
Asterisk por medio de un socket TCP/IP
Una vez establecida la conexión, se obtienen flujos de entrada y salida con el fin de poder escribir y leer en el socket y hacer posible el
intercambio de datos.
Finalmente, el sistema Web divide en subtareas la operación a ejecutar y las envía al servidor Linux por medio del flujo de salida, esto para ejecutar la
operación en el servidor.
Flujo Alternativo Si el sistema Web presenta problemas para establecer la conexión con el Servidor Asterisk, informa al usuario sobre el fallo mediante una
alerta.
Si el sistema Web presentar problemas para obtener los flujos de entrada y salida o ejecutar las subtareas de las operaciones Asterisk, informa al
usuario sobre el fallo mediante una alerta.
Propósito Lograr el intercambio de mensajes entre el sistema Web y
el Framework de Telefonía
Precondiciones: El sistema Asterisk debe encontrase activo.
Excepciones: E1. No es posible efectuar la Invocación Remota de
Métodos.
Se presenta cuando no es posible acceder al Framework.
Se despliega mensaje de no conexión.
Prioridad: Alta
Post-Condición: Ejecutar operación Asterisk.
Complejidad: Alta
50
Tabla 11. Conectar framework
Conectar Framework
Caso de Uso: Conectar Framework
Actores: Sistema Web
Descripción: Permite al sistema web acceder al framework de
configuración.
Casos de Uso
Asociados
Ejecutar operación en dispositivo
Flujo Principal: Una vez el sistema Web recibe una solicitud, entonces procede a conectar el Framework de
telefonía.
Para conectar el Framework de telefonía, el sistema Web invoca los métodos de la librería Connect.jar
La librería Connect.jar contiene enumeraciones que permiten realizar la conexión al servidor Asterisk.
Adicionalmente, Connect.jar tiene una opción gráfica
para desplegar en pantalla el paso a paso de la
ejecución de operaciones en el servidor Asterisk.
Flujo Alternativo Si el sistema Web no logra establecer conexión con
los métodos de la librería Connect.jar, informa al usuario sobre el fallo mediante una alerta.
El Sistema Web informa sobre el fallo por medio de
una alerta, en caso de no lograr acceso a las
enumeraciones que realizan la conexión con el servidor Asterisk.
Propósito Lograr acceso al Framework de Telefonía desde el sistema
Web
Precondiciones: El sistema web debe haber reenviado operaciones.
Excepciones: E1. No es posible Abrir el Socket de conexión
Se presenta cuando no se puede establecerla conexión de
51
socket con el dispositivo remoto. El sistema despliega el
mensaje “No es posible establecer Socket”
E2. No se pueden Obtener Flujos de Entrada Salida
Se presenta cuando no se puede obtener objetos de lectura
escritura a partir del socket de Comunicación. El Sistema
despliega el mensaje “No es posible obtener flujos Input
Output”
Prioridad: Alta
Post-Condición: Se debe desplegar la información sobre el estado de
operaciones en la interfaz gráfica.
Complejidad: Alta
Tabla 12. Ejecutar operación Asterisk.
Ejecutar Operación Asterisk
Caso de Uso: Ejecutar Operación
Actores: Framework Telefonía
Descripción: Permite ejecutar en el sistema Asterisk la operación
indicada.
Casos de Uso
Asociados
Conectar Framework
Flujo Principal: El sistema Web accede al Framework de telefonía enviando una operación a ejecutar.
El Framework de telefonía tiene definidas las
siguientes operaciones; ESTADO, SIP,
EXTENSIONS, VOICEMAIL y RELOAD.
En todas las operaciones el Framework inicialmente
52
realiza la autenticación, proporcionando un nombre
de usuario y una contraseña definidos en el Servidor Asterisk.
La operación ESTADO, invoca la consola Asterisk y ejecuta la operación correspondiente al estado.
Las operaciones SIP y EXTENSIONS inicialmente
eliminan los archivos sip.conf y extensions.conf,
respectivamente. Posteriormente, realizan la concatenación de dos archivos para reconstruir su
contenido. Por último, el Framework de telefonía asigna los permisos requeridos a los archivos sip.conf y extensions.conf.
Al igual que en las operaciones SIP y
EXTENSIONS, VOICEMAIL elimina el contenido del archivo voicemail.conf, después lo reconstruye y lo copia a una nueva ruta de operación.
RELOAD realiza el reinicio de la consola Asterisk
Flujo Alternativo El Framework de telefonía informa al usuario por medio de una alerta sobre algún fallo que se presente
en el proceso de autenticación con el Servidor Asterisk.
El Framework de telefonía informa al usuario por
medio de una alerta sobre fallos que se presenten al
procesar archivos de configuración en el Servidor Asterisk.
Propósito Ejecutar la función del módulo seleccionado en Asterisk.
Precondiciones: Debe existir conectividad IP con el dispositivo móvil.
Excepciones: E1. No es posible efectuar conexión.
Se presenta cuando no se puede acceder al dispositivo.
Prioridad: Alta
Post-Condición: Despliegue del resultado de configuración en el Framework
Complejidad: Alta
53
Tabla 13. Enviar mensaje de texto.
Enviar Mensaje de Texto
Caso de Uso: Enviar mensaje de texto
Actores: Sistema Móvil
Descripción: Permite notificar las llamadas sin atender, enviando un
mensaje de texto al número móvil registrado en la extensión
telefónica.
Casos de Uso
Asociados
Ejecutar Operación Asterisk
Flujo Principal: El sistema móvil activa un servicio en segundo plano con el
fin de monitorear periódicamente las llamadas no atendidas,
éste servicio es consultado periódicamente por el
Framework de Telefonía.
El sistema móvil define un servicio que ejecuta una
tarea periódicamente por medio de un Timer.
La tarea es ejecutada cada 30 segundos en la aplicación móvil.
Ésta tarea construye un paquete SOAP y realiza el consumo del método Celular del sistema Web,
pasando como parámetro un número móvil.
Al consumir el método, el sistema móvil recibe un
mensaje, que es reenviado al número telefónico del dueño de la extensión Asterisk.
Flujo Alternativo El sistema Móvil debe identificar el número de llamadas sin atender por medio de un contador.
El sistema Móvil retorna un mensaje alternativo en caso de falla al enviar el mensaje de texto al número
celular correspondiente.
Propósito Permite notificar al usuario responsable de la extensión
sobre una llamada no atendida.
54
Precondiciones: La extensión Asterisk debe existir.
Excepciones: E1 mensaje no llega al usuario registrado.
Se presenta cuando no se ha desplegado el Servicio Web o
no hay comunicación con el Servidor, por lo tanto no se
puede realizar el envío del mensaje.
Prioridad: Alta
Post-Condición: El usuario responsable de la extensión recibe un mensaje
con el nombre del emisor y la fecha y hora de la llamada.
Complejidad: Muy Alta
55
3.10 Diagrama de clases
Figura 8. Diagrama de clase de la aplicación.
Fuente: elaboración propia.
56
3.11 Descripción del diagrama de clases
La aplicación móvil está compuesta por las actividades MainActivity y Actividad2.
La clase MainActivity se encarga de realizar la autenticación en el servidor. Entre tanto que
la clase Actividad2 tiene las opciones de configuración u operaciones a ejecutar en el
servidor de telefonía Asterisk. Una lista desplegable permite seleccionar la plataforma a
utilizar.
En la segunda actividad de la aplicación móvil son declarados una serie de objetos
RadioButton para representar las opciones de los módulos Sip, Extensions y Voicemal de
Asterisk. Un objeto de tipo RadioGroup permite agruparlos y hacer una sola elección entre
todas las alternativas.
En las dos actividades del sistema móvil se encuentra el método onClick, para gestionar los
eventos asíncronos cuando el administrador de la red, presione los botones de la interfaz
gráfica.
Los servicios Web son aplicaciones modulares que se pueden describir, publicar, localizar e
invocar a través de la Web (Wahli et al., 2016), para este caso la aplicación servidor consta
del servicio web, la clase Telefonía con tres métodos; Validar_Usuario, Operation y
Celular. La primera interacción es del administrador de la red con la aplicación móvil, la
cual invoca el método validar_usuario del servicio web. Posteriormente se instancian las
clases de los módulos Asterisk; Extensiones, Líneas y Voicemail. Cada clase contiene las
instrucciones necesarias para modificar los archivos de la central telefónica en el servidor
Linux. Esta configuración se realiza con el llamado al método Operation del servicio web,
desde el dispositivo móvil. Se envían dos parámetros; la dirección IP de alcance para
conectar el servidor y el nombre del método. Y finalmente, el método Celular se encarga
del envío de los mensajes de texto al número móvil del usuario que corresponde, cuando se
detectan las llamadas Asterisk no atendidas. Toda la comunicación entre las aplicaciones y
el paso de mensajes es realizado por medio del protocolo SOAP.
57
4. Implementación
4.1 Diseño físico de la red
El diseño físico de la red sólo contempla el nivel de acceso, que es proporcio nado por un
router inalámbrico, al cual acceden los demás dispositivos por medio de la tecnología WIFI
802.11 b/g. Al tratarse de una topología sencilla con un pequeño número de dispositivos
que funcionan en intranet, no existe nivel de distribución ni un core de Networking.
Figura 9. Diseño físico de la red.
4.2 Diseño lógico de la red
La red se implementa con un direccionamiento lógico que ocupa el segmento clase C
192.168.1.0/24. Se utiliza la encriptación WPA2 para el acceso WIFI a los dispositivos. Las
siguientes son las asignaciones de direcciones a los dispositivos:
Tabla 14. Diseño lógico de la red.
192.168.1.1/24 Router WIFI
192.168.1.5/24 Servidor Asterisk – Servidor MySQL 192.168.1.50/24 Estación IP, extensión Asterisk 192.168.1.70/24 Estación IP, extensión Asterisk
192.168.1.10/24 Teléfono Móvil Android
Figura 9. Diseño físico de la red
Fuente: elaboración propia.
58
A continuación se detalla la configuración LAN del punto de acceso.
Figura 10. Configuración LAN del punto de acceso.
Fuente: elaboración propia.
Hay un intervalo de direcciones para la asignación automática de nuevas extensiones. El
intervalo va hasta la dirección 192.168.1.100/24.
A continuación se detallan otros aspectos de configuración WIFI, para el acceso a la red
inalámbrica.
SSID de la red
4.3 Opciones de ejecución de Asterisk
El proyecto contiene opciones de configuración para los módulos Asterisk; Sip.conf,
Extensions.conf y Voicemail.conf. Adicionalmente, tiene las opciones Reload, para
reiniciar Asterisk y que los cambios tomen efecto, y la opción Sip_Show_Peers, con el fin
Figura 11. Configuración WIFI.
Fuente: elaboración propia.
59
de poder visualizar cuales teléfonos IP han sido registrados en el sistema. Es importante
resaltar que la configuración de Sip.conf integra un nombre de extensión y un número
móvil, el cual será utilizado por la aplicación Android, para enviar un mensaje por cada
llamada no atendida, indicando el remitente, la fecha y hora del evento.
Figura 12. Opciones Asterisk.
Fuente: elaboración propia.
4.4 Autenticación de Usuario
Se crea en la aplicación móvil una actividad principal, con dos objetos EditText y objeto
Button. Con el fin de consumir el servicio web se crea un objeto SoapObject, el cual recibe
como parámetro el nombre del método a invocar. La llamada al WebMethod remoto se
realiza por medio de un objeto de tipo HttpTransportSE.
La actividad Android implementa la interface OnClickListener para gestionar el evento de
pulsar el botón.
4.5 Selección de Operación Asterisk
En una segunda actividad Android, se realiza la implementación de las opciones Asterisk.
Con el fin de consumir el servicio web se crea un objeto SoapObject, el cual recibe como
parámetro el nombre del método a invocar. La llamada al WebMethod remoto se realiza
por medio de un objeto de tipo HttpTransportSE.
60
La actividad Android implementa la interface OnClickListener para gestionar el evento de
pulsar el botón y el evento OnCheckedChangeListener con el fin de seleccionar la
plataforma Asterisk.
4.6 Conectar Framework
Para implementar el Framework de Telefonía Asterisk, se utiliza la librería telnet.jar de
apache y en conjunto con una enumeración java, la cual tiene las operaciones a ejecutar y
los tokens de los comandos linux, se genera la librería Eigrp.jar.
4.7 Ejecutar Operación
Una vez el usuario selecciona la operación desde la aplicación móvil, un mensaje SOAP es
enviado para realizar el consumo del Servicio Web, el servicio tiene los métodos
Validacion_Usuario y Operación, en el primero se procesan los datos de usuario y
contraseña, y se retorna un número mayor que uno si en la base de datos se encuentra
coincidencia para los datos.
Adicionalmente, se despliega una ventana para mostrar el proceso de las operaciones que se están ejecutando.
En el WebMethod operación, se selecciona cuál de las operaciones Asterisk se quiere ejecutar por medio de la estructura de selección if y el nombre de la operación. Y se
implementa la lógica correspondiente a cada operación.
4.8 Enviar mensaje de texto
La aplicación Android está compuesta por dos actividades; la actividad principal en la que
se realiza el proceso de autenticación, con un formulario para los datos de usuario y
contraseña y un botón para administrar el evento. Adicionalmente, la aplicación Android
integra un servicio en segundo plano para enviar mensajes de texto automáticamente a un
dispositivo móvil, cuando una extensión de la central telefónica no responde.
Una segunda actividad realiza el trabajo de administración Asterisk, con opciones para
crear las instrucciones necesarias en los archivos de configuración /etc/asterisk/sip.conf,
/etc/asterisk/extensions.conf y /etc/asterisk/voicemail.conf y así crear una extensión de
telefonía IP. Las opciones reload y sip show peers también se encuentran integradas en la
segunda actividad, la primera sirve para reiniciar el sistema Asterisk y la segunda permite
61
revisar cuales líneas se encuentran conectadas. Otro factor importante en la segunda
actividad es que finalizando el método onCreate, instancia una intención, una clase Intent,
esto para iniciar el servicio que en segundo plano envía los mensajes de texto al número
móvil correspondiente del propietario de la extensión. En el servicio, se utiliza la clase
Toast de Android para desplegar un label en pantalla que comunica al usuario sobre el
envío de los mensajes, sin interrumpir el curso normal de la aplicación.
El servicio instancia un temporizador que periódicamente en intervalos de 30 segundos
ejecuta una tarea TimerTask. Esta tarea se encarga de consultar al servic io web sobre las
extensiones que tienen llamadas sin atender, el servicio retorna el número de celular y el
mensaje que debe ser enviado, y por medio del método sendSMS realiza el envío.
En el directorio de buzones Asterisk existe un subdirectorio por cada extensión telefónica.
Una llamada sin respuesta genera automáticamente un archivo en el subdirectorio de la
extensión correspondiente. Por esta razón, es necesario ejecutar en el servidor Asterisk, en
la sección “Aplicaciones al inicio”, el siguiente comando Debian, con el objetivo que cada
5 segundos se asignen permisos a los archivos generados dinámicamente y la aplicación
servidor pueda eliminarlos. Por cada archivo creado, se envía el mensaje al número móvil
que corresponda y posteriormente se elimina el archivo para evitar que se repita el envío.
watch -n 5 'chmod -R 777 * /var/spool/asterisk/voicemail'.
4.9 Descripción de la aplicación Servidor
La aplicación servidor consiste en 3 paquetes que siguen la estructura; presentación, lógica
y persistencia. El paquete presentación contiene el servicio web, el cual se comunica por
medio del API ksoap2 con la aplicación móvil Android. Los métodos del servicio web son;
Validación_usuario, Operación y Celular.
Es necesaria la validación del administrador de la red, para acceder a los módulos de
configuración de Asterisk, se realiza por medio de una consulta a la base de datos del
sistema, que retorna un valor positivo, si las cadenas de texto de usuario y contraseña son
correctas y coinciden con los valores almacenados en la tabla autenticación de la base de
datos proyecto.
Adicionalmente, si la verificación de usuario es correcta, entonces se habilita el acceso a las
operaciones de Asterisk, esto se configura por medio de un método llamado Operation en el
servicio web, que toma como argumentos una dirección IP de alcance y un comando.
Finalmente el método celular es el encargado de realizar el envío del mensaje a los números
de celular asociados a extensiones que fueron invocadas sin ninguna respuesta.
62
Entre tanto, el paquete lógica contiene las clases Voicemail, Usuario, Líneas, Extensiones y
Registro. Por medio de las cuales se realiza la configuración de los módulos Sip.conf,
Extensions.conf y Voicemail.conf de Asterisk. Así como el llamado a las clases de
persistencia para registrar los datos correspondientes a las extensiones; tales como nombre,
identificador de extensión y número de teléfono celular.
El paquete de persistencia contiene la clase que conecta la base de datos del sistema por
medio de la clase ConexionDAO, con métodos para registrar, consultar y validar
información. Una clase adicional, llamada ExtensionsDAO, es la encargada de almacenar
los datos de las extensiones de los usuarios.
Figura 13. Estructura de paquetes aplicación servidor.
Fuente: elaboración propia.
4.10 Descripción de la Implementación Aplicación móvil
El SDK Manager funciona como máquina virtual Java para el sistema Android, es
necesario instalar con anterioridad el JDK, antes de configurar el SDK. Un conjunto de
herramientas son integradas en el SDK, que posibilitan la selección de versiones de
Android a instalar, y el uso de paquetes extras. Habitualmente, es obligatorio instalar las
versiones de APIs más recientes de Android. El proceso de instalación de paquetes del
SDK tarda en completarse. No obstante, es necesaria una instalación robusta de este
conjunto de herramientas, puesto que de lo contrario no es posible compilar las aplicaciones
63
móviles con éxito, y se generan errores por paquetes de dependencia ausentes en la
instalación.
Se deben verificar las casillas Tools, Android 4.1.2 (API16), Android 4.0 (API14),
Android 2.2 (API8) así como las opciones extras Android Support Library y Google USB
Driver. Esta instalación es sobre Windows.
Al crear proyectos Android, se deja por defecto la configuración de APIs, que Eclipse
utiliza. Siempre es necesario, cuando se instala el SDK manager, incluir la API más
reciente, A continuación se muestran las APIs seleccionadas en el SDK para desarrollar
este proyecto:
64
Figura 14. Paquetes de APIs necesarias para el proyecto.
Fuente: elaboración propia.
65
.
Figura 15. Paquetes extra necesarios para implementar el proyecto.
Fuente: elaboración propia.
66
4.10.1 Integración de APIsAndroid en eclipse
Para habilitar el uso de aplicaciones Android en Eclipse, es necesario instalar un plugin que
se obtiene desde el siguiente enlace, como se observa en la figura.
https://dl-ssl.google.com/android/eclipse/
Figura 16. PluginAndroid para eclipse.
Fuente: elaboración propia.
Éste se encarga de integrar las Apis de Android a Eclipse y poder implementar proyectos de
aplicación móvil en el IDE.
Figura 17. Integración Android a eclipse.
Fuente: elaboración propia.
67
4.10.2 Desarrollo de la aplicación móvil
La aplicación Móvil consta de dos actividades Android y un servicio que se ejecuta en
segundo plano, que es el encargado de enviar los mensajes de celular.
Es necesario configurar un dispositivo virtual para poder compilar aplicaciones Android.
Figura 18. Configuración de propiedades para dispositivo virtual.
Fuente: elaboración propia.
El dispositivo virtual permite probar las aplicaciones antes de instalarlas en el dispositivo
real, cuenta con funcionalidad de redes incorporada, de forma que es posible realizar tareas
hacia servidores y dispositivos remotos, emulando la funcionalidad del dispositivo real.
68
Figura 19. Dispositivo Android virtual.
Fuente: elaboración propia.
Los ejecutables Android tienen extensión APK, el proceso de instalación de las
aplicaciones Android en los dispositivos reales se realiza por medio de utilidades de
software intermedio como Google Drive.
La actividad principal de Android es la encargada de realizar la validación de usuario para
el ingreso a las opciones de configuración.
El método onCreate inicializa los campos de Usuario y Password. Y un botón para activar
el evento de validación. El botón tiene asociado un evento OnClickListener, que es
invocado asincrónicamente con el click del usuario.
En el método onClick se realiza el paso de mensajes SOAP desde la aplicación móvil hacia
el servicio web, se obtiene un resultado que de ser satisfactorio permite el acceso a la
actividad secundaria del sistema. De lo contrario, un mensaje de advertencia es desplegado,
indicando al usuario el error de validación.
69
5 Conclusiones
Realizar el estudio de diferentes layouts Android, permite diseñar una aplicación móvil para administrar una central Asterisk, con una mejor ubicación y distribución de los widgets Android
Con la correcta distribución de la funcionalidad en varias actividades Android, es
posible construir una interfaz de fácil manejo para el usuario final permitiendo la administración de una central Asterik.
Para lograr administrar una central Asterisk desde una aplicación Android, deben considerarse procesos de autenticación de usuario, conexión programática a la
consola Asterisk y la ejecución automática de tareas en el servidor linux.
El protocolo SIP para el manejo de las sesiones de usuario, ssh o telnet para establecer conexión y el protocolo SOAP que permite el intercambio de información en servicios web, son en conjunto los principales protocolos que deben
gestionarse para la configuración de una central Asterisk.
Definir un modelo de análisis y diseño a partir de los requerimientos de una aplicación, facilita la etapa de implementación y desarrollo.
Construir una aplicación móvil para la administración de una central Asterisk, es un proyecto con alta demanda en el mercado empresarial, que corresponde a un
retorno de la inversión positivo. Esto permite concluir que el proyecto es viable y beneficioso desde el punto de vista económico.
70
6 Referencias
Agesic.gub (2013). Modelo para el análisis de los costos y beneficios. Disponible en
https://www.agesic.gub.uy/innovaportal/file/3284/1/modelo_para_el_analisis_de_costos_y
_beneficios_v20130822.pdf. Consultado [01 Sep. 2016]
Arena, h. (2003). La biblia de linux. Ciudad de buenos aires: MP Ediciones.
Callgest.net. (2016).Tarifas - Call center Callgest. Disponible en:
http://www.callgest.net/tarifas/. Consultado [3 Sep. 2016].
Davidson, J., Peters, J. y Gracely, B. (2000).Voice over IP fundamentals. Indianapolis, en:
Cisco Press.
Dixon, J. (2009). History of Zapata Telephony and how it relates to Asterisk
PBX.Disponible en: http://www.zapatatelephony.org/. Consultado [7 May. 2016].
Docplayer.es. (2016). Tarifa de servicios de assistcall center 2015 recepción o emisión de
llamadas por teleoperadores coste de llamadas atendidas o realizadasDisponible en:
http://docplayer.es/444445-Tarifa-de-servicios-de-assist-call-center-2015-recepcion-o-
emision-de-llamadas-por-teleoperadores-coste-de-llamadas-atendidas-o-realizadas.html.
Consultado [3 Sep. 2016].
Gómez, j. (2007). Estudio y diseño de una red de telefonía de voz sobre IP para plataforma
siglo XXI. 1ª ed. Pamplona. Disponible en:
http://www.unipamplona.edu.co/unipamplona/hermesoft/portalIG/home_1/recursos/tesis/co
ntenidos/tesis_septiembre/05092007/estudio_diseno_de_una_red_voz.pdf. Consultado [2
Mar. 2016].
Goncalves, Flavio. (2007). Asterisk PBX Guía de la Configuración. Janeiro.
González, E. (2006). Asterisk y telefonía tradicional. 1ª ed. Santiago. Disponible en:
http://ftp://ftp.powerfast.net/pub/manuales/Asterisk/tesis%20Asterisk.pdf. Consultado [10
Feb. 2016].
Ietf.org. (2016). Disponible en: http://www.ietf.org/rfc/rfc3261.txt. Consultado [5 Mar.
2016].
Linux-es.org. (2014). Sobre Linux | El rincón de Linux. Disponible en: http://www.linux-
es.org/sobre_linux. Consultado [16 Mar. 2016].
Luengo, i. (2009). Caso práctico de la implantación de un sistema de telefoníaVoIP en una
empresa. 1ª ed. Sevilla. Disponible en:
71
http://www.igln.es/pdf/Telefonia%20de%20Codigo%20Abierto%20Asterisk%20mas%20C
aso%20Practico.pdf. Consultado [20 Feb. 2016].
MrRohan. (2015). World Mobile Applications Market Worth US$25 Billion by 2015,
Disponible en: http://www.marketsandmarkets.com/Press Releases/ mobile- applications-
market.asp.Consultado[25 Mar. 2016].
Outsource2india.com. (2016).Managing your entire outsourcing venture -
Outsource2india.Disponible en: https://www.outsource2india.com/callcenter/precios-
estructura.asp. Consultado[3 Sep. 2016].
Puentes, M. (2016). Asterisk - Grupo Linux S.A, Asterisk Colombia, Groupware bogota,
groupware Latinoamérica, software libre Bogotá, expertos Linux, casa software,
programadores java. Disponible en: http://www.grupolinux.net/main/soluciones-
empresariales/telefon-a-con-Asterisk.html. Consultado [12 Mar. 2016].
Sidar.org, 2016.“La comunicación Humana”. Disponible en:
http://www.sidar.org/acti/jorna/4jorna/ivponen/imagenac/ponencia.htm. Consultado [01 Feb
2016].
UNAD. (2012). Datateca. Recuperado el 29 de octubre de 2015, de http://datateca.unad.
educo/contenidos/233016/EXE_SAM/leccin_2_que_es_una_aplicacin_mvil.html
Urtubia, j. (2007). Voz sobre IP “Creación de una central telefónica a través del
móduloAsterisk-UBUNTU”. 1ª ed. Valdivia. Disponible en:
http://cybertesis.uach.cl/tesis/uach/2007/bmfciu.82v/doc/bmfciu.82v.pdf. Consultado [5
Mar. 2016].
Cantillo E, Diana. (2016,14 de abril). Mipymes generan alrededor del 67% del empleo en
Colombia. Dinero. Recuperado de http://www.dinero.com/edicion-
impresa/pymes/articulo/evolucion-y-situacion-actual-de-las-mipymes-en-colombia/222395
Villamarín Hidalgo, A. H., &MalizaAnaluisa, J. P. (2009). Implementación de un servidor
de correo electrónico utilizando Linux con herramienta virtual.
UNAD. (2015). Datateca. Recuperado el 15 de noviembre de 2016, de
http://datateca.unad.edu.co/contenidos/301309/AVA_301309/Modelo_de_requisitos/3_Mo
delo_de_Casos_de_uso.PDF.
Wahli, U., Burroughs, O., Cline, O., Go, A. and Tung, L. (2016). Disponible en:
http://www.redbooks.ibm.com/redbooks/pdfs/sg247257.pdf. Consultado [15 Nov. 2016].
