AGRADECIMIENTO Agradezco a Dios, por estar conmigo en cada paso que doy, por fortalecer mi corazn e iluminar mi mente y por haber puesto en mi camino a aquellas personas que han sido mi soporte y compaa durante toda la mi vida estudiantil. Hoy y siempre agradezco a mi familia y en especial a mi madre que si no fuese por el su esfuerzo valenta y amor mis estudios no hubiesen sido posible.
DEDICATORIA Dedico mi tesis con todo mi amor y cario a mi padre y hermanos Marcelo Vernica Patricio Paola y Marisol por su ejemplo, ayuda incondicional y apoyo. A todos mis amigos por estar junto a mi todo este tiempo donde he vivido momentos felices y tristes, siempre los llevare en mi corazn.
NOMBRE FIRMA FECHA
Ing. Ivn Menes DECANO FACULTAD DE ..................................... ..................................... INFORMTICA Y ELECTRNICA
Ing. Ral Rosero DIRECTOR ESCUELA ..................................... ..................................... INGENIERA EN SISTEMAS
Ing. Alberto Arellano DIRECTOR DE TESIS ..................................... .....................................
Ing. Diego vila MIEMBRO DEL ..................................... ..................................... TRIBUNAL
LCDO. Carlos Rodrguez DIRECTOR DPTO ..................................... ..................................... DOCUMENTACIN
NOTA DE LA TESIS ....................................
Yo Gladys Natal Toscano Palomo, soy el responsable de las ideas, doctrinas y resultados expuestos en esta Tesis, y el patrimonio intelectual de la misma pertenecen a la ESCUELA SUPERIOR POLITCNICA DE CHIMBORAZO.
INDICE DE ABREVIATURAS Abreviatura Descripcin DNS Sistema de Nombre de Dominio Domain Name System IAX Protocolo de intercambio de Asterisk Inter Asterisk Exchange IAX(2) Protocolo de intercambio Asterisk (versin 2) LAN Red de rea Local Local Area Network NAT Traductor de direcciones IP Network Address Translator PBX(PABX) Centrale Telefonica (Automtica) Privada Private (Automatic) Branch Exchange PSTN/RTB Red de Telefona Bsica (Conmutada) Public Switched Telephone Network QoS Calidad de Servicio RFC Documento de Trabajo de Estandarizacin (Internet) Request For Comment RTP Protocolo de Tiempo Real Realtime Transport Protocol SIP Protocolo de Sealizacin de Sesin(es) Session Initiation Protocol UDP User Data Protocol VoIP Voz sobre IP
INDICE GENERAL CONTENIDO CAPTULO I ....................................................................................................................................... I. Marco Referencial ................................................................................................................ 13 1.1 Antecedentes ........................................................................................................................ 13 1.2 Justificacin .......................................................................................................................... 16 1.3 Objetivos .............................................................................................................................. 17 1.3.1 Objetivo General .................................................................................................................. 17 1.3.2 Objetivos Especficos ........................................................................................................... 17 1.4 Hiptesis ............................................................................................................................... 18 CAPITULO II ..................................................................................................................................... II. Marco Terico ...................................................................................................................... 19 2.1 Voz sobre IP (VoIP) ............................................................................................................. 19 2.2 Telefona IP .......................................................................................................................... 20 2.2.1 Caractersticas ...................................................................................................................... 21 2.3 Protocolos ............................................................................................................................. 22 2.3.1 Protocolos de Transporte ...................................................................................................... 22 2.3.1.1 RTP (Real-Time Transport Protocol) ................................................................................... 22 2.3.1.2 RTCP (RTP Control Protocol) ............................................................................................. 23 2.3.2 Protocolos de Sealizacin ................................................................................................... 23 2.3.2.1 SIP (Protocolo de Inicio de Sesin) ..................................................................................... 23 2.3.2.2 IAX(Inter-Asterisk eXchange Protocol) .............................................................................. 24 2.3.3 Protocolos de Enrutamiento Dinmico ................................................................................. 24 2.3.3.1 OSPF (Open Shortest Path First) ......................................................................................... 24 2.3.3.2 RIP (Routing Information Protocol)..................................................................................... 25 2.4 Clster .................................................................................................................................. 25 2.5 Asterisk ................................................................................................................................ 28 2.5.1 Caractersticas ...................................................................................................................... 29 2.5.2 Servicios que permite implementar Asterisk ........................................................................ 30 2.5.3 Servicios que implementa Asterisk ...................................................................................... 31 2.5.4 Productos Asterisk................................................................................................................ 34
2.6 Elastix ................................................................................................................................... 34 2.6.1 Instalacin Elastix ................................................................................................................ 35 2.6.2 Caractersticas ...................................................................................................................... 35 2.6.3 Funcionalidades .................................................................................................................... 36 2.6.4 Soporte para hardware de telefona ...................................................................................... 37 2.6.5 Protocolos que soporta ......................................................................................................... 38 2.6.6 Codecs soportados ................................................................................................................ 39 2.6.7 Soporte para interfaces anlogas .......................................................................................... 39 2.6.8 Soporte para interfaces digitales .......................................................................................... 39 CAPITULO III .................................................................................................................................... III. Estudio de tecnicas de alta disponibilidad en clusters VoIP. .............................................. 40 3.1 Tcnicas para obtener alta disponibilidad en clsters VoIP ................................................. 40 3.1.1 Criterio de seleccin de la tcnica de alta disponibilidad ..................................................... 41 3.1.2 Heartbeat .............................................................................................................................. 41 3.1.2.1 STONITH .............................................................................................................................. 43 3.1.2.2 Funcionamiento ..................................................................................................................... 44 3.1.3 DUNDi ................................................................................................................................. 45 3.1.3.1 Aplicaciones de DUNDi ....................................................................................................... 47 3.1.3.2 Cluster VOIP con DUNDi .................................................................................................... 48 3.1.4 Definicin de parmetros para evaluacin. .......................................................................... 48 3.1.5 Ponderacin. ......................................................................................................................... 49 CAPITULO IV .................................................................................................................................... IV. Diseo e implementacin de una red de alta disponibilidad en un ambiente de prueba. ..... 41 Modelo DUNDi ................................................................................................................................. 41 4.1 Esquema general .................................................................................................................. 41 4.2 Descripcin de los mdulos de prueba desarrollados.......................................................... 64 4.2.1 Terminales ............................................................................................................................ 64 4.2.2 Telfonos IP ......................................................................................................................... 64 4.2.3 Servidor DNS ....................................................................................................................... 64 4.2.4 Base de Datos MySQL ......................................................................................................... 66 4.2.5 Asterisk Realtime ................................................................................................................. 67
4.3 DUNDi ................................................................................................................................. 67 4.3.1 Configuracin ....................................................................................................................... 68 4.3.2 Ambiente de prueba ............................................................................................................. 68 4.4 Pruebas del clster de Alta Disponibilidad con DUNDi ...................................................... 78 4.4.1 Escenario 1. Apagado del nodo activo ................................................................................. 78 4.4.2 Escenario 2. Cada del servicio ............................................................................................ 83 4.4.3 Interpretacin del Escenario 1 y 2 ........................................................................................ 84 Modelo Heartbeat .............................................................................................................................. 85 4.5 Esquema general .................................................................................................................. 85 4.5.1 Componentes ........................................................................................................................ 85 4.5.2 Diseo de la Arquitectura del Clster. ................................................................................. 86 4.5.3 Estimacin de Costos de la Red ........................................................................................... 92 CAPITULO V ...................................................................................................................................... V. Evaluacin del modelo de alta disponibilidad. ..................................................................... 95 5.1 Evaluando: Centrales Telefnicas ........................................................................................ 95 5.1.1 Escenario 1: Apagando Normalmente la Central con rol principal ...................................... 95 5.1.2 Escenario 2: Fallas en el Servidor Principal ......................................................................... 99 5.1.3 Escenario 3: Fallas en la Red o Tarjeta de Red .................................................................. 100 5.1.4 Escenario 4: Detectando las fallas de los Servidores DNS (Capa 2) ................................. 103 5.2 Comprobacin de la hiptesis de la investigacin realizada. ........................................... 106 5.2.1 Planteamiento de la Hiptesis ............................................................................................ 106 5.2.2 Alta Disponibilidad ............................................................................................................ 106 5.2.3 Evaluacin Indicadores ...................................................................................................... 108 5.2.4 Ponderacin para Indicadores ............................................................................................ 109 5.2.5 Valoracin de la disponibilidad en los modelos de DUNDi y Heartbeat ........................... 109 5.2.6 Decisin .............................................................................................................................. 110 5.2.7 Comprobacin de alta disponibilidad con Heartbeat.......................................................... 110 CONCLUSIONES ................................................................................................................................ RECOMENDACIONES ....................................................................................................................... RESUMEN............................................................................................................................................ GLOSARIO ..........................................................................................................................................
Figura III-1: Arquitectura Heartbeat. ............................................................................................. 43 Figura III-2: Grfico parmetro configuracin .............................................................................. 52 Figura III-3: Grfico parmetro configuracin .............................................................................. 54 Figura III-4: Grfico parmetro escalabilidad ................................................................................ 58 Figura III-5: Grfico parmetro calidad de servicio. ...................................................................... 61 Figura IV-6: Softphone X-lite. ....................................................................................................... 80 Figura IV-7: Registro de cuenta en el Softphone X-lite. ................................................................ 80 Figura IV-8: Grafico de la Tabla IV.XIV . ..................................................................................... 82 Figura IV-9: Grfico de la Tabla IV.XV . ...................................................................................... 84 Figura IV-10: Terminales (Softphone y Telfonos IP) . ................................................................. 85 Figura IV-11: Servidor DNS . ........................................................................................................ 85 Figura IV-12: Servidor Asterisk . ................................................................................................... 86 Figura IV-13: Red Ethernet . .......................................................................................................... 86 Figura IV-14: Capa 1 (Modelo Heartbeat) . ................................................................................... 87 Figura IV-15: Capa 2 (Modelo Heartbeat) . ................................................................................... 89 Figura IV-16: Esquema (Modelo Heartbeat) . ................................................................................ 91 Figura V-17: Grfico Tabla V.XIX. ............................................................................................... 96 Figura V-18: Grfico Tabla V.XX. ................................................................................................. 97 Figura V-19: Grfico Tabla V.XXI. ............................................................................................... 98 Figura V-20: Grfico Tabla V.XXII. ............................................................................................ 100 Figura V-21: Grfico Tabla V.XXIII. ........................................................................................... 101 Figura V-22: Grfico Tabla V.XXIV. .......................................................................................... 104 Figura V-23: Grfico Tabla V.XXVI. .......................................................................................... 108
INDICE TABLAS
Tabla III.I : Determinacin de los criterios de Comparacin. ........................................................ 49 Tabla III.II : Tabla de Ponderacin. ............................................................................................... 49 Tabla III.III : Variables del parmetro Configuracin. .................................................................. 50 Tabla III.IV : Comparacin Variables del parmetro de Configuracin. ....................................... 51 Tabla III.V : Variables del parmetro Soporte Criptogrfico. ........................................................ 52 Tabla III.VI : Variables del parmetro Soporte Criptogrfico. ...................................................... 53 Tabla III.VII : Variables del parmetro Aprendizaje. .................................................................... 55 Tabla III.VIII : Informacin acerca de foros y ayuda en lnea. ..................................................... 56 Tabla III.IX : Variables Parmetro Escalabilidad. ......................................................................... 57 Tabla III.X : Comparacin variables del parmetro Escalabilidad ................................................ 57 Tabla III.XI : Variables parmetro Calidad de Servicio. ............................................................... 59 Tabla III.XII : Comparacin variables del parmetro Calidad de Servicio. .................................. 60 Tabla IV.XIII : Direcciones IP y MAC de las centrales. ............................................................... 68 Tabla IV.XIV : Tiempo de Asignacin de una nueva direccin IP. ............................................... 82 Tabla IV.XV : Tiempo de Asignacin de una nueva direccin IP. ................................................ 83 Tabla IV.XVI : Costo de Equipos y Accesorios. ............................................................................ 93 Tabla IV.XVII : Costos de Instalacin. .......................................................................................... 93 Tabla IV.XVIII : Costo total del Proyecto. .................................................................................... 94 Tabla V.XIX : Tiempo Escenario 1. ............................................................................................... 96 Tabla V.XX : Tiempo de toma de control por el servidor principal. .............................................. 97 Tabla V.XXI : Tiempo de autentificacin de las Terminales. ........................................................ 98 Tabla V.XXII : Tiempo de toma de control por el servidor pasivo. ............................................... 99 Tabla V.XXIII : Tiempo de toma de control por el servidor pasivo ante falla en la red. ............. 101 Tabla V.XXIV : Tiempo de demora del servidor DNS cuando ocurre un fallo ........................... 103 Tabla V.XXV : Tabla resumida de Escenarios de Pruebas. .......................................................... 105 Tabla V.XXVI : Tabla de disponibilidad ...................................................................................... 107 Tabla V.XXVII : Tabla de Indicadores ........................................................................................ 108 Tabla V.XXVIII : Tabla de Indicadores ....................................................................................... 109 Tabla V.XXIX : Disponibilidad en DUNDi vs Heartbeat ............................................................ 110 Tabla V.XXX : Tabla resumida de Escenarios con la Disponibilidad. ......................................... 111
CAPTULO I I. MARCO REFERENCIAL
1.1 ANTECEDENTES
Actualmente, para el funcionamiento de los servicios de voz se utilizan las redes por conmutacin de circuitos que son redes pblicas tales como las redes RTC (Red Telefnica Pblica Conmutada tambin llamada Red Telefnica Bsica o RTB) conocida tambin como PSTN o RTPC que es una red analgica y ISDN o RDSI (Red Digital de Servicios Integrados), pueden servir tambin para el envi de datos, por medio de un mdem o ADSL (Lnea de Abonado Digital Asimtrica).En las empresas se puede decir que utilizan dos redes muy bien diferenciadas, una encargada del trfico y servicios de voz y otra destinada para el trfico de datos que se basa en la conmutacin de paquetes. Con el avance de las tecnologas actuales para VoIP se tiene la capacidad de proporcionar unos servicios garantizados sobre una nica red donde confluyen trficos tanto de voz como de datos, lo 14
que nos lleva a afirmar que se dispone de una red multiservicio que principalmente reduce costes y ancho de banda.
Hoy en da, la mayora de las empresas tienen su propia red telefnica convencional, diseada sobre PBX, que soportan todos los servicios telefnicos tradicionales, estos se conectan a la RTC o RDSI para llamadas externas a telfonos fijos o mviles y si la empresa tiene un gran volumen de llamadas y varias oficinas, stas pueden conectarse por lneas dedicadas de alta capacidad, que le reducirn el coste considerablemente.
Otra de las caractersticas de los sistemas de comunicacin en la empresa es tener su propia red de datos de rea local (LAN), donde se conectan sus diversos equipos de datos. Estas redes de datos se han ido ampliando, pudiendo conectar equipos en oficinas remotas mediante la interconexin de diversas LAN, por medio de lneas dedicadas.
Este tipo de redes se conocen como VPN (Virtual Private Network). El hecho de tener dos redes independientes para comunicaciones telefnicas y de datos es algo caro e innecesario, por lo que la telefona IP proporciona una nueva va en el campo de las comunicaciones de la empresa. Hoy en da se habla mucho de dos conceptos, telefona IP y VoIP, y se tiende a utilizar ambos trminos para lo mismo, cuando existe una diferencia entre ellos. La telefona IP se refiere a la utilizacin de una red IP (privada o pblica, como es Internet) por la que transmitimos los servicios de voz, fax y mensajera. Esta red IP puede ser utilizada para realizar las llamadas internas de la propia empresa, as como las llamadas externas, usando, por ejemplo, Internet en lugar de la red telefnica pblica conmutada.
15
La VoIP es la tecnologa usada para el funcionamiento de la telefona IP. VoIP gestiona el envo de informacin de voz utilizando IP (Internet Protocol). La informacin analgica vocal se transforma en paquetes digitales diferenciados que se envan por la red. Los paquetes de informacin de voz viajan por la red IP, del mismo modo que los datos generados por una comunicacin de correo electrnico, por ejemplo. Por tanto, la telefona IP es una aplicacin inmediata de esta tecnologa.
Asterisk se ha convertido en referente mundial a lo que PBX IP se refiere, muchos han sido los que han solicitado la necesidad de crear un posible clster para Asterisk. Que permita dar soporte a los usuarios aun cuando una de las centrales pertenecientes a los nodos del clster est fuera de servicio.
Hasta hoy sta ha sido una de las prioridades de Digium creador de Asterisk, por el momento se ha desarrollado un modulo llamado res_ais que permite controlar el estado de una extensin situada en otro Asterisk. Lo que restara es propagar esta informacin a travs del Asterisk conectados entre s por DUNDi Dentro del anlisis de las tecnologas a utilizar se encuentra enmarcado DUNDi que permite comunicar 2 o ms PBX basadas en Asterisk y as establecer la comunicacin entre dos terminales VoIP unificando el plan de marcado de cada servidor PBX independiente.
La implementacin de la red de alta disponibilidad se la realizara en los Laboratorios de CISCO a travs de un ambiente de prueba, ya que cuenta con los equipos necesarios adems de que se tiene acceso a otros recursos como por ejemplo el Internet.
16
Este tema de tesis se enmarca en el anlisis y diseo de un clster de Centrales Asterisk basado en DUNDi lo cual permitir implementar una red de alta disponibilidad.
Para la parte aplicativa nos limitaremos en los siguientes mdulos: La red de alta disponibilidad permitir: Unificacin del plan de marcado (Dial Plan) Garantizar la alta disponibilidad
1.2 J USTI FI CACI N
La VoIP es un servicio de misin crtica cuyo mayor riesgo es su interrupcin. Los usuarios de telefona IP deben gozar, por tanto, de los altsimos niveles de disponibilidad a los que estn acostumbrados a recibir de la red telefnica convencional.
Por lo tanto una de las necesidades a resolver es la construccin de un sistema estable y robusto de centrales Asterisk que nos permita obtener una red de alta disponibilidad, que proporcionara y garantizara el servicio en un mayor porcentaje. Para lo cual se propone construir un clster de Asterisk que permita que todo funcione correctamente aun en el caso de que uno de los nodos dejase de funcionar.
En este sentido es conseguir propagar la informacin de los usuarios (libres, ocupados, hablando, no disponible, etc.) entre los distintos servidores que forman el clster. Para el funcionamiento de la red de Alta disponibilidad se proponen los siguientes mdulos.
17
Un servidor DNS que ser el encargado de proporcionar direcciones IP de las centrales a cada uno de los usuarios que ingresen a registrarse, adems facilitar el balanceo de carga.
Las PBX Asterisk o el ncleo de la red, que son las centrales telefnicas y se encargarn de gestionar las llamadas en curso.
La Base de Datos en MySQL esta contendr la informacin del Dial Plan o Plan de marcado, informacin acerca de las terminales y de los registros de llamadas.
DUNDi (Distributed Universal Number Discovery) que interviene al momento de que una extensin no se encuentre gestionada en nuestra central. Este ayudar a buscarle en distintos nodos del clster.
1.3 OBJ ETI VOS
1.3.1 Objetivo General
Analizar y disear una red de alta disponibilidad para centrales Asterisk basada en la tecnologa DUNDi que permita el acceso de los usuarios en un mayor porcentaje.
1.3.2 Objetivos Especficos Estudiar las tcnicas de alta disponibilidad en redes VoIP para seleccionar de acuerdo a sus ventajas y limitaciones la ideal y ms adecuada para este sistema. 18
Analizar la tecnologa DUNDi y configurarla en cada central telefnica para establecer la comunicacin punto a punto entre los nodos que forman parte de la estructura del clster VoIP. Analizar la arquitectura de Asterisk para reconocer los componentes que intervienen en un sistema de Telefona IP y la posibilidad de integrar hardware de distintas marcas y precios. Disear e implementar un Ambiente de Prueba para determinar la disponibilidad que existe en un Clster VoIP y as comprobar el incremento porcentual de la misma.
1.4 HI PTESI S
La implementacin de una red de alta disponibilidad para centrales Asterisk basada en la tecnologa DUNDi permitir dotar de alta disponibilidad al sistema de Telefona IP. Variables e Indicadores Independiente o Variable: Implementacin de una red. Dependiente o Variable: Alta Disponibilidad. o Indicadores: Tiempo de demora de la toma del control del servicio por otros Servidores del Clster. Tiempo de prdida del servicio al ocurrir fallas en los Servidores. Tiempo de demora de registro de las terminales.
CAPITULO II II. MARCO TEORICO
CONCEPTOS IMPORTANTES PREVIOS
2.1 VOZ SOBRE I P (VoI P)
El VoIP (Protocolo de Voz Sobre Internet) o VoIP (Voice Over Internet Protocol) es una tecnologa que rene un grupo de recursos que hacen posible que la seal de voz viaje a travs de Internet empleando un protocolo IP (Internet Protocol), esto quiere decir que permite transmitir la voz en forma digital sobre redes IP, en lugar de una lnea telefnica regular (o analgica), es decir convierte las seales de voz estndar en paquetes de datos comprimidos que son transportados a travs de redes de datos en lugar de lneas telefnicas tradicionales.
20
Segn Wikipedia [ 1 ]: Voz sobre Protocolo de Internet, tambin llamado Voz IP, VozIP, VoIP (por sus siglas en ingls), es un grupo de recursos que hacen posible que la seal de voz viaje a travs de Internet empleando un protocolo IP (Protocolo de Internet).
Segn Monografias [ 2 ]: La Voz sobre IP (VoIP, Voice over IP) es una tecnologa que permite la transmisin de la voz a travs de redes IP en forma de paquetes de datos.
Los servicios de VoIP convierten su voz en una seal digital que viaja a travs de Internet. Si est llamando a un nmero de telfono regular, la seal es convertida a una seal de telfono regular antes de llegar al destino. VoIP puede permitirle hacer una llamada directamente desde una computaadora, un telfono especial de VoIP, o un telfono tradicional conectado a un adaptador especial.
Adems, de forma inalmbrica mediante un "hotspot" en lugares tales como aeropuertos, parques y cafs le permite conectarse a Internet y puede permitir usar el servicio VoIP de forma inalmbrica.
2.2 TELEFON A I P
La telefona IP es una aplicacin de la tecnologa de Voz sobre IP, rene la transmisin de voz y de datos, lo que facilita la utilizacin de las redes informticas para efectuar llamadas telefnicas. Adems, dicha aplicacin al formar una nica red que es la encargada de transmitir todo tipo de
comunicacin, como es voz, datos o video, ha tomado el nombre de red convergente o red multiservicios.
Segn Monografias [ 3 ]: La telefona sobre IP que es una aplicacin inmediata de la tecnologa VoIP de forma que permita la realizacin de llamadas telefnicas ordinarias sobre redes IP u otras redes de paquetes utilizando un PC, gateways y telfonos estndares. En general, servicios de comunicacin - voz, fax, aplicaciones de mensajes de voz - que son transportada va redes IP, Internet normalmente, en lugar de ser transportados va la red telefnica convencional.
Abre un espacio muy importante dentro del universo que es Internet. Establece la posibilidad de estar comunicados a costos ms bajos dentro de las empresas y fuera de ellas, es la puerta de entrada de nuevos servicios apenas imaginados y es la forma de combinar una pgina de presentacin de Web con la atencin en vivo y en directo desde un call center, entre muchas otras prestaciones.
2.2.1 Caractersticas
La telefona IP surge como una alternativa econmica a la telefona tradicional, brindando nuevos servicios y una serie de beneficios econmicos y tecnolgicos con caractersticas especiales como:
En comparacin con la red analgica es realmente econmica, solo es necesario contar con un micrfono y unos auriculares o parlantes.
No depende del tipo de red fsica que lo soporta. Permite la integracin con las grandes redes de IP actuales adems de poder integrarse con la red pblica o PSTN. No depende del hardware utilizado. Admite ser implementado tanto en software como en hardware, con la particularidad de que el hardware supondra eliminar el impacto inicial para el usuario comn. Permite la integracin de Vdeo y TPV Se necesita una red activa para su funcionamiento.
2.3 PROTOCOLOS
2.3.1 Protocolos de Transporte
2.3.1.1 RTP (Real-Time Transport Protocol)
Es un protocolo desarrollado por la IETF [ 4 ] que permite transmitir informacin de audio y video a travs de internet en tiempo real.
Este protocolo funciona sobre el protocolo de transporte UDP [ 5 ] , es decir se encapsula dentro de datagramas UDP. Al trabajar bajo UDP no garantiza la entrega de todos los paquetes al igual que su llegada al destino en el instante adecuado. La capa de aplicacin se encarga de superar estos fallos en la transmisin de informacin. RTP no trabaja con un puerto predefinido por lo general escoge un nmero par elegido al azar.
4 (Internet Engenieering Tast Force) Es una organizacin abierta de normalizacin que contribuye a la ingeniera de Internet. 5 (User Datagrama Protocolo) Es el protocolo de nivel de transporte basado en el intercambio de datagramas. No le importa si los datos llegan con errores o no. Permite el envi de datagramas a travs de la red sin establecer previamente una conexin. 23
2.3.1.2 RTCP (RTP Control Protocol)
Este protocolo se usa para enviar datos de control y de mediciones realizadas durante la transmisin. Para lo cual la transmisin se encapsulan dentro de mensajes RTP. La frecuencia de envo es aproximadamente cada cinco segundos. El puerto con el cual trabaja RTCP al igual que RTP no es definido, por ello escoge un nmero de puerto impar consecutivo en relacin al seleccionado por RTP. RTCP no da ninguna clase de cifrado de flujo o de autenticacin.
2.3.2 Protocolos de Sealizacin
2.3.2.1 SIP (Protocolo de Inicio de Sesin)
Es un Protocolo de Inicio de Sesiones creado por el IETF (Internet Engineering Task Force). Este protocolo de sealizacin para voz sobre IP es utilizado para iniciar, modificar y terminar Sesiones Interactivas de Comunicacin Multimedia entre usuarios tales como: video, voz, mensajera instantnea y realidad virtual. La sintaxis de las operaciones que realiza SIP son equivalentes a las realizadas por los protocolos de servicio de pginas web (HTTP) y distribucin de e-mails (SMTP). SIP para su funcionamiento trabaja en conjunto con los protocolos SDP y RTP. SDP (Session Description Protocol) se encarga de describir los parmetros de inicializacin de los flujos multimedia en una sesin, es decir su funcin es invitar, anunciar y negociar las capacidades de una sesin multimedia en internet. RTP (Real-Time Transport Protocol) cumple con la funcin de transportar en tiempo real el contenido de voz y video entre los usuarios una vez establecida la sesin.
24
Agentes de Usuario
Los Agentes de usuario son los puntos extremos de la Sesin, estos se pueden comportar de dos modos: Un User Agent Client (UAC) es el encargado de realizar las peticiones de servicio, mientras que el User Agent Server (UAS) es el encargado de procesar la peticin recibida.
2.3.2.2 IAX(Inter-Asterisk eXchange Protocol)
Es un protocolo creado para la sealizacin de VoIP en Asterisk. Este protocolo es abierto para su libre desarrollo. Para control y trfico de datos usa el puerto UDP 4569. IAX se basa en muchos estndares de transmisin de datos como SIP y RTP.
2.3.3 Protocolos de Enrutamiento Dinmico
2.3.3.1 OSPF (Open Shortest Path First)
Es un protocolo de enrutamiento jerrquico de pasarela interior, o IGP (Interior Gateway Protocol)pararedes TCP/IP, basadas en el RFC 2328.OSPF es un estndar abierto, razn por la cual est disponible en mltiples sistemas operativos como: Windows 2003 Server, Linux, Cisco IOS, etc.
25
2.3.3.2 RIP (Routing Information Protocol)
El protocolo RIP es un protocolo de encaminamiento dinmico de tipo IGP (Internal Gateway Protocol), utilizado por routers y equipos, para intercambiar informacin acerca de redes IP.
2.4 CLSTER
Es necesario explicar que es un clster; un clster consiste en un grupo de nodos (computadoras) conectados entre s que interactan como una sola maquina as en el caso de que uno de los nodos dejase de funcionar tomara el control el segundo nodo, y as sucesivamente dependiendo del nmero de computadoras que conformen el clster, reduciendo as considerablemente la tolerancia a fallos y cadas de servicio.
Segn Ismael Olea [ 6 ]: Un clster es un grupo de equipos independientes que ejecutan una serie de aplicaciones de forma conjunta y aparecen ante clientes y aplicaciones como un solo sistema. Los clsteres permiten aumentar la escalabilidad, disponibilidad y fiabilidad de mltiples niveles de red. Segn Eugenio Villar y Julio Gmez [ 7 ]: Un clster es una agrupacin de dos o ms computadores que se encuentran interconectados y que normalmente trabajan de forma conjunta con algn propsito determinado. Desde fuera, en la mayora de los casos, el clster es visto como un nico equipo que ofrece unos determinados servicios.
6 Extrado de la siguiente URL, http://www.ibiblio.org/pub/linux/docs/LuCaS/Manuales-LuCAS/doc-cluster- computadoras/doc-cluster-computadoras-html/node8.html 7 Extrado de la siguiente URL, http://www.adminso.es 26
Es usual que los componentes que integran el clster, llamados nodos, se encuentren interconectados mediante conexiones LAN (Local Area Network) de alta velocidad. El objetivo por el cual se sugiere implantar es ampliar la funcionalidad de un servidor o bien mejorar su rendimiento y/o disponibilidad. En funcin de las caractersticas que presente el clster y sus objetivos, se puede mencionar los siguientes: Clsteres de alta disponibilidad. El rasgo particular de este tipo de clsteres es la comparticin de un determinado servicio entre los diferentes nodos que lo componen (o un grupo de ellos), los cuales se monitorizan constantemente entre s, de forma que se garantiza el funcionamiento ininterrumpido del servicio. Tanto si se produce un fallo hardware como si ocurre alguno en las aplicaciones o servicios que corren en el nodo que las ejecuta del clster, las aplicaciones o servicios son migrados por el software de alta disponibilidad de forma automtica a cualquiera de los nodos restantes del clster. Una vez que el problema es subsanado, los servicios migrados pueden retornar a su ubicacin original en el nodo primario (llamado as porque es el que originalmente los ejecuta). Existen diferentes configuraciones, como Activo/Pasivo (donde slo un nodo ejecuta servicios) o Activo/Activo (todos los nodos ejecutan servicios, normalmente diferentes). La alta disponibilidad puede ser garantizada a nivel de servicio y tambin a nivel de datos, existiendo para cada uno numerosas herramientas en GNU/Linux tanto software como hardware.
Clsteres de alto rendimiento. El propsito de este tipo es proporcionar altas prestaciones de capacidad de cmputo superior a las que pudiera ofrecer un nico servidor. El ejemplo ms conocido son los llamados clsteres Beowulf, en los que los nodos se encuentran localizados conjuntamente, son homogneos y comparten una red dedicada. Normalmente 27
son formados cuando el tamao del problema a resolver es inmanejable por un nico servidor o cuando la mquina que podra hacerlo tiene un coste muy alto. El alto rendimiento puede ser aplicado en distintos niveles tambin, siendo especialmente interesante en nuestro caso enfocado a servicios en especial en aquellos que han de soportar una mayor congestin o trfico-. Como ejemplos de software para la implementacin de clsteres de alto rendimiento podemos citar OSCAR (Open Source Cluster Application Resources), distribuido bajo la licencia GPL, o Windows HPC Server 2008 para sistemas operativos Microsoft Windows. Algunas herramientas GNU/Linux enfocadas al alto rendimiento concretamente en servicios son KeepAlived, UltraMonkey, o LifeKeeper. Clsteres de balanceo de carga. Desde el punto de vista que se mire el balanceo de carga tambin podra ser interpretado como una solucin de alto rendimiento. Algunos de los nodos del clster actan como frontend del mismo y se encargan de repartir las peticiones que reciben para un servicio determinado entre otro grupo de nodos que conforman el backend del clster. Existen soluciones tambin enfocadas para servicios especficos, como por ejemplo Web, FTP, DNS entre otros es decir, servicios que esperan recibir proporciones de trfico elevadas. Por ejemplo, para telefona IP existen varias herramientas cuya funcionalidad es la de implementar un proxy SIP (protocolo de sesin ms usado en la actualidad) de alto rendimiento y muy configurable; KAMAILIO y OpenSIPS son dos de las ms importantes, derivadas de la desaparecida OpenSER.
Escalabilidad y robustez son dos caractersticas que siempre deben estar presentes en un clster. Escalabilidad tanto administrativa como en carga soportada, y robustez garantizando siempre la disponibilidad de nodos que estn activos en el clster. 28
Para el presente trabajo de tesis un clster de alta disponibilidad nos sirve perfectamente en el caso de un problema de Hardware o como en las aplicaciones o servicios que corren en el nodo que las ejecuta del clster, nuestros clientes tendran igualmente servicio ya que cualquiera de los nodos restantes tomara el control como maquina primaria.
2.5 ASTERI SK
Bsicamente Asterisk es una plataforma software de Dominio Pblico (Open Software) para el desarrollo de centrales telefnicas (PBXs) y es considerado por algunos como el sistema de telefona ms flexible y extensible de los que actualmente existen en el mercado. Proporciona todas las funcionalidades de los grandes sistemas propietarios y ofrece algunas posibilidades y servicios todava no disponibles en ellos. Adems, es el ms competitivo en precio. Est sujeto a la licencia de distribucin de software GPL y utiliza para su funcionamiento el sistema operativo Linux, tambin de libre distribucin.
Fue creado por Mark Spencer como respuesta a la estrategia de la mayora de los fabricantes de telefona de mantener sus sistemas completamente cerrados para cautivar a sus clientes y evitar la libre competencia. Actualmente es uno de los proyectos de Dominio Pblico de ms difusin y con una de las comunidades de usuarios y desarrolladores ms activa. Adems, Digium, la empresa fundada por Mark Spencer, se encuentra detrs de este proyecto soportndolo comercialmente.
29
2.5.1 Caractersticas
Es econmico ya que utiliza la misma infraestructura de red de datos para realizar llamadas sin hacer uso de la red convencional adems puede utilizar softphone que simulan a los telfonos fsicos. Es Interoperable es decir Asterisk puede integrarse con sistemas hbridos en los que se mezclen medios tradicionales de comunicacin telefnica con nuevos servicios basados en redes IP. Por lo cual se pueden aprovechar las infraestructuras ya existentes, como terminales telefnicos o lneas de comunicaciones, e integrarlas con nuevos servicios. Tiene la capacidad de interoperar protocolos SIP, IAX, H.323, MGCP y SCCP/Skinny, as como soportar los estndares de telefona tanto europeos como americanos.
Es flexible y tiene la capacidad de crecimiento Asterisk est formado en mdulos y estructurado en capas, ofrece cuatro tipos distintos de vas o interfaces para que otras aplicaciones puedan acceder a toda la funcionalidad que ofrece. Se trata realmente de un middleware de telefona y comunicaciones.
Tiene una gran funcionalidad ofrece un conjunto de servicios muy extenso. Por medio de una adecuada configuracin se pueden establecer enrutamientos de llamadas complejos y definir estrategias de asignacin de llamadas a los agentes lo que lo hace muy til para el diseo de call centers para telemarketing o soporte de usuarios.
30
2.5.2 Servicios que permite implementar Asterisk
Contestacin Automtica de llamadas Transferencia de llamadas, internas y externas. Desvo de llamadas si est ocupado o no contesta. Opcin No molestar (Do Not Disturb). Parqueo de llamadas (Call Parking). Contestacin de una llamada a una extensin remota. Llamada en espera (Hold). Grupos de llamada (Ring groups). Identificador de llamante (CallerID). Sistema DISA12. (mtodo por el cual una persona externa a la oficina puede realizar llamadas a travs de la centrale). Operadora Digital (mens interactivos y guiados). Msica en espera y en transferencia (ficheros MP3 actualizables por el usuario). Captura de llamadas de forma remota (remote pickup). Buzones de voz (general, individuales, por grupos) protegidos por contrasea. Gestin de listas negras (nmeros telefnicos con acceso prohibido). Salas de conferencia (2 o ms terminales simultneamente). Registro y listados de llamadas entrantes y salientes, con grficas de consumo. Deteccin automtica de entrada de faxes. Recepcin de fax desde el propio sistema y posterior envo por e-mail. Gestin de colas de llamadas entrantes. Grabacin de llamadas entrantes y salientes. 31
Monitorizacin de llamadas en curso. Soporta videoconferencia con protocolos SIP e IAX2.
2.5.3 Servicios que implementa Asterisk
Extensiones mviles Enrutamiento por Indetificador de llamada Mensajera SMS Sistema TextToSpeach Emitir Letras y Nmeros Deteccin de Voz Llamada a tres Fecha y Hora Traduccin de Codec Trunking Pasarelas VozIP Sistema de Buzn de Voz Indicador visual de mensaje no escuchado Indicador sonoro de mensaje no escuchado Mensajes del Buzn de Voz a Email Grupos de Buzn de Voz Interfaz Web de acceso al Buzn de Voz Identificacin de llamada en Llamada en Espera Soporte de oficina Remoto 32
Sistema de Men en Pantalla Receptor de Alarmas Adicin de Mensajes Autentificacin Atencin de llamada Automtica Listas Negras Transferencia Ciega Transferencia con Consulta Registro de detalles de Llamada Reenvo de llamada en ocupado Reenvo de llamada en No-disponible Reenvo de llamada variable Monitorizacin de Llamadas Aparcamiento de Llamada Sistemas de Colas Grabacin de llamadas Recuperacin de Llamadas Enrutamiento de llamadas (DID & ANI) Escucha de Llamadas Transferencia de Llamadas Llamada en Espera Identificacin de LLamada Bloqueo por identificacin de llamada Tarjetas prepago 33
Multiconferencia Almacenamiento / Recuperacin en BBDD Integracin con BBDD Llamada por Nombre Sistema de Acceso directo entrante Timbre personalizable No molestar E911 ENUM Recepcin y Envo de FAx Lgica de extensiones Flexible Listado de directorio Interactivo Respuesta de Voz Interactiva(IVR) Agentes de llamada Locales y Remotos Macros Msica en Espera Msica en Espera en transferencia Sistema de MP3 configurable Control de Volumen Marcador Predictivo Privacidad Protocolo de establecimiento abierto (OSP) Conversin de protocolo Captura de Llamadas 34
2.5.4 Productos Asterisk
Entre los productos de Asterisk se encuentra Elastix, Trixbox, Asterisknow, Asterisk@Home entre otros, el que se ha destacado por su confiabilidad modularidad y fcil uso ha sido Elastix. Lo cual ha ayudado mucho al momento de decidir que producto utilizar para el desarrollo del presente trabajo de Tesis.
2.6 ELASTI X
Elastix es un software aplicativo que integra las mejores herramientas disponibles para PBXs basados en Asterisk en una interfaz simple y fcil de usar. Adems aade su Propio conjunto de utilidades y permite la creacin de mdulos de terceros para hacer de este el mejor paquete de software disponible para la telefona de cdigo abierto.
La meta de Elastix son la confiabilidad, modularidad y fcil uso. Estas caractersticas aadidas a la robustez para reportar hacen de la misma, la mejor opcin para implementar un PBX basado en Asterisk. Las caractersticas provedas por Elastix son muchas y variadas. Elastix integra varios paquetes de software, cada uno incluye su propio conjunto de caractersticas. Adems aade nuevas interfaces para el control y reportes de si mismo, lo que lo hace un paquete completo.
35
2.6.1 Instalacin Elastix
La instalacin de Elastix es sumamente sencilla, hay que tomar en cuenta la versin que se va a instalar para el presente trabajo de tesis se va a instalar la versin 2.0. Ver Anexo1.
2.6.2 Caractersticas
Soporte para VIDEO Soporte para Virtualizacin Interfaz Web para el usuario Interfaz para tarifas Configuracin grfica de parmetros de red Reportes de uso de recursos Opciones para reiniciar/apagar remotamente Reportes de llamadas entrantes/salientes y uso de canales Mdulo de correo de voz integrado Interfaz Web para correo de voz Servidor de correo integrado incluye soporte multi-dominio. Interfaz web para email Mdulo de panel operador integrado Mdulos extras SugarCRM y Calling Card incluidos Seccin de descargas con accesorios comnmente usados Interfaz de ayuda embebido Servidor de mensajera instantneo (Openfire) integrado 36
Voicemail o Buzn de voz Fax Soporte para softphones Consola de operador IVR o Recepcionista digital Interfase de configuracin Web Grabacin de llamadas Limite de tiempo Least Cost Routing Roaming de extensiones Email Llamada en espera 37
Interconexin entre PBXs Identificador de llamadas Reportacin avanzada Billing Extras
2.6.4 Soporte para hardware de telefona
Elastix cuenta con un buen soporte para hardware de telefona, contando con drivers para los principales fabricantes de tarjetas como:
Elastix tambin soporta muchas marcas de telfonos gracias a que los protocolos SIP e IAX que usa Asterisk lo permiten. Estos protocolos son abiertos por lo que prcticamente cualquier fabricante puede implementar un telfono que se comunique sobre estos estndares. Algunos fabricantes de telfonos soportados son:
38
Polycom Atcom Aastra Linksys Snom Cisco Nokia UTstarcom
2.6.5 Protocolos que soporta
IAX (Inter-Asterisk Exchange) IAX2 (Inter-Asterisk Exchange V2) H.323 SIP (Session Initiation Protocol) MGCP (Media Gateway Control Protocol SCCP (Cisco Skinny) Traditional Telephony Interoperability DTMF support PRI Protocols, entre otros
2.6.8 Soporte para interfaces digitales E1/T1/J1 a travs de protocolos PRI/BRI/R2
CAPITULO III III. ESTUDIO DE TECNICAS DE ALTA DISPONIBILIDAD EN CLUSTERS VoIP.
3.1 TCNI CAS PARA OBTENER ALTA DI SPONI BI LI DAD EN CLSTERS VOI P
En el siguiente apartado se mencionar algunas tcnicas aplicables para construccin de un clster VoIP. De esta manera dotaremos a nuestra infraestructura de red virtual de una de las caractersticas y requisitos imprescindibles que hoy en da a la hora de ofrecer servicios es fundamental como lo es la alta disponibilidad. Cada da que pasa resulta habitual encontrarnos con servicios que requerimos o que debemos proporcionar con una gran exigencia: rapidez, eficiencia, simplicidad, las 24 horas al da, los 7 das de la semana, todo el ao. Es entonces cuando consideramos que ese determinado servicio (base de datos, pgina web, centralita VoIP, almacenamiento) debe estar continuamente 41
disponible, lo que implica que debamos aplicar determinadas tcnicas tanto hardware como software para cumplir este objetivo.
3.1.1 Criterio de seleccin de la tcnica de alta disponibilidad
La tcnica a escoger deber cumplir con las siguientes caractersticas: Respaldar y garantizar los servicios de telefona IP. Mnimo tiempo de retraso al levantarse el servidor de respaldo. Mayor porcentaje de disponibilidad. Cabe aclarar que para el presente trabajo de tesis se ha propuesto crear un clster VoIP; por lo cual se ha tomado en cuenta aquellas tcnicas que nos permitan realizar este cometido.
3.1.2 Heartbeat
Heartbeat es un paquete de software que fue creado por LINUX-HA, funciona de forma similar al System V o init pero en vez de una sola mquina pasara a ejecutar los servicios en los nodos, basndose en que no le llegan respuestas estas se hacen por medio de ping y por pulsaciones del cable serie.
Esta tecnologa implementa heartbeats, cuya traduccin directa sera: latidos de corazn. Funciona enviando peridicamente un paquete, que si no llegara, indicara que un servidor no est disponible, por lo tanto se sabe que el servidor ha cado y se toman las medidas necesarias. 42
Dichos latidos se pueden enviar por una lnea serie, por UDP o por PPP/UDP. De hecho los desarrolladores de Heartbeat recomiendan el uso de puertos serie por varias razones, entre las que destacan que estn aislados de las tarjetas de red.
Tambin incluye toma de una direccin IP y un modelo de recursos, incluyendo grupos de recursos. Soporta mltiples direcciones IP y un modelo servidor primario/secundario. Se ha probado satisfactoriamente en varias aplicaciones, como son: servidores DNS, servidores proxy de cach, servidores web y servidores directores de LVS. El proyecto LVS recomienda Heartbeat para aumentar la disponibilidad de su solucin, pero no es parte de LVS.
En Linux-HA Heartbeat es un servicio de bajo nivel. Cuando un computadora se une al clster, se considera que computadora r se ha unido al canal de comunicaciones, por lo tanto late; cuando sale, implica que ha dejado el canal de comunicaciones.
Cuando una maquina deja de latir y se considera muerto, se hace una transicin en el clster. La mayora de los mensajes de manejo del clster que no son heartbeats se realizan durante estas transiciones. Los mensajes de Heartbeat se envan por todas las lneas de comunicacin a la vez, de esta manera, si una lnea de apoyo cae, se avisar de ese problema antes de que la lnea principal caiga y no haya una lnea secundaria para continuar el servicio.
Heartbeat tambin se preocupa por la seguridad, permitiendo firmar los paquetes con CRC de 32 bits, MD5 y SHA1. Esto puede evitar el desastre que podra provocarse si un nodo no miembro se enmascarase como nodo miembro del cluster. El problema es que el entorno donde se ejecuta 43
Heartbeat no debe parar nunca y con suerte ese entorno se mantendr comunicado y funcionando durante aos.
Hay varias operaciones de mantenimiento de seguridad que necesitan ser efectuadas en ese tiempo, como pueden ser cambio de claves y de protocolos de autentificacin. Heartbeat est preparado para esos cambios disponiendo de ficheros para la configuracin. Heartbeat tiene el problema, si no se dispone de una lnea dedicada, aunque sta sea una lnea serie, al tener un trfico que aunque pequeo es constante, suele dar muchas colisiones con otros trficos que puedan ir por la misma red. Por ejemplo, openMosix y Heartbeat en una misma red que no tenga gran ancho de banda no funcionan bien, sobre todo si hay bastantes nodos, pues los heartbeats se envan de cualquier nodo a cualquier nodo, por lo que podran llegar a ser un trfico voluminoso.
Figura III-1: Arquitectura Heartbeat. Fuente: Arquitecturas de clustering de alta disponibilidad y escalabilidad (linux virtual server).
3.1.2.1 STONITH
STONITH son la Siglas de Shoot The Other Node In The Head ( Pgale un Tiro en la Cabeza al otro Nodo). Es una tcnica usada por Heartbeat que se asegura de que un servidor supuestamente 44
muerto no interfiera con el funcionamiento del cluster, en caso de no implementarse bien esta tcnica, podra dar lugar a que el cluster no funcione. A grosso modo STONITH consiste en que el servidor secundario nota que el primario no funciona, y este le hara un DDOS al primario para asegurarse de que ha sido un falso positivo y tomara el nodo secundario el control.
3.1.2.2 FUNCIONAMIENTO
Segn Marcos Martnez Jimnez y Gabriel Bergs Pujol [ 8 ]:el funcionamiento de Heartbeat se basa en el envo y recepcin de seales enviadas por los demonios de Heartbeat que se ejecutan en ambas mquinas, a estas seales se les conocen como latidos. La diferencia entre el servidor maestro y el esclavo, radica en la prioridad que tienen para ofrecer un servicio. Aqu, el esclavo solo ofrecer el servicio cuando deje de escuchar los latidos del maestro durante periodo de tiempo determinado, pasado el cual se supondr que el servidor maestro dej de funcionar.
Una vez que el esclavo vuelva a escuchar los latidos del maestro, este tomar el control nuevamente, a menos que dentro de la configuracin de Heartbeat se haya colocado la directiva auto_failback en off. Esta directiva puesta en off, quiere decir que si la mquina que era maestro vuelve a funcionar, ya no retomar el control del servicio, sino se convertir en la nueva esclava. El maestro y esclavo pueden comunicarse por medio de dos interfaces, el puerto serial (RS-232) o las tarjetas Ethernet. Heartbeat implementa una serie de tipos de latidos:
8 Extrado de: Arquitecturas de clustering de alta disponibilidad y escalabilidad (linux virtual server), acade (lvs). [en lnea] 45
Bidirectional Serial Rings. UDP/IP Broadcast, UDP/IP Multicast. Pings especiales Heartbeat para routers.
Heartbeat es el encargado de inicializar o detener el servicio al cual se le quiere prestar en alta disponibilidad. Este servicio es prestado a travs del uso de una nica IP en ambas mquinas, que en realidad no es ms que la direccin IP Virtual (VIP). A esta VIP se le considera como un recurso. Aqu ambas mquinas, tanto la esclava como la maestra, tienen una direccin IP propia y tambin comparten la VIP. Cuando Heartbeat lanza el servicio a prestarse, se activa la VIP en esa mquina. Cuando se produce un fallo en la mquina que presta el servicio se le conoce como failover. Cuando el maestro vuelve a estar activo se le conoce como failback.
3.1.3 DUNDi
DUNDi (Distributed Universal Number Discovery) es un sistema de localizacin de gateways para el acceso a los servicios de telefona. Utiliza un esquema punto a punto y, a diferencia de ENUM que es estrictamente jerrquico por que se basa en DNS, DUNDi no requiere ninguna arquitectura de red en particular ni un esquema jerrquico cliente servidor.
En otras palabras DUNDI es capaz de consultar los contextos de otros equipos para encontrar una ruta hacia determinado nmero. Un contexto es una coleccin de extensiones. 46
DUNDi en realidad no realiza una llamada como tal, ya que no es un protocolo de sealizacin VoIP; ms bien el recibe y proporciona la informacin necesaria para poder contactar a los equipos independientemente del protocolo VoIP que sea usado.
DUNDi fue inventado por Mark Spencer, quien tambin desarroll Asterisk, ncleo de la telefona en Elastix, por lo tanto es de esperar que la integracin con este ultimo sea completamente transparente as como su compatibilidad impecable.
Para que DUNDi funcione se debe conocer al menos un peer quien a su vez, si no puede responder al requerimiento, puede delegar la consulta a un peer conocido por l, y as hasta que se encuentre a un peer que tenga una respuesta al nmero consultado (aunque este parmetro es configurable con TTL).
Un ejemplo tpico 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, dnde est el numero 456? la consulta se enviara directa o indirectamente a todos los servidores, y el servidor que tenga esa extensin responder algo como IAX2/usuario:clave@1.2.3.4/456.
Aunque cada equipo tenga asignado un rango de extensiones o una serie de nmeros, DUNDI resultar til, ya que no intentara comunicarse con el equipo si la extensin no esta creada, aunque este en su rango de extensiones.
47
3.1.3.1 Aplicaciones de DUNDi
Bsicamente, DUNDI nos permite crear una red P2P de centrales, donde cada una publica los nmeros de telfono de los que es responsable as como sus extensiones locales, nmeros para la que es la ruta de menor coste, etc.
Ejemplo tpico es el de la empresa multi-sede. Cada sede publica sus extensiones propias, de forma que el de centrales de la red pueda localizarlas. Esta consulta se enviara, directa o indirectamente, a todas las centrales de la red DUNDI. La central que tenga esa extensin responder algo como "tengo esa extensin, y la central que hizo la consulta utilizar esa informacin para realizar la llamada a travs de la lnea de datos a coste 0.
Otro ejemplo de uso. Supongamos dos sedes de la misma empresa en diferentes localizaciones, Riobamba y Quito, y un usuario de la sede Riobamba llama a un telfono de Quito. En el caso de que tengamos tarifa plana en las lneas telefnicas de Riobamba, esta llamada no tendr coste, pero y si no tenemos tarifa plana en todas las lneas?. DUNDI pregunta a todas las centrales de la red cual tiene como nmero local un nmero de Quito, la centrale de Quito responde "yo lo tengo" y la central de Riobamba, efecta la llamada a travs de las lneas telefnicas de Quito a precio de llamada local.
En el caso de que las sedes estn en diferentes pases. El ahorro ya pasa a ser muy importante. Aunque DUNDI, bsicamente solo pregunta "por donde puedo llamar", su aplicaciones son altisimas, y nos proporciona grandes ventajas en el presente trabajo de tesis. 48
El protocolo DUNDi utiliza por defecto el puerto 4520/UDP. Habr que abrirlos en los firewalls. Es independiente de IAX, es decir, la cadena de conexin devuelta en una consulta puede hacer referencia a cualquier tipo de canal (IAX2, SIP, H323, etc), aunque normalmente se usa el IAX2.
3.1.3.2 Clster VOIP con DUNDi
Para este trabajo de tesis, no se tendrn centrales en distintas redes, sino todas en la misma red y todas gestionando las mismas extensiones. De esta forma, se utilizar DUNDi para establecer la comunicacin entre ellas y puedan anunciarse, en este caso, no las extensiones que gestionan, ya que son las mismas, si no las extensiones que estn registradas en el momento de la llamada. Esto se debe a que hace uso de DNS SRV, por tanto, a la hora de asignarnos direccin IP, puede asignar diferentes direcciones por lo que los usuarios se encontrarn en centrales distintas.
Cuando un usuario llame a una extensin que gestione su misma central, no habr problema ya que la llamada se conoce como llamada local y sera directa. En caso de pertenecer a una central diferente, ser cuando se aplique la consulta DUNDi al resto de centrales para saber en cul se encuentra y poder gestionar la llamada entre ambas.
3.1.4 Definicin de parmetros para evaluacin.
Los parmetros que a continuacin se definen para realizar el estudio comparativo de las tcnicas de alta disponibilidad estn basados en los requerimientos del usuario final, los usuarios intermitentes, y segn el criterio de la autor de la tesis.
49
Tabla III.I : Determinacin de los criterios de Comparacin. Parmetros Concepto Configuracin Cada tcnica tiene su propia manera de estructurar sus procedimientos y la utilizacin de un determinado mecanismo. Soporte Criptografico Para asegurar la confidencialidad en el establecimiento de la llamada telefnica mediante el uso de una clave cifrada. Aprendizaje Una documentacin insuficiente o un soporte inadecuado al usuario pueden hacer que un usuario abandone o descarte el uso. Escalabilidad Es la propiedad deseable de una red que indica su habilidad para extender o hacerse ms grande sin perder calidad en los servicios ofrecidos, es decir nos da una idea del comportamiento del sistema cuando se incrementa el nmero de procesadores. Calidad de Servicio Es la capacidad de dar un buen servicio, es decir garantizar la realizacin de una llamada en un tiempo dado.
Los parmetros generales que se ha tomado en cuenta para desarrollar el estudio comparativo se dividen en variables que sern evaluadas de acuerdo a una tabla de ponderacin.
3.1.5 Ponderacin. Cada variable se evala de acuerdo a las siguientes posibles interpretaciones, a estas se les ha asignado un peso que va en un rango de 0 a 5 que se muestra en la tabla a continuacin.
Tabla III.II : Tabla de Ponderacin. Ponderacin Cualitativa Porcentaje (%) Cuantitativa Fcil Excelente Eficiente Cumple Totalmente >=80 y < =100 5 Medio Fcil Muy bueno Medio Eficiente Cumple >=60 y < 80 4 Normal Bueno Limitado Limitado >=40 y < 60 3 Medio difcil Regular Medio deficiente Casi no cumple >=20 y < 40 2 Difcil Malo Deficiente No cumple < 20 1 No Aplica No Aplica No Aplica No Aplica 0 0
50
A cada variable se la define y se establece la comparacin entre DUNDi y Heartbeat, los datos fueron obtenidos mediante la investigacin, pruebas realizadas y la experiencia que se ha adquirido al probar cada una de estas tcnicas.
Parmetro de Configuracin
En la siguiente tabla se define a cada una de las variables que se le ha considerado para el parmetro de configuracin. Tabla III.III : Variables del parmetro Configuracin. Variables Concepto Facilidad de instalacin La capacidad del producto del software para ser instalado en un ambiente especfico. Nivel grfico El poseer una interface grafica para la instalacin.
Facilidad de Instalacin
La instalacin de DUNDi se realiza a bajo nivel, mediante el uso de comandos propios de Linux, es por esa razn que es necesario tener un amplio conocimiento de los mismos, por lo tanto se califica como Normal. La instalacin de Heartbeat se realiza a bajo nivel al igual que la anterior, por la misma causa toma la misma calificacin como Normal.
Nivel Grfico
Gracias a la interface propia de Elastix 2.0, DUNDi puede ser manipulado desde dicha interface, esto facilita en parte la configuracin y monitoreo por esa razn tiene una calificacin de Bueno. 51
Heartbeat no tiene interface alguna, la configuracin y monitoreo siempre se realiza a bajo nivel, su calificacin es de Malo.
Tabla III.IV : Comparacin Variables del parmetro de Configuracin.
Configuracin Variables DUNDi HEARTBEAT Facilidad de instalacin Normal 3 Normal 3 Nivel grfico Bueno 3 Malo 1
Total 6 Total 4
Tomando el valor ms alto que es 6 corresponde al 60 % para el parmetro de configuracin cuando se utiliza DUNDi. Mientras que para Heartbeat se tiene un 40 %. Se aplica una regla de 3 para conocer los porcentajes en cada caso en particular.
Para DUNDi:
Para Heartbeat:
El proceso de instalacin para DUNDi es mucho ms alto que Heartbeat ya que para Heartbeat se necesita tener conocimientos ms avanzados.
52
Figura III-2: Grfico parmetro configuracin
En la Figura III-2, se observa que DUNDi posee los valores ms altos que Heartbeat sobretodo en el nivel grfico.
Soporte Criptogrfico
En la siguiente tabla se define a cada una de las variables que se le ha considerado para el parmetro Soporte Criptogrfico.
Tabla III.V : Variables del parmetro Soporte Criptogrfico. Variables Concepto Cifrado Los sistemas de clave simtrica utilizan una misma clave para cifrar y descifrar de forma que tanto el emisor como el receptor deben ponerse de acuerdo previamente en la clave a utilizar RSA Algoritmo de reduccin criptogrfico. MD5 Algoritmo asimtrico cifrador de bloques, SHA1 53
RSA DUNDi utiliza el algoritmo de cifrado RSA que es un sistema criptogrfico de clave pblica, se en el problema de la factorizacin de nmeros enteros, ser seguro mientras no se conozcan formas rpidas de descomponer un numero grande en producto de primos. La calificacin que se le atribuye es Bueno. Heartbeat no utiliza este algoritmo criptogrfico.
MD5 Heartbeat utiliza el algoritmo de cifrado MD5 que es un algoritmo de reduccin criptogrfico. A pesar de su amplia difusin actual, la sucesin de problemas de seguridad detectados, plantea una serie de dudas acerca de su uso en un futuro. Por lo tanto la calificacin que recibe es Bueno.
SHA1 Heartbeat utiliza el algoritmo de cifrado SHA1 es un sistema de funciones hash criptogrficas. Ha sido examinado muy de cerca por la comunidad criptogrfica pblica, y no se ha encontrado ningn ataque efectivo. Por lo cual la calificacin que toma es Excelente.
A continuacin se muestra la tabla con los pesos correspondientes a cada una de los algoritmos de encriptacin. Tabla III.VI : Variables del parmetro Soporte Criptogrfico.
Soporte Criptogrfico Variables DUNDi HEARTBEAT RSA Bueno 3 No aplica 0 MD5 No aplica 0 Bueno 3 SHA1 No aplica 0 Excelente 5
Total 3 Total 8 54
Tomando el mayor valor que es 8 se deduce que Heartbeat tiene mejor soporte criptogrfico ya que utiliza un algoritmo criptogrfico seguro.
Figura III-3: Grfico parmetro configuracin
Como se ve en la Figura III-3 SHA1 que es el sistema criptogrfico que utiliza Heartbeat supera a RSA y MD5.
Parmetro de Aprendizaje
En la siguiente tabla se define a cada una de las variables que se le ha considerado para el parmetro de Aprendizaje.
55
Tabla III.VII : Variables del parmetro Aprendizaje. Variables Concepto Documentacin Para un correcto desempeo debe existir en medios de consulta como Internet, manuales, tutoriales, ejemplos prcticos Soporte Debe existir ayuda en lnea, foros
Documentacin
Para la bsqueda de fuentes de informacin para DUNDi se suman sin filtrar 673.000 pginas en 0,54 segundos y la bsqueda para resultados en espaol 13.000 pginas en 0,58 segundos. La valoracin se realiza haciendo un promedio entre la informacin filtrada y no filtrada.
DUNDi
Para la bsqueda de fuentes de informacin para Heartbeat se suman sin filtrar 6.260.000 pginas en 0,54 segundos y la bsqueda para resultados en espaol 50.000 pginas en 0,21 segundos [9].
Heartbeat
9 http://www.google.com 20/12/2011 56
El valor ms alto es 3.155.000, el cual corresponde al 100 % de la informacin existente para Heartebeat, por lo tanto se hace una asignacin cumplimiento total, para determinar el valor de DUNDi se realiza una regla de 3.
DUNDi
Soporte
Para valorar esta variable se toma como dato la informacin obtenida al realizar una bsqueda en internet de los foros y ayudas para DUNDi y Heartbeat. La tabla que a continuacin se muestra contiene las direcciones y temas existentes en foros
Tabla III.VIII : Informacin acerca de foros y ayuda en lnea. FOROS Y AYUDA EN LNEA DUNDi Heartbeat Direccin Tema Direccin Tema http://www.elastix.org/index.php/en/componen t/kunena/53-trucos/10183-usando-dundi-en- elastix-o-en-un-asteriskfreepbx.html Usando DUNDi en Elastix http://www.alcancelibre.org/sta ticpages/index.php/como- cluster-heartbeat-centos Configurar Heartbeat http://www.ecualug.org/2008/09/14/blog/filipo k/usando_dundi_en_elastix_o_en_un_asteriskfr eepbx DUNDi http://www.linuxespanol.com/f topic23987.php Heartbeat y DRBD http://elajonjoli.org/node/11 Certificad o de Encriptaci n http://foro.powers.cl/viewtopic. php?f=1&t=230116 Heartbeat
http://www.openecuador.org/ modules/newbb/viewtopic.php ?topic_id=149&forum=6 Guia para configurar un cluster
Se toma el valor mximo de 6 que corresponde al 100 % y es de Heartbeat para conocer la valoracin porcentual de DUNDi se realiza una regla de 3. DUNDi
Parmetro de Escalabilidad
En la siguiente tabla se define a cada una de las variables que se le ha considerado para el parmetro de Escalabilidad. Tabla III.IX : Variables Parmetro Escalabilidad. Variables Concepto Carga Se refiere al incremento de nodos a red telefnica.
Carga El nuevo nodo que forme parte de la red con DUNDi se debe crear cada una de las extensiones existentes en el sistema es por eso que tiene una calificacin de Cumple, ya que se puede incrementar nuevos nodos pero esto tomara tiempo y recursos. Para Heartbeat el incremento de un nuevo nodo es ms simple ya que los datos se replicaran automticamente cuando sincronice con el servidor del cual se obtenga los datos.
Tabla III.X : Comparacin variables del parmetro Escalabilidad
Tomando el valor ms alto que es 5 esto equivale al 100% de Escalabilidad y corresponde a Heartbeat, para conocer el porcentaje de DUNDi realizamos una regla de 3.
DUNDi
A continuacin se muestra la grfica correspondiente a la variable carga.
Figura III-4: Grfico parmetro escalabilidad
Como se ve en la Figura III-4 Heartbeat supera a DUNDi en escalabilidad.
Parmetro Calidad de Servicio
En la siguiente tabla se define a cada una de las variables que se le ha considerado para el parmetro de Calidad de Servicio. 59
Tabla III.XI : Variables parmetro Calidad de Servicio. Variables Concepto Creacin de Extensiones Determina como se debe registrar las extensiones en los servidores que conforman el clster Autenticacin despus de cada del servicio Tiempo que demora en autentificarse una terminal despus de haber perdido el control el servidor activo. Puesta en marcha del servidor esclavo Determina cuanto tiempo demora en tomar el control el servidor esclavo.
Creacin de Extensiones
En DUNDi la creacin de las extensiones se realiza en cada uno de los nodos que conforman el clster; por lo tanto se le califica esta accin como deficiente. En cuanto a Heartbeat para registrar una nueva extensin, es necesario crearla en el nodo que est actuando como principal y automticamente ser replicada en el servidor secundario; por lo tanto se le califica como eficiente.
Autenticacin despus de cada del servicio
En DUNDi la autentificacin despus de la cada del servicio, no se realiza de forma automtica se necesita de una accin manual, por lo cual no aplica para ser evaluada. En Heartbeat la autentificacin es automtica transcurrido un tiempo, por lo tanto se lo califica como eficiente.
60
Puesta en marcha del servidor esclavo
En DUNDi los nodos que conforman el clster permanecen activos, cuando un nodo deja de estar activo se le asigna una nueva IP a todas las extensiones que se encontraba dando servicio dicho servidor, pero es necesario reiniciar las terminales para que se identifique cual es el nuevo servidor que les ofrecer el servicio. Por lo tanto se le califica como deficiente. En Heartbeat el servidor esclavo toma el control y las terminales lo reconocen automticamente. Por lo tanto se lo califica como Eficiente.
Tabla III.XII : Comparacin variables del parmetro Calidad de Servicio.
Calidad de Servicio Variables DUNDi HEARTBEAT Creacin de Extensiones Deficiente 1 Eficiente 5 Autenticacin despus de cada del servicio No aplica 0 Eficiente 5 Puesta en marcha del servidor esclavo Deficiente 1 Eficiente 5
Total 2 Total 15
Tomando el valor ms alto que es 15 corresponde al 100% de calidad de servicio y pertenece a Heartbeat. Para conocer el valor porcentual de DUNDi se aplica una regla de 3. DUNDi
A continuacin se muestra la grafica que corresponde a esta comparacin del parmetro calidad de servicio. 61
Figura III-5: Grfico parmetro calidad de servicio.
Como se observa en la Figura III-5 los resultados obtenidos muestran que Heartbeat supera con un 100 % sobre DUNDi que obtuvo apenas 13.33 % esto nos indica que la implementacin de la red de alta disponibilidad se lo realizara con Heartbeat.
CAPITULO IV IV. DISEO E IMPLEMENTACIN DE UNA RED DE ALTA DISPONIBILIDAD EN UN AMBIENTE DE PRUEBA.
MODELO DUNDI
4.1 ESQUEMA GENERAL
En el presente capitulo se dar a conocer todos los mdulos efectuados para la realizacin del presente trabajo de tesis.
En lo que se refiere a hardware, se ha hecho uso de varias mquinas para poder simular la red. Como se pretende crear un clster de centrales Asterisk, de momento basta con utilizar tres equipos, puesto que la red a implementar ser una red de pruebas y por otra parte se va a necesitar una mquina para los servidores DNS y DHCP. Finalmente, sern necesarios algunos terminales para realizar las pruebas de llamadas.
Se puede observar que el nmero el nmero de equipos es elevado y puede no ser fcil disponer de tal cantidad, por lo que se recomienda hacer uso del software VMWare Worstation versin 7.0. Este programa nos permite crear tantas mquinas virtuales como nos permita el equipo donde se encuentra instalado. Este programa se instalar en un equipo porttil AMD Turion X2 64 de doble ncleo a 2,1 GHz y 4GB de memoria RAM,. El sistema operativo que correr en dicha mquina ser Windows 7 Ultimate. Se ha utilizado dos mquinas para las centrales, dos ms para los servidores DNS con sistema centOS 5.0 y unterminal, por lo que se ha creado cuatro mquinas virtuales. Las caractersticas fsicas de estas mquinas pueden variar debido a que dependen, en parte, al hardware disponible en el equipo fsico donde se encuentran instaladas, por lo que por ejemplo, la memoria RAM, puede variar de unas a otras.
Es muy importante comentar en este punto que a las mquinas virtuales, se puede cargar y editar archivos via ftp, haciendo uso del software Filezilla client. Para facilitar la digitacin de comandos y lneas de cdigo la configuracin de stas se har de forma remota va SSH con Putty.
Las centrales, como cabe de esperar, usarn el software Elastix , en este caso la versin 2.0 y asterisk-addons-1.6.1.1 para el uso de bases de datos MySQL. Para consultar su instalacin, puede consultarse los ANEXOS. Los servidores DNS utilizarn el software BIND 9.0, como ya se coment en apartados anteriores, esto sobre la plataforma Linux en la distribucin de centOS 5.0.
64
4.2 Descripcin de los mdulos de prueba desarrollados
4.2.1 Terminales
Los terminales sern los encargados de permitirnos realizar las llamadas. Podrn ser telfonos fsicos, conocidos como hardphone, se dispone de Telfonos IP CISCO y Grandstream o en su defecto programas informticos que cumplen la misma funcin, llamados softphone (por ejemplo X-Lite, Zoiper). Un requisito que deben cumplir estos telfonos para que funcionen en la red diseada es que tienen que tener soporte para DNS SRV y el protocolo SIP esto es elemental para los terminales.
A continuacin se explicar de forma puntual las caractersticas y configuracin del Telfono IP CISCO 7912 y Grandstream.
4.2.2 Telfonos IP
La configuracin de los telfonos IP CISCO y GRANDSTREAM se mostrar en el Anexo 2.
4.2.3 Servidor DNS
Se ha visto la necesidad de instalar un servidor DNS primario conocido tambin como Maestro y uno secundario o esclavo. Esto ya que como se requiere que exista Alta disponibilidad, en el caso 65
de que nuestro servidor DNS dejase de funcionar el esclavo empezara a actuar, de tal manera que la red no deje de trabajar.
A continuacin se explicar de forma concreta la funcionalidad que el servidor DNS presentar en la red de alta disponibilidad.
La necesidad de un servidor DNS en la presente tesis tiene como objeto la resolucin de una direccin IP, no se har el uso que generalmente se da a un servidor de resolucin de nombres, de forma explcita para la resolucin de nombres. Su uso ser DNS SRV, el mismo que mantienen estabilidad y tambin abre la posibilidad para utilizar tu propio dominio, sin importar el dominio del servicio del SIP que ests utilizando.
Los expedientes del recurso del DNS SRV indican cmo encontrar los servicios para los varios protocolos. ste describe a uno de los registros de DNS (conocido como SeRVice en ingls) que nos permite anunciar los servicios que ofrece nuestro dominio, en nuestro caso SIP.
Descrita la explicacin anterior, se puede afirmar que el servidor DNS es el encargado de suministrar las direcciones IPs de las centrales a todos aquellos terminales sean estos softphones o telfonos IP que deseen registrarse y de esta manera establecer la conexin a la red telefnica.
De tal manera que como es ste quien gestiona las direcciones, se puede adems conseguir fcilmente un balanceo de carga, es decir, podemos decidir a qu central se le asignar mayor carga de procesos a la hora de recibir registros, ya sea, por ejemplo, porque tenga mayor capacidad de procesamiento o porque nos interese tener liberada una de las centrales por consumo de recursos. 66
Para realizar la configuracin del servidor DNS se usar BIND (Berkeley Internet Name Domain) el ms comn en internet sobre sistemas Unix, en nuestro caso montado sobre una plataforma Centos.
Para realizar el trabajo de forma grafica, se ha usado una herramienta de configuracin de sistemas accesible va web usada tambin sobre GNU/Linux y otros sistemas Unix. Webmin est escrito en Perl y se pueden configurar aspectos internos de muchos sistemas operativos, como usuarios, servicios, archivos de configuracin, entre otroa, as como configurar modificar y controlar muchas aplicaciones libres, como el servidor DNS, DHCP, MySQL entre otros. En el Anexo 3 se explica de forma ms detallada la configuracin del servidor DNS y DN SRV.
4.2.4 Base de Datos MySQL
Se ha desarrollado una Base de Datos sobre MySQL, ya que un requerimiento importante es la creacin de nuevas extensiones. Dado que en cualquier momento el administrador, se ver en la necesidad de crear una nueva extensin. Esto se logra haciendo uso la tecnologa Realtime.
En este modulo se explicar todo a cerca de la aplicacin basado en RealTime. Esta tecnologa permite realizar modificaciones en la configuracin de la central Elastix basada en Asterisk sin necesidad de recargarlo nuevamente. Esto es posible realizar gracias a que ciertos mdulos permiten ser configurados desde una Base de Datos.
La Base de Datos se ha creado en cada una de las centrales esto es una gran ventaja ya que en el caso de que una de las centrales pare sus procesos, cualquier otra central tenga la capacidad de 67
tomarse a cargo las extensiones que esta gestiona. A continuacin se explicar la configuracin para Asterisk utilizada para Realtime.
4.2.5 Asterisk Realtime
Se ha implementado realtime, ya que en el momento de realizar modificaciones, crear extensiones, etc. No haya necesidad de recargar Asterisk. En primer lugar se indicar la forma de instalar el CDR en una base de datos que se denomina Asterisk. Para esto se ha instalado MySQL en las centrales Asterisk y las libreras libmysqlclient15-dev y libmysqlclient15off para facilitar la instalacin se us la herramienta Webmin. Se explica de manera ms detalla en el Anexo 4.
4.3 DUNDi
A este punto se ve necesario explicar el por qu se ha optado por la tecnologa DUNDi, este un tecnologa diseada por el creador de Asterisk Mark Spencer. Su objetivo en un principio era crear sistemas distribuidos de Asterisk en una red peer-to-peer, donde los clientes y servidores no cumplen roles fijos, lo que realmente se trat es tener centralitas Asterisk es distintos puntos de la red y conseguir que los usuarios de unas y otras se llamasen entre s. En el presente trabajo de investigacin, las centrales telefnicas son nodos que forman un clster pero que gestionan diferentes extensiones en un momento dado, cuando esto sucede DUNDi se encarga de establecer la llamada entre distintas centrales, de manera segura, y haciendo uso la encriptacin RSA. 68
Elastix est basada en Asterisk y como ya sabemos, es una central de telefona que permite el uso de la tecnologa VoIP, siendo Asterisk la plataforma actual ms extendida en este campo. En este apartado se explicar cmo deben ser configuradas las centrales para su correcto funcionamiento.
4.3.1 Configuracin
En la siguiente configuracin de DUNDi se demuestra cmo se hace la distribucin del plan de marcado en 4 equipos con la mencionada tecnologa, adems se puede afirmar que de esta manera nuestro sistema se convierte totalmente escalable, as que eso es lo que se har continuacin.
4.3.2 Ambiente de prueba Escenario Se configurarn cuatro equipos con los siguientes datos, cada uno de estos datos pertenecen a las cuatro centrales o nodos del clster respectivamente.
Tabla IV.XIII : Direcciones IP y MAC de las centrales. Nombre de equipo Direccin IP MAC pc1.telefonicanet.com 172.30.124.201 00:0C:29:DA:73:F8 pc2.telefonicanet.com 172.30.124.202 00:0C:29:42:02:00 pc3.telefonicanet.com 172.30.124.203 00:0C:29:76:5A:B5 pc4.telefonicanet.com 172.30.124.204 00:0C:29:18:E2:45
69
dundi.conf
Este es el archivo es donde se especifica las caractersticas propias de la central y se da a conocer a las dems centrales. A continuacin se generar este archivo desde el principio, seccin por seccin:
Seccin [general] En esta seccin del archivo se define su propia identificacin en la nube DUNDi, as como las opciones globales, tambin se ha rellenado los campos con los datos reales de los equipos (MAC, etc.):
Para pc1.telefonicanet.com:
Los archivos completos de la configuracin del archivo dundi.conf se presentan en el (Anexo 5) [general] department=CENTRAL01 organization=Cisco locality=Riobamba stateprov=Chimborazo country=EC email=info@telefonicanet.com phone=+593-0000000 ; Aqui podemos definir en que red va a escuchar dundi bindaddr=0.0.0.0 ; El puerto en el que va a escuchar, por defecto 4520 port=4520 ; Aqui nos identificamos con nuestra MAC address entityid= 00:0C:29:DA:73:F8 ; El numero de consultas que har DUNDI hasta alcanzar una extensin ttl=32 ; Finaliza las conexiones fallidas autokill=yes
70
Seccin [mappings]
En esta seccin lo que se ha hecho es definir nuestra respuesta a una consulta hacia determinado nmero que tengamos localmente. Desde esta etiqueta empieza el mapeo de los contextos DUNDi con los contextos presentes en el servidor Asterisk. La sintaxis para definir los contextos es:
dundi_context: El contexto DUNDi que se quiere compartir con los dems nodos de la red DUNDi. local_context: El contexto local definido en el plan de llamadas donde se configuran las rutas o extensiones que se quieren compartir. weight: El peso que damos a las rutas que compartimos. Si son extensiones locales se pone 0, si son rutas por la cuales no tenemos una conexin directa o de alta calidad ponemos un nmero ms alto. Al momento de hacer una solicitud si para el mismo nmero requerido existen distintas rutas, se escoger la ruta con menor peso. tech: Protocolo usado para la conexin entre servidores Asterisk (se usar IAX2) dest: Cuando se hace una solicitud desde el servidor B y se encuentra una ruta en el Servidor A, el Servidor A usar esta destinacin para recibir la llamada. Simplificando: se crea un user en el iax.conf del servidor Asterisk A y dest representa los paramentos para conectarse a ese user y a travs de la conexin recibir las llamadas del servidor B [mappings] ; dundi_context => local_context,weight,tech,dest[,options]] 71
options: Son las distintas opciones que se pueden aadir por cada contexto DUNDi: nounsolicited Llamadas de cualquier tipo que no sean solicitadas no son permitidas en esta ruta nocomunsolicit Llamadas comerciales no solicitadas no son permitidas en esta ruta residential El numero es de una residencia commercial El numero es de una empresa mobile El numero es un celular nopartial No se harn bsquedas por nmeros que no sean completos
Este contexto se comparte a otros peers, es decir a las Centrales de Telefona IP adyacentes. La ruta definida para las centrales ser:
Los valores de ${NUMBER} y ${SECRET} se reemplazaran automticamente, segn el nmero que se consulte y la clave aleatoria que se haya generado en ese momento.
Peers Para finalizar con la configuracin del archivo dundi.conf se definen las centrales Asterisk con las se va a tener una conexin directa. AA:BB:CC:11:22:33: MAC address de la tarjeta de red de Servidor Asterisk B con el que se crea la conexin [mappings] priv => exten_SIP,0,IAX2,dundi:${SECRET}@192.168.137.161/${NUMBER},nopartial
72
model: Puede ser: inbound: recibe solamente solicitudes. outbound: solo efecta solicitudes pero no las recibe. symmetric: recibe y efecta solicitudes. host: direccion IP o nombre de dominio del servidor Asterisk B. inkey: clave RSA usada para autenticarse con el servidor Asterisk B. outkey: clave RSA usada por el Servidor Asterisk B para autenticarse con el Servidor Asterisk A. include: incluye esta conexin para todas las solicitudes efectuadas en el Servidor Asterisk A. permit: se definen los contextos DUNDi a los que tendr acceso este nodo. qualify: se controlar peridicamente que la conexin con el nodo est activa.
A continuacin se va a definir los PEERS que consultaran y sern consultados (con la opcin symmetric), esto lo realizamos as: Para pc1.telefonicanet.com: 73
; Identificamos al servidor 2 (CENTRAL02) por su entityid [00:0C:29:42:02:00] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL02 host=172.30.124.202 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary ; Identificamos al servidor 3 (CENTRAL03) por su entityid [00:0C:29:76:5A:B5] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL03 host=172.30.124.203 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary ; Identificamos al servidor 4 (CENTRAL04) por su entityid [00:0C:29:18:E2:45] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL04 host=172.30.124.204 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary
74
iax_custom.conf Es el momento en el que se puede aadir el usuario dundi al archivo iax_custom.conf. Aqu se procede a definir la configuracin de la troncal; como DUNDI va a hacer todo el trabajo de enviar la cadena exacta de como contactarlos solo creamos un usuario que recibe las llamadas autenticadas de la nube DUNDi. Se aaden las siguientes lneas. En pc1.telefonicanet.com, en pc2.telefonicanet.com, en pc3.telefonicanet.com y en pc4.telefonicanet.com:
Importante definir el parmetro context con el valor del contexto (ext_DUNDi) que se ha definido en nuestro plan de marcado.
sip_general_additional.conf
Este archivo contiene la configuracin por defecto de todos los usuarios y "peers". Se encuentra anexado en el sip.conf normalmente es donde se configuran los usuarios sip locales, es decir, las extensiones que gestionara la centralita. Es por esta razn que hay que considerar ciertos puntos [dundi] type=user context=ext_DUNDi dbsecret=dundi/secret ; Podemos restringir ciertos codecs para mejorar la calidad ; de voz, o dar prioridad al ancho de banda (con gsm o g729) disallow=all allow=ulaw allow=alaw allow=gsm
75
interesantes de configuracin en este fichero, ya que est vinculado estrechamente con el protocolo SIP. Para esto se tomar en cuenta ciertos detalles importantes en la configuracin.
Aqu se indicar la configuracin basada en DNS SRV, DNS es una forma de configurar una direccin lgica para que pueda ser resuelta. Esto permite que las llamadas sean enviadas a diferentes lugares sin necesidad de cambiar la direccin lgica. Usando el DNS SRV se ganan las ventajas del DNS mientras que deshabilitndolo no es posible enrutar llamadas en base a nombre de dominios. Conviene tenerlo activado, por tanto se pone la directiva:
Con esto Asterisk podr resolver el controlador de protocolo SIP para un dominio a travs de los registros DNS SRV y el servidor SIP confirmar que el URI SIP existe realmente en la central y enviar la solicitud. Esto har que Asterisk se comporte de una manera ms unificada.
sip_custom.conf
Al utilizar DUNDi, se marca el objetivo de anunciar slo los usuarios registrados en la base de datos de nuestra central, se implantar la siguiente sentencia.
sipregistration=ext_local_SIP
srvlookup=yes
76
Esta sentencia crear un contexto con nombre ext_local_SIP y crear una entrada de tipo Noop() por cada extensin que se registre esto servir principalmente para anunciar en nuestra red DUNDi que ese usuario est registrado en la centralita y que por tanto puede gestionar la llamada. De la igual forma, cuando dicho usuario se desconecte de la central, se eliminar la presente entrada del contexto.
extensions.conf
Por ltimo se configura el archivo extensions.conf, este contiene el plan de llamadas o Dialplan. Para lograr la integracin con la base de Datos en Realtime debemos crear el contexto "[internal]" que es el contexto que se usa para las extensiones. Teniendo en cuenta que cuando un nmero no es encontrado en el plan de marcado local se usa el contexto [lookup_to_DUNDi], y la configuracin debe ser exactamente la misma en los cuatro servidores: En el archivo extensions.conf, aadimos los siguientes contextos:
Aqu definimos los contextos personalizados para que DUNDI mapee nuestra extensiones, as como una macro para hacer las bsquedas en otros equipos (lo que evita loops) y la sentencia para redirigir las llamadas (switch). [ext_DUNDi] exten => _X.,1,Goto(ext_local_SIP,${EXTEN},1) [context_internal] include => lookup_to_DUNDi include => ext_local_SIP
77
Certificados de encriptacin
DUNDi usa certificados de encriptacin RSA para compartir los planes de marcado, adems por que las respuestas a una consulta incluyen las claves de las troncales (aunque es dinmico).
Usaremos la misma clave para la comunicacin entre todos los servidores, as que el primer paso es generar los certificados de encriptacin uno de los equipos (en este ejemplo en SRV01):
Ahora necesitamos compartir los certificados entre los dos servidores; esto es para que cada uno pueda des-encriptar al otro.
Aplicar la configuracin
Para que los cambios se hagan efectivos podemos ejecutar el comando:
[lookup_to_DUNDi] switch => DUNDi/priv [ext_local_SIP] ; Esta es la contexto que llamamos desde el contexto [lookup_to_DUNDi] ; Tambien evita que hayan loops en las consultas dundi. ;switch => Realtime/sipfriends exten => _X.,1,Dial(SIP/${EXTEN}) exten => _X.,2,Hangup
# cd /var/lib/asterisk/keys astgenkey -n SERVERS-DUNDI 78
O
Ahora cada extensin que creemos en Asterisk con Realtime se aadir al contexto [ext_SIP] el cual est incluido en extensions.conf que va a usar DUNDi para indicar que extensiones tenemos localmente.
Si nosotros tenemos la extensin responderemos con los datos para la comunicacin hacia esa extensin; esos datos a su vez los interpreta el servidor que est preguntando y usa la funcin switch que pusimos en el archivo extensions.conf para comunicarse con la extensin local.
4.4 Pruebas del clster de Alta Disponibilidad con DUNDi
Para probar la configuracin establecida para el clster virtual de alta disponibilidad se ha considerado a bien analizar el comportamiento del mismo ante tres sucesos diferentes que provocan la puesta en marcha de registros de extensiones en los diferentes nodos virtuales del clster : apagado de un nodo activo, cada del servicio Asterisk y saturacin de un nodo.
4.4.1 Escenario 1. Apagado del nodo activo En este suceso, con el apagado del nodo activo en el que se encuentran actualmente registrado un grupo de extensiones en ejecucin podemos simular algunas situaciones reales como la prdida de # amportal restart # Service asterisk restart 79
suministro elctrico, dao fsico en el servidor en el que tenemos alojado ciertos clientes o simplemente un apagado del sistema forzado por motivos fundados en operaciones de mantenimiento (para instalacin o actualizacin de software adicional, reparar o sustituir algn elemento hardware del servidor, etc.). A continuacin se ve paso a paso como ha sido realizada esta prueba. 1. Puesta en marcha de los dominios o nodos. Ingresamos los datos del login,
2. Comprobamos que efectivamente el servicio Asterisk han sido iniciados de forma correcta en cada nodo.
En el caso de la direccin IP lo hacemos ejecutando el comando ifconfig y observando que efectivamente el alias eth0:0 con la direccin 192.168.137.161 ha sido activada. 3. Ingresamos al modo CLI de Asterisk ejecutando la siguiente lnea,
Esto para entrar a la consola y si se quiere ms detalle de lo que est pasando agreguenle v, mientras ms v, mas verbosidad habr.
4. Se procede a registrar los softphone en cada servidor, se ha utilizado X-Lite, a continuacin se muestra el proceso de registro con el mencionado softphone. 80
Damos clic derecho sobre la pantalla, y presionamos configuracin de cuentas SIP SIP Account Settings en ingles.
Figura IV-6: Softphone X-lite. Ingresados los datos de la cuenta se registrar en la central a la cual le asigne el servicio DNS dada por el registro DNS SVR.
Figura IV-7: Registro de cuenta en el Softphone X-lite.
5. Transcurrido el tiempo del registro de extensiones en el presente nodo, se puede observar como se ha registrado.
81
Por medio de la consola nos damos cuenta que la extensin 1851 fue registrada en el nodo que tiene como hostname pc2.
Esto denota que se le fue asignada una extensin al nodo pc2 del cluster VoIP. 6. Procedemos con el apagado del nodo activo (pc2) y posterior comprobacin del traslado de los servicios. Para apagarlo simplemente ejecutamos el comando poweroff, simulando as las diferentes situaciones reales comentadas anteriormente.
Al ejecutar el apagado del nodo pc2 reconoce que ste ha dejado de estar disponible (fallo de uno de los nodos del clster) y automticamente los servicies DNS asignan una nueva direccin IP a esa terminal para que la misma vuelva a registrarse despus de un Reboot.
Se puede decir entonces que la tecnologa DUNDi a este punto tiene deficiencia al no poder establecer la comunicacin entre las terminales despus de apagar un nodo del cluster, a menos que se conecte y desconecte los softphone o en el caso de los telfonos IP se los reinicie.
A continuacin el tiempo de asignacin de la nueva IP.
82
Tabla IV.XIV : Tiempo de Asignacin de una nueva direccin IP. Prueba # Tiempo(seg) 1 97,63 2 84,9 3 84,03 4 86,12 5 88,72 6 84,35 7 84,93 8 85,49 9 87,51 10 84,75 11 88,88 12 82,17 Promedio 86,62
La siguiente figura nos muestra de forma grafica el tiempo que demora en ser asignada una nueva IP a una terminal despus de apagar el nodo activo, se tomo datos de diferentes pruebas.
Figura IV-8: Grafico de la Tabla IV.XIV .
83
4.4.2 Escenario 2. Cada del servicio
En esta segunda prueba vamos a provocar la cada del servicio Asterisk y observar cmo reacciona el sistema de red ante este evento dependiendo. El inicio de la prueba es exactamente igual que en el caso anterior, poniendo en marcha los dos nodos pc1 y pc2 que forman el cluster VoIP. De igual manera, el grupo de extensiones son registradas e iniciadas con xito. Con la deficiencia de volver a registrar manualmente las extensiones en los softphone y en el caso de los telfonos IP conectar y desconectar el cable de red o un Reboot que permite la comunicacin en cada punto.
Tabla IV.XV : Tiempo de Asignacin de una nueva direccin IP. Prueba # Tiempo(seg) 1 86,4 2 79,9 3 81,56 4 78,23 5 85,05 6 75,45 7 80,43 8 78,69 9 80,58 10 82,28 11 89,24 12 77,39 Promedio 81,27
84
La siguiente figura nos muestra de forma grafica el tiempo que demora en ser asignada una nueva IP a una terminal despus de la cada del servicio, se tomo datos de diferentes pruebas y se tiene un tiempo de 81,27 segundos para asignar un nuevo nodo a la terminal.
Figura IV-9: Grfico de la Tabla IV.XV .
4.4.3 Interpretacin del Escenario 1 y 2
Despus de las pruebas realizadas se puede decir que la tecnologa DUNDi, tiene dificultad al momento de la autentificacin despus de la cada del servicio en alguno de los nodos del cluster, esto dificulta la disponibilidad del servicio, es por eso que a continuacin se muestra un nuevo modelo donde se utilizar otra tcnica como es Heartbeat para solventar las deficiencia que nos da DUNDi.
85
MODELO HEARTBEAT
4.5 ESQUEMA GENERAL Despus de haber desarrollado diversos conceptos que sern necesarios para el modelo a disear, necesitamos conocer qu componentes tiene este modelo. 4.5.1 Componentes
Terminales Este componente es el encargado de representar a los clientes que en este caso sern los softphone o telfonos IP.
Figura IV-10: Terminales (Softphone y Telfonos IP) .
Servidores DNS y DHCP El primer componente ser el encargado de resolver el servidor que tenga el rol principal y el segundo componente ser el encargado de asignar una direccin IP a los terminales.
Figura IV-11: Servidor DNS . 86
Centrales telefnicas Asterisk Este componente ser el encargado de representar a los servidores reales, es decir, a los Servidores donde se encuentran las centrales telefnicas.
Figura IV-12: Servidor Asterisk .
Red Ethernet El siguiente componente ser el encargado de representar el tipo de enlace y/o tecnologa de red a utilizar, es decir, Ethernet.
Figura IV-13: Red Ethernet .
4.5.2 Diseo de la Arquitectura del Clster. La arquitectura del clster propuesta, es una arquitectura de dos capas, las cuales separaran a los servidor DNS, servidor DHCP y servidores Asterisk , brindando alta disponibilidad. Estas capas son:
87
Capa 1: Servidores DNS Y DHCP
La primera capa es la destinada a los servidores DNS y DHCP. En esta capa habr dos servidores brindando el mismo servicio en distinto tiempo, dependiendo del rol que tenga, es decir si el servidor mster tiene algn fallo inmediatamente el servidor esclavo toma el control. Bsicamente esta capa se encarga de mostrar al clster como una sola maquina al resto de terminales. TERMINALES Capa 1: Servidor DNS Servidor DHCP Master Esclavo 192.168.137.1 192.168.137.2 `Softphone,Telfonos IP
Figura IV-14: Capa 1 (Modelo Heartbeat) .
Capa 2: Servidores Asterisk
La segunda capa es la destinada a los servidores Asterisk. En esta capa se utilizar una configuracin Activa / Pasiva. Esto brindar alta disponibilidad. Aqu tendremos dos Servidores Asterisk, en los cuales uno ser el principal o activo y el segundo ser el secundario o pasivo. En el servidor activo (o principal) es al cual se acceder. 88
El servidor pasivo (o de respaldo) replicar todos los datos del servidor principal. Cuando el servidor principal falle, el servidor de respaldo tomar el control, siendo totalmente transparente para los terminales. Cuando el servidor principal se recupere, este sincronizar sus datos con el servidor que se ha vuelto el activo.
En cuanto a la replicacin de los datos, para mantener los datos sincronizados de los servidores principal a los secundarios, se har uso de DRBD que se adapta al modelo de clster Activo / Pasivo.
Como sabemos, DRBD es un dispositivo de bloque para almacenamiento replicado, donde el servidor Activo y/o principal ser en el cual se pueden escribir los datos, y en el Servidor Pasivo o Secundario se replicarn todos los datos escritos en el principal. La replicacin se da por cada recurso de DRBD. Este modelo servir tanto para estos Servidores, los cuales podrn tener varios recursos de DRBD almacenando diferentes tipos de datos.
Pero, para que el servidor de respaldo pueda tomar el control cuando ocurra un fallo en el servidor principal, necesitamos de Heartbeat. Aqu, Heartbeat se encargar de monitorear ambos servidores para detectar fallos y as poder pasar el control del Servidor Activo al Servidor de Respaldo cuando ocurra un fallo. Heartbeat tambin se encargar de ejecutar DRBD, Asterisk y dems servicios segn corresponda, en el servidor que asume el control.
Un esquema de esta capa lo podemos ver a continuacin: 89
TERMINALES Servidores Asterisk Centrales Telefnicas Master Esclavo 192.168.137.101 192.168.137.102 Softphone,Telfonos IP Capa 1 Servidores DNS y DHCP Capa 2: Asterisk Asterisk Heartbeat DRBD
Figura IV-15: Capa 2 (Modelo Heartbeat) .
Pero la replicacin de datos, al ser por medio de la red, puede crear un gran trfico en la red y esto podra aumentar el consumo de ancho de banda, lo cual causara que haya mucha latencia. Esto afectar el correcto funcionamiento de la red y de los dems servicios que se encuentran trabajando, como la transferencia de archivos.
Para solucionar esto, es necesario conectar directamente tanto ambos Servidores. Es decir, se tiene que hacer un enlace punto a punto entre los Servidores Asterisk. Esta solucin har posible que la replicacin de datos se haga solo entre esos dos servidores y no utilice el ancho de banda de toda la red, sino utilizar el enlace punto a punto por el cual estn conectados. Esto requerir de una tarjeta de red adicional.
90
En realidad no es necesario tener un grupo separado de servidores. Es decir, podramos brindar ambos servicios, de archivos y Asterisk, en el mismo par de servidores. Esto es posible si el hardware en el que se implementan es muy potente y puede resistir toda esa carga, pero es recomendable tener servidores separados para brindar cada servicio.
Por motivos demostrativos se utilizar este modelo, donde solo un par de servidores brindar ambos servicios, el Servidor de Archivos y Asterisk. Aqu, cada servicio utilizar un recurso de DRBD. Es decir, NFS utilizar un recurso de DRBD y Asterisk utilizar otro recurso de DRBD, que pueden ser tanto una particin en el disco duro, como otro disco duro.
Esquema
Ahora que ya hemos visto todas las capas del modelo, tenemos que ver cmo es que todos los servidores se comunican, para ser totalmente transparentes para los clientes. Es decir, debemos saber cmo es que cada grupo de servidores se van a identificar en la red y para que cada grupo aparezca ser como un solo servidor frente a los clientes.
Para hacer posible que los clientes vean a todo el modelo como si fuese un solo servidor, se hace necesaria la utilizacin de IPs Virtuales (VIPs). Aqu, solo se necesitarn una VIP por todo el conjunto de servidores de las Capas 1 y 2.
Aqu, cada servidor tendr una direccin IP propia, que debern estar en la misma subred. En las capas 1 y 2, es decir en los balanceadores y los servidores reales, se compartir una IP Virtual. A esta IP la llamamos la VIP. 91
En la capa de almacenamiento, tambin cada servidor de archivos tendr su propia direccin IP, pero a su vez. Esto lo podemos apreciar en la siguiente imagen:
Capa 2: Capa 1: Terminales 192.168.137.x 192.168.137.x Servidor DNS Servidor DHCP VIP=192.168.137.100 Heartbeat DRBD 192.168.137.101 192.168.137.102 192.168.137.1 Centrales Telefnicas 192.168.137.x Asterisk Asterisk Softphone Telfono IP Telfono IP 192.168.137.2 CentOS
Figura IV-16: Esquema (Modelo Heartbeat) . Esto hace posible que el clster sea visto como un nico nodo por cada cliente de tal forma que solo se pueda acceder, por medio de la VIP, al servicio que implementa el clster.
Es decir, aqu los clientes ingresarn a la central por un nombre de dominio, que resolver el servidor DNS cada vez que el nombre de dominio sea solicitado, como por ejemplo, el dominio 92
www.telefonicanet.com puede resolver la IP de la central con rol principal por ejemplo 192.168.137.101 192.168.137.102
4.5.3 Estimacin de Costos de la Red
La informacin necesaria para elaborar las tablas con la estimacin de costos fueron obtenidas casi en su totalidad de la empresa TELET de la ciudad de Ambato, debido a la facilidad que este medio proporciona para acceder a los productos que, cumpliendo con las caractersticas requeridas, satisfagan las diferentes necesidades de los usuarios, quienes pueden decidir de esta gama de productos, considerando la funcionalidad del equipo y el precio.
Los principales elementos a considerar en la estimacin de costos son:
Compra de equipo Instalacin Calibracin y puesta en marcha
Costos De Equipos Y Accesorios
De acuerdo al sistema de red establecido para el sistema de telefona IP y de sus requerimientos se dimensionan los siguientes equipos y sus caractersticas que posee el servidor para garantizar un buen servicio, para llevar a cabo la implementacin.
Para justificar el precio de configuracin asignado en la proforma, se realiza el desglose de los costos asociados a la implementacin del sistema de telefona IP.
La Tabla presenta el costo total para la futura implementacin, este costo es un precio referencial que puede variar, pero muestra una idea del capital que se necesita. 94
Tabla IV.XVIII : Costo total del Proyecto. DESCRIPCION PRECIO TOTAL(USD) Equipos 4536 Instalacin, calibracin y puesta en marcha 850 SUBTOTAL 5386
Como resultado se obtiene el costo total de 5.386 dlares, para llevar a cabo la implementacin del prototipo de telefona IP presentado para la empresa descrita en el Captulo I.
CAPITULO V V. EVALUACION DEL MODELO DE ALTA DISPONIBILIDAD.
5.1 Evaluando: Centrales Telefnicas 5.1.1 Escenario 1: Apagando Normalmente la Central con rol principal Esta prueba consisti en apagar y/o reiniciar normalmente el servidor que est teniendo un rol principal dentro de la Capa 2. Aqu, al apagar el servidor maestro, el servidor secundario tendr que entrar en accin y volverse el nuevo principal, tomando el control del servicio. En esta prueba, se tom el tiempo, en segundos, que el servidor de respaldo demor en tomar el control total del servicio. Esta prueba nos sirvi para evaluar el nivel de disponibilidad del servicio en la Capa 2. El resultado de las pruebas se encuentra a continuacin:
La siguiente figura nos muestra de forma grafica el tiempo que demora en tomar el control el servidor esclavo o secundario y lo hace en un tiempo promedio de 48,75 segundos.
Figura V-17: Grfico Tabla V.XIX.
97
Tomando el control Normalmente el servidor maestro.
Tabla V.XX : Tiempo de toma de control por el servidor principal. Prueba # Resultado 1 59,37 2 49,09 3 47,93 4 50,45 5 53,56 6 48,95 7 49,46 8 50,45 9 52,23 10 49,43 11 48,12 12 50,04 Promedio 50,75
La siguiente figura nos muestra de forma grafica el tiempo que demora en tomar el control nuevamente el servidor principal y lo hace en un tiempo promedio de 50,75 segundos.
Figura V-18: Grfico Tabla V.XX. 98
Tiempo de autenticacin de los terminales al servidor
Tabla V.XXI : Tiempo de autentificacin de las Terminales. Prueba # Resultado 1 38,26 2 35,81 3 36,1 4 35,67 5 35,16 6 35,4 7 35,47 8 35,04 9 35,28 10 35,32 11 40,76 12 32,13 Promedio 35,87
La siguiente figura nos muestra de forma grafica el tiempo que demora en autentificarse las terminales y lo hace en un tiempo promedio de 35,87 segundos.
Figura V-19: Grfico Tabla V.XXI.
99
5.1.2 Escenario 2: Fallas en el Servidor Principal
Esta prueba consisti en simular que el servidor principal ha sufrido alguna falla, que puede haber sido tanto en software como hardware, y/o se hayan apagado o reiniciado abruptamente. Aqu tambin se midi el tiempo, en segundos, que el servidor de respaldo tard en tomar el control total del servicio.
El resultado de las pruebas se muestra a continuacin:
Tabla V.XXII : Tiempo de toma de control por el servidor pasivo. Prueba # Resultado 1 50,97 2 51,93 3 53,36 4 50,16 5 50,23 6 48,63 7 49,56 8 51,25 9 49,85 10 47,32 11 46,78 12 49,25 Promedio 51,13
La siguiente figura nos muestra de forma grafica el tiempo que demora tomar el control el servidor pasivo o secundario al momento de que ocurra algn fallo como puede ser el corte de suministro elctrico u otro y lo hace en un tiempo promedio de 51,13 segundos. 100
Figura V-20: Grfico Tabla V.XXII.
5.1.3 Escenario 3: Fallas en la Red o Tarjeta de Red
Esta prueba consisti en simular que el segmento de red y/o tarjeta de red del servidor principal han sufrido alguna falla por lo cual el servidor secundario tuvo que tomar el control de los recursos. Como en las pruebas anteriores, tambin se midi el tiempo, en segundos, que el servidor de respaldo tard en tomar el control total del servicio.
El tiempo es el cual el servidor de respaldo se demor en tomar el control del servicio, una vez que la red y/o tarjeta de red del servidor principal fall.
El resultado de esta prueba se ve a continuacin:
101
Tabla V.XXIII : Tiempo de toma de control por el servidor pasivo ante falla en la red. Prueba # Resultado 1 48,14 2 44,09 3 45,46 4 42,56 5 49,89 6 40,05 7 44,96 8 43,65 9 45,30 10 46,96 11 48,48 12 45,26 Promedio 45,40
La siguiente figura nos muestra de forma grafica el tiempo que demora tomar el control el servidor pasivo o secundario al momento de que ocurra algn fallo en la tarjeta de red y lo hace en un tiempo promedio de 45,40 segundos.
Figura V-21: Grfico Tabla V.XXIII.
102
Interpretacin de Resultados de la Capa 2
Gracias a los resultados del Escenario 1 (Tabla V.XIX), se pudo determinar que cuando se apaga y/o reinicia el servidor principal, se tiene un promedio de 48,75 segundos en el que el servidor esclavo de respaldo se demora en detectar la cada del servidor principal, y en tomar el control del servicio. De acuerdo a los resultados de la (Tabla V.XX), se pudo determinar que cuando el servidor principal toma nuevamente el control lo hace en un promedio de 50,75 segundos. De acuerdo a los resultados de la (Tabla V.XXI), se pudo determinar que cuando las terminales se registran, se tiene un promedio de 35,87 segundos en que tarda en registrarse en el servidor que toma el control en un momento determinado. Gracias a los resultados del Escenario 2 (Tabla V.XXII), se pudo determinar que cuando hay una falla en el servidor principal que cause el apagado o reiniciado abrupto de este, se tiene un promedio de 51,13 segundos en el cual el servidor de respaldo se demora en tomar el control del servicio. Gracias a los resultados del Escenario 3 (Tabla V.XXIII), con el Tiempo 1 se pudo determinar que cuando hay una falla de red y/o en la tarjeta de red del servidor principal, que cause su exclusin de la red momentneamente, se tiene un promedio de 45,40 segundos en el cual el servidor de respaldo se demora en tomar el control del servicio. Todas estas pruebas validan al indicador de Tiempo de demora de la toma del control del servicio por otros Servidores del Clster. Evaluando los tiempos promedio, y segn la Tabla de disponibilidad de un servicio, se puede determinar que la Capa 1, de servidores Asterisk, del modelo se encuentran en una Alta Disponibilidad aproximada al 99.999%. Pero, cabe resaltar que estos resultados fueron obtenidos sin tener trfico de red de peticiones de los clientes, es decir, no haban peticiones por el servicio. Tambin podemos deducir que esta capa es tolerante a fallos, ya 103
que se elimina el punto nico de fallos teniendo un servidor de respaldo que, con diferentes pruebas, demostr que toma el control del servicio en caso que el servidor principal falle.
5.1.4 Escenario 4: Detectando las fallas de los Servidores DNS (Capa 2)
Este Escenario consisti en simular que el servidor DNS sufri alguna falla, que pueden haber estado relacionadas tanto a hardware como software, y que hayan causado que el servidor se apaguen o reinicien de manera abrupta. En esta prueba se mide el tiempo en que el servidor de Asterisk activo se demor en detectar la cada de el servidor DNS mas el tiempo en que el servidor DNS estaba activo nuevamente. Los resultados los tenemos a continuacin: Tabla V.XXIV : Tiempo de demora del servidor DNS cuando ocurre un fallo Prueba # Tiempo(seg) 1 1,81 2 1,87 3 1,79 4 1,78 5 1,78 6 1,86 7 1,79 8 1,82 9 1,83 10 1,84 11 1,81 12 1,80 Promedio 1,82
La siguiente figura nos muestra de forma grafica el tiempo que demora cuando el servidor DNS presenta algn fallo y lo hace en un tiempo promedio de 1,82 segundos. 104
Figura V-22: Grfico Tabla V.XXIV.
Interpretacin de Resultados de la interaccin de las Capas 1 y 2
Gracias a la Prueba 4 (Tabla V.XXIV), pudimos determinar que el tiempo que se demor en detectar la falla de alguno de los Servidor DNS de la Capa 1 mas el tiempo que el Servidor DNS demor en estar disponible para brindar el servicio, una vez que ha sido inicializado nuevamente. este tiempo fue un promedio de 1,82 segundos, Cabe resaltar que este tiempo puede variar segn la cantidad de servicios que inicializan cada tipo de servidor. Este tiempo valida al indicador Tiempo de recuperacin del servicio al ocurrir fallas en los Servidores.
Resumen de los Escenarios de Pruebas
A continuacin una tabla resumida con los datos de los diferentes escenarios de pruebas.
105
Tabla V.XXV : Tabla resumida de Escenarios de Pruebas.
Podemos deducir el modelo Heartbeat es tolerante a fallos, ya que se elimina el punto nico de fallos teniendo un servidor de respaldo que, con diferentes pruebas, demostr que toma el control del servicio en caso que el servidor principal falle.
En la tabla anterior se puede observar los tiempos que demora en cada uno de los Escenarios de prueba, es as que en el Escenario 1 se tiene un tiempo de 48,75 segundos que demora hasta que el servidor secundario tome el control, el Escenario 2 se tiene un tiempo de 51,13 segundos que demora hasta que el servidor secundario tome el control, el Escenario 3 se tiene un tiempo de 45,40 106
segundos que demora hasta que el servidor secundario tome el control y en el Escenario 4 se tiene un tiempo de 1.83 segundos que demora el servidor Asterisk en reconocer y restablecer la conexin cuando uno de los servidores DNS a cado.
5.2 Comprobacin de la hiptesis de la investigacin realizada.
5.2.1 Planteamiento de la Hiptesis
"La implementacin de una red de alta disponibilidad para centrales Asterisk basada en la tecnologa DUNDi permitir dotar de alta disponibilidad al sistema de Telefona IP ".
El trmino "disponibilidad" hace referencia a la probabilidad de que un servicio funcione adecuadamente en cualquier momento. En este punto se ve necesario definir a que se considera alta disponibilidad en el presente trabajo de tesis.
5.2.2 Alta Disponibilidad
La alta disponibilidad consiste en una serie de medidas tendientes a garantizar la disponibilidad del servicio, asegurando que el servicio funcione durante las veinticuatro horas. Es decir la alta disponibilidad se considera a la capacidad de ofrecer un servicio cuando el servidor que lo ofrece deja de funcionar.
107
Cuando un servidor deja de funcionar el servicio se deja de ofrecer, pero la alta disponibilidad se refiere a que por ms de que este servidor deje de funcionar, el servicio se siga ofreciendo, ya que otro servidor puede tomar el control del servicio que se ofrece.
Segn Jos ngel de Bustos Prez [ 10 ]: La alta disponibilidad es ofrecida por todos los Clsteres que posean lo siguiente: Correcta configuracin del clster. Redundancia de Hardware, que implica la red, almacenamiento, fuentes de alimentacin. Redundancia del Sistema Elctrico.
La disponibilidad se expresa con mayor frecuencia a travs del ndice de disponibilidad (un porcentaje) que se mide dividiendo el tiempo durante el cual el servicio est disponible por el tiempo total. Segn Jos Angel de Bustos Prez nos dice que la disponibilidad se clasifica de acuerdo a la regla de los 9s.
Tabla V.XXVI : Tabla de disponibilidad Disponibilidad Disponibilidad del Servicio Tiempo de cada 99% 3,7 das 99,9% 8,8 horas 99,99% 52,7 minutos 99,999% 5,3 minutos 99,9999% 31,5 segundos
10 Extrado de, utilizacion y administracion avanzadas de sistemas gnu/linux y aplicaciones de software libre para estudiantes universitarios. clustering y alta disponibilidad en gnu/linux. http://www.ibiblio.org/pub/linux/docs/LuCaS/Manuales-LuCAS/doc-curso-salamanca- clustering/html/clustering-ha.html 108
Fundamentada en la tabla anterior, se considera para evaluar que la red tenga Alta disponibilidad en el presente trabajo de tesis, los valores porcentuales de disponibilidad a partir del 99,99%. Es decir solo aquellos valores en tiempo que se encuentren con una disponibilidad de Servicio a partir del 99,99% o ms ser considerado como alta disponibilidad.
Figura V-23: Grfico Tabla V.XXVI.
5.2.3 Evaluacin Indicadores
Para la comprobacin de la hiptesis se evalan los siguientes indicadores tanto para DUNDi como para Heartbeat.
Tabla V.XXVII : Tabla de Indicadores Siglas Descripcin TD Tiempo de demora de la toma del control del servicio por otros Servidores del Clster TP Tiempo de prdida del servicio al ocurrir fallas en los Servidores TR Tiempo de demora de registro de las terminales
109
5.2.4 Ponderacin para Indicadores Para cada rango de tiempo se asigna un valor cuantitativo, la suma de estos en cada uno de los indicadores tanto para DUNDi como para Heartbeat nos ayudar a determinar cul tiene mayor peso. De esta manera se aceptara la hiptesis o se negar la hiptesis.
Tabla V.XXVIII : Tabla de Indicadores Ponderacin Tiempo Porcentaje (%) Cuantitativa (0-20)seg >=80 y < =100 5 (21-40)seg >=60 y < 80 4 (41-60)seg >=40 y < 60 3 (61-80)seg >=20 y < 40 2 (81-100) seg < 20 1 No Aplica 0 0
5.2.5 Valoracin de la disponibilidad en los modelos de DUNDi y Heartbeat
Con los resultados obtenidos de las pruebas realizadas tanto para DUNDi como para Heartbeat se procede a valorar cuantitativamente de acuerdo a la Tabla V.XXVIII a cada uno de los indicadores.
El mayor resultado que se obtenga de la suma de los indicadores muestra cual es el modelo que tiene alta disponibilidad.
110
Tabla V.XXIX : Disponibilidad en DUNDi vs Heartbeat
5.2.6 Decisin Se concluye que se rechaza la hiptesis ya que no se puede medir uno de los indicadores y por lo tanto el resultado en DUNDi que es 62 es bastante inferior al de Heartbeat que es 144 por lo cual se deduce que no se puede obtener alta disponibilidad con DUNDi.
5.2.7 Comprobacin de alta disponibilidad con Heartbeat
Al demostrar que Heartbeat es la mejor opcin para disear una red de alta disponibilidad para centrales Asterisk, es necesario comprobar si se encuentra en el rango de alta disponibilidad de la Tabla V.XXVI de disponibilidad.
111
A continuacin se muestra el promedio de cada escenario de pruebas realizadas para Heartbeat con su equivalente porcentual en disponibilidad
Tabla V.XXX : Tabla resumida de Escenarios con la Disponibilidad. Escenario Promedio Disponibilidad (%) 1 48,75 99,999 2 51,13 99,999 3 45,4 99,999 4 1,82 99,9999 PROMEDIO 36,775 99,999
Evaluando los tiempos promedio, y segn la Tabla V.XXVI de disponibilidad de un servicio. se puede determinar que los servidores Asterisk, del modelo Heartbeat se encuentran en una Alta Disponibilidad aproximada al 99.999%.
Podemos decir que la mejor opcin y la mejor adaptable para una red de alta disponibilidad es el modelo de Heartbeat, ya que adems de las ventajas que tiene sobre el modelo de DUNDi este tambin puede ser adaptable a otras tecnologas de almacenamiento y de Base de Datos.
CONCLUSIONES
Se ha demostrado que al implementar un sistema para telefona IP tolerante a fallos con DUNDi no se obtiene alta disponibilidad ya que al ocurrir algn fallo en el servidor que se encuentra proporcionando el servicio, las terminales no logran registrarse automticamente, sino que se necesita reiniciar las terminales para que estas reconozcan al nuevo servidor que se les fue asignado para establecer la comunicacin.
Con DUNDi cada uno de los nodos que se encuentra conectados entre si propagan la informacin del estado de cada una de las extensiones, esto ayuda a la comunicacin entre los nodos que forman parte de la estructura del clster VoIP.
Asterisk permite integrar dispositivos de distintas marcas y precios como CISCO y Grandstream, convertidores ATA, Gateway, softphones entre ellos X-lite y Zoiper, entre otros, esto gracias a la arquitectura de Asterisk.
De acuerdo al estudio realizado acerca de las tcnicas de alta disponibilidad en redes VoIP, Heartbeat es la mejor herramienta para dar alta disponibilidad a un servicio, en este caso Asterisk; ya que siendo un software libre se adapta a las necesidades del cliente y proporciona un clster evitando en lo ms mnimo la prdida del servicio de telefona. Esto se ve reflejado en la utilizacin de un servidor de respaldo que entrar en accin cuando ocurra alguna falla en el servidor principal, tomando el control del servicio.
Con Heartbeat, la adquisicin de la IP se produce en menos de un segundo. DRBD se re-configura en casi 35 segundos y luego dependiendo de la plataforma de hardware y la complejidad de las aplicaciones que se ejecuten en Asterisk puede tardar entre 10-15 segundos para que Asterisk se ponga en marcha en el servidor secundario, se sincronizan los archivos de configuracin y est listo para procesar las llamadas en un promedio de 48,75 segundos .
El modelo implementado en un Ambiente de Prueba haciendo uso de DRBD junto con Heartbeat optimiza en un 99.999% la disponibilidad de la solucin; puesto que se crea una particin virtual la misma que ser compartida entre los servidores que se realice el clustering.
RECOMENDACIONES
Es recomendable tener un modelo de red de alta disponibilidad donde adaptar el modelo propuesto. As, al contar con una red de alta disponibilidad, se asegura tambin que el servicio est siempre disponible cuando ocurran fallas en los diversos segmentos de la red, donde se encuentre implementado el modelo.
Se recomienda utilizar enlaces Ethernet punto a punto entre los Servidores Asterisk, para que la replicacin de datos se realice por medio de este enlace. As, nos aseguramos de separar el trfico de red producido por el acceso a los datos, del trfico producido por la replicacin de datos. Adems, al ser un enlace dedicado, se evitan las colisiones de los paquetes al momento de hacer la replicacin de los datos, en este caso se utilicen hubs en vez de switches. Tambin nos aseguramos que los servidores se monitoreen entre ellos por medio del enlace punto a punto y no por medio de la red, lo cual podra generar mayor trfico. Gracias a esto, los servidores se seguirn monitoreando an si ocurre alguna falla de red.
La utilizacin de mltiples tarjetas de red, le permitir a los servidores adaptarse a diferentes modelos de red de alta disponibilidad, entre ellas, las redes con enlaces redundantes. Esto tambin incluye la utilizacin de enlaces elctricos de respaldo. Este modelo es motivo de una prxima investigacin.
RESUMEN
El presente documento tiene como objetivo el anlisis y diseo de una red de alta disponibilidad para centrales Asterisk basada en la tecnologa DUNDi que ser desarrollada en los Laboratorios de la Academia CISCO de la Escuela Superior Politcnica de Chimborazo. La investigacin se realiz con el mtodo deductivo con el cual se estudio las tcnicas de alta disponibilidad en redes VoIP y se propuso una solucin que consiste en un modelo activo / pasivo basado en Heartbeat como la mejor opcin para mantener servicios de alta disponibilidad, este modelo hace uso de un Servidor Maestro y un Servidor Esclavo que forman la Capa 2, un Servidor DNS y DHCP que se encuentran en la Capa 1 y los terminales que son Telfonos IP, convertidores ATA Grandstream y softphones; todos estos equipos se encuentran en una red Ethenet mediante cables UTP cat 5e con conectores RJ45. Los resultados muestran que existe un tiempo promedio de demora de 36,775 segundos hasta que sistema se recupere despus de que haya ocurrido algn fallo, esto equivale a una alta disponibilidad del 99,999% segn la tabla de disponibilidad. Se concluye entonces que Heartbeat es la mejor herramienta para dar alta disponibilidad al servicio Asterisk; pues es un sistema tolerante a fallos y proporciona un clster evitando en lo ms mnimo la prdida del servicio. Se recomienda la utilizacin de mltiples tarjetas de red esto permitir a los servidores adaptarse a diferentes modelos de red de alta disponibilidad, entre ellas, las redes con enlaces redundantes.
SUMMARY
This study allows us choosing the best technique for obtaining high availability IP telephony networks. It intended to decrease the risk of a prolonged interruption in telephone network, for which is proposed for a stable and robust core Asterisk that allows us to obtain a high availability network. the main goal is to analysis and design a highly available network core based Asterisk DUNDi technology, which will develop at the Laboratory of CISCO Academy Polytechnic School of Chimborazo. It was used the deductive method to study the techniques of high availability VoIP networks and to propose a solution of a model asset/liability based on Heartbeat as the best option to maintain high availability services. this model uses a Master and a Slave server that form the Layer 2, a DNS server, and DHCP are on Layer 1, and the terminals are IP phones, softphones and Grandstream ATA drives; all these equipments are on a network Ethernet by Cat 5e UTP cables with RJ45 connectors. the result show a turnaround time of 36.775 seconds until the system recovers after a failure has occurred; this equals high availability of 99.999% availability per table. It concluded that, Heartbeat is the best tool to provide high availability by running Asterisk; it is a fault tolerant system and provides a cluster in the least prevent the loss of service. Using multiple network cards, which will allow to the servers to adapt them to different models of high availability network, including networks with redundant links, were recommended.
GLOSARIO
B BIND (Berkeley Internet Name Domain) Servidor DNS ms comn para sistemas Unix, el cual resuelve los nombres de hosts en la red a direcciones numricas y viceversa C Canal Va o medio utilizado para comunicar un mensaje. CentOS Es una libre y disponible distribucin de Linux que se basa en Linux Red Hat Enterprise Linux RHEL. Clustering Es la facultad que tienen varias mquinas para realizar una tarea como si se tratase de una sola mquina, siendo esto tranparente para las maquinas clientes. D DHCP (Dynamic Host Configuration Protocol) Protocolo utilizado para la configuracin dinmica y est encargado de asignar, de forma automtica, direcciones IP a los hosts de una red de computadoras. DNS (Domain Name Server) Servidor de Nombres de Dominios, se encarga de convertir nombres de dominio en direcciones IP. T Telefona Sistema telefnico en el que la conexin entre el aparato porttil y la central se realiza mediante ondas hercianas.
DRBD (Distributed Replicated Block Device) Traducido es un Dispositivo de Bloque Distribuido y Replicado, este dispositivo se asemeja a un disco duro, es el encargado del almacenamiento de los datos en clsteres de alta disponibilidad, replicando sobre una red. E Ethernet Es un estndar de transmisin de datos para redes de rea local para computadoras, que define el acceso al medio. Failback Es el proceso que permite devolver el control del servicio a un servidor, sistema o red, a su estado original, una vez que se recuper de alguna falla. Failover Es la facultad para dar el control de un servicio a un servidor, sistema o red redundante o de respaldo, de forma automtica, cuando ocurre alguna falla. G GPL (General Public License) Licencia Pblica General, fue creada por la Free Software Foundation para proteger la libre distribucin, modificacin y uso de Software Libre. H Heartbeat Software que se encarga de monitorear dos o ms mquinas destinadas a mantener servicios de alta disponibilidad en un modelo activo / pasivo, dando el control del servicio a la mquina en estado pasivo en caso ocurra alguna falla en la activa.
HTTP (HyperText Transfer Protocol) Protocolo de Transferencia de Hipertexto, es el protocolo estndar para la transmisin de pginas Web. IP (Direccin) Nmero que identifica de manera lgica a un computador dentro de una red de computadoras, que utiliza el protocolo IP. K Kernel Ncleo de los Sistemas Operativos GNU/Linux. L LAN (Local Area Network) Red de rea Local, es una red de computadoras de tamao medio, disperso dentro de un edificio o hasta dentro de una ciudad. Linux Es un Sistema operativo, tambin conocido como GNU/Linux, basado en UNIX, distribuido bajo la licencia GPL, siendo este Software Libre. Linux-HA Proyecto que provee un framework de alta disponibilidad, con Heartbeat como su componente bsico. M MAC (Media Access Control) Direccin de Control de Acceso al Medio, es un identificador de 48 bits que identifica, de manera nica, a una tarjeta de red
MySQL Sistema Gestor de Bases de Datos. S SO Sistema Operativo. STONITH (Shoot The Other Node In The Head) Modalidad de Fencing que consiste en apagar o reiniciar algn servidor para asegurarse de que libere los recursos que tiene asignados. Switch Es un dispositivo de interconexin de redes de computadoras, que interconecta dos o ms segmentos de red. U UNIX Sistema operativo portable, multitarea y multiusuario. URL (Uniform Resource Locator) Localizador Uniforme de Recursos, es una secuencia de caracteres que se usa para nombrar recursos de Internet para su localizacin, de acuerdo a un formato estndar para los diversos protocolos utilizados en Internet como HTTP, FTP, etc. V VIP (Virtual IP Address) Direccin IP Virtual, es una direccin IP que puede ser asignada a un conjunto de computadores dentro de un clster.
; ; Sample configuration for res_config_mysql.c ; ; The value of dbhost may be either a hostname or an IP address. ; If dbhost is commented out or the string "localhost", a connection ; to the local host is assumed and dbsock is used instead of TCP/IP ; to connect to the server. ; [general] dbhost = 127.0.0.1 dbname = asteriskrealtime dbuser = asteriskuser dbpass = eLaStIx.asteriskuser.2oo7 ;dbport = 3306 ;dbsock = /tmp/mysql.sock
ANEXO 2
PASOS PARA LA CONFIGURACIN DE TELEFONIA IP CISCO
ANEXO 2.
PASOS PARA LA CONFIGURACIN DE TELEFONIA IP CISCO
Telfono I P CI SCO 7912
Figura 4: Telfono IP CISCO 7912.
Descripcin de las caractersticas del Telfono IP 7912
Tabla VIII : Caractersticas del telfono IP CISCO 7912. N. Caractersticas Funcin 1 Modelo del telfono Indica el modelo del telfono IP CISCO 2 Pantalla LCD Presentan informacin tales como el estado de la llamada, nmero de telfono y las etiquetas de las teclas programables de funcin soft-keys. 3 Teclas programables Activan las funciones presentadas en sus correspondientes etiquetas. 3 5 7 1 9 6 8 2 4
4 Botones de navegacin Permiten desplazarse por el texto y seleccionar las funciones que aparecen en la pantalla. Ofrece acceso directo al men de navegacin rpida cuando el telfono est colgado. 5 Botn de men Proporciona acceso a los servicios que ofrece el telfono. 6 Botn de retencin Para poner la llamada activa en espera. Tambin reinicia una llamada en espera. 7 Teclado Funciona como en un telfono tradicional. 8 Botn de volumen Sube o baja el volumen del telfono. Tambin controla el volumen del timbre (si el telfono est colgado). 9 Auricular con indicador luminoso Sube o baja el volumen del telfono. Tambin controla el volumen del timbre (si el telfono est colgado).
Teclas programables
Este telfono IP Cisco dispone de teclas programables que activan las funciones que aparecen en la parte inferior de la pantalla LCD. Las teclas varan en funcin del estado del aparato. Las teclas programables se usan para iniciar las funciones que aparecen en las correspondientes pestaas de la pantalla LCD.
A continuacin se muestra una lista con las teclas programables del Telfono IP Cisco 7912G. Las funciones varan dependiendo de la configuracin del sistema.
Tabla IX : Teclas programables del telfono IP CISCO 7912. Tecla Funcin << >> Para desplazarse al editar caracteres Acct Consulte con el administrador acerca de la utilizacin de esta tecla. RetroLl. Indica que la lnea est libre. Cancela Anula la ltima seleccin. DsvInc. Desva todas las llamadas.
Elimina Elimina el historial de la agenda. Confrn Establece una conferencia. Eliminar Elimina el nmero seleccionado.
Tabla X : Teclas programables del telfono IP CISCO 7912 (continuacin). Tecla Funcin DND Activa la funcin no molesten. Abajo Disminuye el contraste de la pantalla LCD. EdtMarc Selecciona un nmero y active el cursor para modificarlo. FinLlam. Finaliza la llamada en curso Salir Para abandonar la seleccin en curso Flash Activa el indicador luminoso del suricular para llamadas a 3 y llamadas en espera. CaptGr. Para atender llamadas entrantes en un nmero de telfono que forma parte de un grupo determinado. Login Acceso a servicios que requieren de un PIN para su activacin. Consulte al administrador de su sistema para el uso de esta tecla. Message Para acceder al buz del voz. Monitor Para pasar de la escucha a travs del auricular al altavoz y al modo manos libres. Monoff Para pasar de la escucha a travs del altavoz alauricular y seguir hablando. Ms Para desplazarse por opciones adicionales (utilice el botn Mas, por ejemplo, para localizar la tecla DND) Mute Activa o desactiva el silenciador. Llamar Abre una nueva lnea para realizar una llamada. Ok Para confirmar la seleccin. Park Enva la llamada a una extensin desde la cual puede ser recuperada. Captur Para responder a llamadas dirigidas a otra extensin. Reprod. Reproduce una muestra del timbre ReLlam. Vuelve a marcar el ltimo nmero marcado. Guardar Consulte al administrador para el uso de esta tecla. Resume Returna a una llamada activa. Guardar Guarda el ltimo cambio. Busca Inicia una bsqueda en el directorio local.
Selecci. Selecciona la opcin resaltada en pantalla. Config. Acceso a la configuracin del telfono para tonos de llamada, contraste de la pantalla y volumen del timbre. Trnsf. Para transferir las llamadas a un nmero alternativo. Arriba Incrementa el contraste de la pantalla LCD.
Elementos
A continuacin se especifica los elementos necesarios para la configuracin de un Telfono IP sobre una central Asterisk. Es importante configurar el tipo de protocolo que se usar, en los telfonos CISCO los telfonos CISCO se configurar el protocolo SIP. Los elementos que se necesitan son: Un Telfono IP CISCO SIP 7912 Y un servidor dhcp, para que la direccin ip sea asignada al telfono de forma dinmica.
Configuracin telfono CISCO SI P 7912 Configuracin por medio de la pantalla LDC La siguiente configuracin se realizara mediante interface web, en la barra de direcciones se ingresa la direccin ip correspondiente al telfono IP Cisco (ejemplo 172.30.124.167), en SIP Parameters se procede a crear la extensin.
Figura 5: Registro de parmetros SIP en el Telfono IP CISCO.
Figura 6: Registro de parmetros SIP en el Telfono IP CISCO (continuacin).
Para realizar una llamada: Se puede utilizar cualquiera de los mtodos que se indican a continuacin: Se descuelga el telfono y se marca un nmero. Se puede pulsar Llamar y luego marcar un nmero.
Otra forma es pulsando ReLlam.. Y la litma forma es marcar el nmero sin descolgar el auricular y, a continuacin, pulsar Marcar o descolgar el auricular.. Para realizar una llamada al ltimo nmero marcado Se descuelga el telfono y se pulsa la tecla de rellamada. se pulsa el botn de servicios y luego se navega hasta la opcin de Llamadas enviadas a continuacin se seleccione el nmero que desea marcar.
Para poner una llamada en espera Basta con pulsar Reten.. Y para volver a recuperar la llamada en espera se vuelve a pulsar Reten.. Para silenciar una llamada Se debe pulsar en Mute. Para desactivar el silencio se debe volver a pulsar Mute o, si utiliza la funcin de silencio y la de manos libres, simplemente descuelgue el auricular. Para gestionar las llamadas en espera Para seleccionar entre varias llamadas en espera en la misma lnea, utilice el botn Reten.. Para realizar una conferencia telefnica 1. Durante una llamada, pulse Confrn.. Al hacerlo se abre una lnea automticamente y el primer interlocutor pasa a modo en espera. 2. A continuacin llame a otro nmero. 3. Cuando se establece la llamada, vuelva a pulsar Confrn. para aadir al nuevo interlocutor a la conferencia. Nota: Cuando el que origina la llamada cuelga, termina la conferencia telfonica.
Para ajustar el volumen del timbre Pulse Up o Down Volume con el telfono colgado. Para ajustar el volumen de la llamada en curso. Para ajustar el volumen de la llamada en curso Pulse Arriba o Abajo Volumen mientras utiliza el telfono. Para transferir llamadas Existen dos modos de transferencia de llamadas a otro nmero: Transferencia a ciegas: redirige la llamada directamente, sin hablar con la persona a la que se transfiere la misma. Transferencia con consulta: redirige la llamada despus de haber hablado con la persona a la que se va a transferir. Para transferir una llamada: 1. Durante la llamada, pulse Trnsf.. La llamada activa se pone en espera. 2. Marque el nmero al que desea transferir la llamada. 3. Para realizar una transferencia a ciegas: Cuelgue cuando oiga la seal de lnea. Para realizar una transferencia con consulta: Cuando la persona a la que desea transferir la llamada contesta, pulse Trnsf. y, a continuacin, cuelgue. Nota: Si no se transfiere la llamada, pulse Resume para volver a la llamada original. 4. Para cancelar un intento de transferencia de llamada y volver a tener en lnea a la persona que ha llamado, pulse Reten.. Para desviar todas las llamadas 1. Pulse DsvInc.. Se oye una seal sonora de confirmacin.
2. Marque el nmero al que desee desviar todas las llamadas. Mrquelo exactamente como lo hara si quisiera realizar una llamada; con todos los prefijos necesarios. 3. Se actualizar la pantalla del telfono para indicar que se ha desviado la llamada. 4. Pulse almohadilla (#). Se actualizar la pantalla del telfono para indicar que se ha desviado la llamada. 5. Para cancelar el desvo de llamadas, pulse DsvInc.. Para escuchar los mensajes del buzn de voz, configurar el telfono y utilizar la agenda 1. Pulse Menu. 2. Utilice el botn Navigation para desplazarse por las opciones: a. Pulse 1 para escuchar los mensajes y siga las instrucciones de la operadora. b. Pulse 2 para acceder a la agenda y para ver las llamadas perdidas, recibidas y enviadas. c. Pulse 3 para acceder a la configuracin del aparato: ajuste del contraste, volumen del timbre, tipo de timbre. 3. Utilice el botn Navegacin para desplazarse por las opciones. 2. Para seleccionar una opcin, pulse Selecci.. 4. Si desea regresar al men precedente, pulse Salir. Activacin de la funcin de no molesten (DND) Para recibir un aviso visual e informacin de las llamadas sin que suene el telfono, utilice el DND. La lnea se mostrar ocupada y las llamadas se tratarn como en los casos normales sin respuesta. Pulse Mas para localizar la tecla DND. Pulse la tecla DND. Para utilizar la funcin Captura de Llamada
Pulse Captur.. Marque la extensin del telfono IP Cisco que est sonando El control de la llamada se transferir a su aparato. Para atender una llamada procedente de un telfono que forma parte de un grupo determinado, puede utilizar uno de los mtodos que se exponen a continuacin: Pulse CaptGr.. Si slo hay un grupo definido en todo el sistema CallManager Express, el control de la llamada se transfiere a su telfono. Si el telfono que est sonando y el suyo pertenecen al mismo grupo, pulse asterisco (*) para transferir el control de la llamada a su aparato. Si el telfono que est sonando y el suyo pertenecen a grupos distintos, marque el nmero del grupo al que pertenece el telfono que est sonando para transferir el control de la llamada a su aparato.
Almacenamiento y recuperacin de llamadas aparcadas
Puede recurrir al aparcamiento de llamadas si desea almacenar una llamada para recuperarla desde otro telfono del sistema Cisco CallManagerExpress (por ejemplo, un telfono de la oficina de otra persona o de una sala de conferencias).
El aparcamiento de llamadas es una funcin especial que el administrador del sistema puede configurar en su telfono.
Para Almacenar una llamada activa con aparcamiento de llamadas:
Durante una llamada, seleccione ms > Aparcar. En la pantalla del telfono se mostrar el nmero especial para aparcar llamadas en el que se almacenar la llamada. Pulse el botn de transferencia, seguido del nmero especial de aparcamiento presentado por el sistema.
Recuperar una llamada Aparcada: Marque el nmero en el que se aparc la llamada desde cualquier telfono IP de Cisco en su red para recuperarla. Nota: Dispone de un perodo de tiempo limitado para recuperar la llamada aparcada antes de que vuelva a sonar en su destino original.
Pregntele al administrador del sistema el valor de este tiempo limitado.
Funcin de difusin de mensajes
El servicio de difusin de mensajes proporciona un mtodo para enviar mensajes de audio a grupos de telfonos IP que hayan sido previamente designados por el administrador del sistema como destinatario de estos mensajes. La comunicacin es unidireccional y los mensajes no pueden ser contestados. Para utilizar la funcin de difusin de mensajes, haga lo siguiente:
1. Seleccione una lnea disponible levantando el auricular y espere el tono de llamada. 2. Marque el nmero del grupo de difusin. Este nmero debe ser proporcionado por el administrador del sistema.
Cada uno de los telfonos IP que han sido configurados como pertenecientes al grupo de difusin, y que no estn ocupado en ese momento, responde automticamente en modo manos libres, y la
pantalla muestra la identidad del llamante. Cuando el iniciador de la difusin cuelga el auricular, los telfonos retornan a su estado normal.
Personalizacin de tonos de llamada
El usuario puede seleccionar el tono de llamada utilizad de entre los configurados por el administrador y que estn disponibles en el sistema de Call Manager Express. Para ello, acceder al men de configuracin del telfono a travs del botn de configuracin.
Navegar por las opciones de configuracin del telfono hasta la opcin de RingList y seleccionar el tono deseado de entre los disponibles.
PASOS PARA LA CONFIGURACIN DEL TELFONO IP GRANDSTREAM
Telfono GRANDSTREAM Budge Tone-201
Presiona el botn Men del telfono IP GRANDSTREAM, con el botn que indica la flecha hacia abajo recorre hasta la opcin 2 y presiona nuevamente el botn Men. En la pantalla LCD se visualiza una direccin IP que fue asignada por el servidor DHCP en mi caso se me ha asignado la direccin 172.30.124.183, para continuar con la configuracin, se registrar una extensin configurada anteriormente en la PBX Asterisk. Accedemos mediante un Cliente Web que puede ser un navegador (Google Chrome, Mozilla Firefox, Internet Explorer, etc.).
En el navegador Google Chrome en la barra de direcciones e ingresado la direccin IP 172.30.124.183. User: admin Password: admin
Figura 7: Login en el Telfono IP GRANDSTREAM.
Se ha Ingresado los datos de la extensin de la siguiente manera Si no se posee un servidor de DNS, en SIP server se ingresa la IP de la central Asterisk, (por ejemplo: 172.30.124.202). El DNS que yo he configurado reconoce el dominio www.telefonicanet.com.
Figura 8: Registro de cuenta en el Telfono IP GRANDSTREAM (continuacin).
Figura 9. Registro de cuenta en el Telfono IP GRANDSTREAM (continuacin).
Se acepta las modificaciones clicleando Update. Nuevamente ingresamos el password (admin). Finalmente se ha registrado la extensin en el telfono IP GRANDSTREAM Budge Tone-201.
ANEXO 3 CONFIGURACIN DE DNS SRV
ANEXO 3.
CONFIGURACIN DE DNS SRV
Lo primero a realizar es la creacin de una zona en este punto se modificar el archivo de configuracin que se conoce como named.conf.
Este archivo ubicado en el directorio /etc es el archivo de configuracin principal de DNS ya que contiene la ubicacin y parmetros de los dems archivos de configuracin, en l se indican todas las zonas a las cuales dar servicio el servidor DNS, entre otras funciones. Este archivo contiene dos tipos de secciones:
Opciones " options ": Indica el directorio donde se encuentran otros archivos de configuracin y algunas otras opciones.
Zonas " zone ": Pueden existir varias zonas por archivo, estas zonas definen los dominios (telefonicanet.com) y redes "networks" (172.30.124.0) sobre los que se mantiene informacin.
A continuacin se muestran las lneas de configuracin del dominio, los archivos de configuracin completos se pueden ver en los ANEXOS. Para observar este apartado se ha ingresado mediante interface grafica de Webmin en Edit Config File de la zona.
La zona configurada ser el dominio dentro de la red, conocido como telefonicanet.com. Zone indica el nombre del dominio que estamos configurando, el resto son sus detalles. Type master indica que es el servidor principal de la zona. Si fuera un servidor secundario tendramos que poner "type slave".
La razn de la existencia de ambos no es en estricto rigor pero es tremendamente conveniente en el caso de que el primario dejase de funcionar. La lnea file indica qu fichero contiene los datos de la zona. Este fichero se debe encontrar en el directorio /var/named.
zone "telefonicanet.com" { type slave; file "/etc/bind/db"; master { 172.30.124.100 }; };
Por ltimo, allow-update indica desde qu equipos se pueden realizar actualizaciones dinmicas, en nuestro caso se permitir realizarlas hacia el host 172.30.124.101. En estos ficheros tendremos que poner direcciones IP y no nombres porque el sistema de resolucin aun no est activo.
Ahora tenemos que introducir una configuracin inicial de la zona. Este fichero ha de contener todos los registros de recurso asociados a dicha zona.
Tipos de registros de DNS
Tabla XI: Tipos de registros de DNS. Tipo Nombre Funcin Zona SOA Start Of Authority Define una zona representativa del DNS NS Name Server Identifica los servidores de zona, delega subdominios Bsicos A Direccin IPv4 Traduccin de nombre a direccin AAAA Direccin IPv6 original Actualmente obsoleto A6 Direccin IPv6 Traduccin de nombre a direccin IPv6 PTR Puntero Traduccin de direccin a nombre DNAME Redireccin Redireccin para las traducciones inversas IPv6 MX Mail eXchanger Controla el enrutado del correo Seguridad KEY Clave pblica Clave pblica para un nombre de DNS NXT Next Se usa junto a DNSSEC para las respuestas negativas SIG Signature Zona autenticada/firmada Opcionales CNAME Canonical Name Nicks o alias para un dominio LOC Localizacin Localizacin geogrfica y extensin RP Persona responsable Especifica la persona de contacto de cada host SRV Servicios Proporciona la localizacin de servicios conocidos TXT Texto Comentarios o informacin sin cifrar
Es necesario definir un registro de recurso que es el que har funcionar todo la estructura de la red de alta disponibilidad, el registro de recursos SRV; permite utilizar varios servidores para un nico dominio DNS, para mover servicios desde un host a host fcilmente y designar algunos hosts como servidores. Localizan servidores que proporcionen un servicio basado en TCP/IP mediante una nica operacin de consulta DNS. Gracias a este registro es por el cual se puede establecer un balanceo de carga en las centrales en uno de sus parmetros. Se muestra a continuacin el fichero de registros DNS.
$ttl 38400 telefonicanet.com. IN SOA dns0.telefonicanet.com. cisco.telefonicanet.com. ( 1293935335 10800 3600 604800 38400 ) IN NS dns0 telefonicanet.com. IN A 192.168.137.100 dns0 IN CNAME telefonicanet.com. www.telefonicanet.com. IN CNAME telefonicanet.com. pc1 IN A 192.168.137.161 pc2 IN A 192.168.137.162 pc3 IN A 192.168.137.163 pc4 IN A 192.168.137.164 telefonicanet.com. IN NS telefonicanet.com. dns0.telefonicanet.com. IN CNAME telefonicanet.com. _sip._udp.telefonicanet.com. 300 IN SRV 0 1 5060 pc1.telefonicanet.com. _sip._udp.telefonicanet.com. 300 IN SRV 0 1 5060 pc2.telefonicanet.com. _sip._udp.telefonicanet.com. 300 IN SRV 0 1 5060 pc3.telefonicanet.com. _sip._udp.telefonicanet.com. 300 IN SRV 0 1 5060 pc4.telefonicanet.com.
Los registros de tipo A son aquellos que aportan la direccin IP de una mquina, en este caso cada una de estas centrales, conocidas por el nombre pc1, pc2, pc3 y pc4. Las dos ltimas sentencias son pertenecientes al registro SRV. Para razonar mejor su funcionalidad, se har una explicacin ms puntualizada de esta sentencia.
Formato del registro de recursos SRV
El registro de recursos SRV tiene cdigo de tipo DNS, a continuacin se muestra la siguiente sintaxis:
Cada uno de los estos campos que se usan en el registro de recursos SRV tienen como objetivo lo siguiente:
Servicio (_sip): Nombre simblico de la informacin solicitada de servicio, Pueden llamarse localmente slo servicios definidos localmente. Servicio no distingue entre maysculas y minsculas. Para los servicios conocidos, se define en el documento RFC 1700. Si no se define en el documento RFC 1700 un nombre de servicio conocido, en su lugar se puede utilizar un nombre creado por el usuario. Si el RFC 1700 asigna un nombre para un servicio indicado en este campo, el nombre definido en RFC es el nico nombre que se puede utilizar pero solo se lo utilizar localmente.
Servicio.Protocolo.Nombre TTL clase SRV Prioridad Peso Puerto destino.
Protocolo (._udp): TCP y UDP son en este momento los valores ms tiles para este campo, Se puede utilizar cualquier protocolo de transporte nombrado en RFC 1700, aunque cualquier nombre definido por nmeros asignados o localmente, se puede utilizar (como en servicio). Distingue maysculas de minsculas e indica el tipo de protocolo de transporte.
Nombre (telefonicanet.com.): Dominio que hace referencia este registro de recursos a. El registro de recursos SRV es nico en que el nombre buscado no es este nombre. Es diferente con relacin a otros tipos de registro DNS en que no se utiliza para realizar bsquedas o consultas.
TTL: Especifica el tiempo mximo que otros servidores DNS y aplicaciones deben mantener en cach ese registro. Si el valor es 0, entonces no se mantiene ningn cach y los cambios que se realicen en el registro se registrarn en el momento. Cuando se decide el tiempo TTL, se debe tener en cuenta cuan a menos se cambiar el record (registro). Por el cach, los cambios en un registro DNS no alcanzarn toda la red hasta que el TTL no haya expirado. Si se quieren cambios rpidos, debe elegirse un TTL bajo.
Clase: Es un entero de 16 bits que define la clase del Resource Record. Prioridad (0): Es la prioridad de este host de destino. El campo de prioridad determina la prioridad de uso de los datos del registro. Los clientes siempre usan el registro SRV con el menor valor de prioridad numeradas en primer lugar. El intervalo es 0-65535.
Peso (1): Se lo considera como un mecanismo de equilibrio de carga. Al seleccionar un host de destino entre las que tienen la misma prioridad, la posibilidad de tratar este uno primero debe ser proporcional a su peso. Pesos mayores se debera dar una proporcionalmente mayor probabilidad de
que se est seleccionada. El intervalo es 0-65535. En el caso de no requerir equilibrio de carga se asignar 0.
Puerto (5060): Puerto de este host de destino de este servicio. El intervalo es 0-65535. Esto es a menudo como especificado en los nmeros asignados, pero no es necesario.
Destino: se define el nombre de dominio DNS de los host de destino. Debe haber uno o ms registros "A" para este nombre. Los implementadores deben, pero no son necesarios, para devolver los registros "A" en la seccin de datos adicionales. Nombre de la compresin es que se va a utilizar para este campo. Un destino de "." significa que el servicio no est disponible en este dominio.
Si nos fijamos en los registros SRV el campo peso asignado es 1 esto quiere decir que no habr preferencia por ninguno de los servidores, todos tienen igual preferencia.
ANEXO 4
CONFIGURACIN DE ASTERISK EN REALTIME
ANEXO 4.
CONFIGURACIN DE ASTERISK EN REALTIME
Descargar asterisk-addons-1.4.13.tar de http://downloads.asterisk.org/pub/telephony/asterisk/. Al punto se ha descargado el asterisk-addons-1.4.13.tar que es un paquete que permitir integrar a nuestra central de telefona IP y aade cuatro funcionalidades muy importantes como son:
Tener un registro de las llamadas en una base de datos usando MySql. Poder utilizar archivos MP3 para la msica en espera. Aadir el protocolo H.323 para proveer a los usuarios con tele-conferencias que tienen capacidades de voz, video y datos sobre redes de conmutacin de paquetes. El canal chan_mobile que nos permite conectar, via bluetooth, un celular a nuestra central y usarlo como gateway GSM y, si el celular lo soporta, envio de SMS, esta es una funcionalidad que no se ha la implementar en el presente trabajo de Tesis.
Antes de empezar tenemos que parar el servidor Asterisk y arrancar el servidor Mysql Para hacer esto digitamos:
Luego dentro del directorio /usr/src/ se descomprime el archivo asterisk-addons-1.4.13.tar.
/etc/init.d/asterisk stop service asterisk stop /etc/init.d/mysqld start service mysqld stop
Ingresamos al terminal y procedemos a compilar e instalar.
Posteriormente ir al directorio de archivos de configuracin de Asterisk /etc/asterisk y editar los archivos cdr_mysql.conf y res_mysql.conf
[global] hostname=localhost dbname=asterisk1 table=cdr password=123456 user=userealtime userfield=1 port=3306 ;sock=/tmp/mysql.sock [pc1@localhost ~]$ cd asterisk-addons-1.4.13 [pc1@localhost ~]$ ./configure [pc1@localhost ~]$ make [pc1@localhost ~]$ make install
Para habilitar esta funcionalidad, simplemente hay que disponer de una base de datos mysql, en este caso se crear una base de datos Asterisk1.
Para esto se debe crea un usuario con libre acceso a la Base de Datos. Para eso ingresamos a Servidores y luego a Servidor de Base de Datos MySQL, con la herramienta Webmin:
Luego en Permisos de usuario sealamos aadir usuario con permisos como se indica en la figura, procedemos a crear el usuario, esto nos permitir manipular adecuadamente la base de datos Asterisk1:
Entonces creamos la base de Datos que lleva por nombre Asterisk1.
Figura 10: Servidor de base de datos MySQL.
Nuestra base de datos mysql se encuentra en la misma mquina, as que no se necesitar cambiar el hostname y dbhost. Luego se debe crear la tabla "cdr" en nuestra base de datos. A continuacin el script de la Tabla cdr:
Finalmente reiniciar Asterisk
Al ingresar a la consola para verificar si los cambios y la tabla han sido reconocidos con el comando
Para registrar el uniqueid, se debe recompilar asterisk-addons previamente hay que agregar al principio del archivo. Asterisk*CLI> realtime mysql status /etc/init.d/asterisk reload CREATE TABLE cdr ( calldate datetime NOT NULL default '0000-00-00 00:00:00', clid varchar(80) NOT NULL default ' ', src varchar(80) NOT NULL default ' ', dst varchar(80) NOT NULL default ' ', dcontext varchar(80) NOT NULL default ' ', channel varchar(80) NOT NULL default ' ', dstchannel varchar(80) NOT NULL default ' ', lastapp varchar(80) NOT NULL default ' ', lastdata varchar(80) NOT NULL default ' ', duration int(11) NOT NULL default '0', billsec int(11) NOT NULL default '0', disposition varchar(45) NOT NULL default ' ', amaflags int(11) NOT NULL default '0', accountcode varchar(20) NOT NULL default ' ', uniqueid varchar(32) NOT NULL default ' ', userfield varchar(255) NOT NULL default ' ', KEY `calldate` (`calldate`), KEY `dst` (`dst`), KEY `accountcode` (`accountcode`) ) ENGINE=MyISAM ;
La lnea
Guardar el archivo y recompilar asterisk-addons
Por ltimo se presentar el script de la Tabla sipfriends para manejar los usuarios, peers y extensiones.
Al final modificamos el archivo de configuracin de Asterisk para el Realtime; en el archivo /etc/asterisk/extconfigs.conf vamos a encontrar algo como: ;sipusers => odbc,asterisk ;sippeers => odbc,asterisk
La primera lnea debe indicar el tipo de conexin y base de datos que estamos usando en este caso mysql, luego Asterisk es el nombre de la base de datos y sipfriends en el nombre de la tabla, obviamente cambiando estas dos lneas queda de la siguiente manera:
Por ltimo recargamos la configuracin de Asterisk y verificamos que toda la configuracin est bien en nuevo sistema con soporte Realtime esto significa que solo tendremos que modificar la base de datos y los cambios sern activados en lnea, la informacin de los anexos y peers estar reflejada directamente en la tabla sipfriends.
Se ha comprobado la conexin a Asterisk por el puerto 3306 con el usuario userealtime.
/etc/init.d/asterisk reload asterisk rvvvvvvvvvvvv CLI> realtime mysql status sipusers => mysql,asterisk1,sipfriends sippeers => mysql,asterisk1,sipfriends
En este modulo se afirma que la configuracin de Asterisk en realtime es decir en tiempo real es de gran ventaja para obtener Alta disponibilidad, con esto es posible la administracin del sistema desde cualquier aplicacin externa, ya que podemos almacena y acceder a la informacin de una base de datos, en este caso MySQL.
ANEXO 5
ARCHIVOS DE CONFIGURACIN DE DUNDi
ANEXO 5.
ARCHIVOS DE CONFIGURACIN DE DUNDi
dundi.conf Seccin [general] Para pc1.telefonicanet.com:
[general] department=CENTRAL01 organization=Cisco locality=Riobamba stateprov=Chimborazo country=EC email=info@telefonicanet.com phone=+593-0000000 ; Aqui podemos definir en que red va a escuchar dundi bindaddr=0.0.0.0 ; El puerto en el que va a escuchar, por defecto 4520 port=4520 ; Aqui nos identificamos con nuestra MAC address entityid= 00:0C:29:DA:73:F8 ; El numero de consultas que har DUNDI hasta alcanzar una extensin ttl=32 ; Finaliza las conexiones fallidas autokill=yes
Para pc2.telefonicanet.com:
Para pc3.telefonicanet.com: [general] department=CENTRAL02 organization=Cisco locality=Riobamba stateprov=Chimborazo country=EC email=info@telefonicanet.com phone=+593-0000000 ;Aqui podemos definir en que red va a escuchar dundi bindaddr=0.0.0.0 ; El puerto en el que va a escuchar, por defecto 4520 port=4520 ; Aqui nos identificamos con nuestra MAC address entityid= 00:0C:29:42:02:00 ; El numero de consultas que har DUNDI hasta alcanzar una extensin ttl=32; ; Finaliza las conexiones fallidas autokill=yes
Para pc4.telefonicanet.com:
Seccin [mappings] [general] department=CENTRAL03 organization= Cisco locality=Riobamba stateprov=Chimborazo country=EC email=info@telefonicanet.com phone=+593-0000000 ;Aqui podemos definir en que red va a escuchar dundi bindaddr=0.0.0.0 ; El puerto en el que va a escuchar, por defecto 4520 port=4520 ; Aqui nos identificamos con nuestra MAC address entityid= 00:0C:29:76:5A:B5 ; El numero de consultas que har DUNDI hasta alcanzar una extensin ttl=32; ; Finaliza las conexiones fallidas autokill=yes [general] department=CENTRAL04 organization= Cisco locality=Riobamba stateprov=Chimborazo country=EC email=info@telefonicanet.com phone=+593-0000000 ;Aqui podemos definir en que red va a escuchar dundi bindaddr=0.0.0.0 ; El puerto en el que va a escuchar, por defecto 4520 port=4520 ; Aqui nos identificamos con nuestra MAC address entityid= 00:0C:29:18:E2:45 ; El numero de consultas que har DUNDI hasta alcanzar una extensin ttl=32; ; Finaliza las conexiones fallidas autokill=yes
Para pc1.telefonicanet.com:
Para pc2.telefonicanet.com: [mappings] priv => exten_SIP,0,IAX2,dundi:${SECRET}@192.168.137.161/${NUMBER},nopartial ; ; Identificamos al servidor 2 (CENTRAL02) por su entityid [00:0C:29:42:02:00] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL02 host=172.30.124.202 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary ; Identificamos al servidor 3 (CENTRAL03) por su entityid [00:0C:29:76:5A:B5] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL03 host=172.30.124.203 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary ; Identificamos al servidor 4 (CENTRAL04) por su entityid [00:0C:29:18:E2:45] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL04 host=172.30.124.204 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary
Para pc3.telefonicanet.com: [mappings] priv => exten_SIP,0,IAX2,dundi:${SECRET}@192.168.137.162/${NUMBER},nopartial ; ; Identificamos al servidor 1 (CENTRAL01) por su entityid [00:0C:29:DA:73:F8] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL01 host=172.30.124.201 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary ; Identificamos al servidor 3 (CENTRAL03) por su entityid [00:0C:29:76:5A:B5] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL03 host=172.30.124.203 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary ; Identificamos al servidor 4 (CENTRAL04) por su entityid [00:0C:29:18:E2:45] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL04 host=172.30.124.204 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary
Para pc4.telefonicanet.com: [mappings] priv => exten_SIP,0,IAX2,dundi:${SECRET}@192.168.137.163/${NUMBER},nopartial ; ; Identificamos al servidor 1 (CENTRAL01) por su entityid [00:0C:29:DA:73:F8] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL01 host=172.30.124.201 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary ; Identificamos al servidor 2 (CENTRAL02) por su entityid [00:0C:29:42:02:00] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL02 host=172.30.124.202 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary ; Identificamos al servidor 4 (CENTRAL04) por su entityid [00:0C:29:18:E2:45] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL04 host=172.30.124.204 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary
Los siguientes archivos se configuran en todas las centrales.
[mappings] priv => exten_SIP,0,IAX2,dundi:${SECRET}@192.168.137.164/${NUMBER},nopartial ; ; Identificamos al servidor 1 (CENTRAL01) por su entityid [00:0C:29:DA:73:F8] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL01 host=172.30.124.201 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary ; Identificamos al servidor 2 (CENTRAL02) por su entityid [00:0C:29:42:02:00] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL02 host=172.30.124.202 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary ; Identificamos al servidor 3 (CENTRAL03) por su entityid [00:0C:29:76:5A:B5] ;permitir y realizar conexiones model=symmetric ; IP ser servidor CENTRAL03 host=172.30.124.203 inkey=SERVERS-DUNDI outkey=SERVERS-DUNDI ; Incluimos el contexto antes definido en la seccin mappings include=priv permit=priv qualify=yes order=primary
iax_custom.conf
sip_general_additional.conf
sip_custom.conf vmexten=*97 disallow=all allow=ulaw allow=alaw context=ext_local_SIP bindaddr=0.0.0.0 srvlookup=yes regcontext=sipregistration rtcachefriends=yes callerid=Unknown notifyringing=yes notifyhold=yes limitonpeers=yes tos_sip=cs3 tos_audio=ef tos_video=af41 alwaysauthreject=yes [dundi] type=user context=ext_DUNDi dbsecret=dundi/secret ; Podemos restringir ciertos codecs para mejorar la calidad ; de voz, o dar prioridad al ancho de banda (con gsm o g729) disallow=all allow=ulaw allow=alaw allow=gsm
extensions.conf
Certificados de encriptacin
Para pc1.telefonicanet.com:
Copiar hacia pc2.telefonicanet.com:
[ext_DUNDi] exten => _X.,1,Goto(ext_local_SIP,${EXTEN},1) [context_internal] include => lookup_to_DUNDi include => ext_local_SIP [lookup_to_DUNDi] switch => DUNDi/priv [ext_local_SIP] ; Esta es la contexto que llamamos desde el contexto [lookup_to_DUNDi] ; Tambien evita que hayan loops en las consultas dundi. ;switch => Realtime/sipfriends exten => _X.,1,Dial(SIP/${EXTEN}) exten => _X.,2,Hangup
sipregistration=ext_local_SIP
# cd /var/lib/asterisk/keys astgenkey -n SERVERS-DUNDI
INSTALACIN Y CONFIGURACIN DE HEARTBEAT Y DRBD A continuacin se explica cmo instalar drbd y heartbeat y como configurar este servicio para tener siempre disponible un equipo servidor y en el caso de una cada del mismo que otro pueda tomar su lugar sin que el usuario cliente perciba alguna anomala (de ser posible).
Una vez realizadas las instalaciones bsicas y securizadas las mquinas, los siguientes pasos a dar seran: Pasos que se deben realizar en los servidores primarios y secundarios. 1. Arranque Elastix-2.0del CD de instalacin
2. En el men de inicio tipo "avanzado" y entrar
3. Durante la rutina de instalacin elige manejar particiones manualmente duro. La siguiente es basado en un160,0GBSATA Creacin de raz (/), ext3con6144MB(sda1) Crear una particin swap con3072MB(sda2)
4. El resto de la rutina de instalacin es estndar.
5. Despus de la instalacin y el arranque realizar la actualizacin. Actualizar el sistema operativo. Para realizar la actualizacin se ejecuta: - yum y update
6. Asegrese que para arrancar el fichero / boot/grum/menu.lst del kernel no-xen a menos que necesite el kernel de Xen. http://elanalista.wordpress.com/2007/01/08/editar-menu-de-grub/
- default=1 El archivo de configuracin del men es: /boot/grub/menu.lst Antes de hacer ningn cambio sera buena idea hacer una copia de seguridad de nuestro men, por lo que pudiera pasar. Para ello ejecutaremos en un terminal la siguiente orden: cp /boot/grub/menu.lst /boot/grub/menu.lst_original
Con lo que nos har una copia del archivo menu.lst con el nombre menu.lst_original. Ahora s podemos empezar, abriremos el archivo de configuracin usando nuestro editor de texto favorito, yo usar nano: nano /boot/grub/menu.lst
Con lo que veremos un archivo similar a este:
Para guardar los cambios ctrl+x enter S Enter
7. Ahora vamos a crear la particin que contendr los datos que se replicaran, para esto ejecutamos el comando: fdisk /dev/sda
Pasos
1.- Presionamos la letra n (add a new partition) 2.- Presionamos la letra p (Primarypartition) 3.- Escribimos el nmero 3 (Partitionnumber) 4.- Presionamos Enter un par de veces hasta que nos aparezca el Command de nuevo. 5.- Luego presionamos la letra t para cambiar el id del sistema de particiones. 6.- Escribimos la particin 3. 7.- En HEX code escribimos 83 que es la particin de Linux 8.- Por ultimo escribimos la letra w para salvar los cambios. 9.- Despus reiniciamos el servidor para que la nueva tabla est disponible.
8. Ahora procederemos a formatear la nueva particin con el siguiente comando:
mke2fs -j /dev/sda3
Slave
9. Ahora hay que eliminar el sistema de archivos desde el disco que acabamos de crear dd if=/dev/zero bs=1M count=1 of=/dev/sda3; sync
10. Instalamos DRBD, Heartbeat y dependencias con yum.
yum -y installdrbd
yum -y install kmod-drbd82
yum -y installOpenIPMI-libs
yum -y installheartbeat-pils
yum -y installopenhpi
yum -y install heartbeat
yum -y installheartbeat-stonith
11. Para garantizar la correcta nombre de host IP de la resolucin se recomienda que actualice manualmente el archivo / etc / hosts para reflejar una asignacin correcta de host- a-IP.
SLAVE
12. DRBD nos permite escribir la particin declarada en ambos miembros de la agrupacin. En nuestro caso / dev/sda3. Para que esto suceda tenemos que crear una particin virtual llamado / dev/drbd0.
13. Editar el archivo / etc / drbd.conf en ambos servidores primarios y secundarios. drbd.conf archivo debe ser idntico en ambos servidores.
Configuracin de DRBD
Esto en ambos servidores /etc/drbd.con
# Do not remove the following line, or various programs # that require network functionality will fail. 192.168.137.101 master.telefonicanet.com 192.168.137.102 slave.telefonicanet.com 127.0.0.1 master.telefonicanet.com ::1 localhost6.localdomain6 localhost6
# Do not remove the following line, or various programs # that require network functionality will fail. 192.168.137.101 master.telefonicanet.com 192.168.137.102 slave.telefonicanet.com 127.0.0.1 slave.telefonicanet.com ::1 localhost6.localdomain6 localhost6
14. Antes de seguir se debe de cambiar el nombre del servidor en la interface web de Elastix
15. Ahora vamos a crear la particin virtual / dev/drdb0 en ambos servidores
drbdadm create-md r0
# # please have a a look at the example configuration file in # /usr/share/doc/drbd/drbd.conf # resource "r0" { protocol A; disk { on-io-error pass_on; } startup { wfc-timeout 5; degr-wfc-timeout 3; } syncer { rate 100M; } onmaster.telefonicanet.com { device /dev/drbd0; disk /dev/sda3; address 192.168.137.101:7789; meta-disk internal; } on slave.telefonicanet.com { device /dev/drbd0; disk /dev/sda3; address 192.168.137.102:7789; meta-disk internal; } }
--== This is a new installation of DRBD ==-- Please take part in the global DRBD usage count at http://usage.drbd.org.
The counter works anonymously. It creates a random number to identify your machine and sends that random number, along with DRBD's version number, to usage.drbd.org.
The benefits for you are: * In response to your submission, the server (usage.drbd.org) will tell you how many users before you have installed this version (8.2.6). * With a high counter LINBIT has a strong motivation to continue funding DRBD's development.
In case you want to participate but know that this machine is firewalled, simply issue the query string with your favorite web browser or wget. You can control all of this by setting 'usage-count' in your drbd.conf.
* You may enter a free form comment about your machine, that gets used on usage.drbd.org instead of the big random number. * If you wish to opt out entirely, simply enter 'no'. * To count this node without comment, just press [RETURN]
--== Thank you for participating in the global usage survey ==-- The server's response is:
you are the 19977th user to install this version
From now on, drbdadm will contact usage.drbd.org only when you update DRBD or when you use 'drbdadm create-md'. Of course it will continue to ask you for confirmation as long as 'usage-count' is at its default value of 'ask'.
Just press [RETURN] to continue: v08 Magic number not found v07 Magic number not found v07 Magic number not found v08 Magic number not found Writing meta data... initialising activity log NOT initialized bitmap New drbdmeta data block sucessfully created.
16. Inicio servicio drbd en ambos servidores para iniciar el proceso de sincronizacin. service drbd start
17. Verificar proceso de sincronizacin con el siguiente comando service drbd status
Inicialmente, ambos servidores son "secundarios". Tenemos que asignar, cual es el' principal'. Escriba el siguiente comando slo en el servidor principal
drbdsetup /dev/drbd0 primary -o
Compruebe drbd estado de nuevo con servicio drbd estado. Usted debe obtener un estatus similar al siguiente
--== Creating metadata ==-- As with nodes, we count the total number of devices mirrored by DRBD at at http://usage.drbd.org.
The counter works anonymously. It creates a random number to identify the device and sends that random number, along with DRBD's version number, to usage.drbd.org.
* If you wish to opt out entirely, simply enter 'no'. * To continue, just press [RETURN]
success
-----------------
Podemos determinar la uncin de un servidor mediante la ejecucin de los siguientes
drbdadm state r0
The primary server should return;
# drbdadm state r0
Slo el servidor primario: Ahora podemos montar la particin virtual /dev/drbd0, pero primero tenemos que formatear la particin con ext3 con el siguiente comando Despus de reiniciar los dos servers.
mke2fs j /dev/drbd0 mkdir /replica mount /dev/drbd0 /replica
Slo el servidor primario: Ahora vamos a copiar todos los directorios que quieres sincronizar entre los dos servidores a nuestra nueva particin, eliminar los directorios originales y crear enlaces simblicos para reemplazarlos. Directorios de inters;
Recuerde detener cualquier servicio que debe ser controlado por el Heartbeat. Estos servicios sern controlados por Heartbeat en el servidor que tiene el control
chkconfig asterisk off chkconfig mysqld off chkconfig httpd off
Ahora tenemos que crear tres archivos de configuracin: ha.cf authkeys haresources
Editar el archivo /etc/ha.d/ha.cf. Este es un sencillo archivo de configuracin que proporciona todas nuestras funcionalidades requeridas.
En el servidor slave: nano /etc/ha.d/ha.cf debugfile /var/log/ha-debug logfile /var/log/ha-log logfacility local0 keepalive 2 deadtime 20 warntime 10 initdead 40
udpport 694 bcast eth0 192.168.137.101 auto_failback off node master.telefonicanet.com node slave.telefonicanet.com Editar el archivo / etc / ha.d / haresources. Aqu es donde se especifica que es nuestro servidor principal, el nombre de la particin DRBD vamos a montar y donde, nuestra flota direccin IP(10.1.1.3 en este ejemplo en eth1 con una mscara de subred de 24 bits) y los scripts de init.d se pondr en marcha durante una conmutacin por error o un cambio (fonulator, asterisco, mysqld,httpd)
Editar el archivo / etc / ha.d / authkeys. Esto proporciona un nivel de seguridad y autenticacin entre los nodos.
nano /etc/ha.d/authkeys
auth 1 1 sha1 password123456
B!gb@dUndUglIp@$$werd
Cambiar permisos en el archivo / etc / ha.d / archivo authkeys
chmod 600 /etc/ha.d/authkeys
Configurar heartbeat para iniciar en el arranque
chkconfig --addheartbeat
Reinicie drbd en ambos servidores
service drbd restart
Compruebe que ambos servidores se encuentran actualmente en estado de secundaria
drbd adm state r0 Result should be Secondary/Secondary on both
Restaurar heartbeat
service heartbeat restart
Espere un momento se vuelven a comprobar el estado de los servidores.
Procederemos a copiar dentro de /replica la data que queramos replicar, incluyendo archivos de configuracin de servicios, en el caso de Elastix serian los siguientes directorios:
tar -zcvf var-lib-asterisk.tgz /var/lib/asterisk tar -zxvfvar-lib-asterisk.tgz rm -rf /var/lib/asterisk ln -s /replica/var/lib/asterisk/var/lib/asterisk
tar -zcvfusr-lib-asterisk.tgz /usr/lib/asterisk tar -zxvfusr-lib-asterisk.tgz rm -rf/usr/lib/asterisk ln -s /replica/usr/lib/asterisk/usr/lib/asterisk
tar -zcvfvar-spool-asterisk.tgz /var/spool/asterisk tar -zxvfvar-spool-asterisk.tgz rm -rf/var/spool/asterisk ln -s /replica/var/spool/asterisk/var/spool/asterisk
tar -zcvfvar-lib-mysql.tgz /var/lib/mysql tar -zxvfvar-lib-mysql.tgz rm -rf/var/lib/mysql ln -s /replica/var/lib/mysql/var/lib/mysql
tar -zcvfvar-log-asterisk.tgz /var/log/asterisk tar -zxvfvar-log-asterisk.tgz rm -rf/var/log/asterisk ln -s /replica/var/log/asterisk/var/log/asterisk
Recordar de reiniciar el servicio de mysql una vez finalizado este paso
Acordarse de que para declarar como secundario hay que desmontar la unida /replica) y antes de
desmontarla detener el servicio de mysqld
umount /replica
Ahora se debe proceder a instalar Heartbeat, que es el software que hace el cluster propiamente.
Configuracion de Heartbeat
Acordarse de apagar los servicios que se iniciaran con el heartbeat chkconfig asterisk off chkconfigzaptel off chkconfigmysqld off chkconfighttpd off
Esto se hace ya que el Heartbeat iniciara estos servicios cuando el servidor sea master. Debemos copiar los archivos de configuracin de Heartbeat (http://www.linux/- ha.org/) de la documentacin que viene con el paquete al directorio de configuracin /etc/ha.d, asi:
La particin /replica solo se montara en el servidor cuyo estado sea Primario, es decir, si por algn motivo el servidor master-elastix.com falla entonces slave- elastix.com asumir el estado de Primario y por ende levantara la particin /replica, la cual contendr la informacin replicada entre ambos equipos.
Esperar a que termine de hacer la sincronizacin de los dos servidores, este proceso se puede observar con el comando:
watchcat /proc/drbd
Cuanto tenemos los dos nodos en modo stand alone, con un cs:StandAlonest:Secondary/Unknownds:UpToDate/DUnknown lo ms probable es que tengamos que realizar una re sincronizacin de la data, para ello basta con ejecutar:
En el servidor que no est UpTodate
drbdadm discard-my-data connectall
Luego en el servidor que esta UpToDate
drbdadmconnectall
Los nodos empezaran a re-sincronizarse, transfiriendo los datos desde el nodo con datos OK, al nodo con los datos corruptos.
chkconfig asterisk on chkconfig mysqld on chkconfig httpd on
ANEXO 7
MARCAS Y COSTOS DE TELEFONOS IP
ANEXO 7.
MARCAS Y COSTOS DE TELEFONOS IP
Los telfonos IP son dispositivos de conmutacin de paquetes utilizados en la en la telefona de voz sobre IP, los cuales son telfonos que fsicamente son normales, con apariencia tradicional donde estos incorporan un conector RJ45 para conectarlo directamente a una red IP en Ethernet, estos dispositivos no pueden ser conectados a lneas telefnicas normales, estos terminales utilizan tecnologa Voz IP y normalmente pueden realizar funcionalidades avanzadas como lo es llamada en espera, transferencia de llamada, se configuran desde los mens del propio telfono o por interfaz Web y entre otras.
Telfono IP Marca Costo Telefono Cisco Sip Phone 3911 $102 Grandstream Telefono Ip Gxp280 1-line Voip Sip $108 Telefono Ip Grandstream Gxp2000 $145,24
Telfono Ip Itp-5121d Samsung $200 Telefono Ip Linksys 2 Or 4 Lineas Ip $250
Cisco IP Phone 7912G $150 Ip Analog Gateway Gxw4008 Fxs $ 388
Fuente: http://articulo.mercadolibre.com.ec/
Algunos telfonos como lo detallamos anteriormente disponen de dos conectores RJ-45 e implementan funciones de switch, de esta forma no es necesario instalar cableado nuevo para los nuevos terminales. Los telfonos IP en cierta forma se estn pareciendo a los telfonos mviles por los tipos de accesorios que estos traen consigo como
Fuente: http://www.hostname.cl
Adaptadores analgicos IP Los adaptadores IP son dispositivos de conexin que permiten aprovechar los telfonos analgicos actuales, transformando su seal analgica en los protocolos de Voz IP. Existen diferentes tipos de adaptadores entre los cuales esta el ATA, FXS17, FXO18 que son considerados como gateway IP ATA. Adaptador para Telfonos Analgicos (ATA) Un adaptador para telfonos analgicos (ATA) o a futuro, adaptadores telefnicos (TA), conectan un telfono ordinario a una red de VoIP. Un ATA tiene un conector RJ11 (el conector de telfono) y un RJ45 (el conector de red o Ethernet). Un ATA funciona como si fuera un adaptador FXS. Este dispositivo por un lado habla con el telfono analgico y por el otro opera en modo digital con la red de voz IP. Los ATAs hoy en da suelen ser suelen ser ms baratos y al ser ms pequeos suelen ser ms fciles de nacionalizar en las aduanas. Otra de las ventajas de usar un hardware ATAs, es
que se puede conectar cualquier tipo de dispositivo telefnico a la red IP, por ejemplo, se pueden conectar una cabina telefnica (de monedas o tarjeta), un fax o un telfono inalmbrico. El Analog Telephone Adapter (ATA), es el caso ms normal, tienen un conector FXS para telfono analgico normal y envan por Voz IP a travs del conector LAN, soportan SIP normalmente. En la figura siguiente, se puede describir un adaptador de los mas usados actualmente por la telefona IP consta de dos puertos FXS con conectores RJ 11 y un puerto ethernet con un conector RJ 45 el cual se encarga de permitir el paso de la entrada de los datos para que se haga la conversin digital- anloga o viceversa, despus saliendo por los dos puertos FXS para un telfono normal con esto se logra el aprovechamiento de terminales convencionales.
Dispositivo Marca Costo
Grandstream Handytone 286 Adaptador Ata Fxs - Voip $77 Adaptador ATA marca Linksys $120
Fuente: http://articulo.mercadolibre.com.ec/ Softphones Son programas que permiten llamar desde el ordenador utilizando tecnologas Voz IP, los cuales se ejecutan en estaciones o servidores de trabajo permitiendo establecer llamadas de voz sobre el protocolo IP. Este tipo de dispositivo o software de comunicacin es muy esencial a la hora de no querer colocar telfonos ni otro elemento de comunicacin para esta tecnologa como lo es la voz IP, en la Figura siguiente, podemos establecer los diferentes tipos softphones, los cuales son lo ms
utilizados en la actualidad. Estos elementos son de gran importancia para un red de telefona IP por que permiten la comunicacin al igual que cualquier otro telfono comn, estos software o dispositivos IP permiten una reduccin de costo a la hora de la implementacin, por loque hay algunos elementos de estos que no tienen licencia y son software libres. Los softphones, son una alternativa al uso de equipos dedicados (fsicos) de VoIP. Estos programas funcionan en cualquier ordenador personal. El nico requerimiento es tener una tarjeta de sonido en funcionamiento y estar seguro de que el cortafuegos instalado en tu mquina no est bloqueando a la aplicacin. Si se desea reducir el ancho de banda usado por las conversaciones, se puede elegir un soft phone que tenga soporte para el protocolo IAX2, en donde se pueda activar un codec de alta compresin.
X-Lite Zoiper Las caractersticas Principales de estos tipos de software de comunicaciones son: Integracin con el entorno. Icono en systray, dock. Aviso visual de llamadas entrantes. Integracin con plataformas de acceso y validacin de usuarios (LDAP). Importacin / Exportacin de datos: libretas de contactos en XML. Soporte de varias conversaciones simultneamente y en algunos casos de varias lneas
BIBLIOGRAFIA
1.- BARRIOS J., Alcance libre implementacin de servidores con GNU/Linux., Mxico - Mxico., s. edt., 2007., Pp. 491 2.- BONILLA, M y otros., Arquitecturas distribuidas como solucin a sistemas demandantes de servicios de uso crtico considerando factores de seguridad, rendimiento y disponibilidad., Colombia - Bogota., s. edt., 2011., Pp. 120 3.- LANDIVAR E., Comunicaciones unificadas con Elastix., Mxico - Mxico., s. edt., 2009., Pp. 256 4.- LANDIVAR E., Comunicaciones unificadas con Elastix., 2a. ed. Mxico - Mxico., s. edt., 2009., Pp. 218 5.- LOPEZ, J. y otros., VoIP y Asterisk : Redescubriendo la telefona., Mxico - Mxico., Alfaomega., 2009., Pp. 348 6.- VAN J. y otros., Asterisk The Future of Telephony., 2a. ed. Washington - United States., OReilly Media., 2007., Pp. 604 7.- BIND es.wikipedia.org/wiki/BIND [ 2011/11/10 ]