Capítulo 4: Escenario de Trabajo red VoIP y Análisis de...

MIGRACIÓN DE UN SISTEMA DE TELEFONÍA EN PRODUCCIÓN HACIA VOIP CON ASTERISK 52

Capítulo 4:

Escenario de Trabajo red VoIP y

Análisis de Soluciones


4. ESCENARIO DE TRABAJO DE RED VOIP Y ANÁLISIS DE SOLUCIONES

4.1. Situación inicial y metodología de trabajo. En la actualidad coexisten en Persan dos redes: una de datos IP con un núcleo Ethernet y un acceso WI-FI desde las naves, y una de telefonía analógica con una centralita propia y terminales DECT en algunas naves. Estas redes son independientes. Cada red ha sido desplegada de manera incremental en base a necesidades de cobertura y es mantenida de forma independiente, presentando cada una de ellas una serie de limitaciones que ya se detallaron en el capítulo 1. La solución requerida es el diseño de una red con garantías suficientes para el transporte de voz que elimine la dependencia de la red de telefonía. Se diseñará una única red de transporte IP que integre los servicios actuales de voz y datos y que permita añadir nuevos servicios y redes de acceso. La arquitectura del sistema que se desea implementar es similar a aquella de las redes de próxima generación tal y como las define la ITU-T en su serie de recomendaciones Y. Es decir, un núcleo de transporte o backbone IP con garantías de calidad de servicio (QoS) conectado a una serie de redes de acceso (en nuestro caso Wi-Fi, ethernet y la red de telefonía existente) y un estrato de control de servicios independiente de los estratos anteriores. Esto se muestra en la siguiente figura, donde se pueden distinguir los tres pilares del proyecto: núcleo de red de transporte IP, red acceso wifi, servicios multimedia.

Figura 11. Componentes de la Solución

IP Core Network

Ethernet

Wi-Fi(ruido)

Servicios necesarios en la

Red: QoS, Fiabilidad ,

ServicioVoIP

ServicioTelediag/Teleconf

ServicioLocalización

Wifi...

Inter-operación entre Terminales Heterogéneos

SERVICIOSAVANZADOS:

MultimediaIPLocalización

RED NÚCLEO:

QoSFiabilidad

RED ACCESO:

Diseño Wi-Fi entorno indust.

DECT(ruido)

GateWay


La Figura 11 se muestra esquemáticamente los componentes principales del sistema en diversos estratos. En el estrato inferior tendríamos las redes actuales y de acceso con sus respectivos terminales. Estas redes cursan y reciben tráfico a través de un núcleo de red IP (Ethernet conmutada) que a su vez ofrece dos servicios claves a las aplicaciones: fiabilidad (restauración automática y diseño redundante) y control de prestaciones (retardo, pérdidas y ancho de banda) para aplicaciones de tiempo real (voz y vídeo). Finalmente, el estrato de los servicios se plantea como un plano que permite la implementación y el control (contabilidad, autorizaciones, seguridad, calidad del servicio, grupos, etc…) de las aplicaciones ofrecidas. A este respecto en el proyecto se plantean la implementación de VoIP, televigilancia, telediagnóstico y de un servicio de localización y control de presencia basado en WiFi. Una vez se conocen los requisitos que debe cumplir este proyecto es necesario precisar que:

1. Para la integración de la red de datos y la red telefónica (solución relativa a este proyecto) existirá una fase de convivencia entre las dos tecnologías previa a la migración completa a IP.

2. Una vez sea puesto en marcha y su funcionamiento sea relativamente normal se migrará el conjunto existiendo al final como solución única la red VoIP.

3. Para el estudio de la solución adoptada se plantearán dos posibles escenarios, comparándolos en función de sus características y ponderando dichas características en función de las necesidades de este escenario. Este estudio se detalla en el Anexo III. Análisis de la solución propuesta para Persan .

Para la adopción de una solución que cumpla con las premisas necesarias, será necesario realizar este trabajo en distintas fases. En primer lugar, se realizará un estudio de la situación actual de la red y se planterarán posibles soluciones atendiendo a los distintos elementos de estudio a la hora de seleccionar una topología de red. Una vez adoptada una solución se trabajará en funcion de dicha arquitectura. Este estudio se encuentra recogido en el Anexo III, ‘Escenario de Trabajo y análisis de posibles soluciones’. Una vez seleccionada la topología, será necesario analizar las distintas ofertas para la elección de un sistema operativo que satisfaga las necesidades de este proyecto. Además se procederá a la instalación del mismo así como la configuración de Asterisk en alta disponibilidad. Tras la instalación se llevarán a cabo una serie de pruebas que corroboren el correcto funcionamiento del mismo. Una vez esté instalado tanto Asterisk como el sistema operativo sobre el que se apoyará, se configurará el plan de marcado para ofrecer una serie de servicios (tanto básicos como avanzados). Para cada uno de los servicios, se realizan pruebas de funcionamiento que comprenden una serie de llamadas para comprobar la calidad del servicio obtenido. Llegados a este punto, una vez los servicios básicos y avanzados funcionan y son capaces de ofrecer a los usuarios mayor número de prestaciones que aquellas de las que disponían, se procederá a la interconexión con los primarios para permitir la comunicación con la red fija y móvil. Tras esto, se realizarán una serie de pruebas que verifiquen el correcto funcionamiento del plan de marcado así como que las llamadas realizadas llegan al destino correcto. Antes de proceder a desglosar cada una de las fases de trabajo, se considera necesario un estudio de la arquitectura de red inicial, intermedia y final.


4.2. Estudio de la Arquitectura de Red Llegados a este punto se ha determinado por un lado que para la integración de la red de voz y datos se usará la red IP haciendo uso del protocolo SIP para señalización, que existirá un periodo de convergencia en el que coexistirán la red de voz actual con la centralita Ericsson y la nueva red de voz IP, y que el nexo de unión entre ambas y que posteriormente sustituirá a la centralita analógica será Asterisk. Se considera necesario en este punto analizar la arquitectura de protocolos de los distintos escenarios, es decir, del escenario inicial y del impacto de la inclusión de Asterisk. Para todo ello, se van a analizar por un lado los elementos que existen en la red, la funcionalidad de cada uno de ellos, y los protocolos que soportan. A la hora de profundizar sobre estos protocolos se separará en dos planos:

� Plano de Control: Se encarga de la conexión en la red (establecimiento y terminación), llamadas multimedia y control de llamadas ya establecidas así como de la provisión de servicios suplementarios.

� Plano de Usuario: Se ocupa de la transferencia de información de usuario de

forma transparente. Además de esta información se detalla el paso de mensajes necesarios para el establecimiento de una llamada en cada uno de los escenarios.

4.2.1. Situación actual.

Descripción de elementos

Inicialmente, la red de voz de Persan estaba constituida por un conjunto de teléfonos RDSI conectados a una centralita que hacía las funciones de interfaz con el exterior de la empresa. Todos estos elementos forman el escenario básico de una conexión a la red telefónica conmutada (PSTN, Public Switched Telephone Network).

Figura 12. Situación actual

PBXBP250

ExtensionesAnalógicas(7/8XXX)

E1 Fijos

E1 Móviles

E1MÓVILES

E1FIJOS

Situación Actual:

Freeset(inalámbricos)


A continuación se profundizará en las características de la red de voz del escenario de partida. Los elementos involucrados son:

� TE1: Es el teléfono o equipo terminal que se conecta a la red. Es el punto donde termina la señalización de usuario por lo que maneja protocolos. Cada uno de los teléfonos está identificado con un número de extensión con la nomenclatura 7XXX/8XXX.

