DISEÑO E IMPLEMENTACIÓN DEL SISTEMA DE INFORMACIÓN TELEFÓNICO COMUNITARIO CBD-CONECTA2.

DESIGN AND IMPLEMENTATION OF COMMUNITY TELEPHONE

INFORMATION SYSTEM CBD-CONECTA2

Yudy Constanza Marroquin Forero1 Cesar Johan Carrillo Hoyos2

Msc. Luis Fernando Pedraza Martinez3

Universidad Distrital “Francisco José de Caldas” – Facultad Tecnológica. Ingeniería en Telecomunicaciones

yudymarroquin@gmail.com1, cesarjohan@gmail.com2, pedrazaluis2001@gmail.com3 Bogotá, Colombia

Abstract: In this article shown development of a system with the capacity of making automatic phone calls to provide information to the community in Ciudad Bolivar in Bogota is being made, this tool looks forward to have a positive impact in the community, get them close to the information technologies and communication by means of a traditional object such as the telephone and an application-oriented information needs, the system manages a database responsable for selecting recipients and messages depending on the user. .

Keywords: Subscribers, Jitter, Session Protocol,SIP, RTP,VoIP

1. INTRODUCCION Las tecnologías de la información y comunicación (TIC) se convirtieron en parte fundamental de los cambios de la sociedad y de la economía. Esta serie de cambios han marcado la separación de los sectores sociales por su nivel de ingresos y por la posibilidad de acceder a la información. Las bondades tecnológicas han beneficiado a una pequeña parte de la población, condición que es conocida como brecha digital. Este proyecto plantea una solución por vía tecnológica a una problemática real que consiste en la dificultad para entregar información a la población que por diferentes factores no acceden a otras tecnologías de la información diferentes al teléfono, busca apoyar también los objetivos de los ejes de política del Plan de Gobierno Nacional en TIC; “todos los colombianos conectados e informados”. [1] El desarrollo elaborado incorpora sistemas de información para el control y administración de bases de datos,

conectividad IP (Protocolo de Internet) para brindar acceso y control remoto, una interfaz de usuario grafica que brinda fácil acceso y gestión, una central de conmutación automática dedicada que garantiza la ejecución de las llamadas y entrega de los mensajes a los usuarios. En el mercado comercial y académico se encuentran desarrollos que utilizan parcialmente partes de la estructura de la solución planteada. Tales como AUTODIALER1, VICIDIAL2, GNUDIALER3, y proyectos con fines sociales y que usan infraestructuras similares se encuentran en desarrollo como el caso de MobilED4 (mobile audio wiki) cuya idea original es llevar contenido a teléfonos móviles de nivel de entrada.

1http://www.yoursautodialer.com/autodialer-

review.html

2 http://www.vicidial.org/vicidial_brochure_sheet.pdf

3 http://www.voip-info.org/wiki/view/GnuDialer

4 http://mobiled.uiah.fi/

Resumen: En este artículo se presenta el desarrollo de un sistema con la capacidad de realizar llamadas telefónicas automáticas para brindar información a la comunidad de Ciudad Bolívar en Bogotá. Esta herramienta busca impactar positivamente a la comunidad y acercarla a las tecnologías de la información y las comunicaciones mediante un medio tradicional como el teléfono y un aplicativo orientado a sus necesidades informativas, el sistema gestiona una base de datos encargada de seleccionar los destinatarios y los mensajes personalizados según el usuario.

Estas herramientas buscan incrementar el servicio y la atención a los clientes en forma masiva, mediante la interacción del uso sistematizado y planeado del teléfono, buscando mayores coberturas, la estandarización y aseguramiento en la entrega de mensajes y la mejora de la rentabilidad para las empresas. 2. IMPLEMENTACION SERVIDOR TRIXBOX. Este proyecto se basa en el funcionamiento de la tarjeta PCI MotorotaWildcard x100p5 dispositivo electrónico que gestionado por una herramienta informática brinda a un computador la posibilidad de trabajar entre otras funciones como PBX (Private Branch Exchange). Por otra parte Asterisk es una plataforma de telefonía convergente de código abierto, de naturaleza adaptable, complementada por el soporte de una gran cantidad de estándares basadas en Linux [2]. Asterisk, posee una Interfaz gráfica llamada FreePBX conocida como Trixbox6, para este proyecto se utiliza la versión 2.6.18, dicha interfaz de administración puede ser accesada desde cualquier navegador Web ingresando la dirección IP perteneciente al equipo donde se encuentra instalada. Cabe anotar que el equipo que se use para esta aplicación debe tener una tarjeta de red y al menos una ranura PCI (Peripheral Component Interconnec). Los requerimientos mínimos de memoria y procesamiento para este aplicativo pueden variar según la magnitud de la aplicación deseada, la tabla 1 relaciona las características necesarias:

