Microsoft Lync Server
Header

Otra de las novedades de Lync 2013 es la posibilidad de controlar que números de teléfono vamos a permitir en los desvíos o simultaniedad de llamadas en el cliente Lync:

desvio_llamadas_Lync_1.jpg
Como vemos tenemos varias posibilidades que detallaré a continuación:
  • Distribuir con los usos de la RTC de llamadas: el desvío de llamadas a números externos (móvil, trabajo y otros) en función de la configuración de los usos de RTC configurados
  • Distribuir solo a usuarios internos de Lync: permite que configuremos el desvio de llamadas o la simultaniedad únicamente a usuarios de Lync de nuestra organización
  • Distribuir con los usuarios de la RTC personalizados: podemos configurar un nuevo Uso de RTC personalizado que se aplicará únicamente a esta Directiva de Voz cuando los usuarios hayan configurado el desvión de llamadas

La única personalización que tenemos disponibles como  exclusiva es la de Distribuir con los usuarios de la RTC personalizados, una vez que hemos elegido esta opción se nos habilita la opción de agregar usos de RTC que previamente teniamos configurados o los podemos crear en este mismo instante.

desvio_llamadas_Lync_2.jpg

Por lo que podríamos configurar un uso de RTC que no permita llamar a números móviles, internacionacionales, nacionales, etc… esto ya es cuestión de cada cual. Por ejemplo voy a configurar que no se puedan marcar numeraciones de los teléfonos internos de la empresa (20X). Para ello pulsamos en Agregar y escribimos una descripción y luego volvemos a pulsar en Agregar para añadir rutas asociadas

desvio_llamadas_Lync_3.jpg

En las rutas solo voy a añadir las rutas que voy a permitir, vamos los dígitos iniciales permitidos y porque troncal se cursarán estas llamadas desviadas

desvio_llamadas_Lync_4.jpg

Si queremos probar que realmente no podrá marcar las extensiones 20X podemos probarlo desde la opción de test que tenemos disponible:

1. Si escribimos el número de alguna extensión veremos que no tenemos expresión para el por lo que no se cursará la llamada

desvio_llamadas_Lync_5.jpg

2. Si escribimos un número que comience por +34 o 34 veremos que si tiene expresión y tratará de cursar la llamada. Yo he puesto algo que no tiene sentido, el +34 y el número de extensión y asi os veréis que si podría marcarlo pero con las reglas de normalización al formato E.164 en el plan de marcado ya no permitirá la llamada puesto que espera 9 dígitos no 5. Si por cualquier motivo queremos evitar esto para no confundirnos podemos agregar a los dígitos iniciales otro número más, por ejemplo el primer dígito del código de área: +349. De esta forma evitamos este comportamiento que tal vez pueda confundirnos

desvio_llamadas_Lync_6.jpg

Ahora guardamos esta configuración de Ruta

desvio_llamadas_Lync_7.jpg
Y ya tenemos configurado nuestro desvío de llamadas personalizado

desvio_llamadas_Lync_8.jpg

Ahora únicamente nos queda Confirmar los cambios

desvio_llamadas_Lync_9.jpg

nos muestra los valores de configuración que vamos a confirmar
desvio_llamadas_Lync_10.jpg

y si no hay problemas nos muestra que se han aplicado correctamente

desvio_llamadas_Lync_11.jpg

Ahora vamos a habilitar en nuestro cliente Lync la llamada simultánea a la extensión 205, recordad que no tenemos permitido la llamada a esa numeración

desvio_llamadas_Lync_12.jpgdesvio_llamadas_Lync_13.jpg

como podeís apreciar tengo activado la llama simultánea a Lync y la extesión 205

desvio_llamadas_Lync_14.jpg

Ahora cuando alguien nos haga una llamada a nuestro cliente de Lync, la llamada NO sonará en la extensión o número que hemos asignado en el desvío de llamadas si lo hemos denegado. Pero el problema es que tampoco nos avisa, esto puede resultar algo confuso para los usuarios.  De momento es lo que tenemos, habrá que esperar a que Microsoft nos habilite alguna forma de avisar al usuario de que la llamada al número que hemos desviado no está permitido. Si tenemos Lync integrado con la UM de Exchange nos llegará un correo de voz a nuestro buzón si el usuario que nos llama nos ha dejado algún comentario:

