Memoria. Protocolos Sccp

TRABAJO DE FINAL DE CARRERA

TÍTULO DEL TFC: Propuesta de Mejora, Diseño e Implantación de una Red de Telefonía IP TITULACIÓN: Ingeniería Técnica de Telecomunicaciones, especialidad en Telemática AUTOR: Carlos Asensio Ruiz DIRECTOR: Alfonso López SUPERVISORA: Silvia Ruiz Boqué FECHA: 14 de Mayo de 2008

Título: Propuesta de Mejora, Diseño e Implantación de una Red de Telefonía IP Autor: Carlos Asensio Ruiz Director: Alfonso López Supervisora: Silvia Ruiz Boqué Fecha: 14 de Mayo de 2008 Resumen Este proyecto se ha llevado a cabo en un marco laboral real, en una empresa dedicada al sector de las TIC, contando con una amplia gama de servicios como Proveedor de Servicios de Internet (ISP). Uno de los servicios ofrecidos es el de Telefonía IP, brindando a sus clientes la posibilidad de disfrutar las mejoras y ventajas que estos sistemas proporcionan sobre la telefonía tradicional. Nos centramos en el estudio concreto de una empresa cliente que realiza una migración de su sistema de telefonía tradicional analógica hacia una convergencia entre la nueva red de telefonía IP que se implementará y su red de datos actual. Analizaremos la situación inicial del cliente, sus motivaciones de cambio, recogeremos las especificaciones particulares y diseñaremos y presentaremos una solución. Dicha solución será implementada y validada de acuerdo a una planificación técnica acorde con el proyecto. Atenderemos también a la rentabilidad del proyecto desde un punto de vista económico para la empresa que lo lleva a cabo, evaluando cuando obtendrá el retorno de la inversión, es decir, pasar de tener pérdidas a obtener beneficios. Se han utilizado como herramientas de trabajo distintos programas software que me han facilitado mucho la tarea de recopilar, organizar y ordenar toda la información disponible, así como gestionar el tiempo de una manera eficaz. También daremos unas pautas para posibles líneas de trabajo futuras a realizar a la finalización de este proyecto. Se basarán en posibles mejoras de las infraestructuras que se implementarán y que llevarían al sistema a un mejor rendimiento global. Un resumen de las distintas tecnologías, aplicaciones y protocolos que se recogen en este proyecto son: ADSL, VoIP, ToIP, RDSI, TRAC, PSTN, FXO, SSAM, IVR, BILLY, VMWare, CCME, CCM, VLANs, IPSec, DHCP, RADIUS, STP, TFTP, HSRP, SRST, SCCP, H323, SIP, MGCP, QoS, G.711, G.729.

Title: Proposed Improvement, design and implementation of an IP Telephony Network Author: Carlos Asensio Ruiz

Director: Alfonso López

Supervisor: Silvia Ruiz Boqué

Date: May, 14th 2008 Overview This project has been carried out within a real job, a company dedicated to the ICT sector, with a wide range of services such as Internet Service Provider (ISP). One of the services offered is that of IP telephony, offering its customers the chance to enjoy the improvements and advantages that these systems provide on traditional telephony. We focus on the specific study of a company that makes a migration of its traditional analog telephone system towards a convergence between the new IP telephony network that will be implemented and its current data network. We look at the initial situation, analyze their motivations for change, collect the individual specifications and design and present a solution. This solution will be implemented and validated according to a technical planning commensurate with the project. Also to accommodate the profitability of the project from an economic point of view for the company that is carried out when evaluating get ROI, move to take losses to profits. Have been used as working tools different software titles that I have greatly facilitated the task of collecting, organizing and ordering all available information, and manage time efficiently. They also give guidelines for possible future lines of work to do to completing this project. They draw on possible improvements to infrastructure that will be implemented and that the system would lead to a better overall performance. A summary of the different technologies, applications and protocols which are reflected in this project are: ADSL, VoIP, ToIP, ISDN, TRAC, PSTN, FXO, SSAM, IVR, BILLY, VMWare, CCME, VLANs, IPSec, DHCP, RADIUS, STP, TFTP, HSRP, SRST, SCCP, H323, SIP, MGCP, QoS, G.711, G.729.

A mi abuela Mercedes

Agradecimientos

A mis padres, familia, amigos, compañeros de trabajo

y a todos los que me han apoyado

ÍNDICE

INTRODUCCIÓN ............................................................................................... 1

1. SITUACIÓN INICIAL.................................................................................. 3

1.1. Descripción inicial ............................................................................................................. 3

1.2. Topología de red................................................................................................................ 4 1.2.1. Topología LAN........................................................................................................ 4 1.2.2. Topología WAN ...................................................................................................... 5

1.3. Arquitectura de VoIP ......................................................................................................... 5 1.3.1. VoIP LAN................................................................................................................ 6 1.3.2. VoIP WAN............................................................................................................... 6

2. MOTIVACIÓN DEL CAMBIO..................................................................... 6

2.1. Necesidades....................................................................................................................... 7

3. PRESENTACIÓN INICIAL DE LA SOLUCIÓN ......................................... 7

3.1. Ventajas del nuevo sistema.............................................................................................. 8 3.1.1. Reducción de costes .............................................................................................. 8 3.1.2. Simplificación de las comunicaciones .................................................................... 8 3.1.3. Mayor flexibilidad.................................................................................................... 8 3.1.4. Plataforma de comunicación unificada................................................................... 8 3.1.5. Optimización de recursos ....................................................................................... 9 3.1.6. Mejora de la productividad ..................................................................................... 9

4. RECOGIDA DE ESPECIFICACIONES...................................................... 9

4.1. Clasificación....................................................................................................................... 9 4.1.1. Según los usuarios ............................................................................................... 10 4.1.2. Según el sistema .................................................................................................. 10

5. SOLUCIÓN PROPUESTA ....................................................................... 11

5.1. Diseño de la solución...................................................................................................... 11 5.1.1. Diagrama de red................................................................................................... 11 5.1.2. Equipos de comunicaciones................................................................................. 13 5.1.3. Calidad de servicio ............................................................................................... 13 5.1.4. Aplicaciones adicionales ...................................................................................... 17 5.1.5. Modelos de teléfonos ........................................................................................... 17 5.1.6. Redundancia de Gateways .................................................................................. 18 5.1.7. Interconexión de delegaciones............................................................................. 19 5.1.8. Política de Backups .............................................................................................. 19 5.1.9. Plan de Numeración ............................................................................................. 20 5.1.10. Integración con la red existente............................................................................ 20 5.1.11. Ubicaciones físicas............................................................................................... 22 5.1.12. Limitaciones.......................................................................................................... 23

5.2. Visado técnico ................................................................................................................. 24

5.3. Valoración comercial ...................................................................................................... 24

6. IMPLANTACIÓN...................................................................................... 25

6.1. Diseño de implantación .................................................................................................. 26 6.1.1. Direccionamiento IP ............................................................................................. 26 6.1.2. Servidores DHCP ................................................................................................. 27 6.1.3. Configuración HSRP ............................................................................................ 28

6.2. Impacto sobre el sistema en producción...................................................................... 29

6.3. Tareas ............................................................................................................................... 30 6.3.1. Diagrama de Gantt ............................................................................................... 30 6.3.2. Instalar hardware en los routers ........................................................................... 31 6.3.3. Instalación física de los equipos........................................................................... 33 6.3.4. Configuración de los dispositivos de red.............................................................. 34 6.3.5. Instalación del software en los servidores............................................................ 38 6.3.6. Configuración de los servidores ........................................................................... 39 6.3.7. Fase de pruebas................................................................................................... 41 6.3.8. Puesta en producción........................................................................................... 41 6.3.9. Retirada de dispositivos analógicos ..................................................................... 42 6.3.10. Formación de usuarios ......................................................................................... 43 6.3.11. Integración de delegaciones................................................................................. 44

7. VALIDACIÓN........................................................................................... 45

7.1. Funcionamiento ante fallos ............................................................................................ 45

7.2. Plan de aceptación .......................................................................................................... 46

7.3. Instrucción técnica al cliente ......................................................................................... 47

8. ANÁLISIS DE RENTABILIDAD............................................................... 48

CONCLUSIONES ............................................................................................ 49

BIBLIOGRAFÍA ............................................................................................... 50

ANEXO A. CONFIGURACIÓN DEL CISCO CALLMANAGER....................... 52

ANEXO B. CONFIGURACIÓN DEL STONEVOICE........................................ 61

ANEXO C. PLANTILLA DEL PLAN DE ACEPTACIÓN.................................. 66

INTRODUCCIÓN 1

INTRODUCCIÓN Este proyecto se ha llevado a cabo en un marco laboral real en la empresa a la que pertenezco actualmente: COM 2002, S.L NEXICA, dedicada al sector de las TIC, contando con una amplia gama de servicios como Proveedor de Servicios de Internet (ISP). Uno de los servicios ofrecidos es el de Telefonía IP, brindando a sus clientes la posibilidad de disfrutar las mejoras y ventajas que estos sistemas proporcionan sobre la telefonía tradicional. Por este mismo motivo el cliente ha contratado este proyecto: realizar un cambio significativo en su infraestructura de telefonía. Este cliente tiene su actividad laboral centrada en la seguridad privada y, para mantener su anonimato, le vamos a dar el nombre ficticio de SV24H (Seguridad y Vigilancia 24 Horas). Para la elaboración de este proyecto he tenido a mi disposición todo el material, dispositivos y documentación necesarios por parte de mi empresa. Mi trabajo se inició con la fase de implantación en Noviembre de 2007 y se ha prolongado hasta la redacción de esta memoria en Mayo de 2008 para la que he tenido que realizar la documentación de todas las partes y así poder darle una entidad única como proyecto. En el capítulo 1 tendremos una visión general del estado de la red del cliente, que nos permitirá tener un punto de vista inicial sobre cómo se encuentra la red. En el capítulo 2 MOTIVACIÓN DEL CAMBIO explicaremos las necesidades que hacen preciso el cambio en el sistema del cliente. En el capítulo 3 PRESENTACIÓN INICIAL DE LA SOLUCIÓN daremos una descripción a grandes rasgos del proyecto a realizar, destacando los puntos fuertes que introduce la telefonía IP en la infraestructura del cliente En el capítulo 4 RECOGIDA DE ESPECIFICACIONES clasificaremos las especificaciones necesarias para la elaboración del proyecto para cumplir con todos los requerimientos del cliente. En el capítulo 5 SOLUCIÓN PROPUESTA detallaremos la solución final que será elaborada para presentar al cliente como respuesta al estudio y análisis previos realizados. En el capítulo 6 IMPLANTACIÓN realizaremos la implantación del proyecto, cumpliendo con el diseño realizado en las fases anteriores.

2 Propuesta de Mejora, Diseño e Implantación de una Red de Telefonía IP

En el capítulo 7 VALIDACIÓN analizaremos como se comporta el sistema ante posibles fallos, elaboraremos un plan de aceptación de la solución y realizaremos una encuesta al usuario final para obtener un feedback sobre su nivel de satisfacción con la instalación. Por último, en el capítulo 8 ANÁLISIS DE RENTABILIDAD analizaremos cuando será amortizado y comenzaremos a obtener beneficios en función de diferentes parámetros económicos.

SITUACIÓN INICIAL 3

1. SITUACIÓN INICIAL En este capítulo se describirá la estructura de SV24H, nuestra empresa cliente, en la que nos basaremos para realizar este proyecto. Obtendremos una visión general del estado de la red del cliente, que nos permitirá tener un punto de vista inicial sobre el que determinaremos cómo se encuentra la red, qué aspectos podemos mejorar y, en general, cómo podemos abordar el nuevo diseño.

1.1. Descripción inicial La empresa SV24H cuenta con una sede central en Esplugues de Llobregat (Barcelona), en la que posee dos edificios separados 30 metros aproximadamente. En el primer edificio (Central 1) se encuentran las oficinas, cuya disponibilidad horaria es la normal de cualquier oficina. En el segundo edificio (Central 2) se encuentran más oficinas y una garita de seguridad. En esta garita hay siempre una persona trabajando para dar cobertura a los distintos servicios que presta la empresa. El hecho de tener que disponer de comunicaciones aseguradas las 24 horas los 7 días de la semana es un punto crítico que nos condicionará el diseño de la nueva red. En esta sede es donde se centralizan las comunicaciones de la empresa, contando ambos edificios con una estructura de red local (LAN) independiente, que da conectividad a los cerca de 50 usuarios que allí trabajan. Las dos LANs están conectadas de forma que tienen visibilidad a nivel 3 la una de la otra. Los usuarios pueden acceder a los servicios alojados en uno u otro edificio indistintamente. Además de esta sede central, cuenta con cinco delegaciones repartidas por la geografía española: Madrid, Reus, Sevilla, Valencia y Asturias. El perfil de trabajo de estas delegaciones es sencillo, contando con pocos usuarios. Se pretende que su trabajo esté centralizado contra la delegación principal. Con este propósito tienen creados túneles seguros (VPN) que permiten extender la red local de la central hasta las delegaciones. Gracias a ellos, pueden trabajar accediendo a los mismos servicios que los usuarios locales,


limitados tan sólo por el ancho de banda de las conexiones a Internet de que dispongan.

1.2. Topología de red

1.2.1. Topología LAN La topología de red de LAN de la central la podemos dividir en dos:

• Central 1: edificio antiguo, dónde tenemos un solo router que soporta el tráfico de datos y voz. Esto supone una carga de proceso excesiva para este router además de posibles problemas de seguridad al estar expuestos los servicios de telefonía en un router frontera.

• Central 2: edificio nuevo, dónde tenemos dos routers. Uno soporta el

tráfico de datos de una VLAN y el otro soporta la parte de voz más el tráfico de varias VLAN’s de datos. De nuevo, es un mal diseño de balanceo de carga de tráfico en los dispositivos. También tenemos problemas de seguridad ya que el router de voz es accesible desde Internet al disponer de una ip pública asignada.

El esquema topológico de red descrito lo podemos observar en la Fig. 1 .

Fig. 1 Esquema topológico LAN inicial

Central 1 Central 2

SITUACIÓN INICIAL 5

1.2.2. Topología WAN La topología de red WAN está compuesta por las conexiones con las distintas delegaciones. Estas conexiones se realizan a través de túneles VPN IPSec que nos proporcionan seguridad a la hora de establecer comunicaciones con extensiones remotas de una LAN. Mediante los túneles las delegaciones acceden a los servicios proporcionados en la red local de la central como si estuvieran físicamente conectadas a ella. Este modo de trabajo se hace transparente para las aplicaciones al usar un direccionamiento de nivel 3 que enruta el tráfico procedente de la LAN remota hasta la LAN local pasando por el túnel. El esquema topológico WAN descrito lo podemos observar en la Fig. 2

Fig. 2 Esquema topológico WAN incial

1.3. Arquitectura de VoIP La arquitectura VoIP implementada se puede diferenciar en los mismos ámbitos que los empleados para la topología de red: LAN y WAN.


1.3.1. VoIP LAN Dentro de la red local, nos encontramos con dos arquitecturas de voz distintas:

• Central 1 que cuenta con una centralita analógica conectada a la red de telefonía PSTN1 mediante varias líneas RDSI. Para la comunicación con terminales móviles disponen de dos TRAC2s con los que abaratar costes en estas llamadas. En este edificio todos los terminales son analógicos y están interconectados a la centralita analógica, que a su vez dispone de un módulo TCP/IP por el que conecta contra el router disponible. Este router se encarga de comunicar la red de voz analógica de su edificio con la red VoIP del otro.

