MENSAJERÍA INSTANTÁNEA

Transcripción

1

2 Capítulo 19 Protocolo XMPP MENSAJERÍA INSTANTÁNEA XMPP o Extensible Messaging and Presence Protocol, por sus siglas en inglés, es un protocolo extensible y abierto basado en el estándar XML. Es ampliamente utilizado para el intercambio en tiempo real de mensajes y presencia entre dos puntos en Internet. Existe una gran red de servidores XMPP interconectados entre sí, y a la vez independientes unos de otros. Usuarios de distintos servidores conectados a la red Jabber pueden hablar entre ellos sin ningún problema, ya que cada usuario está conectado a su servidor, y los servidores de estos usuarios se intercambian los mensajes. XMPP es el protocolo seleccionado por Facebook para su chat y por Google para GoogleTalk. Al nivel más básico, si dos contactos tienen cuentas creadas en el mismo servidor XMPP, podrán hablar entre ellos. Características de XMPP Es abierto: El protocolo de XMPP es gratuito, abierto, público y comprensible. Existen múltiples implementaciones de código abierto para Servidores XMPP, asi como numerosos clientes y librerías de desarrollo. 1

3 Capítulo 19 Es extensible: Usando el potencial del lenguaje XML, cualquiera puede extender el protocolo de XMPP para una funcionalidad personalizada. Es seguro: Cualquier servidor XMPP puede ser aislado de la red pública Jabber. Cualquier implementación del servidor usa SSL para las comunicaciones clienteservidor y numerosos clientes soportan PGP-GPG para encriptar las comunicaciones de cliente a cliente. Es descentralizado: Cualquiera puede montar su propio servidor XMPP, además está libre de patentes y no depende de ninguna empresa de modo que se puede usar siempre con total libertad. Para mantener la interoperabilidad, las extensiones comunes son controladas por la XMMP Standards Foundation. Clientes XMPP Spark: Integrado con el servidor OpenFire y pensado para empresas. Escrito en Java. Libre, gratuito. (Windows, Linux, Mac). Jabbin: Cliente libre desarrollado a partir de Psi (Windows, Linux) No se sigue desarrollando. Bitlbee: Es una pasarela IRC-IM que permite conectar a varios protocolos usando un cliente IRC. Pidgin: (Windows y Linux) soporta además protocolos para msn y yahoo. ichat: cliente incluido en OSX (Mac) Openfire en Elastix Openfire es un sistema de mensajería instantánea de código abierto que permite habilitar servicio de mensajería instantánea interna. Es el servicio de IM utilizado por Elastix por sus características que permiten transferencia de archivos, transmisión de mensajes (broadcast), integración con telefonía, integración con otros gateways, y por supuesto IM. Está escrito en Java y su funcionalidad puede ser extendida con plugins. Openfire viene desactivado por defecto en Elastix. Para instalar Openfire ir al menú IM y luego hacer clic en click aquí. 2

4 Capítulo 19 El primer paso consiste en seleccionar el idioma Se debe especificar el dominio del sistema, el cuál ya debe estar configurado (Es el mismo dominio del servidor Elastix). 3

5 Capítulo 19 Se debe especificar la configuración de la Base de Datos. Es conveniente elegir la base de datos embebida. En esta pantalla seleccionamos el lugar de datos donde se almacenarán los usuarios. En esta pantalla seleccionamos la contraseña del administrador. 4

6 Capítulo 19 Después del paso anterior culmina la instalación y podemos ingresar a la interfaz administrativa. Una vez en la interfaz administrativa podemos crear usuarios, configurar plugins y grupos. 5

7 Capítulo 19 Una vez que instalamos Openfire tendremos acceso a algunas de las siguientes características de este servicio: Funcionalidad expandible a través de plugins Posibilidad de integración con Asterisk Interacción con otras redes de mensajería instantánea como Gtalk, Yahoo Messenger, ICQ, entre otros Soporte para mensajes broadcast Transferencia de archivos Puede guardar histórico de conversaciones Soporte para clustering Permite crear diferentes grupos de trabajo 6

