viernes, 10 de agosto de 2012


Curso Cisco Voice Unified Communications Administration
CCNA Voice Certification Parte 1-3
Cisco Unity Connection


Cisco Unity Connection


  •          Instalado sobre Appliance o una instalación basada en Cisco Unified Computing System
  •          Hasta 20.000 usuarios por Servidor
  •          Acceso a mensajes de vos desde cualquier parte
  •          Integración con LDAP
  •          Soporte para Microsoft Exchange
  •          Perfil de voz para Internet Mail (VPIM)
  •          Correo de voz compatible con la supervivencia de sitio remoto


Requerimiento mínimo de Cisco Unity Connection versión 8.0
  •          Procesador de 2Ghz
  •          2G en RAM
  •          146GB de espacio en disco duro


Sistema de Mensajería de Voz Cisco



Max. Casillas
Plataforma
Redundancia
Cisco Unity Express
300
Router
No
Unified CM Business Edition
500
Appliance
No
Cisco Unity Express
15.000 por Server
Windows Server
Activo/Pasivo
Cisco Unity Connection
20.000 por Server
Appliance
Activo /Activo

Arquitectura de Cisco Unity Connection


  •          Almacena los mensajes localmente en su sistema de archivos
  •          Cisco Unity Connection usa la base de datos Informix de IBM para la configuración de los datos
  •          El flujo de audio para los mensajes de voz fluyen entre el que llama y el sistema de comunicaciones de Cisco Unity Connection



Alta disponibilidad en Cisco Unity Connection


  •          Activo/Activo
  •          Ambos servidores aceptan llamadas de audio, http e IMAP
  •          Un servidor es designado como el nodo primario, que poses la base de datos y el message store
  •          El nodo secundario de suscribe a la base de datos y al message store del Publisher




martes, 7 de agosto de 2012


Curso Cisco Voice Unified Communications Administration

CCNA Voice Certification Parte 1-2
Cisco Unified Communications Manager




Cisco Unified Communications Manager


Las capacidades de Cisco Unified Communications Manager son:
  •          Soporte de audio y video telefonía
  •          Hasta 30.000 teléfonos por clúster
  •          Corre sobre un appliance con sistema operativo endurecido
  •          Basado en base de datos Informix de IBM
  •          Sistema de Recuperación ante desastres (DRS) para respaldos y mecanismos de restauración
  •          Funcionalidades de administración y troubleshooting con “Cisco Unified Serviceability” y Cisco RTMT


Hardware Requerimiento:
  •          Servidores Cisco MCS 7800
  •          Cisco Unified Computing System
  •          Servidores de otros proveedores
Servidores con un mínimo de:
  •          Procesador de 2Ghz
  •          2 GB RAM
  •          Disco duro de 72GB


Alta disponibilidad de Cisco Unified Communications Manager


  •          Hasta 30.000 teléfonos en un Clúster
  •          Hasta 8 servidores corriendo con el servicio de “Cisco Callmanager”
  •          Hasta 3 subscriptores corriendo en un Grupo de Unified CM
  •          Hasta 2 servidores con servicios de TFTP
  •          Adicionales servidores pueden ser usados para recursos de medios, etc.


La decisión de cuantos subscriptores agregar al clúster depende de:

  •          Requerimiento de respaldo en caso de fallas (redundancia)
  •          Dividir la carga de los servidores (Compartición de carga)
  •          Cuantos teléfonos serán soportados en la red (escalabilidad)


Replicación de Base de Dato y características de cara al usuario


Base de Datos Informix:
  •          El Publisher es el dueño
  •          Replicación solo en un sentido
  •          Todos los cambios son hechos en el Publisher
  •          Si el Publisher está abajo:
o   Características de cara al usuario (User-facing features) tal como traspaso de llamadas, son cambiadas en el Subscriber activo
o   Cambios en el subscriber son replicados a los otros servidores en el Clúster.
  •          Cuando el Publisher sube de regreso, el subscriber sincroniza los cambios con el Publisher.



Comunicación Intracluster


  •          La señalización de la comunicación intracluster (ICCS), replica datos en tiempo real como la registración de dispositivos, a todos los nodos que arrancan el servicio de “Cisco Callmanager”
  •          Call Detail Records (CDR) y Call Management Records (CMRs) son recogidos por  los subscriptores
o   Los datos son periódicamente subidos al Publisher
o   El sistema de Cargo (Billing) se conecta solo con el Publisher