• Central 2 donde todos los terminales son teléfonos IP y se registran

contra el router que actúa como CCME. Este router es el que permite la comunicación con los teléfonos analógicos del otro edificio gracias a la información que intercambia con el router de Esplugues 1.

La arquitectura VoIP LAN descrita se puede observar en la Fig. 1.

1.3.2. VoIP WAN La arquitectura de voz IP empleada en la parte WAN se basa en el uso de routers clientes modelo Cisco 827-4V. Este modelo dispone de cuatro puertos POTS (para conectar a la PSTN) en los que están conectados teléfonos analógicos normales. Gracias a la configuración implementada, son capaces de enrutar las llamadas dirigidas a la central o demás delegaciones hacia los routers respectivos de cada una de ellas. Los teléfonos que estén conectados a estos puertos solo pueden realizar llamadas a la central y delegaciones ya que el router al que están conectados no dispone de líneas telefónicas de salida. La arquitectura VoIP WAN descrita puede observarse en la Fig. 2.

2. MOTIVACIÓN DEL CAMBIO Una vez hemos dado una descripción general de la estructura de la empresa a tratar, nos centraremos en explicar las necesidades que hacen preciso un cambio.

1 Public Switched Telephone Network 2 Telefonía Rural por Acceso Celular

MOTIVACIÓN DEL CAMBIO 7

2.1. Necesidades Los puntos principales que motivan al cliente a la migración hacia un nuevo sistema de telefonía son los siguientes:

a) Finalización del contrato de alquiler y mantenimiento de la centralita analógica actual. Al finalizar dicho contrato se plantean la idea de mejorar su red de telefonía, en lugar de continuar manteniendo la que ya tenían.

b) Disponer de una red de telefonía escalable. El actual sistema de

telefonía no permite más escalabilidad de la que ya existe. Al disponer de telefonía IP tendrán la posibilidad de aumentar el número de terminales que forman su red, tanto en la parte LAN como WAN.

c) Mejora de integración con el software de gestión actual. La empresa

cuenta con un software de gestión que necesita los datos de accounting (detalles de llamadas) para controlar los servicios que puede facturar y los que no. El software podrá beneficiarse de la variedad de soluciones que aporta la telefonía IP para facilitar ese tipo de datos.

d) Integración total VoIP. Según la estructura descrita, el edificio Espulgues

1 de la central no cuenta con ningún terminal VoIP. Es necesario actualizar todos los terminales para poder beneficiarse de las ventajas de la telefonía IP.

e) Alta disponibilidad en las comunicaciones. Al tratarse de una empresa

de seguridad necesitan estar comunicados las 24 horas del día. El actual sistema no permite una tolerancia a fallos ni balanceos de tráfico de voz que asegure esta disponibilidad. Al introducir la telefonía IP se reducirá el riesgo de quedar incomunicado con el exterior, siendo este un tema crítico en una empresa con una infraestructura como esta.

3. PRESENTACIÓN INICIAL DE LA SOLUCIÓN Con todos estos datos de partida sobre la infraestructura del cliente realizaremos una presentación inicial de la solución. La presentación constará de una descripción a grandes rasgos del proyecto a realizar, destacando los puntos fuertes que introduce la telefonía IP en la infraestructura del cliente. En esta presentación inicial no se profundizará en aspectos técnicos. Una solución más detallada y pormenorizada será evaluada posteriormente, una vez se hayan recabado las especificaciones propias de la implantación del proyecto si al cliente le convence la oferta inicial planteada.


3.1. Ventajas del nuevo sistema A continuación se detallan las ventajas más destacadas del nuevo sistema que se ofrecen al cliente, enfatizando en los mejores aspectos que pueden beneficiar al cliente, al sistema y al usuario.

3.1.1. Reducción de costes

a) Dispondremos de una única plataforma de Hardware tanto para voz como para datos, al actuar los teléfonos como un pequeño switch. La conexión se realiza del switch al teléfono y del teléfono al pc. Sólo será necesario disponer de un único cable de red por usuario.

b) Ahorro de costes a la hora de establecer comunicaciones con las

distintas delegaciones actuales y futuras.

c) Redirección selectiva de las llamadas salientes a las líneas que resulten más económicas a partir del número marcado.

3.1.2. Simplificación de las comunicaciones

a) Trabajaremos con un único lenguaje de comunicación, con lo que se simplifica la integración con cualquier sistema o aplicación de red.

b) Integración de la red de datos y de voz en una sola red.

c) Facilidad a la hora de implementar nuevos servicios de

comunicaciones.

3.1.3. Mayor flexibilidad

a) El cliente dispone de un entorno de Gestión fácil e intuitivo que le permite realizar de manera autónoma tareas como Añadir una nueva extensión al sistema, configurar un desvío, etc.

b) Creación de planes de numeración, marcaciones rápidas y todo

tipo de configuraciones personalizadas.

3.1.4. Plataforma de comunicación unificada

a) Permite la posibilidad de integrar la plataforma de correo con la telefonía

PRESENTACIÓN INICIAL DE LA SOLUCIÓN 9

b) Permite la integración con el software de gestión actual del

cliente. c) Realización de reportings detallado de las llamadas que han sido

gestionadas y cursadas en la red.

3.1.5. Optimización de recursos

a) Disponer de una plataforma centralizada permite optimizar recursos técnicos, agilizar incidencias, disponer de una plataforma de monitorización única, etc.

b) Resolución más rápida y eficiente de las posibles averías y

problemas del sistema.

3.1.6. Mejora de la productividad

a) Los usuarios van a poder disponer de herramientas como agendas compartidas, directorios corporativos, agendas personales, mensajería unificada, etc.

b) Mensaje automático de bienvenida al llamar al número de

cabecera del cliente.

c) Buzones de voz para cada usuario que permiten enviar los mensajes como archivos adjuntos de sonido en un mail a la cuenta del usuario.

4. RECOGIDA DE ESPECIFICACIONES Una vez realizada la presentación inicial de la solución se llevará a cabo la recogida de especificaciones necesarias para la elaboración de una solución que abarque en su totalidad los requerimientos del cliente y su infraestructura.

4.1. Clasificación Vamos a clasificar las especificaciones atendiendo al origen de las mismas. Si tomamos en cuenta el punto de vista del usuario y si tomamos en cuenta el punto de vista del sistema global. De esta forma analizamos los requerimientos que se deberán cumplir en la solución final propuesta.


4.1.1. Según los usuarios

a) Cuando las operadoras de la centralita tienen que pasar una llamada necesitan saber si el terminal de destino está ocupado con otra llamada.

b) Es necesario de mantener un plan de numeración todo lo parecido

que se pueda al actual. De esta forma a los usuarios les será menos traumático adaptase al nuevo sistema de telefonía.

c) Necesitan un buzón de voz por cada terminal de usuario. Esta

funcionalidad la aprovecharán como contestador automático para cada usuario.

d) Reporting detallado de las llamadas que el sistema curse, con

posibilidad de elaborar estadísticas que permitan ver el tráfico de llamadas de una manera fácil.

4.1.2. Según el sistema

a) Necesitan que se entregue accounting contra una aplicación que recoge las llamadas perdidas que se hacen a un determinado número de teléfono.

b) Integración de las delegaciones remotas en el sistema de telefonía

corporativo. c) Política de restricción de llamadas, que se aplicará tanto en los

usuarios como en las delegaciones.

d) Alta disponibilidad de las comunicaciones de voz, debido a la actividad laboral de la empresa cliente que cuenta con una garita donde hay un trabajador las 24 horas de cualquier día.

e) Necesitan poder grabar las llamadas que se reciban u originan en la

garita. Al tratarse de una empresa de seguridad, la policía le pide que mantenga un registro de las conversaciones que se produzcan en su garita de vigilancia.

f) Operadora de bienvenida al llamar al número de cabecera de la

empresa. Este mensaje será el que se escuche antes de entrar en la cola de atención de la centralita.

g) Reutilización de los terminales antiguos de los que se disponían en el

edificio de Central 2.

h) Tener en cuenta el número de líneas RDSI y TRAC de que disponen en cada edificio. Esto condicionará al tráfico total de voz que se

SOLUCIÓN PROPUESTA 11

i) podrá soportar y como realizar un balanceo eficiente de la carga de llamadas.

5. SOLUCIÓN PROPUESTA En este capítulo detallaremos la solución final que será elaborada para presentar al cliente como respuesta a sus necesidades y requerimientos. La solución propuesta es una solución basada en el Cisco CallManager (CCM) 4.3 con una serie de aplicaciones de software adicionales opcionales diseñadas para aportar funcionalidades de valor añadido a la solución de Cisco. En primer lugar diseñaremos la solución, profundizando en todos los aspectos que hay que tener en cuenta, como son: diagramas de red, ubicaciones físicas de los equipos, plan de numeración, copias de seguridad, etc. Seguidamente veremos el visado técnico que se realiza sobre el diseño planteado y, por último, la valoración económica que se plantea al cliente, desde el punto de vista comercial.

5.1. Diseño de la solución En el diseño de la solución se detallarán todos los aspectos que son necesarios para poder llevar a cabo el proyecto.

5.1.1. Diagrama de red Presentaremos el esquema de red que hemos diseñado. Sobre él iremos detallando en los siguientes apartados todos los aspectos que nos han condicionado a este diseño final. En el esquema podemos ver una separación por Central 1 y Central 2, donde podemos ver las conexiones hacia Internet y hacia la red de telefonía, los dispositivos que intervienen, las VLAN’s configuradas y los dispositivos terminales que cuelgan de ellas. El esquema descrito lo observamos en la Fig. 3.


Fig. 3 Diagrama de red de la solución


5.1.2. Equipos de comunicaciones Podemos distinguir tres tipos de equipos y dispositivos de comunicaciones:

a) Switches. Aprovechamos los cuatro que se encuentran ya instalados en el cliente. Existen dos por cada edificio, siendo los modelos Cisco WS-C2950 de 24 puertos. Estos switches cuentan con capacidad de VLANs y otras muchas funcionalidades que los caracterizan como equipos ideales para el tipo de requerimientos de esta instalación.

b) Routers. Utilizaremos dos nuevos equipos Cisco 2821, uno para

cada edificio, que actuaran como gateways de voz. Un Gateway de voz es un equipo que tiene capacidad para enrutar las llamadas de voz, generalmente de modo bidireccional entre VoIP y PSTN. Por otro lado, en Central 1 dejaremos el actual Cisco 1751-V como salida a Internet. En Central 2 dejaremos el Cisco 1841 como salida a Internet y el Cisco 1760V-CME lo integraremos en un programa de recompra de dispositivos.

c) CCM, o Cisco CallManager, hace las funciones de centralita IP. Es

un software propietario de Cisco, utilizado para gestionar todo lo relacionado con la telefonía IP: teléfonos, gateways, etc. Principalmente utiliza el protocolo SCCP, también propietario de Cisco, como sistema de señalización, aunque admite otros como: H323, SIP, MGCP.

5.1.3. Calidad de servicio En una red orientada a la conmutación de paquetes es necesario establecer una política de QoS (Quality of Service) acorde a los requerimientos del sistema en el que nos encontramos. Los principales problemas a los que se enfrenta la calidad de servicio son:

a) Latencia o retardo que es el tiempo que tarda un paquete en llegar desde el origen al destino. Es un problema que suele aparecer en enlaces lentos o congestionados. Valor ideal: < 150ms.

b) Jitter que es la variación en el tiempo en la llegada de los paquetes,

causada por congestión de red, perdida de sincronización o por las diferentes rutas seguidas por los paquetes para llegar al destino. Valor ideal: < 100ms.

c) Pérdida de paquetes que se suelen dar, principalmente, por

descartes realizados al no llegar a tiempo al receptor. El mayor problema lo tenemos cuando las pérdidas se producen a ráfagas, ya que no podremos reconstruir la información original. Valor ideal:< 1%.


d) Eco que es la reflexión retardada de la señal acústica original. El problema se acentúa cuanto mayor es el retardo e intensidad. Valores ideales: < 65ms y atenuación entre 25 y 30 dB.

También deberemos asegurar el ancho de banda necesario para soportar el tráfico de VoIP, que dependerá del codec utilizado y del número de llamadas concurrentes que queramos soportar. Una vez conseguido esto, deberemos garantizar que los paquetes de VoIP se aseguren un porcentaje del total de ese ancho de banda, así como darles priporidad sobre otro tipo de tráfico para que la comunicación en tiempo real se lleve a cabo. En la Tabla 1 podemos observar datos sobre los codecs y cálculos del ancho de banda que consumen cada uno. Los dos codecs más importantes son el G.711 y el G.729, mostrados en primer y segundo lugar, respectivamente.

Codec Information Bandwidth Calculations

Codec & Bit Rate (Kbps)

Codec Sample

Size (Bytes)

Codec Sample Interval

(ms)

Mean Opinion Score (MOS)

Voice Payload

Size (Bytes)

Voice Payload

Size (ms)

Packets Per

Second (PPS)

Bandwidth Ethernet (Kbps)

G.711 (64

Kbps) 80 Bytes 10 ms 4.1 160 Bytes 20 ms 50 87.2 Kbps G.729 (8

Kbps) 10 Bytes 10 ms 3.92 20 Bytes 20 ms 50 31.2 Kbps G.723.1

(6.3 Kbps) 24 Bytes 30 ms 3.9 24 Bytes 30 ms 34 21.9 Kbps

G.723.1 (5.3

Kbps) 20 Bytes 30 ms 3.8 20 Bytes 30 ms 34 20.8 Kbps G.726

(32 Kbps) 20 Bytes 5 ms 3.85 80 Bytes 20 ms 50 55.2 Kbps G.726

(24 Kbps) 15 Bytes 5 ms 60 Bytes 20 ms 50 47.2 Kbps G.728

(16 Kbps) 10 Bytes 5 ms 3.61 60 Bytes 30 ms 34 31.5 Kbps

Tabla 1 Información de codecs y cáculos de anchos de banda Daremos una breve explicación de los campos arriba indicados:

• Codec Bit Rate (Kbps) es el número de bits por segundo que se necesitan transmitir para transportar los datos de una llamada de voz. (codec bit rate = codec sample size / codec sample interval).

• Codec Sample Size (Bytes) es el número de bytes capturados por el

DSP en cada intervalo de muestreo. Por ejemplo, el codec G.711 tiene


intérvalos de muestreo de 10 ms, que corresponden a 80 Bytes (640 bits) por muestra a una velocidad de 64 Kbps.

• Codec Sample Interval (ms) es el intervalo de muestreo al que

trabaja el codec.

• Mean Opinion Score (MOS) es un sistema de puntuación de la calidad de la voz en un sistema de telefonía. El test es ejecutado por una serie de personas que dan su opinión subjetiva sobre la calidad de la voz que escuchan en una escala de puntuación que va de uno (malo) a cinco (excelente).

• Voice Payload Size (Bytes) es el número de Bytes de carga útil de

voz que se introducen en un paquete a transmitir. Este tamaño debe ser múltiplo del Codec sample size.

• Voice Payload Size (ms) también puede darse en términos de

muestreo de codec. Por ejemplo, G.711 tiene un voice payload size de 20 ms (dos codec samples de 10 ms) que representa un voice payload de 160 Bytes [ ( 160 Bytes * 8 ) / ( 20 ms) = 64 Kbps ].

• Packets Per Second (PPS) es el número de paquetes que necesitan