Tabla 1. Requerimientos mínimos de procesador y Memoria para la PBX. 5 http://www.x100p.com/support/doc/novavox-x100p-se-

ukcallerid-history.pdf 6 http://fonality.com/trixbox/

3. IMPLEMENTACION DE ESCENARIOS TELEFONICOS: Evidenciar y validar las situaciones reales de comportamiento es el objetivo de las pruebas que a continuación son descritas, las tendencias encontradas y su posible solución, permiten que el esquema de funcionamiento planteado desde la teoría a nivel de programación sea corregido y/o mejorado. 3.1 Llamadas SOFTPHONE a SOFTPHONE. La primera parte tiene por objetivo monitorear una llamada con el packet sniffer WIRESHARK7 (captura de las tramas de red) y analizar la manera como se lleva a cabo la comunicación de voz por medio de los protocolos correspondientes al inicio de la llamada, durante la transmisión de los paquetes de voz y en el cierre de sesión. Para ello se configura el esquema de la figura 1 y se analiza la transacción SIP (Session Initiation Protocol). [3].

SERVIDOR TRIXBOX PBX

SERVICIO DHCP

TERMINAL VoIP # 1

TERMINAL VoIP # 2

ESQUEMA INICIAL DE PRUEBAS VoIP

Figura 1. Esquema inicial pruebas VoIP. De este escenario es importante rescatar el aporte a nivel de programación, para determinar las banderas y avisos que con mayor frecuencia iteran desde la PBX, de esta forma se evalúan las condiciones a las cuales la aplicación en desarrollo podría enfrentarse como por ejemplo: perdida de datos, negación a inicios de sesión, tiempos de espera. Dicha información permite desarrollar algoritmos más robustos que ahondan en un mejor desempeño de la aplicación.

7 http://www.whireshark.org

3.2. Llamadas SOFTPHONE a RTPBC. El segundo paso consiste en evaluar la manera en la cual se gestiona una llamada desde la red IP mediante el Softphone hacia la RTPBC, tal como se observa en la figura 2. Esto con el ánimo de evaluar los mismos parámetros del ejercicio anterior.

RTPBC

ABONADOS

SERVIDOR TRIXBOX PBX

SERVICIO DHCP

TERMINAL DE OPERACIONES

ESQUEMA DE FUNCIONAMIENTO LOCAL (Acceso LAN únicamente)

Figura 2. Esquema de funcionamiento local. Al establecer el vínculo por RTP ( Real-time Transport Protocol) se evidencia que es necesario mantener un canal de tamaño dinámico de transporte de paquetes [4], debido a esto se hizo necesario realizar una verificación indirecta de las direcciones IP de HOST y la IP remota con la cual el servicio se encontraba en funcionamiento. Como resultado a los dos análisis se genera un algoritmo basado en la vigilancia inicial únicamente de la bandera ACK y se desprecian el resto de indicadores, para las respuestas de establecimiento de comunicación se evalúan solo 100 y 200 únicas opciones de funcionamiento para el sistema [5], luego de la validación de estos dos indicadores se establece la comunicación con el protocolo RTP para el transporte de paquetes. El algoritmo obtenido puede ser visto en detalle en la figura 3.

Figura 3. Diagrama de Flujo Algoritmo SIP y RTP implementado. 3.3. PARAMETRIZACION DE ELEMENTOS SONOROS EN LLAMADAS TELEFONICAS Con los anteriores esquemas telefónicos y mediante la captura, tabulación y análisis de datos transportados conocidos como PAYLOAD (Carga útil), también se realiza el análisis digital de los siguientes patrones sonoros: Timbre de FAX, voces humanas, contestadores automáticos, tonos de ocupado y tiempos de silencio. El objetivo de este análisis es la obtención de patrones matemáticos que le otorguen

INICIO

FIN

ENVIO DE INVITACION SIP

CB2 -> PBX

Respuesta SIP = ACK

Respuesta SIP =100

(Intentando)

200 OK

INICIO DE TX RTP

Bye

ESPERA++

ESPERA<60

Respuesta SIP = ACK NO

NO

NO

NO

NO

SI

SI

SI

SI

SI

SI

NO