� NT2: Grupo funcional representado por la actual centralita Ericsson BP 250.

Realiza funciones de nivel dos del modelo OSI (Open System Interconnection). Se encarga de la conmutación y concentración. Gestiona todas las llamadas entre las extensiones de la empresa (extensión que identifica cada uno de los TE1).

� NT1: Aísla al usuario de la tecnología de transmisión que se usa en el bucle

de abonado. Es un dispositivo de capa física. Hay algunos casos en los que en lugar de un teléfono RDSI (TE1) se cuenta con un teléfono analógico por lo que sería necesario hacer uso de un ATA (Analog Telephone Adapter) para conectarlo en a la centralita. Los terminales están conectados a la centralita en paralelo mediante un acceso básico (formado por dos canales B de 64Kbps y un canal D de 16 Kbps) y son dúplex, de forma que se puede transmitir y recibir a la vez. La conexión de la centralita con la PSTN (de forma similar que con la red GSM) se realiza mediante un enlace primario formado por 30 canales B y un canal D (todos ellos de 64Kbps).

Arquitectura de protocolos

El análisis de los protocolos se hará desde el plano de control y el plano de usuario. Plano de Usuario Para los medios, solamente será necesario indicar el códec vocal usado y los elementos que lo usan, puesto que muchos elementos de la red tienen funciones que se reducen al plano de señalización. Para la voz se usa el códec G.711. Plano de Control Para la señalización se usan los protocolos clásicos para una red PSTN. Estos protocolos llegan hasta el nivel de red. A continuación se hará un breve resumen de ellos:

1. Nivel Físico: Se hace uso de dos protocolos diferentes atendiendo al tipo de enlace con que se conecta al siguiente elemento. Para la conexión entre los terminales y la centralita, se usan enlaces básicos (2 canales B + canal D de 16Kbps), este tipo de enlace atiende al protocolo I.430. La conexión con la red se hará a través de un enlace primario formado por 30 canales B. Este enlace primario atiende al primer nivel de la jerarquía PDH, E1, a 2.048Mbps y usa el código de línea HDB3. El nivel de enlace y red harán uso de los respectivos canales D.

2. Nivel de Enlace: Es el encargado de llevar la información entre dos equipos

adyacentes, corrigiendo errores y permitiendo compartir la capa física entre múltiples entidades de nivel de enlace. Se ocupa además de la sincronización de las tramas. Se usa el protocolo LAPD (Link Access Protocol for D-channel), es un protocolo de control de enlace de datos para los


canales tipo D que son usados para transportar información de control y señalización y que nunca se separan de los canales B que transportan datos de usuario. Se encuentra recogido en el ITU-T Q.921.

3. Nivel de Red: Se usa el protocolo Q.931, protocolo de control y señalización

de la capa de red RDSI. Este protocolo usa el canal D a través del SAPI 0 para controlar las llamadas que se transmiten por los canales B: establecimiento, mantenimiento y liberación de conexiones de red. Además proporciona mecanismos de señalización usuario-usuario y control de servicios suplementarios.

A continuación se muestra dicha arquitectura de protocolos.

Figura 13. Arquitectura de protocolos. Plano de Control y Usuario.

Escenario actual.

Paso de Mensajes

Cada uno de los TE1 arriba representados, está identificado por un número de extensión, que será el que los demás usuarios de la empresa deberán marcar para poder ponerse en contacto con ellos. En este apartado, se describirá el intercambio de mensajes entre los elementos implicados en la conexión. Existen dos situaciones posibles donde solo se ven implicados los teléfonos y la centralita Ericsson y otra en la que un usuario externo realiza o recibe una llamada desde la red. A continuación se muestran las dos situaciones. Se considera la llamada entre extensiones una simplificación del paso de mensajes de una llamada externa.


SP A SP B

TE 2 954236435

TE 1954998350

Descuelga

Invitación a marcar

Marca 954236435

SETUP (954236435)

SETUP ( CallRef,954236435)

IAM

ACM

CALL PROCEEDINGCALL PROCEEDING

SETUP (954236435)

Timbre

ALERTING

ALERTING

ALERTING

Tono Llamada

Descuelga

CONNECT

ANM

CONNECT

CONNECT

Cese Tono

CONNECT ACK

CONNECT ACK

CONNECT ACK

CPG

DIALOGO

Figura 14. Paso de mensajes llamada con PSTN


Cuando el usuario del equipo TE1 descuelga, suena el tono que le invita a marcar el número de teléfono al que quiere llamar. Una vez se han introducido todos los dígitos, el TE1 comienza la secuencia enviando un SETUP que será recogida por la Centralita Ericsson, decidiendo en función del número recibido donde tiene que desviar la llamada. En el mensaje el Terminal TE1 incluye la información para el establecimiento de la llamada como es la capacidad portadora y la identidad del llamando. Si se trata de una llamada a otra extensión él mismo enviará la llamada (mediante el intercambio con el Terminal de una serie de mensajes) al teléfono destino. Si el número marcado es un número externo a la empresa, será necesario enviar un mensaje a la red para pedir solicitar el establecimiento de la llamada con el número correspondiente. Los terminales de usuario pueden programarse de dos maneras en función de cómo se envíe el número llamado. En Figura 14 se ha considerado el modo bloque, es decir, se envía el número completo en un único mensaje. La centralita envía un mensaje SETUP a la red, siendo recibido por la central de conmutación correspondiente. Esta central, chequea en primer lugar si el contenido del mensaje es válido y se autoriza al usuario a usar la capacidad portadora requerida si el canal B está disponible y a continuación decide, en función del número recibido cómo encaminar la llamada, enviando un mensaje IAM a la siguiente central que será el siguiente tránsito del camino hacia el destino. Este mensaje se usa para indicar la toma de un circuito de salida y transmitir el número y otras informaciones relativas al encaminamiento y tratamiento de una llamada. Una vez recibe este mensaje, la central B sabe cómo encaminar la llamada hacia el destino y envía los siguientes mensajes:

� Por un lado, envía a la central SPa un mensaje ACM para indicarle que ha recibido todas las señales necesarias para encaminar la llamada hacia el destino. A su vez la central enviará un mensaje CALL PROCEEDING (lo emite la red para informar al usuario que tiene toda la información necesaria para encaminar la llamada). .

� Un mensaje de SETUP al TE llamado para iniciar la conversación. Este

mensaje no es el mismo que el enviado a la red por parte del usuario (la señalización usuario-red no se prolonga más allá del interfaz de usuario), sin embargo contiene prácticamente la misma información, a excepción de la referencia de llamada y algunos atributos de acceso En este momento, suena el teléfono llamado y éste envía hacia atrás un mensaje de ALERTING para indicar que está sonando, y al usuario final le llegará el tono de llamada a la espera que el número llamado descuelgue.

Una vez el teléfono es descolgado, el teléfono llamado envía un mensaje de CONNECT para indicar que la llamada ha sido aceptada. El mensaje que envía SPb a SPa es un mensaje de ANM donde le indica que la llamada ha sido respondida, que se inicia el cómputo de la tasación a aplicar y que se inicia la medición de la duración de la llamada. La central SPa envía el correspondiente CONNECT hacia atrás que pasará de la centralita al Terminal y el usuario percibirá como el cese del tono de llamada y el establecimiento del diálogo. A cada CONNECT se le responde con un mensaje de CONNECT ACK.