ser transmitidos por segundo para lograr tener el bit rate deseado por el codec. Por ejemplo, para una llamada G.711 con un voice payload por paquete de 160 Bytes (1280 bits), se necesitan 50 paquetes por segundo [ (64 Kbps) / ( 1280 bits) = 50 pps ].

• Bandwidth Ethernet (Kbps) reperesenta el ancho de banda que

ocupa una conversación, utilizando Ethernet como mecanismo de acceso al medio. Por ejemplo, en la Tabla 2 tenemos los datos y cálculos para averiguar el ancho de banda de una llamada de voz que utilice el codec G.711.

Codec Information Codec Bit Rate 64 kbps = (Codec Sample Size * 8) / (Codec Sample Interval)

Codec Sample Size 80 bytes size of each individual codec sample

Codec Sample Interval 10 msec the time it takes for a single sample

Packet Size Calculation Total Packet Size 218 bytes Entire Packet Size

Voice Payload Size 160 bytes Size of the Codec Samples per packet

Layer2 Overhead 18 bytes Layer2 Overhead including CRC

IP Header Overhead 20 bytes IP Overhead in bytes

UDP Header Overhead 8 bytes UDP Overhead in bytes

RTP Header Overhead 12 bytes RTP Overhead in bytes


Bandwith Per Call (VoIP) Voice Packets Per Second

50 (Codec Bit Rate / Voice Payload Size)

Bandwidth Per Call (RTP Only)

87.2 kbps ( Total Packet Size(bits) )* ( Packets Per Second )

5% Additional Overhead

4.36 kbps 5% additional overhead per call to accommodate bandwidth for signaling (for example: RTCP/H225/H245 messages on H.323 networks).

Bandwith Per Call + 5.0% Additional Overhead

91.56 kbps Overhead + Bandwidth Per call

Total Bandwith Required (VoIP) Bandwidth Used for All Calls (RTP Only)

87.2 kbps (Bandwidth per Call) * (Number of Calls)

Total Bandwidth (including Overhead)

91.56 kbps Same as above + 5.0% Overhead

Tabla 2 Cálculos de ancho de banda para una llamada con G.711

Los cálculos realizados han sido:

o Tamaño total del paquete = (cabeceras L2) + (cabeceras IP/UDP/RTP) + (voice payload) = 18 Bytes + 40 Bytes + 160 Bytes = 218 Bytes * 8 = 1744 bits

o Ancho de banda por llamada = Tamaño total del paquete *

Paquetes por segundo = 1744 bits * 50 pps = 87,2 Kbps

o Ancho de banda con Overhead = 87,2 Kbps + 5% = 91,56 Kbps Dos posibles medidas extras que podemos tomar para aprovechar mejor el ancho de banda disponible son:

• Activar el VAD (Voice Activity Detection) que consiste en suprimir de la red los paquetes que contienen el silencio de la conversación. Activaremos también el CNG (Comfort Noise Generation) generando localmente en el otro extremo un ruido de fondo, de forma que no se confundan la falta de silencio con una desconexión de llamada.

• Activar el cRTP (compressed RTP) que comprime las cabeceras

IP+UDP+RTP de 40 Bytes en 2 o 4 Bytes, siendo entonces el tamaño de la cabecera bastante menor comparado con el payload de voz, mejorando la eficiencia en la transmisión.


5.1.4. Aplicaciones adicionales Como aplicaciones adicionales al Cisco CallManager, Cisco dispone de una serie de aplicaciones desarrolladas para aportar valor añadido a este tipo de soluciones. Estas aplicaciones están englobadas dentro de la solución de StoneVoce, que permite comprar individualmente cada uno de los módulos disponibles. Los principales módulos a destacar son los siguientes:

a) SSAM: se trata de un servicio de Mensajería Unificada, donde se recogen todas las llamadas que no pueden ser atendidas por el usuario y las convierte en una grabación WAV para que pueda ser enviada por correo electrónico a cualquier medio.

b) IVR Manager: es un servicio de atención telefónica automático

(operadora automática) con un sencillo interface web de configuración. Los mensajes de bienvenida son completamente configurables y pueden ser obtenidos de cualquier medio.

c) BILLY: es una herramienta de reporting y de tarificación muy

completa. Su interfaz de configuración está basada en herramienta web. Permite hacer un análisis exhaustivo de número de llamadas, tiempos, números más frecuentes, etc.

5.1.5. Modelos de teléfonos Los teléfonos IP escogidos para integrarlos en el sistema de telefonía IP son varios modelos de Cisco que presentamos a continuación:

a) 7911G: tipo agente. Características: 4 teclas de programación, control de volumen, switch integrado, etc.

Fig. 4 Modelo de teléfono IP Cisco 7911G

b) 7940G: tipo supervisor o ejecutivo. Características: 8 teclas de

programación, control de volumen, switch integrado, tipos de tonos, info en display, etc.


Fig. 5 Modelo de teléfono IP Cisco 7940G

c) 7960G + 7914 (Mod. Expansor): tipo operadora. Características: 12

teclas de programación, control de volumen, switch integrado, tipos de tonos, info en display, etc.

Fig. 6 Modelo de teléfono IP Cisco 7960G + 7914 (Mod. Expansor)

5.1.6. Redundancia de Gateways Para brindar alta disponibilidad en las comunicaciones vamos a diseñar una redundancia entre los gateways de voz. Esto lo haremos configurando en el CCM un Route Group en el que configuraremos los dos gateways de voz disponibles para que si uno falla, las llamadas las enrute el CCM hacia el otro gateway. Sin embargo, si uno de los dos gateways falla, aunque el CCM tenga configurado el enrutamiento redundante, los teléfonos que dependan de ese gateway no sabrán llegar (conectividad IP, nivel 3) hasta el gateway del otro edificio. Necesitan algún dispositivo que los enrute. Este dispositivo será el router que actúa de salida a Internet en ambos edificios (1751 y 1841) y lo que haremos será configurar el protocolo HSRP entre ellos. Es decir, los teléfonos tendrán como gateway principal al 2821 que tiene conectadas las líneas RDSI. Si ese router cayera o cayera su interfaz de LAN, el router de salida a Internet de su edificio tomará el relevo en las veces de


gateway para enrutar los paquetes de telefonía hacia el gateway de voz del otro edificio y que puedan realizar llamadas. HSRP es un protocolo que permite definir un grupo de routers y una prioridad en este grupo. A este grupo se le configura una IP virtual, por la que responderá el primer miembro del grupo. Si ese miembro cae, el protocolo consigue que el segundo miembro lo sepa y entonces responderá él a la IP virtual creada. Con esta configuración conseguimos que, desde el punto de vista del usuario, exista una capa de abstracción en cuanto a quién le ofrece el servicio de gateway.

5.1.7. Interconexión de delegaciones Para la interconexión de las delegaciones con el nuevo sistema de telefonía aprovecharemos la infraestructura existente, aunque la mejoraremos. Hasta ahora los routers de las delegaciones atacaban cada uno directamente por su IPs pública contra la IP pública del CCME de Central 2. Ahora aprovecharemos para securizar las comunicaciones de voz, introduciéndolas por la VPN existente entre las delegaciones. De esta forma, en las delegaciones podremos conectar un teléfono IP en su LAN e indicándole la IP del CCM de la sede central se irá a registrar allí sin problemas. Esto es gracias a la capa de abstracción a nivel de conectividad IP que proporcionan los routers, encriptando a través del túnel VPN todo el tráfico L2L (LAN to LAN).

5.1.8. Política de Backups Se aplicarán políticas de backups tanto para los dispositivos de red como para los servidores CCM y StoneVoice. Con estas políticas nos aseguraremos de poder recuperar el sistema ante cualquier desastre, entendiendo por desastre cualquier incidencia que repercuta en el correcto funcionamiento del sistema completo. Programaremos copias de seguridad en los servidores corporativos donde se realizan las copias habituales en métodos externos, como cintas o cualquier otro dispositivo de almacenamiento exterior.


5.1.9. Plan de Numeración El plan de numeración diseñado está pensado para que los usuarios sufran el menor impacto posible a la hora de la migración de un sistema de telefonía a otro. Dispondremos de varios posibles destinos diferenciados: Central 1, Central 2, Delegaciones y Móviles. En las dos primeras dispondremos de buzón de voz, al que se accederá cambiando el primer dígito de la extensión asignada por el número ‘8’. Para las Delegaciones y para los Móviles no tiene sentido disponer de un buzón de voz. Los números de Móviles se marcan con un ‘3’ delante del número corto asignado por Vodafone, que nuestro sistema convertirá a un número largo normal de móvil (6XX.XX.XX.XX). Dentro de las llamadas Externas tenemos: móviles largos, nacionales, internacionales, servicios, etc. A estos números podemos llamar marcando el ‘0’ delante de dicho número. El plan de numeración descrito lo podemos observar en la Tabla 3.

Extensión Central 1 Central 2 Delegaciones Móviles Externas Interna 1XX 28XX 2[2-7]XX 3XXX 0 + <num. externo> Buzón Voz 8XX 8XXX n.d. n.d. n.d.

Tabla 3 Plan de numeración Este plan de numeración es diseñado integrando el ya existente (prefijos ‘2’, ‘3’, etc.) con las nuevas implementaciones (buzón de voz) para beneficiar al usuario.

5.1.10. Integración con la red existente Este proyecto no comienza de una red en blanco, sino que tenemos una situación inicial y una situación final. Por ello, tenemos que planificar la migración de una situación a otra y eso incluye la integración o adecuación de la red actual al nuevo diseño.


Podemos distinguir dos aspectos a tener en cuenta: retirada de equipos antiguos de comunicaciones y reestructuración de la red actual.

a) Retirada de equipos antiguos En el edificio de Central 1 cuentan con unos 50 de teléfonos analógicos que retiraremos para instalar los nuevos terminales de telefonía IP. La retirada y sustitución se hará de acuerdo a los puestos de trabajo de los usuarios. Además, en este edificio cuentan con una centralita analógica modelo ALCATEL OmniPCX 4X00 que retiraremos junto a los terminales analógicos una vez se haya planificado y realizado una migración progresiva de los teléfonos para que la operatividad de los usuarios se vea afectada lo menos posible. Ambas cosas (teléfonos y centralita) forman parte de un programa de recompra con el que el cliente se verá beneficiado al no tener que hacerse cargo del equipamiento a sustituir. La centralita antigua que retiraremos según el plan de recompra, tiene programadas una serie de funcionalidades que hemos intentado mantener en la medida de lo posible. La mayoría de esas funcionalidades las hemos recogido en el apartado 5.1.9 Plan de Numeración, en donde especificamos los números cortos que hemos mantenido de la programación de la centralita antigua.

b) Reestructuración de la red actual Hay varios aspectos que tendremos en cuenta a la hora de reestructurar la red actual, como son:

1. Sustitución de routers: dentro del programa de recompra incluimos también el router de la Central 2 Cisco 1760-v que actuaba como CME. Esto nos condicionará a trasladar los servicios soportados por este router (enrutamiento entre VLANs, etc.) a otros equipos.

2. Configuración de la LAN: para integrar los equipos de

comunicaciones dentro del esquema de VLANs actual hemos integrado a los Cisco 2821 dentro de la VLAN2. También hemos trasladado los servicios soportados por el router que se recompra hacia el 1841 de Central 2.

3. Reubicación de teléfonos antiguos: en el edificio de Central 2

disponen algunos teléfonos ya operativos modelo Cisco 7902. Los sustituiremos por modelos de mayores prestaciones,


redistribuyendo estos por puestos que no son de primera necesidad en cuanto a necesidades de telefonía.

5.1.11. Ubicaciones físicas Una vez estudiados y decididos los elementos de la electrónica de red que vamos a introducir en la red, debemos decidir donde, cómo y porqué colocarlos en una ubicación u otra. Analizaremos los distintos emplazamientos de que disponemos para decir cual cumple mejor con nuestras necesidades.

a) Racks disponibles: disponemos de dos armarios de comunicaciones o racks: uno en Central 1 y otro en Central 2. En la Tabla 4 hemos realizado una comparativa en la que veremos reflejados las diferencias entre uno y otro. Los aspectos que valoramos son los básicos de cualquier rack: ventilación, limpieza, acceso controlado, si cuenta con Sistemas de Alimentación Ininterrumpida (SAI), cómo llega el cableado hasta él y los enlaces cercanos de qué dispone. Hemos puntuado con una escala de 0 a 5 las distintas características.

Características Rack Central 1 Rack Central 2 Ventilación 2 -> Bastante mala 4 -> Muy buena Limpieza 0 -> Mala 4 -> Muy buena Acceso controlado 2 -> No en todo el horario 5 -> Siempre Cableado hasta él 2 -> Bastante malo 4 -> Muy bueno SAI 0 -> No dispone 3 -> SAI pequeño Enlaces disponibles 0 -> Ningún enlace 3 -> Líneas normales Puntuación 6 23

Tabla 4 Comparativa entre racks de la sede central

Como vemos el rack óptimo es de Central 2, donde ubicaremos el CCM, elemento central de la telefonía IP de esta instalación, además del gateway de voz de esta sede. En el rack de Central 1, no podremos ubicar nuestro gateway de voz, ya que no tenemos enlaces que lleguen a él. En el siguiente apartado describiremos el lugar escogido para este dispositivo. b) La centralita analógica será sustituida por el gateway de voz y está

ubicada en un pequeño armario en la entrada de la Central 1, donde se encuentra los enlaces de telefonía y los móviles. Tendremos que colocar allí nuestro gateway de voz y aprovechar el único cable de red que une esta ubicación con el rack de este edificio para poder integrarlo en la LAN.


c) Los servidores que necesitamos para nuestras aplicaciones son

dos: uno para el CCM y otro para el StoneVoice. Para el primero ya disponemos de un servidor físico que lo albergará, pero para el segundo no. Hemos pensado en la posibilidad de virtualizarlo. Virtualizar un servidor consiste en crear una máquina virtual (dentro de una máquina física) en la que instalaremos nuestra aplicación. Como ya hemos visto antes, el servidor del CCM lo ubicaremos en el rack de la Central 2 y en ese mismo servidor será donde instalaremos la máquina virtual que alojará la aplicación del StoneVoice. De este modo conseguimos independencia de cualquier otro servidor que no cumpla las condiciones deseadas de disponibilidad, accesibilidad y capacidad que necesita dicha aplicación.

d) Los nuevos teléfonos deben instalarse de acuerdo a los planos de

reparto de terminales que nos ha proporcionado el cliente. En ellos está recogido qué terminal debe llevar cada usuario, ya sea terminal nuevo o antiguo reasignado, y también la extensión que le corresponda.

5.1.12. Limitaciones Las limitaciones propias de esta red de telefonía en cuanto a capacidad de enfrentarse a fallos en el sistema son varias. Para intentar combatir una de las principales, contamos con un sistema llamado SRST (Survivable Remote Site Telephony) cuyo funcionamiento es el siguiente: en caso de fallo del CCM los teléfonos se registrarán en el gateway de voz que tengan configurado como dispositivo SRST. Este dispositivo hará las veces de CCM y de gateway a la vez, con lo que los teléfonos continuarán funcionando con normalidad, pese al fallo del CCM. Este sistema tiene varias limitaciones:

• Sólo pueden recibir 1 llamada simultánea. • No pueden transferir llamadas entre terminales.

• Si tuvieran un desvío aplicado antes de la entrada en funcionamiento del

SRST, tendrían que volver a programarlo. Otras limitaciones del diseño de telefonía relacionadas con los gateways de voz son:

• Si cae un gateway de voz, perdemos los enlaces que tiene conectados. Eso implica que no podremos realizar ni recibir llamadas por las RDSIs ni TRACs de móviles conectadas al dispositivo.


