Desarrollo de un sistema de soporte telefónico autónomo para ISPS inalámbricos

UNIVERSIDAD TECNICA PARTICULAR DE LOJA

ESCUELA DE CIENCIAS DE LA COMPUTACIÓN

Desarrollo de un Sistema de Soporte Telefónico

Autónomo para ISPs Inalámbricos

PROYECTO PREVIO A LA OBTENCIÓN DEL TITULO DE INGENIERO EN INFORMÁTICA

ASPIRANTES

:

José Andrés Cuenca Ojeda.

Luis Enrique Romero Juelas.

DOCENTE

–

INVESTIGADOR:

Ing. María Paula Espinoza.

Cesión de Derechos

Nosotros, José Andrés Cuenca Ojeda y Luis Enrique Romero Juelas, declaramos ser autores del presente trabajo y eximimos expresamente a la Universidad Técnica Particular de Loja y a sus representantes legales de posibles reclamos o acciones legales.

Adicionalmente declaráramos conocer y aceptar la disposición del Art. 67 del Estatuto Orgánico de la Universidad Técnica Particular de Loja que su parte pertinente

textualmente dice: “Forman parte del patrimonio de la Universidad la propiedad

intelectual de investigaciones, trabajos científicos o técnicos y tesis de grado que se realicen a través, o con el apoyo financiero, académico o institucional (operativo) de la

universidad”.

F:………. F:……….

Certificación

Certifico que el presente trabajo fue desarrollado por los señores José Andrés Cuenca Ojeda y Luis Enrique Romero Juelas, bajo mi supervisión.

Agradecimiento

Agradecemos el apoyo de nuestras familias y amigos que nos han alentado para

graduarnos y ser profesionales. De igual manera agradecemos a la empresa Lojasystem

proveedora de Internet inalámbrico y a todo su personal de soporte técnico por las

Dedicatoria

Este proyecto se lo dedico a mi familia que me ha apoyado toda mi vida y quiere lo mejor para mi, ésta es una meta para mi padres porque quieren dejar a sus hijos la mejor herencia que les pueden dar, que es una profesión.

Muchas gracias a toda mi familia, en especial a mi esposa por la paciencia que me ha tenido.

Luis Enrique

Quiero dedicar este proyecto con un afecto especial a mi madre que siempre me estuvo dando aliento para salir adelante y culminar este proyecto

Índice

OBJETIVOS ... vii

1. GENERALIDADES ... 1

1.1. ISP Inalámbrico ... 2

1.1.1. Estructura de un ISP Inalámbrico ... 3

1.1.1.1. NOC o Centro de Operaciones ... 3

1.1.1.2. Backbone inalámbrico ... 4

1.1.1.3. Equipos suscriptores ... 4

1.1.2. Tecnologías para redes WLAN ... 5

1.1.2.1. Estándar IEEE 802.11 ... 6

1.2. Plataforma de desarrollo ... 8

1.2.1. Linux ... 10

1.2.1.1. Características de Linux ... 10

1.2.1.2. Distribución de GNU/Linux ... 13

1.2.1.3. Linux frente a otros sistemas operativos ... 14

1.2.2. Asterisk ... 15

1.2.2.1. Funcionalidades generales ... 15

1.2.2.2. Funcionalidades avanzadas de asterisk ... 16

1.2.2.3. Aspectos generales ... 17

1.2.2.4. Reducción extrema de costos ... 17

1.2.2.5. Limitaciones de la arquitectura de asterisk ... 17

1.2.2.6. Requisitos técnicos del sistema ... 18

1.2.2.7. Arquitectura base de asterisk ... 18

1.2.3. Ivr ... 21

1.2.3.1. Servicios ... 21

1.2.3.2. Tecnologías involucradas ... 22

2. INTRODUCCIÓN ... 23

2.1. Análisis de los problemas más comunes en el área de

help desk de un ISP inalámbrico ... 24

2.2. Soluci

_{ón Propuesta…….}

... 26

3. IMPLEMENTACIÓN Y PRUEBAS DEL SISTEMA ... 30

3.1. Implementación ... 30

3.1.2.1. Plan de discado ... 31

3.1.2.2. Instalación de un Softphone para las pruebas del IVR. ... 32

3.1.3. Implementar Acceso a Consola SSH sin Contraseña ... 32

3.1.4. Instalar script de monitoreo en el servidor IPCOP…. ... 34

3.2. Detalles de Implementación ... 34

3.2.1. Arquitectura del Sistema de Soporte Automático ... 34

3.2.2. Integración del Sistema... 36

3.3. Pruebas del Sistema ... 37

3.3.1. Escalabilidad ... 39

3.4. Resultados Obtenidos ... 39

4. CONCLUSIONES Y RECOMENDACIONES ... 44

4.1. Conclusiones ... 44

4.2. Recomendaciones ... 45

5. BIBLIOGRAFÍA ... 46

6. APÉNDICES ... 48

6.1. Encuesta realizada a ISPs Inalámbricos ... 48

6.2. Tabla de los problemas de soporte más comunes de un ISP

inalámbrico ... 49

6.3. Distribución Linux IPCOP ... 51

6.4. Hardware a utilizar ... 53

Objetivos

autónomo para proveedores de internet inalámbrico (ISP)”.

Y ampliando más la presente declaración se pretende:

Desarrollar de una interfaz de soporte telefónico que bajo ciertos requerimientos pueda trabajar en forma autónoma y que pueda deducir por sí mismo y sin la intervención de ningún ser humano la posible avería que tiene un cliente. Este sistema contestará las líneas telefónicas de soporte técnico; el cual será capaz de detectar hasta un 60% de averías del cliente y recomendará soluciones a los problemas más comunes de soporte.

Que ante condiciones anormales durante la provisión del servicio tales como de degradación del sistema, congestión del backbone o caída de algún enlace, el sistema pueda comunicarse y/o recibir feedback de los administradores del ISP, esto mediante emails, o mensajes de texto. Este deberá detectar al menos un 60% de condiciones anómalas.

Capítulo 1.

Generalidades

En el capítulo 1, se describirá brevemente como funciona un ISP inalámbrico, su estructura y sus componentes, como también se explicarán los estándares de las tecnologías inalámbrica, así mismo se hará una exposición de la plataforma de desarrollo de la tesis, como una breve explicación de Linux, sus características principales, comparativa junto con otros sistemas operativos, y por ultimo una introducción al Asterisk recalcando sus funcionalidades generales, funcionalidades avanzadas, ventajas, limitaciones, requisitos técnicos, su arquitectura con los conceptos relacionados con el esquema (canal, codecs, protocolos, extensión, contexto, aplicaciones, dialplan), Introducción al IVR, sus servicios y las tecnologías involucradas.

En el capítulo 2, la introducción expondrá algunos antecedentes de trabajos similares así como también el análisis de los problemas más comunes en el área de help desk (soporte) de un ISP inalámbrico, basado en las repuestas de una encuesta realizada a varios proveedores de internet inalámbrico, luego del análisis se propondrá una solución de la forma en que podrían ser resueltos los problemas por la lógica de un computador.

En el capítulo 3 se realizará la implementación del sistema de soporte, en el cual se describirá detalladamente la arquitectura del sistema de soporte automático para luego integrarlo, se desarrollarán las interfaces para que el sistema de soporte interactué con el sistema de gestión del ISP inalámbrico y se procederá con las respectivas pruebas para comprobar los niveles de exactitud del sistema y los niveles de satisfacción del cliente, se determinará la escalabilidad y luego de lo cual se hará un análisis e interpretación de los resultados obtenidos.

El capítulo 5 hace referencia a la bibliografía utilizada, cabe destacar que al tratarse de proyecto de implementar un sistema de soporte telefónico autónomo para solución de problemas en el área de soporte de un ISP inalámbrico la mayor parte de referencia bibliográfica se la ha obtenido de la Internet, y de foros en la Web.