Flujo de Datos Cisco Unified Comunications Manager


  •          Señalización y el control de la sesión fluye entre el Cisco Unified CM y el teléfono IP, y entre el Cisco Unified CM y el Gateway de la PSTN
  •          El flujo de audio es terminado en el Gateway PSTN, y se convierte el flujo en Time Division Multiplexing (TDM)



Principales características de Cisco Unified Comunications Manager


  •          Procesamiento de llamadas
  •          Señalización y control de dispositivos
  •          Alta escalabilidad
  •          Configuración vía GUI (Interfaz Gráfica de Usuario)
  •          Servicio de Directorio Telefónico
  •          Soporte de CTI (Computer Telephony Integration)
  •          Soporte de aplicaciones (XML)


viernes, 3 de agosto de 2012


Curso Cisco Voice Unified Communications Administration

CCNA Voice Certification Parte 1-1
Cisco Unified Communications Manager Express y Cisco Unity Express




Entendiendo los componentes de la solución Cisco Unified Communications



Dentro de la solución de Cisco Unified Communications tenemos:
  • Cisco Unified Communications Manager Express y Cisco Unity Express
  • Cisco Unified Communications Manager
  • Cisco Unity Connection
  • Cisco Unified Presence


Cisco Unified Communications Manager Express (CME)


Las capacidades que incluye son:

  • Telefonía IP
  • Video Telefonía
  • Soporta hasta 350 teléfonos IP
  • Conferencias
  • Tcl scripts
  • Soporta aplicaciones de terceros
  • Arquitectura basada en ruteo

Las plataformas en que es soportado CME

  • Cisco 3250 à 20 teléfonos IP
  • Cisco IAD 2430 à 25 teléfonos IP
  • Cisco 3270 à 48 teléfonos IP
  • Cisco 1861 ISR à 15 teléfonos IP
  • Cisco 2801 ISR à 25 teléfonos IP
  • Cisco 2811 ISR à 35 teléfonos IP
  • Cisco 2821 ISR à 50 teléfonos IP
  • Cisco 2851 ISR à 100 teléfonos IP
  • Cisco 3825 ISR à 175 teléfonos IP
  • Cisco 3845 ISR à 250 teléfonos IP


Flujo de Datos Cisco Unified Communications Manager Express (CME)


CME usa Session Initiation Protocol (SIP) o Skinny Client Control Protocol (SCCP) para comunicarse con teléfonos IP para setup de llamadas y señalización.

Cuando la llamada es configurada, el intercambio del medio de comunicación ocurre directamente entre los teléfonos usando Real-Time Transport Protocol (RTP) para transportar los datos de voz.



Características claves de Cisco Unified Communications Manager Express (CME)


  • Procesamiento de llamadas
  • Señalización y control de dispositivos
  • Configuración vía CLI o GUI
  • Servicio de Directorio
  • Soporte de Computer telephony integration (CTI)
  • Despliegue sobre sitios únicos o múltiples sitios
  • Interconexión con CUCM
  • Trabajadores conectados de forma remota

    Cisco Unity Express


      Las principales capacidades de Cisco Unitu Express son:

  •           Proveer correo de voz
  •          Capacidades de Auto-attendant
  •          Soporte IVR
  •          Soporte para mensajes de fax
  •          Supervivencia de sitio remoto de correo de voz

  

     Módulos de Cisco Unity Express


  •          Cisco Serie 2800/3800                   à  AIM2-CUE-K9 / NME-CUE
  •          Cisco Serie 2900/3900                   à ISM-SER-300-K9 / SM-SER-700-K9



     Flujo de Datos Cisco Unity Express


  •          La señalización y el control de sesión fluye entre el Unified CME y el Cisco Unity Express módulo.
  •          El Stream de audio fluye entre el teléfono ip y el módulo del Cisco Unity Express.
  •          Cisco Unity Express solo soporta G.711 audio streams. Transcodificadores son necesarios para llamadas G.729.




miércoles, 20 de junio de 2012


Problemas porque una Dirección IP No responda en Switch Cisco





A veces nos encontramos que instalamos un servidor o una impresora y no responde ping, por ejemplo:

 switch>ping 10.1.1.1

 ******************************************************************
Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)
*******************************************



Puede haber varias razones entre las que podemos mencionar que indiquen porque nuestro server NO responde:



1.     El servidor o impresora (u otro equipo con ip) no tiene la ip que dice que tiene, por lo que tenemos que revisar lo siguiente en el Server:

a.       Dirección IP: 10.1.1.1