• Si caen los dos gateways de las VLANs de voz de la central, tan solo se podrán realizar llamadas internas gracias al CCM.

5.2. Visado técnico Una vez que tenemos listo nuestro diseño de la solución, falta un proceso antes de poder presentárselo al cliente. Este proceso es el visado técnico, que consiste en que el responsable del área técnica que se encargará de la implantación de la solución tiene que revisar la solución propuesta y decir si es viable o no. Dentro de este visado se pude incluir alguna mejora de la solución propuesta y ciertos retoques que el visador considere oportunos para asegurar la viabilidad de la solución que se quiere proponer. Con este visado técnico lo que se pretende es asegurar un sello de calidad en la venta del proyecto. Esto quiere decir que cuando el proyecto pase a su fase de implantación no se deben encontrar problemas por carencias de fases anteriores, como falta de especificaciones o problemas graves que impidan la implementación técnica sin una profunda remodelación del diseño de solución presentada al cliente.

5.3. Valoración comercial Finalmente, una vez que disponemos de una solución diseñada realizaremos la valoración comercial o presupuesto que será el que presentemos al cliente para que la estudie y compare con el resto de propuestas que reciba. El presupuesto realizado lo podemos ver en la Tabla 5. Cant Código Descripción

PVD. Unit (€)* PVD. Total (€)

1 CISCO CALL MANAGER 4.3 + Servidor + Licencias + Inst. + Config

1 MCS-7815-I2-IPC1 HW Only MCS-7815-I2 with 2GB RAM and 80GB SATA HD n.d. n.d.

1 CM4.3-K9-7815I2S-1 SW Only, CallManager 4.3 For MCS 7815-I2, 100 User n.d. n.d.

Subtotal 6.018,38 € 6.018,38 €

2 ROUTER CISCO 2821 + Tarjetas RDSI + Tarjetas Móviles

2 CISCO2821-SRST/K9

2821 Voice Bundle w/ PVDM2-32,FL-SRST-48,SP Serv,64F/256D n.d. n.d.

2 NM-HD-2V= Two-slot IP Communications Voice/Fax Network Module n.d. n.d.

5 VIC2-2BRI-NT/TE= Two-port Voice Interface Card - BRI (NT and TE) n.d. n.d.


2 PVDM2-64= 64-Channel Packet Voice/Fax DSP Module n.d. n.d.

1 VIC2-2FXO= Two-port Voice Interface Card - FXO (Universal) n.d. n.d.

Subtotal 5.945,93 € 11.891,86 €

TELÉFONOS + Transformadores + Cables 1 CP-7960G-CH1 7960 IP Phone with one Station User License 345,00 € 345,00 €7 CP-7940G-CH1 7940 IP Phone with one Station User License 288,00 € 2.016,00 €

26 CP-7911G-CH1 Cisco IP Phone 7911G with 1 RTU License 231,00 € 6.006,00 €2 CP-7914= 7914 IP Phone Expansion Module 174,35 € 348,69 €

1 CP-SINGLFOOTSTAND= Footstand kit for single 7914 14,57 € 14,57 €

32 CP-PWR-CUBE-3= IP Phone power transformer for the 7900 phone series 22,00 € 704,00 €

32 CP-PWR-CORD-CE= 7900 Series Transformer Power Cord, Central Europe 12,00 € 384,00 €

Subtotal 1.086,91 € 9.818,26 €

SOFTWARE STONE VOICE 1 SV-SSAM-CCM-4-M SSAM for Unified CallManager (CCM) - 4 ports 4.950,00 € 4.950,00 €1 SV-BIL-CCM-1-M Billy for Unified CallManager (CCM) 2.500,00 € 2.500,00 €

1 SV-IVR-CCM-4-M IVR Manager for Unified CallManager (CCM) – Up to 4 instances 1.650,00 € 1.650,00 €

RECOMPRA

1 Centralita ALCATEL OmniPCX 4X00 44 Telefonos Analógicos

1 Router CISCO 1760V-CCME Subtotal - 1.717,00 €

INSTALACIÓN Y CONFIGURACIÓN

3.600,00 € 3.600,00 €

Total (IVA incl. ) 38.711,50 €

MANTENIMIENTO REMOTO 24x7 (No incluye reposicion de Hardware) 625€/mes

Tabla 5 Valoración comercial de la Solución

6. IMPLANTACIÓN En este capítulo llevaremos acabo la implantación de la solución propuesta en el sistema del cliente. Describiremos un diseño propio de la fase de implantación, estudiaremos el impacto de trabajar en un sistema en producción, veremos las implicaciones


que conllevará a la red local y ejecutaremos las tareas propias de la implantación. Una vez ejecutadas dichas tareas tendremos una fase de pruebas que nos llevará finalmente a pasar el sistema a producción. Daremos formación a los usuarios y detallaremos el servicio que hemos proporcionado.

6.1. Diseño de implantación Dentro de la fase de implantación realizaremos un diseño que entrará más en detalle que el diseño realizado al diseñar la solución. Profundizaremos en los aspectos técnicos que son necesarios a la hora de llevar a la implementación el proyecto, como son el direccionamiento IP a utilizar, qué servidores DHCP utilizaremos, etc.

6.1.1. Direccionamiento IP El direccionamiento IP que vamos a utilizar, lo podemos dividir según su ámbito: LAN o WAN. Dentro del direccionamiento LAN, a su vez, podemos dividir según los dos edificios de la sede central.

a) Central 1: 1. VLAN 1 – 172.16.0.0 /16 Datos. 2. VLAN 2 – 10.0.1.0 / 24 Voz. 3. VLAN 3 – 172.31.1.0 /28 Routers.

b) Central 2:

1. VLAN 1 – 172.17.0.0 /16 Datos. 2. VLAN 2 – 10.0.0.0 /24 Voz. 3. VLAN 3 – 172.31.1.0 /28 Routers. 4. VLAN 5 – 172.20.1.0 /24 Servidores receptora. 5. VLAN 6 – 172.20.2.0 /24 Servidores imágenes. 6. VLAN 7 – 172.20.3.0 /24 Servidores bidireccional.

La VLAN 3 es la que tienen en común los routers de ambas centrales y, por tanto, es por donde tienen visibilidad de nivel 3 una de la otra. El direccionamiento LAN descrito lo podemos observar en la Fig. 3.

IMPLANTACIÓN 27

En cuanto al direccionamiento WAN, tenemos el direccionamiento de cada red local de cada sede remota. A estas LANs tendremos acceso a través de las VPNs que montaremos contra cada una de las delegaciones remotas.

a) Madrid 10.118.76.0 /24 b) Reus 192.168.1.0 /24

c) Valencia 192.168.2.0 /24

d) Sevilla 192.168.4.0 /24

e) Asturias 192.168.5.0 /24

El direccionamiento WAN descrito lo podemos observar en la Fig. 2.

6.1.2. Servidores DHCP Los servidores DHCP también los podemos dividir según el ámbito que tratemos. En el ámbito LAN hemos habilitado el servicio DHCP para la VLAN de voz, donde los teléfonos utilizarán DHCP para obtener los parámetros necesarios para su funcionamiento. El más importante es la opción de servidor TFTP, numerada como 150, y que configuraremos con la ip del CCM. Gracias a esta opción, los terminales bajarán del servidor TFTP del CCM la configuración que necesiten. Del rango disponible (10.0.1.1 – 10.0.1.254 y 10.0.0.1 – 10.0.0.254), las primeras diez direcciones y las dos o tres últimas están reservadas para dispositivos de red actuales o futuros. El resto de direccionamiento lo hemos dividido en dos. La parte inferior del rango (.11 a 128) las asignará el router que actúa como gw secundario (1751 o 1841). La parte superior del rango (.129 a .252 o 251) se la queda el router que actúa como gw principal (2821). De esta forma tendremos a los dos routers de cada sede actuando como servidores DHCP a la vez, pero sin interferirse. Así, si cayera el gw principal, el secundario podrá seguir asignando direcciones sin problemas.

a) Central 1:

1. Rango router 1751: 10.0.1.11 hasta 10.0.1.128. 2. Rango router 2821: 10.0.1.129 hasta 10.0.1.252.

b) Central 2:


1. Rango router 1841: 10.0.0.11 hasta 10.0.0.128. 2. Rango router 2821: 10.0.0.129 hasta 10.0.0.251.

En el ámbito WAN trataremos las sedes remotas de que disponemos. En ellas no tendremos separación por VLAN entre voz y datos. Conectaremos un teléfono IP directamente a la red de datos y vía conectividad por la VPN se asociará con el CCM como un teléfono local normal. Esto lo hará de la misma manera que hemos comentado anteriormente, es decir, utilizando la ip del CCM que estará configurada en la opción 150 de la respuesta que el servidor DHCP proporcionará al terminal. En cuanto al rango de direcciones a asignar, es bastante más sencillo que el ámbito LAN ya que no disponemos de tantos dispositivos que necesiten conectividad. Por tanto, reservaremos un rango de direcciones por cada delegación, que esté fuera de las ip’s utilizadas por los pocos pc’s que estén conectados.

a) Madrid 10.118.76.101 - 10.118.76.254 b) Reus 192.168.1.201 - 192.168.1.234

c) Valencia 192.168.2.201 - 192.168.2.254

d) Sevilla 192.168.4.201 - 192.168.4.254

e) Asturias 192.168.5.201 - 192.168.5.254

6.1.3. Configuración HSRP Hemos hablado de que por cada VLAN de voz tendremos un gw principal y uno secundario, y que si fallaba el principal el secundario tomará el relevo. Pero, ¿cómo se implementa esto? La respuesta es el protocolo HSRP que, a grandes rasgos, es una forma de configurar failover en un default Gateway. Es decir, configuramos un dispositivo que hará de Gateway principal y si este cae lo relevará en el dispositivo secundario y así sucesivamente. Esto se consigue definiendo un grupo con una IP virtual a la que responderán todos los dispositivos del grupo en caso de que sean el dispositivo principal. Esta IP virtual será la que utilizarán los dispositivos que estén en el segmento de red como default Gateway. En nuestro caso, definiremos las siguientes configuraciones de HSRP:

IMPLANTACIÓN 29

a) Central 1:

1. IP router 2821: 10.0.1.1 (prioridad 200) 2. IP router 1751: 10.0.1.2 (prioridad 50) 3. IP Virtual HSRP: 10.0.1.253

b) Central 2:

1. IP router 2821: 10.0.0.1 (prioridad 200) 2. IP router 1751: 10.0.0.2 (prioridad 50) 3. IP Virtual HSRP: 10.0.0.253

6.2. Impacto sobre el sistema en producción Antes de comenzar con la implementación del proyecto en la infraestructura del cliente tenemos que pensar en que no partimos desde cero sino que tenemos que trabajar sobre un sistema que está en producción. Más concretamente, el mayor impacto lo sufrirá el sistema de telefonía que es sobre el que realizaremos la mayor parte de actuaciones, migrando un sistema con núcleo analógico a completamente digital, trabajando bajo TCP/IP. Pero también la red de datos sufrirá modificaciones ya que algunos dispositivos serán suprimidos de la red, además de introducir a los elementos de telefonía en esta red, como ya hemos comentado con anterioridad. Todo ello nos condicionará a la hora de trabajar. Deberemos planificar las intervenciones de manera que se minimice el impacto el sistema del cliente, puesto que su producción tiene que verse afectada lo menos posible. Es inevitable que existan puntos críticos durante la implantación del proyecto en los que se tendrá que interferir en la producción. Es fundamental identificar estos puntos para tenerlos controlados en todo momento. Lo forma ideal de tratar a estos puntos es con la programación de ventanas de actuación, que consisten en definir intervalos de tiempo consensuados con el cliente en los que se llevarán a cabo las operaciones críticas del proyecto. Durante el transcurso de esta ventana podremos interrumpir la actividad normal del sistema con una condición: cada paso que demos debe tener una vuelta atrás. Con esta vuelta atrás nos aseguramos que al finalizar la ventana de actuación podamos dejar el sistema en un estado operativo.


6.3. Tareas En esta fase realizaremos las tareas propias de la implantación del proyecto. Tendremos varias tareas diferenciadas y que se deberán llevar a cabo por etapas hasta llegar a la realización completa del proyecto. Comenzaremos preparando el hardware de los dispositivos que intervendrán en la red, los instalaremos y configuraremos. Luego continuaremos configurando el CCM que es el “cerebro” o centralita IP y el servidor de Stone Voice, encargado del software de aplicaciones adicionales.

6.3.1. Diagrama de Gantt Hemos elaborado un diagrama de Gantt para las tareas de la fase de implantación. Este diagrama nos servirá para tener una planificación detallada por tareas en el tiempo sobre la que basarnos. Así sabremos en todo momento en qué punto estamos, cuánto y qué nos falta y si debemos dedicar más o menos tiempo a una tarea u otra.

Fig. 7 Diagrama de Gantt general

Como vemos en la Fig. 7 las tareas comienzan en la segunda semana de Noviembre de 2007 y se alargan hasta la primera semana de Enero de 2008, resultando un total de 8 semanas aproximadamente. Las tareas que están descritas son:

• Instalar hardware en los routers. • Instalación física de los equipos. • Configuración de los dispositivos de red. • Instalación del software en los servidores. • Configuración de los servidores. • Fase de pruebas. • Puesta en producción.

IMPLANTACIÓN 31

• Retirada de dispositivos antiguos analógicos. • Formación de usuarios. • Integración de delegaciones.

Cada una de estas tareas será descrita con más detalle en los siguientes apartados.

6.3.2. Instalar hardware en los routers El diagrama de Gantt detallado para esta tarea lo vemos en la Fig. 8.

Fig. 8 Diagrama Gantt detallado para Instalación de HW en routers

Como ya hemos visto, los routers que actúan como Gateway de voz son Cisco 2821 y sobre estos dispositivos es donde realizaremos la instalación de hardware. Comenzaremos instalando los módulos de expansión de red (NM-HD-2V). Estos módulos traen interfaces para conectar tarjetas VICs (Voice Interface Cards), que permiten interconectar al Gateway con los distintos dispositivos externos de telefonía. Para instalarlo, desatornillaremos la bahía de protección trasera del router e introduciremos nuestro módulo de expansión de red, atornillándolo una vez haya entrado por completo. A continuación instalaremos los módulos PVDM (Packet Voice Digital Signal Processor Module). Estos módulos son los que integran los procesadores digitales de la señal con los que podremos realizar la conversión analógico-digital y viceversa de la voz. En nuestro contamos con un PVDM2-64, cuyas características las resumimos en la Tabla 6.

Tabla 6 Características del módulo PVDM2-64


Así mismo, los codecs soportados de gama alta y media los vemos en la Tabla 7.

Tabla 7 Codecs soportados por el módulo PVDM2

Para instalar el módulo en el router deberemos abrir la tapa superior del mismo y localizar las ranuras de expansión para estos módulos. El detalle de esta operación lo apreciamos en la Fig. 9, donde el slot que nos interesa es el marcado con el número ‘3’.

Fig. 9 Detalle del interior del router Cisco 2821

