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

Cisco Unified Communications Manager 8.5

Diseño de un Red de Telefonía IP Parte 2

CUCM Clúster Services

Dentro del clúster hay servers que proveen servicios específicos.

Con CUCM 8.x, un clúster podría contener hasta 20 servers, de los cuales un máximo de 8 podrían ejecutar el servicio de CallManager que provee el procesamiento de las llamadas. Los otros servers podrían ser configurados como Publisher, un server dedicado a TFTP o MoH por ejemplo

Publisher (o Primer Nodo):

Hay uno por clúster.

En grandes deployments con más de 1250 usuarios se recomienda un Publisher dedicado para prevenir que las operaciones administrativas afecten el servicio de telefonía. Un Publisher dedicado no tiene un servicio de TFTP o procesa llamadas.

Call-Processing Subscriber:

Es el server que realiza el procesamiento de llamadas. Los dispositivos como teléfonos, gateways y media resources pueden registrarse y hacer llamadas a los Subscribers.

Cada subscriber 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.

TFTP Server:

El server TFTP realiza dos funciones principales:

·         Entrega archivos de configuración de dispositivos como teléfonos o gateways, archivos binarios para el upgrade de teléfonos y de algunos gateways, y varios archivos de seguridad.

·         Generación de archivos de configuración y de seguridad. La mayoría de los archivos generados por el servicio de TFTP son firmados y en algunos casos encriptados antes de estar disponibles para ser bajados.

CTI Manager:

El CTI Manager es requerido en un clúster para aplicaciones que utilizan TAPI o JTAPI Computer Telephony Integration (CTI) actúa como un agente entre la aplicación CTI y el servicio de Call Manager. Provee autenticación de la aplicación y habilita el control o monitoreo de dispositivos autorizados. El CTI manager se habilitará en los subscribers.

IP Voice Media Streaming Application

En este diseño el IP Voice Media Streaming Application proveerá MoH y Annunciator.

·         Music on Hold (MoH): Provee música multicast o unicast a los dispositivos que están on hold, transfiriendo o siendo agregados a conferencias. Un único server soporta hasta 500 streams unicast.

·         Annunciator: Provee anuncios en lugar de enviar tonos para indicar un número marcado incorrectamente o rutas no disponibles.

·         Los recursos de Conference Bridge serán manejados por Hardware y sólo se utilizará el servicio en los Subscribers para caso de backup.

Bueno, espero que les sirva.

Herramientas de Monitoreo de Redes IP Real Time Bandwidth Monitor Solarwinds

Herramientas de Monitoreo de Redes IP

Real Time Bandwidth Monitor

Solarwinds

Una herramienta interesante y de fácil uso es Real-Time Bandwidth Monitor. Este utilitario te sirve para visualizar y resolver problemas que tengan que ver con el uso del ancho de banda en tiempo real.

Lo puedes bajar desde http://www.solarwinds.com/downloads/

Puedes monitorear múltiples interfaces de un equipo, por ejemplo monitorear aquellas interfaces que se conectan con tu proveedor de servicios Internet, o un servidor de aplicaciones en particular.

Con esta aplicación puedes ver el uso actual del ancho de banda de la interface, te lo muestra en bps y en porcentajes.

Además puedes ver el tráfico tanto entrante como saliente, puedes configurar umbrales para que te muestren en el gráfico cuando sobrepasa un cierto un ancho de banda

Bueno, excelente herramienta de uso fácil y rápido

Subscribete a nuevos contenidos

Correo Electronico 

Síguenos también en:

Facebook | Twitter | Google + | Youtube | Cursos

Cisco Unified Communications Manager 8.5 "Diseño de un Red de Telefonía IP Parte 1 Features"

Cisco Unified Communications Manager 8.5

Diseño de un Red de Telefonía IP Parte 1

Features

·         Múltiples llamadas por línea

En el CUCM pueden existir múltiples llamadas sobre la misma línea (dependiendo del modelo de teléfono). El usuario se mueve por la pantalla para ver cada una de las llamadas. Esta capacidad elimina la necesidad de crear múltiples instancias de la misma línea y aún así ser capaz de recibir o realizar múltiples llamadas sobre la misma línea. Para poder manejar fácilmente más de una llamada en una línea y poder visualizar el número llamando y el número de llamadas en la línea existe un modelo de interacción en el display del teléfono. En la configuración del número de directorio el administrador puede configurar los siguientes parámetros para múltiples llamadas o call waiting de cada línea del teléfono:

No Answer Ring Duration – Se utiliza en conjunción con Call Forward No Answer Destination para establecer la duración del ring antes de re direccionar la llamada.