4.2.2. Situación Final Deseada. En la Figura 15 se muestra el escenario tal y como quedará tras la finalización del trabajo. Según se vio en el apartado de ‘Elección de la topología de Red’ , la solución aportada por el escenario 2 facilitaba la migración definitiva a IP de la red de voz. Sin embargo, para la realización de todas las pruebas y el trabajo diario se ha usado una configuración diferente, la presentada en el escenario 1 del mismo estudio puesto que la tarjeta de E1s disponible para usar tenía solamente 2 puertos y no permitía el montaje de este escenario (eran necesarios 4 puertos). En los siguientes apartados, se trabajará con la situación denominada de ‘estudio’ correspondiente al escenario descrito en el apartado de “Elección de topología”. Durante el desarrollo del trabajo, se consideró que el impacto producido ante un cambio de topología y las modificaciones en la configuración de Asterisk eran mínimos por lo tanto, se detallará la configuración de los ficheros y la arquitectura de protocolos en función del escenario de estudio. Los cambios a realizar en la configuración de los ficheros que se deberán realizar en el paso de migración completa a VoIP no se detallan en esta memoria.

Figura 15. Escenario Final deseado


4.2.3. Situación Estudio. Para la adopción de esta solución, es importante no olvidar el hecho de que se pretende alcanzar la integración de la red de voz y datos dentro de una misma arquitectura. La arquitectura final que se dará en este escenario será como el mostrado en Figura 16, donde coexistan diversas Vlans haciendo uso de los recursos IP de los que dispone la empresa.

ACL

AC

LACL

ACL

ACL

Figura 16.Escenario de estudio

Para alcanzar esta solución entrará en juego Asterisk. Es importante recordar las dos principales funciones que puede desempeñar Asterisk, por un lado, la función de centralita IP, y por otro lado la de Gateway. La flexibilidad que ofrece a la hora de adaptarlo al escenario es clave para el desarrollo de un proyecto con tantos cambios de topología.

Descripción de los elementos.

A continuación se muestra el escenario genérico de la situación de estudio.


BRI

BRI

Figura 17. Escenario genérico de estudio

Para la descripción de estos elementos así como los protocolos que usen será necesario indicar en primer lugar el funcionamiento básico de este escenario. Para toda llamada realizada por un teléfono RDSI (aquellos conectados directamente en la centralita Ericsson con extensión 7XXX/8XXX) que no vaya dirigido a otra extensión del mismo tipo saldrá por el enlace PRI que conecta la centralita Ericsson con Asterisk. Estas llamadas podrán ser tanto a extensiones SIP (de la red VoIP) como llamadas al exterior a través de la red telefónica y será Asterisk quien se encargue de encaminarlas a su destino haciendo uso del correspondiente plan de marcado. Toda llamada realizada por un teléfono IP (configurados en Asterisk y con código de extensión 3XXX) será encaminada por Asterisk, pudiendo ser enviadas tanto a un destino SIP, a un número con extensión 7XXX o a la red telefónica. En cualquier caso será Asterisk quien se encargue de este encaminamiento. Una parte de los elementos aquí descritos se han presentado ya en el apartado de “situación actual”, queda por lo tanto hablar de los nuevos elementos de la red IP. Es importante resaltar que debido a las múltiples funcionalidades de Asterisk, dependiendo de la llamada estudiada, tendrá funciones bien de NT2, bien de gateway.

� Asterisk: servidor que se conecta a la centralita Ericsson haciendo ahora las funciones de de NT2, centralita IP, o de gateway en función de la llamada que se esté cursando. Cada una de estas funcionalidades se verá con detenimiento en cada uno de los casos.

� Teléfono IP: Un terminal IP es un dispositivo que permite realizar una

comunicación utilizando una red IP ya sea mediante red de área local o a través de Internet y llevan a cabo una comunicación de paquetes de datos en los que se transporta voz o vídeo (VoIP).


Arquitectura de Protocolos

Para el estudio de la arquitectura de este escenario, se van a plantear las posibles llamadas y en función de ellas se estudiará tanto las torres de protocolo como el intercambio de mensajes necesario para que estas se lleven a cabo.

� Llamada entre extensiones 7XXX: Esta posibilidad es similar a la de la situación actual.

� Llamadas entre extensiones 7XXX y PSTN: A estudio � Llamadas entre extensión 7XXX y 3XXX: A estudio � Llamadas entre extensión 3XXX y PSTN: A estudio

Llamada entre una extensión 7XXX y la red PSTN.

Los protocolos que aparecen son los mismos usados en la situación actual. Asterisk realiza la misma función que un NT2 conectado a la red.

Figura 18. Arquitectura de protocolos. Plano de Control y Usuario.

Escenario a estudio.

Llamada entre una extensión 7XXX y 3XXX.

Para poder realizar una llamada entre un teléfono conectado a la centralita Ericsson y un teléfono VoIP es necesario que Asterisk haga las veces de Gateway. Asterisk no es una pasarela monolítica, sino modular, sin embargo no necesita de MGC (Media Gateway Control) para funcionar (en este escenario en particular). Plano de Usuario La primera parte, hasta llegar a Asterisk es exactamente igual que en las situaciones anteriores. Asterisk es un gateway de medios por lo que tendrá la capacidad de tratar estas llamadas haciendo uso del protocolo RTP (Real Time


Protocol) y empaquetar la llamada en datagramas. Es necesario recalcar que no se hará transcodificación del códec de voz de G.711 a G.729 (la justificación se encuentra en el Anexo II “"Codificación de voz e imágenes"), por lo que a pesar de cambiar le resto de la torre de protocolos las muestras de voz mantienen el códec con el que se han codificado. Plano de Control Al igual que en el plano de usuario, los protocolos empleados hasta llegar a Asterisk ya han sido mencionados. También se ha profundizado sobre los protocolos que se emplean dentro de la red IP.

TE1

TE1

TE1

BRI

BRI

BRI

PRI

VoIP

PLANO CONTROL

PLANO USUARIO

NT2

Figura 19. Escenario llamada de7xxx y 3xxx .

Llamada entre extensión 3XXX y PSTN. Las torres de protocolo para la realización de esta llamada son muy similar a la anterior solo que implica la conexión con centrales de conmutación. No se considera necesario repetir aquí dicho esquema puesto que es un híbrido entre la Figura 18 y la Figura 19.

Paso de Mensajes.

Llamada entre una extensión 7XXX y la red PSTN. En el intercambio de mensajes para el establecimiento de una llamada, solamente habría que añadir al diagrama de establecimiento de llamada del escenario anterior un nuevo SETUP entre la centralita Ericsson y Asterisk y ésta sería la encargada de enviar a la red la petición de establecimiento de llamada, por lo que no se va a estudiar. Llamada entre una extensión 7XXX y 3XXX.


Para la llamada entre extensiones, será Asterisk el que convierta los mensajes que le llegan de la centralita Ericsson (SETUP) en el INVITE propio del protocolo usado (SIP). Todos los mensajes del protocolo SIP se encuentran detallados en el Anexo II.VoIP apartado "Estructura de mensajes". Este paso de mensajes se aprecia en la Figura 20. Llamada entre una extensión 3XXX y PSTN. Al igual que en el caso de las torres de protocolos, el paso de mensajes sería un híbrido entre las dos primeras situaciones. Cuando el teléfono IP quiere iniciar una llamada o establecer una sesión, mandará un INVITE a Asterisk. Asterisk tras analizar el destinatario de la llamada (usando el plan de marcado) mandará un SETUP a la red, indicando el número llamado y el resto de parámetros necesarios. La red analiza el mensaje que le llega y tomará las medidas necesarias para encaminar la llamada hasta el destinatario correcto. Cuando este descuelgue, devolverá a la última central de conmutación un CONNECT, éste a su vez recorrerá el camino en dirección inversa mandando mensajes ANM de establecimiento de llamada con éxito a todas las centrales por las que pasó hasta llegar a la del borde de la red a la que está conectada Asterisk. Esta recibirá un CONNECT y enviará un 200OK al Proxy para que se lo enviara al Terminal. Cuando este recibe el 200 OK envía un mensaje ACK directamente a Asterisk. Una vez ahí empieza el intercambio de medios Terminal IP-Asterisk/ Asterisk –TE de PSTN.