Una vez localizados, introduciremos el módulo PVDM en el slot libre y volveremos a cerrar la tapa superior del router. El resultado lo podemos observar si arrancamos el router y ejecutamos el comando “show diag”. En su salida vemos como en el Slot 0 tenemos el PVDM2-32 que trae integrado el router y en el Slot 1 tenemos el PVDM2-64 que hemos añadido nosotros. Por último, introduciremos en el router las tarjetas VIC2-2FXO= y VIC2-2BRI-NT/TE=. La primera la utilizaremos para enlazar con los dos TRACs de móviles gracias a los dos puertos FXO (Foreign Exchange Office. Para conectar a las líneas RDSIs que nos darán salida a la red telefónica utilizaremos las tarjetas VIC2-2BRI-NT/TE=.

IMPLANTACIÓN 33

6.3.3. Instalación física de los equipos El diagrama de Gantt detallado para esta tarea lo vemos en la Fig. 10.

Fig. 10 Diagrama Gantt detallado para Instalación física de equipos

Comenzaremos instalando primero los routers que actuarán de gateways y que irá cada uno en cada edificio de la central. En la Central 1 lo colocaremos en un pequeño armario que hay en la sala de visitas, ya que allí es donde el operador de telefonía ha colocado los puntos de conexión a la red de telefonía, es decir, las líneas RDSIs y los TRACs de móviles. Hasta ahora, en esta ubicación solo había la centralita analógica como dispositivo de comunicaciones, que disponía de un módulo digital conectado por un cable contra el rack de comunicaciones que está en otra sala. En la Central 2 colocaremos el router en el rack de comunicaciones que se encuentra en la garita del vigilante. En este mismo armario tenemos la electrónica de red de la LAN y justo en frente tenemos las RDSIs y los TRACs de móviles para este edificio, por lo que nos será mucho más fácil la interconexión. Continuaremos instalando el CCM que, según hemos visto en el apartado 5.1.11, colocaremos en el rack de la Central 2 por reunir unas mejores condiciones para albergar este tipo de dispositivos. Lo instalaremos a la misma altura que el router que hemos instalado anteriormente. Pasaremos ahora a instalar los nuevos teléfonos IP que ubicaremos según las indicaciones del cliente, atendiendo a los modelos de teléfono que nos indique según el punto de trabajo en que nos encontremos. Los modelos los podemos consultar en el apartado 5.1.5. Comenzaremos instalando los teléfonos nuevos en la Central 1 que es donde solo contaban con terminales analógicos. Mientras que montamos el sistema y no lo pasamos en producción, los usuarios tendrán dos teléfonos en su mesa: el antiguo analógico y el nuevo IP.


En la Central 2 instalaremos también los nuevos terminales en sus posiciones correspondientes y recogeremos los antiguos terminales modelo Cisco 7902. Estos teléfonos no cuentan con switch integrado para conectar el pc a ellos, ni con pantalla en la que ver información del teléfono, así como otras funcionalidades que los modelos nuevos si traen. Una vez terminada la instalación de los nuevos terminales, reubicaremos los antiguos 7902 que hemos recogido en la Central 2 y los repartiremos en las ubicaciones que faltan de la Central 1. Por último, como interconexión de equipos realizaremos las conexiones de los distintos dispositivos a la red local. En el caso del router de la Central 1 aprovecharemos el único cable de red que esta siendo usado por el módulo digital de la antigua centralita analógica para conectarlo a uno de los switches del rack de ese edificio. En el caso del router de la Central 2 no tendremos que inventar nada raro para conectarlo a la red puesto que ya está instalado en el mismo armario de comunicaciones que ellos. Respecto a los teléfonos solo tendremos que conectarlos a la roseta de red más cercana. Nos hemos encontrado algunos casos en los que no disponían de parcheado en los patch panels para las rosetas de red que les correspondían y hemos tenido que hacer los correspondientes parcheos sin mayores problemas.

6.3.4. Configuración de los dispositivos de red El diagrama de Gantt detallado para esta tarea lo vemos en la Fig. 11.

Fig. 11 Diagrama Gantt detallado para Configuración de dispositivos de red

IMPLANTACIÓN 35

a) Routers. La parte de configuración de routers la comenzamos trasladando los servicios soportados por el router que se recompra al Gateway de datos de la Central 2. Estos servicios son las VLANs 5, 6 y 7 que se utilizan para algunos servidores. Crearemos en el 1841 de Central 2 estás VLANs y le asignaremos la misma IP que tenía el otro router de forma que, para los equipos clientes, el cambio de Gateway será transparente. También actualizaremos las rutas correspondientes y las listas de acceso, incorporando las líneas que tenía el otro dispositivo si procede. Pasando al Gateway de voz, configuraremos sus puertos de voz, más concretamente los dos puertos FXO que van conectados a las líneas de móviles. Introduciremos una descripción con el número de móvil al cuál pertenece y mediante el comando “connection plar” haremos una interconexión con la extensión que queremos que suene cuando se llame a esos números. También configuraremos las opciones del protocolo SCCP para asociarlo con el CCM así como los perfiles de los codecs DSP para poder luego definir los recursos hardware y software que utilizará el CCM. Respecto a las tarjetas RDSI, configuraremos cada puerto de todas las tarjetas de red de forma que definiremos el tipo de switch, el tipo de enlace y demás parámetros necesarios para el funcionamiento. Para poder aplicar el dial-plan establecido es necesario que configuremos los dials-peers. Estos parámetros identificarán el origen y destino de las llamadas y definirán parámetros asociados a ellas. A grandes rasgos, existen dos tipos de dials-peers atendiendo a su origen o destino: los de voip y los de pots. Configuraremos los dial-peer prácticamente igual en ambas sedes, variando el número de dial-peers por las tarjetas que tiene cada uno, por el direccionamiento y algunos detalles más. En la Tabla 8 podemos observar distintas características que hemos configurado en los dial-peers para la Central 1 y para la Central 2:

• Destino de la llamada, según sea a fijos, móviles, mensaje de bienvenida IVR, restricción de llamadas, extensiones internas o números virtuales creados como grupos de salto o Hunt groups.

• Sentido de las llamadas, es decir, si la configuración es aplicable para

las llamadas salientes, entrantes o en ambos casos.


• Número oculto en la llamada. Esta característica la aplicaremos en las

llamadas salientes en las que queramos ocultar nuestro número origen.

• Prioridad del dial-peer, que en la tabla hemos representado como ‘1’ o ‘2’, en la configuración real tendremos la mayor prioridad con el número ‘0’ y decrece conforme aumentamos el número asignado. De esta forma podemos definir distintas alternativas en función de si están disponibles o no.

• Dispositivo por el que saldrán enrutadas las llamadas. En el caso de los

dial-peers pots serán los puertos de las líneas RDSI o FXO y en el caso de direcciones IP serán las IP de los GWs o del CCM.

Destino Sentido Nº

Oculto Prioridad Dispositivo

Dial-peer

Central 1

Dial-peer Central 2

Entrantes No 1 RDSI 30 a 37 n.d.

1 RDSI 2 a 9 2 a 7 No 2 FXO 10 y 11 8 y 9

Fijos Salientes Si 1 RDSI 12 y 13 10 y 11

1 FXO 22 y 23 18 y 19 No 2 RDSI 14 a 21 12 a 17 Móviles Salientes

Si 1 FXO 24 y 25 20 y 21

IVR Entrantes No 1 IP GW local 40 40

Restricción Salientes No 1 Null (no

enrutadas) 69 a 71 69 a 71

No 1 IP CCM 998 y 999 999 Ext.

Internas Ambos No 2 IP GWs

550 y 551 550 y 551

Hunt Pilots Ambos No 1

IP CCM 996 y 997 n.d.

Tabla 8 Resumen de parámetros de dial-peers por sede En cuanto a la función de SRST, en los GWs configuraremos dentro de la opción call-manager-fallback los parámetros necesarios para que puedan soportar el registro de los teléfonos si cae el CCM.

IMPLANTACIÓN 37

Estos parámetros son, a grandes rasgos, los siguientes: número máximo de conferencias, idioma, ip y puerto con la que se asociará, número máximo de teléfonos soportados, patrones de transferencia, etc. Como números directos configuraremos los DDIs (o DID, Direct Inward Dialing) que consiste en definir una regla para trasladar los números largos externos hacia una extensión interna. Por ejemplo, si marcamos el 93.123.45.67 y queremos que suene directamente en la extensión 112, configuraremos el siguiente comando en el GW que disponga de la línea que tenga asociada ese DDI: num-exp 931234567 112. Una vez que ya tenemos nuestros routers prácticamente configurados, realizaremos una limpieza de configuraciones que consistirá en quitar los comandos que ya no estén realizando ninguna función. Una muestra de estos comandos a limpiar es la configuración de dial-peers existente en el GW de datos en Central 1. Además, actualizaremos las rutas de los dispositivos asegurarnos de que todas las redes son alcanzables y ellas pueden alcanzar al resto. Utilizaremos la VLAN 3 para hacer que las redes de las sedes se vean entre sí, enrutadas mediante los routers de que disponemos. También aprovecharemos para añadir tracking sobre las ADSL. Esto consiste en monitorizar el siguiente salto hacia la WAN desde los GWs frontera y si no pudieran ser alcanzados en período determinado y tras algunos reintentos, se enrutaría todo el tráfico de esa interfaz hacia el otro GW frontera con salida a Internet. Así conseguimos configurar un failover de ADSL entre los dos GWs. También configuraremos HSRP dentro de la VLAN 2, la de voz, según hemos explicado en el apartado 6.1.3. De esta forma tendremos failover a nivel de GW para la VLAN de voz. Por último, configuraremos los parámetros de AAA accounting necesarios para que un el GW envíe a un servidor RADIUS la información de detalles de llamadas.

b) Switches. En lo que respecta a los switches, deberemos configurar los puertos de manera que quede definida la VLAN 2 como voz. Esto lo haremos mediante el comando switchport voice vlan 2 de forma que cuando se conecte un teléfono a este puerto, el switch lo reconocerá como dispositivo de voz y le asignará la VLAN 2.


También añadiremos el comando spanning-tree portfast que nos acelerará el proceso de configuración del spanning-tree, si conocemos que en ese puerto no se va a conectar ningún dispositivo que nos pueda provocar un bucle (switches, hubs, etc). En cuanto a la calidad de servicio (QoS, Quality of Service), hemos utilizado una configuración sencilla que confía en el marcado de los paquetes del dispositivo que tiene detrás. Además, le indicaremos que el dispositivo es un teléfono IP Cisco. Para todo ello utilizaremos el comando mls qos trust device cisco-phone. En el apartado 5.1.3 hemos expuesto la importancia de desarrollar una política de QoS acorde con los requerimientos de latencia y pérdida de paquetes de voz. Configuraremos los puertos donde vayan conectados los routers, switches u otros dispositivos como trunks. Este tipo de puertos, a diferencia de los de acceso, es miembro de todas las VLANs que existen en el switch local y puede transportar el tráfico marcado de dos maneras: ISL (Inter-Switch Link, propietario de Cisco) o 802.1Q, que será el que utilizaremos en nuestro caso.

6.3.5. Instalación del software en los servidores El diagrama de Gantt detallado para esta tarea lo vemos en la Fig. 12.

Fig. 12 Diagrama Gantt detallado para Instalación del software en los servidores

a) CCM La instalación del CCM la comenzaremos instalando el sistema operativo en el servidor que albergará la aplicación un MCS (Media Convergence Server) 7815. Para ello utilizaremos la imagen que trae el siguiente cd de instalación:

IMPLANTACIÓN 39

• Cisco IP TELEPHONY SERVER OS 2000.4.3.(a) INSTALLATION/RECOVERY. For 7815l, 7825l, 7835l, 7845l or IBM Server.

Esto nos instalará un sistema operativo Windows 2003 prácticamente limpio en el que podremos instalar nuestro software de telefonía. A continuación instalaremos los cds de instalación del CCM que será el corazón de nuestra telefonía IP. Utilizaremos el siguiente cd de instalación:

• Cisco CallManager versión 4.3. Disk 1 y 2. INSTALLATION, UPGRADE AND RECOVERY.

Una vez hayamos terminado de seguir los pasos del asistente y se haya terminado la instalación, introduciremos la aplicación que nos permitirá realizar copias de seguridad de nuestra base de datos del CCM. Utilizaremos el siguiente cd de instalación:

• Backup Utility: Cisco CallManager versión 4.0(11) Backup Utility. La aplicación se llama BARS (Backup and Restore System) y es bastante útil y sencilla de utilizar.

b) StoneVoice A continuación procederemos a instalar la máquina virtual VMware sobre la que instalaremos el software de StoneVoice. Nos descargaremos el VMware Server que es gratuito y lo instalaremos. El archivo descargado se llama VMware-server-installer-1.0.4-56528.exe y ocupa unos 150MB. Haremos uso de una imagen que ya cuenta con un sistema operativo instalado (Windows Server 2003) y será aquí donde instalemos nuestro software. Ya estamos en disposición de descargarnos el software de la web de StoneVoice para su instalación. El archivo descargado es StonevoiceAppSuite-2.4.0.2-ccm-es+en.exe y ocupa unos 16MB. Deberemos instalar las licencias para nuestros productos SSAM, IVR y BILLY. El proceso es un poco engorroso, pero finalmente conseguimos que nos envíen por email el Unlock code para cada aplicación que nos permite completar el proceso.

6.3.6. Configuración de los servidores El diagrama de Gantt detallado para esta tarea lo vemos en la Fig. 13


Fig. 13 Diagrama Gantt detallado para Configuración de los servidores

a) CCM

La configuración de nuestro CCM es un tema que trataremos en el ANEXO A. CONFIGURACIÓN DEL CISCO CALLMANAGER. Su correcta configuración es de vital importancia al ser la centralita IP de nuestro sistema de telefonía, es decir, la que soportará toda la carga de señalización, enrutamiento de llamadas y demás decisiones críticas en el sistema.

b) StoneVoice La configuración de las aplicaciones de StoneVoice la detallaremos en el ANEXO B. CONFIGURACIÓN DEL STONEVOICE, donde veremos como configurar las aplicaciones SSAM, IVR y BILLY. Estas aplicaciones son las que nos darán funcionalidades de valor añadido, complementando nuestro sistema de telefonía al integrarse completamente que la solución implementada de Cisco.

IMPLANTACIÓN 41

6.3.7. Fase de pruebas El diagrama de Gantt detallado para esta tarea lo vemos en la Fig. 14.

Fig. 14 Diagrama Gantt detallado para la Fase de pruebas

Para iniciar la fase de pruebas conectaremos una de las líneas RDSI y de móviles a cada Gateway de las sedes. Asociaremos algunos teléfonos nuevos con el CCM, configurándoles las ips dentro del rango de la VLAN de voz correspondiente. Realizaremos pruebas de llamadas entrantes y salientes entre los internos, hacia la red PSTN o hacía los móviles y terminaremos de pulir algunos aspectos de configuración en los dial-peer. Comprobaremos si el CCM enruta correctamente las llamadas al Gateway oportuno, según el origen interno de la llamada. Probaremos también las funcionalidades del buzón de voz, llamando a un interno y esperando a que salte. Dejaremos un mensaje y veremos como al usuario se le enciende el led del teléfono y puede entrar a su menú del buzón de voz autenticándose y recuperar el mensaje grabado. Llamaremos también al número de cabecera, probando que salte correctamente el mensaje de bienvenida del IVR, así como a los números directos que no pasan por este mensaje de bienvenida y van hacia la extensión configurada. En esta fase corregiremos los posibles fallos de configuración detectados, haciendo que el sistema cumpla al máximo con los requerimientos establecidos en el proyecto.

6.3.8. Puesta en producción El diagrama de Gantt detallado para esta tarea lo vemos en la Fig. 15.


Fig. 15 Diagrama Gantt detallado para la Puesta en producción

