Extend and connect

Estamos hablando probablemente de la funcion mas potente de un sistema Cisco de comunicaciones unificadas. Nos permite utilizar cualquier teléfono fijo o movil, como si fuera el teléfono que tenemos sobre nuestra mesa de trabajo en la oficina.

Imaginemos un ejecutivo que está en casa de un cuñado, y quiere usar el fijo del cuñado como si fuera su teléfono de empresa. Abre su portatil en el que tiene cargado jabber para windows, se conecta a la red corporativa de su empresa a traves de la wifi de su cuñado con cualquier programa de tunelado que tienen todas las empresas y busca en la esquina inferior derecha de la aplicación jabber el icono del teléfono, que al pinchar despliega un menú en el que aparecerá "usar otro número para las llamadas".
Ahí es donde pone el número publico del teléfono que va  a usar, su movil, por ejemplo, o el fijo del cuñado.
A partir de ese momento podrá hacer llamadas desde la ventana de marcado de jabber, y el sistema generará una llamada hacia el número marcado y otra hacia el teléfono del cuñado, y las unirá.
Tambien recibirá en el teléfono del cuñado las llamadas dirigidas a su extensión. Y podrá utilizar las funciones propias del sistema, retener, conferencia, etc.

Además las llamadas se identificarán como si estuviese en la oficina.

ESQUEMA DE FUNCIONAMIENTO (LLAMADA SALIENTE):

Llamada saliente: primero elegimos en jabber el fijo del cuñado para usarlo como propio

Marcamos en jabber el nº de destino: la llamada se establece.

Vamos a ver como se configura, nuestro escenario es CUCM y Presence en 9.1:
(Esta funcionalidad no es posible en versiones anteriores)

• Crear un dispositivo "CTI Remote Device" para ese usuario

Seleccionamos device > add new
Creamos uno del tipo : "CTI Remote device"
Lo asociamos con el usuario (En la casilla owner user ID)
Le damos un nombre, por ejemplo CTIRDuserid
Le ponemos un CSS que le permita hacer llamadas en "rerouting calling search space".
Le añadimos un número de directorio, el nº de la extensión del teléfono principal del usuario.
Asociamos el número de directorio con el usuario.
Comprobaremos que el dispositivo queda registrado contra el call manager

En este dispositivo añadimos un destino remoto, que el usuario podrá editar libremente desde la aplicación jabber windows.
En la sección "Associated remote destinations", añadir un destino que tiene que llamarse JabberRD
Le ponemos un número público de destino.

• Configurar el usuario: Ir al "end user" que vamos a configurar

Marcar "Enable mobility"
Asociarlo a los grupos:
      Standard CCM End-Users
      Standard CTI Enabled

Añadir el CTI que hemos creado como dispositivo asociado.

• En el presence server, crear un CCMCIP profile:

Atencion: al abrir la página web dice que sólo hay que hacerlo en versiones 8.x. Es mentira, si no configurais esto, no funciona.

Seleccionar application > Legacy clients > CCMCIP profile > add new 
Creamos un profile con las direcciones IP de los call manager que van a cursar las llamadas.
Añadimos los usuarios al profile.

Con esto ya debe funcionar. Tener en cuentar que los servicios de CTI deben estar habilitados en los servidores, y que tras crear el dispositivo CTI hay que dar el apply config.

Un detalle final: normalmente cuando hacemos llamadas desde el teléfono fijo, anteponemos un código de escape. Normalmente un cero.
Esto no es elegante cuando estamos fuera del ambito de la empres o utilizamos aplicaciones.
Por eso configuraremos las application dial rules para que se enruten las llamadas marcando directamente.
Trataremos el tema en un próximo post.


Añadido el 25/04/2016
LIMITACIONES de Extend And Connect.
Simplemente indicar que Extend and Connect no funciona a través de Expressway, es decir, si tenemos un Jabber en PC y nos conectamos o validamos al sistema de comunicaciones unificadas mediante un Expressway (vía Internet), este no permite utilizar dispositivos CTIRD como dispositivos de llamada. Desconocemos si en futuras versiones de Expressway Cisco cambiará algo pero de momento (estamos en la versión X8.5 de Expressway) no es posible. 

Configuración de un SIP Trunk de Cisco (Intercluster) con MTPs