desvio_llamadas_Lync_15.jpg

El tiempo que tardará una llamada que no es contestada por el usuario en enviarse al buzón de voz es de 20 segundos de forma predeterminada, si queremos aumentar o disminuir este tiempo tenemos que ir a la opción de Desvios de Llamadas en las opciones de Lync

desvio_llamadas_Lync_16.jpg
desvio_llamadas_Lync_17.jpg

Seguramente lo ideal sería que se puediese advertir al usuario que ha configurado el desvío que no está permitido, pero bueno .. de momento es lo que tenemos.

Espero os sea de utilidad!!!

​Una de las cosas que debemos tener en cuenta cuando configuramos la UM de Exchange (esté integrada o no con Lync) es que debemos configurar el conector de recepción de Exchange para el usuario pueda recibir el correo de voz en su buzón. Uno de los errores más comunes suele ser este: Origen: MSExchange Unified Messaging  Id. del Evento: 1446

Exchange_UM_Error_1.jpg
Nombre de registro:Application
Origen:        MSExchange Unified Messaging
Fecha:         25/01/2013 10:47:06
Id. del evento:1446
Categoría de la tarea:UMCore
Nivel:         Error
Palabras clave:Clásico
Usuario:       No disponible
Equipo:        XXX.XXXX.XXX
Descripción:
El servidor de mensajería unificada no procesó el mensaje con el archivo de encabezado «C:\Program Files\Microsoft\Exchange Server\V14\UnifiedMessaging\voicemail\66e41384-7ee7-4325-a8ab-9068706b861a.txt» en «23» minutos. El servidor de MU continuará con el procesamiento y envío del mensaje, pero el contador de rendimiento «MSExchangeUMAvailability: % de mensajes procesados correctamente en la última hora» se reducirá.
XML de evento:
<Event xmlns=»http://schemas.microsoft.com/win/2004/08/events/event«>
<System>
<Provider Name=»MSExchange Unified Messaging» />
<EventID Qualifiers=»49156″>1446</EventID>
<Level>2</Level>
<Task>2</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime=»2013-01-25T09:47:06.000000000Z» />
<EventRecordID>1496965</EventRecordID>
<Channel>Application</Channel>
<Computer>XXX.XXXX.XXX</Computer>
<Security />
</System>
<EventData>
<Data>C:\Program Files\Microsoft\Exchange Server\V14\UnifiedMessaging\voicemail\66e41384-7ee7-4325-a8ab-9068706b861a.txt</Data>
<Data>23</Data>
</EventData>
</Event>
En principio esto tiene fácil solución, debemos crear (o modificar un conecto existente) un conectar  de recepción con la siguiente configuración:
Como es un conector de uso interno el nombre FQDN que debemos poner es el del propio servidor, puesto que este servidor no entregará el correo a Internet (si fuese así sería el FQDN con el que nos tienen que ver el resto de servidores)
Exchange_UM_Error_2.jpg
Como yo he creado un conector en exclusiva para UM (no tenéis porque) le he puesto que solo se puede conectar a el el propio servidor, para ello he añadido la IP del servidor
Exchange_UM_Error_3.jpg
y por último debemos habilitar la Autenticación de Exchange Server
Exchange_UM_Error_4.jpg
Una vez que hemos configurado estas opciones, que son las esenciales si solo utilizaremos el conector para que pueda entregar los correos de voz a los buzones de los usuarios, ya tenemos solucionado el problema. Siempre y cuando este haya sido vuestro problema, además debéis tener asignado un certificado para la UM con el nombre FQDN que tenéis configurado en el conector.
Sino queréis crear un nuevo conector debéis modificar el que tengáis por defecto y habilitar la Autenticación de Exchange Server
Espero que os sea de utilidad!!!

Os voy a mostrar un escenario que es muy común cuando estamos migrando una solución de Voz con IP-PBX a Lync Server, manteniendo un entorno híbrido hasta completar la migración