En esta fase será donde migremos el sistema actual analógico de telefonía hacía el nuevo sistema de telefonía IP. Tendremos que sacar de producción a la centralita analógica e introducir el Cisco 2821 en la Central 1 y en la Central 2 tendremos que sacar de producción al antiguo CME y conectar de igual modo al otro Cisco 2821. Conectaremos todas las líneas RDSI y de móviles a los nuevos dispositivos, asegurándonos de que tienen conectividad y que no queda ninguna línea caída. Haremos que todos los teléfonos IP cojan IP de los servidores DHCP de los 2821 y se asocien contra el CCM. Nos aseguraremos de que las llamadas al número de cabecera entren correctamente a la centralita pasando por el mensaje de bienvenida del IVR. Antes del paso a la siguiente fase dejaremos el sistema un par de días en observación para asegurarnos de que todo funciona como debe, por si tuviéramos que hacer una vuelta atrás de urgencia por alguna incidencia no controlada.

6.3.9. Retirada de dispositivos analógicos El diagrama de Gantt detallado para esta tarea lo vemos en la Fig. 16.

Fig. 16 Diagrama Gantt detallado para la Retirada de dispositivos analógicos

Una vez que nuestro nuevo sistema en producción ha estado estable un par de días, procederemos a retirar los dispositivos analógicos.

IMPLANTACIÓN 43

Aquí incluimos a la centralita analógica que deberemos retirar de la Central 1. Nos quedarán sueltos todos los cables que vienen de las tomas de telefonía analógicas que, hasta ahora, se conectaban contra esta centralita. También retiraremos todos los terminales analógicos de la Central 1, excepto en un par de ubicaciones donde disponen de líneas analógicas directas para un par de números 902 que van directos hasta allí. Durante la retirada de cada terminal nos aseguraremos de que el usuario dispone del terminal IP con todas las funcionalidades operativas para que pueda trabajar sin ningún problema.

6.3.10. Formación de usuarios El diagrama de Gantt detallado para esta tarea lo vemos en la Fig. 17.

Fig. 17 Diagrama Gantt detallado para la Formación de usuarios

Para la formación de usuarios organizaremos, junto con un contacto responsable del cliente, grupos de formación en donde repartiremos guías rápidas de fácil consulta a las que podrán hacer referencia en cualquier momento. A estos grupos se les dará una formación más práctica que teórica sobre el uso de los terminales, explicándoles las funcionalidades principales que permiten los nuevos teléfonos IP con ejemplos en tiempo real donde puedan interactuar y aprender. Las principales funcionalidades básicas que explicamos fueron:

• Atender una llamada. • Realizar una llamada. • Re-llamadas. • Ajustar el volumen del timbre. • Poner una llamada en espera.


• Visualizar el registro de llamadas. • Acceso al buzón de voz. • Navegación básica por los menús del teléfono. • Búsqueda en el directorio corporativo.

También explicamos funcionalidades más avanzadas:

• Transferencia de llamadas. • Desvío de llamadas. • Realizar conferencias. • Marcaciones rápidas. • Grupos de captura.

Conforme íbamos explicando las funcionalidades, aparecían las dudas que intentábamos resolver de manera práctica. De cualquier modo, durante las siguientes visitas también fuimos resolviendo dudas que iban apareciendo a lo largo del día a día en el uso cotidiano de los terminales.

6.3.11. Integración de delegaciones El diagrama de Gantt detallado para esta tarea lo vemos en la Fig. 18.

Fig. 18 Diagrama Gantt detallado para la Integración de delegaciones

Una vez que tenemos operativa la delegación principal, integraremos las sedes remotas en cuanto a telefonía IP se refiere. Primero actualizaremos el túnel VPN de cada delegación para que introduzcan todo el tráfico de la VLAN de voz hacia el direccionamiento de LAN remoto. Con esto nos aseguraremos conectividad IP de forma transparente y segura entre los dispositivos conectados en la LAN remota y el CCM, gateways y demás terminales IP. En los routers de cada delegación configuraremos un servidor DHCP con un rango pequeño de direcciones IP a asignar dentro del ámbito de LAN local y con la opción 150 de TFTP con la ip del CCM (10.0.0.254).

IMPLANTACIÓN 45

De esta manera, cuando pinchemos los terminales IP en la LAN remota y pidan dirección DHCP se les concederá una, además de la ip del CCM donde se asociarán como un teléfono más sin ningún problema. En el CCM les asociaremos el Device Pool correspondiente a las delegaciones remotas, que tendrá configurado el codec G.729 como codificación de voz. De esta forma realizamos un mejor aprovechamiento del ancho de banda que, para los enlaces WAN, es más limitado que en un entorno LAN. A las delegaciones remotas tan solo les permitiremos que llamen a los internos de la central y a otras delegaciones, restringiéndoles el acceso a llamadas nacionales, móviles e internacionales. Esto lo hacemos así para diferenciar a nivel de facturación, ya que sino las llamadas que cursen las delegaciones se facturarían por las líneas de la central y no estarían controladas ni diferenciadas. Una vez esté todo configurado, realizaremos las pruebas pertinentes de llamadas desde las delegaciones hacía la central y viceversa.

7. VALIDACIÓN En este capítulo posterior a la fase de implantación validaremos la solución. Para ello analizaremos como se comporta el sistema ante posibles fallos que puedan ocurrir mientras se encuentra en producción. También elaboraremos un plan de aceptación de la solución, en la que se certificará el funcionamiento operacional de ciertas tareas que el tarea debe ser capaz de llevar a cabo. Por último daremos una breve instrucción técnica al cliente de los cambios de dispositivos y de topología que ha habido en su red.

7.1. Funcionamiento ante fallos En la Tabla 9 podemos ver una tabla resumen de algunos posibles fallos del sistema así como el análisis del comportamiento de los distintos elementos que intervienen en él. En algunos campos están explícitamente indicados los casos en los que existe algún problema. Damos por sobreentendido que el resto de funcionalidades no nombradas funcionan correctamente. La descripción de los campos de la Tabla 9 es la siguiente:

• Fallo: detallamos el elemento del sistema del que analizamos el fallo.


• ToIP Central 1 y 2: estado de los terminales IP del edificio de Central 1

y 2. Podemos tenerlos funcionando correctamente, asociados por SRST contra un Gateway, enrutándose por HSRP hacia el otro Gateway o solo asociados con el CCM por falta de Gateways.

• Llamadas Salientes: llamadas que realizan los terminales IP hacia la

PSTN o destinos móviles.

• Llamadas Entrantes: posibilidad de un usuario externo de realizar llamadas a los números asociados a las líneas RDSI o móviles, entre ellos el número de cabecera de la empresa.

• Llamadas Internas: llamadas entre internos, ya sean del mismo edificio

o no.

Fallo ToIP Central 1

ToIP Central 2

Llamadas Salientes

Llamadas Entrantes

Llamadas Internas

CCM SRST a GW

Central 1 SRST a GW

Central 1 OK OK OK

Enlace entre edificios

SRST a GW Central 1 OK OK OK

Entre edificios

no, desvío nº cabecera

CCM y

Enlace entre edificios

SRST a GW Central 1 NO Central 2

NO Central 2 NO Entre

edificios no

GW Central

1 HSRP a GW

Central 2 OK OK Líneas GW Central 1 NO OK

GW Central

2 OK HSRP a GW Central 1 OK Líneas GW

Central 2 NO OK

Ambos GWs Solo con CCM Solo con CCM NO NO OK

Tabla 9 Comportamiento ante fallos del sistema

7.2. Plan de aceptación Hemos elaborado un plan de aceptación para el sistema de telefonía IP. Consiste en una serie test que certifican ciertas funcionalidades con las que debe cumplir el sistema. Las pruebas de las que consta este plan son las siguientes:

VALIDACIÓN 47

1. CallManager Basic test. 2. Basic CallManager phone test. 3. Calls via local Gateway test. 4. Software conferencing. 5. Call routing test. 6. SRST test. 7. Other redundancy test.

El detalle y resultado de los test se describe en el ANEXO C. PLANTILLA DEL PLAN DE ACEPTACIÓN.

7.3. Instrucción técnica al cliente Finalizada todas las fases anteriores decidimos reunirnos con los representantes técnicos del cliente y darle una pequeña formación técnica sobre los cambios que ha habido en su red. El cliente llevaba varios años trabajando con una centralita analógica y, gracias a la experiencia, había adquirido el conocimiento suficiente como para realizar unos diagnósticos rápidos de primera necesidad, permitiéndole disponer de una dependencia menor del soporte técnico externo. Por estas razones organizamos una visita conjunta para ver los nuevos equipos, presentárselos al cliente y que conociera como son físicamente así como que observara los cambios que hay respecto a los dispositivos anteriores. Un detalle a señalar es que el cliente nos pedió saber como se reseteaban físicamente los equipos o, en su defecto, saber donde estaba el interruptor de “on/off”. Después de esta visita, lo supo. .


8. ANÁLISIS DE RENTABILIDAD Hemos elaborado un breve análisis de rentabilidad del proyecto realizado, siguiendo el modelo de costes-volúmen-beneficio que nos permite conocer para un período determinado el punto muerto del proyecto. Este punto muerto nos determina cuando obtendremos ni pérdidas ni beneficios, es decir, cuando amortizaremos el coste del proyecto. Todos los factores que tendremos en cuenta a la hora de calcular los distintos términos son los que afectan más directamente al proyecto, descartando los términos más indirectos que complican mucho el proceso de cálculo y afectan en pequeña proporción en comparación con el resto. Hemos calculado los ingresos referidos a este proyecto como el precio final que el cliente paga más el coste que le supone al cliente el mantenimiento de la instalación (servicio 24x7, mantenimiento de equipos, etc). Para calcular los costes hemos tenido en cuenta el precio de distribuidor de todo el material empleado en la instalación y el coste de mano de obra de los técnicos, además del coste que le supone a la empresa proporcionar el servicio de mantenimiento de la instalación. En la Fig. 19 observamos los resultados y vemos como durante los tres primeros meses tenémos pérdidas por el desembolso inicial no amortizado. En Febrero de 2008 se termina el proyecto y el cliente paga por su finalización y en este período donde tenemos el punto muerto del proyecto, pasando de pérdidas a beneficios, que irán en aumento sin volver a caer en pérdidas gracias a que los costes de mantenimiento son inferiores a los ingresos que obtenemos por ellos.

-10000

0

10000

20000

30000

40000

50000

60000

nov-07

dic-07

ene-08

feb-08

mar-08

abr-08

may-08

jun-08

jul-08

ago-08

sep-08

oct-08

nov-08

dic-08

ene-09

feb-09

mar-09

abr-09

may-09

Meses

€uro

s

Costes Ingresos Beneficios

Punto Muerto

Fig. 19 Gráfica de los Costes, Ingresos, Beneficios y Punto Muerto del proyecto

BIBLIOGRAFIA 49

CONCLUSIONES Este proyecto ha tratado el estudio de las necesidades que han motivado a un cliente a migrar sus sistemas de telefonía tradicionales analógicos hacia una convergencia entre la nueva red de telefonía IP y su red de datos actual. Hemos presentado una solución que ha cumplido con los requerimientos demandados por el cliente y que, además, hemos implementado y validado de acuerdo a una planificación técnica que ha cumplido con las expectativas generadas. Personalmente este proyecto me ha complementado bastante en las distintas áreas en las que he tenido que trabajar, ya que me ha dado una visión mucho más amplia y global de lo que significa un proyecto de ingeniería de estas dimensiones. He tenido la oportunidad de conocer y trabajar con distintas herramientas hasta ahora desconocidas que me han facilitado mucho la tarea de recopilar, organizar y ordenar toda la información disponible, así como gestionar el tiempo de una manera eficaz. A nivel técnico, como posible línea de trabajo para el futuro, se puede mejorar el enrutamiento entre redes que realizan los routers, ya que se utilizan rutas estáticas. Se podría implementar un protocolo de enrutamiento dinámico que otorgue a la red de mayor flexibilidad a la hora de convergencia en enrutamiento. También se podría realizar un estudio de los elementos únicos de fallo e intentar proponer una arquitectura de failover que nos proporcione redundancia ante posibles fallos. Algunos puntos a estudiar serían la posibilidad de poner un cluster de CallManagers, redundar el enlace entre los edificios de la central, etc.


BIBLIOGRAFÍA

[1] Documentación Nexica: Archivos históricos del cliente en la empresa.

[2] Software utilizado:

http://office.microsoft.com/es-hn/visio/default.aspx http://ganttproject.biz/ http://freemind.sourceforge.net/wiki/index.php/Main_Page

[3] Documentación de Cisco sobre VoIP: http://www.cisco.com/warp/public/788/voip/in_dial_peer_match.html http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010ae1c.shtml http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080147524.shtml http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010e6d1.shtml http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a00801142f8.shtml http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a00800b6710.shtml

[4] Aplicaciones StoneVoice: http://www.stonevoice.com/

[5] Configuración de RADIUS en Gateways:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_programming_reference_guide09186a00800b5e17.html#wp1057687

[6] HSRP:

http://www.cisco.com/en/US/docs/internetworking/case/studies/cs009.html

[7] QoS: http://www.cisco.com/en/US/tech/tk543/tk759/technologies_white_paper09186a00801348bc.shtml http://www.cisco.com/en/US/docs/ios/solutions_docs/qos_solutions/QoSVoIP/QoSVoIP.html

[8] Instalación de Hardware en Cisco Router 2800:

http://www.cisco.com/en/US/docs/routers/access/2800/hardware/installation/guide/hw.html

[9] Conexión de módulos de expansión Voice Network Modules: http://www.cisco.com/en/US/docs/routers/access/interfaces/nm/hardware/installation/guide/Conntvoi.html

[10] Packet Voice Digital Signal Processor Module: http://www.cisco.com/en/US/prod/collateral/routers/ps5854/product_data_sheet0900aecd8016e845_ps3115_Products_Data_Sheet.html

[11] Vlan Trunking: http://www.ciscopress.com/articles/article.asp?p=29803&seqNum=3

http://office.microsoft.com/es-hn/visio/default.aspx

http://ganttproject.biz/

http://freemind.sourceforge.net/wiki/index.php/Main_Page

http://www.cisco.com/warp/public/788/voip/in_dial_peer_match.html

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010ae1c.shtml

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010ae1c.shtml

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080147524.shtml

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080147524.shtml

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010e6d1.shtml

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010e6d1.shtml

http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a00801142f8.shtml

http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a00801142f8.shtml

http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a00800b6710.shtml

http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a00800b6710.shtml

http://www.stonevoice.com/



http://www.cisco.com/en/US/docs/internetworking/case/studies/cs009.html

http://www.cisco.com/en/US/tech/tk543/tk759/technologies_white_paper09186a00801348bc.shtml

http://www.cisco.com/en/US/tech/tk543/tk759/technologies_white_paper09186a00801348bc.shtml

http://www.cisco.com/en/US/docs/ios/solutions_docs/qos_solutions/QoSVoIP/QoSVoIP.html

http://www.cisco.com/en/US/docs/ios/solutions_docs/qos_solutions/QoSVoIP/QoSVoIP.html



http://www.cisco.com/en/US/docs/routers/access/interfaces/nm/hardware/installation/guide/Conntvoi.html

http://www.cisco.com/en/US/docs/routers/access/interfaces/nm/hardware/installation/guide/Conntvoi.html

http://www.cisco.com/en/US/prod/collateral/routers/ps5854/product_data_sheet0900aecd8016e845_ps3115_Products_Data_Sheet.html

http://www.cisco.com/en/US/prod/collateral/routers/ps5854/product_data_sheet0900aecd8016e845_ps3115_Products_Data_Sheet.html