Figura 20. Paso de mensajes llamada 7xxx y 3xxx


4.3. Desarrollo de la migración del sistema en producción a VoIP A continuación se desglosarán las distintas fases de las que se hablaba en el apartado anterior.

4.3.1. Instalación del Sistema Operativo y Configur ación de Asterisk en alta disponibilidad.

El primer paso para la instalación de la centralita Asterisk es decidir que sistema operativo se usará. Originalmente fue desarrollada para el sistema operativo GNU/Linux, pero también se distribuye en versiones para los sistemas operativos BSD, MacOSX, Solaris y Microsoft Windows, aunque la plataforma nativa (GNU/Linux) es la mejor soportada de todas. Por este motivo se elegirá Linux como S.O. No existe ninguna recomendación por parte del proyecto Asterisk en cuanto a qué distribución de Linux utilizar. La distribución Debian Etch 4.0 será la elegida en este caso. Se trata de la última versión estable (a fecha de elaboración de este documento). Los pasos para la instalación del S.O así como la compilación y puesta en servicio de Asterisk se detallan el en Anexo III. Fase 1 Instalación del SO. Asterisk se configura en alta disponibilidad. La alta disponibilidad es una característica que permite a un sistema asegurar un cierto nivel de continuidad operacional. Se basa en la replicación de elementos para conseguir la recuperación ante fallos. En nuestro caso, el elemento a replicar es el servidor Asterisk. Con esta replicación se intenta reducir al mínimo el tiempo de indisponibilidad de servicio. En la se representa como sería la conexión de equipos ofreciendo un servicio de alta disponibilidad.

Figura 21.Configuración de los equipos en alta disponibilidad Cuando cae el nodo que está ofreciendo el servicio, el alternativo debe asumir la responsabilidad, importar los datos necesarios y levantar el servicio. A este proceso, representado en la Figura 22, se le denomina failover. A ese grupo de equipos que confían unos en otros y proporcionan un servicio a pesar de que uno de ellos falle se le denomina cluster.


Figura 22. Proceso de Failover

Soluciones alta disponibilidad

Linux como sistema operativo ofrece una serie de facilidades, para que los sistemas de alta disponibilidad puedan integrarse correctamente. Actualmente existen varios proyectos abiertos que permiten a Linux ofrecer la funcionalidad de alta disponibilidad. Se van a describir las más importantes

� Heartbeat: es el proyecto principal para ofrecer alta disponibilidad en Linux. Consiste en un módulo software que permite diseñar y gestionar un clúster de alta disponibilidad. Permite crear grupos de recursos que se intercambian fácilmente entre nodos. Sus características más importantes son:

� Máximo número de nodos no establecidos. Puede ser usado tanto

para clusters grandes como clusters de menor tamaño. � Motorización de recursos: éstos pueden ser reiniciados o movidos a

otro nodo en caso de fallo. � Mecanismo de cercado para eliminar nodos caídos del cluster � Gestión de recursos basado en directivas, interdependencia de

recursos y restricciones � Reglas basadas en el tiempo permiten diferentes directivas

dependiendo del tiempo. � Varios scripts de recursos (para Apache, DB2, Oracle, PostgreSQL,

etc…) incluidos. � GUI para configurar, controlar y monitorizar recursos y nodos

� Ldirectord y LVS (Linux Virtual Server): LVS permite crear un clúster de

balanceo de carga, en el cual hay un nodo que se encarga de gestionar y repartir las conexiones (nodo master LVS) entre todos los nodos esclavos (slaves) del clúster. El servicio de datos debe residir en todos los nodos esclavos. LVS puede llegar a soportar sin problemas hasta 200 nodos esclavos. En la figura siguiente se muestra un esquema de conexión típico. Ldirectord es un demonio que se ejecuta en el master LVS, que se encarga de testear el servicio de datos de los nodos esclavos y eliminarlos e insertarlos en el clúster dinámicamente, si surge algún problema o si se repone el servicio según sea el caso.


Figura 23. Sistema de alta disponibilidad con LSV

� UltraMonkey: Es una solución creada por VA Linux que se basa en LVS y Heartbeat para ofrecer clusters de alta disponibilidad y balanceo de carga. El nodo master LVS se pone en alta disponibilidad ya que es el único SPOF10 (Single Point Of Failure). Además incorpora una interfaz para configurar el clúster.

� Kimberlite: Creada por Mission Critical Linux, es una solución que soporta

un clúster de 2 nodos. Permite fácilmente, definir un dispositivo de quórum, monitorizar los servicios de datos, así como gestionarlo. Un recurso quorum, es un recurso compartido, que se ha preestablecido en ambos nodos como tal. Este recurso es un recurso exclusivo, sólo un nodo del cluster puede reservarlo. Como este recurso sólo puede ser reservado por un nodo, el nodo que llegue tarde a la reserva del recurso, entiende que debe abandonar el clúster y ceder todos sus recursos. El quórum es utilizado como simplemente, método de decisión. Tras sopesar las distintas opciones disponibles, optamos por Heartbeat que es la solución más testada y fiable de todas las presentadas. Se adapta perfectamente a Asterisk y nos ofrece todas las funcionalidades que se le pueden exigir a un servicio de alta disponibilidad.

Para configurar la alta disponibilidad con Asterisk, se usará Heartbeat. Para como instalar y configurar un cluster de 2 nodos usando heartbeat se consultará el anexo correspondiente.

Pruebas Realizadas

En este apartado se van a realizar una serie de pruebas que verifiquen el funcionamiento del servidor Asterisk y del servicio de alta disponibilidad. Para ello se ha creado una maqueta con dos nodos en los que se ha instalado Asterisk siguiendo los pasos indicados en este documento, de la misma manera se ha realizado la instalación y configuración de heartbeat. Como cliente de VoIP se usará el software Xlite 3.0 que es de libre distribución (aunque no de código abierto). En la Figura 24 se muestra un esquema del escenario de pruebas.

10 Hace referencia a cualquier elemento de nuestro sistema de alta disponibilidad que no esté replicado.


Figura 24. Escenario de Pruebas Se supondrá que los dos servidores están funcionando y que Asterisk-A (Asterix) es el principal, mientras que Asterisk-B (Obelix) se encuentra en espera. Esto se puede comprobar ejecutando ps aux | grep asterisk que nos muestra si el servicio está activo o no. Tras comprobar que sólo Asterisk-A tiene el servicio en marcha, comprobamos que hearbeat está funcionando en los dos nodos con el comando /etc/init.d/heartbeat status. Ahora nos disponemos a configurar el cliente.

La configuración de Xlite es muy sencilla. Tan sólo debemos indicarle un nombre de usuario, que debe existir en la configuración SIP de Asterisk. La dirección IP del servidor Asterisk y la del servidor Proxy. En la Figura 25 se muestra una captura de pantalla.

Figura 25: captura del menú de configuración de Xlite

Como puede verse, la dirección IP del servidor Asterisk es la 172.16.16.57 que corresponde la IP virtual donde se ofrece el servicio.

Asterisk-A Asterisk-B

HEARTBEATIP

172.16.16.55

IP 172.16.16.56

Cliente XLite

IP 172.16.16.12

IP Proxy 172.16.16.57

IP virtual172.16.16.57