Lync_CME_PBX_Esquema_Final.jpg

Primero vamos a tratar de simular una posible migración de sus antiguas IP-PBX a Lync Server 2013. Lo que queremos lograr en primera instancia es instalar Lync en un entorno virtualizado y posteriormente ir moviendo a los usuarios de teléfonos de las IP-PBX a lync. No podemos dejar pasar por alto que debemos dotar de llamadas a la PSTN y a los usuarios de Lync y de comunicación con el resto de usuarios conectados a las IP-PBX. Todas las sedes están comunicadas entre sí mediante una VPN con IPSec, lo que ha permitido a la empresa conectar las centralitas IP-PBX mediante H.323 a través de la VPN. Esto permitía dotar de llamadas internas y a coste 0 entre todas las sedes de la empresa y, además todos los usuarios podrían llamar a la PSTN mediante los enlaces PRI o BRI conectados en cada una de las centralitas.
Estos son los requisitos del proyecto:
  • Centralización de las llamadas
  • Sistema de Videoconferencia con clientes
  • Dotación de telefonía y videoconferencia a los usuarios itinerantes
  • Ahorro de costes en las llamadas la PSTN
  • Ahorro de costes en infraestructura y servicios
Teniendo en cuenta estas premisas empezaremos a describir cual es el entorno actual. Todos los usuarios de cada una de las sedes cuentan con un teléfono físico y por consiguiente tiene una extensión asignada. El rango de extensiones que maneja cada centralita por cada una de las sedes es la siguiente:
Sede 1: desde la 300 hasta  la 400
Sede 2: desde la 500 hasta la 599 y desde la 700 hasta la 799
Sede 3: desde la 100 hasta la 200
Los dispositivos de seguridad que tenemos en cada sede nos permiten configurar una VPN Site-to-Site mediante IPSec, lo que nos permite securizar las comunicaciones entre las sedes. Además, en el modelo actual de comunicaciones de voz, nos permite conectar mediante H.323 las distintas centralitas para comunicar internamente a los usuarios de las tres sedes.
Las centralitas IP-PBX no tienen soporte para configurar un Direct SIP contra Lync, por lo que debemos adquirir un gateway que nos permita enlazar ambos sistemas. Para ello voy a utilizar un Gateway de Cisco con el CME 8.6, lo que nos posibilita configurar los dial-peer necesarios con H.323 y SIP para las IP-PBX y Lync respectivamente. La idea es que podamos comunicar a los usuarios de Lync con los de la telefonía tradicional, para ello el gateway «hablará ambos idiomas» de tal forma que será nuestro interlocutor entre ambos sistemas.
Una vez que tenemos claros cuales son los objetivos, vamos a empezar con la configuración del Gateway que situaremos físicamente en la sede número 3. La sede número 3 es en la que tenemos más recursos en cuanto a virtualización y conectividad a internet. Ya doy por hecho que tenemos nuestro servidor de Lync correctamente desplegado y con usuarios activos. Esta parte no la voy a documentar, únicamente voy a tratar de explicar las configuración de la Voz Empresarial. Antes de meternos de lleno en la configuración del gateway, vamos a ver las direcciones IP de los dispositivos que utilizaremos: Gateway, Front End y Centralitas IP-BPX.
Direccionamiento IP 
​Dispositivo Tipo ​Sede ​Dirección IP
Lync_CME_PBX_1.jpg IP-PBX​ SEDE 1
​192.168.40.10
Lync_CME_PBX_1.jpg
IP-PBX​
SEDE 2 ​ ​​192.168.41.10
Lync_CME_PBX_1.jpg
IP-PBX​
SEDE 3 ​ ​​192.168.42.10
Lync_CME_PBX_3.jpg Gateway SEDE 3 ​ ​​192.168.42.15
Lync_CME_PBX_4.jpg Front End ​SEDE 3 192.168.42.20

 