8 Capítulo 20 Sintetización de voz SINTETIZACIÓN Y RECONOCIMIENTO DE VOZ Es la tecnología que permite convertir el texto a audio. También se conoce como TTS debido al término Text-To-Speech (texto-a-habla en inglés). Actualmente ya existen alternativas de sintetización de voz de relativo bajo costo e inclusive de libre uso como Festival o FreeTTS. Festival es el motor de sintetización por defecto en Elastix. Es necesario activarlo. La técnica de sintetización de voz usada por Festival está dividida en en tres partes: Análisis de texto.- Normaliza el texto, lo traduce a un formato de palabras estándar. Análisis lingüístico.- Convierte el texto normalizado en fonemas. Generación de audio.- Traducción de fonemas a audio. El algoritmo por omisión usado por Festival para la traducción de fonemas a audios es RELP (Residual Excited Linear Prediction) Festival Festival es un sistema de sintetización de voz desarrollado por la Universidad de Edimburgo utilizando lenguaje de programación C++ Festival soporta Inglés Americano, Inglés Británico y Español. 7

9 Capítulo 20 Puede ser utilizado desde Asterisk. Festival puede trabajar como cliente y como servidor. Como cliente puede trabajar en dos modos: línea de comandos y tts (text-to-speech). Festival dentro del plan de marcado Asterisk provee una aplicación de plan de marcado llamada Festival. Esta aplicación funciona internamente conectándose a un servidor Festival a través de la red y reproduciendo la salida de audio en el canal en uso. La sintaxis de la aplicación Festival es la siguiente: text es el texto que se desea sintetizar (y reproducir) intkeys es un parámetro opcional que especifica las teclas telefónicas que pueden interrumpir la ejecución del comando. En este ejemplo si llamamos a la extensión 5333, escucharemos ese mensaje escrito. Festival en Elastix Con festival se puede sintetizar voz desde la interfaz Web de Elastix. Ir a PBX Tools Text to Wav. Se puede escribir un texto y generar un en formato wav o gsm. Esta funcionalidad podría servir para crear prompts de voz que podemos usar en el plan de marcado. 8

10 Capítulo 20 Reconocimiento de voz Es el proceso en el que un sistema computacional reconoce lo que un ser humano le dice. El término reconocimiento de voz es muchas veces utilizado para referirse al reconocimiento del habla, como en el caso del sistema telefónico. Una aplicación muy utilizada para sistemas telefónicos IP basados en Asterisk es LUMENVOX. Lumenvox Lumenvox aunque usa algunos de los fundamentos del reconocimiento de voz, es diferente ya que no trata de identificar a individuos. Más bien trata de identificar lo que éste dice. Para esto hace una comparación de las ondas del audio de una persona que llama, con los modelos acústicos de su base de datos. De ahí que sea común encontrarlo en aplicaciones donde una persona que llama completa una orden de voz; Ej: decir la extensión o el nombre de la persona a la que llamamos. Procedimiento Lumenvox El procedimiento completo sería el siguiente: Cargar una lista de palabras para ser reconocidas. El SRH (Sistema de Reconocimiento del Habla) carga el audio del altavoz. Este audio se representa como una forma de onda. El SRH compara la forma de onda con sus propios modelos acústicos (Las bases de datos que contienen información sobre las formas de onda de cada uno de los sonidos) El SRH comparan las palabras en la gramática a los resultados obtenidos a partir de su búsqueda de modelos acústicos. Determina qué palabras en la gramática de audio concuerdan y devuelve un resultado. 9

11 Capítulo 21 Desempeño de Elastix DESEMPEÑO & DIMENSIONAMIENTO El desempeño de un servidor Elastix es un asunto complejo de analizar. Existen muchos parámetros a tomar en cuenta principalmente el desempeño de Asterisk, ya que la comunicación de voz es en tiempo de real. En muchos casos interesa conocer los resultados y recomendaciones principalmente desde el punto de vista de una PBX. Factores que afectan el desempeño de Elastix Hay muchos factores que pueden afectar el desempeño de Elastix de alguna manera. Los más comunes relacionados con la operación de un servidor de comunicaciones unificadas son: Llamadas Concurrentes Transcoding Interrupciones de Hardware Numero de llamadas concurrentes El número de llamadas concurrentes afecta directamente el consumo de CPU del servidor. Es Muy Importante El gráfico siguiente tiene pruebas realizadas (sin transcoding) en un computador con un CPU de 2.2 GHz con 512 MB de RAM. Obviamente una prueba teórica siempre supone condiciones ideales, por lo cual el rendimiento debe ser tomado como referencia únicamente. En el computador se usó Elastix