Y por último en los apéndices se anexará el modelo de la encuesta realizada a los ISPs inalámbricos, la tabla de los problemas de soporte más comunes de un ISP inalámbrico, breve introducción a la distribución Linux IPCOP, el hardware a utilizar, el dialplan, los archivos tipo texto del código fuente y por ultimo un modelo de una breve encuesta realizada vía telefónica a los usuarios del sistema.

También se anexa un manual que detalla las pantallas de instalación y configuración del Linux distribución Debian y del Asterisk.

1.1. ISP INALÁMBRICO

Se llama ISP a un proveedor de servicios de internet, viene del término inglés “Internet Service Provider”. Pero cuando un ISP lo provee al servicio en forma inalámbrica se le

llama simplemente “ISP Inalámbrico”; en ingles es llamado Wireless ISP o más concreto WISP1_.

De acuerdo a la legislación ecuatoriana los ISPs son denominados proveedores de valor agregado (RESOLUCIÓN 534-22-CONATEL-2006). Estos se conectan con el

usuario final por medio de enlaces inalámbricos o de espectro ensanchado. Este tipo de equipos trabajan generalmente en frecuencias que no requieren concesión por parte del estado, que funcionan en las bandas de 900Mhz, 2.4 y 5 GHZ, estos equipos son generalmente basados en el estándar 802.11a/b/g.

1.1.1. Estructura de un ISP inalámbrico

Un ISP inalámbrico posee la misma estructura que uno tradicional con la diferencia que la infraestructura de acceso o de distribución es inalámbrica; la misma que consiste de una serie de sistemas multipunto interconectadas formando un backbone1_{, las cuales}

a su vez se enganchan los usuarios mediante los equipos suscriptores o CPEs2_.

1.1.1.1. NOC o Centro de Operaciones

Es el lugar donde residen los servidores, routers, firewall, infraestructura administrativa y soporte técnico. Aquí el ISP recibe el internet por parte de los carriers o mayoristas (Figura 1-1).

INTERNET

CLIENTES DEL ISP INALAMBRICO RED DE TELEFONIA

PUBLICA PSTN

PBX y Sistema de

Soporte telefonico Servidores: dns, email, proxy

Router, firewall

ETHERNET

Figura 1-1.Centro de Operaciones (NOC)

1.1.1.2. Backbone Inalámbrico

1 _{Principales conexiones troncales de Internet}

Es la infraestructura de distribución mediante la cual el ISP llega a sus clientes.

Es un conjunto de sistemas multipuntos conectados mediante algún medio de trasmisión al NOC central. Cada multipunto provee servicios de Internet a los clientes que están en su área de cobertura en forma similar a las redes celulares (Figura 1-2).

Figura 1-2. Backbone inalámbrico

1.1.1.3. Equipos Suscriptores

Comúnmente llamados CPEs1_{. Es un equipo inalámbrico que conecta al cliente con el}

como, teléfono Wi-Fi1_{, usuarios residenciales, usuarios móviles (laptops). etc .}

Figura 1-3. Equipos suscriptores [1]

1.1.2. Tecnologías para redes WLAN2

Las necesidades de movilidad de los usuarios de equipos de computación es muy importante hoy en día, razón por la cual Ethernet, que ha sido la tecnología más

ampliamente usada, tiene un competidor muy fuerte, las Redes Inalámbricas de Área Local (WLAN). Las WLAN se están utilizando cada vez más en edificios de oficinas,

aeropuertos, centros comerciales, restaurantes, hoteles, entre otros lugares públicos.

Las WLAN son muy versátiles en las oficinas, ya que son un complemento a la

infraestructura cableada, brindando a los usuarios móviles una conectividad