Voy a tratar de explicar de un modo diferenciado cada uno de los enlaces que debemos confgurar en el gateway para comunicarnos con el resto de dispositivos o sistemas. Primero vamos a habilitar SIP y H.323 en el gateway, para ello debemos aplicar estos comandos (hay comandos adicionales necesarios para la configuración)
voice service voip
 allow-connections h323 to h323
 allow-connections h323 to sip
 allow-connections sip to h323
 allow-connections sip to sip
 supplementary-service h450.12
 no supplementary-service sip moved-temporarily
 no supplementary-service sip refer
 h323
  h225 signal overlap
 sip
  no update-callerid
  midcall-signaling passthru
voice class codec 1
codec preference 1 g711alaw
codec preference 2 g729r8
codec preference 3 g711ulaw
!
voice class h323 1
h225 timeout tcp establish 3
h225 timeout setup 3
Ahora que hemos habilitado SIP y H.323 en el gateway vamos a empezar con la configuración de los distintos enlaces, primero los Direct SIP entre Lync y el gateway, tanto para las llamadas que emitirán los usuarios de Lync hacia las extensiones de las IP-PBX como las llamadas a la PSTN. Debemos configurar tantos dial-peer como sean necesarios para las distintas llamadas entrantes o salientes que pasen por el gateway. Debemos configurar dos dial-peers uno para la recepción de las llamadas hacia el Lync y otras las llamadas de Lync a la PSTN. Los dial-peers a muy grandes rasgos son como rutas estáticas que enviarán las llamadas a destinos concretos basándose en los patrones previamente establecidos. De ahí que debemos tener tantos dial-peer como patrones diferentes tengamos, tanto en llamadas salientes como entrantes. Necesitamos configurar un dial-peer para establecer la comunicación desde otro dispositivos hacia nosotros y además necesitamos saber cómo enviar las llamadas que esos otros dispositivos quieren cursar. Vamos a ir viendo como sería el orden lógico de una llamada y que dial-peers serían necesarios para dar servicio al esquema anterior.
Primero vamos a configurar los dial-peer que afectan a Lync con el Gateway,  el primero enviará todas las llamadas que reciba el gateway dirigidas a extensiones con un ratón de 5… al Lync. Luego el Lync ya debe estar configurado adecuadamente para recibir esa llamada y enviársela internamente al usuario que corresponde (Direct SIP Lync 2013 –> Cisco CME 8.X (Parte II))
Direct SIP: Cisco CME –> Lync
Enviará todas las llamadas desde teléfonos de las IP-PBX hacia extensiones Lync que comiencen por 5 y tengan 4 dígitos
Lync_CME_PBX_Esquema_Final_Direct_SIP_CME_LYNC.jpg
dial-peer voice 101 voip
description **Llamadas Entrantes desde Lync 2013**
b2bua
session protocol sipv2
session target ipv4:192.168.42.2O:5060
incoming called-number 5…
session transport tcp
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
dtmf-relay rtp-nte
no vad​

Como en nuestro caso solo los usuarios de Lync pasarán por el gateway para realizar llamadas a la PSTN (el resto de usuarios ya las tramitan directamente desde las IP-PBX), crearemos un dial-peer que envíe las llamadas directamente  la IP-PBX de la sede 3 y que curse la llamada hacia el exterior. Nosotros únicamente debemos crear el dial-peer con un patrón de llamada identificado que cuando el gateway reciba unos dígitos marcados por el usuario y empiece por el 0 y luego cualquier número debe enviar la llamada a la IP-PBX de la sede 3. De esta forma cuando un usuario quiera realizar una llamada al exterior nosotros tendremos que manipular los dígitos desde las reglas de normalización y la configuración del tronco (Direct SIP Lync 2013 –> Cisco CME 8.X (Parte II)), puesto que nosotros debemos normalizar los dígitos marcados al estandard E.164. De tal forma que si un usuario marca el 986000000 lo cambiará a +34986000000 y cuando la llamada se envíe al gateway se le quitarán los tres prímeros dígitos y se añadirá un 0. De tal forma que la llamada que enviaremos al gateway será 0986000000 y utilizará el dial-peer 101 que enviará las llamadas directamente a la IP-PBX que enviará la llamada a la PSTN.  Esto podemos hacerlo así, o bien enviar el número normalizado al gateway y que el ser encargue de manipular los digitos que sean necesarios quitando el +34 y añadiendo un 0 al número para posteriormente enviarlo a la IP-PBX de la SEDE 3.