12 Capítulo 21 CPU vs. Llamadas Concurrentes Uso de CPU Vemos que se han superado las 200 llamadas concurrentes con menos del 50% de CPU. Transcoding En ocasiones una llamada llega con un codec y el punto de destino final utiliza un codec distinto. Asterisk está en el medio por lo tanto tiene que hacer las veces de traductor para que los dos puntos se entiendan. A este proceso denominamos transcoding. El transcoding requiere de muchos cálculos matemáticos pues se está decodificando y codificando información con algoritmos complejos, consumiendo recursos a nivel de CPU. 11

13 Capítulo 21 Openfire Openfire es un software escrito en Java que proporciona el servicio de Mensajería Instantánea. Sin embargo, cabe señalar que consume una gran cantidad de memoria. Por lo tanto, si el servicio no es realmente necesario y se cuenta con un servidor limitado por recursos, es recomendado dejarlo apagado. Por omisión Openfire no activa al instalar Elastix. 12

14 Capítulo 21 Dimensionamiento telefónico Determinando el número de líneas telefónicas necesarias Primer parámetro en un proyecto telefónico nuevo: calcular número de líneas para satisfacer la demanda prevista. No se quiere tener más líneas de las necesarias, esto podría significar un desperdicio de recursos. Tampoco se debe sub dimensionar el número de líneas, ya que los usuarios podrían recibir continuamente tonos de ocupado. El cálculo, por lo tanto debe basarse en criterios técnicos y no ser tomado a la ligera. El modelo Erlang es una aproximación estadística para calcular cuántas líneas telefónicas necesitaremos en una instalación determinada para satisfacer una demanda prevista con cierta calidad. Agner Krarup Erlang Erlang, Ingeniero y matemático danés que desarrolló las técnicas de Ingeniería de Tráfico y Teoría de Colas. Exploraremos estos conceptos para darle al lector cierto conocimiento básico y práctico de estas técnicas sin llegar al rigor matemático que ellas demandan. Estas técnicas nos permitirán dimensionar cuántas líneas telefónicas necesitaremos en una instalación. La unidad Erlang Un Erlang es una unidad adimensional comúnmente utilizada para medir el tráfico telefónico por hora, o se puede decir que un Erlang representa la utilización continua de un circuito. 13

15 Capítulo 21 1 Erlang equivale a la utilización de un circuito continuamente durante una hora, en un lapso de una hora de tiempo o lo que es lo mismo que el circuito estuvo siempre en uso. Así mismo 0.5 Erlangs quiere decir que en el lapso de una hora el circuito se utilizó solo 30 minutos. Para calcular el tráfico en Erlangs se puede proceder de la siguiente manera: Encontrar el tráfico total en horas: Se suma el tiempo de todas las llamadas durante un lapso de tiempo cualquiera y se convierte este valor a horas Encontrar el tráfico por unidad de tiempo (en horas): Se divide el total anterior para el lapso de tiempo en horas Ejemplo En una empresa cualquiera entre las 9H00 y 12H00 de un día determinado se realizaron 300 llamadas, con un promedio de 6 minutos por llamada y se quiere medir el tráfico en Erlangs. Tráfico Total = Tráfico en 3 horas = 300 x 6 = 1800 minutos = 1800 minutos / 60 minutos = 30 horas (quiere decir que se hablaron 30 horas en ese lapso de tiempo) Tráfico por hora = Tráfico Total / Lapso de Tiempo = 30 horas / 3 horas = 10 Erlangs Hemos obtenido una medida de tráfico de 10 Erlangs. Modelos Erlang En esencia existen dos modelos en las teorías de Erlang que se utilizan mucho en telefonía: modelo B modelo C En la presente obra estudiaremos el modelo B pero recomendamos al lector recabar información del modelo C. Nota: El modelo C se utiliza para calcular probabilidades en llamadas que entran a colas así que si el lector está pensando en administrar un call center sería útil que indagara en el modelo Erlang C. 14

16 Capítulo 21 Erlang B El modelo Erlang B es el más común. Se usa determinar el número de líneas necesarias. Básicamente necesitamos alimentar a la fórmula con un par de parámetros y podemos obtener el número de líneas que necesitamos. Estos parámetros son: Tráfico punta o pico (el tráfico en la hora de mayor actividad) Grado de Servicio (o GOS por sus siglas en inglés). El Tráfico punta o pico se obtiene sumando todo el tráfico en la hora con más actividad telefónica. Es útil tomar muestras no solo de un día sino de algunos días o semanas para que la información sea más exacta. El Grado de Servicio representa la probabilidad de que una llamada sea rechazada. Su valor va de 0 a 1. Donde 1 significa el 100% de rechazo de llamadas. Grados de Servicios Comunes 15