Vamos a ver lo que ocurre durante el registro del cliente en el servidor. Para ello utilizaremos el capturador de tráfico Wireshark. Se recuerda que Asterisk-A con IP 172.16.16.55 es el nodo activo. En la Figura 26 se muestra como el cliente, con IP: 172.16.16.12 solicita registrarse a la dirección IP virtual 172.16.16.57 y que es el nodo activo asterisk-A con IP 172.16.16.55 el que contesta a esa petición.

Figura 26: registro de un cliente

En la Figura 27 se muestra que es Asterisk-A el que responde en 172.16.16.55.

Figura 27: conectividad con Asterisk-A

Esta prueba muestra lo que pasa cuando el cliente intenta registrarse y el nodo principal está activo. Vamos a estudiar que pasa cuando éste cae. Para ello deshabilitamos la interfaz de red de Asterisk-A con el comando ifdown eth0 y comprobamos que hemos perdido la conectividad (Figura 28). Tras hacerlo, intentamos hacer una llamada con el cliente. Evidentemente el equipo principal no puede darle servicio así que a no ser que se haya producido el traspaso de competencias hacia el nodo en espera, la llamada no se realizará.


Figura 28: comprobación de pérdida de conectividad

El intento de llamada se hará a la extensión 1000 que es una de las definidas en el contexto demo que se asocia al usuario juan. Para estudiar lo que ocurre, de nuevo capturamos el tráfico (Figura 29) y observamos que la dirección a la que el cliente envía las peticiones es la misma, la 172.16.16.57. Esto es lo lógico porque la configuración de la cuenta del cliente no se ha modificado. A partir del segundo paquete, se puede ver que la dirección del equipo servidor ya no es la de Asterisk-A sino la de Asterisk-B, es decir la 172.16.16.56.

Figura 29: comprobación de traspaso entre servidores Asterisk

Si se quisiéra ver el tráfico de Heartbeat tan sólo habría que buscar paquetes UDP con como puerto destino el 694 (configurado en ha.cf). Con esta prueba certificamos el funcionamiento del servicio de VoIP en alta disponibilidad.

En este apartado se ha explicado la instalación y configuración de un servicio de VoIP en alta disponibilidad utilizando Asterisk como centralita software y Heartbeat como mecanismo de alta disponibilidad. Tras configurar los dos servicios, se ha estudiado su comportamiento usando una maqueta en el laboratorio con dos nodos servidores y un cliente. Las pruebas realizadas [29] muestran un correcto funcionamiento del servicio y representan un primer acercamiento para la puesta en marcha del servicio.


4.3.2. Servicios Básicos En esta fase se van a analizar los distintos servicios que se ofrecerán a los usuarios de telefonía conectados a la centralita Asterisk. Los objetivos principales que se persiguen son dos. En primer lugar ofrecer los mismos servicios que se usan actualmente en Persan con los teléfonos analógicos pero implementados mediante funciones propias de Asterisk. Segundo, apoyándonos en la cantidad de mejoras que conlleva el uso de teléfonos VoIP aprovechar éstas para implementar nuevas funcionalidades.

Descripción de la maqueta

El escenario sobre el que nos apoyaremos en esta sección, se basa principalmente en el uso de Asterisk (trabajando como centralita) y los teléfonos VoIP registrados en él haciendo uso de los distintos servicios. Este es el montaje básico de la maqueta, siendo necesario en algunos servicios añadir elementos adicionales. Estos elementos se detallan en el apartado correspondiente.

Figura 30. Escenario Red VoIP Las características técnicas de cada uno de los equipos de la maqueta básica se describen a continuación:

� Un servidor con Asterisk 1.6 instalado sobre S.O Debian 4.0 Etch. � Tres teléfonos VoIP GrandStream GXP 1200

Los servicios que se expondrán a continuación, se dividen en dos grupos, servicios básicos y servicios avanzados. Dentro de los primeros se agrupan todos aquellos servicios que se han implementado de forma similar a la existente en la empresa (llamada en espera, desvío de llamadas…). Los servicios avanzados agrupan todos aquellos servicios que valiéndose de las ventajas ofrecidas por la telefonía VoIP permiten la integración de distintas aplicaciones existentes (por ejemplo con Outlook…).


El escenario que existe actualmente en Persan, se basa en el uso de teléfonos analógico cuyas funcionalidades son limitadas. Por ello, para usar cualquier servicio como desvío de llamadas, llamada en espera…. ( servicios que aquí se han catalogado como básicos), se hace uso de una serie de combinaciones numéricas que son capaces de ejecutar con el teléfono analógico y que la centralita actual de la que disponen en Persan es capaz de interpretar. Para implementarlo se han mantenido dichas combinaciones (a pesar de que las funcionalidades del propio teléfono te permiten hacerlo de forma automática) para facilitar a los usuarios la transición a la utilización de los nuevos terminales VoIP. Los servicios básicos son los siguientes y se profundizará en ellos en apartados posteriores:

� Llamada a tres � Buzón de llamadas � Desvío de llamadas � Rellamada � Rellamada automática

En cuanto a los servicios avanzados se ha estudiado IVR. Se proponen además otros servicios que abogan por la integración de las distintas herramientas de uso diario en la oficina como es la aplicación DialApplet.

Descripción de los servicios básicos

Como se ha explicado anteriormente, los servicios básicos engloban todas aquellas funciones que implementadas en Asterisk que permiten a los usuarios trabajar de forma similar (usando las mismas combinaciones de dígitos) a la que tenían anteriormente. En el apartado siguiente se detallan cada uno de estos servicios, realizándose todos ellos sobre la maqueta anteriormente presentada. La parte referente a la configuración de los equipos aparece detallada en el anexo correspondiente a esta actividad.

� Llamada a tres

Este servicio permite a un usuario hablar por teléfono con dos personas al mismo tiempo y por la misma línea. La implementación en Asterisk se realiza a través de conferencias o rooms. El funcionamiento es el siguiente, cuando un usuario quiere establecer una llamada a tres, marcará el número de teléfono que se configure para acceder a dicha conferencia (por ejemplo el 600). Los dos usuarios siguientes actuarán exactamente igual. Una vez los tres usuarios formen parte de la conversación, si un cuarto usuario intenta acceder a la conversación establecida, se le deniega el permiso. Inicialmente los rooms de Asterisk están pensados para cualquier número de usuarios, sin embargo, para ajustarse a los servicios originales se restringe el acceso a tres. Se pueden crear tantos rooms como se consideren necesarios.

� Buzón de llamadas

Este servicio se pone en uso cuando un usuario realiza una llamada y el número con el que desea establecer la comunicación está ocupado o no contesta la llamada.


En ese momento, se activa un buzón de voz donde se permite que el llamante deje un mensaje de voz que luego escuchará el llamado. Se configura un buzón de voz para cada una de las extensiones, de forma que son independientes y privados, pudiendo especificarse para cada uno de ellos una clave de acceso que evite que otros puedan acceder a él. Sobre este servicio se han realizado algunas modificaciones respecto al servicio ofrecido por la antigua centralita. Esta modificación consiste en el hecho de que cuando un usuario externo llama a una extensión y el llamado no contesta al teléfono, el buzón de voz en el que anteriormente dejaba el mensaje era el buzón de voz de la operadora. Ahora, el mensaje se almacena directamente en el buzón privado de cada extensión llamada.

� Desvío de llamadas