Ejemplo de translation-rule que manipulará los dígitos para quitar el +34 y añadir el 0 al número marcado por el usuario
voice translation-rule 1200
 rule 1 /^\+34/ /0/
voice translation-profile LLAMADAS_PSTN
 translate called 1200

Direct SIP: Lync –> Cisco CME –> PSTN
Enviará todas las llamadas que comiencen por 0 a la IP-PBX de la sede 3,
esta a su vez enviará la llamada a la PSTN utilizando las líneas PRI o BRI configuradas​

Lync_CME_PBX_Esquema_Final_Direct_SIP.jpg
dial-peer voice 101 voip
description **Llamadas Salientes desde Lync 2013**
translation-profile outgoing LLAMADAS_PSTN (opcional)
destination-pattern 0T
session target ipv4:192.168.42.10
voice-class codec 1
dtmf-relay h245-alphanumeric
no vad
Ahora debemos configurar varios dial-peer para las llamadas que lleguen al gateway  procedentes de Lync a extensiones internas de cualquier IP-PBX. Lo que necesitamos hacer es que cada llamada en función del patrón que tengamos configurado se envíe a una u otra centralita, puesto que como habíamos simulado cada centralita gestiona un rango de extensiones determinado. Para ello vamos a crear 3 dial-peer uno para el rango de la SEDE 1, SEDE 2 y SEDE 3.

H.323: Cisco CME –> IPPBX​
Enviará a la IP-PBX de la Sede 1 todas las llamadas hacia las extensiones
3xx y 4xx para comunicar a los usuarios de Lync que serán quieren utilicen el
gateway para realizar las llamadas a esas extensiones

Lync_CME_PBX_Esquema_Final_CME_IPPBX.jpg
dial-peer voice 200 voip
description **Llamadas Salientes PBX Ext 3.. y 4..**
translation-profile outgoing CME-PBX
destination-pattern [3-4]..
session target ipv4:192.168.40.10
voice-class codec 1
voice-class h323 1
dtmf-relay h245-alphanumeric
no vad​

 

H.323: Cisco CME –> IPPBX​
Enviará a la IP-PBX de la Sede 2 todas las llamadas hacia las extensiones
5xx y 7xx para comunicar a los usuarios de Lync que serán quieren utilicen el
gateway para realizar las llamadas a esas extensiones
Lync_CME_PBX_Esquema_Final_CME_IPPBX.jpg
dial-peer voice 201 voip
description **Llamadas Salientes PBX Ext 5.. y 7..**
translation-profile outgoing CME-PBX
destination-pattern [^1-4][5][^6][7]..
session target ipv4:192.168.41.10
voice-class codec 1
voice-class h323 1
dtmf-relay h245-alphanumeric
no vad​

 

H.323: Cisco CME –> IPPBX​
Enviará a la IP-PBX de la Sede 3 todas las llamadas hacia las extensiones
1xx y 2xx para comunicar a los usuarios de Lync que serán quieren utilicen el
gateway para realizar las llamadas a esas extensiones
Lync_CME_PBX_Esquema_Final_CME_IPPBX.jpg​ ​
dial-peer voice 202 voip
description **Llamadas Salientes PBX Ext 1.. y 2..**
translation-profile outgoing CME-PBX
destination-pattern [1-2]..
session target ipv4:192.168.42.10
voice-class codec 1
voice-class h323 1
dtmf-relay h245-alphanumeric
no vad​

 