17 Capítulo 21 Fórmula Modelo Erlang B Donde: E es el valor del tráfico punta o pico (en Erlangs) N es el número total de líneas telefónicas Como vemos, el valor de GoS no es sencillo de calcular. N, que es el valor que buscamos, tampoco es sencillo de despejar. Actualmente hay muchas herramientas en línea, algunas gratuitas, o aplicaciones para Smartphones que permiten calcular el modelo de Erlang B. La presentación de la fórmula ayuda a que el profesional de Elastix sepa los fundamentos del cálculo de la misma lo cual siempre es útil. Tomemos el cálculo que hicimos anteriormente: Tráfico Total = Tráfico en 3 horas = 300 x 6 = 1800 minutos Tráfico por hora = 10 Erlangs Cuántas líneas telefónicas necesito con un GoS de 0.01? Calcúlalo en: Flash Operator Panel En instalaciones con alta actividad telefónica el FOP puede comenzar a consumir recursos fuera de los niveles deseados. 16

18 Capítulo 21 En instalaciones con alta actividad telefónica el FOP puede comenzar a consumir recursos fuera de los niveles deseados. El FOP se comunica con Asterisk a través de AMI. Por lo tanto se encuentra escuchando toda la actividad telefónica a través del puerto de red que levanta Asterisk para este fin. Cuanto más actividad, más información tiene que procesar el FOP. En instalaciones grandes, en caso de que el uso del FOP no sea requerido es mejor apagarlo. Herramientas top Para hacer un análisis breve de los servicios que están consumiendo recursos, basta con ejecutar un comando top. Ordenamos su salida por consumo de memoria y también por consumo de CPU. Para hacer lo primero escribimos la letra M (Mayúscula) y para lo segundo la letra P. En algunas ocasiones podemos observar el proceso java liderando las estadísticas de consumo. 17

19 Capítulo 21 Normalmente esto tiene que ver con Openfire debido a que se encuentra implementado sobre java. sipp Sirve como generador tráfico SIP, ayudándonos a generar llamadas SIP hacia nuestro servidor Elastix. Esto nos permite tomar muestras para entender cómo reaccionan los recursos del sistema (CPU, memoria). La idea general es generar un volumen alto de llamadas y determinar el performance de nuestro equipo en varios escenarios. Sipp es una herramienta de código abierto. Información de descarga y documentación puede ser encontrada en: Cuando un solo servidor no alcanza Muchas veces una instalación es tan grande que rebasa la capacidad de un sólo equipo. Para estos casos es recomendable dividir un Elastix en uno o más servidores, o balancear la carga. Existen dos esquemas que se usan en la práctica: Distribuir el trabajo en equipos especializados Distribuir el plan de marcado 18

20 Capítulo 21 Distribuir el trabajo en equipos especializados Es posible migrar ciertos servicios a otros servidores: MySQL Antispam Postfix Openfire Distribuir el Plan de marcado La funcionalidad utilizada es DUNDi y puede configurarse para utilizar varios servidores. Elastix tiene actualmente un addon que permite configurar un plan de marcado distribuido. Revisaremos Plan de Marcado Distribuido y DUNDi mas adelante en este curso. 19

21 Capítulo 22 SEGURIDAD Algo de Historia Por los años 60 se dieron cuenta que si generaban una señal audible a la frecuencia exacta de 2,600 Hertz producían que las llamadas telefónicas se colgaran. Algunos hackers se pusieron a estudiar y entender la señalización telefónica, realizando llamadas de larga distancia de manera gratuita. Desde entonces hay personas dedicando miles de horas de investigación a tratar de quebrantar la seguridad de servidores alrededor del mundo. Buenas Prácticas Todas las acciones básicas recomendadas para iniciar la operación de un servidor de comunicaciones unificadas Limitación del acceso al servidor No usar el usuario root No dejar sesiones de consola abiertas Bloquear el reinicio Utilizar contraseñas fuertes Deshabilitar el acceso directo a FreePBX Ataques y vulnerabilidades a nivel de red IP Denegación de servicio Ataques de inundación SIP (SIP Flooding) Sniffing Captura de llamadas a nivel de VoIP Fraude telefónico Intento de obtención de privilegios de root Algunas soluciones a los problemas de seguridad Apagar los servicios que no vamos a usar 20