Este servicio se presenta como uno de los más usados dentro de los servicios básicos. La utilidad de este servicio radica en el hecho de que en el momento en que un usuario va a cambiar de ubicación temporalmente (por ejemplo de oficina) puede desviar las llamadas a un número de extensión que seleccione. De esta forma, todas las llamadas que se efectúen a la extensión original serán reencaminadas hacia el número seleccionado por el usuario sin necesidad de ninguna otra acción. Para seleccionar este servicio, se ha configurado Asterisk manteniendo la combinación de dígitos *21*XXXX que se usaba anteriormente en Persan, donde XXXX hace referencia a la extensión a la que desean encaminar las llamadas en el desvío. Para desactivar este servicio se marcarán #21#.

� Rellamada

Este servicio se utiliza cuando un usuario quiere volver a llamar al último número llamado. Para ellos pulsará la combinación *** y Asterisk intentará establecer la llamada con ese número (está almacenado en la base de datos de Asterisk, AstDB). Este número puede ser tanto una extensión como un número externo.

� Rellamada automática

Este servicio es simplemente una especificación del explicado en el apartado anterior. Cuando un usuario realiza una llamada y el llamante está ocupado, tiene la opción de indicarle a Asterisk que desea que cuando el número al que ha llamado quede libre, se intente de nuevo la comunicación. Para ello el llamante pulsará el 5 una vez escuche el tono de ocupado y colgará. Cuando Asterisk detecte que el número al que llamó está libre, iniciará la llamada a ese número, sonando el terminal correspondiente a ese número y a la vez el del número llamante. Una vez el llamado y llamante descuelguen se establece la comunicación.

Descripción del escenario de pruebas

El escenario de pruebas sobre el que se trabajará es el que se muestra a continuación.


Figura 31. Escenario de Pruebas servicios básicos

Configuración de los equipos

La configuración de los equipos se detalla en el Anexo III. Escenario de trabajo y análisis de posibles soluciones apartado "Servicios Básicos"

Resultados

Para comprobar que todos los servicios implementados funcionan correctamente se realizaron 10 pruebas para cada uno de los servicios ofrecidos usando los tres teléfonos implicados en la maqueta. La calidad del servicio fue evaluada por los participantes mediante una escala de opinión subjetiva obteniéndose los resultados que figuran en la tabla siguiente.

Función Muy buena (%)

Buena (%)

Regular (%)

Mala (%)

Llamada a Tres 80 20 0 0 Buzón de Llamada 90 10 0 0 Desvío de Llamada 95 5 0 0 Rellamada 95 5 0 0 Rellamada Automática 90 10 0 0

Tabla 2. Resultados evaluación servicios básicos

4.3.3. Servicios avanzados El término servicios avanzados es un término muy amplio. Sin embargo, para agrupar dichos servicios se hará referencia a un conjunto de servicios que sin ser


indispensables para el funcionamiento normal de una oficina aportan un gran número de ventajas o comodidades a la hora de trabajar, puesto que permiten la integración con diversas aplicaciones. En este apartado, se centrará en el l estudio del IVR

1. IVR u operadora 2. DialApplet

En este apartado, se ha incluido una mejora futura como servicio avanzado como es el uso de DialApplet. Hay que tener en cuenta, que el uso de DialApplet ofrece un gran número de servicios como la integración con Outlook que engloban gran parte de estos servicios y que se desglosarán en el apartado correspondiente.

IVR. Descripción del servicio

Al incluir el IVR u operadora digital dentro de los servicios avanzados, se puede pensar que se ofrece como un servicio adicional, sin embargo, es uno de los servicios más comunes ofrecidos por centralitas. El hecho de englobarlo aquí es simplemente una cuestión de complejidad de código. Cuando un usuario externo realiza una llamada a la empresa, normalmente aparecerá una locución que le informará sobre las posibles opciones que puede realizar, por ejemplo, acceder a una extensión concreta, seleccionar el tipo de información que desea recibir etc…También se le puede ofrecer la posibilidad de hablar directamente con una operadora. La selección de las distintas posibilidades suele realizarse pulsando un dígito determinado que estará relacionado con la opción correspondiente. En el caso concreto de Persan, se han desarrollado dos IVR u operadoras. Uno, que atenderá todas las llamadas realizadas al número de la empresa (954998350) y otro que se activará cuando se llame al número directo del presidente. El funcionamiento de ambos es similar por lo que se explicará el IVR general y se considera el IVR del presidente una simplificación del mismo. El IVR general que se ha implementado, es una copia del servicio que ofrece la centralita existente en Persan en la actualidad. Cuando en horario laboral (es decir de 8:00 a 18:00) un usuario llama al número de la empresa (954998350), sonará una locución que le ofrece la posibilidad de introducir directamente la extensión con la que desea hablar (si la conoce) o en caso de no conocerla que espere a ser atendido por la operadora. Si la operadora atiende una llamada, y lo envía a la extensión con la que desea hablar, o el llamante conoce la extensión y accede directamente, pero en ninguno de los casos el llamado contesta, se da la opción de dejar un mensaje en el buzón de voz y después vuelve a ser atendido por la operadora. El único cambio significativo respecto al IVR original, reside en el hecho de que antes, el mensaje de voz se dejaba en el buzón de la operadora siempre, y ahora, se deja en el buzón individual de cada extensión. Cuando la llamada se realiza en horario no laboral y no conoce la extensión asociada a la persona a la que desea llamar, el usuario dejará un mensaje en el buzón de voz de la operadora. En el anexo correspondiente, se adjunta tanto el código explicado como un diagrama de flujo que facilita la comprensión del IVR (tanto el IVR general como el del presidente).


IVR.Escenario de pruebas

El escenario de pruebas usado es el mismo que para los servicios básicos.

Figura 32. Maqueta IVR

IVR.Configuración de equipos

La configuración de los equipos junto con el diagrama de flujo de este servicio aparece en el Anexo III Escenario de trabajo y análisis de posibles soluciones apartado Servicios Avanzados.

IVR.Resultados

Para evaluar este servicio se realizaron un conjunto de pruebas que validaron su funcionamiento. La prueba consistía en realizar una llamada al número de Persan y que esta llamada fuese atendida por la operadora. A partir de ahí se han realizado 10 pruebas verificando el servicio de día y de noche, y dentro de cada uno de ellos comprobando que las distintas opciones que se ofrecen funcionan correctamente. Los resultados obtenidos se muestran a continuación.

Acción Muy

Bueno(%) Bueno (%)

Regular (%)

Malo(%)

Llamada de día marcando extensión

95 5 0 0

Llamada de día atendida por operadora

90 10 0 0

Llamada de noche marcando extensión

90 10 0 0

Llamada de noche sin marcarla

100 0 0 0

Tabla 3.Resultados evaluación IVR

IVR

Teléfono Fijo Externo


La evaluación de estos servicios se ha realizado mediante un método subjetivo, por lo tanto, la puntuación obtenida está determinada no solo por el correcto funcionamiento del servicio (que en este caso funcionó siempre) sino por la calidad de la llamada al ser atendido por una operadora o al comunicarse con la extensión requerida. De ahí que la puntuación del último servicio sea 100% muy buena, puesto que en ese caso simplemente se dejaría un mensaje de voz y el único factor influyente es el correcto funcionamiento del servicio.

DialApplet. Descripción del servicio

DialApplet es una aplicación que funciona junto con una centralita Asterisk y ofrece diversos servicios que facilitan la integración de voz y datos. Es decir, es un software integrador telefonía y ordenador (CTI).

Este software esta formado por:

1. DialApplet Desktop: Asterisk compatible con Windows, Linux y Mac. 2. DialApplet Web: Configuración centralizada de la solución y datos de la

explotación.