La configuración de un Intercluster (ICT) entre dos servidores de llamadas de Cisco no suele presentar ningún tipo de dificultad (o al menos eso dice la teoría) salvo por problemas propios del enrutamiento. Se configura la parte de trunk entre ambos extremos con los datos de IP y, quitando la señalización, las comunicaciones una vez establecidas entre ambos clusters (flujos RTP) discurren por la red de datos entre los extremos finales.

¿Pero qué ocurre cuando por el motivo que sea (protección, seguridad, política,…) no se permite que se vean los extremos finales a nivel de IP? En este caso hay que dejar que todas las comunicaciones discurran a través de los equipos de red e incluso que los flujos RTP tengan otros actores que no son única y exclusivamente los extremos finales de la comunicación, por lo que será preciso habilitar MTP’s como pasarela en la configuración del trunk e incluso configurar reglas de permisos en los equipos de red de ambos extremos.

Imaginemos un escenario de conectividad entre clusters por medio de una red que implementa también equipos de protección perimetral (tipo firewall). En este caso hay que permitir en los equipos de red las comunicaciones entre todos los equipos que intervienen en la señalización (servidores de llamadas) y los equipos que van a gestionar los flujos RTP (por ejemplo gateways con DSPs hardware).

También es necesario asociar los recursos hardware correspondientes (MTP) al dispositivo (ICT) mediante la configuración correcta del MRGL (Media Resource Group List) y habilitar MTP en la configuración del ICT.

Así conseguimos que los MTP’s hagan su función de pasarela en ambos extremos teniendo los flujos de RTP de la siguiente forma:

Term.IP.1 <----> MTP.1 <----> MTP.2 <----> Term.IP.2

En este tipo de escenario, sobre todo con firewalls intermedios  o soluciones con NAT, se recomienda que se active el modo duplex para los flujos de voz  (variable “Duplex Streaming Enabled” dentro de los parámetros de servicio del servicio Call Manager). Con esta variable habilitada se evitan problemas de fonía de la MoH.

Cuidado! Cambiar la IP de Contact Center invalida las licencias

Recientemente tuve que cambiar la máscara del los Contact Center CCX de un cliente. Puede hacerse desde el interfaz web del CCX en el apartado OS Administration > System > IP > Ethernet, pero no me funcionó porque estaba activado el failover del interfaz Ethernet. El failover permite la redundancia de los puertos Ethernet del servidor.

En este caso no hay más remedio que conectarse por ssh y hacerlo en modo consola:

ssh –l CRSAdministrator 10.X.Y.Z
set network failover dis
set network ip eth0 10.X.Y.Z 255.255.248.0
set network failover ena

El cambio de dirección IP o máscara provoca un reinicio del servidor.

Si haces el reinicio desde el interfaz web te avisa de que las licencias dejarán de ser válidas y que tendrás un periodo de gracia de 30 dias para cargar las nuevas. Esto suele ocurrir si trabajas con servidores virtualizados, pero en mi caso eran servidores dedicados.

Al logarse tras el reinicio te avisa de que está con licencias temporales. Abrí un caso a Cisco pidiendo nuevas licencias con la MAC que puedes encontrar en OS Administration > Show > System. Hay que distinguir entre la MAC del servidor y la "License MAC", que no coinciden. Ya os podéis imaginar por qué insisto en este punto.

Cargué las licencias y me dio unos mensajes de error sobre licencias duplicadas.

No hay motivo de alarma, aunque sí de confusión. Al cerrar y abrir de nuevo la sesión comprobé que el mensaje de licencias temporales había desaparecido.



PS. Debí haber leído antes la información de Cisco en la web de licencias...