22 Capítulo 22 Firewalls IDSs e IPSs Actualizaciones Monitoreo Usar un Switch en lugar de un HUB Cambiar las claves por omisión Encriptando la VoIP SRTP: El protocolo SRTP (Secure RTP) no se encuentra soportado oficialmente en Asterisk 1.6; Asterisk 1.8 tiene soporte nativo para SRTP. VPNs: Una VPN (Virtual Private Network) o Red Privada Virtual es un concepto que nos permite simular una red privada sobre una red pública como el Internet. Encriptación IAX: Cuando IAX fue concebido se pensó en problemas de violación a la privacidad y se añadió soporte nativo para encriptación de llamadas. Auditoría de seguridad Una auditoría de seguridad debe ser considerada como una práctica preventiva. Es recomendable que se realice periódicamente para detectar a tiempo problemas que podrían poner en riesgo nuestros equipos. Escaneo de puertos de red Revisión de logs del sistema Revisión de rootkits Auditoría avanzada con Nessus El módulo de Seguridad de Elastix Configuraciones básicas de seguridad a nivel de interfaz: Gestión de Firewall Auditoría de uso de la Interfaz web de Elastix Auditoría de Contraseñas débiles Configuración Avanzada 21

23 Capítulo 22 Gestión de Firewall Interfaz para administración de IPTables Posee un conjunto de reglas predefinidas Permite la personalización de puertos 22

24 Capítulo 22 Activando el Firewall Creando una nueva regla Opciones para configuración Tráfico: ENTRADA, SALIDA, A TRAVES Interfaz de ENTRADA: CUALQUIERA, Ethernet 0, Loopback Dirección de Origen Dirección de Destino Protocolo: TODOS, TCP, UDP, ICMP, ESTADO Objetivo: ACEPTAR, DESCARTAR, RECHAZAR 23

25 Capítulo 22 Personalizando un Puerto o un rango de Puertos Auditoría de uso de la Interfaz web de Elastix Permite visualizar las operaciones efectuadas utilizando la Interfaz web de Elastix Posee la posibilidad de utilizar filtros por fecha o por búsqueda de una palabra clave Ofrece la descarga de los logs de utilización en formato CSV, XLS o PDF Auditoría de Contraseñas Débiles Analiza las contraseñas de las extensiones creadas en Elastix Verifica que no sean demasiado cortas o que estén basadas en diccionario Algunos ejemplos: qweasd, a1b2c3,

26 Capítulo 22 Configuración Avanzada En este menú se puede activar el acceso directo a FreePBX Se puede también activar llamadas SIP anónimas. Es importante mencionar, que aunque existan estas configuraciones, se recomienda mantenerlas desactivadas por defecto. Activando FreePBX sin embeber Elastix mantiene desactivado por defecto la interfaz no embebida de FreePBX. Si aun es necesario activar la interfaz no embebida de FreePBX, es importante hacerlo correctamente. Para esto es necesario ir a: Security Advanced Settings Una vez que culminemos cualquier configuración que necesitemos hacer es recomendable volver a desactivarla. No actualice FreePBX desde su interfaz, existen procedimientos de actualización con Elastix, consulte en los foros o listas. 25

27 Capítulo 22 Una vez activado FreePBX, podemos revisar lo requerido y después desactivarlo de nuevo. Técnicas Adicionales Implementación de Fail2Ban Implementación de Port Knocking Implementación de ordenes Allow/Deny durante la configuración de las extensiones Mantener deshabilitada la interfaz de FreePBX sin embeber Cambio de puertos por defecto Utilización de VPNs para extensiones remotas Documentación Adicional Seguridad en servidores CentOS con Elastix Rodrigo Martín Elastix Network Security Guide Bob Fryer Trunking entre dos Sistemas de PBX Elastix PBX Vía Internet Bob Fryer Asegurando Elastix Samuel Cornú 26