b.      Gateway: 10.1.1.254

c.       Máscara: 255.255.255.0



2.      Segundo debemos comprobar que el Gateway existe en nuestro switch L3 o router, es decir:

a.       Existe la Vlan à  Por ejemplo la vlan 10

                                                              i.      Show vlan:

1.       VLAN Name                             Status    Ports

---- -------------------------------- --------- ------

10    default                          active    Gi2/1



b.      Existe la Interfaz Vlan à Por ejemplo Interface Vlan10

                                                              i.      Show run int Vlan10

1.       interface Vlan10

description Vlan Server

 ip address 10.1.1.254 255.255.255.0



c.       Y por ultimo debemos revisar si la puerta del switch esta asignada a la Vlan respectiva

                                                              i.      Show run int g2/1

1.       interface GigabitEthernet2/1

switchport access vlan 10

 switchport mode access





Para comprobar por spanning-tree que nuestra puerta del switch conoce la vlan, ejecutamos el siguiente comando:



router#show spanning-tree vlan 10



VLAN0010

  Spanning tree enabled protocol ieee

  Root ID    Priority    8208

             Address     0011.9359.8b40

             This bridge is the root

             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec



  Bridge ID  Priority    8208   (priority 8192 sys-id-ext 16)

             Address     0011.0000.0000

             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

             Aging Time 300



Interface        Role Sts Cost      Prio.Nbr Type

---------------- ---- --- --------- -------- --------------------------------

Gi2/1           Desg FWD 4         128.75   P2p







Nos vemos

miércoles, 30 de mayo de 2012

Cisco Unified Communications Manager 8.5 "Diseño de un Red de Telefonía IP Parte 3 Diseño de un Clúster Clustering sobre la WAN – Failover Remoto"

Cisco Unified Communications Manager 8.5
Diseño de un Red de Telefonía IP Parte 3
Diseño de un Clúster
Clustering sobre la WAN – Failover Remoto

El diseño del clúster comprende el Publisher y un subscriber ubicado en el sitio A y un subscriber instalado en el Sitio B. El esquema de redundancia será 1:1 active/backup con balanceo de carga.
Para proveer disaster recovery y una distribución de recursos más equilibrada a diferentes áreas geográficas los siguientes puntos relacionados a la redundancia del clúster deben ser considerados:
·         La solución no provee un backup de Publisher, en el evento de una falla en el Publisher no pueden realizarse modificaciones en la configuración.
·         El plan es que haya TFTP servers en cada Sitio y aplicar features específicos que permiten un upgrade de firmware de los teléfonos no traumático en caso de upgrade completo.

Clustering sobre la WAN – Failover Remoto

Para cumplir con el requerimiento de proveer procesamiento de llamadas aún si uno de los sitios falla, se configurará un modelo de deployment “Clustering sobre la WAN” con redundancia de procesamiento 1:1 y balance de carga separada entre los servers localizados a través de la WAN.

Failover remoto permite instalar los servers de procesamiento de llamadas separados en la WAN entre Sitio A y Sitio B.

En cada sitio que dependa de estos sitios centrales a través de conexiones LAN, se instalarán Gateways con SRST para mantener los llamados internos en caso de pérdida de conectividad con el clúster.

Algunas características claves serán mantenidas:

·         Único punto de administración para todos los sitios
·         Transparencia de features
·         Shared lines
·         Dial plan unificado


Consideraciones en la WAN
Clustering en la WAN requiere que se cumplan algunas características de diseño, planificación e implementación.
La comunicación Intra-Cluster (ICCS= Intra-Cluster Communication Signaling) entre los servers consiste de muchos tipos de tráfico. Esos tipos de tráfico ICCS se clasifica como tráfico priority o Best Effort. En el primer caso se marca con DSCP 24 o PHB CS3. El tráfico Best Effort se marca con DSCP 0 o PHB BE. Esta marca la realizan los servidores de UC.
Las siguientes condiciones deben ser cumplidas cuando se realiza clustering sobre la WAN:
·         El delay máximo one-way entre dos CallManagers para todo el tráfico priority ICCS no tendría que exceder 20 ms o 40 ms de round-trip (RTT). El delay de otro tráfico ICCS tiene que mantenerse razonable para permitir el acceso a la base de datos y directorios. El delay de propagación entre dos sitios agrega 6 micro-seg por Km, sin considerar ningún otro tipo de delay.
·         El jitter es la variación del delay en el que el paquete puede incurrir a través de la red debido a procesamiento, colas, buffers, congestión o variaciones de delay en el camino. Para el tráfico ICCS priority debe ser minimizado utilizando QoS.
·         La red no debe tener errores o pérdida de paquetes para el tráfico ICCS priority debido a que la pérdida o los errores tendría efecto negativo sobre el procesamiento de llamada dentro del clúster.
·         Ancho de banda: Es necesario suministrar el ancho de banda necesario entre los servers para el volumen de llamadas esperado, tipo y número de dispositivos. Este ancho de banda es adicional a cualquier otro BW para otras aplicaciones que compartan la red incluyendo voice y video. El BW debe tener QoS habilitado para proveer prioritización y scheduling para las diferentes clases de tráfico.