1_{Wireless Fidelity (}

permanente. Adicionalmente permite que visitantes se conecten al Internet o a la red sin tener que conectarse físicamente, lo que implica tener puertos disponibles en el lugar donde se requiera ubicar el computador.

1.1.2.1. Estándar IEEE 802.11 [2]

IEEE 802.11 o Wi-Fi es un estándar de comunicaciones que define el uso de los dos

niveles más bajos de la arquitectura OSI 1(capa física y capa de enlace de datos), este

estándar norma el funcionamiento en una WLAN.

El protocolo 802.11 estandarizado en 1997 describe tres técnicas de transmisión de la capa física: la primera el método de infrarrojos que es la misma tecnología que se usa en los controles remotos de televisión; los otros dos métodos utilizan la técnica de radio de espectro expandido, como son espectro ensanchado por salto de frecuencia (FHSS) y espectro ensanchado por secuencia directa (DSSS). Estas dos últimas técnicas utilizan la frecuencia sin licenciamiento de 2.4 GHz, y una velocidad de 1 Mbps y 2 Mbps.

Al trabajar en la banda ISM (Industrial, Scientific and Medical) de 2.4 GHz se tiene

mucha interferencia con artefactos eléctricos como: puertas automáticas de garajes controladas por radio, los hornos microondas, los teléfonos inalámbricos, etc. La interferencia disminuye la velocidad efectiva al producirse muchos errores en la transmisión, debiéndose retransmitir las tramas erróneas.

En 1999 se introdujeron dos técnicas adicionales de modulación para alcanzar mayor capacidad de transmisión, éstas son Multiplexación por División Ortogonal de Frecuencia (OFDM) y Secuencia Directa en Espectro Extendido de Alta Velocidad

(HRDSSS) que permiten velocidades de hasta 54 Mbps y 11 Mbps, respectivamente. En

el año 2001 se introdujo OFDM para la frecuencia de 2.4 GHz, ya que la primera

La (Tabla 1-1) muestra una comparativa de los diferentes estándares 802.11 con sus respectivas características, ventajas y desventajas. Es necesario hablar de las tecnologías inalámbricas puesto que el uso adecuado de una tecnología inalámbrica depende mucho en la prevención de problemas que se puedan dar en los enlaces inalámbricos con los clientes.

Tabla 1-1 Comparativa de los estándares 802.11

Estándar 802.11 a 802.11b 802.11g 802.11n

Velocidad 54Mbps 11Mbps 54Mbps 600 Mbps

Frecuencia 5Ghz 2.4Ghz 2.4Ghz

Distancias 8 a 23 metros 30 a 45 metros 30 a 45

metros

Ventajas -No muy saturada

-Los equipos con este estándar no son muy

comunes, son más utilizados en usuarios corporativos

- Algunos Hot spots están ya

instalados con este estándar y Existen bastantes equipos funcionando. Compatible con el Estándar 802.11b por lo que pueden coexistir con redes

de este estándar.

Altas velocidades

1.2. PLATAFORMA DE DESARROLLO

El presente trabajo pretende implementar un sistema de soporte telefónico automático, esto será realizado mediante una centralita de VOIP1_{, por lo cual se ha escogido la}

plataforma de desarrollo de telefonía basada en software libre Asterisk, este producto sobre el sistema operativo Linux, permite desarrollar centrales telefónicas con todas las características que se esperan de una PBX2 comercial, trabajan con voz sobre IP en varios protocolos (SIP, H323) e interoperan con casi todo el equipo estándar basado en telefonía IP usando hardware relativamente barato. De tal manera que es fácil implementar servicios que sólo ofrecen los grandes sistemas PBX propietarios como, correo de voz, conferencia de voz, comunicación de llamada, respuesta interactiva de voz, cola de llamadas, servicio de identificación de llamadas, registro detallado de llamadas etc.

Para funcionar con voz sobre IP no necesita de ningún hardware adicional, ahora para interconectar con la telefonía tradicional requiere de tarjetas especiales de muy bajo costo como las tarjetas FXO (Foreign Exchange Office) y mediante el software, realizar y recibir llamadas de teléfono. Sirve sobre todo para implementar centralitas telefónicas (PBX) con un computador. Los dispositivos para conectar un teléfono a un computador son las llamadas FXS (Foreign Exchange Station).

Un claro ejemplo de FXO es un típico módem o tarjeta Fax-Modem.

La (Figura 1-4) muestra el funcionamiento de un sistema de telefonía IP con Linux.

Figura 1-4. Sistema de Telefonía IP con Linux

Haciendo una breve explicación de la (Figura 1-4). El usuario realiza y recibe llamadas desde y hacia su línea telefónica actual utilizando un teléfono convencional, hace uso de la red de telefonía pública (ETB/EPM), las tarjetas o dispositivos de entrada análogo (FXO) permiten la conexión entre el computador (servidor Linux) y la línea telefónica convencional. El servidor Asterisk que está montado en el servidor Linux permite la conversión y administración de las señales analógicas a digitales y viceversa, las mismas que son trasmitidas utilizando la red de datos existente sea esta una red privada (Intranet) o a través de internet sin importar en que parte del mundo se encuentre. Los Adaptadores de Voz sobre IP ATA1 _{(FXS) son necesarios para una conexión entre la}

red de datos y los teléfonos convencionales.

1.2.1. Linux

Es un Sistema Operativo. El mismo que está basado en una implementación de UNIX, de distribución libre para computadores que facilita su uso y operación. En la actualidad puede ser instalado en gran variedad de hardware, incluyendo computadores de escritorio, computadores de mano, celulares, dispositivos empotrados, videoconsolas (Xbox, PlayStation), enrutadores y algunos modelos de iPod. Fue desarrollado para el i386 y ahora soporta los procesadores más comunes del mercado.

Como sistema operativo, Linux es muy eficiente y tiene un excelente diseño. Es multitarea, multiusuario, multiplataforma y multiprocesador.

1.2.1.1. Características de Linux [3]

Multitarea: La palabra multitarea describe la habilidad de ejecutar varios programas al mismo tiempo.

LINUX utiliza la llamada multitarea preventiva, la cual asegura que todos los programas que se están utilizando en un momento dado serán ejecutados, siendo el sistema operativo el encargado de ceder tiempo de microprocesador a cada programa.

Multiusuario: Muchos usuarios usando la misma máquina al mismo tiempo.

Multiplataforma: Las plataformas en las que en un principio se puede utilizar Linux son Pentium III, PentiumIV, Intel Core duo, etc. También existen versiones para su utilización en otras plataformas, como Alpha, ARM, MIPS, PowerPC y SPARC.

Multiprocesador: Soporte para sistemas con más de un procesador está disponible para Intel y SPARC (Scalable Processor ARChitecture).

Funciona en modo protegido 386.

Protección de la memoria entre procesos, de manera que uno de ellos no pueda colgar el sistema.

Política de copia en escritura para la compartición de páginas entre ejecutables: esto significa que varios procesos pueden usar la misma zona de memoria para ejecutarse. Cuando alguno intenta escribir en esa memoria, la página (4Kb de memoria) se copia a otro lugar. Esta política de copia en escritura tiene dos beneficios: aumenta la velocidad y reduce el uso de memoria.

Memoria virtual usando paginación (sin intercambio de procesos completos) a disco: A una partición o un archivo en el sistema de archivos, o ambos, con la posibilidad de añadir más áreas de intercambio sobre la marcha Un total de 16 zonas de intercambio de 128Mb de tamaño máximo pueden ser usadas en un momento dado con un límite teórico de 2Gb para intercambio. Este límite se puede aumentar fácilmente con el cambio de unas cuantas líneas en el código fuente.

La memoria se gestiona como un recurso unificado para los programas de usuario y para el caché de disco, de tal forma que toda la memoria libre puede ser usada para caché y ésta puede a su vez ser reducida cuando se ejecuten grandes programas.

Librerías compartidas de carga dinámica (DLL's) y librerías estáticas.

Se realizan volcados de estado (core dumps) para posibilitar los análisis post-mortem, permitiendo el uso de depuradores sobre los programas no sólo en ejecución sino también tras abortar éstos por cualquier motivo.

Compatible con POSIX, System V y BSD a nivel fuente.

Emulación de iBCS2, casi completamente compatible con SCO, SVR3 y SVR4 a nivel binario.

Todo el código fuente está disponible, incluyendo el núcleo completo y todos los drivers, las herramientas de desarrollo y todos los programas de usuario; además todo ello se puede distribuir libremente. Hay algunos programas comerciales que están siendo ofrecidos para Linux actualmente sin código fuente, pero todo lo que ha sido gratuito sigue siendo gratuito.

Control de tareas POSIX (operaciones básicas de las tareas de tiempo real).

Emulación de 387 en el núcleo, de tal forma que los programas no tengan que hacer su propia emulación matemática. Cualquier máquina que ejecute Linux parecerá dotada de coprocesador matemático. Por supuesto, si el ordenador ya tiene una FPU (unidad de coma flotante), esta será usada en lugar de la emulación, pudiendo incluso compilar tu propio kernel sin la emulación matemática y conseguir un pequeño ahorro de memoria.

Soporte para muchos teclados nacionales o adaptados y es bastante fácil añadir nuevos dinámicamente.

Consolas virtuales múltiples: varias sesiones de login a través de la consola entre las que se puede cambiar con las combinaciones adecuadas de teclas (totalmente independiente del hardware de video). Se crean dinámicamente y puedes tener hasta 64.

Soporte para varios sistemas de archivo comunes, incluyendo minix-1, Xenix y todos los sistemas de archivo típicos de System V, y tiene un avanzado sistema de archivos propio con una capacidad de hasta 4 Tb y nombres de archivos de hasta 255 caracteres de longitud.

Acceso transparente a particiones MS-DOS (o a particiones OS/2 FAT) mediante un sistema de archivos especial: no es necesario ningún comando especial para usar la partición MS-DOS, esta parece un sistema de archivos normal de Unix (excepto por algunas restricciones en los nombres de archivo, permisos, y esas cosas). Las particiones comprimidas de MS-DOS 6 no son accesibles en este momento, y no se espera que lo sean en el futuro. El soporte para VFAT (WNT, Windows 95) ha sido añadido al núcleo de desarrollo y estará en la próxima versión estable.

Un sistema de archivos especial llamado UMSDOS que permite que Linux sea instalado en un sistema de archivos DOS.

Soporte en sólo lectura de HPFS-2 del OS/2 2.1

Appletalk.

Software cliente y servidor Netware.

Lan Manager / Windows Native (SMB), software cliente y servidor.

Diversos protocolos de red incluidos en el kernel: TCP, IPv4, IPv6, AX.25, X.25, IPX, DDP, Netrom, etc.

1.2.1.2. Distribución de GNU/Linux

Una distribución es un modo de facilitar la instalación, la configuración y el mantenimiento de un sistema. Al principio, las distribuciones se limitaban a recopilar software libre, empaquetarlo en disquetes o CD-ROM y redistribuirlo o venderlo. GNU

es un acrónimo recursivo para "Gnu No es Unix" (“GNU's Not UNIX”), GNU es el nombre de un proyecto con el objetivo de crear un sistema operativo completamente libre.

Ahora las grandes distribuciones -RedHat, SuSE, Caldera, Mandrake, Corel Linux, TurboLinux...- son potentes empresas que compiten entre sí por incluir el último software, a veces también software propietario, con instalaciones gráficas capaces de autodetectar el hardware y que instalan un sistema entero en unos cuantos minutos sin apenas preguntas (Dee-Ann Leblanc 2001).

En una distribución hay todo el software necesario para instalar en un ordenador personal; servidor, correo, ofimática, fax, navegación de red, seguridad, etc.

1.2.1.3. Linux frente a los otros sistemas operativos

Linux es una muy buena alternativa frente a los demás sistemas operativos. Más allá de las ventajas evidentes de costo, ofrece algunas características muy notables.

En comparación con las otras versiones de Unix para PC, la velocidad y confiabilidad de Linux son muy superiores. También está en ventaja sobre la disponibilidad de aplicaciones, ya que no hay mucha difusión de estos otros Unixes (como Solaris, XENIX o SCO) entre los usuarios de PC por sus altos costos (Daniel L. Morril 2002).

1.2.2. Asterisk

Es un software PBX que usa el concepto de software libre (GPL), el asterisk permite conectividad en tiempo real entre las redes PSTN (red telefónica del servicio público) y redes Voip (Jim Van Meggelen 2005) .

1.2.2.1. Funcionalidades Generales

La (Figura 1-5) representa un esquema conceptual de Asterisk el cual es capaz de trabajar con prácticamente todos los estándares de telefonía tradicional como Líneas analógicas, Líneas digitales (E1, T1, accesos básicos). Soporta casi todos los protocolos de VozIP como SIP, IAX2 , MGCP, Cisco Skinny. (Gorka Gorrotxategui-Iñaki Baz 2006).

Figura 1-5. Esquema conceptual de Asterisk [4]

Asterisk es mucho más que un PBX central. Se puede crear cosas nuevas en telefonía como:

– Conectar oficinas en varias provincias sobre IP. Esto puede ser hecho por Internet o por una red IP privada.

– Dar a los funcionarios, buzón de voz, integrándolo con una “web” y sus e-mail.

– Construir aplicaciones de respuesta automática por voz, que puede conectarlo a un sistema de pedidos, por ejemplo, o a otras aplicaciones internas.

– Dar acceso al PBX de la compañía para usuarios que viajan, conectando sobre la red privada virtual (VPN) de un aeropuerto o un hotel.

Incluye muchos recursos que solo eran encontrados en sistemas de mensajería unificada como:

– Música en espera para clientes en filas de espera, soportando streaming de media así como música en MP3.

– Filas de llamadas donde agentes de forma conjunta atienden las llamadas y monitorean dicha fila.

– Integración para la sintetización de la conversación (text-to-speech).

– Registro detallado de llamadas (call-detail-records) para integración con sistemas de tarificación.

– Integración con reconocimiento de voz.

– La habilidad de interfaces con líneas telefónicas normales.

1.2.2.2. Funcionalidades Avanzadas de Asterisk.

– IVR: Interactive Voice Response, gestión de llamadas con menús interactivos.

– LCR: Least Cost Routing, encaminamiento de llamadas por el proveedor VoIP

más económico.

– AGI: Asterisk Gateway Interface, integración con todo tipo de aplicaciones externas.

– AMI: Asterisk Management Interface, gestión y control remoto de Asterisk.

1.2.2.3. Aspectos Generales

Asterisk es un demonio (¿daemon=demonio?) que se ejecuta en segundo plano. Al igual que el resto de servidores conocidos (apache, openssh, proftpd,).

La configuración normalmente se almacena en varios ficheros de texto editables de forma tradicional.

Se distribuye como código fuente para ser compilado e instalado. Aunque existen versiones 'paquetizadas' para las distribuciones GNU/Linux más comunes.

1.2.2.4. Reducción Extrema de Costos

Normalmente los sistemas de PBX digitales tienen costos elevados y para agregar recursos avanzados como voz sobre IP, Buzón de mensajes, unidad de respuesta audible (URA), distribución automáticas de llamadas (DAC), etc, estos componentes son hechos de forma separada y muchas veces de diferentes fabricantes, los costos de adquisición de cada uno de estos componentes son elevados y la integración muchas veces es difícil. Asterisk solo puede ser comparado con PBX digital, y se puede agregar recursos avanzados con una gran facilidad (Flavio E 2007).

1.2.2.5. Limitaciones de la Arquitectura Asterisk

1.2.2.6. Requisitos Técnicos del sistema

Dependen directamente de:

– Llamadas concurrentes.

– Conferencias y Aplicaciones complejas simultáneas.

– Transcodifcaciones necesarias (recodificación).

Principalmente, Asterisk requiere microprocesador.

Según Digium Ink (2007): Equipo Dual Intel Xeon 1.8 Ghz 1 Gb Ram soporta 60 llamadas concurrentes codificando con el codec G.729.

Es difícil determinar con exactitud, y es mejor apuntar alto para poder escalar.

1.2.2.7. Arquitectura Base de Asterisk

La (Figura 1-6) nos muestra la arquitectura básica de Asterisk. Para lo cual necesitaremos explicar los conceptos relacionados con este esquema como los canales, codecs, y las aplicaciones entre otros.

Canal: Es una conexión que conduce una llamada entrante o saliente en el sistema Asterisk. La conexión puede venir o salir hacia telefonía tradicional analógica o digital o VozIP (Figura 1-7).

Figura 1-7. Concepto de canal [4]

Por defecto, Asterisk soporta una serie de canales, los más importantes:

– H.323, IAX2, SIP, MGCP: Protocolos VozIP

– Console: GNU Linux OSS/ALSA sound system.

– Zap: Líneas analógicas y digitales.

Codecs y conversores de Codecs: Se utiliza para codificar de forma que se emplee el menor ancho de banda permitiendo colocar muchas llamadas como sea posible en una red de datos. Algunos Codecs como el G.729 permite codificar a 8 kilobites por segundo, una compresión de 8 para 1. Otros ejemplos son ULAW, ALAW, G.711, GMS, SPEEX.

tono y tiempo de campanilla, identificador de llamadas, desconexión, etc. Hoy es común el uso del SIP ( Session Initiated Protocol), y otros protocolos también muy en auge en el mercado como lo es el H.323, ZAPATA, MGCP, y el más reciente el IAX que es excepcional cuando se trata de Trunking y Nat (Network Address Traslation).

Dialplan: Se trata de la configuración de la centralita Asterisk que indica el itinerario que sigue una llamada desde que entra o sale del sistema hasta que llega a su punto final. Se trata en líneas generales del comportamiento lógico de la centralita.

Extension: En telefonía tradicional, las extensiones se asocian con teléfonos, interfaces o menús. En Asterisk, una extensión es una lista de comandos a ejecutar.

Las extensiones se acceden cuando:

– Se recibe una llamada entrante por un canal dado.

– El usuario que ha llamado marca la extensión.

– Se ejecuta un salto de extensiones desde el Dialplan de Asterisk.

Contexto (Context): El Dialplan o lógica de comportamiento de Asterisk se divide en uno o varios contextos. Un contexto es una colección de extensiones.

Los contextos existen para poder diferenciar el 'lugar' donde se encuentra una llamada, para:

– Aplicar políticas de seguridad: Asterisk no se comporta igual cuando llama un usuario y marca el 1 y cuando un usuario local marca el mismo 1.

– Menús y submenús diferenciados.

– En general, es una forma de diferenciación.

– Hangup: Colgar la llamada.

– Monitor: Comenzar la grabación a disco de la llamada.

– Dial: Realiza una llamada saliente.

– Goto: Salta a otra extensión o contexto.

– PlayBack: Reproduce un fichero de sonido.

1.2.3. IVR

IVR son las siglas de Interactive Voice Response, que se traduce del inglés como

Respuesta de Voz Interactiva. También se utiliza el término VRU (Voice Response Unit).

Consiste en un sistema telefónico que es capaz de recibir una llamada e interactuar con el humano a través de grabaciones de voz. Es un sistema de respuesta interactiva, orientado a entregar y/o capturar información automatizada a través del teléfono permitiendo el acceso a los servicios de información y operaciones autorizadas, las 24 horas del día.

1.2.3.1. Servicios

El IVR es la típica máquina que nos responde con una voz grabada cuando llamamos a una central o que nos recibe en la banca telefónica. Según las opciones que el usuario le ingresa lo deriva a un centro de atención telefónica o a otra central telefónica.

Las empresas suelen usar la tecnología de IVR para enrutar una llamada entrante hacía un departamento u otro, sin la necesidad de intervención humana, así reduciendo el tiempo de espera de sus clientes.

Puede combinarse con servicios de mensajes cortos (SMS) para prestar cualquier clase de servicio: tele votación, encuestas, sorteos, acceso a bases de datos, servicios informativos, etc.

El usuario realiza una llamada a un número de teléfono, el sistema de audiorespuesta contesta la llamada y le presenta al usuario una serie de acciones a realizar, esto se hace mediante mensajes (menús de opciones) previamente grabados en ficheros de audio (Por ejemplo "Pulse uno para ventas, dos para administración"). El usuario elige la opción a realizar introduciendo un número en el teclado del teléfono y navega por los diferentes menús hasta encontrar la información solicitada o que el sistema enruta la llamada al destinatario elegido.

1.2.3.2. Tecnología Involucrada

El IVR para brindar mejores servicios involucra otras tecnologías como:

DTMF (Dual Tone Multi Frequency): Propia de la telefonía, es la tecnología de tonos utilizada para el marcado.

TTS (Text To Speech): Iniciada en la informática, le da capacidad de transformar texto a audio que escucha el operador.

Capítulo 2.

Introducción

De acuerdo a la Norma de calidad del servicio de valor agregado de internet expedida mediante RESOLUCIÓN 534-22-CONATEL-2006, el ente regulatorio de nuestro país es decir la superintendencia de telecomunicaciones solicita se provea un servicio de soporte técnico las 24 horas del día durante los 365 días del año, en este sentido una solución automatizada va a permitir una importante reducción de costos e incrementar los niveles de satisfacción del cliente.

Un proveedor de internet requiere proveer de un soporte técnico de calidad, muchas de las veces es difícil encontrar técnicos de soporte calificados que sepan diagnosticar en forma expedita los problemas que un cliente puede tener, la curva de aprendizaje suele ser medianamente larga, y síntomas obvios muchas de las veces son pasados por alto.

Para la resolución de cada problema el técnico de soporte sigue una rutina preestablecida y con pasos predefinidos, entonces cada problema se puede clasificar y luego de ello seguir un procedimiento rutinario de solución, por este motivo, sí es factible una solución automatizada que pueda trabajar en forma independiente o en conjunto con los técnicos de soporte. De hecho una solución inteligente podría en promedio encontrar el problema mucho más rápido que cualquier técnico con mediana experiencia.

Los autores del presente proyecto no hemos encontrado implementaciones de soporte técnico en forma totalmente autónoma; es decir que un software ejecutándose en un ordenador pueda encontrar la posible avería y pueda sugerirle la solución al cliente. No obstante el presente estudio va a ser el punto de partida para otros trabajos que pretendan automatizar problemas de soporte técnico en línea y que puedan ser resueltos por la lógica de un ordenador.

no tienen los recursos económicos como para costear un staff de técnicos las 24 horas del día durante los 365 días del año.

A demás puede ser un referente para futuros estudios de reingeniería en la automatización de servicios de soporte técnico para empresas de un tamaño similar o mayor al propuesto, tomando en cuenta los servicios que se pueden implementar hoy en día en una red convergente. Los equipos y servicios que se propone se ajustan a la realidad del país. Puesto que se comercializan en el Ecuador.

2.1. ANÁLISIS DE LOS PROBLEMAS MÁS COMUNES EN EL

ÁREA DE HELP DESK DE UN ISP INALÁMBRICO

Evidentemente el hecho de que un usuario tenga un problema técnico, significa una pérdida tanto para el cliente que no puede realizar su actividad o tarea a tiempo como para el proveedor de Internet que ve disminuida su imagen como empresa y posiblemente tenga que descontar por un servicio que no fue provisto adecuadamente.

Se ha realizado a cabo una investigación para determinar los problemas más comunes por los que el cliente llama al departamento de servicio técnico de los proveedores de internet inalámbrico.

Esta información permitirá más adelante determinar que problemas serían posibles de detectar y solucionar utilizando la lógica de un computador y cuáles serían simplemente registrados para que un técnico en el tiempo más corto posible pueda contactar al cliente o visitarle para diagnosticar la falla.

atienden los proveedores de Internet inalámbrico se contactó a varios de ellos; tanto de la ciudad de Loja como de Machala y se les solicitó que llenaran una encuesta, con lo cual se obtuvo la tabla de los problemas de soporte más comunes de un ISP inalámbrico como figura en el apéndice Nº 2. El modelo de la encuesta consta en el apéndice Nº 1.

La estrategia que utilizan los técnicos para resolver un problema de soporte es básicamente enviar paquetes de solicitud de eco ICMP1 _{o ping tanto al enlace}

inalámbrico de radio como a la computadora o servidor del cliente, con ello se obtiene el porcentaje de paquetes perdidos y la latencia o tiempo de respuesta del enlace. Por ejemplo en un supuesto que tanto el radio como el computador del cliente no responden; lo más probable es que el radio está apagado o inhibido y lo que el técnico recomendaría sería que se revise si el equipo está encendido o que lo reinicie en el caso de que estuviera inhibido. Ahora, en el caso que el equipo inalámbrico tuviera un 10% de paquetes perdidos, allí habría un problema del enlace de radio y un técnico debería realizar una visita donde el cliente; pero al contrario, si el radio NO tiene paquetes perdidos, y el computador o el servidor SI, en ese caso habría una saturación de su ancho de banda y el cliente está consumiendo toda su capacidad contratada.

Un caso especial se presenta cuando el radio responde y el equipo no responde pero si tiene una dirección MAC2 en la tabla ARP3, este se da cuando la computadora o el servidor del cliente tiene bloqueado el protocolo ICMP y las peticiones ping no tienen respuesta; esto generalmente debido a un firewall instalado. En este caso con lo único que se cuenta para hacerse una idea del problema es con la latencia del radio y con el porcentaje de paquetes perdidos, puesto que solamente se conoce que el computador del cliente está conectado.

En relación con la calidad del servicio es necesario acotar que es un tema bastante subjetivo puesto que lo que un usuario puede percibir como una navegación rápida,

otro usuario podría pensar que es sumamente lento, en otras ocasiones la computadora podría estar descargando una actualización del sistema operativo o de algún programa antivirus y el usuario experimenta una degradación de la velocidad.

También podría darse el caso que la computadora tenga algún software espía o virus que empieza a enviar en forma masiva información desde la computadora del cliente, en este sentido seria un tanto difícil para un software discriminar tráfico normal de tráfico malicioso.

También hay que tomar en consideración que a muchas personas les pueda incomodar

que una “maquina” detrás de la línea les ayude con un problema que se les presenta.

2.2. SOLUCIÓN PROPUESTA

inicio

usuario. Existe?

Revisión de radio y computador cliente

Mientras se realiza el test, el cliente permanece

escuchando un mensaje si

Calcular latencia y % de paquetes perdidos del radio y del PC

0 al 2 % Paquetes

perdidos en el PC

? Se informa al cliente que

su enlace es NORMAL

100% Paquetes perdidos en el PC si no no Fin PC no tiene MAC en

tabla ARP ?

no

Informar “equipo no responde a peticiones

ping”

si

Paquetes perdidos radio <

100%

Informar “radio responde pero equipo no

responde” si

no

Informarle al cliente estado del enlace de

radio (Latencia

radio < 3 ) y (Latencia_equipo -latencia_radio > 3) Informar “El cliente

esta congestionado” si

no si

no

Cliente realiza llamada de Soporte

Técnico e ingresa codigo

Figura 2-1. Diagrama de flujo de datos para la resolución de un problema de soporte técnico.

porcentaje de paquetes perdidos tanto del radio como del computador o servidor del cliente, luego procesar esa información e inmediatamente informarle al usuario la posible solución a su problema de acuerdo a la (Figura 2-1).

Para implementar el sistema de soporte técnico automatizado se deberá integrar el algoritmo descrito en la (Figura 3-1) con el servidor de VOIP. Esto se lo hace mediante el desarrollo de una interfaz AGI que ejecutará en forma remota el respectivo monitoreo dentro del servidor que provee de Internet a los clientes. Cuando se habla de un servidor que provee de Internet a los clientes, debe de entenderse como un Proxy o un equipo que haga traducción automática de direcciones NAT.

Inicio llamada telefonica Cliente necesita soporte automatizado

Servidor de VOIP solicita codigo de usuario y transfiere control a interfaz AGI

si Cliente realiza llamada y esta es

contestada por servidor de VOIP

Interfaz AGI se introduce en servidor

proxy¹, realiza monitoreo y provee

soporte al cliente Llamada es

contestada de acuerdo a plan de

discado

Fin llamada telefonica no

Se almacena en bitacora resultados de soporte para

efectos de control

Figura 2-2. Diagrama de flujo de datos para integrar el Servicio técnico automatizado de un servidor VOIP1

Capítulo 3.

Implementación y Pruebas del Sistema

3.1. IMPLEMENTACIÓN

La fase de implementación consta de las siguientes partes:

1. Instalar el sistema operativo Linux en el futuro servidor de VOIP.

2. Instalar Asterix: colocar y compilar las fuentes en el servidor de VOIP, Modificar los archivos de configuración del Asterix con el objeto de implementar el plan de discado y copiar script AGI.

3. Implementar acceso de consola segura sin contraseña hacia el servidor IPCOP.

4. Instalar script de monitoreo en el servidor IPCOP.

Para la implementación del servidor de VOIP se ha escogido trabajar en el sistema operativo GNU/Linux - Distribución Debian, puesto que este ambiente es Open Source, tiene muchas ventajas en relación al software privativo entre ellas documentación abundante, disponibilidad de código fuente, una comunidad de desarrollo madura y consolidada y sobre todo el coste económico sumamente reducido.

En relación con el servidor de VOIP Asterix es necesario recalcar que si bien es cierto existen distribuciones muy sencillas de utilizar y que se instalan en cuestión de minutos tales como elastix y asterisknow, estas solamente son recomendables cuando se van a utilizar las funciones básicas de un PBX, más no cuando se piensa trabajar directamente sobre el dialplan y con interfaces AGIs.

inalámbricos pequeños cuando inician operaciones. No se ahondará en detalles de instalación del servidor IPCOP, puesto que no es materia del presente trabajo de investigación, se asumirá que está habilitado el servicio SSH y que está configurado correctamente para proveer servicio de internet a un grupo de usuarios. Para fines de este proyecto se ha configurado el servidor IPCOP con las interfaces GREEN, RED y BLUE.

3.1.1. Instalación de Linux Debian

Esto se discutirá en el manual de instalación de Linux-Debian adjunto; se utilizará Debian con kernel 2.6 para la instalación de asterisk con linux. Se ha escogido esta distribución por la gran aceptación que tiene. Se recomienda usar el kernel mencionado previamente puesto que hay mayor soporte para hardware de telefonía sobre esta versión.

3.1.2. Instalación y Configuración del Asterisk

Igualmente para la instalación de asterix se deberá referir al manual de instalación adjunto, de todas maneras la instalación de asterisk en un sistema GNU/Linux sigue los siguientes pasos:

– Instalación de paquetes y librerías dependientes.

– Descarga del código fuente de asterisk.

– Compilación de asterisk.

– Instalación en el sistema y copia de archivos de configuración de ejemplo.

– Creación del plan de discado y de voces personalizadas.

3.1.2.1. Plan de discado

como asterisk irá gestionando las llamadas. Este consiste en una lista de instrucciones o pasos que asterisk debería seguir, las mismas que son activadas a partir de los dígitos recibidos de un canal o aplicación.

La mayor parte del plan de discado está contenida en el archivo “extensions.conf” que está en el directorio “/etc/asterix”.

Adicionalmente los archivos de sonido que se utilizan en el plan de discado deben ser copiados en el directorio respectivo.

3.1.2.2. Instalación de un Softphone para las pruebas del IVR.

Softphone es un software que hace una simulación de teléfono convencional por computadora. Es decir, permite usar la computadora para hacer llamadas a otros softphones o a otros teléfonos convencionales. Para estas pruebas se utilizará el softphone XLITE que es gratuito, el cual se lo ha descargado de la web en una computadora portátil con Windows XP.

En el menú “ opcion system settings “ se deberá colocar la dirección IP del servidor de VOIP junto con el nombre de usuario y contraseña asignado. Luego se deberá verificar en la consola del Asterix que se registre el Xlite, y que todo está listo para las pruebas, adicionalmente se puede conectar un ATA con un teléfono convencional o un teléfono IP los cuales se configuraran como otras extensiones ejemplo (ext101, ext102, ..etc).

3.1.3. Implementar acceso a consola SSH sin contraseña

SSH1 _{es el nombre de un protocolo y del programa que lo implementa, y sirve para}

computadora mediante un intérprete de comandos. Además de la conexión a otras máquinas, SSH nos permite copiar datos de forma segura, gestionar claves RSA1 _para

no escribir claves al conectar a las máquinas y pasar los datos de cualquier otra aplicación por un canal seguro tunelizado mediante SSH.

Puesto que el servidor de VOIP necesita acceso al equipo que entrega el internet, se necesita acceder al mismo mediante una consola segura pero sin contraseña. Se puede solucionar este problema haciendo que un equipo confíe en el otro.

Lo primero, en la máquina cliente, es decir el servidor de voip que tendrá acceso al servidor Proxy se deberá generar una clave RSA pública local que posteriormente se exporta al ordenador remoto usando el comando Linux: ssh-keygen

TesisVoIP:~# ssh-keygen -t rsa

La ejecución de este comando presenta lo siguiente en la pantalla:

Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is:

8b:44:6b:d0:0d:8e:cb:78:f0:12:60:df:52:16:ac:ab [email protected]

La “passphrase” se la deja en blanco, el objetivo es poder ingresar mediante consola

segura SSH sin digitar la contraseña.

Una vez hecho esto, se genera el archivo “~/.ssh/id_rsa.pub” el cual se debe copiar en forma segura al servidor al cual se desee tener acceso sin contraseña:

scp ~/.ssh/id_rsa.pub 192.168.0.254:~/.ssh/authorized_keys2

De esta manera el servidor o servidores que proveen servicio al servidor de VOIP ya no pedirán contraseña cada vez que se necesite realizar un monitoreo.

3.1.4. Instalar script de monitoreo en el servidor IPCOP

Este es un procedimiento bastante trivial como copiar mediante un software de consola segura tal como winscp en el caso de windows o scp en el caso de linux y colocarlo en la carpeta “/usr/local/sbin”

3.2. DETALLES DE IMPLEMENTACIÓN

3.2.1. Arquitectura del Sistema de Soporte Automático

Este sistema fue diseñado en base a dos capas o niveles de abstracción en donde la capa superior no necesita conocer detalles específicos de implementación del nivel inferior tal como se muestra en el (Figura 3-1).

SERVIDOR INTERNET SERVIDOR VOIP

Asterisk

Tescli.agi

probarcliente

comprueba

(

REINICIA SERVICIOS ENVIA ALERTAS POR

SMS O EMAIL USUARIO REALIZA LLAMADA SOPORTE

PROTOCOLO SSH

A). NIVEL 1.- Servidor VOIP

Esta es la capa de abstracción superior y con la cual interactúan los usuarios vía telefónica, consta del servidor de código abierto asterisk y la interfaz AGI “testcli”. En este nivel se procesan las llamadas telefónicas de los clientes y en caso de requerir soporte automático se realiza una llamada hacia un módulo de software localizado en el servidor de internet de los clientes. Este nivel no conoce detalles de implementación ni formas de acceso a la información de los clientes, solo hace una llamada especificando el servidor y el código del usuario. Consta a su vez de dos módulos:

Servidor Asterisk.- Hace las veces de centralita telefónica y realiza llamadas a la interfaz AGI “testcli” cuando el usuario necesita soporte automatizado.

Interfaz testcli.agi.- Esta es una interfaz AGI, la misma que mediante el protocolo ssh ejecuta remotamente el script “probarcliente” que reside dentro del servidor que provee servicio de internet a los clientes. Los parámetros que envía son la dirección IP del servidor y el código del cliente.

B). NIVEL 0 .- Servidor de internet de los clientes

Esta parte consta de dos módulos.

Script probarcliente

Este provee funciones de monitoreo a los clientes y les sugiere una posible solución. Este código que reside en el servidor que provee servicio a los clientes recibe como parámetro el código que provee el usuario,

Script comprueba

Este módulo provee funciones de monitoreo y auto reparación a los servicios y funciones del servidor y realiza una comprobación periódica de los servicios corriendo sobre el mismo tales como: dns, smtp, pop3, Proxy, etc, y en caso de que haya un servicio inhabilitado o que funcione en forma incorrecta trata de solucionar el problema y notifica al administrador vía email o mensaje de texto.

3.2.2. INTEGRACION DEL SISTEMA

El sistema será utilizado por tres entidades: los clientes que requieren soporte automático, el personal del área de soporte y el servidor que será monitoreado por el sistema.

Clientes.

El cliente solicita soporte automático.

El servidor de VOIP hace una llamada al interfaz AGI “testcli”.

“probarcliente” realiza las respectivas pruebas y envía información al usuario mediante el protocolo de comunicaciones AGI.

Cuando el script termina, el servidor de VOIP continúa ejecutando el plan de marcado.

Personal del área de soporte

El Administrador necesita ejecutar alguna instrucción en algún servidor del ISP. El servidor de VOIP hace una llamada al AGI “testcli”.

“testcli” mediante SSH ejecuta la instrucción solicitada en el servidor solicitado.

Servidor

El script de auto-monitoreo “comprueba”, detecta un servicio inhabilitado o que funciona en forma incorrecta.

Si es una falla que se puede corregir, el script trata de hacerlo y notifica mediante un correo electrónico y/o un mensaje de texto al administrador.

3.3. PRUEBAS DEL SISTEMA

Figura 3-2. Hardware utilizado con el fin de realizar pruebas del sistema

Intencionalmente se desconectó el cable de red del bridge inalámbrico conectado a la computadora y el sistema informó que posiblemente el cable de red estaría desconectado.

Se apagó deliberadamente el bridge inalámbrico relacionado con un usuario y se procedió a monitorearlo, en este caso el sistema siempre informó: “el equipo

inalámbrico no responde, posiblemente porque este trabado o porque este sin energía eléctrica, le recomendamos desconectar brevemente el adaptador de

corriente y verificar que este con energía”.

Se deshabilitó la respuesta a paquetes de solicitud de eco ICMP o ping en las computadoras de prueba y el sistema pudo determinar que el equipo inalámbrico si estaba encendido pero no podía determinar la latencia hacia el computador; este comportamiento es normal puesto que un técnico tampoco podría determinar el tiempo de respuesta hacia un cliente inalámbrico, si las peticiones ping están deshabilitadas.

Posteriormente se asignaron códigos a ciertos usuarios en la empresa Lojasystem con el fin de evaluar la efectividad del sistema.

Como fase final de las pruebas se lo implemento en la empresa Lojasystem y se lo monitoreo al sistema durante un periodo de 4 meses, durante este periodo se hicieron los correctivos necesarios al sistema, así mismo se monitorio el registro o bitácora de los problemas que se fueron presentando, para sacar estadísticas y resultados.

3.3.1. Escalabilidad

Durante las pruebas que se realizó, los recursos del sistema estuvieron bastante holgados, este sistema es lo suficientemente escalable como para manejar algunos cientos de llamadas simultáneas; puesto que el código para diagnosticar un problema consume muy pocos ciclos del procesador y se utiliza el mismo códec en todas las llamadas entrantes, es decir no se requiere transcoding. De todas formas cuando el sistema escale a algunas decenas de llamadas simultáneas sería recomendable colocar el sistema en un equipo más poderoso: por ejemplo un computador Pentium 4 o superior con 512 MB de memoria RAM o más.

3.4. RESULTADOS OBTENIDOS

Como antecedentes se tiene que en la empresa donde fue implantado el sistema para las

pruebas “Lojasystem”, el soporte técnico brindado a sus clientes cubría el horario de

La pérdida de recursos humanos era inevitable debido a que muchos de los técnicos les incomodaba responder llamadas a cualquier hora de la noche y muchas de las veces llamadas más tarde de las doce de la noche no eran contestadas y si respondían lo hacían de mala gana puesto que interrumpían su descanso. Esta situación ocasionaba insatisfacción tanto en los clientes como el personal de soporte de la compañía. Inclusive algunos clientes habían suspendido su contrato puesto que no habían recibido soporte técnico en forma oportuna.

En este contexto el software de monitoreo y auto reparación de los servicios del servidor resultó sumamente oportuno y ya no se presentaron llamadas por causa de un servidor trabajando incorrectamente puesto que éste sin la intervención de ningún técnico reinicia servicios que no están trabajando correctamente y alerta en forma sonora cuando ello sucede; si esto no fuera suficiente se podría reiniciar remotamente el servidor mediante una llamada desde un teléfono fijo o móvil. Cabe destacar que nunca se ha hecho necesario reiniciar remotamente el servidor puesto que el software realiza su función en forma bastante eficiente.

De acuerdo a los registros en bitácora, a nivel de servidor el sistema resuelve mensualmente en promedio 5 problemas relacionados con la provisión del servicio a todos los clientes y que necesitarían de la intervención de un técnico para solucionarlo, los más comunes son relacionados con el servicio squid que es el encargado de realizar el cacheo de las paginas y con el servicio dnsmasq que es el modulo encargado de la resolución de los nombre de dominio. De todos los casos presentados el sistema ha resuelto el 100%, exceptuando aquellos casos en donde no esté a su alcance la solución de un problema como por ejemplo si hay una defectuosa provisión del Internet por parte del proveedor; en este caso lo único que hace es registrar en bitácora el incidente y emitir una alerta.

encuesta de la tabla 3-1 tiene una exactitud del 81% para diagnosticar los problemas.

En la empresa que fue implementado el sistema, éste empezó a ser utilizado en una fase progresiva, es decir se les entregó códigos de monitoreo solamente a ciertos usuarios; en su mayoría corporativos y a unos pocos clientes residenciales. La idea fue ir evaluando el nivel de satisfacción de los clientes para poder hacer cambios o mejoras.

Los directivos de la compañía no han creído pertinente que el sistema responda llamadas de soporte en horas laborables sino mas bien en horas fuera de oficina.

Si bien es cierto el sistema todavía no ha sido implantado en un ciento por ciento se puede decir que:

• Se cumplió con el requerimiento de las autoridades regulatorias de proveer servicio técnico las 24 horas del día, los 365 días del año.

• Se redujo a 0% el número de llamadas relacionadas con fallas en el “servidor”

que provee Internet a los clientes.

• Se está cumpliendo con las expectativas de los clientes de poder proveerles un servicio técnico a cualquier día de la semana y a cualquier hora.

Tabla 3-1 Exactitud en el diagnostico desde el punto de vista del usuario1

PROBLEMA DIAGNOSTICADOS POR EL

SISTEMA OPINION DEL USUARIO

El sistema reporta que el equipo posiblemente está congelado o sin energía eléctrica

100%

El sistema no detecta ningún problema 43% 2

El sistema informa que hay problemas de calidad en el enlace

100%

El sistema reporta que el usuario posiblemente está consumiendo toda su capacidad

68%

Posiblemente cable de red desconectado 76%

El sistema reporta que el usuario está suspendido su servicio por falta de pago

100%

PROMEDIO

81%

Que el sistema diagnostique un problema no significa que el cliente esté de acuerdo con ese diagnóstico, esto se puede evidenciar en una forma más acentuada cuando el sistema le manifiesta al usuario que el problema no atañe a la empresa proveedora del servicio; por ejemplo un cliente corporativo experimentó congestión en la señal pero estuvo ocupando todo su ancho de banda disponible, entonces ese usuario supo manifestar que el sistema le estaba dando información sesgada a favor del proveedor de Internet.

Además se pudo determinar lo siguiente:

El sistema detecta un problema más rápidamente que un técnico de soporte, y siempre la información presentada es exacta, pero existen problemas que si requieren del conocimiento de un técnico especializado por ejemplo; sería muy difícil para un software determinar cuando un equipo inalámbrico ha perdido su

configuración y está con los valores de fábrica, de todas maneras son excepciones que las debería responder un técnico calificado en la siguiente jornada laborable de acuerdo al registro en bitácora de problemas no resueltos por el sistema.

Muchos posibles usuarios se mostraron renuentes a que un software interactivo intente proveerles una solución por lo que habría que tomar bastante atención a este punto cuando se desee implementar el sistema.

De acuerdo a la (Tabla 3-2), la mayor cantidad de llamadas se da por que el equipo inalámbrico del cliente se quedó congelado o detenido, puesto que el sistema le indicó al cliente que debería reiniciar este equipo la mayoría de veces este problema fue resuelto.

Tabla 3-2 Llamadas según el tipo de problema diagnosticado

TIPO DE PROBLEMA DIAGNOSTICADO PORCENTAGE

El sistema reporta que el equipo posiblemente está congelado o sin energía eléctrica

46%

El sistema no detecta ningún problema 15%

El sistema informa que hay problemas de calidad en el enlace

12%

El sistema reporta que el usuario posiblemente está consumiendo toda su capacidad

17%

Posiblemente cable de red desconectado 3%

El sistema reporta que el usuario está suspendido el servicio por falta de pago

6%

Otros 1%

Capítulo 4.

Conclusiones y Recomendaciones

4.1. CONCLUSIONES

Luego de haber desarrollado la presente investigación se concluye que el futuro de la telefonía será desarrollada sobre tecnología IP y basada principalmente sobre proyectos open source como Asterix; por ende un sistema de computación con recursos modestos podría correr soluciones bastante sofisticadas las mismas que en sistemas comerciales costarían decenas de miles de dólares. Eso significa trabajo para nuestros profesionales y que el dinero invertido en tecnologías de la información no salga de nuestro país.

En este contexto desarrollar aplicaciones que antes tenían costo de varios cientos de miles de dólares se vuelven económicas; por ejemplo un sistema de información electoral vía telefónica incluido hardware y costo de desarrolladores estaría por alrededor de USD 8.000.1

Esto demuestra que en este universo globalizado el activo más valioso llega a ser el conocimiento.

En relación con el objetivo del presente proyecto se podría decir que este sistema pudo solucionar un problema que es el hecho de proveer soporte en horas no laborables y días feriados, reduciendo con ello costos operativos e incrementando la satisfacción de los clientes que saben que en cualquier día y hora del año pueden tener soporte de la empresa proveedora de internet.

Además este trabajo puede ser el punto de partida para dar solución a otras aplicaciones comerciales que requieren del acceso a una base de datos y de una persona que entregue una información en forma telefónica por ejemplo; autorizaciones de tarjeta de crédito, información de servicios básicos como agua, luz o teléfono, etc.

4.2. RECOMENDACIONES

Como Recomendaciones para la escuela se podría sugerir lo siguiente:

Incentivar en la UTPL el desarrollo de proyectos de investigación de voz sobre el protocolo IP bajo plataformas de código abierto.

Como recomendaciones para los ISPs inalámbricos se podría recomendarles lo siguiente:

Incrementar la calidad de los suscriptores utilizados por cada cliente.

Capitulo 5

Bibliografía

Netkrom Tecnologies (2005), Soluciones Wireless ISP, [web en línea]. Disponible desde internet en: <http://www.netkrom.com/es/sol_wisp.html> [con acceso el 6-10-2008]. [1]

Román S. Francisco (2008) Reingeniería de la intranet de la empresa Tecnomega C.A., Tesis de Ingeniería y Redes de Información, Escuela Politécnica Nacional, Quito, Ecuador. [2]

Michael K. Johnson (1996), Linux Information Sheet, Características de Linux, [web en línea]. Disponible desde internet en: <http://www.grulic.org.ar/comos/info-sheet/InfoSheet-Como-2.html> [con acceso el 12-10-2008]. [3]

Gorka Gorrotxategui-Iñaki Baz, (2006) Curso Voz sobre IP y Asterisk v1.0 Modulo III, Bilbao, España. IRONTEC. [4]

Colaboradores de Wikipedia. IPCop (2009) Wikipedia, La enciclopedia libre [web en

línea]. Disponible desde internet en:

<http://es.wikipedia.org/w/index.php?title=IPCop&oldid=24480566> [con acceso el 12-02-2009]. [5]

Francisco Omil. (2003) Manual de estilo en la redacción de tesis/dea, [web en línea]. Disponible desde internet en: <http://www.usc.es/biogrup/manestilodea.htm> [con acceso el 1-10-2008].

Daniel L. Morrill. (2002) Configuración de sistemas Linux. Ed. Anaya Multimedia, ISBN: 84-415-1465-8

Dee-Ann Leblanc, (2001) La Biblia de Administración de sistemas Linux. col. La Biblia de, Ed. Anaya Multimedia, , ISBN: 84-415-1126-8.

Matt Welsh, Matthias Kalle Dalheimer y Lar Kaufman (2000) Linux. Guía de referencia y aprendizaje., col. O'Reilly, Ed. Anaya Multimedia, , ISBN: 84-415-1071-7.

Jim Van Meggelen, Jared Smith, and Leif Madsen, (2005) Asterisk: The Future of Telephony. Media lnc.,O'Reilly CA, USA.

Flavio E. Goncalves, (2007), Asterisk PBX, Guía de la configuración, florianópolis, tercera edición.Janeiro, Brasil.

VOIP WIKI, (2008) a reference guide to all things VOIP, PBX and Servers -VOIP PBX and Servers [web en línea]. Disponible desde internet en: <http://www.voip-info.org/>. [con acceso el 15-08-2008]

Digium Inc, (2007) Asterisk: An Open Source PBX and telephony toolkit [web en línea]. Disponible desde internet en: <http://www.asterisk.org> [con acceso el 05-09-2008]

Digium lnc, (2007) Asterisk Guru, Tutorials and howto's for the asterisk PBX and voip in general, [web en línea]. Disponible desde internet en: <http://www.asteriskguru.com/> [con acceso el 10-09-2008]

Stopford, Andrew. (2002) Proyectos profesionales: con PHP, Anaya Multimedia-Anaya Interactiva,. ISBN: 84-415- 1418-6