http://www.ciscopress.com/articles/article.asp?p=29803&seqNum=3

BIBLIOGRAFIA 51

[12] Cisco Unified CallManager Version 4.3: http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps556/ps7042/product_data_sheet0900aecd805e321f.html

[13] Cisco MCS 7815-I2:

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/ps5748/ps378/product_data_sheet0900aecd80456604.html

[14] VMware Server:

http://www.vmware.com/products/server/

[15] Foros: http://www.voipforo.com

[16] Codecs:

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml http://www.voip-info.org/wiki-Codecs

[17] Rentabilidad empresarial:

Joaquim-Andreu Monzón Graupera, Tècniques d’anàlisi de la rendibilitat empresarial, FUOC, 2005.

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps556/ps7042/product_data_sheet0900aecd805e321f.html

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/vcallcon/ps556/ps7042/product_data_sheet0900aecd805e321f.html



http://www.vmware.com/products/server/

http://www.voipforo.com/

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml

http://www.voip-info.org/wiki-Codecs


ANEXO A. CONFIGURACIÓN DEL CISCO CALLMANAGER

Comenzaremos nuestra configuración del CCM configurando el acceso remoto por Terminal Service. De esta no será necesario que estemos en las instalaciones del cliente para realizar la gran mayoría de configuraciones. Para acceder a configurar todos los parámetros del CCM deberemos entrar por la siguiente url: https://10.0.0.254/ccmadmin e introducir el usuario y contraseña que nos solicita, que coincide con el de administrador local de la máquina. Comenzaremos configurando los servidores. En nuestro caso solo tenemos un CCM y será el que configuraremos con su dirección IP (10.0.0.254) y su MAC.

Fig. 20 Configuración de los Servidores

Configuraremos dos regiones distintas: Default y Delegaciones_Remotas. En la primera especificaremos el codec G.711 y en la segunda G.729. Con esto optimizaremos el uso de ancho de banda, según hemos hablado en el apartado 5.1.3 Calidad de servicio.

Fig. 21 Configuración de las regiones

El horario lo configuraremos según la opción Date/Time Group donde le diremos como queremos que se represente la hora en los terminales. Configuraremos recursos adicionales de hardware y software para poder utilizarlos a la hora de gestionar la carga de trabajo. Primero definiremos los recursos Conference Bridge y Transcoder, con los mismos parámetros que configuramos en los routers, como explicamos en el apartado 6.3.4.

ANEXO A. CONFIGURACIÓN DEL CISCO CALLMANAGER 53

Fig. 22 Definición de grupos de Conference Bridge y Transcoder

Ahora crearemos el grupo de Media Resources Hardware, en el que incluiremos los recursos creados.

Fig. 23 Grupo de Media Resource Hardware

También definiremos el grupo Media Resource Software con los recursos del propio CCM.

Fig. 24 Grupo de Media Resource Software

Y solo nos falta crear un Media Resource List en el que incluiremos los dos grupos anteriores.


Fig. 25 Definición del Media Resource List

En la configuración del servidor Music on Hold que es la música en espera que escucharemos, tan solo agregaremos a nuestro CCM como servidor especificando su dirección IP. Luego podremos añadir los Audio Source que queramos para personalizar nuestra música en espera. Definiremos una Location para la LAN, donde podemos limitar el ancho de banda que utilizarán nuestras aplicaciones de video y audio.

Fig. 26 Definición de Location de LAN

Configuraremos tres gateways: uno por cada router 2821 de cada sede y el tercero será la ip de la máquina virtual donde tenemos el software de StoneVoice.

Fig. 27 Configuración de Gateways

También añadiremos los dos routers 2821 como referencia SRST.

Fig. 28 Configuración de referencias SRST


Ahora añadiremos dos Device Pool en donde agruparemos todas los parámetros que hemos ido configurando para asociárselo luego a los dispositivos de cada sede independientemente.

Fig. 29 Configuración de Device Pool por sede

Generaremos las particiones que dividiremos en según las sedes y donde tendremos los siguientes grupos:

• Internos. • Nacionales. • Móviles. • Internacionales. • Servicios. • Común, que será la única que compartirán ambas sedes.

Para agrupar estas particiones crearemos los Calling Search Spaces, en donde definiremos principalmente tres grupos, también por cada sede:

• CSS Internacional: agrupa a las particiones internacionales, móviles, nacionales e internos, servicios de su sede más común e internos de la otra sede.

• CSS Móviles: igual que la anterior pero sin internacionales. • CSS Internos: agrupa a los internos de las dos sedes más servicios y

común.


Ahora definiremos los Route Group, uno por cada sede en los que incluiremos los gateways, comenzando por el que corresponda a su sede que será el que tenga preferencia y si este fallara probaría con el siguiente.

Fig. 30 Definición de Route Groups con gateways ordenados por preferencia

Ahora asociaremos estos Route Group con un Route List cada uno.


Fig. 31 Definición de Route List por sede

A continuación definiremos los Route Patterns donde asociaremos el plan de numeración a los Route List definidos anteriormente para controlar quién puede llamar a qué destinos. Dentro de esta lista existen algunos caracteres especiales, entre los cuales están los siguientes:

• ‘X’ que machea con cualquier digito del 0 al 9. • ‘!’ que machea con una cadena de dígitos del 0 al 9, sin restricción de

cantidad, y terminara de acuerdo al timeout interdigit (parámetro configurable en el campo t_302 del menú Service Parameter).

• ‘[‘ y ‘]’ que junto a ‘-‘ los utilizamos para determinar una posible lista de

valores permitidos en la posición en la que se encuentra.


• ‘.’ que lo utilizamos para separar el código que nos da acceso al exterior y lo podríamos utilizar para descartarlo por si nuestro Gateway no lo supiera enrutar.

Fig. 32 Definición del dial-plan asociado a los Route List por sede

Para permitir la marcación rápida a los números de móviles, configuraremos los Translation Patterns en donde asociaremos la extensión corta con el número de móvil que queramos. El cliente nos ha facilitado una lista con 233 números y en la Fig. 33 vemos una muestra de esta lista con los números de móvil modificados para proteger su privacidad.

Fig. 33 Detalle de los números cortos a móviles en los Translation Patterns


Para definir un grupo de salto sobre un determinado número, configuraremos un Line Group con los números internos en el orden en que queramos que vaya sonando el número. En el nombre del Line group y demás grupos hemos borrado las cuatro últimas cifras del número externo hasta el guión.

Fig. 34 Configuración de un Line Group

Ahora asociaremos este Line Group a un Hunt List.

Fig. 35 Asociación del Line Group al Hunt List

Y por último definiremos un Hunt Pilot, asociándolo al Hunt List, en el que especificaremos mediante qué número virtual podremos llamar al grupo de extensiones internas indicadas en el Line Group.

Fig. 36 Definición del Hunt Pilot

A este número virtual será al que asociemos el número externo en el Gateway mediante un num-exp, según explicamos en el apartado 6.3.4 números directos. Deberemos añadir a los usuarios en la base de datos. Para crear un usuario solo deberemos especificar su nombre, apellidos y extensión. Luego asociaremos su dispositivo físico a su usuario, de manera que podrá realizar modificaciones sobre su terminal si accede a la siguiente url y se autentifica: https://10.0.0.254/ccmuser. Introducir la información de los usuarios con la extensión correctamente es de vital importancia, ya que esta será la que se visualizará en el directorio corporativo de los teléfonos. Para que el CCM comience a dar servicio, deberemos activar los servicios imprescindibles para ello. En la Fig. 37 podemos ver como los hemos activado dentro del Cisco Unified CallManager Serviceability – Control Center.


Fig. 37 Activación de los servicios del CCM

Por último configuraremos los backups mediante la utilidad BARS, a la que entraremos por la url: http://10.0.0.254/BARS/BARSschedule.asp, y autenticándonos con las mismas credenciales que para entrar al CCM. Añadiremos el Server del que queremos hacer las copias de seguridad, así como la ubicación donde queremos que se realicen dichas copias. En nuestro caso hemos configurado una carpeta compartida en uno de los servidores de la red, ya que en este servidor existen políticas de copias de seguridad en la que incluiremos los datos de nuestro CCM.

Fig. 38 Copias de seguridad del CCM en servidor externo

ANEXO B. CONFIGURACIÓN DEL STONEVOICE 61

ANEXO B. CONFIGURACIÓN DEL STONEVOICE Comenzaremos la configuración del StoneVoice instalando el VMware como servicio. Configuraremos una opción para que cuando el host donde está instalado se apague, el VMware apague de forma correcta la máquina virtual y no perdamos datos. De igual manera podemos decirle que cuando se arranque el host, se arranque el VMware e inicie la imagen de nuestra máquina virtual. De este modo volveremos a tener siempre disponible nuestro servidor virtual, independientemente de si la máquina física se reinicia o no.

Fig. 39 Opciones de configuración en el VMware Server para el arranque de la

máquina virtual Instalaremos el servidor RADIUS IAS (de Microsoft) en la misma máquina virtual del StoneVoice para recoger los datos de accounting que nos proporcionará el gateway. En la Fig. 40 podemos apreciar el servidor IAS con el GW de la Central 1 configurado, la carpeta donde guarda los archivos .log, y uno de esos archivos abiertos donde vemos como guarda los datos separados por comas.


Fig. 40 Servidor RADIUS IAS con ficheros de log de detalle de llamadas

A continuación configuraremos las aplicaciones de StoneVoice y para ello entraremos mediante la url http://10.0.0.252/fw/frame/login.asp y añadiremos a los usuarios en la base de datos. Por cada usuario añadiremos su nombre, apellidos, extensión y número del buzón de voz.

Fig. 41 Añadimos los usuarios a la base de datos de StoneVoice

Si entramos a gestionar el SSAM podremos iniciar o detener el servicio, modificar el mensaje de bienvenida al buzón de voz, etc.


Fig. 42 Interfaz para gestionar el SSAM

Para la gestión del IVR comenzaremos añadiendo a nuestros dos gateways. Introduciremos su IP y el usuario de Telnet que crearemos a la aplicación dentro del Gateway.

Fig. 43 Configuración de gateways en el IVR

Subiremos a la aplicación el archivo de audio que queramos utilizar en nuestra aplicación IVR como mensaje de bienvenida y de espera en cola. A continuación asociaremos un script de los que dispone el sistema con cada entrada de IVR. Este script es el que definirá las distintas opciones posibles o menús que oiremos cuando actúe el IVR. Aquí configuraremos el número de centralita al que saltarán las llamadas, el tiempo de espera así como los mensajes de bienvenida y de espera en cola.


Fig. 44 Configuración de script asociado a instancia IVR

Una vez todo listo, se habrán añadido unas sentencias en nuestros dos gateways bajo el comando application, en donde se detallan los datos y parámetros necesarios para que funcione la conexión con el IVR. También deberemos añadir en el dial-peer que machee las entradas el comando service script2 que será el que llame a los parámetros que están configurados bajo el comando application. En nuestro caso, para diferenciar a los números que pasarán por el IVR hacia la centralita de los números directos, hemos configurado en los gateways los números que van hacia el IVR con un num-exp hacia un número virtual (6900). Hemos creado el dial-peer 40 de voip que recoge el número virtual y tiene el comando service script2. Esto hará que salte el IVR, presentará el mensaje de bienvenida y conectará con la extensión de la operadora configurada. Para configurar el Billy deberemos configurar el usuario de la base de datos del CCM para que pueda realizar consultas SQL contra su base de datos.

Fig. 45 Configuración del usuario de la BBDD SQL para el Billy


Una vez se produzca la conexión con la base de datos, podremos definir las tarifas de las llamadas, definir los grupos para distinguir entre llamadas internacionales, nacionales y móviles, etc. Particularmente no hemos conseguido terminar de levantar la interfaz del Billy por problemas de acceso a la base de datos del CCM. Se dejará para futuras mejoras el resincronizar el Billy para que se integre correctamente con el SQL del CCM. Para realizar los backups, el StoneVoice dispone de una aplicación no muy elaborada que te permite realizar las copias de seguridad.

Fig. 46 Aplicación de backups en el StoneVoice

Utilizaremos el programador de tareas para programar las copias de seguridad en un recurso compartido de algún servidor externo, de forma que las copias no se queden en la máquina virtual.


ANEXO C. PLANTILLA DEL PLAN DE ACEPTACIÓN CallManager basic tests - Preliminary Introduction

The tests detailed below in this section should be considered mandatory. These procedures will ensure that the Acceptance Test Plan will be started correctly and that any specifics are completed.

Event Viewer

This should be checked to make sure there are no services not starting correctly, any anomalies etc.

Test Results Publisher

ok

Pass

Fail

ANEXO C. PLANTILLA DEL PLAN DE ACEPTACIÓN 67

Call Manager/Unity Ping test Basic IP connectivity should be checked before starting on the main tests. If the below tests fail then it shows there is an IP routing issues that needs to be clarified before proceeding.

From To CCM Default Gateway Pass

Fail


Basic CallManager Phone Tests Introduction

The tests below cover the basic requirements for phones and end users.

Test 1: Basic IP Phone Test/IP Phone User Web access OBJECTIVE To ensure that the phones have registered correctly WHERE The phones should be local, i.e. on the same site and not across a WAN link PROCEDURE Use the Configuration checklist in the document referred below EXPECTED RESULTS The phone should have the ip addresses as detailed in the Low Level Design Test Category

General IP Phone Test

Test Devices

IP Phones

Expected Results

Verify the network configuration and IP Phone load.

Step Device Procedure Remarks Check

Step 1. IP Phone

Press the “Settings” button. Settings screen displays on the LCD.

OK


Step 2. IP Phone

Select Network Configuration (option 3). Use the scroll button to highlight the option you want, then press the Select button.

OK

Step 3. IP Phone

Check the DHCP Server IP address. Verify the IP address. OK

Step 4. IP Phone

Scroll down to check the IP address. Verify that the IP address is in the VLAN.

OK

Step 5. IP Phone

Scroll down to check the TFTP Server IP address.

Verify it is the CCM IP address.

OK

Step 6. IP Phone

Scroll down to check the CallManager 1 IP address.

Verify it is the CCM IP address.

OK

Step 7. IP Phone

Scroll down to check the SRST IP address. Verify it is the SRST IP address.

OK

Step 8. IP Phone

Press the Cancel button. Returns you to previous screen.

OK

Step 9. IP Phone

Select Status (option 4), then Firmware Versions (option 3).

Verify the Boot Load ID. OK

Step 10. IP Phone

Press the Exit button three times to return to idle state.

Verify the DN is displayed.

OK

Step 11. IP Phone

Go to http://<CallManagerServerName>/cmuser/logon.asp

Log in to access the IP Phone user settings.

OK

Step 12. IP Phone

Follow the instructions on the web page to program a speed dial button.

Verify that the new speed dial number displays on the IP Phone.

OK

Step 13. IP Phone

Take the phone off hook. Verify there is a dial tone.

OK

Step 14. IP Phone

Hang up the phone. IP Phone is idle. OK

Test Results OK Pass

Fail


Test 2: Phone-to-phone Dial-up Test on LAN IP/IP OBJECTIVE To ensure that local phones to phone calls can be made, i.e. on the same LAN WHERE The phones should be local, i.e. on the same site and not across a WAN link PROCEDURE Use the Configuration checklist in the document referred below EXPECTED RESULTS

Use the remarks checklist in the document referred below

Test Category Campus Call Processing

Test Devices IP Phones, CallManager, Catalyst Switches, Access Routers

Expected Results