Número máximo de llamadas – Se pueden configurar hasta 200 llamadas por línea sobre un dispositivo, con la limitante del modelo y el número total de llamadas configuradas para el dispositivo completo.

Call Forward No Answer – Este campo re direcciona llamadas cuando el teléfono no es contestado luego de extinguirse la duración de no answer ring.

Bussy Trigger – Este setting, que trabaja en conjunción con el número máximo de llamadas y Call Forward busy, determina el número máximo de llamadas que pueden ser presentadas en la línea.

·         Shared Line

Se puede compartir una extensión entre múltiples teléfonos. Esto permite que muchos teléfonos compartan el número de extensión y se utiliza a menudo en áreas comunes donde una llamada puede requerir que sea manejada por varias extensiones. Una llamada puesta en hold en una extensión puede ser re tomada en otra con la misma extensión sin necesidad de utilizar la softkey Resume. Con shared line no se puede realizar una nueva llamada hasta que la llamada original ha sido completada. Si puede recibir una nueva llamada en base al número máximo de llamadas configurado.

·         Caller ID y Nombre ID

Calling Line Identification (CLID), o Caller ID, provee el número llamando en las llamadas entrantes a un teléfono IP desde sitios externos o en llamadas salientes desde teléfonos IP a sitios externos. Si bien los teléfonos soportan estos features en el caso de la PSTN esto depende del contrato realizado entre el carrier y el cliente.

Calling Name Identification (CNID) es similar a CLID pero provee el nombre de quien llama entre teléfono IP.

·         Conferencias

Hay dos tipos diferentes de conferencias disponibles:

o Conferencias Ad-hoc.

o Conferencias Meet-me

Las conferencias Ad-hoc permiten a los usuarios establecer conferencias, llamar a usuarios independientemente y unirlos en una conferencia. Se inicia durante una llamada activa utilizando la softkey Confrn. El usuario que inicia la conferencia, el controller, puede agregar hasta 10 personas a una conferencia que es el máximo permitido por el sistema. Mientras haya dos personas presentes en la conferencia, la conferencia se mantiene, pero solo el controller puede agregar más usuarios a la conferencia.

Las conferencias Meet-Me permiten que el usuario marque a un número pre determinado para acceder a la conferencia. Una extensión o un rango de extensiones puede ser configurada para permitir que alguno o todos los usuarios accedan al conference bridge. La diferencia con la anterior es que el sistema controla la conferencia permitiendo a todos los componentes entrar o salir de ella.

·         Join

Join es una softkey que permite unir múltiples llamadas en una línea en una conferencia ad hoc. Este feature utilizando la softkey Join trabaja en conjunto con el feature Múltiples llamadas por línea enumerado anteriormente.

·         Transferencia

Permite a un usuario enviar una llamada a otra extensión y para ello se utiliza la softkey Transfer. Hay dos tipos de transferencias:

o Blind: Se transfiere la llamada a otra extensión y la llamada se finaliza desde el teléfono sobre el que se está realizando esta acción y así liberando la línea.

o Consultiva: Se inicia la transferencia y la llamada se pone en hold cuando se llama al destinatario de la llamada a transferir. Luego el usuario puede retomar la llamada con Resumen o presionar la softkey Transfer de nuevo y completar la transferencia.

·         Sistema de Conferencias

Existen dos tipos de servicios de conferencias disponibles dentro de CUCM: Conference bridge basados en Software y en Hardware. Todos los servidores de conferencias, que están bajo el control del CUCM, utilizan Skinny Client Control Protocol (SCCP) para comunicarse con el CUCM.

El conference bridge basado en software se provee a través del Cisco IP Media Streaming Application mientras que el basado en Hardware es provisto por PVDMs en los Gateways.

Algunos HW conference bridge soportan múltiples streams de low bit-rate como G.729,GSM o G.723. Esto permite que algunos conference bridge en HW manejen conferencias en modo mixed. En este modo el conference bridge hace transcoding de streams G.729, GSM y G.723 a G.711, los mezcla y codifica el resultado en el stream apropiado para transmitirlo al usuario.

·         Llamadas a PSTN a través de claves

Cuando se activa FAC (Forced Authorization Codes) el usuario debe ingresar un código de autorización para poder realizar la llamada. Cuando el usuario marca un número que reaquiere FAC el sistema ejecuta un tono que pide el ingreso de ese código de autorización.

Se pueden configurar varios niveles de autorización, si el código ingresado no iguala o supera el nivel de autorización de route pattern el usuario escucha un reorder tone y la llamada no es completada.

·         Call Hold

