el
05-15-2019
01:07 PM
- fecha de última edición
05-30-2019
10:38 AM
por
Hilda Arteaga
Aclare todas sus dudas acerca de las mejores prácticas para configurar e implementar Cisco Unified Communications Manager (CUCUM). La sesión abarca las mejores prácticas en las distintas funciones de esta solución, desde la administración del plan de marcación, la mensajería unificada, la mensajería instantánea, el registro de teléfonos y la integración para end points de video, hasta los expressway entre otros.
Haga sus preguntas del 20 de Mayo al 7 de Junio del 2019.
Detalles de la Especialista
Jessica Alcántara trabaja como líder del equipo de Tecnologías de Colaboración en ISAT Telecomunicaciones en México. Tiene 16 años de experiencia en troubleshooting e implementación de soluciones de Colaboración, particularmente Communications Manager, Unity Connection, Presence y Gateways de Voz. Antes de desempeñarse como ingeniero de implementaciones trabajó con un Learning Partner como entrenador certificado de Cisco. Jessica es egresada del Instituto Tecnológico y de Estudios Superiores de Monterrey de la carrera de Ingeniería en Electrónica y Comunicaciones. Cuenta con las certificaciones CCNA y CCNP de R&S y CCNP de Collaboration.
Jessica puede no lograr responder a todas las preguntas, debido al volumen esperado durante este evento. Recuerde que también puede hacer sus preguntas en nuestra categoría de Colaboración, Voz y Video https://community.cisco.com/t5/colaboraci%C3%B3n-voz-y-video/ct-p/5461-colaboracion-voz-video
** ¡Los puntos de utilidad fomentan la participación! **
Por favor asegúrese de dar uno a las respuestas a sus preguntas.
el 05-20-2019 01:03 PM
Hola Jessica!
Hay ciertos elementos bastante conocidos como usar FQDNs, Device Pools, CSS, usar E.164 de ser posible, No usar nuestro Publisher como procesador de llamadas de no ser necesario, entre otras.
Mi pregunta es: ¿Qué otro tipo de elemento consideras indispensable en cualquier instalación de CUCM?
>>>>>>>>>
Aprovechando la oportunidad, respecto a E-CAC... al final del día es un modelo de nuestra red, pero con tantos enlaces LAN/WAN, protocolos de enrutamiento y otras variables... ¿Qué tan recomendado es utilizarlo sabiendo que no se adapta a los cambios en la red ocurridos por fallas?
Gracias
Rolando A. Valenzuela
el 05-20-2019 10:08 PM
Muchas gracias por tu pregunta, considero que lo más importante es tener en mente
cómo funcionará el sistema en caso de una falla y diseñar una configuración
que nos permita ofrecer redundancia. Por ejemplo, contar con Callmanager Groups
que tengan capacidad para soportar la carga completa de teléfonos en caso de falla
considerando su CPU, volumen máximo de llamadas,etc. Otro ejemplo sería configurar una
estructura de Route List, Route Groups y Gateways que nos permita tener una ruta
alterna de comunicación a la PSTN si llegara a fallar el enlace principal.
En caso de tener oficinas remotas, pensar ¿El gateway local tiene capacidad de
dar el servicio de SRST a todos los teléfonos si se pierde el enlace al sitio
central? ¿Cuénta con una configuración adecuada para que la operación continue?
Planear los posibles escenarios de falla nos permitirá tener una red más estable y también
podremos predecir su conducta si se presenta algún problema.
Respecto a E-CAC, aunque es un modelo y no se adaptará a fallas, nos permite generar un
modelo más apegado a la realidad y más eficiente para controlar el volumen de llamadas, principalmente en el caso de topologías de red que no
son centralizadas, es decir, que hay sucursales conectadas atrás de otras sucursales.
Por ejemplo :
Oficina A-----128Kbps------Oficina B-----128Kbps-----Sitio Central.
Un CAC tradicional no sería capaz de representar esta topologia dado que considera que todas
las oficinas están conectadas directamente al sitio central.¿Cuál es el problema?
Una llamada de A al sitio central va a consumir ancho de banda tanto en el enlace de A como
en el de B, pero el CAC tradicional no considerará el consumo de ancho de banda en B, lo que puede
causar que se sature el ancho de banda de la oficina B. En el caso de E-CAC si
habrá visibilidad de esta topologia y hará la deducción de ancho de banda de ambos sitos.
E-CAC también es importante cuando realizamos comunicación interclusters,porque permite
a ambos clusters controlar el volumen de llamadas entre ellos, sin E-CAC no tendríamos
visibilidad ni control consumo de ancho de banda entre clusters independientes. La configuración
de Shadow Location nos ayuda a resolver esta necesidad.
Este URL puede servirte de referencia,
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/9_0_1/ccmfeat/CUCM_BK_CEF0C471_00_cucm-features-services-guide-90/CUCM_BK_CEF0C471_00_cucm-features-services-guide-90_chapter_0101101.html
Saludos !!
el 05-21-2019 06:41 AM
el 05-28-2019 10:05 PM
Al contrario Rolando, gracias a ti por participar, saludos!
el 05-23-2019 09:12 AM
Hola Jessica
Tengo una duda ¿cuál es la mejor práctica para monitorear, hacer track y visualizar a los usuarios de teléfono que continuamente pierden su registro y posteriormente el “self heals” solo para repetir el ciclo después en un intervalo non-cyclical?
Gracias por la oportunidad
el 05-27-2019 09:28 AM
Hola Adolfo,
Muchas gracias por enviar tu pregunta, hay dos muy buenos lugares para identificar la razón de desconexión de un teléfono, el primero, son los logs del teléfono directamente, mismos que puedes ver si haces click en la IP del teléfono. En la página del teléfono puedes revisar la sección de Status Messages para identificar eventos en general que le han ocurrido al teléfono y los Console Logs, que te pueden dar una buena referencia de la razón de desconexión desde el punto de vista del teléfono, como errores de DHCP por ejemplo.
Otra herramienta muy útil es el Real Time Monitoring Tool, en la sección System-> Tools ->Syslog viewer . Después selecciona el nodo de CUCM donde está registrado el teléfono y busca en el folder Applications Logs->Archive-> Alternate Log
En ese log podrás identificar la razón de desconexión con la MAC address del dispositivo, hay mensajes de este tipo
%[DeviceName=SEP0016474AE000][ReasonCode=8]
Y del lado derecho te explica la razón del reason code, con esta información, tendrás una mejor referencia respecto al porqué la desconexión del teléfono.
Gracias por participar en el foro y si hay algo más en lo que pueda apoyarte avísame.
el 05-26-2019 01:35 AM
Las soluciones estándar de Standard HDLC y Cisco HDLC varían de muchas maneras, y personalmente las veo como dos entidades separadas. Mi pregunta es tu los clasificaría como dos protocolos de encapsulación WAN separados, ¿sí / no?
el 05-27-2019 10:51 AM
Muchas gracias por tu excelente pregunta, personalmente y en un sentido teórico no los clasificaría como protocolos separados debido a que son de la misma familia, Cisco HDLC es una extensión de HDLC Standard. La extensión de cHDLC inlcuye soporte multiprotocolo, citando el libro T1 Survival Guide de M.Gast, “cHDLC es un frame de HDLC con un código de Tipo de Ethernet para identificar el protocolo de red que lleva el frame”
https://www.oreilly.com/library/view/t1-a-survival/0596001274/ch08s03.html
Ahora, en un sentido práctico, es crucial saber con qué tipo de HDCL estamos lidiando si estamos conectando equipos que no sean Cisco y tengan una implementación de HDLC diferente; dado que no se podrán comunicar debido a diferencias en la construcción del frame.
Espero haber contestado tu pregunta, saludos.
el 05-26-2019 04:01 AM
Hola!! Recientemente adquirí unos teléfonos IP cisco modelo CP8841, lamentablemente no he podido configurarlos en mi central Asterisk a través del protocolo SIP, mi pregunta: Que requiero de la gama de productos de CISCO para poner en funcionamiento mis teléfonos ?? me gustaría migrar mi plataforma de telefonía a CISCO. Gracias!!
el 05-27-2019 09:46 AM
Saludos,
Gracias por enviar tu pregunta, el equipo Cisco que necesitas depende de varios factores, como la cantidad de teléfonos que vayas a registrar en él , la distribución de los mismos, por ejemplo, si están en diferentes oficinas y se conectan a un sitio central o si están todos juntos y qué funciones adicionales necesites (buzón de voz, chat, etc).
Para empresas medianas existe la solución de Callmanager Express que soporta hasta 450 dispositivos y se instala en un ruteador Cisco.
Otra opción que puedes considerar es Business Edition 6000 que soporta hasta 1000 dispositivos y tiene capacidad para funciones más avanzadas.
También hay soluciones que funcionan en la nube que pueden ser muy buena opción dependiendo de tus necesidades.
En todos las opciones que te menciono, están soportados los teléfonos 8841.
Espero que la información te sea de utilidad, saludos.
el 05-27-2019 10:51 AM
Hola Jessica,
Mis preguntas son un tanto básicas que espero por favor me puedas apoyar contestando.
Cuáles con las mejores prácticas de seguridad a implementar en la instalación de un Cisco Integrated Management Controller con todo lo que conlleva, CUCM, CUC, Presences?
Por otro lado, cuando ya se tiene un ambiente completo en producción como el que mencioné arriba, cuáles son las mejores prácticas para comenzar a administrar las distintas soluciones?
En un ambiente de producción donde en un comienzo no se considero la seguridad como algo importante, qué medidas se pueden adoptar? Me refiero por ejemplo a que en los teléfonos no tengo ninguna restricción para ver la información del teléfono tales como IP, DG, DNS, etc.
----
En el escenario de que quiero llevarme mi teléfono físico (Cisco IP Phone 8811) a mi casa para trabajar con él, cuáles son las mejores prácticas de implementación del servicio y qué debo tomar en cuenta para la seguridad?
Si cuentas con documentos a los que pueda acceder para todo esto te lo voy a agradecer.
Muchas gracias. Saludos!
el 05-28-2019 10:02 PM
Hola, gracias por participar en el foro. Respecto a las mejoras prácticas de seguridad, el documento que puedes revisar es la Security Guide de CUCM (de la versión de CUCM que estés utilizando)
Otra excelente referencia es el SRND de Colaboración, te comparto este documento como ejemplo de la versión 11.
Ahí puedes encontrar recomendaciones sobre las mejoras prácticas para configuración y administración de toda la solución de colaboración e.g. gateways, QoS, mensajes de voz así como de seguridad en los diferentes componentes de la solución de colaboración, desde los switches hasta los servidores ¿Por qué diferentes componentes? Hay muchos puntos de seguridad que se deben considerar e involucran a la red, teléfonos, servidores, etc, es necesario implementar una política de seguridad para cada componente de la red.
Para Unity Connection también te puede ser útil la Guía de Seguridad
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/11x/security/b_11xcucsecx.html
Para el punto en concreto respecto a la información visible desde los teléfonos se puede modificar en la página del teléfono en la sección de Product Specific Configuration Layout (es la última sección en la configuración de un teléfono) y cambiar el parámetro Settings Access a Restricted, con este cambio, el botón de settings solo permitirá que se cambien preferencia de usuario y volumen, los parámetros de red ya no serán accesibles.
Finalmente, en los dos primeros documentos también hay una sección que describe la operación de clientes de VPN en teléfonos IP, para este requerimiento en particular es importante en primera instancia, configurar los parámetros de VPN y aprovisionar y configurar el teléfono en la red interna antes de tratar de hacer la conexión del teléfono 8811 desde tu casa.
Espero que esta información te ayude, ¡Saludos!
el 06-04-2019 11:46 AM
Buenas tardes.
Cual seria la mejor práctica cuando tengo un diseño de un cluster centralizado y N numero de sitios en SRST, especificamente para Unity Connection, es decir, cuando tengo una interrupción con el sitio central y los dispositivos se tienen que registrar en modo de supervivencia en el GW, como puedo mantener la operación de la operadora automática (Call Handlers) ??
Saludos
el 06-05-2019 12:04 PM
Buenas tardes, gracias por tu pregunta, hay varias opciones para poder brindar servicio de auto attendant en ese escenario. Si no necesitas que el servicio de voicemail esté centralizado, es factible utilizar el módulo para virtualizar Unity Express de manera independiente y conectado al Callmanager Central. En este tipo de escenario, se puede hacer la configuración de un dial-peer con menor prioridad en el gateway que permita la comunicación con el Unity Express para que el servicio de auto attendant continúe funcionando a pesar de no tener comunicación con el sitio central.
Otra opción es configurar una aplicación de TCL en el gateway.
Esta solución tiene opciones muy limitadas de configuración, pero para fines de supervivencia, te permite que se escuche un audio y se transfiera la llamada a una extensión interna.
Te comparto estos documentos, para una referencia más detallada.
Cisco Unity Express Voicemail and Auto Attendant https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/unity_exp/administrator/AA_and_VM/guide/vmadmin_book.html
Cisco Unified CME B-ACD and TCl Call-Handling Applications
En el caso de que también les interesen opciones de redundancia donde lo más crítico sea conservar voicemail puedes revisar los siguientes URLS.
Unity Connection Design Guide (sección Survivable Remote Site Voicemail)
Complete Reference Guide for Cisco Unity Connection Survible Remote Site (SRSV) (puntos importantes a revisar son la compatibilidad de los módulos con el gateway y los alcances de operación que tiene el modo
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/11x/srsv/guide/b_11xcucsrsvx.html
Saludos !
Descubra y salve sus notas favoritas. Vuelva a encontrar las respuestas de los expertos, guías paso a paso, temas recientes y mucho más.
¿Es nuevo por aquí? Empiece con estos tips. Cómo usar la comunidad Guía para nuevos miembros
Navegue y encuentre contenido personalizado de la comunidad