Guías de diseño:
·         Cada 10000 busy hour call attemps (BHCA) entre sitios que tienen clúster sobre la WAN requiere 900 kbps de BW para Intra-Cluster Communications Signaling (ICCS). Este es el mínimo BW requerido y el BW es asignado en múltiplos de 900 kbps.
·         El mínimo recomendado entre sitios que están en clustering sobre la WAN es 1.544 Mbps. Esta cantidad permite un mínimo de 900 kbps para ICCS y 644 kbps para LDAP y otro tráfico inter-server.
·         Entre cualquier dos servers del clúster se permite un Round Trip máximo (RTT) de 40 ms. Este tiempo es igual a 20 ms de delay máximo de one-way, o una distancia de transmisión de aproximadamente 3000 km en condiciones ideales.

La siguiente tabla muestra los puertos utilizados por el tráfico ICCS y las marcas:
Call Manager TCP/UDP Ports

Tráfico
Descripción
TCP/UDP ports
Marking

ICCP

ICCS
CTiM
CES

TCP 8000 – 2
TCP 8003
TCP 2552 - 1

CS3
CS3
CS3

IBM INFORMIX

Replicación de base de datos entre servers

TCP 1526

Best Effort 0

LDAP

DC Directory replication between all servers

TCP 389, 8404

Best Effort 0

RIS

RIS Data Collector

TCP 2555 – 6

Best Effort 0

SCCP
IP Phone signaling.
TCP 2000 - 2
CS3
H323
H225
RAS GK
RAS GK CCM
1720
1719
1718
CS3
CS3
CS3










Cisco ha comenzado a cambiar las marcas de los protocolos de control de voice desde DSCP 26 (PHB AF31) a DSCP 24 (PHB CS3). Sin embargo muchos productos aún marcan con DSCP 26 (PHB AF31), por lo tanto, se recomienda que las reservas de bandwidth consideren ambas marcas. El CallManager 8 usa el nuevo sistema de marcas.

Redundancia de Subscribers
La tecnología de clustering provee redundancia de Call Manager. La redundancia de Call Manager es la habilidad de proveer un server hot standby para el procesamiento de llamadas para todos los endpoints capaces de mover su conexión desde el primario automáticamente en caso de disrupción del servicio.
Se pueden definir hasta tres Subscribers por grupo de CallManagers. El backup tiene que tener la capacidad de soportar los teléfonos registrados de manera primaria a ellos y eventualmente los que se registren cuando deban actuar como backup
En este diseño 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.

Utilizando grupos de redundancias y device pools se puede hacer que los dispositivos se registren en uno de los subscribers mientras que el otro, del otro lado de la WAN actúa como backup y viceversa. Esta distribución debe ser realizada con cuidado de manera que cuando un server responde a sus dispositivos registrados, y a su vez actúa como backup de los dispositivos del otro server en un momento de falla, no se exceda la cantidad máxima de dispositivos que el server puede soportar.
En el caso que ambos servers lleguen a quedar no disponibles se realiza un switch a SRST en los gateways.