Por último debemos crear un dial-peer que nos permita recibir llamadas a extensiones Lync (5xxx) desde cualquier centralita IP-PBX, permitiendo así que los usuarios que aún no hayamos migrado a Lync puedan realizar llamadas a usuarios de Lync. Si hemos asignado como número de teléfono la extensión del usuario en Lync, debemos crear una regla de traducción para que envíe a Lync la extensión marcada con el signo +, de tal forma que los usuarios no tienen que marcar el símbolo + desde sus teléfonos para llamar a los usuarios de Lync.
Lync_CME_PBX_5.JPG
Ejemplo de Translation-Rule, los usuarios únicamente deberán marcar el número sin el símbolo +, puesto que será el gateway quien manipulará los dígitos y enviará el número normalizado con el formato E.164
voice translation-rule 1300
rule 1 /\(5…\)/ /+\1/
voice translation-profile LLAMADAS_A_LYNC
translate called 1300
H.323: IPPBX​ –> Cisco CME
Llamadas entre usuarios de IP-PBX de la SEDE 1 con los usuarios de Lync
Lync_CME_PBX_Esquema_Final_Direct_SIP_IPX_CME.jpg
dial-peer voice 203 voip
description **Llamadas Entrantes desde IPPBX a Lync**
translation-profile outgoing LLAMADAS_A_LYNC (opcional)
incoming called-number 5…
session target ipv4:192.168.40.10
voice-class codec 1
voice-class h323 1
dtmf-relay h245-alphanumeric
no vad​
H.323: IPPBX​ –> Cisco CME
Llamadas entre usuarios de IP-PBX de la SEDE 2 con los usuarios de Lync
zial-peer voice 204 voip
 description **Llamadas Entrantes desde IPPBX a Lync**
 incoming called-number .%
 session target ipv4:192.168.41.10
 voice-class codec 1
 voice-class h323 1
 dtmf-relay h245-alphanumeric
 no vad​

H.323: IPPBX​ –> Cisco CME
Llamadas entre usuarios de IP-PBX de la SEDE 3 con los usuarios de Lync
dial-peer voice 205 voip
 description **Llamadas Entrantes desde IPPBX a Lync**
 incoming called-number .%
 session target ipv4:192.168.42.10
 voice-class codec 1
 voice-class h323 1
 dtmf-relay h245-alphanumeric
 no vad​​