argumentos al aplicativo para que sea capaz de decidir la no entrega o entrega de mensajes, disminuyendo así las fallas en el envió de información y reduciendo la incertidumbre de entrega de los mismos a los usuarios del sistema. 3.3.1. COMPARACIÓN DE OBJETOS Se realizaron las grabaciones de las señales sonoras anteriormente mencionadas, los datos obtenidos son almacenados en vectores de comparación (buffers), este tipo de información se captura en cada una de las llamadas y un selector basado en variables estadísticas determina cual es el patrón que mas se acerca y de esta forma define la naturaleza de la señal, tal y como se muestra en la figura 4. Esta información permite al sistema decidir la no entrega o entrega de los mensajes, y permite un mejor registro de los resultados.

Figura 4. Diagrama de bloques para reconocimiento de señales. Una vez analizados los requerimientos de tiempos, verificaciones de estado mediante las herramientas de monitoreo, los tipos de señal y el esquema de comparación de objetos, se diseño el bosquejo de integración para responder a cada una de las necesidades de los sub-bloques funcionales: Gestión de Base de datos, validación de información, interfaz grafica, transporte de información por IP; obteniendo el diagrama que se muestra en la figura 5.

Figura 5. Sistema de información telefónico Ciudad Bolívar CONECTA2. 4. INTERFAZ GRAFICA DE USUARIO. La interfaz de desarrollo elegida es NetBeans IDE 6.8, entorno de desarrollo hecho principalmente para el lenguaje de programación JAVA, adicional a esto es un producto libre y gratuito que no presenta restricciones de uso. En la figura 6 se puede apreciar la interfaz grafica de usuario desarrollada, y sus vínculos para trabajar con cada modulo del proyecto.

Figura 6. Interfaz grafica Sistema de información Telefónico comunitario CBD-Conecta2. La figura 6 es un pantallazo de la aplicación (software) donde se tienen las siguientes funciones:

Archivo: Permite guardar los registros de los últimos eventos y exportarlos a archivos de texto plano o Excel. Llamada automática: Detiene el ciclo de llamadas permitiendo realizar cambios de parámetros. Base de datos: Presenta las opciones, para borrar, cargar o modificar registros en la base de datos. Configuración: Activa la selección de destinatarios especiales y mensajes, reúne las condiciones con las cuales se filtra la información a enviar. Permite el ingreso a la base de datos de nuevos mensajes. Configuración de Mensaje: Visualiza el mensaje en caso de ser texto o nombre del archive si es audio que se encuentra en reproducción Voz: Brinda la posibilidad de escoger el tipo de voz para reproducir los mensajes, el sistema actualmente cuenta con Javier (Voz Masculina Mexicana) y Rosa (Mujer español Latino), para mensajes en Español y para mensajes en ingles cuenta con Crystal (Mujer) y Sam (Masculina). Operación programada: Define los espacios temporales de operación del sistema. Estado de línea telefónica: Visualiza gráficamente los repiques de marcado, el estado de la llamada, nombre de la persona y teléfono contactado. Llamada de prueba: Espacio para realizar llamadas individuales de prueba para el sistema.

5. BASE DE DATOS.

Se diseño e implemento una base de datos para la gestión de la información bajo la plataforma de licencia GPL (General Public License) MySQL version 1.2.12. La base de datos diseñada permite el almacenamiento, actualización, transferencia de datos y accesibilidad desde JAVA para: • Datos personales o de organizaciones

(nombres, profesión, documento) • Datos de contacto. • Mensajes y contenidos escritos para

difundir • Mensajes y contenidos en audio para

difundir. • Estado y hora de las llamadas realizadas. • Estado de llamadas pendientes.

6. RESULTADOS. En la figura 7 se observa el diagrama de flujo que corresponde al programa central, este programa realiza los requerimientos a cada modulo del proyecto y ejecuta la operación total del sistema de información diseñado:

Figura 7. Diagrama de flujo Programa principal 6.1. EVALUACION DE LOS PARAMETROS DE CALIDAD Como parte del proceso de evaluación final del proyecto, se realizan las comparaciones con sistemas de VoIP y telefonía fija evaluando los factores de calidad. El ejercicio diseñado consiste en realizar una llamada en la cual es reproducido un archivo de audio de prueba, para comparar el desempeño de los dos sistemas y tener una referencia tanto subjetiva como cualitativa.

6.1.1. ANALISIS PARA UNA LLAMADA ESTABLECIDA ENTRE 2 SOFTPHONES. Para la primera parte de la prueba fueron necesarios dos computadores autenticados en la PBX Trixbox, los abonados utilizados son 1007 y 1005 respectivamente, el softphone utilizado es X-lite. En la figura 8 se muestran las características de la llamada, y los gráficos y estadísticas de la misma, la escala temporal es un espacio por minuto.