A grandes rasgos, el software DialApplet le informa del estado de su extensión. Cuando reciba una llamada, aparece una ventana emergente donde puede ver el número de teléfono de quien está llamando, el nombre de la persona, su foto y un comentario. En ese momento se pueden llevar a cabo diversas acciones, de modo que se puede interactuar con otros sistemas de los que ya disponga el cliente. No sólo se muestra el estado de la extensión de un usuario sino que también se puede ver el estado de las demás extensiones de su grupo en un cuadro dedicado especialmente a este fin. Sin embargo, estas son solo algunas de las herramientas de las que se puede hacer uso.

En general, este software, le permite realizar distintas actividades dependiendo de la versión que se tenga instalada. Estas versiones, añaden progresivamente complejidad a las herramientas que se pueden usar y son:

1. Auditor: obtiene el control de Asterisk. Consigue monitorizar todo el sistema. El agente o manager a cargo, puede supervisar todas las llamadas que están en curso, espiar una llamada concreta pinchando en ella, puede grabarla…En resumen, permite una gestión total con un simple clic.

2. Call Center: aporta rapidez y flexibilidad a la hora de usar tecnología CTI en Contact Center. Está enfocada al técnico encargado del Call Center, y permite por ejemplo que al descolgar una llamada aparezca una ficha del llamante. Todo ello es posible porque incorpora una interfaz web y es capaz de abrir un socket que informe de un evento a otra aplicación, es este caso a una página web.

3. Enterprise: integra Asterisk con el escritorio permitiendo reforzar la relación con los clientes. Está enfocada a empresas que requieren que una parte de sus usuarios disponga de sistemas de telefonía avanzada. Las extensiones se convierten en Agentes, dotando a Asterisk de un sistema de presencia multicanal.

4. Essential: integración de voz y datos de menor coste. Es una versión más sencilla de la ‘Enterprise’.

En la actualidad, ha aparecido una última versión Free, que es la que se propone inicialmente para este proyecto. A pesar de que ofrece un abanico más limitado de


herramientas de trabajo, éstas serán suficientes para comprobar la funcionalidad de dicho software y proponer una versión más completa en su futura implementación.

Los servicios (así como la explicación de los mismos) que ofrece la versión utilizada son los siguientes:

1. Copy to call: Este servicio permite usar número de teléfono que se tienen almacenados en distintos sitios, y permite la opción de llamar directamente haciendo clic sin tener que teclear en el teléfono. Por ejemplo, un número de teléfono almacenado en un bloc de notas, o un número de teléfono que se ha recibido en un email y pinchar directamente sobre él y poder realizar una llamada. Esta opción es configurable, es decir, se puede seleccionar llamar siempre, que una ventanita emergente te pregunte si deseas hacerlo o desactivarla. También te permite meter todos estos números en una agenda centralizada.

2. Quick Call: Este servicio permite tener almacenados una serie de número de marcación rápida. Aproximadamente el 70% de las llamadas de una empresa son a los mismos números. Esta opción te permite asignar un conjunto de teclas a un número concreto, por ejemplo, la combinación Alt+F5 llama directamente al número del jefe.

3. Clic to Call: Este servicio trabaja con una agenda centralizada que permite almacenar un conjunto de números, tanto personales como por departamentos, de otras empresas….A este servicio se asocia una tecla (seleccionada por el usuario, por defecto es F11) y al pulsarla se despliega toda esa lista de contactos. Simplemente haciendo clic sobre el número se realiza la llamada.

4. Click to e-mail: Funciona de forma similar a Clic to Call pero haciendo uso de direcciones de correo electrónico.

5. Integración con Outlook: Permite exportar todos los contactos del gestor de correo en DialApplet de forma nativa.

6. Click for voicemail: Aviso de mensajes nuevos en el buzón de voz. 7. Ventana de aviso de llamadas: Cuando reciba una llamada, aparece una

ventana emergente donde puede ver el número de teléfono de quien está llamando, el nombre de la persona, su foto y un comentario.

8. Ring & open: Este servicio se usa cuando descolgamos el teléfono para atender una llamada, se abre una página web que nos muestra información del llamante (si lo tenemos registrado).

DialApplet. Maqueta de pruebas.

La maqueta de pruebas se muestra en la Figura 33.


Figura 33. Maqueta aplicación DialApplet

DialApplet. Resultados

Tras la instalación de la versión Free de DialApplet se han realizado una serie de pruebas relacionadas con cada uno de los posibles servicios. Las pruebas consistían en comprobar uno a uno que éstos funcionaban correctamente (el mecanismo de funcionamiento de cada servicio se explica en el sub-apartado de descripción de servicio. Se realizaron 3 pruebas para comprobar que cada uno de esos servicios funcionaba correctamente. En este apartado no es necesario introducir un cuadro de resultados puesto que en la repetición de cada una de las pruebas lo que se comprobó fue el funcionamiento, siendo en todas el adecuado.

Aplicación DialApplet




4.3.4. Inteconexión con enlaces primarios Para la interconexión con la red telefónica conmutada, ya sea fija o móvil, son necesarios enlaces primarios que poseen la capacidad suficiente para gestionar un gran número de llamadas. Por lo tanto, será necesario instalar tarjetas que contengan los puertos necesarios para dicha conexión. Normalmente Asterisk va de la mano de Digium, y son estas tarjetas las usadas en todos los escenarios donde se emplea como solución Asterisk. La configuración de dichas tarjetas se detalla en el Anexo III"Configuración tarjetas". En esta fase se analiza un escenario hibrido de telefonía donde conviven el nuevo sistema de VoIP implantado y el heredado de telefonía tradicional. Con este análisis se persiguen dos objetivos fundamentales. Primero, establecer una configuración que permita a los equipos implicados (centralita tradicional y Asterisk) trabajar adecuadamente de forma integrada y transparente al usuario. Segundo, verificar mediante una batería de pruebas el correcto funcionamiento del sistema completo.

Descripción del escenario

A la hora de realizar la implantación de sistemas de telefonía IP, uno de los mayores retos es conseguir integrarlos con los de telefonía tradicional existente. La incompatibilidad entre los protocolos que se utilizan en VoIP y en la telefonía conmutada hace necesario el uso de algún mecanismo de adaptación entre ambos. Asterisk consigue resolver el problema de la interoperabilidad soportando los protocolos característicos de la red telefónica conmutada, actuando así, como elemento de adaptación entre los dos mundos.

IPIP

IP Figura 34. Escenario híbrido de telefonía


En el escenario de la figura se muestra la situación de coexistencia de las dos tecnologías, VoIP y telefonía tradicional. Esta solución permite el uso del sistema de telefonía heredado de forma transparente a sus usuarios, al tiempo que incorpora el nuevo sistema de VoIP. Con esta solución permitimos la convivencia de ambas tecnologías como paso previo a la migración completa a VoIP que es el objetivo final. El escenario inicial del que partimos es el que existe actualmente en Persan ( Figura 35). Éste cuenta con una centralita Ericsson BP250 (con extensiones analógicas) que se comunica con la red pública a través de dos enlaces primarios (uno hacia la red móvil y otro hacia la red fija).

Figura 35: Escenario actual de Persan Este escenario debe ser modificado para incorporar el sistema de telefonía de VoIP. Las distintas soluciones que permiten conseguir esto se enumeran a continuación:

� Escenario 1: conexión de Asterisk con el enlace primario de móviles y conexión de centralita con el enlace primario de fijos.

� Escenario 2: conexión de Asterisk con el enlace primario de fijos y conexión de centralita con el enlace primario de móviles.

� Escenario 3: conexión de Asterisk con enlace primario de fijos y móviles y conexión de Asterisk y la centralita mediante un primario.


IPIP

IP

FIJA

MÓVIL

IP

IP IP

MÓVIL

FIJA

IP

IP

IP

IP

IP

IP

MÓVIL

FIJA

Escenario 1 Escenario 2

Escenario 3

Figura 36: Posibles escenario de interconexión

Los escenarios 1 y 2 muestran dos soluciones en las que tanto asterisk como la centralita se conectan a la red pública. En el escenario 3, sólo asterisk se conecta directamente a la red pública (a la fija y a la móvil). En las pruebas que se describen a continuación se tomarán como referencia estos tres escenarios pero será necesario imponer una limitación sobre ellos. Cuando la centralita se conecta simultáneamente a la red pública y a Asterisk, presenta problemas de sincronismo, debido a que recibe dos fuentes de reloj distintas. Por lo tanto, en las pruebas referentes a los escenarios 1 y 2, la centralita no se conectará a la red pública (fija y móvil respectivamente). En las pruebas del escenario 3 no se produce este problema, pero se tiene otra limitación debida a la falta de puertos primarios en Asterisk. Actualmente se cuenta con una tarjeta de dos puertos que se ocuparían en las conexiones con la red pública (uno para la fija y otro para la móvil), siendo necesarios otros dos puertos más para su interconexión con la centralita. Por lo tanto, en estas pruebas, Asterisk y la centralita no se encontrarán conectados. A continuación se describe las pruebas realizadas en cada uno de estos escenarios.

Desarrollo de pruebas

Para el desarrollo de cada una de las pruebas se ha empleado la misma mecánica.

� Creación de ficheros de configuración para Asterisk � Conexión física de los equipos � Realización de llamadas (contemplando todas las posibilidades) � Obtención de resultados

Con respecto a la configuración de Asterisk, hay que indicar que se parte de una configuración base, común para todos los escenarios. De todos los ficheros de


configuración existentes, sólo tres: extensions.conf, chan_dahdi.conf y system.conf serán distintos para cada prueba.

� Prueba 1: Interconexión de Asterisk con el enlace p rimario de móviles

En este escenario Asterisk se conecta a la red pública móvil. La interconexión entre Asterisk y la centralita se realiza a través de un enlace primario. El objetivo consiste en comprobar que se pueden realizar todas llamadas de forma satisfactoria. Las combinaciones posibles son:

1. Entre la red móvil y extensiones de VoIP (en ambos sentidos) 2. Entre la red móvil y extensiones analógicas (en ambos sentidos) 3. Entre extensiones analógicas y extensiones de VoIP (en ambos sentidos)

El escenario utilizado se muestra en la Figura 37.

IPIP

IP

Figura 37. Escenario 1 de pruebas

. Configuración de Asterisk En esta sección se va a detallar la configuración de los tres ficheros que es necesario modificar para la realización de las pruebas. Como se dijo, anteriormente, estos ficheros son: extensions.conf, chan_dahdi.conf y system.conf. La configuración de estos ficheros se recoge en el III apartado "Prueba 1: Interconexión de Asterisk con el enlace primario de móviles"

Realización de pruebas

Para comprobar el funcionamiento del escenario desplegado, se realizarán todas las combinaciones de llamadas posibles (se repite veinte veces cada posibilidad).

Resultados

Todos los intentos de llamadas se realizaron satisfactoriamente, obteniéndose una percepción de calidad por parte de los usuarios como sigue:


Tipo de llamada

Muy Bueno %)

