Académique Documents
Professionnel Documents
Culture Documents
TM
Advanced Services
Version 0.4
Cisco
Corporate Headquarters
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100
Contenido
Contenido........................................................................................................................................2
Figuras ............................................................................................................................................7
Tablas ..............................................................................................................................................8
Historia ......................................................................................................................................... 14
Historia .................................................................................................................................... 14
Revisiones .............................................................................................................................. 14
Servers .................................................................................................................................... 19
Gateways ................................................................................................................................ 21
Servicios ...................................................................................................................................... 28
DHCP ....................................................................................................................................... 28
TFTP ........................................................................................................................................ 28
DNS .......................................................................................................................................... 29
Time Zone ............................................................................................................................... 29
NTP .......................................................................................................................................... 29
LDAP Directory....................................................................................................................... 30
Workgroup / Domain .............................................................................................................. 30
Annunciator....................................................................................................................................... 47
Recursos de conferencias y transcoding ........................................................................... 47
Conferencias ..................................................................................................................................... 48
Transcoding....................................................................................................................................... 49
Media Termination Point .................................................................................................................. 50
Music on Hold (MoH) ............................................................................................................. 50
MoH Servers ..................................................................................................................................... 51
Audio Source .................................................................................................................................... 52
Sitios Remotos .................................................................................................................................. 52
MRG y MRGL .......................................................................................................................... 52
Media Resource Group ..................................................................................................................... 53
Media Resource Group List .............................................................................................................. 54
Call Park............................................................................................................................................ 77
Call Pickup ........................................................................................................................................ 77
Meet me ............................................................................................................................................ 78
Unity ............................................................................................................................................. 86
MLA.................................................................................................................................................. 99
Roles ................................................................................................................................................. 99
Privilegios de acceso del role ............................................................................................................ 99
User Groups .................................................................................................................................... 100
Table 33 Regiones 39
Table 35 SRST 41
Table 42 Annunciator 47
Table 47 MoH 51
Table 58 Particiones 64
Table 60 Gateways 71
Table 68 Meet Me 78
Historia
Version No. Issue Date Status Reason for Change
0.1 04 Sep 2011 Draft Release Inicial – Fase I
Revisiones
Reviewer’s Details Version No. Date
Audiencia
Este documento está destinado para ser utilizado por los ingenieros de Dimension Data y Collahuasi y
Cisco involucrados en la implementación y todas aquellas personas involucradas en el proyecto y como
referente durante el proceso de implementación.
Scope
El documento discute infraestructura de UC solamente. Los detalles de infraestructura de red están fuera
del scope de este documento.
El documento también suministra alguna información conceptual para explicar decisiones tomadas pero
este no es su propósito principal. Describe detalles específicos de la rede de IP Telephony de Collahuasi,
incluyendo templates de configuración de gateways, configuración de CallManager y Dial Plan. La
solución de UC es un reemplazo de la existente en la actualidad. Las políticas de Dial Plan, CAC y
restricciones de llamadas se determinan en base a las mejores prácticas, necesidades de negocio, costos
operativos o políticas de utilización inherente a Collahuasi. Sólo se darán sugerencias de modificaciones u
optimizaciones de acuerdo a la información de la configuración suministrada.
Este documento describe integración de CallManager, Unity, IPCC y Microsoft Lync.
Un document de Diseño de bajo Nivel (LLD = Low Level Design) consiste de un número de componentes
que incluyen:
Requerimientos del cliente
Contenido genérico y contenido específico del cliente
Mejores prácticas
Este diseño de bajo nivel ha sido escrito basado en el documento de Diseño de Alto Nivel “HLD” y en las
recomendaciones de mejores prácticas de Cisco.
El documento incluye guías de configuración detallada y templates los cuales se utilizarán como referencia
para crear configuraciones específicas de cada sitio necesarias en el deployment.
En realidad, el documento NIP (Network Implementation Plan) que será generado posteriormente, y bajo el
context del LLD, personalizará las configuraciones genéricas presentadas en este documento.
Documentos Relacionados
La solución de Telefonía IP en Collahuasi estará desplegada en diferentes sitios siendo los principales el
Datacenter de Coposa SCC, donde se instalará parte del cluster (Publisher y un Subscriber), Unity, IPCC,
servidor de Presence, CUMA y Herramienta de Management; Iquique, donde se instalará en segundo
subscriber y los gateways que permitirán uno de los accesos a la PSTN, y Santiago donde estarán los
gateways que permitirán el segundo acceso a la PSTN.
El cluster soportará un total de usuarios actual (aproximado) de 1400 con un crecimiento estimado de el
doble de esa cantidad en los próximos cinco años.
1. El cluster estará distribuido entre Coposa SCC e Iquique con la modalidad Clustering sobre la WAN.
El cluster está compuesto por tres servers: 1 Publisher +2 Call Processing Subscriber/CTI/MoH/TFTP.
Ambos subscribers serán primarios para un grupo de teléfonos y serán backups de los teléfonos
registrados en el otro.
2. En en resto de los sitios no habrá un CUCM local y los teléfonos se registrarán en el Data Center más
cercano. Gateways de voz con SRST habilitado permitirán mantener llamadas entre internos de cada
sitio en caso que los teléfonos pierdan la conexión con los CUCM.
3. El acceso a la PSTN se realiza a través de gateways instalados en Iquique y Santiago. Solo los
teléfonos que tengan como SRST a estos gateways tendrán acceso a la PSTN cuando pierdan
conectividad con el CUCM.
4. Habrá un esquema de restricción de llamadas determinado por Forced Authorization Code (FAC).
Cuando los teléfonos que utilizan los Gateways a la PSTN como SRST pasan a esta modalidad se
utilizará COR para la restricción de llamadas hacia la PSTN, pero no existe FAC disponible.
5. Un servidor de Unity instalado en Coposa SCC derá el servicio de Unified Messaging. En el caso de
perderse conectividad con el servidor de voicemail, los usuarios pierden la posibilidad de acceder a sus
mensajes hasta que el servicio sea restablecido.
6. Habrá un IPCC Express instalado en Coposa SCC para la atención de la mesa de ayuda.
7. Habrá usuarios con acceso al servicio de Extensión Mobility. Estos usuarios podrán hacer log in y tener
su profile en otros teléfonos en la de te telefonía de Collahuasi.
8. El servicio de movilidad se da a través de Mobile Connect (Single Number Reach) de acuerdo a las
restricciones establecidas en el HLD y Cisco Unified Mobile Communicator con cliente de
BlackBerry.
9. La solución se integrará con Microsoft Lync.
10. Se instalarán dos software de Management: QoS Police Manager y Cisco Unified Operation Manager.
La descripción de este software de management, su instalación y configuración están fuera del scope
de este documento.
Esta sección detalla el Hardware Cisco que será utilizado en los Datacentes de Collahuasi para el
deployment de IPT. Esto cubre el siguientes Hardware: CUCM, Unity, IPCC y Gateways.
Servers
Los Servers tienen que ser instalados en un ambiente que provea alta disponibilidad. Los servers tienen que
recibir energía de UPS si la energía del edificio no es confiable. La conectividad a la red tiene que asegurar
máxima performance y disponibilidad. Los servers se tienen que conectar a la red a 100 Mbps full-duplex.
Los servers que soportan interface Giga que se conectan a redes a 100 Mbps, deben configurarse fijando la
velocidad y el duplex del switch y el Server. Para 1000 Mbps se recomienda usar Auto/Auto para
velocidad y duplex en el Server y en el switch.
Modelo MCS7845-I3-IPC1
Single 5540 Quad-core 2.53-GHz
Numbero de Procesadores y
CUCM Appliance Model Velocidad
2 Servers en Coposa SCC 3 * 2 GB PC3-10600 1333-MHz DDR3
RAM
1 Server en Iquique Four 146-GB 10K SAS drives
Hard Disks
Floppy / DVD
Floppy / CD-Rom Drives
Dual onboard 10/100/1000
LAN Card
Aplicación CUCM 8.5
Modelo MCS-7835-I3-ECS1
Single Intel E5504 2.00-GHz; last level
Numbero de Procesadores y
cache: 8 MB
Velocidad
Unity Server
4-GB (two 2-GB DIMM) PC3-10600
1 Server en Coposa SCC RAM
1333-MHz, fully buffered DDR-3
RDIMM
Two 300-GB SAS 2.5-in. hot-swap
Hard Disks
Floppy / DVD
Floppy / CD-Rom Drives
Dual onboard 10/100/1000
LAN Card
Modelo MCS-7825-I4-CCE1
Numbero de Procesadores y Single Intel Dual Core Xeon E8400 3.0-
Velocidad GHz 6M L2
2-GB (two 1-GB) PC2-5300 Error
RAM
Checking and Correction (ECC) double-
IPCC Express Appliance data-rate 2 (DDR2)
Model
Hard Disks Two 250-GB Serial Advanced
1 Server en Coposa SCC
Technology Attachment (SATA) 3.5-in.
cold-swap drive
Floppy / DVD
Floppy / CD-Rom Drives
2 onboard Broadcom NetXtreme
LAN Card
10/100/1000
Aplicación IPCC Express 8.0
Modelo MCS7825I4-K9-CMD1
Numbero de Procesadores y Single Intel Dual Core Xeon E8400 3.0-
Velocidad GHz 6M L2
2-GB (two 1-GB) PC2-5300 Error
RAM
Checking and Correction (ECC) double-
Presence data-rate 2 (DDR2)
1 Server en Coposa SCC Hard Disks Two 250-GB Serial Advanced
Technology Attachment (SATA) 3.5-in.
cold-swap drive
Floppy / DVD
Floppy / CD-Rom Drives
2 onboard Broadcom NetXtreme
LAN Card
10/100/1000
Aplicación Presence 8.0
Modelo MCS7825I4-K9-CMD1
Numbero de Procesadores y Single Intel Dual Core Xeon E8400 3.0-
CUMA Velocidad GHz 6M L2
2-GB (two 1-GB) PC2-5300 Error
1 Server en Coposa SCC RAM
Checking and Correction (ECC) double-
data-rate 2 (DDR2)
Hard Disks Two 250-GB Serial Advanced
Technology Attachment (SATA) 3.5-in.
cold-swap drive
Floppy / DVD
Floppy / CD-Rom Drives
2 onboard Broadcom NetXtreme
LAN Card
10/100/1000
Aplicación CUMA 7.1.3
Gateways
Las siguientes tablas indican la composición de los gateways destinados a cada uno de los sitios:
EM-HDA-6FXO
DSP PVDM3-32U64
SRST NA
Las siguientes tablas muestran las versiones de software que serán utilizadas en este deployment:
Convención de Nombres
La convención de nombres que se utilizará en los distintos dispositivos y servers relacionados con la
solución de IPT se muestran es las siguientes tablas:
Requerimientos de la solución
La siguiente sección describe brevemente los requerimientos de la solución de telefonía que será
implementada en Collahuasi y que fueron establecidas en el documento de Diseño de Alto Nivel (HLD).
Requerimientos de la solución
La siguiente información ha sido extraída del documento de HLD.
o Integración con Microsoft Lync: Extiende las capacidades de IM y presencia de Microsoft Lync a
la solución de UC.
No está prevista en esta etapa la interconexión con la red de video.
Servicios
En esta sección se definen los servicios requeridos y que serán utilizados en el despliegue de la solución de
UC de Collahuasi
DHCP
DHCP se necesita para la operación de la red de telefonía IP. Específicamente se deben crear scopes de
DHCP individuales para cada VLAN de voice con suficiente espacio de direccionamiento para soportar el
número máximo de teléfonos que serán desplegados en esa VLAN. El servicio de DHCP será suministrado
por el DHCP erver de Collahuasi.
Además de las opciones habituales de DHCP como la máscara de subred, el default Gateway, el servidor
de DNS, etc, para los teléfonos se incluye la opción 150 que suministra la dirección IP del TFTP server.
El valor de lease time depende del comportamiento de cada red en lo que respecta a la asignación de
direcciones IP de PCs o laptops. Para la asignación de direcciones IP en los teléfonos se recomienda que el
lease time sea de 8 días o más para que permitir solucionar cualquier falla en el servdir de DHCP sin que lo
teléfonos se queden sin IP.
La siguiente tabla muestra la configuración
TFTP
Las funciones principales del TFTP Server son suministrar archivos para los servicios, archivos de
configuración para dispositivos como teléfonos o Gateways y los archivos para los upgrades.
Como se estableció en el HLD, y debido a la topología de Collahuasi, se utilizarán los subscribers como
servidores de TFTP de los teléfonos que estarán en ambos lados de la MPLS. Iquique, Santiago y Patache
utilizarán como TFTP Primario al servidor instalado en Iquique y los teléfonos de Faena utilizarán como
TFTP primario al servidor instalado en Coposa SCC. Ambos servers serán a su vez TFTP backup del otro
grupo de teléfonos.
El Service Parámeter Serving Count especifica la cantidad máxima de pedidos que pueden ser manejados
de manera concurrente por el TFTP server. El valor por default de este parámetro es 500. Este valor no
debe modificarse en aquellos servers que tienen activo el servicio de TFTP server conjuntamente con otro
Servicio de Call Manager como es el caso de Collahuasi.
Cada teléfono puede soportar hasta 2 dependiendo de él. Por lo que por cada teléfono habrá uno del que
obtiene la imagen y dos a quienes se la entrega propaganda el árbol. Esto permite una propagación más
rápida de la imagen. Hay una conexión TCP entre los dispositivos, no se hace broadcast de la información.
DNS
Se recomienda no utilizar DNS para las comunicaciones críticas en el ambiente de IPT (teléfono a CUCM,
Gateway a CUCM). Las direcciones IP se utilizarán para esas comunicaciones de manera de evitar que
impacte cualquier falla posible en el DNS.
Durante la instalación del Publisher en el cluster, éste es referenciado en la tabla local por su hostname.
Antes de instalar cualquier nodo subsecuente (subscribers) o definir cualquier endpoint en el sistema, se
debe cambiar el hostname por la dirección IP.
Durante la instalación de los servers el cliente de DNS no será habilitado.
DNS es requerido para los servidores de aplicaciones.
Para propósito de management los elementos de IPT (servers, gateways, etc) pueden ser refenrenciados en
el DNS.
Time Zone
NTP
Se recomienda la configuración de NTP en la red para permitir la sincronización de los archivos de log
entre los diferentes dispositivos.
The following needs to be configured in the IOS Cisco devices to achieve this:
LDAP Directory
La base de datos del CUCM se sincronizará con Microsoft AD 2003. El AD se utilizará también para
autenticar usuarios. Se utilizará con CUPS, CUMA, etc.
Workgroup / Domain
Los servers de UC en el data center serán instalados sobre Cisco Linux OS y no serán miembros de ningún
dominio Windows o workgroup.
La excepción es Unity donde el server debe ser incorporado al dominio.
El corazón de la red de IP Telephony es el Call Control o el Call Processing Engine. Para Collahuasi el
procesamiento de llamadas será llevado a cabo por un cluster de 3 CUCM.
Las siguientes sesiones detallan las actividades requeridas para implementar los servers CUCM y los IP
phones que comprenden el corazón de la solución de UC de Collahuasi, más cualquier configuración del
CUCM para integrar con otras aplicaciones/endpoints.
La red de UC base está compuesta por tres MCS-7845-I3-IPC1.
El cluster estará distribuído en la WAN entre Coposa SCC e Iquique. En Coposa SCC estará el Publisher y
1 Subscriber/TFTP/MOH/CTI Manager. En Iquique se instalará un Subscriber/TFTP/MoH/CTI Manager.
Consideraciones de Banwidth
Se recomienda que Collahuasi utilice esta ecuación como una guía para calcular el BW necesario para más
de 10.000 BHC:
Además del BW requerido para tráfico Intra-Cluster se requiere de un mínimo de 1.544 Mbps para tráfico
de base de datos y otro tráfico inter-server por cada Subscriber remoto.
http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucm/compat/ccmcompmatr.html
La siguiente tabla muestra la información requerida para la instalación de los servers del cluster:
Password del usuario Reservado fuera de la Tiene que tener al menos Se puede cambiar luego
administrador documentación 6 caracteres alfanuméricos de la instalación con:
y puedes tener - _
CLI > set password
admin
Security Password Reservado fuera de la Es el que utilizan los Se puede cambiar después
documentación miembros del cluster para de la instalación con :
comunicarse entre ellos.
CLI > set password
Debe contener al menos 6 security
caracteres alfanuméricos y
debe comenzar con un ! Precaución porque se
carácter alfanumérico. puede perder
comunicación entre el
cluster
Servers y Roles
Los servers se agregan automáticamente a la base de datos del cluster a medida que son instalados al
cluster. Se recomienda enérgicamente que el nombre de cada server sea cambiado por su IP address en
CUCM Administration > System Server, para evitar problemas relacionados con el DNS.
La siguiente tabla muestra los roles que cubrirán cada uno de los servers del cluster:
Licencias CUCM
Antes que los dispositivos se registren con el CUCM se necesitan instalar las licencias.
Licencias es una manera de Device License Unit (DLU). Una licencia puede ser agregada vía System >
Licensing > License file upload.
El administrador de licencias sirve como el componente lógico que mantiene registro de las licencias que
hay disponibles y utilizadas.
El administrador del sistema debe revisar periódicamente el status de las licencias. Este servicio se activa
desde Cisco Unified Serviceability, elegir Tools > Control Center - Network Services > Cisco License
Manager.
Activación de servicios
Los siguientes servicios estarán activados en cada uno de los servers del cluster:
CM Services
Cisco Call Manager N Y Y
Cisco TFTP N Y Y
Cisco Messaging Interface N N N
Cisco Unified Mobile Voice
Access Service N N N
Cisco IP Voice Media
Streaming App N Y Y
Cisco CTI Manager Y Y Y
Cisco Extension Mobility Y N N
Cisco Extended Functions Y N N
Cisco Dialed Number
Analyzer Y N N
Cisco DHCP Monitor Service N N N
CTI Services
Cisco IP Manager Assistant Y Y Y
Cisco WebDialer Web Service N N N
CDR Services
Cisco Soap-CDRonDemand
Service Y N N
Cisco CAR Web Service Y N N
Database and Admin Services
Cisco AXL Web Service Y Y N
Cisco Bulk Provisioning
Service Y N N
Cisco TAPS Service N N N
Performance and Monitoring Services
Cisco Serviceability Reporter Y N N
Cisco Communications
Manager SNMP Service Y Y Y
Security Services
Cisco CTL Provider N N N
Cisco Certificate Authority
Proxy Function N N N
Directory Services
Cisco DirSync Y N N
Redundancia de Subscribers
Cada par de subscribers soporta 7500 endpoints. Sin embargo para asegurar que la CPU y la utilización de
la memoria no superen el 70% se recomienda no se supere los 6000 endpoints por par de subscribers.
En Collahuasi se utilizará load balancing entre Servers. De esa manera no habrá ningún Servers que sólo
actúe en caso de backup sino que todos serán activos de un grupo y backup de otro.
Este modelo permite compartir la carga de procesamiento con lo que se consigue una respuesta más rápida.
Al mismo tiempo permite una transición más rápida en caso de falla de alguno de los servers debido a que
todos los dispositivos (teléfonos, CTI Ports, Gateways, etc) están distribuidos en todos los subscribers.
La distribución de carga de Collahuasi no será una distribución 50:50 debido a la distribución geográfica
de los dispositivos.
CUCM Groups
Se configurarán dos CUCM Groups para todos los endpoints. Cada dispositivo tendrá asignado como
primario su subscriber más cercano y sólo recurrirán al subscriber remoto en caso de falla. La tabla debajo
indica cómo serán configurados los CUCM Groups:
Date/Time Group
La red se encuentra en un solo time zone.
CUCM prove un mecanismo de Call Admission Control basado en Locations. Este feature permite
especificar la cantidad máxima de bandwidth para audio y video que está disponible para llamadas desde y
hacia cada location.
Esta especificación limita el número de llamadas activas o la utilización inadecuada de los enlaces WAN.
CUCM asume que cada llamada G.711 consume 80 kbps y que cada llamada G.729r8 consume 24 Kbps.
Estos valores no consideran el header de L2 que sí debe ser considerado cuando se realiza el cálculo de
bandwidth para QoS. En Collahuasi se utilizará G.711 dentro de cada sitio y G.729 a través de la WAN.
Regiones
Las regiones se utilizan para especificar el CODEC utilizado entre dispositivos dentro de una región y
entre regiones.
El uso de regiones especifica el tipo de compresión y cantidad de ancho de banda usado por llamada. Se
puede seleccionar la compresión y el ancho de banda usado por las llamadas dentro de una región y entre
dos regiones
Se definirán regiones y asignará una correspondencia de CODECS entre las mismas. Para las llamadas de
video se deja el default de 348 Kbps.
Table 33 Regiones
Regiones RGN_IQQ RGN_STG RGN_PTCH RGN_FAENA
RGN_IQQ G.711 G.729 G.729 G.729
RGN_STG G.729 G.711 G.729 G.729
RGN_PTCH G.729 G.729 G.711 G.729
RGN_FAENA G.729 G.729 G.729 G.711
RGN_G711 G.711 G.711 G.711 G.711
Locations
Locations trabajan en conjunto con Regiones para definir las características de un enlace. Como se indicó
anteriormente las Regiones definen el CODEC a ser utilizado y Locations define la cantidad disponible de
ancho de banda disponible para ese enlace. En Collahuasi se utilizará G.711 dentro de cada site para
calidad óptima de la voz y G.729 sobre la WAN para ahorar Bandwidth y proveer una calidad adecuada.
Locations son necesarias para proveer el Call Admission control (CAC) correcto para llamadas entre
sitios diferentes. Standard Bank diferentes sites entre sites centrales y sucursales y se aplicará CAC para las
llamadas entre los diferentes sitios.
La calidad de la voz puede comenzar a degradarse cuando hay muchas llamadas activas sobre un enlace y
la cantidad de ancho de banda es sobrepasado. El control de admisión regula la calidad de la voz limitando
el número de llamadas que pueden estar activas al mismo tiempo sobre un enlace.
Esto no garantiza un nivel de audio particular sobre el enlace sino que permite regular la cantidad de ancho
de banda consumido por las llamadas activas sobre el enlace.
Si la llamada es rechazada por no haber ancho de banda disponible, el usuario escucha una señal de reoder
tone y ve un mensaje en el display indicando que no hay suficiente bandwidth.
El CallManager desconoce el encapsulado y el overhead de la red y por lo tanto realiza un CAC basado en
el BW necesario por el codec utilizado.
Como resultado el CallManager deduce 24 Kbps para G.729 y 80 Kbps para G.711 por llamada.
HUB_NONE Ilimitado
Para audio es relativamente fácil calcular el porcentaje de overead por paquete. Para video, sin embargo, es
casi imposible calcular un porcentaje exacto debido a que el payload varía dependiendo del movimiento
presente en el video. Para resolver esto se recomienda agregar 20% sin importar que medio de L2 estén
atravesando los paquetes. Este 20% da un espacio suficiente para cubrir las diferencias entre los protocolos
de transporte Ethernet, Frame Relay,etc.
SRST
Survivable Remote Site Tellephony (SRST) se utilizan en sitios que dependen de un CUCM centralizado
que puede quedar inaccesible. SRST provee servicio de telefonía alos teléfonos en caso que pierdan la
posibilidad de acceder al CUCM. Un router con SRST tiene funcionalidades que permiten llamadas entre
los teléfonos bajo su servicio y en el caso que ese router tenga acceso a la PSTN, como Iquique y Santiago,
lo teléfonos en esos sitios tedrán también acceso a la PSTN a través del servicio de SRST.
SRST acepta registraciones de IP Phones y rutea llamadas basadas en el número de directorio que está
registrado y basado en el ruteo configurado en el Gateway para llamadas a la PSTN. Para esto los teléfonos
tienen que estar registrados en los gateways que tienen acceso a la PSTN.
SRST es una opción que se configura en el CUCM y provee una capacidad limitada si los teléfonos pierden
su conectividad con el CUCM. Cuando el teléfono pierde la conectividad con todos los CUCM asociados
intenta conectarse con el Gateway SRST que tiene como referencia. El teléfono indica en el display que ha
pasado a estado de SRST.
SRST tiene limitaciones algunas de las cuales se mencionan debajo. En SRST sólo un subset de
funcionalidades del CUCM están disponibles para los usuarios y las siguientes se pierden:
Habilidad de hacer login/logout de Extension Mobility. Sin embargo un usuario logged on no es logged
out cuando el teléfono pasa a SRST.
Voicemail no estará disponible.
Acceso a servicios XML centralizados (Corporate Directory, EM, IPMA) no estará disponible.
Aplicaciones centralizadas no estarán disponibles.
Particiones y Calling Search Space para las restriccione sde llamadas se pierden como así también FAC
y se implementará localmente en los gateways de IQQ y Santiago que tienne el acceso a la PSTN para
sus teléfonos locales.
La configuración del call forward.
No se generarán registros CDR en la base del Publisher
Solo conferencias en G711, los recursos de DSP no se utilizan y los streams se mezclan localmente en
el router.
Funcionalidad limitada de HuntGroup, CallPickup y GroupPickup.
No hay Call Park
No hay CallBack
Table 35 SRST
Sitio Gateway Nombre Capacidad VLAN IP Address Port
Coposa C3925-CME- GW-IPT-SCC-01 325 219 10.130.19.10 2000
SCC SRST/K9
Coposa C2951-CME- GW-IPT-VPO-01 125 220 10.130.20.10 2000
VPO SRST/K9
C2951-CME- GW-IPT-IQQ-01 175 240 10.130.40.10 2000
Iquique
SRST/K9
Patache C2921-CME- GW-IPT-PTCH- 75 252 10.130.52.10 2000
SRST/K9 01
Rosario C2951-CME- GW-IPT-RSR-01 125 232 10.130.32.10 2000
SRST/K9
C2951-CME- GW-IPT-STG-01 125 248 10.130.48.10 2000
Santiago
SRST/K9
Edif. C2951-CME- GW-IPT-SFR-01 125 204 10.130.4.10 2000
Sulfuro SRST/K9
LDAP
CUCM almacena el profile de los usuarios en su base de datos IDS. Collahuasi sincronizará la base de
datos con Microsoft Active Directory. La versión utilizada es AD 2003.
La siguiente sesión detalla la integración de CUCM LDAP.
La sincronización del CUCM con el directorio corporativo LDAP permite re-utilizar los datos de usuario
en el directorio LDAP y permite que el directorio LDAP se utiliza como repositorio central para esa
información. CUCM tiene una base de datos integtrada para almacenar los datos de usuario y una interface
web para crear y administrar los datos de usuario.
Cuando se habilita la sincronización, la base de datos local aún es utilizada pero la facilidad de crear
cuantas de usuarios se deshabilita.
El manejo de las cuentas de usuarios es entonces realizado a través de la interface del directorio LDAP. La
información de la cuenta del usuario es importada desde el LDAP a la base local en el Publisher. La
información que se importa desde LDAP no puede modificarse en el CUCM. Información adicional
específica a la implementación de UC puede ser manejada por el CUCM y se almacena en la base de datos
local. Por ejemplo la asociación del teléfono con el usuario, speed dials y los PINs son datos que se
manejan en el CUCM y se almacenan en la base de datos local del Publisher y no existen en el directorio
LDAP. Los datos se propagan desde el Publisher a los subscribers mediante la sincronización de la base de
datos.
Este proceso utiliza una herramienta interna llamada Cisco Directory Synchronization (DirSync) en el
CUCM para sincronizar un número de atributos de usuarios (de manera manual o períodica) desde el
directorio corporativo LDAP.
Cuando se habilita esta funcionalidad los usuarios son automáticamente tomados desde el directorio
corporativo. Esto sólo aplica a usuarios finales, mientras que los Applications users se mantienen de
manera separada y se mantiene su administración en el CUCM.
Resumiendo, los End users se definen en el directorio corporativo y se sincronizan con la base de datos del
CUCM mientras los Applications users se almacenan sólo en la base de datos del CUCM y no es necesario
definirlos en LDAP.
El proceso de autenticación de LDAP habilita la librería IMS para autenticar las credenciales de usuario
contra el directorio corporativo. Cuando se habilita esta funcionalidad, el password del End user se
autentica contra el directorio corporativo mientras que el application user se autentica localmente. Los PIN
de Extension mobility se autentican localmente.
Configuración de LDAP
Enterprise Parameters
Service Parameters
Service Parameters definen parámetros del servicio CUCM y de varios servicios. Pueden ser accedidos en
Service Parameter > Select Server > Select Service
Media Resources
Media Resource provee los recursos para mezclar la media (conferencias), conversión de codecs
(transcoding), MTP y Music on Hold (MOH). En esta sesión se analiza ese diseño para cumplir con los
requerimientos de Collahuasi.
El menu de Media Resources permite la configuración de los recursos de media, media resource group y
media resource group list.
MoH está también bajo este menú y será analizado en esta sesión.
Annunciator
CUCM incluye la habilidad de ejecutar anuncios pre-grabados (archivos .wav) y tonos a los teléfonos,
gateways y otros dispositivos configurables. Esto habilita al CUCM a alertar a los usuarios del por qué un
allamada ha fallado. Al ser una función del servicio Cisco IP Voice Media Streaming Application se
ejecuta co-residente en los CUCM servers del cluster.
En Collahuasi, el Annunciator se active en los servers donde se está ejecutando el IP Voice Media
Streaming Application. La siguiente tabla muestra la configuración:
Table 42 Annunciator
Nombre Descripción Device Pool Location
ANN_SCC Annunciator Subscriber DP_SCC Hub_None
SCC
ANN_IQQ Annunciator Subscriber DP_IQQ Hub_None
IQQ
El Media Resource Manager (MRM), un componente de software del CUCM determina si es necesario
utilizar un recurso de media para insertarlo en el camino de la media. Cuando el MRM decide e identifica
el tipo de recurso de media y busca a través de los recursos disponibles de acuerdo a la configuración.
Los recursos de Conferencia y Transcoding que se utilizarán serán de los DSP disponibles en los
Gateways. La siguiente tabla muestra los recursos de los Gateways de cada sitio:
Conferencias
Como se indicó en la tabla anterior todos los sitios tendrán recursos para conferencias Ad Hoc. Las mejores
prácticas de Cisco establecen que se reserven recursos de HW para conferencias para como mínimo el 5%
de la base de usuarios.
No existen actualmente estadísticas que pueda predecir este comportamiento y depende de cada sitio. Si el
usuario necesita establecer una conferencia y no existen recursos de DSP, la conferencia fallará.
El número de conferencias soportadas por los DSP depende de la cantidad de participantes de cada
conferencia y los codecs utilizados por cada una de ellas. En el cálculo estimativo de cantidda de
conferencias de acuerdo a los recursos disponibles en los gateways se consideraron conferencias en G.711
y en G.729.
Para configurar los recursos de conferencias Service > Media Resources > Conference Bridge
Transcoding
El CUCM invoca al transcoder cuando dos dispositivos están utilizando diferente códec y no son capaces
de comunicarse. Cuando se inserta en la llamada, el transcoder convierte el straem de datos entre dos
codecs diferentes para posibilitar la comunicación entre ellos.
MTP GW_IPT_LMINA
Cisco IOS Of Mina XCODE_HW_OMINA XCODE en DP_OMINA LOC_FAENA
Enhanced GW_IPT_OMINA
MTP
Cisco IOS Oxido XCODE _HW_OXD XCODE en DP_OXD LOC_FAENA
Enhanced GW_IPT_OXD
MTP
Cisco IOS Truck XCODE _HW_TRK XCODE en DP_TRK LOC_FAENA
Enhanced GW_IPT_TRK
MTP
Los tonos DTMF se utilizan durante una llamada para señalizar un dispositivo remote en el caso de la
navegación de menús, ingreso de datos u otra manipulación de dígitos. Se procesan diferente de lo que se
haría con los tonos DTMF que se envían durante el establecimiento de una llamada como parte de la
señalización de control.
Existen varias maneras de enviar DTMF sobre IP y puede ocurrir que dos endpoints no soporten un
procedimiento en común. En esos casos el CUCM podría insertar de manera dinámica un MTP en el medio
del camino para convertir señales DTMF de un endpoint a otro.
Una combinación de un endpoint SIP y uno no-SIP podrían requerir un MTP. Todos los endpoints SIP
Cisco no requieren conversión, por lo que si todos los endpoints SIP son Cisco el MTP no sería requerido.
El CUCM tiene la habilidad de tomar recursos de MTP dinámicamente en base a las capacidades de los
endpoints.
En Collahuasi se activará MTP en los servers donde se está ejecutando IP Voice Media Streaming
Application. La siguiente tabla muestra la configuración:
Music on Hold (MoH) prove música a los usuarios cuando las llamadas son puestas en hold, transferidas,
puestas en park o agregadas a una conferencia.
Para mayor calidad de MoH, los archivos de audio usarán G.711.
Hay dos partes donde se configure MoH: audio sources y la configuración de servers. Se recomienda que
en Collahuasi el MoH sea suministrado por los servers de cada sitio y para los sitios remotos se utilice
cada gateway como fuente de MoH para evitar enviar los streams a través de la red MPLS.
Se utilizará unicast en Faena desde el subscriber en SCC y en Iquique. Se utiliza MoH multicast en Patache
y Santiago entregando el stream desde los Gateways
Con MoH multicast la memoria flash de cada uno de los GW SRST de los sitios remotos tienen que tener
un archivo de audio para MoH y suministrar el stream de audio y evitar que este atraviece la WAN. El
archivo puede tener formato wav o au pero tiene que tener dato a 8 bit 8 khz como el formato a-law mu-
law. Esto implica habilitar multicast en los GW y en los switches de los sitios.
Se pueden obtener un archivo de audio para MoH (music-on-hold.au) en el archivo .zip que se puede bajar
de http://www.cisco.com/cgi-bin/tablebuild.pl/ip-iostsp y copiada en la flash de los Gateways.
Se utilizarán stream G.711 Unicast en los sitios principales y stream multicast G.711 generados en cada
sitio remoto desde los gateways.
MoH Servers
Para configurar el server de MoH en el cluster de Collahuasi, desde CUCM Administrator elegir choose
Service > Media Resources > Music on Hold Server.
Table 47 MoH
Nombre Descripción Device-Pool Location Max Max Multicast Run
Unicast Multicast Enabled Flag
Streams Connections
MOH_MUL_SCC Subscriber1 DP_MOH_MSCC HUB_NONE 500 500 Checked Yes
SCC
MOH_UNI_SCC Subscriber1 DP_MOH_USCC HUB_NONE 500 500 Unchecked Yes
SCC
MOH_MUL_IQQ Subscriber2 DP_MOH_MIQQ HUB_NONE 500 500 Checked Yes
IQQ
MOH_UNI_IQQ Subscriber2 DP_MOH_UIQQ HUB_NONE 500 500 Unchecked Yes
IQQ
Audio Source
Por Default, el audio se configure sólo en Unicast. La siguiente tabla muestra la configuración de MoH
audio source.
Sitios Remotos
MOH para los sitios remotos será enviado desde la flas de los gateways para salvar bandwidth en la
MPLS.
call-manager-fallback
ip source-address X.X.X.X port 2000
moh SampleAudioSource.wav
multicast moh 239.1.1.1 port 16384 route X.X.X.X
MRG y MRGL
Un Media Resource Group (MRG) es un grupo de recursos de media (conference bridge, MTP,
Annunciator, transcoder y server MOH) que se agrupan lógicamente para propósito de balanceo.
Un Media Resource Group List es una lista ordenada de MRG para propósito de redundancia.
En Collahuasi se ponen disposnibles diferentes recursos de media a través de la red. Para asegurar la
selección correcta de los recursos de media se agrupan en MRG y MRGL
Agrupamos los siguientes tipos de dispositivos en un MRG:
Un MRG provee un grupo priorizado de recursos de media de acuerdo al orden de prioridad por sitio
geográfico o lógico.
Point
MRG_MTP_IQQ MTP_IQQ Media Termination MTP en SUB2 IQQ
Point
MRG_MOH_MSCC MOH_MUL_SCC Music on Hold MoH multicast desde
SUB1 SCC
MRG_MOH_USCC MOH_UNI_SCC Music on Hold MoH Unicast desde
SUB1 SCC
MRG_MOH_MIQQ MOH_MUL_IQQ Music on Hold MoH multicast desde
SUB2 IQQ
MRG_MOH_UIQQ MOH_UNI_IQQ Music on Hold MoH Unicast desde
SUB2 IQQ
Un MRGL provee una lista priorizada de MRG. Una aplicación selecciona los recursos de media
necesarios, como el server de MoH dentro de los recursos disponibles de acuerdo al orden de prioridad
definido en el MRGL. Se recomienda que cada grupo utilice los recursos locales como primarios y los
remotos como backup.
MRG_MOH_USCC
MRG_ANN_IQQ
MRG_CFB_IQQ
MRGL_MIQQ MRG_XCODE_IQQ
MRG_MTP_IQQ
MRG_MOH_MIQQ
MRG_ANN_IQQ
MRG_CFB_IQQ
MRGL_UIQQ MRG_XCODE_IQQ
MRG_MTP_IQQ
MRG_MOH_UIQQ
MRG_ANN_IQQ
MRG_CFB_STG
MRGL_STG MRG_XCODE_STG
MRG_MTP_IQQ
MRG_MOH_MIQQ
MRG_ANN_IQQ
MRG_CFB_PTCH
MRGL_PTCH MRG_XCODE_PTCH
MRG_MTP_IQQ
MRG_MOH_MIQQ
MRG_ANN_FAENA
MRG_CFB_RSR
MRG_CFB_SFR
MRGL_RSR MRG_XCODE_RSR
MRG_XCODE_SFR
MRG_MTP_SCC
MRG_MOH_USCC
MRG_ANN_FAENA
MRG_CFB_SFR
MRG_CFB_RSR
MRGL_SFR MRG_XCODE_SFR
MRG_XCODE_RSR
MRG_MTP_SCC
MRG_MOH_USCC
MRG_ANN_FAENA
MRG_CFB_OXD
MRG_CFB_TRK
MRGL_OXD
MRG_XCODE_OXD
MRG_XCODE_TRK
MRG_MTP_SCC
MRG_MOH_USCC
MRG_ANN_FAENA
MRG_CFB_TRK
MRG_CFB_OXD
MRGL_TRK MRG_XCODE_TRK
MRG_XCODE_OXD
MRG_MTP_SCC
MRG_MOH_USCC
MRG_ANN_FAENA
MRG_CFB_LMINA
MRG_CFB_OMINA
MRGL_LMINA MRG_XCODE_LMINA
MRG_XCODE_OMINA
MRG_MTP_SCC
MRG_MOH_USCC
MRG_ANN_FAENA
MRG_CFB_OMINA
MRG_CFB_LMINA
MRGL_OMINA MRG_XCODE_OMINA
MRG_XCODE_LMINA
MRG_MTP_SCC
MRG_MOH_USCC
Device Pools
Un Device Pool es un grupo de parámetros comunes como regiones, CUCM Group, date/time Group, etc
que se aplicarán a un grupo de dispositivos. Algunos de esos parámetros son configurables a nivel de
dispositivo. Los parámetros que son configurables a nivel de dispositivo tiene precedencia sobre los que lo
son a nivel de device pool.
Para configurar los devices pools ir a CUCM Administration, elegir System > Device Pool
Para un mejor management, por ejemplo reiniciar/actualizar un grupo de teléfonos, los edificios de cada
sitio se asignarán a un device pool separado.
_SCC_I ONE
Dial Plan
El dial plan es el atributo fundamental del sistema de telefonía. Tiene mucho que ver con la experiencia del
usuario ya que define las reglas que gobiernan cómo el usuario alcanza los destinos. Las reglas del dial
plan incluyen:
Marcar extensiones: Cuántos dígitos tienen que ser marcados para alcanzar una extensión del
sistema.
Direccionamiento de extensiones: Cuántos dígitos identifican una extensión.
Privilegios de marcado: Permitir o no permitir cierto tipo de llamadas.
Selección del camino: Por ejemplo utilizar la red IP para llamadas internas y PSTN para llamadas
externas.
Selección automática de caminos alternativos en caso de congestion de la red, por ejemplo salir
por Santiago para llamadas nacionales cuando Iquique esta congestionado.
Bloquear el llamado a ciertos números: Por ejemplo servicios 6xx
Tranformar el número llamado: Por ejemplo mantener solo los 5 últimos dígitos de 8 dígitos
marcados.
El dial plan determina todos los aspectos del manejo de llamadas. CallManager Groups determina cual
CUCM procesará las llamadas. Particiones y Calling Search Space permiten crear restricciones que
especifican dónde pueden llamar los usuarios.
Los Route Groups definen los gateways que se utilizarán en cada sitio. Los Route Patterns identifican los
diferentes números destino.
Las Route List proveen múltiples caminos (Route Groups) para direccionar la llamada a un número que
hace match a un route pattern determinado. Existe también un Local Route Group que se elige
dinámicamente de los device pools y determina quien inicia la llamada a la PSTN.
Los números de emergencia deben ser alcanzables por cada dispositivo en el cluster sin importar qué
privilegios tiene el teléfono.
Como muestra la figura debajo, cuando se configuran los elementos del plan de enrutado de llamadas, el
orden de configuración es desde abajo hacia arriba. Eso significa que primero se configuran los gateways,
luego los route groups, route list y por último los route patters.
CUCM procesa las lamadas desde arriba hacia abajo. Por ejemplo, cuando un usuario marca un número, el
CUCM verifica si hay coincidencia con con algún route pattern. Si hay un match, el CUCM envía la
llamada al route list. CUCM verifica la lista del route groups en los route lists. Si hay más de un route
Group, envía la llamada al primero, si la llamada no puede ser completada, por ejemplo porque no hay
canales disponibles en el Gateway, el CUCM selecciona el segundo route Group para enviar la llamada.
Restricciones de llamadas: Cuáles son las extensiones o números externos que pueden o no ser
marcados desde una extención. Esto puede variar para diferentes grupos de teléfonos o usuarios de
Extension Mobility y es referido como “Class of Service” (CoS) o Class of Restriction (CoR).
Alcanzabilidad: Determina qué extensiones pueden ser alcanzadas desde otros teléfonos o desde la
PSTN.
Camino hacia el destino: determina cual es el camino por el cual será enviada la llamada. Eso
puede ser LAN/WAN para un IP pone en otro sitio o através de la PSTN.
Transformaciones: Cambios que se realizan al número llamado o al número llamando. Esos
cambios pueden ocurrir en varios puntos del camino lógico
La siguiente sesión establece las reglas que se utilizarán en el dial plan de Collahuasi.
Las llamadas que se originan y terminan en la misma red de telefonía se consideran on-net. Por contraste si
una llamada se origina en una extensión y tiene que ser ruteada a la PSTN. En los sistemas TDM, los
límites on-net de un sistema telefónico son establecidos por las PBX y generalmente no se extiende más
alla de un sitio. Uno de los atributos del sistema IP es su habilidad de expandir los límites de las llamadas
que pueden ser consideradas on-net.
Las llamadas hacia/desde la PSTN se clasifican como Off-Net y serán enrutadas hacia la PSTN a través del
Gateway.
La siguiente tabla sumariza los números Off-net que podrán marcarse desde las extensiones del CUCM
dependiendo de las restricciones aplicadas.
Números reservados
Restricciones de llamadas
Se configurarán restricciones de llamadas dependiendo de los privilegios de los usuarios para realizar
llamadas a algunos destinos y eso se aplicará en Calling Search Space (CSS) y como CoR (Classes of
Restriction) en los gateways en Iquique y Santiago cuando los usuarios de estos sitios ingresen en SRST.
Los números de emergencias y los números de extensiones serán siempre permitidos.
Las excepciones aplican con los managers que están bajo la modalidad de IPMA. En este caso, si bien el
número puede ser marcado la llamada es interceptada por la asistente. Algunos números siempre estarán
bloqueados sin importar los permisos de usuario. Estos números son definidos por Collahuasi. El acceso a
la PSTN siempre será permitido dependiendo del status del usuario de acuerdo a la siguiente tabla:
Desde sus teléfonos los usuarios pueden configurar el Call Forward All (CFA) para re-enviar las llamadas
destinadas a sus extensiones.
Los usuarios podrán re-enviar las llamadas a sus extensiones al mismo grupo de números a los que se le
permite llamar de acuerdo a su restricciones de llamadas. Por lo tanto si el usuario puede hacer llamadas
nacionales podrá re-enviar sus llamadas a números nacionales.
Esto se determina configurando el Service Parámeter “CFA CSS Activation Policy” con “With activating
Device/Line CSS”
Si se deja el parámetro “With Configured CSS (default)” se necesita configurar explísitamente las CSS
para CFA.
Desde la página Web del usuario puede también configurar Call Forward Busy (CFB) and Call Forward
No Answer (CFNA). Para esas restricciones específicas el administrador tiene que asignar el CSS
específicas en las extensiones de los usuarios. Por default el CSS asignado será a la categoría 0.
Una partición comprende una agrupación lógica de números de directorio (DN) y route patterns con
características de alcanzabilidad similares. Los dispositivos que se ubican generalmente en particiones
incluyen DNs y route patterns.
Un Calling Search Space comprende una lista de particiones. Los Calling Search Space determinan las
particiones que pueden ser alcanzadas cuando se intenta completar una llamada. Cuando se asigna un CSS
a un dispositivo, la lista de particiones en el CSS comprende las particiones que el dispositivo tiene
permitido alcanzar. Todos los otros DNs que están en particiones que no están en el CSS del dispositivo no
podrán ser alcanzados y se recibirá una señal de ocupado.
Los Calling Search Space pueden aplicarse en el device, en la línea o en ambos.
Utilizamos el calling search space en el dispositivo para proveer información de routing, por
ejemplo qué gateways seleccionar hacia la PSTN.
Utilizamos el calling search space en la línea para proveer la información de Class of Service.
Cuando se activa FAC a través de route patterns el usuario debe ingresar un código de autorización para
alcanzar el destino. Cuando un usuario marca un número que tiene que ser enlutado a través de un route
pattern con FAC, el sistema ejecuta un tono para indicar que es necesario ingresar el código de
autorización.
FAC se configura con niveles de autorización. Si el código de autorización del usuario no es igual o mayor
al nivel de autorización especificado para enrutar el número marcado, el usuario recibe un reorder tone.
Definición de Particiones
La definición de las particiones está relacionada a las restricciones de los usuarios. La siguiente tabla lista y
describe las definiciones de las particiones:
Table 58 Particiones
Nombre de las Particiones Descripción
Internas
P_INTERNOS Internos de las extensiones
P_GLOBAL_FEAT Features/Servicios globales
P_IPMA_RP Route Point de IPMA
Las Calling Search Space (CSS) es la lista ordenada de particiones. Para poder llegar a un destino la
partición de la parte llamada tiene que estar en la CSS de la parte llamando. La siguiente tabla muestra las
CSS que serán implementadas en la red de IP Phone de Collahuasi.
P_FAC_PRIV
P_IPMA_RP CSS para la línea de los
P_PSTN_EMERG_IQQ dispositivos en IQQ con Class 2
P_PSTN_SERV_IQQ
CSS_LINE_CLASS2_IQQ P_PSTN_LOC_IQQ
P_IQQ_W_STG
P_FAC_NAC
P_FAC_INTER
P_FAC_PRIV
P_MANAGER CSS para la línea de las
P_PSTN_EMERG_IQQ asistentes con Class 2
P_PSTN_SERV_IQQ
CSS_LINE__IPMA_CLASS2_IQQ P_PSTN_LOC_IQQ
P_IQQ_W_STG
P_FAC_NAC
P_FAC_INTER
P_FAC_PRIV
P_IPMA_RP CSS para la línea de los
P_PSTN_EMERG_IQQ dispositivos en IQQ con Class 3
CSS_LINE_CLASS3_IQQ P_PSTN_SERV_IQQ
P_PSTN_LOC_IQQ
P_IQQ_W_STG
P_FAC_INTER
P_MANAGER CSS para la línea de las
P_PSTN_EMERG_IQQ asistentes con Class 3
CSS_LINE__IPMA_CLASS3_IQQ P_PSTN_SERV_IQQ
P_PSTN_LOC_IQQ
P_IQQ_W_STG
P_FAC_INTER
P_IPMA_RP CSS para la línea de los
P_PSTN_EMERG_IQQ dispositivos con Class 4 en
CSS_LINE_CLASS4_IQQ P_PSTN_SERV_IQQ todos los sitios diferentes de
P_PSTN_LOC_IQQ IQQ y STG
P_IQQ_W_STG
P_MANAGER CSS para la línea de las
P_PSTN_EMERG_IQQ asistentes con Class 4
CSS_LINE__IPMA_CLASS4_IQQ P_PSTN_SERV_IQQ
P_PSTN_LOC_IQQ
P_IQQ_W_STG
P_IPMA_RP CSS Categoría 5
P_PSTN_EMERG_IQQ
CSS_LINE_CLASS5_IQQ P_PSTN_SERV_IQQ
P_PSTN_LOC_IQQ
P_IQQ_W_STG
P_BL_CELU
CSS para las línes en STG
P_IPMA_RP CSS para la línea de los
P_PSTN_EMERG_STG dispositivos con Class 0
P_PSTN_SERV_STG
P_PSTN_LOC_STG
CSS_LINE_CLASS0_STG P_STG_W_IQQ
P_BL_CELU
P_BL_NAC
P_BL_INTER
P_BL_PRIV
P_MANAGER CSS para la línea de las
CSS_LINE_IPMA_CLASS0_STG P_PSTN_EMERG_STG asistentes con Class 0
P_PSTN_SERV_STG
P_PSTN_LOC_STG
P_STG_W_IQQ
P_BL_CELU
P_BL_NAC
P_BL_INTER
P_BL_PRIV
P_IPMA_RP CSS para la línea de los
P_PSTN_EMERG_STG dispositivos en STG con Class 1
P_PSTN_SERV_STG
P_PSTN_LOC_STG
CSS_LINE_CLASS1_STG P_STG_W_IQQ
P_FAC_CELU
P_FAC_NAC
P_FAC_INTER
P_FAC_PRIV
P_MANAGER CSS para la línea de las
P_PSTN_EMERG_STG asistentes con Class 1
P_PSTN_SERV_STG
P_PSTN_LOC_STG
CSS_LINE__IPMA_CLASS1_STG P_STG_W_IQQ
P_FAC_CELU
P_FAC_NAC
P_FAC_INTER
P_FAC_PRIV
P_IPMA_RP CSS para la línea de los
P_PSTN_EMERG_STG dispositivos en STG con Class 2
P_PSTN_SERV_STG
CSS_LINE_CLASS2_STG P_PSTN_LOC_STG
P_STG_W_IQQ
P_FAC_NAC
P_FAC_INTER
P_FAC_PRIV
P_MANAGER CSS para la línea de las
P_PSTN_EMERG_STG asistentes con Class 2
P_PSTN_SERV_STG
CSS_LINE__IPMA_CLASS2_STG P_PSTN_LOC_STG
P_STG_W_IQQ
P_FAC_NAC
P_FAC_INTER
P_FAC_PRIV
P_IPMA_RP CSS para la línea de los
P_PSTN_EMERG_STG dispositivos en STG con Class 3
CSS_LINE_CLASS3_STG P_PSTN_SERV_STG
P_PSTN_LOC_STG
P_STG_W_IQQ
P_FAC_INTER
P_MANAGER CSS para la línea de las
P_PSTN_EMERG_STG asistentes con Class 3
CSS_LINE__IPMA_CLASS3_STG P_PSTN_SERV_STG
P_PSTN_LOC_STG
P_STG_W_IQQ
P_FAC_INTER
P_IPMA_RP CSS para la línea de los
P_PSTN_EMERG_STG dispositivos en STG con Class 4
CSS_LINE_CLASS4_STG P_PSTN_SERV_STG
P_PSTN_LOC_STG
P_STG_W_IQQ
P_MANAGER CSS para la línea de las
CSS_LINE__IPMA_CLASS4_STG
P_IPMA_RP asistentes con Class 4
P_PSTN_EMERG_STG
P_PSTN_SERV_STG
P_PSTN_LOC_STG
P_STG_W_IQQ
P_IPMA_RP CSS Categoría 5
P_PSTN_EMERG_STG
CSS_LINE_CLASS5_STG P_PSTN_SERV_STG
P_PSTN_LOC_STG
P_STG_W_IQQ
P_BL_CELU
CSS para las línes en Patache y Faena
P_IPMA_RP CSS para la línea de los
P_PSTN_EMERG_IQQ dispositivos con Class 0
P_PSTN_SERV_IQQ
P_PSTN_IQQ
CSS_LINE_CLASS0 P_PSTN_STG
P_BL_CELU
P_BL_NAC
P_BL_INTER
P_BL_PRIV
P_MANAGER CSS para la línea de las
P_PSTN_EMERG_IQQ asistentes con Class 0
P_PSTN_SERV_IQQ
P_PSTN_IQQ
CSS_LINE_IPMA_CLASS0 P_PSTN_STG
P_BL_CELU
P_BL_NAC
P_BL_INTER
P_BL_PRIV
P_IPMA_RP CSS para la línea de los
P_PSTN_EMERG_IQQ dispositivos con Class 1 en
P_PSTN_SERV_IQQ todos los sitios diferentes de
P_PSTN_IQQ IQQ y STG
CSS_LINE_CLASS1 P_PSTN_STG
P_FAC_CELU
P_FAC_NAC
P_FAC_INTER
P_FAC_PRIV
P_MANAGER CSS para la línea de las
P_PSTN_EMERG_IQQ asistentes con Class 1
P_PSTN_SERV_IQQ
P_PSTN_IQQ
CSS_LINE__IPMA_CLASS1 P_PSTN_STG
P_FAC_CELU
P_FAC_NAC
P_FAC_INTER
P_FAC_PRIV
P_IPMA_RP CSS para la línea de los
P_PSTN_EMERG_IQQ dispositivos con Class 2 en
P_PSTN_SERV_IQQ todos los sitios diferentes de
CSS_LINE_CLASS2 P_PSTN_IQQ IQQ y STG
P_PSTN_STG
P_FAC_NAC
P_FAC_INTER
P_FAC_PRIV
P_MANAGER CSS para la línea de las
CSS_LINE__IPMA_CLASS2 P_PSTN_EMERG_IQQ asistentes con Class 2
P_PSTN_SERV_IQQ
P_PSTN_IQQ
P_PSTN_STG
P_FAC_NAC
P_FAC_INTER
P_FAC_PRIV
P_IPMA_RP CSS para la línea de los
P_PSTN_EMERG_IQQ dispositivos con Class 3 en
CSS_LINE_CLASS3 P_PSTN_SERV_IQQ todos los sitios diferentes de
P_PSTN_IQQ IQQ y STG
P_PSTN_STG
P_FAC_INTER
P_MANAGER CSS para la línea de las
P_PSTN_EMERG_IQQ asistentes con Class 3
CSS_LINE__IPMA_CLASS3 P_PSTN_SERV_IQQ
P_PSTN_IQQ
P_PSTN_STG
P_FAC_INTER
P_IPMA_RP CSS para la línea de los
P_PSTN_EMERG_IQQ dispositivos con Class 4 en
CSS_LINE_CLASS4 P_PSTN_SERV_IQQ todos los sitios diferentes de
P_PSTN_IQQ IQQ y STG
P_PSTN_STG
P_MANAGER CSS para la línea de las
P_PSTN_EMERG_IQQ asistentes con Class 4
CSS_LINE__IPMA_CLASS4 P_PSTN_SERV_IQQ
P_PSTN_IQQ
P_PSTN_STG
P_IPMA_RP CSS Categoria 5
P_PSTN_EMERG_IQQ
CSS_LINE_CLASS4 P_PSTN_SERV_IQQ
P_PSTN_IQQ
P_PSTN_STG
P_BL_CELU
CSS Especiales
Gateways
Se configuran gateways Gateways H323 para acceso a la PSTN. H.323 utiliza el modelo peer-to-peer con
el CUCM. Un Gateway H.323 es en sí un call agent. Tiene su propio dial plan y call control (utilizando la
suite H.323)
El Gateway H.323 utiliza dial peers para el ruteo de las llamadas y puede proveer SRST y utilizar los
mismos dial peers
Antes de configurar el GW H323 en el CCM, se debe configurar el GW a través de los comandos de IOS.
El GW además se requiere en la configuración del dial plan para el acceso a la PSTN.
Table 60 Gateways
H.323 IP Nombre Device Pool Location CSS Tipo
Address
10.130.40.10 GW_IPT_IQQ_01 DP_IQQ LOC_IQQ CSS_GATEWAYS H.323
10.130.40.10 GW_IPT_IQQ_02 DP_IQQ LOC_IQQ CSS_GATEWAYS H.323
10.130.48.10 GW_IPT_STG_01 DP_STG LOC_STG CSS_GATEWAYS H.323
10.130.48.10 GW_IPT_STG_02 DP_STG LOC_STG CSS_GATEWAYS H.323
Route Groups
Un Route Group es un alista priorizada de gateways a las que los route patterns envían la llamada a través
del route list. Un route group direcciona todas las llamadas al dispositivo primario y luego utiliza los
dispositivos siguientes cuando el primario no está disponible o sus recursos están agotados. Todos los
dispositivos en un route Group tienen las mismas características, por ejemplo la manipulación de dígitos.
Local route Group es un feature que ayuda a reducir el número de route list y route patterns que son
necesarios desplegar en las implementaciones de un cluster donde cada uno de los sitios necesita tener
acceso a los gateways remotos.
Route List
Un route list define un camino para enviar la llamada. Apuntan a uno o más route groups al que le envían
la llamada en un orden de preferencia configurado.
Para poder ser asignado a los Route Patterns, cada Route Group tiene que formar parte de un Route List.
Route Patterns
Un route pattern comprende un string de dígitos y manipulación de dígitos asociada que rutea las llamadas.
Llamadas bloqueadas
9.09XXXXXXXX P_BL_CELU Llamadas a RL_LRL Block offnet / Outside
Celulares (precedence Dial Tone
level
excedeed)
9.032XXXXXXX P_BL_NAC Zona Primaria RL_LRL Block offnet / Outside
Valparaíso (precedence Dial Tone
level
excedeed)
9.041XXXXXXX P_BL_NAC Zona Primaria RL_LRL Block offnet / Outside
FAC
9.09[6-9]XXXXXXX P_FAC_CELU Llamadas a RL_LRL Route offnet / Outside No 20
Celulares Dial Tone
9.032XXXXXXX P_FAC_NAC Zona Primaria RL_LRL Route offnet / Outside No 30
Valparaíso Dial Tone
9.041XXXXXXX P_FAC_NAC Zona Primaria RL_LRL Route offnet / Outside No 30
Concepción Dial Tone
9.0XXXXXXXX P_FAC_NAC Llamadas RL_LRL Route offnet / Outside No 30
Nacionales Dial Tone
9.00! P_FAC_INTER Llamadas RL_LRL Route offnet / Outside No 40
Internacionales Dial Tone
9.00!# P_FAC_INTER Llamadas RL_LRL Route offnet / Outside No 40
Internacionales Dial Tone
Translation Patterns
El CUCM utiliza translation patterns para manipular los números marcados antes de enrutar la llamada.
Los tranalation patterns se utilizan para realizar cambios en el número llamado o el número llamando.
Líneas analógicas
En Collahuasi existen un grupo de líneas analógicas (FXO) que se utilizan como llamadas entrantes y que
serán utilizadas como redundancia para llamadas salientes en caso que se agote la disponibilidda de canales
en las tramas E1.
La siguiente tabla muestra la asignación de números a esas líneas a través de PLAR.
Santiago
2039101 6592 P_INTERNOS Fax Finanzas
2039102 6510 P_INTERNOS Operadora STG
2039019 6562 P_INTERNOS Fax recepción
La siguiente sesión establece los parámetros de diseño de los features de los IP phones.
Call Park
Call Park permite que un usuario detenga una llamada en una extensión y que otro usuario en el sistema
pueda alcanzarla. Esto se configura globalmente en el CUCM y puede ser utilizado por cualquier usuario
del sistema. Para utilizar call park se asignan números especiales como números call park. Solo una
llamada a la vez puede utilizar cada uno de esos números asignados. Para configurar call park Call
Routing > Call Park.
Call Pickup
Call Pickup permite a los usuarios tomar una llamada entrante dentro de su grupo. El número de call
pickup apropiado es marcado automáticamente cuando el usuario presiona la tecla Call Pickup sobre un IP
Phone. Para que el call pickup este operacional se requiere configurar el grupo de call pickup en la
administración del CUCM Call Routing > Call Pickup.
Group Call Pickup permite a los usuarios que pertenecen al grupo de call pickup responder llamadas
entrantes en otros grupos. El usuario debe marcar al número del call pickup apropiado cuando utiliza esta
funcionalidad. Sólo los números de directorio que pertenecen a un grupo de call pickup pueden usar esa
funcionalidad. Para que un usuario de un call pickup Group alcance llamadas destinadas a un usuario de
otro call pickup Group debe conocer el número del grupo.
Una vez determinados los grupos de pickup se le comunica a los usuarios el número. Para asignar el call
pickup Group a un usuario: Device > IP Phone > Go to line settings > Call Pickup Group
Meet me
Las conferencias Meet Me dan la posibilidad de reservar un número en particular para conferencias para
que todas las partes que van a asistir a las conferencias ya conocen de antemano el número de meeting.
La siguiente tabla contiene los parámetros de configuración.
Table 68 Meet Me
Rango Meet Me Descripción Particiones
28XX Rando de numerous para armar P_GLOBAL_FEAT
una conferencia MeetMe
Los IP Phone soportan un número de servicios que pueden ser activados de manera individual en teléfonos
específicos. Estos servicios que se utilizarán en Collahuasi son Extension Mobility (EM) e IP Manager
Assistant (IPMA).
Extension Mobility
Extension Mobility permite a un usuario hacer login en cualquier IP phone de manera que ese teléfono
tome el perfil del usuario. Al hacer login en otro teléfono, el usuario convierte temporariamente ese
teléfono para adoptar su número de línea, speed dials, servicios, permisos y cualquier otra propiedad
inherente al usuario.
Los usuarios que tendrán disponible el feature de EM son usuarios de nivel de management de Collahuasi.
Cuando el usuario esta logged-in tendrá las siguientes características:
Funcionalidad de IPMA: Se ha decidodo continuar con la funcionalidad de IPMA actual de
Collahuasi
No será requerido FAC para hacer llamados.
Tendrá la luz de MWI encendida en caso que reciba un voicemail
Como se indicó en el HLD el servicio EM Application puede sólo ser ejecutado en un servidor, en este
caso el Publisher por lo que si se pierde conectividad con ese server no habría posibilidad de realizar
logged-in al servicio.
Por esta razón se dará al usuario las funcionalidades principales para que pueda seguir operando sin
problemas:
- Mismo número de interno
- Podrá recibir llamados
- Deberá utilizar FAC
- No tendrá disponible el servicio de IPMA pero el manager puede activarlo bajo la modalidad utilizada
en Collahuasi.
- No tendrá disponible la luz de MWI en caso de recibir un voicemail
IPMA habilita a los asistentes a manejar llamadas entrantes en lugar de uno o más managers.
Existe una aplicación integrada en el CUCM con dos modalidades, Proxy Line y Shared Line.
La aplicación soporta las siguientes capacidades:
La asistente puede utilizar una consola instalada en su PC o utilizar el servicio Unified CM Assistant
Console phone para determinar el status del manager y determinar cómo administrar la llamada para proxy
line
Se ha determinado continuar con la modalidad actual de Collahuasi.
La arquitectura del servicio de IPMA comprende el servicio Cisco IP Manager Assistant, las consolas de
asistente y la interface del IP Phone.
La siguiente figura muestra la distribución e interacción de los componentes:
Cisco Tomcat carga el servicio de IPMA, un servlet. Cisco Tomcat se instala en el momento de la
instalación del CUCM.
El servicio de IPMA se instala en todos los CUCM en el cluster. Despues de la instalación el servicio es
activado desde serviceability. El servicio IPMA verifica si es uno de los CUCM configurado como Cisco
IPMA Server. Si es asi, el servicio intenta ser el servicio IPMA activo.
El servicio IPMA realiza las siguientes tareas:
Contiene el servicio HTTP que se ejecuta sobre el teléfono del manager
Contiene las páginas web que el manager utiliza para configurar
Contiene la lógica de routing que aplica filtros sobre las llamadas entrantes para el manager como
se muestra en el gráfico de abajo,
Se comunica con el CUCM a través de CTIManager
Accede a los datos de la base de datos
Soporta la aplicación de la consola
1- El usuario A llama manager marcando 6001. El CTI Route Point intercepta la llamada basado en el
número 6XXX.
2- Luego, basado en el DN del manager la llamada es redireccionada por el route point a una Proxy line
del manager en el teléfono de la asistente (el número 1110 es un ejemplo)
3- El asistente puede contestar o manejar la llamada y, si corresponde, redireccionarla al teléfono del
manager.
4- En el caso que la aplicación CMAssistant o el Route point fallen, existe un mecanismo a través de Call
Forward No Answer (CFNA) al 6XXX en el Route Point. En este caso la llamada iría directamente al
manager.
Hay que prestar especial atención a la configuración del dial-plan cuando se utiliza el feature de manager
Assistant con Proxy line. Para asegurar que las llamadas al manager sean interceptadas por el Route_Point
y direccionadas a la asistente, se configuran CSS y particiones especiales para que los DN de los managers
no sean alcanzables por nadie mas que por la Proxy line de la asistente.
El siguiente esquema es requerido para configurar IPMA:
The following IPMA „profiles‟ are requested by SAT, and will be configured on a per-manager and per-
assistant basis in the End Users menus of the CUCM :
- 1 Manager - 1 Asistente
- 1 Línea Principal
- 1 Línea intercom por asistente
- 1 Línea principal
- 1 Proxy Line por Manager
- 1 Línea Intercom por cada Manager
Consola de la asistente
Para que la asistente maneje las llamadas del manager se necesita la consola de la asistente. La aplicación
de consola provee a la asistente con una interface gráfica para manejar llamadas mientras que el servicio
provee una interface de menús para manejar llamadas. Ambos permiten que la asistente configure el
teléfono del manager y monitoree el status y la disponibilidad.
Para bajar la aplicación de consola:
https://10.130.56.10:8443/ma/Install/IPMAConsoleInstall.jsp
Para activar el teléfono como una consola no se requiere instalar nada, solo agregar el servicio en el
teléfono.
En el modo shared line el Route Point no es necesario para interceptor las llamadas. En este modo features
como call filtering, call intercept, selección de asistente no están disponibles.
1- El usuario A llama al manager marcando 6001. El DN del manager está en shared line con una línea
del teléfono de la asistente.
2- Ambos teléfonos sonarán a menos que el manager haya invocado No Molestar, en cuyo caso solo el
teléfono de la asistente sonará.
Para los casos en que la funcionalidad IPMA integrada en el sistema no sea adecuada para los usuarios, y
específicamente para los managers o asistente que tengan teléfonos 9971 que no soportan la funcionalidad
IPMA se crea una confihuración alternativa para esa prestación.
La funcionalidad es la siguiente:
- El Jefe tiene su número de extensión
- La Secretaria tiene su número de extensión
- Las llamadas de usuarios “comunes” deben desviarse automáticamente a la extensión de la
Secretaria
- La Secretaria puede transferirle de vuelta la llamada al Jefe
Al igual que en el caso anterior se crea una partición específica para la línea del manager a la cual los
usuarios no pueden llamar MANAGER-XXXX, con XXXX la extensión de manager para su
identificación.
DN del Manager
Un CSS es creado justo para el manager en cuestión, llamado CSS_MNAGER_XXXX, donde al igual que
en el caso anterior XXXX representa el DN del manager (esto es sólo a los fine sde identificación)
Este CSS se crea basao en el CSS que tendría la asistente más la partición MANAGER_XXXX agregada
en la parte superior. Esta CSS se asigna a las líneas 1 y 2 de la asistente. Este CSS también se asigna a
Subscribe CSS para que la sistente pueda ver el status de la línea del jefe a través de BLF (Busy Lamp
Field).
Unity
Para la configuración de Cisco Unified Messaging el server de Unity se instala en una infraestructura
existente, va a ser parte del ambiente de messaging del Exchange existente y utiliza el Domain
controller/global catalog server (DC/GC) existente. Con unified messaging se necesita solo una
infraestructura para soportar mensajes de voice y de email. Collahuasi es responsable de mantener DC/GC,
Exchange y DNS.
La siguiente tabla indica las características del Cisco Unity adquirido por Collahuasi:
Cisco Unity almacena los mensajes de voz en el message store de versiones soportadas de Exchange. En
Collahuasi la versión de Exchange utilizada es la 2007 que es soportada por la versión 8.0 de Unity.
Exchange
Unity almacena toda la información de los usuarios e información de configuración específica de Unity en
una base de datos SQL 2005 dentro de server de Unity.
Debido a que los datos de los usuarios están en el SQL del Unity, el Unity puede responder llamadas,
buscar número de extensiones de usuarios y tomar mensajes aun cuando el Exchange esta caído o
inaccesible. En este último caso los usuarios no tendrán acceso a los mensajes hasta que el Exchange se
encuentre nuevamente disponible.
Solo es necesario almacenar un subset de datos de usuario en el directorio y esa información no cambia
frecuentemente por lo que la replicación del directorio por causa de cambios en el Unity es poco frecuente.
Una pequeña cantidad de datos que aparecen en el SQL también aparecen en el Active Directory como se
señaló anteriormente, incluyendo el nombre grabado.
Unity monitorea el directorio para mantener la sincronización de los datos entre el directory el el SQL.
Para replicar datos en el Active Directory se necesitan algunos cambios en el directory. El Active Directory
schema debe extenderse con algunos atributos específicos de Unity.
El siguiente link indica esos atributos que deben ser modificados:
http://www.cisco.com/en/US/docs/voice_ip_comm/unity/white/paper/5xcudatadirectory.html
http://www.cisco.com/en/US/docs/voice_ip_comm/unity/white/paper/5xcuadsizing.html
Hay información de Unity que se almacena tanto en SQL 2005 como en el address book/directory. Esta
imformacoión puede modificarse en ambos. La información del usuario puede ser modificado por el
administrador de Unity en el Unity server o puede modificarse desde el Active Directory.
Debido a que esta información puede ser almacenada y modificada en más de un lugar, hay que sincronizar
regularmente. Debido a que el dato almacenado en el directorio es pequeño, el impacto en la replicación
entre el SQL y el directory es mínimo. La excepción es cuando los usuarios del unity se crean importando
los datos desde el Exchange.
Para asegurar que Cisco Unity funcione correctamente se necesita que el server de Unity esté en el mismo
data center que los siguientes gateways:
Server de Exchange con el que se comunica el Unity
Al menos un domain controller. Si los usuarios de Unity están en más de un dominio, debe haber
un DC por cada dominio en el mismo datacenter que el Unity.
Al menos un global catalog.
Al menos un DNS
Conectar el server Unity y aquellos servers con los que se comunica a una red gigabit sin congestion. El
tiempo de respuesta MAPI debe ser menor a 10 msegundos.
El unity debe ser instalado en el mismo ambiente Windows que el Exchange.
El Exchange tiene que poder enviar tráfico UDP a puertos dinámicos en el Unity, los puertos se negocian
por MAPI. Esas notificaciones le dicen al Unity cuándo un mensaje de un usuario ha sido leído, cuando se
ha entregado un nuevo mensaje o información relacionada. Si hay un firewall entre el Unity y el Exchange,
el Exchange tiene que poder enviar tráfico UDP a los puertos del Unity 1024-65535.
Mas adelante en este documento se indican los puertos que deben estra abiertos en los firewalls que se
encuentren entre las diferentes aplicaciones.
Resolución de Nombres
Unity tiene que poder encontrar los servers con los que interactúa resolviendo nombres a IP address:
Los mensajes pueden ser entregados al mailbos del usuario sólo si el Unity puede encontrar el
Exchange.
Los usuarios acceden al Cisco Unity Assistant o Cisco Unity Inbox
Unity tiene que utilizar DNS
Unity tienen que tener acceso al Windows Domian Controller para autenticar cuentas de servicios, con el
Exchange como message store, para autenticar usuarios.
Cuando se instala Unity se especifica el Exchange server con el que se comunicará, partner Exchange
server. El message store almacena los mailbox alias: Unity_<ServerName>
Cuando el Exchange server, o message store, no está disponible la funcionalidad de Unity queda
afectada de la siguiente manera:
o Los mensajes de llamados externos se almacenan en el Unity como se indicó anteriormente, en
el Unity Message Repository (UMR), y puede ser accedidos desde allí durante este período.
Sin embargo, los mensajes de voz que fueron recibidos con anterioridad no están disponibles
hasta que el server del message store este disponible nuevamente.
o No funciona el message waiting indicator (MWI)
La performace del Exchange es crítica para la performance del Unity. Para asegurar que la
performance del Exchange no afecte de manera negativa al Unity se recomienda que Collahuasi
evalúe la performance de su infraestructura de Exchange antes de instalar Unity.
El server de Exchange debe cumplir con los requerimientos de Microsoft, incluyendo el número
máximo de usuarios por server, la cantidad de memoria apropiada, el procesador y la velocidad
del procesador apropiados, disco rígido que permita un buen tiempo de respuesta.
Unity no puede soportar que el server de Exchange con cuello de botella como disco lento o
memoria insuficiente. Por ejemplo, en caso de acceso al disco duro lento o transacciones de logs
demoradas, el acceso IMAPI, utilizado por Microsoft Outlook, Exchange o el acceso de Unity a
Exchange, se suspenderá temporariamente hasta que se liberen los buffers de transacción a cierto
nivel. Esto puede demorar el acceso al Unity.
Al servidor de Exchange no se le permite servir al máximo número de usuarios que permite Microsoft.Para
obtener la capacidad recomendada de Mailbox de un server de Exchange se puede recurrir a la información
suministrada por Microsoft http://technet.microsoft.com/en-us/library/aa996719(EXCHG.80).aspx
Es importante para la provisión de capacidad de estorage para voicemail que el sistema tendrá calcular
ciertos parámetros tales como códec, duración máxima del mensaje y capacidad máxima de voicemail por
usuario. Es necesario establecer los valores en base al espacio libre en el disco del server. Como base
puede tomarse que los voicemail generalmente no son mayores a 100Mb para usuarios comunes. Si luego
calculamos el espacio que ocupa un minuto de voicemail dependiendo del códec:
Luego obtenemos que 100 Mb equivale a 208 minutos para G711 y 1666 minutos para G729. Esos valores
son bastantes grandes para usuarios standard ya que los voicemail no son generalmente mayores a 20-30
minutos. La recomendación entonces es configurar el sistema para un máximo de 25 Mb por usuario con
G711 (para proveer la calidad máxima de voz) que equivale a una capacidad de voicemail de 52 minutos.
El AD schema debe extenderse para que Unity funcione adecuadamente. Esto trae un impacto en
el AD. El siguiente link provee información que debe ser tenida en cuenta por el administrador de
AD: Active Directory Capacity Planning
http://www.cisco.com/en/US/docs/voice_ip_comm/unity/white/paper/5xcuadsizing.html
En este documento también se incluye información sobre los objetos que Unity habilita para voz.
Finalmente discute el Unity schema, que es lo que se necesita cuando se extiene el schema y
cuándo es necesario.
Para instalar Cisco Unity promeramente hay que hacer una extensión del schema. El siguiente
documento brinda información sobre Unity y AD Cisco Unity Data and the Directory
http://www.cisco.com/en/US/docs/voice_ip_comm/unity/white/paper/4xcudatadirectory.html#wp
43458
Los principales servicios de Unity inician session utilizando dos cuentas del AD que el instalador
crea durante el proceso de instalacin del Unity:
o El Servicio de Message store inicia session utilizando la cuenta de servicio de message
store. La cuenta debe tener acceso directo al Exchange messahe store donde reside el
usuario.
o Los servicios de Directory inicia sesión utilizando la cuenta de directory services. Esos
servicios escriben a objetos de usuario, grupo y contacto cuando estos objetos se
importan al Unity y escriber sobre las propiedades de un ususario en particular cuando un
usuario o administrador realiza cambios personales.
La instalación del Unity, los servicios de message store y directory necesitan permisos del Active
Directory para crear objetos durante la instalación y para manejar objetos durante la operación
regular. El Unity Permissions wizard garantiza los permisos requeridos basados en opciones que
el instalador elige para la configuración del cliente.
Recursos Microsoft
La integración habilita la comunicación entre el Unity y el sistema telefónico, proveyendo a los ususarios
con los siguientes features:
Llamar a una extension de un usuario que no responde o tiene su línea ocupada y sumnistrar el
saludo personal del usuario.
Los mensajes que se dejan a los usuarios activan el message waiting indicator (MWI) en las
extensions. En el caso de los usuarios con Extension Mobility, el MWI se encenderá cuando el
usuario se haya registrado en el teléfono.
El usuario acceder de manera sencilla a los mensajes presionando el botón de mensajes e
ingresando el password.
Unity puede ser integrado con CUCM con puertros de SCCP o trunk SIP. Se recomienda la utilización de
pueros SCCP por las siguientes razones:
1. Integrando cpon SCCP, Collahuasi podría incorporar redundancia que no es soportado con SIP.
Como guía general, se recomienda configurar el 75% de los puertos de Unity para llamadas entrantes y el
25% para llamadas salientes.
Llamadas entrantes son generalmente usuarios consultando sus mensajes o llamadores externos que están
interactuando con el auto-attendant o dejando mensajes a otros usuarios.
Llamadas salientes son típicamente llamadas para avisar a los usuarios de los mensajes o para encender el
MWI en el teléfono del usuario. El uso de los puertos salientes es muy breve.
La table debajo muestra la utilización de los puertos en base a la capacidad máxima de puertos del
Hardware que se utilizará para la instalación del Unity que es este caso es de 48 puertos.
La siguiente sesión establece los parámetros a configurar en el CUCM para integrar con Unity
CDC <None>
Location HUB_NONE
Partition P_UM
CSS CSS_UM
LG_UM_IN Top Down Try Next Try Next Try Next Voice ports
Member; Then, Member; Then, Member; Then, entrantes
Try Next Group Try Next Group Try Next Group
in Hunt List. in Hunt List. in Hunt List.
LG_UM_OUT Top Down Stop Hunting Stop Hunting Stop Hunting Voice Ports
Salientes
system
3111* CSS_UM Unity Voicemail Pilot check
Para integrar Unity con CUCM se necesita Unity-CM TSP. La siguiente tabla muestra las compatibilidad
entre versiones:
IPCC Express
CRS Engine
Es el componente que provee los servicios de ACD, IVR y CTI y cumple las siguientes funciones:
CRS Database
Es el componente que maneja el acceso a las base de datos. El CRS Database contiene 4 lugares de
almacenamiento de datos:
Configuración: Contiene información como recursos (agentes), skills, resource groups, teams y
colas.
Repositorio: Contiene los prompts y documentos.
Agentes: Contiene el log de los agentes, estadísticas y punteros a los archivos de recording
Historical: Contiene Contact Call Detail Records (CCDR).
Password del usuario Reservado fuera de la Tiene que tener al menos 6 Se puede cambiar luego de la
administrador documentación caracteres alfanuméricos y instalación con:
puedes tener - _
CLI > set password admin
Application user CCXCOP Se utiliza para acceder a las Se puede cambiar luego de la
aplicaciones que se instalan instalación con :
en el sistema como el Cisco
CLI > utils reset_application_ui_
Unified Communications
Manager. administrator_name
Security Password Reservado fuera de la Es el que utilizan los Se puede cambiar después de la
documentación miembros del cluster para instalación con :
comunicarse entre ellos.
CLI > set password security
Debe contener al menos 6
caracteres alfanuméricos y ! Precaución porque se puede perder
debe comenzar con un comunicación entre el cluster
carácter alfanumérico.
Licencias
UCCX utiliza un nuevo sistema de licenciamiento llamado LIcense MAC que es diferente de la MAC
física. Este string se genera durante la instalación y esta compuesto de varios parámetros como el
hostname, IP address, mask, default Gateway, time zone, NTP, DNS, SMTP, Certificate Information
(Organization, Unit, Location, State, Country). Si cualquiera de esos campos se modifica luego de la
instalación, el License MAC será inválido y se deben solicitar nuevas licencias.
Administración de CUCM
MLA
La administración de CUCM utiliza roles y grupos de usuarios para proveer niveles de privilegios (acceso).
Esto permite garantizar privilegios específicos a un grupo de usuarios y limitar las funciones de
configuración de otros.
Los roles y los grupos de usuarios proveen múltiples niveles de seguridad a la administración de CUCM y
otras aplicaciones. Cada aplicación viene con roles standard y predefinidos. Cada aplicación define su
propio privilegio de acceso.
El administrador puede configurar roles adicionales para una aplicación. Un role contiene, para una
aplicación particular, la lista de recursos que comprenden una aplicación. Para cada recurso que comprende
el role, el administrador define los privilegios de acceso. Para la aplicación CUCM, los privilegios de
acceso incluyen read y update. Otras aplicaciones especifican sus propios privilegios de acceso.
Después de configurar los roles para una aplicación, el administrador puede configurar grupos de usuarios.
User Groups define grupos de usuarios que comparten una lista común de roles asignados. User groups
comprende ambos, application user y end user.
Roles
Un role incluye una colección de recursos para una aplicación como la aplicación CUCM Administrtaion.
Existen dos tipos de roles: standard, que son los roles por default, y custom, roles definidos por el
administrador. Roles standard para una aplicación se crean durante la instalación de la aplicación. Los
administradores pueden definir roles custom.
Todos los roles standard creados durante la instalación no pueden borrarse o modificarse, pero pueden
copiarse para crear roles custom basados en roles standard. Se recomienda a Collahuasi definir roles
custom de acuerdo a sus políticas de management y provisioning.
Para CUCM application, para los recursos que están en un role en particular aplican los siguientes accesos:
Read: Especifica que el usuario que se encuentra en este grupo definido para un recurso en
particular puede sólo ver la ventana que comprende el recurso pero no modificar. El privilegio
Read limita el acceso a solo ver la operación. Los botones tales como Insert, Delete, Update y
Reset no son mostrados a estos usuarios.
Update: Especifica que los usuarios que se encuentran en este grupo definido para un recurso en
particular puede ver y cambiar. Los botones tales como Insert, Delete, Update y Reset son
mostrados a estos usuarios. Así mismo las funciones ejecutivas que pueden start o stop procesos o
servicios en Serviceability.
User Groups
Un User Group comprende una colección de CUCM appplication user y end users que son agrupados con
el propósito de asignar una lista común a los miembros de ese grupo.
Hay varios user groups que son pre-definidos y no tienen moenbros asignados al momento de la
instalación. El usuario con privilegios para configurar grupos puede asignar usuarios a ese grupo.
La determinación de los grupos y de los privilegios está directamente relacionada con, y depende de, la
estructura de administración que Collahuasi determine para el cluster y los privilegios asignados a quienes
estén destinados a esa administración.
Firewall y ACL
Esta sección focaliza en los puertos utilizados entre los diferentes componentes de la solución de
Collahuasi. Estos tienen que ser tenidos en cuenta al momento de la configuración de la infraestructura,
Firewalls y ACLs, que se encuentran en el camino de la señalización y de la media.
Las siguientes tablas proveen los puertos que serán necesarios entre los varios elementos de la solución de
Collahuasi.
Esto podría no ser completo y podría ser necesario tests específicos durante el deployment de Firewalls.
La siguiente tabla lista los puertos que el CUCM8.5 utiliza para conectarse con dispositivos fuera del
cluster. Esta provee información importante para la configuración de Firewalls, Listas de acceso (ACLs) y
QoS en Collahuasi para la solución de UC. Los siguientes puertos tienen que ser abiertos en el caso que se
instalen firewalls entre los data centers y por lo tanto entre los servers CUCM.
Endpoint or Gateway Unified CM 69, 6969, then Ephemeral Servicio Trivial File Transfer
/ UDP Protocol (TFTP) para teléfonos y
gateways
Unified CM NTP Server 123 / UDP Network Time Protocol (NTP)
SNMP Server Unified CM 161 / UDP Servicio SNMP requerido por los
software de management
SNMP Server Unified CM 199 / TCP SNMP agent Nativo escuchando
un puerto para soporte de SMUX
SNMP Server Unified CM 7999 / TCP Cisco Discovery Protocol (CDP)
Unified CM Directorio Ephemeral/ TCP Lightweight Directory Access
Externo Protocol (LDAP) query hacia
Directorio Externo
directorio (Active Directory,
Unified CM Netscape Directory)
External Directory CUCM Ephemeral/ TCP Lightweight Directory Access
Protocol (LDAP) query hacia
directorio (Active Directory,
Netscape Directory)
Browser Unified CM 80, 8080 / TCP Hypertext Transport Protocol
(HTTP)
Browser Unified CM 443, 8443 / TCP Hypertext Transport Protocol
sobre SSL (HTTPS)
Browser o CLI Unified CM 2355, 2356 / TCP Eventos de Log audit events
desde la CLI and aplicaciones
Web
Unified CM Phone 80 / TCP Hypertext Transport Protocol
(HTTP)
QRT , RTMT , Find and List
Phones page , Phone
Configuration page
Phone Unified CM 8080 / TCP Phone URLs para aplicaciones
XML, autenticación, directories,
servicios, etc. Se puede
configurar esos puertos por
servicio.
Phone Unified CM 2000 / TCP Skinny Client Control Protocol
(SCCP)
Phone Unified CM 5060 / TCP and UDP Session Initiation Protocol (SIP)
phone
Cisco Unified Communica- Unified CM 2749 / TCP TLS entre aplicaciones CTI
tions App (JTAPI/TSP) y CTIManager
Cisco Unified Communica- Unified CM 2789 / TCP JTAPI application server
tions App
Además de los teléfonos IP los end users tendrán que acceder a la solución de Unified Communication
utilizando el browser.
Los siguientes puertos podrían ser requeridos en firewalls que se encuentren en el camino de la
señalización.
Los siguientes puertos podrían ser requeridos en firewalls que se encuentren en el camino de la solución de
Unity/Exchange.
El Unity no debe ser separado por Firewalls de los siguientes servers:
Exchange
Domain Controller
Global catalog
La siguiente tabla lista los puertos que son necesarios tenar habilitados en los firewalls para permitir la
comunicación con el IPCC:
Consideraciones Operacionales
La siguiente sección considera aspectos operacionales que deben ser tenidos en cuenta para no afectar la
operación de la plataforma de voice.
Las políticas de cambio de password de muchas empresas consideran una renovación periódica de
passwords de los servers. Debe considerarse que estos servers no forman parte de un sistema de servers
tradicionales sino que conforman la plataforma de UC y que no sigue los patrones normales de cambio de
password.
En el caso de los modelos de appliance: CUCM, IPCC, CUP, CUMA, no todos los password pueden ser
cambiados, y en el caso que sí se pueda, existen procedimientos específicos para el cambio de password
que deben ser ejecutados específicamente y no pueden formar parte de una rutina periódica de cambio de
pasword.
En el caso de Unity cuyo sistema operativo es Windows, al igual que los servers anteriores conforma la
plataforma de UC y su cambio de password no puede regirse por la política general de cambio de password
que se utilice para el resto de los servers del datacenter.
Estos servers poseen sus propias políticas y sistemas de seguridad.
Cualquier cambio de password que se requiera realizar a los servers que conforman la plataforma de
UC debe ser previamente notificado a los administradores de esta plataforma para la ejecución del
proceso correspondiente.
Los cambios de password NO pueden regirse por una política de renovación de passwords rutinaria que
afecte al resto de los servers del DC.
En el caso de los appliance: CUCM, IPCC, CUP y CUMA el sistema operativo es Linux. Todas las
aplicaciones vienen con Security Agent incorporado. NO soportan instalación de aplicaciones o software
adicional a los instalados durante el proceso de instalación.
Para el caso de Unity cuyo sistema operativo es Windows Server 2003 SP2
La ejecución del antivirus puede afectar la utilización del procesador por lo que se recomienda que se
programe su ejecución fuera del horario de mayor utilización del sistema de telefonía.
Como se indicó anteriormente No puede instalarse cualquier software adicional en los servers que
componen la plataforma de UC. Los antivirus soportados en Unity 8 son los siguientes:
CA Anti-Virus for the Enterprise version 8.0 y posterior (Llamado eTrust Antivirus)
Computer Associates InoculateIT for Microsoft Windows
McAfee
o NetShield for Microsoft Windows
o VirusScan Enterprise
Symantec
o AntiVirus Corporate Edition
o Norton AntiVirus for Microsoft Windows
Trend Micro
o ServerProtect for Microsoft Windows
1- Bug de software
2- Security advisory
Se denomina update de software a aquella actualización que se realiza dentro del mismo main release, por
ejemplo de 8.0 a 8.5 dentro del main release 8.x
Se denomina upgrade de software a aquel que se realiza desde una main release a la siguiente, por ejemplo
desde la versión 7.x a la 8.x.
NO instalar parches de Microsoft o de Linux de manera independiente. TODOS los parches deben ser
obtenidos desde Cisco e instalados siguiendo el proceso establecido en el Release Note.
Para el caso particular de Unity cuyo sistema operativo es Windows deben tenerse las referencias.
Microsoft provee pdates períodicos de Windows, Exchange, SQL, Explorer y IIS. Esos updates, conocidos
de diferentes maneras, incluyendo security rollup patches, security updates, critical updates, parches y
hotfixes, están limitados a solucionar problemas específicos, no incluyen nuevos features. Todos esos
updates de Microsoft son analizados en Cisco desde el día que Microsoft los pone disponibles. Cisco
provee un wizard para instalar los updates de Microsoft que aplican al software instalado en el servidor de
Unity.
El siguiente link provee la información necesaria acerca del wizard:
http://www.cisco.com/en/US/partner/docs/voice_ip_comm/unity/updates/wizard/2011cuupwz.html#wp420
75
Microsoft ocasionalmente también suministra services pack. Debido a que la razón del service pack puede
ser amplia, cada service pack debe ser revisado para asegurar que no afecte negativamente a Unity. NO
instalar SP que no hay sido revisados por Cisco o la aplicación no será soportada por el TAC. Dentro de los
60 días de liberado el SP, Cisco anuncia si éste puede ser aplicado al Unity
Obtener información
Para obtener información sobre nuevos releases disponibles para updates de las aplicaciones o updates de
firmware de los teléfonos es aconsejable incribirse para la recepción de notificaciones en el siguiente link:
http://www.cisco.com/cisco/support/notifications.html
En este caso las notificaciones serán sobre CUCM, pero esta operación puede repetirse para todas las
aplicaciones que comprenden la solución de UC instalada en Collahuasi
Análisis de la versión
Este documento provee toda la información necesaria a considerar antes de proceder al update/upgrade
Los puntos clave a verificar en este documento son:
Release Notes para la versión que se está analizando: Este documento provee toda la información
relacionada con las restricciones a tener en cuenta, proceso de update/upgrade, bugs solucionados
y bugs pendientes y todo lo que debe tenerse en cuenta antes de comenzar el uldate/upgrade.
SIEMPRE se debe leer la información provista en el release Notes antes de realizar cuanquier
instalación a un server en producción
Compatibility Matrix:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/compat/ccmcompmatr.html
Este documento muestra la compatibilidad entre la versión a la que se quiere llevar la aplicación con todo
el resto de aplicaciones relacionadas.
En el caso de los teléfonos otra información a tener en cuenta son los default loads que corresponden a las
versiones de los firmwares que que han sido probados con la versión y a partir de las cuales se debe
utilizar.
Figure 14 Compatibility Matrix
CUCM Hardware
http://www.cisco.com/en/US/partner/prod/collateral/voicesw/ps6790/ps5748/ps378/data_sheet_c7
8-564637.html
Unity Hardware
http://www.cisco.com/en/US/partner/prod/collateral/voicesw/ps6790/ps5748/ps378/data_sheet_c7
8-564635.html
IPCC Express Hardware
http://www.cisco.com/en/US/partner/prod/collateral/voicesw/ps6790/ps5748/ps378/data_sheet_c7
8-478937.html
CUCM Ports
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/port/8_0_2/portlist802.html
Unity Ports
http://www.cisco.com/en/US/docs/voice_ip_comm/unity/5x/security/guide/ex/5xcusec030e.html#
wpxref62278
IPCC Express ports
http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_8_0/c
onfiguration/guide/uccx801putil.pdf
Name Name
Title Title
Company Company
Signature Signature
Date Date
Name Name
Title Title
Company Company
Signature Signature
Date Date