Figura 8. Análisis para la Calidad de voz en una llamada establecida entre 2 softphones. Se puede observar que durante el primer minuto de la llamada existe una relación inversamente proporcional entre las variables Retardo y Jitter [6], esto ocurre mientras los buffers de datos se preestablecen entregando un valor constante para la comunicación luego de la asignación de recursos. 6.1.2. ANALISIS PARA UNA LLAMADA ESTABLECIDA ENTRE CB2 Y RTPBC. Para la parte final de la prueba se realiza una llamada a un abonado fijo en Bogotá (4177991) usando la plataforma del “sistema

de información telefónico comunitario CBD-CONECTA2”. La escala temporal del grafico es de 30 segundos entre punto y punto. La figura 9 presenta las grafica de los resultados obtenidos para esta prueba.

Figura 9. Análisis para la calidad de voz en una llamada establecida entre CBD-CONECTA2 Y RTPBC. De la figura 9 es importante resaltar el cambio en el factor de calidad que presenta la variable MOS pasando de un 3,7 a un 4,4 y su valoración cuantitativa de calidad donde el factor R gana también 25 puntos acercándose al ideal de calidad consignado en la tabla 2 donde se define el valor ideal para las variables de QoS en VoIP. Los valores de esta tabla son comparados con los valores encontrados en los dos escenarios de prueba y referenciación utilizados. Obteniendo de esta manera las variaciones y diferencias que impactan el factor de calidad en VoIP para cada caso.

Jitter (ms) 50

Retardo (ms) 180

Perdida de Paquetes (%) 10

MOS 4

R Factor >50 Tabla 2. Variables que definen el QoS en VoIP.

6.1.3. TASA DE DATOS DEL SISTEMA Al programar un ciclo de 240 llamadas para efectuarse en un día se obtienen los resultados graficados en la figura 10 donde se presenta el número de llamadas por día y la calidad de servicio prestada.

Figura 10. Calidad de servicio – Numero de llamadas por hora. El intervalo de las 12 del día registra el mayor numero de llamadas con un total de 60, el potencial de llamadas realizables depende de: la longitud del mensaje a entregar, el tiempo que tarde el receptor en contestar al llamado entre otros factores; para esta prueba se entrego el siguiente mensaje: “Muy buenos días este es un saludo especial para el estudiante [x][y] del grupo de investigación Gidenutas de la Universidad Distrital Francisco Jose de Caldas Sistema de Información Telefónico comunitario Ciudad Bolivar conectados MUCHAS GRACIAS POR SU ATENCION que tenga un feliz dia” (Duración Aproximada: 22 segundos). En la figura 11 se encuentra graficado el trafico generado en el lapso de las 6 a las 22 horas del día de pruebas, al igual que en la figura 10 se registra el aumento significativo de trafico (VoIP en Amarillo) hacia las 12 horas por un pico máximo de llamadas ejecutadas por el sistema y trafico generado por otras aplicaciones (color verde).

Figura 11. Trafico generado. El promedio registrado para la tasa de datos en voz es de 39,6 Kbps debido a los intervalos en los cuales no se realizaron llamadas, pero para los momentos de mayor uso se puede apreciar que la variable asciende a los 128 Kbps aproximadamente. Las transacciones SIP representan un 1% del tráfico generado por el sistema, mientras que la voz representa un 49%. Para observar con mejor detalle y de manera individual el tráfico para el sistema en desarrollo se monitorea con la herramienta WIRESHARK una llamada de 60,40 segundos de duración y se determina el valor en Kbps de la Tasa de datos necesaria para la operación del sistema. De acuerdo a la información contenida en la figura 12 se conoce que el tamaño de los paquetes RTP equivale 213,58 bytes.

Figura 12. Resumen de datos para una

llamada.

6.1.3.1. ANÁLISIS PARA TASA DE DATOS Para realizar el análisis de tasa de datos individual por tramas RTP se debe conocer en primer lugar el tamaño de cada paquete RTP del sistema, de esta manera: 213,58 bytes =1078,64 bits (tamaño de cada paquete RTP para el sistema). Con el anterior valor y la tasa de paquetes (ver figura 12.) obtenemos la Tasa de datos:

[ ] [ ]KbpsKbpsdeDatosTasa 122. =