The Unified CCX system uses a new licensing mechanism. The licenses are based on a string called the License MAC which is different from the Physical MAC address of a system.
The License MAC string is generated during installation and is based on various input fields, such as the hostname, IP address, etc.
If any of these fields change after fresh installation, the License MAC will become invalid and you must request new license(s).
You can generate the License MAC in one of the following ways.
Obtain License MAC after installing Unified CCX
Obtain License MAC before installing Unified CCX
To obtain License MAC after installing Unified CCX:
License MAC will be displayed during system install. You must make a note of this for ordering license files. To obtain License MAC after installing Unified CCX, complete the following steps:
Step 1: Log in to the Unified CCX system command line interface (CLI) using Unified CCX Administrator credentials.
Step 2: Run ?show status? command. Output of this command contains the License MAC.Obtain License MAC before installing Unified CCX.
To obtain License MAC prior to installing Unified CCX:
Step 1: Go to the answer file generation Web site. http://www.cisco.com/web/cuc_afg/index.html
Step 2: Select Cisco Unified CCX from Product Options.
Step 3: Fill in all the configuration information used for installation, such as IP address, hostname, and more on that site. Answer file generated from this can be used for unattended Unified CCX installation. You can also use this answer file to generate the License MAC (based on given parameters) so you can order the license prior to building the machine.
Step 4: Once the answer file is generated, this page enables you to obtain the License MAC. Caution: If you change any of the parameters or configuration information after ordering the license, License MAC will be changed and the ordered license file may become invalid.
By submitting this form, you are acknowledging that you have read the End-User License Agreement, of which this Registration Form is a part "Agreement", and that you understand it and agree to be bound by its terms and conditions. You further agree that the Agreement is the complete and exclusive statement of the Agreement between the parties, and supersedes all proposals or prior agreements, oral or written, and all other communications between the parties relating to the subject matter of the Agreement.

Integración Active Directory (AD) con CUCM (CallManager)

Pues eso, voy a estrenarme con el siguiente post e intentar aportar mi granito de arena. ;)

Hablaremos de como crear un Active Directory (AD) con su LDAP en Win2003 Server con sus usuario, y éstos puedan acceder al dominio dentro de sus PCs (Windows XP) y luego integrarlo con nuestro querido cacharro CUCM (CallManager).

Lo primero de todo, instalar el AD. Debemos ejecutar dcpromo en el RUN de Windows y como casi todo en este mundo Microsoft...siguiente-siguiente, donde tenemos que seleccionar primero, Domain controller for a new domain, luego Domain in a new forest, y luego introducimos el nombre al dominio NetBios. A continuación, aparecerá varias ventanas en referente a la localización de varios ficheros, tanto de Log como de Database y Sysvol, lo dejamos todo por defecto y siguiente x2.  Cuando nos salga la venta de DNS Registration Diagnostic, debemos de estar atento de seleccionar la segunda opción, sino la liamos, interesa que los usuarios internos entren en sus PCs con nuestro dominio y para ello debe responder al DNS creado, cada usuario en su PC deberá configurar su Network apuntando a este DNS.

Seguimos con lo nuestro, y ahora toca decirle que el AD que  solo sea compatible con Win2000 y Win2003 (cosas de Microsoft), asignamos password al Administrador y listo. Instalado el AD.

Ahora toca crear los usuarios, también facilito. Vamos a Administrative Tools-Active Directory Users and Computers. Una vez allí, creamos Unidades Organizativas, si os apetece (a mi me gusta todo organizadito), y dentro de cada una creamos los usuarios. Nos pedirá crear los usuarios con contraseñas bastante pesaditas (letras-números-símbolos). También he creado un grupo de seguridad llamado novatos , y me ha quedado así:

Para comprobar que los usuarios y que el AD funciona correctamente, vamos a un PC, y probamos que entramos al dominio creado. Vamos a Propiedades del Sistema-Cambiar nombre de equipo o unirse a dominio, cambiamos dominio e introducimos el usuario y contraseña:

Nos dará la bienvenida al dominio, reiniciamos y listos, ya estaríamos dentro de nuestro dominio.

Ahora toca la integración con el CUCM (CallManager), vamos allá.

Recomiendo usar la siguiente herramienta, ya que queda bien claro cual es el índice de cada uno de los usuarios y su estructura (Domain Name o DN). Es necesario saber la cadena BASE DN y usaremos la herramienta ldp.exe. He tenido que introducir el CD del WinServer2003, que contiene utilidades (entre las que está ldp.exe). Extraer dicha utilidad que está en el archivo SUPPORT.CAB del directorio \SUPPORT\TOOLS. Ejecutarlo y en el menú Connection elegir Connect y escribimos nuestro Server (nuestro caso xxxx.local) y el puerto 389. Y este es el resultado:

Ahora vamos a nuestro CUCM, y activaremos el servicio Cisco DirSync, ya que por defecto está deshabilitado, en CUCM Serviceability > Tools > Service Activation y Cisco DirSync y le hacemos check. A continuación vamos a Cisco Unified CM Administration > System > LDAP > LDAP System y seleccionamos Microsoft Active Directory y  sAMAccountName, que se refiere para el login del dominio.

