Microsoft Lync Server
Header

Después de unas cuantas horas de trabajo,  hemos traducido he introducido nuevas opciones en Lync How-To que MSFT tiene para Lync 2010. Nosotros lo hemos vuelto a crear con la base web del Lync How-To pero con capturas y videos de Lync 2013, espero que os guste!!! He puesto una captura de pantalla para que veáis como podéis acceder y el vínculo no pase desapercibido

lync_how_to_no_guia_lync_si_1.pngPara que esto fuera posible he contado la con colaboración inestimable de Tomás González  y Belén Francisco (compañeros de ASIR), sin ellos esto no hubiera sido posible hacerlo.
Se agradece todo tipo de comentarios y sugerencias, además poco a poco iremos subiendo más contenidos que seguro que serán de vuestro interés
Espero que os sea de utilidad!!!

​Después de configurar la federación ​entre Lync Online y mi implementación On Premise he visto algunas cosas curiosas, como por ejemplo que si nos comentamos desde la versión 2010 y 2013 del cliente Lync habilitadas opciones diferentes. Por lo menos me han resultado bastante curiosas y de momento no he encontrado mucha explicación y de ahi que quisiera compartirlo con vosotros por si alguien tiene la respuesta. Voy a trtar de enumerarlas:

1. Foto del Active Directory: En teoría se supone que si hemos federado nuestro Lync con otra compañia, no podemos ver la foto del contacto de la otra organización si está integrada en el Directorio Activo. Pues yo desde el cliente Lync 2013  con la cuenta de Office 365 puedo ver la foto de mi otra cuenta On Premise pero no al revés!!

Esta es mi cuenta OnLine y como podéis apreciar puedo ver la imagen que yo tengo en el Directorio Activo asignada al usuario.  En principio pensé que la podía estar sacando de Linkedin, FB, etc.. que era una de las novedades del cliente 2013 pero si os fijáis dice que la imagen la muestra desde la Libreta de Direcciones!!!

Diferencias_Lync_20xx_5.jpg
Y esta captura de pantalla es desde mi sesión de Lync On Premise con el cliente Lync 2013  y, como podéis apreciar no puedo ver la imagen del usuario de la sesión de Office 365!!!Diferencias_Lync_20xx_9.jpg
Si trato de hacer esto mismo iniciando sesión con la cuenta de Office 365  desde un cliente Lync 2010 ya no la puedo ver y, si os dais cuenta tampoco puedo ver los números de teléfonos asociados a mi usuario, pero eso si podía hacerlo con el cliente Lync 2013Diferencias_Lync_20xx_3.jpg

Ahora os muestro la captura de pantalla de mi sesión On Premise en un cliente 2013 y sigo sin poder ver su foto!!!!Diferencias_Lync_20xx_12.jpg

2. Cambio de Foto Lync Online: Esto también me ha resultado curioso, desde Lync 2010 puedo cambiar la imagen de Lync directamente desde el propio cliente, pero desde Lync 2013 tengo que hacerlo desde MIcrosoft Online Services!!

Esta captura de pantalla es del cliente Lync 2010, como véis muestra la imagen que yo habia cambiado desde el panel de Microsoft Online Services y tengo habilitada la posibilidad de mostrar una imagen desde una URL

Diferencias_Lync_20xx_2.jpg

Y esta otra captura de pantalla es desde el cliente Lync 2013 y… no puedo cambiar la imagen!!! Además como ya habia cambiado la imagen desde el cliente Lync 2010 ya me la está mostrando,  pero no puedo cambiarla.

Diferencias_Lync_20xx_7.jpg

Si quiero volver a tener mi foto en el cliente Lync Online tengo que ir al cliente 2010 y volver a seleccionarla porque solo desde este cliente tengo esta opción disponible.Diferencias_Lync_20xx_2.jpg

Además aunque he cambiado de nuevo la imagen en la web de Microsoft Online Services «prevalecía» la configuración establecida desde el cliente 2010 aunque iniciase sesión en el 2013

Diferencias_Lync_20xx_13.jpg
Desde luego sus razones tendrá Microsoft para que tenga este comportamiento, pero no he encontrado información alguna sobre ello. Si alguien sabe el porque de este comportamiento, dejen su comentario

Gracias!!

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!!!