28 Capítulo 23 Introducción DEPURAMIENTO AVANZADO Un depurador permite examinar la ejecución de un programa a un nivel de detalle mayor que el habitual. La ejecución en detalle permite encontrar errores que de otro modo resultarían difíciles de hallar. Con un depurador es posible examinar qué estuvo ocurriendo en el momento en que un programa se colgó. Dos alternativas para depuración son: strace y gdb Qué hacer cuando Asterisk se comporta mal? Identificar el componente que está causando problemas En algunas ocasiones existen problemas por errores en el código, o bugs. Es importante saber diferenciar si el problema está relacionado con un bug o no Muchas veces no es un problema de Asterisk sino de Sistema Operativo El problema puede ser también por otros componentes de Software o Hardware Reproducir el bug Los pasos básicos a seguir son: Examinar los logs, siendo clave la revisión de los minutos anteriores a la falla. Consultar a los usuarios, ellos viven la operación telefónica día a día. Monitorear el equipo Aunque suene drástico en ocasiones es necesario montar guardia en las instalaciones del cliente y esperar a que el problema ocurra. Una vez que logramos reproducir el bug y determinamos la situación en que se produce podemos hacer dos cosas: Verificar si ha sido reportado - Verificar si ya fue solucionado en recientes versiones de Asterisk. Reportar el bug, si este aun no ha sido reportado, de tal manera que la comunidad de desarrollo de Asterisk lo resuelva. 27

29 Capítulo 23 Errores de Programación Errores de programación que provocan caídas, colgados o comportamientos indeseados Falla de segmentación (Segmentation Fault) Deadlock Fuga de memoria División para cero Buffer overflow Strace Monitorea las llamadas a sistema que realiza un programa determinado y todas las señales que éste recibe. Llamadas al sistema comunes en Linux: open, read, write, close, wait, exec, fork, exit, kill, entre otras. ptrace es la carácterística que hace posible el trabajo de Strace. Ejemplo de ejecución de Strace al programa: cat /proc/cpuinfo : [root@elastix ~]# strace cat /proc/cpuinfo Depuración en Asterisk Un ejemplo sencillo Hay ocasiones donde es importante monitorear un proceso de Asterisk en ejecución. Por ejemplo si nuestro servidor consume muchos recursos de CPU y queramos averiguar qué está ocurriendo. Para depurar un programa en ejecución con strace primero debemos averiguar el PID del proceso que queremos monitorear. Un ejemplo sencillo En nuestro enlistaremos los procesos que contengan la palabra Asterisk y tomaremos el menor PID [root@elastix ~]# ps aux grep asterisk 28

30 Capítulo 23 Ahora que sabemos el PID podemos monitorearlo con strace de manera sencilla: ~]# strace -p 1619 GDB GDB es un completo depurador desarrollado y mantenido por la Free Software Foundation. Nos permite hacer seguimiento de la ejecución de un programa insertando pausas cuando creamos necesario. También nos permite observar lo que un programa estaba haciendo cuando se colgó. Además nos permite cambiar ciertas cosas dentro del programa para ver los efectos que se producen con dichos cambios. GDB es una opción más completa que strace pero también su uso requiere un tanto más de conocimiento. Con GDB podemos depurar programas escritos en C o C++ como es el caso de Asterisk Ejemplos simples de uso de GDB GDB puede utilizarse para depurar un programa de tres maneras diferentes: Depurando un programa desde el depurador; Desde el propio GDB gdb programa Depuración sobre Asterisk en plena ejecución gdb programa PID Depuración haciendo backtrace sobre un Asterisk caído gdb programa caído 29

31 Capítulo 23 Comandos básicos Nota: Para más información puede recurrir al comando man gdb Archivos core y backtraces Muchas aplicaciones dejan archivos core cuando terminan inesperadamente, esto nos permite hacer una depuración post-mortem del software. En el caso de Asterisk esto es posible cuando se lo inicia con la opción g (Elastix inicia Asterisk con dicha opción por defecto). 30

32 Capítulo 23 Si no se está seguro que Asterisk haya sido iniciado con la opción g se puede verificar con el siguiente comando. Un archivo core es el contenido de memoria del programa en el momento en que se detuvo. Es el sistema operativo quien guarda ese contenido de memoria. Este contenido de memoria, combinado con la tabla de símbolos que se genera cuando el programa es compilado hacen que gdb nos pueda mostrar información más legible. Un backtrace es un reporte de las llamadas a funciones que se encontraban en memoria en un momento dado. Desde gdb es posible realizar backtraces sobre un archivo core. Para hacerlo existen dos comandos, el bt y el bt full. El bt full es un backtrace más detallado que el normal. Muestra parámetros y variables locales usados por las funciones que están siendo invocadas. Ejemplo: Primero identificamos el archivo core que necesitamos examinar, por lo general se trata del último. 31