Ya hemos finalizado la configuración del gateway, ahora podrá enviar las llamadas a cualquier destino que hemos establecido, tanto a la PSTN como llamadas entre las diferentes extensiones de los usuarios de Lync y la telefonía tradicional. Todas las llamadas desde los usuarios de Lync que vayan dirigidas a la PSTN saldrán directamente por la IP-PBX de la SEDE 3. También podríamos configurar que las llamadas de los usuarios de Lync saliesen por cualquiera de las centralitas, sería únicamente configurar varios dial-peer similares al 101 y configurando una preferencia de salida, del tal forma que pudiéramos utilizar cualquier centralita o «balancear» las llamadas salientes. Pero en principio lo que nosotros queremos es que salgan únicamente por la IP-PBX de la SEDE 3. Hemos designado la SEDE 3 como la sede principal porque es la que tiene mayor cantidad de usuarios y de recursos tecnológicos para el despliegue de la infraestructura. Una vez una vez migrados todos los usuarios vamos a configurar en Lync un Direct SIP con un ITSP para que todas las llamadas a la PSTN se realicen mediante este proveedor olvidándonos de pasar por el gateway. También podemos mantener el gateway si queremos y configurar el Direct SIP entre el Gateway y el ITSP, así solo tendríamos que cambiar la configuración del Gateway y no el Direct SIP de Lync, ahí es cuestión de cada cual con lo que se sienta más cómodo.
La configuración de Lync para reglas de normalización las había comentado en su momento (Direct SIP Lync 2013 –> Cisco CME 8.X (Parte II)), por lo que no voy a volver a repetir el mismo artículo.
Lo único que debéis tener en cuenta en los siguientes:
  • Normalizar los números marcados por los usuarios desde Lync (E.164)
  • Asignar correctamente la extensión a los usuarios de Lync, sino tienen DDI asignado podemos asignar la extensión 5XXX como número de teléfono (no es lo recomendado
  • En las centralitas IP-PBX debemos configurar que para llamar a las extensiones de Lync debe hacerlo mediante el gateway

La configuración del gateway nos permite crear un entorno hibrido, el cual nos posibilita conectar ambas tecnologías sin perder la operatividad de los usuarios. Una vez que hayamos migrado todos los usuarios a Lync ya podemos deshacernos del gateway si lo consideramos oportuno.

Con esto hemos cumplido el objetivo del proyecto que nos habíamos propuesto:

  • Centralización de las llamadas: las llamadas se cursarán desde el sevidor de Lync en la SEDE 3
  • Sistema de Videoconferencia con clientes: con Lync Web APP podemos tener videoconferencias con los clientes sin que ellos tengan que disponer de infraestructura
  • Dotación de telefonía y videoconferencia: los usuarios solo tienen que iniciar sesión en Lync y ya tienen todos los servicios disponibles, sin que para ello tengan que estar conectados desde dentro de las sedes o bien conectarme mediante VPN.
  • Ahorro de costes en las llamadas a la PSTN: una vez que hayamos migrado también las líneas PRI o BRI a un ITSP tendremos las llamadas a coste * uso y con un precio tarificado por segundo
  • Ahorro de costes en infraestructura y servicios: dejaremos de tener centralitas en cada sede actual y en las futuras, además del coste de los teléfonos físicos

He resumido mucho esta infraestructura, pero espero que os hayáis quedado con la idea. El resto de configuraciones las he ido comentando en distintos artículos, de tal forma que si los habéis leído podéis realizar las adaptaciones necesarias a esta configuración sin problema. La idea es que mostrar la importancia de un gateway  en las infraestructuras, las distintas configuraciones que debemos implementar y su finalidad. En organizaciones en donde quieren ir migrando a Lync en función de la finalización de contratos de renting de las centralitas, contratos de servicios, etc… el proceso sería igual pero el gateway sería la figura más importante del sistema, puesto que es la que enlaza ambas tecnologías. A lo que me refiero es que no tenéis que obligatoriamente migrar a Lync completamente y podéis mantener un entorno híbrido completamente funcional.

Espero que os sea de utilidad este artículo!!!

​Una de las novedades que más me ha sorprendido en Lync es algo que se llama «Configuración de escape en correo de voz», el nombre se las trae pero bueno. ​Esto es una nueva opción de Lync 2013 que permite enrutar una llamada al buzón de voz corporativo si el usuario de Lync tiene activada la llamada simultánea a un móvil y, este móvil no se encuentra disponible (apagado, fuera de cobertura).  Si el móvil no se encuentra disponible lo normal es que salte el buzón de voz personal del usuario configurado, pero ahora podemos configurar un temporizador que permite enrutar la llamada al buzón de voz coportativo (UM Exchange) desconectando el buzón de voz personal.

Escape_Buzón_Corporativo_Esquema.jpg

Este comportamiento viene desactivado por defecto, para comprobarlo ejecutamos el siguiente cmdlet: Set-CsVoicepolicy -Identity nombre_politica

La opción es EnableVoicemailEscapeTimer  y PSTNVoicemailEscapeTimer

Escape_correo_voz_1.jpg
Si queremos habilitarlo  y establecer el timer en 2 segundos (cada uno tendrá que ajustarlo según sus necesidades, como máximo podemos establecerlo a 8 segundos) ejecutaremos el siguiente cmdlet:

Set-CsVoicePolicy -Identity Interoute -EnableVoicemailEscapeTimer $true –PSTNVoicemailEscapeTimer 2000Escape_correo_voz_2.jpg
Ahora cuando el usuario tenga habilitado la llamada simultánea y reciba una llamada siempre que el contestador personal conteste la llamada en el intervalo establecido (PSTNVoicemailEscapeTimer ) el Lync desconectará el buzón personal y lo enrutará al buzón corporativo (UM de Exchange).

Espero que os sea de utilidad!!

Por defecto, en Lync la opción de modificar el audio de MOH está deshabilitado. Si queremos que desde el cliente Lync se pueda cambiar el audio de la MOH, debemos habilitarlo. Para ello podemos hacerlo desde la política global o a nivel de política de usuario.

MOH deshabilitado

image

Vamos a mostrar como habilitar la MOH a nivel global

set-csclientpolicy -identity global -enableclientmusiconhold $true

 

Una vez que el usuario inice sesión en Lync, podrá cambiar el audio de la MOH

image

Espero que les sea de utilidad!!!