Es importante obtener el valor de tasa de datos y velocidad de paquetes para cada una de las tramas, esto permite observar el óptimo desempeño del sistema con cualquiera de estas. Para ello se utiliza como referencia una llamada con las características consignadas en la tabla 3.

Trama RTP AC34 Max Delta (ms) 21,2 Max Jitter (ms) 0,23 Mean Jitter (ms) 0,3 Max Skew (ms) -1,18

Total RTP Paquetes

3,59

Paquetes esperados 3,59 Paquetes Perdidos 0

Duración (s) 7,16 Tabla 3. Resumen de datos para una llamada. Para comenzar se calcula la tasa de paquetes para la trama AC34. Por definición la tasa de paquetes esta dada por la cantidad de paquetes en unidad de tiempo como se define en la ecuación (2).

Reemplazando los valores de total de paquetes y duración de trama en la ecuación (2) se obtiene:

==

segundos

paquetes5013,0

7,16

3,59 paquetes de Tasa

Con el valor conocido anteriormente para el tamaño de paquetes del sistema y la velocidad de paquetes de la trama AC34 se calcula la tasa de datos con la ecuación (1)

[ ]

×

=

seg

paq

paq

bitsbpsdeDatosTasa 5013,064,1078.

Se obtiene finalmente:

[ ]

=

segundo

bitsbpsdeDatosTasa 860.

TASA DE DATOS PARA LA TRAMA AC34

ES IGUAL A 860 Bpbs.

Bajo el mismo procedimiento para cada una de las tramas resultan los valores de Tasa de datos y velocidad de paquetes consignados en la tabla 4.

Tabla 4. Análisis para la tasa de datos individual por tramas RTP.

Como resultado se obtiene un desempeño que cumple con las características de la Tasa de datos acorde al codificador utilizado (G.711) y a los protocolos implementados para el transporte de voz. Tasa de datos promedio 85,57 Kbps.

[ ] )1)(()(. etetasadepaquxpaqueteRTPbpsdeDatosTasa =

[ ]

=

segundo

bitsbpsdeDatosTasa 55,121928.

)2(Duracion

Paquetes de Total paquetes de Tasa

=

segundos

paquetes

7. CONCLUSIONES • En este trabajo se presenta una nueva

herramienta que tiene por objeto la disminución de la brecha digital mediante las comunicaciones tradicionales y difundidas, buscando incluir a la población que se rehúsa o no tiene acceso a las nuevas TIC´s.

• Gracias a este sistema de información

telefónico la comunidad en general pero en especial los habitantes de Ciudad Bolívar podrán ser informados con solo una llamada acerca de temas de interés general como: jornadas de vacunación, capacitaciones, ofertas de empleo, información de la alcaldía local entre otros.

• Mediante la integración adecuada de

tecnologías, el conocimiento de protocolos y lenguajes de programación, se realiza un aporte a la convergencia de las comunicaciones, planteando como desafíos para trabajos futuros la modularidad e interacción con contenidos multimedia, redes celulares etc.

• Los parámetros de calidad obtenidos para

el sistema superan ampliamente el desempeño del softphone usado para comparar; sin embargo hay que aclarar que el equipo terminal en este desarrollo no requiere etapas de decodificación pues el usuario final recibe una señal analógica.

• El ancho de banda requerido para la

aplicación luego del inicio de sesión es de 85,57 Kbps.

• El desarrollo de software se realizó mediante un modelo de ingeniería de requerimientos, utilizando los elementos que se consideraron necesarios para cumplir con el modelo de desarrollo en etapas, que suelen utilizar las herramientas de análisis, de diseño, de implementación y de testing.

8. REFERENCIAS [1]http://www.colombiaplantic.org.co/medios/docs/PLAN_TIC_COLOMBIA.pdf (ultimo Ingreso marzo 16 de 2011) [2] SMITH, J Y MADSEN, L. (2005). Asterisk, the future of telephony. O’Reilly Media Inc. USA, Primera Edición pp 11 [3] DAVIDSON, J. y PETERS, J. (2001).

Fundamentos de voz sobre IP, Pearson

Educación S.A, Madrid, pp 145-146-147. [4] HUIDOBRO MOYA, J. (2006). Comunicaciones en redes WLAN, Noriega Editores. México: Limusa pp 109-110. [5] KEAGY, S. (2001). Integración de redes de voz y datos, Pearson Educación S.A, Madrid, pp 382. [6] GOBL, C. y. NÍ CHASAIDE A. (2003). “The role of voice quality in communicating emotion, mood and attitude”. Speech Communication. USA, pp. 189.