33 Capítulo 23 Cómo reportar un Backtrace a Digium? Si determinamos que tenemos un bug de Asterisk el siguiente paso lógico es reportar ese bug al fabricante. Digium dispone de una interfaz Web para esta finalidad ubicada en: Cuando se reporta un bug es de mucha ayuda para los desarrolladores de Asterisk contar un backtrace para poder entender mejor lo que ocurrió a nivel interno. Los lineamientos generales para reportar backtraces son: Se pide no subir archivos core sino únicamente la salida del comando bt y bt full conseguidos con gdb. Es importante, al reportar un bug de Asterisk, mencionar que se está utilizando Elastix. Esto permitirá a los desarrolladores de Digium conocer que se trata de un Asterisk compilado con parches y funcionalidades adicionales. 32

34 Capítulo 24 PLAN DE MARCADO DISTRIBUIDO DUNDi Distributed Universal Number Discovery DUNDi es un sistema de localización de gateways para el acceso a los servicios de telefonía. Utiliza un esquema punto a punto y no requiere ninguna arquitectura de red en particular ni un esquema jerárquico cliente-servidor. Este es un punto de diferenciación con ENUM En otras palabras DUNDI es capaz de consultar los contextos de otros equipos para encontrar una ruta hacia determinado usuario o peer. DUNDi en realidad no realiza una llamada como tal, ya que no es un protocolo de señalización VoIP Recibe y proporciona la información necesaria para poder contactar a los equipos independientemente del protocolo de señalización usado. Por esto es posible usar DUNDi virtualmente con cualquier protocolo soportado por asterisk. Es parte de Asterisk por lo cual su integración y funcionalidad en Elastix es transparente. Funcionamiento Para que DUNDi funcione se debe conocer al menos un peer Si este peer no puede responder a la consulta (él no tiene ese usuario), puede delegar la consulta a otro peer conocido. Esto sucede sucesivamente hasta que se encuentre a un peer que tenga una respuesta al peer consultado. DUNDi puede ser utilizado en una empresa para extender su operación a varios servidores en una o diferentes sucursales. 33

35 Capítulo 24 Ejemplos de uso Un ejemplo típico de la utilidad de DUNDi es en una empresa multi-sede, en la cual cada sede tiene su propio equipo con Elastix. Cada equipo puede publicar sus extensiones y si uno de los equipos pregunta, por ejemplo dónde está el número 456? la consulta se enviará directa o indirectamente a todos los servidores en la red DUNDi El servidor que tenga esa extensión publicada responderá algo como: IAX2/usuario:clave@ /456 El uso de DUNDi hace que no necesite un plan de marcado fijo para cada equipo integrado en una red. Otro uso común de DUNDi es clúster y balanceo de carga. Esto es importante en un esquema con muchos usuarios así como para esquemas de clúster y disponibilidad. Cuando un servidor no alcanza, comentamos esto en la sección de rendimiento. Bueno, DUNDi es una muy buena opción. Seguridades DUNDi usa certificados de encriptación RSA par compartir los planes de marcado. Esto es requerido ya que las respuestas a una consulta incluyen las contraseñas de las troncales. 34

36 Capítulo 24 Asterisk integra el comando astgenkey que se encarga de generar dichos certificados. Su uso es: astgenkey -n nombre-de-certificado, ej: Estos certificados deben ubicarse en la carpeta /var/lib/asterisk/keys de cada servidor. Podemos compartir este archivo de un servidor a los demás servidores con el comando spc: Configuración DUNDi guarda su configuración en el archivo dundi.conf dentro de la carpeta /etc/asterisk/. Este archivo se divide en tres secciones: [general] - donde se define la identificación en la nube DUNDi y opciones globales. [mappings] - donde se definen las respuestas a una consulta de otro equipo. Peers definición de peers que consultarán y serán consultados. Esta configuración debe ser realizada en cada servidor donde se distribuirá el plan de marcado. iax_custom.conf - Configuración de troncal. extensions.conf - Configuración para modificar el contexto "from-internal" de FreePBX, de tal manera que no obtengamos una respuesta de bad-number en la búsqueda del número. extensions_custom.conf - definimos los contextos personalizados para que DUNDi relacione nuestras extensiones, realice búsquedas en otros equipos y redirija las llamadas. Esta configuración permite que cuando creemos una extensión nueva desde la interfaz, se añada al contexto local incluido en dundi-priv-canonical que usará DUNDi. 35