TFTP
Como se mencionó anteriormente las funciones principales del TFTP Server son suministrar archivos para los servicios, archivos de configuración para dispositivos como teléfonos o Gateways, los archivos para los upgrades y archivos de seguridad.
Cada vez que un endpoint pide un archivo hay una nueva sesión de transferencia TFTP. En un modelo de procesamiento centralizado el tiempo en completar esa transferencia afecta el tiempo en que un endpoint está listo para operar. Si bien no es el único factor que afecta el tiempo que se toma un endpoint para quedar listo para operar, es un componente importante. El tiempo que toma cada transferencia de archivo vía TFTP es función del tamaño del archivo, el porcentaje de paquetes TFTP que deben ser retransmitidos y la latencia y el round-trip de la red.
Debido a que la latencia y la pérdida de paquetes afecta el tiempo de transferencia de TFTP, es ventajoso tener un TFTP server local. Este server TFTP local podría ser un subscriber local en un modelo de clustering sobre la WAN.
Una alternativa es TFTP Load Server en un router local. Los dispositivos se configuran con una dirección de un server local, que le permite al endpoint bajar archivos pequeños de configuración del TFTP central y obtener los archivos más grandes de firmware de un server local. Este método requiere que el administrador cargue los archivos de firmware en los TFTP servers en cada sitio.
Otro método de upgrade de firmware sin utilizar la WAN excesivamente es utilizar Peer File Sharing (PFS). Con este feature sólo un teléfono de cada modelo baja el nuevo firmware del TFTP central.
Una vez que un teléfono baja el firmware distribuye el archivo a todos los otros teléfonos.
Este método evita la carga manual y la configuración necesaria en los “Load servers”.
El feature PFS trabaja de manera que los teléfonos se ordenan en una jerarquía al momento de hacer el upgrade. Intercambian mensajes entre ellos y seleccionando el root que será quien realice el download desde el TFTP. El teléfono envía el archivo de firmware al segundo teléfono en la cadena mediante TCP, éste lo envía al tercero y así hasta llegar al último teléfono.
La jerarquía se forma por subnet y por firmware de teléfono.
En nuestro caso, se utilizará el modelo de un server TFTP en cada lado de la WAN y el feature PFS. La siguiente figura muestra un esquema del funcionamiento.



Media Resources
Los Media Resources, conferencias, annunciator, transcoders, media termination point (MTP) y MoH pueden ser provistos de un par de maneras dependiendo del tamaño del clúster y de la topología de la solución.
La siguiente es una breve descripción de los servicios:
·         Music on Hold (MoH): Provee MoH unicast o Multicast a los dispositivos que se ponen on hold, se transfieren o son agregados a una conferencia. Debido a que la red de nuestro sitio está integrada a través de la red MPLS que no soporta multicas, en los sitios remotos será entregado por los gateways locales y los archivos de audio se localizarán en la flash de los dispositivos.
·         Annunciator: Provee anuncios en lugar de tonos para indicar números marcados incorrectamente. Este servicio se brinda desde los CUCM servers.
·         Conference bridges: Puede ser basado en software o en hardware, en este caso será suministrado por hardware.
Todos los sitios proveerán recursos de locales por hardware para las conferencias. Las mejores prácticas indican reservar recursos de conferencias para al menos el 5% de la base de recursos.
Los recursos de DSP serán tomados de los Gateways Locales.
·         Media termination point (MTP): provee features para clientes H323, trunks H323 y trunks SIP.
Cisco AS recomienda que el diseño para recursos de media este distribuido equitativamente y tener redundancia a través del clúster. Esto se realiza a través de Media Resource Group List (MRGL) y Media Resource Group (MRG). El ancho de banda de la WAN debe ser tenido en cuenta en el diseño de los recursos de media a través de la WAN.

Music on Hold
MoH provee la música a los usuarios cuando su llamada en puesta on hold, transferida, puesta en park o agregado en una conferencia. Para proveer la mayor calidad de MoH, el archivo de audio utilizará el códec G.711.
La propuesta para este clúster es proveer MoH multicast desde los servers del Sitio 1 y del Sitio 2 solamente, esto significa que serán utilizados sólo por los teléfonos de esos lugares. La distribución de MoH al resto de los sitios y en particular a través de la WAN que no soporta Multicast estará basado en la flash de los servers locales como lo indica la siguiente figura:



Se alcanzará configurando los subscribers con un audio que tiene la misma IP Multicast y número de port que el que se configura en los gateways. Debido a que el stream de audio MoH está viniendo de la flash de los gateways, no es necesario que atraviesen la WAN.
Para lograr esto es necesario que la infraestructura soporte Multicast.
Para tener streams de MoH en multicast desde la flash del Gateway, hay que considerar que se recomienda que el límite del archivo de audio sea de 10 MB que contiene aproximadamente 10 min de audio.

CTI Manager
El CTI Manager se necesita para las aplicaciones que usan TAPI o JTAPI como el IPCC. Las aplicaciones CTI se comunican con un CTI Manager primario y si ocurre una falla utilizarán un backup.
El CTI Manager tendría que ser activado sólo en Subscribers. Se recomienda realizar load-balance a través de varios CTI Managers.
Saludos