Bueno (%)

Regular (%) Malo(%)

Sip-Analóg.

80 15 5 0

Sip-Sip 85 10 5 0 Sip-móvil 75 20 5 0 Analóg-móvil

75 20 5 0

Tabla 4. Resultados pruebas escenario 1

� Prueba 2: Interconexión de Asterisk con el enlace p rimario de fijos

Este escenario Asterisk se conecta a la red pública fija. La conexión entre Asterisk y la centralita se realiza a través de un enlace primario. El objetivo es comprobar que las llamadas a fijos de la red pública, procedentes tanto de los teléfonos SIP como de los teléfonos analógicos, se realiza correctamente. Así mismo, verificar que las llamadas procedentes de la red fija son tratadas de forma adecuada por Asterisk. El escenario se muestra en la Figura 38.

RTC fijafrom-pstn

from-sip

from-pbx

IP

IP

IP

IP

Enlace g2 Enlace g1

Figura 38.Escenario 2 pruebas

Configuración de Asterisk En esta prueba, los ficheros chan_dahdi.conf y system.conf son los mismos que en la anterior, por lo tanto, el único fichero que sufre alguna modificación es extensions.conf. Se puede estudiar con más detalle en el Anexo III apartado "Prueba 2: Interconexión de Asterisk con el enlace primario de fijos". Realización de pruebas Se seguirá la misma mecánica que en el escenario anterior, es decir, se realizarán veinte intentos de llamada para todas las posibles combinaciones de éstas, comprobando así el funcionamiento del escenario desplegado.


Resultados Todos los intentos de llamadas se realizaron satisfactoriamente, obteniéndose una percepción de calidad por parte de los usuarios como sigue:

Tipo de llamada

Muy Bueno (%)

Bueno (%)

Regular (%) Malo (%)

Sip-Analóg.

85 10 5 0

Sip-Sip 85 10 5 0 Sip-fijo 80 15 5 0 Analóg-fijo

90 5 5 0

Tabla 5. Resultados pruebas escenario 2

� Prueba 3: Interconexión de Asterisk con la red fija y móvil En este escenario Asterisk se conecta tanto a la red pública fija como a la móvil. La centralita no se conectará al sistema. El objetivo es comprobar el correcto funcionamiento del escenario de migración final. En este escenario se cuenta con un sistema totalmente IP donde Asterisk se conecta a las dos redes públicas (fija y móvil) la centralita Ericsson desaparece. Los terminales analógicos se conectarán a la red a través de un adaptador (ATA). La Figura 39 muestra el escenario de trabajo.

IP

IP

V

Figura 39: Escenario 3 de pruebas

Configuración de Asterisk En el escenario final planteado para Persan, el servidor Asterisk deberá asumir el manejo de todas las llamadas. Para la realización de esta prueba, ha sido necesaria la modificación de los archivos: extensions.conf, chan_dahdi.conf y sistem.conf.


La configuración detallada puede observarse en el Anexo III apartado "Prueba 3: Interconexión de Asterisk con la red fija y móvil". Realización de pruebas Se seguirá la misma mecánica que los escenarios anteriores, es decir, se realizarán veinte intentos de llamada para todas las posibles combinaciones de éstas, comprobando así el funcionamiento del escenario desplegado. Resultados Todos los intentos de llamadas se realizaron satisfactoriamente, obteniéndose una percepción de calidad por parte de los usuarios como sigue:

Tipo de llamada

Muy Bueno(%)

Bueno (%)

Regular (%) Malo(%)

Sip-Sip 90 5 5 0 Sip-fijo 84 15 5 1 Sip-móvil 70 20 8 2

Tabla 6.Resultados pruebas escenario 3

Conclusiones finales

Se han presentado tres posibles escenarios para el despliegue de telefonía IP sobre el sistema de telefonía actual de Persan. Cada escenario ofrece una alternativa distinta para la integración de los dos sistemas telefónicos. El objetivo que se persigue con el conjunto de pruebas realizadas es presentar la viabilidad de las distintas alternativas existentes. Como se ha expuesto en el documento, este conjunto de ensayos tienen unas limitaciones que impiden que sean utilizados como soluciones finales. Por lo tanto, aunque los resultados obtenidos no sean suficientes para afrontar el despliegue de una solución definitiva, sí ofrecen una primera aproximación válida para abordar el problema completo.

Capítulo 4: Escenario de Trabajo red VoIP y Análisis de...

Documents

Transcript of Capítulo 4: Escenario de Trabajo red VoIP y Análisis de...