Phone call can be made by any two phones on the LAN.


Step 15. All devices Record all IP Phone DN numbers in the diagram above.

OK

Step 16. IP Phones Verify that all IP Phones have power and display.

Check IP Phone display. OK

Step 17. IP Phone A Take Phone A off hook. Verify there is a dial tone. OK

Step 18. IP Phone A Dial the DN number of Phone B. Phone B rings. OK

Step 19. IP Phone B Answer the call, verify that the conversation can take place.

Phones A and B are connected.

OK

Step 20. IP Phones Hang up both Phones A and B. Phones A and B are idle. OK

Step 21. IP Phone B Take Phone B off hook. Verify there is a dial tone. OK

Step 22. IP Phone B Dial the DN number of Phone A. Phone A rings. OK

Step 23. IP Phone A Answer the call, verify that the conversation can take place.


OK


118 112



Fail

Test 3: Call Transfer to another IP phone locally OBJECTIVE To ensure that call transfers can be made between local phones, i.e. on the same LAN WHERE The phones should be local, i.e. on the same site and not across a WAN link PROCEDURE Use the Configuration checklist in the document referred below EXPECTED RESULTS Use the remarks checklist in the document referred below

Test Category Campus Call Processing

Test Devices IP Phones, CallManager, Catalyst Switch

Expected Results

Phone call can be made by any two phones on the LAN.



OK

Step 2. IP Phones Verify that all IP Phones have power. Check IP Phone display. OK



Step 5. IP Phone B Answer the call. Phones A and B are connected.

OK

Step 6. IP Phone B Press the Trnsfer button and dial the DN number of Phone C.

Phone C rings. OK

Step 7. IP Phone C Answer the call. Phones B and C are connected.

OK

Step 8. IP Phone B Press the Trnsfer button again to transfer the call, then hang up.

Phone B is idle. OK

118

112

111


Step 9. IP Phone A Begin conversation with Phone C. Phones A and C are connected.

OK

Step 10. IP Phones Hang up both Phones A and C. Phones A and C are idle. OK


Fail


Test 4: Call Forward to another IP phone locally OBJECTIVE To ensure that call forward can be made between local phones, i.e. on the same LAN WHERE The phones should be local, i.e. on the same site and not across a WAN link PROCEDURE Use the Configuration checklist in the document referred below EXPECTED RESULTS Use the remarks checklist in the document referred below Test Category Campus Call Processing


Expected Results

All calls for IP Phone A are forwarded (ring) to IP Phone B



OK



Step 4. IP Phone A Press the CFwdAll button. Listen for two short beeps. OK

Step 5. IP Phone A Dial the DN number of Phone B, then hang up.

Phones A is idle. OK

Step 6. IP Phone C Take Phone C off hook. Verify there is a dial tone. OK

Step 7. IP Phone C Dial the DN number of Phone A. Phones B rings. OK

Step 8. IP Phone B Answer the call. Phones B and C are connected.

OK

Step 9. IP Phones Hang up both Phones B and C. Phones B and C are idle. OK


Fail

118

112

111


Test 5: Call On-hold and Retrieve Test OBJECTIVE To ensure that the phones can be put on-hold and calls can be retrieved. WHERE The phones should be local, i.e. on the same site and not across a WAN link PROCEDURE Use the Configuration checklist in the document referred below EXPECTED RESULTS Use the remarks checklist in the document referred below Test Category General IP Phone Test


Expected Results

Calls can be put on hold and later retrieved.


Step 1. All devices Record both IP Phone numbers in the diagram above.

OK

Step 2. IP Phones Verify that both IP Phones have power.

Check IP Phone display OK

Step 3. IP Phone A Take Phone A off hook. Verify that there is a dial tone. OK


Step 5. IP Phone B Pick up Phone B to establish connection.


OK

Step 6. IP Phone A Press the Hold button on Phone A. “Hold” displays on the screen. OK

Step 7. IP Phone B Verify the call is on hold. Listen for three short beeps. OK

Step 8. IP Phone A Press the Resume button on Phone A.

“Connected” displays on the screen.

OK

Step 9. IP Phones Resume conversation. Phones A and B are connected.

OK

Step 10. IP Phone B Press the Hold button on Phone B. “Hold” displays on the screen. OK

Step 11. IP Phone A Verify the call is on hold. Listen for three short beeps. OK

Step 12. IP Phone B Press the Resume button on Phone B.

“Connected” displays on the screen.

OK

Step 13. IP Phones Resume conversation. Phones A and B are OK

118 112


connected.

Step 14. IP Phones Hang up both Phones A and B. Phones A and B are idle OK


Fail


Test 6: Call Waiting Test OBJECTIVE To ensure call waiting is possible on the phone, i.e. the ability for two simultaneous calls to be received by the phone WHERE The phones should be local, i.e. on the same site and not across a WAN link PROCEDURE Use the Configuration checklist in the document referred below EXPECTED RESULTS Use the remarks checklist in the document referred below

Test Category General IP Phone Test


Expected Results

Users can alternate between listening to two different incoming calls.



OK




Step 5. IP Phone B Take Phone B off hook. Phones A and B are connected.

OK

Step 6. IP Phone C Take Phone C off hook. Verify there is a dial tone. OK

Step 7. IP Phone C Dial the DN number of Phone B. Phone B flashes with the new call.

OK

Step 8. IP Phone B Press the Answer button to answer second call.

Phones B and C are connected.

OK

Step 9. IP Phone B Press the up-arrow key and press the Resume button to return to the Phone A call.


OK

118

112

111


Step 10. IP Phone B Press the Hold button and switch to the Phone C call.

Phones B and C are connected.

OK

Step 11. IP Phones Hang up all three phones. Phones A, B, and C are idle. OK


Fail


Speed Dial Test For a specific phone or number of phones the speed dial key should be tested to make sure it is configured and working


Fail

Fast dials Test For a specific phone or number of phones the Fast Dials should be tested to make sure it is configured and working. Tests should be carried out to add/delete users via the phone and web page


Fail

Directory Search

For a specific phone or number of phones the Directory Key should be tested to make sure it is configured and working. Tests should be carried out to search for users.


Fail


Receptionist/Operator Console Test – 7914 Module OBJECTIVE To check that the local operator/receptionist can make and receive calls via the phone and pc based application WHERE The phones should be local. Calls from PSTN and locally should be tried PROCEDURE Use the Configuration checklist in the document referred below EXPECTED RESULTS Use the remarks checklist in the document referred below Test Category Advanced functionality


Expected Results

7914 expansion module is working properly

Phone A: 111 Phone B: 118


Step 1. IP Phone A Take Phone off hook & dial phone B extension

Phone B rings. OK

Step 2. IP Phone B Answer the call Phones are connected OK

Step 3. IP phone A Pickup another line & dial phone C extension

Phone C rings OK

Step 4. IP Phone C Answer the call Phones are connected OK

Step 5. IP phone A Repeat steps 1 & 2 with other lines buttons

Verify that 3 lines are available OK

Step 6. PC Log into ccmuser page as phone A user & configure a SpeedDial associated to one of the expansion module unused buttons.

Verify that when pressing the configured SpeedDial button, that he correponding DN is being dialed.

OK


Fail


Calls Via Local Gateway Tests Test 1: Calls to the PSTN via local gateway OBJECTIVE To check that calls can be made via the local PSTN gateway to the PSTN WHERE One phone should be local and one phone should be on the PSTN PROCEDURE Use the Configuration checklist in the document referred below Phone A is an IP phone Phone B is an Analogue Phone (where applicable) EXPECTED RESULTS Calls should be possible to the PSTN (assuming no Class of service restrictions are in place) Test Category General IP Phone Test


Expected Results

Calls via local PSTN gateway



OK



Step 4. IP Phone A Dial the DN number of Phone C. Phones C rings. OK

Step 5. IP Phone B Answer the call. Phones A and C are connected.

OK

Step 6. IP Phones Hang up Phones A and C. Phones A and C are idle. OK

111 112 902202223


Test Results IP Phone

OK Pass

Fail

Test Results Analogue Phone

OK Pass

Fail


Test 2: Call Transfer to a PSTN Phone via local gateway OBJECTIVE To check that calls can be transferred from an IP phone to the PSTN phones WHERE One phone should be local and one phone should be on the PSTN PROCEDURE Use the Configuration checklist in the document referred below EXPECTED RESULTS Use the remarks checklist in the document referred below



Expected Results

A call from Phone A to Phone B can be transferred to an off-net Phone C.



OK



Step 4. IP Phone A Dial the DN number of Phone B. Phones B rings. OK

Step 5. IP Phone B Answer the call. Phones A and B are connected.

OK

Step 6. IP Phone B Press the Transfer button and dial the DN number of Phone C.

Phone C rings. OK

Step 7. IP Phone C Answer the call. All three phones are connected.

OK

Step 8. IP Phone B Press the Transfer button again to transfer the call to Phone A, then

Phone B is idle. OK

112 111 902202223


hang up Phone B.

Step 9. IP Phones Phones A and C begin conversation. Phones A and C are connected.

OK

Step 10. IP Phones Hang up Phones A and C. Phones A and C are idle. OK


Fail


Test 3: Call Forward to a Phone via local gateway OBJECTIVE To check that calls can be forwarded from an IP phone to the PSTN phone via a local gateway WHERE One phone should be local and one phone should be on the PSTN PROCEDURE Use the Configuration checklist in the document referred below EXPECTED RESULTS Use the remarks checklist in the document referred below



Expected Results

All calls to Phone A can be forwarded to an off-net Phone C.



OK



Step 4. IP Phone A Press the CFwdAll button. Listen for two short beeps. OK

Step 5. IP Phone A Dial the DN number of Phone C, then hang up Phone A.

Phones A is idle. OK


Step 7. IP Phone B Dial the DN number of Phone A. Phone C rings. OK

Step 8. IP Phone C Answer the call. Phones B and C are connected.

OK

Step 9. IP Phones Hang up Phones B and C. Phones B and C are idle. OK

112 111 902202223



Fail


Software Conferencing Test 1: Four-party Conference Call local OBJECTIVE To ensure that Four party Ad-hoc conferencing between local phones works, i.e. on the same LAN. The CallManager should be local to the phones and the conference bridge will use the G711 codec WHERE The phones should be local, i.e. on the same site and not across a WAN link PROCEDURE Use the Configuration checklist in the document referred below EXPECTED RESULTS


Test Category Advanced IP Telephony Test


Expected Results Phone A can initiate a four-party conference call, adding one party at a time to the call.


Step 1. IP Phones Record all IP Phone DN numbers in the diagram above.

OK




Step 5. IP Phone B Answer the call. Phones A and B are connected. OK

Step 6. IP Phone A Press the Hold button, then the NewCall button.

Phone B is on hold. OK

Step 7. IP Phone A Dial the DN number of Phone C. Phone C rings. OK

Step 8. IP Phone C Answer the call. Phones A and C are connected. OK

Step 9. IP Phone A Press the Hold button, then the NewCall button.

Phones B and C are on hold. OK

112

118111

151


Step 10. IP Phone A Dial the DN number of Phone D. Phone D rings. OK

Step 11. IP Phone D Answer the call. Phones A and D are connected. OK

Step 12. IP Phone A Press the More button then the Confrn button to conference all parties.

Conference number displays; Phones A, B, C, and D are connected.

OK

Step 13. IP Phones Hang up Phones A, B, C, and D. Phones A, B, C, and D are idle. OK


Fail


Test 2: Phone-to-phone Dial-up Test over MAN OBJECTIVE To ensure that calls between remote sites work, i.e. Voicemail over the MAN WHERE The phones will be located across a MAN link PROCEDURE Use the Configuration checklist in the document referred below EXPECTED RESULTS


Test Category Centralized Call Processing


Expected Results

Both Phones A and B can dial and communicate with each other over the WAN.


Step 1. scvd

All devices Record site names, CallManager name, and IP Phone DN numbers in the diagram above.

OK




Step 5. IP Phone B Answer the call and begin conversation.


OK

Step 6. IP Phone A Check that G729 is being used Press “ii” button OK



Step 9. IP Phone A Dial the DN number of Phone A. Phone A rings. OK

2200

Esplugues Madrid

CCM

112


Step 10. IP Phone A Answer the call and begin conversation.


OK



Fail


Call Routing Tests Introduction The tests below can be used to build customer specific tests as each customer will have a slightly different requirement. Short Code Dialing/Call Translation Patterns The customer may have a requirement for mapping short code dials to full numbers or translation patterns. The template below should be used to test this on a per site basis. Note: After translating the call the call may need to be routed on-net/off-net depending on certain criteria Number dialled Translated to Call Successful 3200 60718XXXX Pass

Fail 3201 68781XXXX Pass



Fail


SRST Tests Introduction The Cisco CallManager SRST software operates by taking advantage of the keep-alive packets emanating from both the centralized Cisco CallManager cluster and local Cisco IP phones. During normal operations, the Cisco CallManager receives keep-alive packets from the Cisco IP phones. Cisco CallManager performs call setup and processing, call maintenance, and call termination. The branch router is configured for SRST but has no awareness of the IP phones in normal mode. SRST Failover by Disconnecting MAN-Switch

OBJECTIVE To ensure IP Phones call processing by SRST router when communications fails to CCM WHERE This will involve to interrupt the communication between IP Phones and Callmanager Cluster PROCEDURE Validates SRST router call processing EXPECTED RESULTS



Test Devices IP Phones, CallManager, and Catalyst Switch, SRST router

Expected Results SRST router successfully perfoms call processing of IP Phones.


Step 1. IP Phones Verify that all IP Phones have power Check IP Phone display. OK

Step 2. MAN Switch Disconnect LAN Cable to stackable Switch.

This stopps communication with CCMs

OK

Step 3. All Devices Wait for phones to reconnect to SRST Router

Message appears in status line OK

Step 4. IP Phone Place call to other internal destination Verify communication OK

Step 5. IP Phone Place call to PSTN destination Verify communication OK

Step 6. IP Phone During Call press ‘Hold’ Verify MoH on PSTN phone OK

Step 7. IP Phone Place call to GSM destination Verify communication OK

Step 8. External Phone PSTN

Place call to IP Phone Verify communication OK

Step 9. External Phone PSTN

Place call to Attendant Phone Verify communication OK

Step 10. External Phone GSM

Place call to IP Phone Verify communication OK

Step 11. MAN Switch Reconnect Cable Check IP Phone display after phones have reconnected to CCM

OK



Fail Other Redundancy Tests TRAC Link Down on Primary Voice Gateway

OBJECTIVE To ensure IP Phones call processing continues when the TRAC link on the primary voice gateway 1 is down WHERE This will involve to interrupt the communication between IP Phones and primary voice gateway TRAC link PROCEDURE Validates TRAC link rerouting to PSTN link on the primary voice gateway EXPECTED RESULTS



Test Devices IP Phones, CallManager, and Catalyst Switch, Voice Gateway Routers

Expected Results TRAC call processing works properly


Step 1. IP Phones Verify that all IP Phones have power Check IP Phone display. OK

Step 2. Voice GW1 Shutdown TRAC link on primary voice gateway

OK

Step 3. IP Phone Place call to GSM destination Verify communication OK

Step 4. Voice GW1 Verify that call is routed through PSTN on primary voice gateway

Check on voice gateway 1 OK

Step 5. Voice GW1 Reestablish TRAC link connected to GSM Provider on primary voice gateway

OK

Step 6. Voice GW1 Make sure that GSM calls are routed through GSM TRAC link

Check on voice gateway 1 OK


Fail

Documents

Memoria. Protocolos Sccp