Hold permite a un usuario almacenar una llamada en su extensión. Hold y Resume son teclas que aparecen en el teléfono cuando la llamada es conectada. Esas softkey se asignan por medio del softkey template. El default contiene esas softkey.

·         Music on Hold

MoH puede ser suministrado vía unicast o multicas dependiendo del mecanismo de transporte de la infraestructura.

El origen del la MoH puede ser un archivo en el server de MoH o un audio en una tarjeta USB o en un Gateway.

Debido a que estadísticamente hay aproximadamente un 1-2% de usuarios on hold en cualquier momento en la red es importante considerar desde dónde se suministran los recursos de MoH al momento del diseño.

·         Re envío de llamadas (Call Forward)

Las llamadas que llegan a un teléfono que tiene activado Call Forward son re enviadas a un número especificado. Las llamadas pueden ser re enviadas en cuatro condiciones:

o    Call Forward All (CFA) – El administrador o el usuario pueden designar un número al cual las llamadas tienen que ser re enviadas, dependiendo de la clase de restricción que afecta al usuario.

o    Call Forward Busu (CFB) – El administrador puede designar un número al cual re enviar las llamadas cuando la línea está ocupada.

o    Call Forward No Answer (CFNA) – El administrador puede designar un número al cual las llamadas son re enviadas en el caso que no sean respondidas.

o    Call Forward on Failure (CFOF) – El administrador puede designar un número al cual las llamadas serán re enviadas cuando hay un error con el dispositivo destino.

·         Call Park

Call Park permite poner una llamada en hold y tomarla desde otro teléfono. Cuando la llamada se coloca en situación de park el sistema elige un número de un grupo reservado para este feature.

·         Call Pickup

Call Pickup y Group Call Pickup permite que los usuarios contesten llamadas presentadas a otros teléfonos que no son los suyos. El usuario puede re direccionar la llamada a su teléfono. Hay dos tipos de call pickup:

o Call Pickup: Un usuario toma la llamada de otro usuario dentro de su grupo utilizando la softkey PICKUP.

o Group call pickup: permite al usuario tomar un llamada dirigida a otro teléfono de su grupo o de otro grupo. Para ellos debe marcar el número de pickup del grupo cuando presiona la softkey GPickup.

·         Phone Templates

Un beneficio del sistema es que los botones de los teléfonos son programables. El CUCM utiliza templates para definir el número de líneas, speed dials o aplicaciones asignadas a un teléfono en particular. CUCM incluye default templates para cada modelo de Cisco IP Phone. Se pueden crear templates específicos para cubrir las necesidades puntuales de un usuario.

·         Call Back

Call Back permite recibir notificación en el teléfono cuando el destinatario desocupa su línea. Se puede activar para un destino que se encuentra dentro del clúster o en un destino remoto a través de QSIG.

·         Do not disturb

Cuando se activa la opción de Do not Disturb se desactiva el ring de una llamada pero se obtiene información de la llamada en el display y permite tomar la llamada.

·         Cisco Extensión Mobility

Cisco Extensión Mobility permite a los usuarios utilizar temporariamente otro teléfono accediendo a la configuración de su teléfono personal, por ejemplo speed dials, servicios, etc. El usuario utiliza un user y un password para acceder a su profile el cual es instalado en el teléfono en el cual el usuario está realizando el log in.

·         Manager Assistant – IPMA

Manager Assistant permite a un asistente manejar llamadas del manager, interceptar llamadas del manager y re-enviarlas apropiadamente.

·         Cisco Unified Mobility (Mobile Connect – Single Number Reach)

Mobile Connect permite los usuarios responder llamadas entrante en la extensión o en el teléfono móvil, tomar llamadas en progreso sobre la extensión o el teléfono móvil sin perder la conexión.

·         Auto Answer/Intercom

Auto Answer permite contestar automáticamente una llamada, causando que el teléfono vaya a off-hook cuando entra una llamada. Esto podría ser utilizado por un headset o un speakerphone de ciertos modelos de teléfonos.

·         Directorio

El feature Directories en los teléfonos IP provee el acceso a:

o Directorio Corporativo

o Llamadas perdidas

o Llamadas realizadas

o Llamadas recibidas

o Directorio Personal

Desde cualquiera de esos directorios, el usuario podría iniciar una llamada al número presionando la softkey Dial. También se puede editar el número antes de realizar la llamada.

·         Directorio Personal

El Cisco IP Phone Address Book Synchronizer permite sincronizar el directorio del outlook. En ciertos modelos de teléfonos se puede usar el servicio XML Personal Address Book para buscar entradas, seleccionar y presionar el softkey Dial.

Luego seguiremos con la siguiente parte del curso de diseño de Callmanager