Seguimos con System > LDAP > LDAP Directory y "click" a Add New. Y rellenamos con lo siguiente:

El primer atributo, ponemos el nombre que queremos que se llame en el CUCM. En el LDAP Manager DN, se pone el usuario con el cual se hará la consulta, podemos meter el "chorro" entero del DN del usuario o si lo mentemos al estilo usuario@dominio, yo he preferido este último. Luego en el LDAP User Search Base, ponemos el DC (Domain Component), por eso la recomendación de usar la herramienta ldp.exe. Seleccionamos Perform Sync Just Once, y más abajo introducimos la IP de nuestro servidor de AD (ldap) y su puerto, por defecto, LDAP trabaja con el 389.

Por último vamos a System > LDAP > LDAP Authentication. Y rellenamos los datos, esto autenticará el CUCM End Users usando AD.

Una vez esto volvemos a LDAP Directory, seleccionamos nuestro LDAP, y le damos a Perform Full Sync Now, y se empezará a sincronizar.

....y con esto y un bizcocho, tenemos los usuario del AD en el CUCM:

Actualizar version de CIMC (Instalar un UCS 220M3 parte 2)

Entre las mejores prácticas (Best practices) de Cisco se cuenta la de tener las cosas actualizadas a la última versión.
Se supone que la última versión de cada producto subsana muchos de los errores conocidos. El fabricante les llama bugs, nosotros les llamamos pufos. Además, ¡que leches!,  nos gusta estar a la última.
 
Hemos recibido el UCS con el CIMC en versión 1.5.1b y vamos a actualizarlo a la 1.5.(1f).
Hablando de pufos: La versión 1.5(1b) no te permitirá lanzar una consola KVM salvo que el PC desde el que trabajes tenga el sistema operativo en inglés. Además recuerda que hay que tener el java actualizado.

La actualización se hace con una aplicación proporcionada por Cisco que se llama huu (Host Upgrade Utility) que actualmente tiene una presentación gráfica y amigable.

Se descarga de: Servers-Unified Computing > Cisco UCS C-series Rack-Mount Standalone Server Software> Cisco UCS C220 M3 Rack Server Software > Unified Computing System (UCS) Server Firmware-1.5(1f) y se llama ucs-c220-huu-1.5.1f.iso
(Dios, acabo de ver que en Cisco ya está la 1.5.(1j))


El servidor, aunque viene con el CIMC en versión 1.5.(1b) corriendo, tiene tambien el huu con una versión en backup, en nuestro caso la 1.4(7h). Esta versión está en una tarjeta que llama flexflash, de la que ya hablaremos.

Actualización sencilla, de una de las dos formas siguientes:

• Conectarnos con un PC inglés y lanzar una consola KVM. Desde ella en la pestaña virtual media montar la huu y volviendo al CIMC lanzar un power cycle. Cuando arranque el servidor pulsamos F6 para elegir arrancar desde (Cisco vKVM-Mapped) que es donde hemos montado el huu.
• Lanzar un power cycle directamente, pulsar F6 en el arranque y elegir inicio desde la huu que hay de backup. Instalamos la version 1.4.7. Con esta versión siguiendo el método del punto anterior no será necesario el PC en inglés para pasar a la versión 1.5.1f.

Pantalla de arranque

Pantalla del huu CONSIDERACIONES IMPORTANTES: Se resetea todo el servidor. Si se hace en máquinas en producción se interrumpe totalmente el servicio. No actualizar solo el CIMC. Hay que actualizar todo, la BIOS y todo lo demás. Best Practices.

Instalar un UCS 220 M3 (parte 1)

Lo dicho, vamos a instalar un UCS 220 M3. (En realidad instalaremos dos)
El objetivo final es la constitución de un cluster de comunicaciones Cisco, con 2 Call Manager (publisher y suscriber), un Unity conection y un Presence server.

En un servidor UCS irán el publisher y el unity, y en otro el suscriber y el presence. Todos ellos virtualizados.

Vamos poco a poco.

LA MECÁNICA:

El UCS es enracable en un armario de 19" y tiene una altura de una unidad, pero atención, es muy profundo.  Tiene 72,5 cms de fondo, que contando con el retranqueo que siempre hay en las guias de fijacion delanteras y el espacio trasero para enchufes nos va a obligar a tener un armario de al menos 800 mm.
Ventila por encima y por detrás. Lleva equipadas 1 ó 2 fuentes redundadas de 650watt, que pueden sacarse en caliente sin problemas.
Es muy ruidoso, como todos estos cacharros. No está pensado para convivir con el.
Discos duros: según se compre, hasta 8. Situados en el frente y extraibles facilmente.

Trae una guias para enracado con un diseño bastante bueno. Se instala en el armario en 5 minutos y sin herramientas de ningún tipo. No es necesario leer las intrucciones. Toquiteando lo ves enseguida.

Hablando de instrucciones de instalación, en la caja viene un pequeño manual en inglés que no está mal. Tipo sábana.
Lo hemos escaneado y subido a la siguiente dirección:

 https://www.box.com/s/urywsrsc9esuj5sco31k
 
En la caja hay tambien un cable especial de Cisco, que por un lado se conecta al frontal de la maquina y por el otro nos entrega 3 conectores para poner un monitor, teclado y ratón. No es necesario porque podemos conectarlos en la trasera de la máquina.

EL CIMC:

Cisco Integrated Management Controller, en adelante CIMC.
Es una especie de Alien siempre vivo. Es una aplicación que permite controlar el servidor, incluso aunque esté parado. Nuestra primera referencia cuando instalamos la máquina.
En la trasera del servidor tenemos como equipamiento base un puerto fastethernet y 2 puertos Gigabit con redundancia.  En nuestro caso, cada UCS lleva tambien una placa adicional con 4 puertos Gigabit. Ya veremos el uso.

Conectamos monitor, teclado, ratón y enchufamos. Tendremos una pantalla de arranque en la que damos F8 para acceder a la configuración del CIMC. La pantalla que nos presenta es como la siguiente:

 Por defecto viene marcado Shared LOM, que quiere decir que el CIMC está conectado a los puertos Gigabit. Nosotros marcaremos "dedicated" para que en vez de los puertos Gigabit, responda en el  puerto Fastethernet. Este puerto solo servira para acceder al CIMC.
Introducimos IP, máscara y GW. Salvamos.

A partir de ese momento, podemos conectarnos al puerto Fastethernet con un PC y abrir un navegador apuntando a la dirección IP que pusimos en la pantalla de configuración. Ahí tendremos a nuestro agente secreto, el CIMC.
La apariencia se ve en la siguiente imagen:

Desde el CIMC puede gestionarse la máquina sin perder nunca conectividad. Encenderla, apagarla, ver los discos, establecer las prioridades de inicio, etc.etc.
Tiene un usuario por defecto que es "admin" y un password que es "password". Ingenioso ¿verdad?
Podemos cambiarlos i/o poner otros nuevos.
Hay otras mariconadillas que pueden verse/gestionarse desde el CIMC pero te dejamos que las descubras por tí mismo.

Podremos lanzar una consola KVM. Nos abrirá en nuestro PC una ventana emergente en la que tendremos 2 cosas en 2 pestañas diferentes:

• Una pestaña con la imagen que se ve en el monitor conectado en local.
• Una pestaña "virtual media", en la que podemos montar dispositivos. 

Importante: Hay que cerrar las sesiones de CIMC pulsando "Log out". Si no lo hacemos se quedan las sesiones abiertas y el máximo son 4. Si se alcanza dicho nº ya no nos podremos conectar (de momento)

Importante:   En el PC local hay que tener una versión actual de Java. En otro caso no funciona.
El CIMC tiene versión. En nuestro caso venía con la 1.5b. Peligro!!! Con esta versión solo puedes abrir la consola KVM si tu PC tiene el sistema operativo en inglés.



Lo primero será cambiar la versión del CIMC y de la BIOS del servidor. Lo veremos en el siguiente post.

La telefonía ha cambiado

Hoy inauguramos este blog, que será en un futuro mas o menos inmediato un referente obligado de la telefonía Cisco.

Experiencia no nos falta.

Cuando empezamos, la telefonía fija y la telefonía movil se resumían en las dos imágenes añadidas.

Pero nos hemos reciclado.

No hablaremos aquí de repartidores, ni cámaras de registro, ni lineas aereas, ni sistemas telegráficos.

Este es un blog en español sobre comunicaciones unificadas Cisco.

PRÓXIMO CAPÍTULO: INSTALACIÓN DE UN UCS 220 M3 

Con 2 cojones.