Microsoft Lync Server
Header

​Se ha liberado  una nueva actualización del cliente Lync para móvil, la cual da soporte para Windows Phone 8.1 y corrige algunos errores:

Update_Lync-2013.png
Aquí tenéis el enlace de descarga: Lync 2013 Mobile 5.5.1277.0

 

Se ha liberado la actualización para el cliente Lync de MAC 2011 ​KB3007876, aquí tenéis el enlace de descarga: http://www.microsoft.com/en-us/download/details.aspx?id=36517. Esta actualización corrige los siguientes errores:

This update resolves the following issues:
  • 3007886

    Update enables users to view call history in Lync for Mac 2011

  • 3007885

    Update for Lync for Mac 2011 enables users to store conversation history on an Exchange server

  • 3007884

    Location is not displayed in Lync for Mac 2011 when users join a wireless network

  • 3007883

    Error "One or more selected contacts cannot receive your calls" when you forward calls in Lync for Mac 2011

  • 3007881

    Delegation relationship is broken after a delegate signs in to Lync for Mac 2011

  • 3007879

    Computer shutdown is not processed when Lync for Mac 2011 is running

  • 3007878

    Update implements media resiliency mode in Lync for Mac 2011

  • 3007877

    Dial pad disappears when a user who is not enabled for EV joins a video conference or a video call in Lync for Mac 2011

  • 2909659

    Update enables users to interact with a contact from the call history in Lync for Mac 2011

 

​Microsoft ha liberado una nueva actualización acumulativa para Lync 2013 (CU8) (http://www.microsoft.com/en-us/download/confirmation.aspx?id=36820), aquí tenéis el KB de esta actualización

 Lync CU8.png

Lista de funciones de servidor y las actualizaciones que se aplican a ellos

Lync Server 2013 – servidor Standard Edition

  • Actualización de componentes principales: KB 2937305
  • Actualización para la API administrada de comunicaciones unificadas 4.0, tiempo de ejecución principal 64 bits: KB 2937311
  • Actualización de servidor Front-End y borde (servidor Standard o Enterprise edition): 2937310 KB
  • Actualización de Conferencing Server: KB 2835434
  • Actualización de componentes de servidor: KB 2937297
  • Actualización para el servidor de conferencia Web: KB 2937314
  • Actualización para el servidor de mediación: KB 2881699
  • Actualización para el servicio de parques de llamada: KB 2881703
  • Actualización de servicio de Backup: KB 2910243
  • Actualización para el servidor de Administración Central: KB 2910244
  • Actualización para Windows Fabric: KB 2967486

Servidor Front-End de Lync Server 2013 – Enterprise Edition – y servidor de Back End

  • Actualización de componentes principales: KB 2937305
  • Actualización para la API administrada de comunicaciones unificadas 4.0, tiempo de ejecución principal 64 bits: KB 2937311
  • Actualización de servidor Front-End y borde (servidor Standard o Enterprise edition): 2937310 KB
  • Actualización de Conferencing Server: KB 2835434
  • Actualización de componentes de servidor: KB 2937297
  • Actualización para el servidor de conferencia Web: KB 2937314
  • Actualización para el servidor de mediación: KB 2881699
  • Actualización para el servicio de parques de llamada: KB 2881703
  • Actualización de servicio de Backup: KB 2910243
  • Actualización para el servidor de Administración Central: KB 2910244
  • Actualización para Windows Fabric: KB 2967486

Lync Server 2013 – servidor perimetral

  • Actualización de componentes principales: KB 2937305
  • Actualización para la API administrada de comunicaciones unificadas 4.0, tiempo de ejecución principal 64 bits: KB 2937311
  • Actualización de servidor Front-End y borde (servidor Standard o Enterprise edition): 2937310 KB
  • Actualización para Windows Fabric: KB 2967486

Servidor de mediación de Lync Server 2013 – independiente

  • Actualización de componentes principales: KB 2937305
  • Actualización para la API administrada de comunicaciones unificadas 4.0, tiempo de ejecución principal 64 bits: KB 2937311
  • Actualización para el servidor de mediación: KB 2881699

Lync Server 2013 – servidor Director

  • Actualización de componentes principales: KB 2937305
  • Actualización para la API administrada de comunicaciones unificadas 4.0, tiempo de ejecución principal 64 bits: KB 2937311
  • Actualización de servidor Front-End y borde (servidor Standard o Enterprise edition): 2937310 KB
  • Actualización de componentes de servidor: KB 2937297
  • Actualización para Windows Fabric: KB 2967486

Lync Server 2013 – servidor Front-End persistente de charla

  • Actualización de componentes principales: KB 2937305
  • Actualización para la API administrada de comunicaciones unificadas 4.0, tiempo de ejecución principal 64 bits: KB 2937311

Lync Server 2013 – herramientas de administración

  • Actualización de componentes principales: KB 2937305

 Ahora os toca actualizar, pero siempre siguiendo el procedimiento adecuado: http://support.microsoft.com/kb/2809243

Es posible que estéis pensando en migrar vuestro Exchange, SharePoint o Lync a la nube, y con esto buscáis que vuestros usuarios puedan iniciar sesión en las aplicaciones nombradas con las mismas credenciales de vuestro dominio local. Para ello debéis realizar una serie de pasos antes, uno de ellos es la publicación del AD FS que habéis configurado en alguno de vuestros servidores On-Permises, y si tenéis un Reverse-Proxy (TMG, F5, KEMP, IIS ARR, etc..) debéis realizar una serie de configuraciones las cuales voy a comentaros si utilizáis TMG. Debemos disponer de un certificado digital de una entidad certificadora pública (DigiCert, Verising, Geotrust, etc..), tanto puede ser un certificado con un solo nombre, como SAN o Wildcard, aquí no tenemos problema con el tipo de certificado, lo que sí es que los nombres de dominio que tenga el certificado se deben corresponder con lo que vamos a publicar (lo de siempre vamos) y en base a los UPN que hayamos sincronizado con Office 365 porque harán referencia a los inicios de sesión de los usuarios. Una vez dicho esto, veamos cual sería la configuración del TMG, para ello nos vamos a la consola de administración y con el botón derecho hacemos clic encima de la opción Reglas de Firewall – Nuevo – Regla de Publicación Web

Publicar AD FS via TMG 2010.png

Escribimos uno nombre corto pero descriptivo para la regla de publicación que vamos a crear y pulsamos en Siguiente

Publicar AD FS via TMG 2010 - 1.png

Elegimos la opción Permitir y pulsamos en Siguiente
Publicar AD FS via TMG 2010 - 2.png

Selecionamos que queremos publicar una única web o un balanceador y pulsamos en Siguiente

Publicar AD FS via TMG 2010 - 3.png

Requisito inprescindible es que el servidor web que vamos a publicar sea bajo SSL y pulsamos en Siguiente

Publicar AD FS via TMG 2010 - 4.png

Escribimos el FQDN del nombre del servicio a publicar en interno (en mi caso es el mismo que el externo, tratando de tener un criterio único) y pulsamos en Siguiente

Publicar AD FS via TMG 2010 - 5.png

Especificamos una ruta del servidor web que vamos a publicar, en este caso escribimos /adfs/* (de tal forma que esta regla solo permitirá la conexión cuando se intente acceder aa /adfs/ y cualquier cosa de aquí en adelante) y pulsamos en Siguiente:
Publicar AD FS via TMG 2010 - 6.png
Ahora escribimos el nombre público con el que se publicará el servicio web, de tal forma que el TMG sepa que si le llega una petición con una cabecera adfs.asirsl.com tenga claro que esta es la regla que tendrá que aplicar, y en la ruta igualmente permitimos únicamente las conexiones desde /adfs/ hacia adelante. Si el nombre es diferente al interno es cuestión de que lo pongáis, eso si, este nombre debe tener su registro DNS de Tipo A (o CNAME, pero mejor A) en el servidor DNS externo):
Publicar AD FS via TMG 2010 - 7.png
Elegimos el Listener que previamente hemos configurado con el certificado que vayamos a utilizar y pulsamos en Siguiente
Publicar AD FS via TMG 2010 - 8.png

Ahora nos toca elegir el tipo de autenticación, debemos escoger No delegación, pero el cliente puede autenticarse directamente y pulsamos en Siguiente

Publicar AD FS via TMG 2010 - 9.png
Cómo último paso guiado por el asistente añadiremos al grupo Todos los Usuarios y pulsamos en Siguiente

Publicar AD FS via TMG 2010 - 10.png

Y por último pulsamos en Finalizar

Publicar AD FS via TMG 2010 - 11.png

Nos quedaria por ajustar varias cosas en esta regla, para ello la buscamos entre las directivas de Firewall, vamos a sus propiedades y configuramos las diferentes opciones tal cual os muestro:

Publicar AD FS via TMG 2010 - 12.png

Esto es a modo revisión, porque si lo recordáis esto es justamente lo que hemos configurado con el Asistente

Publicar AD FS via TMG 2010 - 14.pngPublicar AD FS via TMG 2010 - 13.png

También debemos configurar una cosa más a nivel del protocolo HTTP, para ello pulsamos con el botón secundario de ratón encima del protocolo de la regla de AD-FS 3.0 y pulsamos en Configurar HTTP:

Publicar AD FS via TMG 2010.png
Y desmarcamos las casillas que os muestro en la siguiente imagen:

Publicar AD FS via TMG 2010 - 17png.png

Ahora sí que podempos aplicar los cambios pendientes en el TMG y si ya tenemos todas las configuraciones preparadas para iniciar sesión en Office 365 con nuestras credenciales de dominio, solo toca probarlo. Para ello nos vamos a https://login.microsoft.com, introducimos nuestro usuario y si estámos federados correctamente automáticamente nos redirigirá la petición a nuestro ADFS para autenticarnos, ahí es cuando entre en juego la regla que hemos creado:

Paso 1: Introducimos el usuario de nuestra organización

Publicar AD FS via TMG 2010 - 18.png

Paso 2: El sistema automáticamente nos intenta redirigir a la página de incio que hemos publicado anteriormente (adfs.asirsl.com)

Publicar AD FS via TMG 2010 - 19.png

Paso 3: Nos solicitará las credenciales, las introducimos y pulsamos en Aceptar

Publicar AD FS via TMG 2010 - 21.png

Paso 4: Ya estamos dentro de Office 365 accediendo con nuestras credenciales de dominio

Publicar AD FS via TMG 2010 - 20.png

Sin el momento de conectarnos revisamos el LOG del TMG, veremos las conexiones oportunas y si hemos iniciado sesión correctamente lo podremos ver con claridad:

Publicar AD FS via TMG 2010 - 15.png
Como podéis apreciar la publicación es sencilla y rápida, os llevará más tiempo la configuración de la sincronización, preparación del AD y el AD FS que esta regla. Si bien es cierto que esto no es complejo, únicamente debemos cumplir los requisitos previos y funcionará  muy bien. Otra cosa es configurar los diferentes servicios con autenticación integrada, entornos híbridos, etc.. pero bueno eso para otro momento.

Espero que os sea de utilidad!!!

Cuando implementamos Lync como nuestra solución de Telefonía, algo que debemos tener en cuenta a la hora de configurar nuestros planes de marcos, directivas, rutas de voz, etc… es saber como queremos enrutar nuestras llamadas salientes si tenemos más de un ITSP. Lo lógico es que si tenemos varios ITSP  queramos utilizarlos, bien porque tenemos diferentes costes de llamadas por ITSP, destino de llamada, etc… y por lo tanto debemos optimizar la utilización de los distintos ITSP para no incurrir en costes innecesarios y  en caso de que alguno falle tengamos la posibilidad de seguir emitiendo llamadas en base a un criterio determinado. Lo normal sería que sí no tenemos conexión con un TRUNK SIP que hayamos configurado, tenemos que ver la forma de seguir emitiendo llamadas y con un criterio nos permite en todo momento decidir que otros TRUNK SIP utlizaremos. Y no solo cuando tengamos algún TRUNK SIP caído, sino porque queremos y debemos optimizar el gasto de nuestras comunicaciones de Voz. Para ello como sabéis, debemos crear diferentes directivas de Voz aplicadas a nivel Global, Sitio o Usuario, sobre las cuales definiremos en que orden se utilizarán los distintos TRUNK SIP y si lo haremos por balanceo (roound-robin) o por commutación por error.

Lo primero que debemos definir a que nivel vamos a crear nuestra directiva de voz: Global (modificarla más bien, no se puede eliminar), Sitio o Usuario, y debéis analizarlo de la siguiente forma:

  • Global: Cuando todos los usuarios de Lync residan en el mismo país, puesto que todos utilizarán los mismos ITSP
  • Sitio: Cuando tenemos varios sitios configurados en el mismo o distintos país y que además tengamos diferentes ITSP o TRUNK SIP con Gateways locales, puesto que tendrán posiblemente configuraciones diferentes
  • Usuario: Cuando tengamos diferentes usuarios en diferentes países o usuarios habilitados para llamadas internacionales o tarificaciones adicionales  que no todos los usuarios deben tener.
Una vez que tengamos esto definido, debemos crear las directivas de voz correspondientes, para posteriormente crear los diferentes usos de RTC. En los usos de RTC es donde vamos a definir como se gestionarán las llamadas salientes. Debemos crear diferentes usos de RTC en función del tipo de llamada (Nacional, Internacional, Móviles, etc..) y luego definir el TRUNK SIP (que se corresponderá con cada ITSP o conexión con el SBC correspondiente) por el cual enviaremos las llamadas en base a la configuración de las rutas que hemos configurado.  Cada uso de RTC debe ser lo más específico posible, de tal forma que tengamos identificado de forma clara solo con ver el nombre del Uso de RTC tengamos claro que tipo de llamada se realizarán por cada uno. Luego en cada ruta definiremos por que TRUNK SIP enviaremos las llamadas, y aquí es donde debemos hacer especial hincapié. En este artículo me centraré en como debemos impletar las directivas de voz, usos de RTC y Rutas para enviar las llamadas vía los TRUNK SIP.  Además de mostrar como se pueden tener varios TRUNK SIP en una misma directiva de Voz asociando uno o varios usos de RTC. Los usos de RTC nos permiten enlazar las directivas de voz con las rutas, y las rutas es donde definimos la numeración que permitiremos y los TRUNK SIP que se utilizarán. Por ejemplo, podemos tener una Directiva de Voz para los usuarios de España, que tenga dos usos de RTC, uno para llamadas Nacionales (ITSP1) y otro uso de RTC para llamadas Internacionales (ITSP2), y cada uso de RTC tiene sus rutas en donde definiremos los números permitidos para llamar con su TRUNK SIP asociado. De tal forma que cuando un usuario de Lync llame a un número nacional utilizará el ITSP1 y cuando marque un número de ámbito internacional la llamada se cursará vía ITSP2. Ahora bien, si queremos implementar un sistema tolerante a errores en cuanto al ITSP o un sistma de balanceo de tipo round-robin en cuanto al TRUNK SIP que hemos configurado para cada ITSP. Esto es muy interesante si tenemos varios ITSP para cursar nuestras llamadas y queremos que en el caso de uno de ellos esté caido podamos utilizar otros de los que tengamos configurados. Pero también es cierto que queremos poder balancear las llamadas a través de varios ITSP que para nosotros son los TRUNK SIP configurados en cada ruta que hemos asignado a los usos de RTC que estos a su vez se aginan a cada directiva de Voz (Global, Sitio o Usuario).
 
Una vez dicho esto, veamos como podemos configurar estos dos escenarios de manejo de los TRUNK SIP implementando Balanceo (Round-Robin) o Conmutación por error. Para ello he preparado dos esquemas para poder explicarlo con una imagen acorde con cada argumento. Lo primero que veremos será como podemos configurar una directiva de Voz a nivel de usuario, en el cual tendremos un uso de RTC para todo tipo de llamadas (Móviles, Nacionales e Internacionales) porque todos los usuarios están en el mismo país y con un único sitio configurado en la topología. Con esto quiero decir que todos tienen las mismas necesidades de telefonía y ámbito de las llamadas, pero si tenemos varios ITSP a través de los cuales queremos balancear las llamadas salientes, lo haremos de la  y en el caso de que uno de los dos ITSP esté caido se utilice el activo.
 
Routing Failover Trunk Esquema Round Robin.jpg
Este esquema representa un Mediation Server con dos TRUNK SIP (ITSP1 y ITSP2) para los usuarios de España, que tienen asignada una directiva de Voz (ES-Llamadas-ITSP-LB), esta a su vez una ruta de Voz (ES-RTC-NACIONALES-LB) y por último una ruta (ES-RV-NACIONALES-LB) con los dos TRUNK SIP (ITSP1 y ITSP2) para las llamadas nacionales. Aquí tenéis las capturas de pantalla para que podáis ver la configuración comentada, para ello nos vamos al Panel de Control de Lync – Enrutamiento de Voz – Directiva de Voz – Agregar Directiva de Usuario
Routing_Failover_Trunk_10.jpg
Pulsamos en Agregar para crear nuestro uso de RTC en donde asignaremos una única ruta en donde configuraremos los diferentes TRUNK SIP previamente configurados desde el configurador de Topología:
Routing_Failover_Trunk_14.jpg
Ahora debemos agregar una nueva ruta en donde definiremos los números iniciales del número marcado por el usuario que se permitirán en esta ruta, de tal forma que tenga coincidencia con esta ruta. En este caso yo tengo un plan de marcado con varias reglas de normalización para que todos los números marcados por los usuarios los normalice al estándard E.169, de tal forma que siempre que el número se haya normalizado a +34 y el número marcado se aplicará estar ruta:
Routing_Failover_Trunk_15y.jpg
Por último en esta ruta debemos añadir los troncos (TRUNK SIP) que hemos configurado previamente en la topología:, para ello pulsamos en Agregar
Routing_Failover_Trunk_16y.jpg
Ahora debemos elegir los troncos (TRUNK SIP) que queremos utilizar en esta ruta
Routing_Failover_Trunk_8.jpg
Ahora como vemos tenemos los troncos (TRUNK SIP) asociados a esta ruta, ojo!! los troncos no se pueden cambiar de orden desde aquí, si queremos cambiarlos de orden debemos volver a agregarlos en el orden que queramos. De todas formas, si agregamos más de un tronco aquí se utilizarán como balanceo de tipo Round-robin (esa es la idea):
Routing_Failover_Trunk_17.jpg
Con esto ya tenemos lo que queríamos, tener varios troncos asociados en una misma ruta la cual está asociada al uso de RTC añadido a nuestra política de voz. De esta forma los usuarios a los cuales le apliquemos esta configuración tendrán tres troncos (TRUNK SIP con distintos ITSP o Gateways) para cursar llamadas utilizándose de forma alterna. Aquí os dejo una prueba de tres llamadas a destinos nacionales y cada uno se ha cursado en un tronco diferente, si hubiese una carta o n llamadas se realizarían utilizandos vía round-robin los tres troncos asociados a nuestra ruta:
 
Llamada 1: Tronco 195.x.x.x
Routing_Failover_Trunk_11.jpg
Llamada 2: Tronco trunkcme.asirsl.com
Routing_Failover_Trunk_12.jpg
Llamada 3: Tronco 195.x.x.x (porque el 192.x.x.x lo había desconectado manualmente para poder apreciar el funcionamiento)
Routing_Failover_Trunk_13.jpg
 
En este caso como habéis podido apreciar, tenemos tres troncos configurados en nuestra RUTA y que se utilizarán utilizando round-robin. En el caso de que no esté disponible alguno de ellos, el sistema utilizará de igual forma el resto de troncos. Por lo que si queremos balancear las llamadas a través de varios troncos (TRUNK SIP) esta es la forma de  hacerlo, una Directiva de Voz – Uso de RTC – Ruta (con varios troncos). El "problema" que tiene este sistema es que no podemos definir porque tronco saldrán las llamadas, los utilizará todos y además en el orden que le toque. Depende del escenario que vayamos a desplegar será o no el correcto, pero desde luego para balancear la carga de llamadas a través de varios ITSP, SBCs, etc.. es la forma de hacerlo.
 
Ahora vamos a ver como podemos configurar un sistema de llamadas tolerante a errores de algún TRUNK SIP que tengamos configurado. Imaginaros que tenemos una implementación de Lync de ámbitos internacional y que tenemos usuarios de varios paises pero con una sola implementación de Lync con un único sitio (gestión centralizada de las llamadas). Configuraremos distintas políticas de Voz , usos de RTC y Rutas "principales" para cada país. En cada país hemos contratado un ITSP (no haría falta obligatoriamente que fuese así, pero esto es otro debate) para ajustar el coste de la llamada nacional a cada país. Pero además, lo que queremos es que los usuarios nunca se queden sin poder cursar llamadas aunque para eso en determinados momentos tengamos que utilizar el ITSP de otros páis. Os recuerdo que esto es un ejemplo forzado, más lejos de la realidad de un entorno de buenas prácticas de diseño de elección de los ISTP, Sitios de Lync, etc. es simplemente para ver de forma clara la utilización de los Usos de RTC y Rutas para loas directivas de Voz de Lync para un sistema de conmutación por error de los ISTP. Dicho esto, aquí os dejo un esquema de un Mediation Server con los 4 TRUNK SIP (España, Francia, Inglaterra y Argentina) (pulsar en la imagen para verla a tamaño completo):
 
Routing Failover Trunk Esquema Failover.jpg
La idea es que para los usuarios de cada país el ITSP que primero utilicen sea el de su país y luego en orden descendente y por cercanía geográfica el resto de ITSPs del resto de paises. De tal forma que un usuario de España primero utilizará el ITSP1, luego el 2 (Francia), 3 (Inglaterra) y 4 (Argentina) y para el resto de usuarios del resto de países más de lo mismo invirtiendo el orden:
 
Routing Failover Trunk Esquema Failover 1.jpg
Para implementar esta configuración debemos hacer lo siguiente:
  1. Crear una directiva de voz para usuarios
  2. Crear un uso de RTC
  3. Crear una RUTA con el tronco del ITSP del país de los usuarios
  4. Añadir en el orden correcto el resto de usos de RTC del resto de directivas de voz asignadas a los usuarios de los diferentes países

Ahora lo que debemos hacer es realizar dichas configuraciones, para ello nos vamos al Panel de Control de Lync – Enrutamiento de Voz – Directiva de Voz y agregamos tantas Directivas de Usuario como necesitamos (en nuestro ejemplo 4). Yo he nombrado las Directivas de Voz de la siguiente forma:

ES: Pais

Llamadas-NMI: Llamadas Nacionales, Móviles e Internacionales

De esta forma solo con ver las directivas ya tengo claro cual es su función, de tal forma que como podéis apreciar tengo una por país:

Routing Failover Trunk_2.jpg

Si entramos por ejemplo en ES-Lllamadas-NMI veremos que tenemos 4 usos de RTC ya en orden en el que queremos implementar la conmutación por error de alguno de los ITSP configurados en las rutas de cada uno de los usos de RTC que os muestro a continuación. Antes comentaros que los usos de RTC  los he nombrado siguiendo el mismo proceso que las Directivas de Voz:

ES: País

RTC: Tipo (podemos quitarlo porque es obvio que es un RTC, pero lo he puesto así para que siempre tengamos claro de que estamos hablando)

Nacionales: Ámbio de la llamada

Routing_Failover_Trunk_4.jpg

Si editamos el primer uso de RTC que se corresponderá siempre con el ITSP que está en el mismo pais que el grupo de usuarios al que les asignamos la directiva de voz en donde se encuentra este uso de RTC vemos la ruta que hemos añadido. Antes comentaros que los usos de RTC  los he nombrado siguiendo el mismo proceso que las Directivas de Voz y los Usos de RTC:

ES: País

RV: Tipo (podemos quitarlo porque es obvio que es un RTC, pero lo he puesto así para que siempre tengamos claro de que estamos hablando)

Nacionales: Ámbito de la llamada

Routing_Failover_Trunk_5.jpg

Si editamos la Ruta asociada esto es lo que veremos, los números permitidos y el troncal asociado:

Routing_Failover_Trunk_6.jpg

El número es  +34 porque con los Planes de Marcado ya he normalizado siempre la numeración y el troncal único porque no queremos balancearlo a través de varios troncales sin "control" (Round-Robin), sino que queremos gestionar la conmutación por error de forma controlada. Dicho esto y visto las configuraciones de un país, el resto son exactamente iguales solo que en la ruta le cambiamos los números permitos y el tronco asociado que será el de cada país. Con esto los usuarios tendrán una directiva de Voz asignada en la cual tendrán varios usos de RTC asociados en el orden que consideremos adecuado, del tal forma que si un usuarios quiere realizar una llamada y el tronco asociado en su Ruta está caído utlizará el siguiente uso de RTC para tratar de realizar la llamada y así consecutivamente si fallase el otro ITSP hasta recorse todos los usos de RTC disponibles. Si os habéis fijado yo he creado un una única ruta por cada uso de RTC, pero podríamos tener varias rutas una para llamadas Nacionales, Móviles, Internacionales porque cada una tendría un ITSP o SBC difernte para ajustar el coste de la llamada. Yo lo he hecho más simple, mostrando solo la ruta asociada a las llamadas Nacionales, pero vosotros ajustarlo en función de vuestras necesidades. La idea es tener claro el funcionamiento de la conmutación por error y la diferencia con respecto a tener dos o más troncos en una ruta. Con los diferentes Usos de RTC podefinir el orden de utilización y se utilizará la conmutación por error de forma ordenada, cosa que con la utilización de varios troncos asociados a una ruta no sería posible.

Ahora os muestro una capturas de las Microsoft Lync Server 2013 Debugging Tools en donde vemos como una llamada es enviada a un primer tronco y como no está disponible se envía al siguiente que si cursará la llamada:

Routing_Failover_Trunk_1.png
Este tema es muy amplio y cada diseño se tendrá que ver con mucho detenimiento para no incurrir en costes de llamadas innecesarios y para obtener un sistema de conmutación por error o balancear las llamadas a través de varios ITSP. Recordad que si implantamos un sistema de Conmutación por Error, solo se pasará al siguiente uso de RTC si la llamada no se puede cursar por la ruta del primer RTC. Pero eso no quita también que podemos tener un sistema de conmutaciónp por error combinado con un sistema balanceado. Para ello tendriamos que configurar los usos de RTC que necesitemos y ordenarlos según nuestras preferencias y en las rutas asociadas  a cada RTC podríamos tener más de un tronco asociado. De esta forma tendríamos lo mejor de las dos configuraciones, y es posible que en muchos casos fuese lo más acertado. Porque de esta forma tendríamos varios troncos para cada país (siguiente con el ejemplo de este artículo), por lo que tendríamos redundancia de tronco, pero en el caso de que todos los troncos no estuviesen disponibles se utilizarán otro Uso de RTC de otro país. Si bien es cierto que si esa fuese la configuración, los troncos deberían ser de diferentes ITSP para obtener redundancia total y que los costes fuesen iguales, porque pensad que no podemos definir porque tronco se cursarían, porque a nivel de RUTA los troncos utilizan Round-Robin (se alternan las llamadas salientes).
 

Lo dicho, si queremos balancear las llamadas configuraremos varios troncos en nuestra RUTA y si queremos conmutación por error configuraremos varios usos de RTC y ajustaremos el orden  de cada uno de ellos. En las rutas no podemos elegir el orden de los troncos y en los usos de RTC si podemos ordenarlos en la Directiva de Voz, lo que nos permite definir por donde se enviarán las llamadas.

Por último me gustaria comentaros la idea del primer esquema, que bien podría representar un escenario común en muchas empresas. Tener un escenario de líneas PRI e ITSPs, de tal forma que tengamos una implementación híbrida hasta que finalmente migrásemos toda la compañía a Lync. Para ellos las llamadas externas nacionales se cursarían a través del PRI y los ITSP, pero debemos dar soporte a conectar a los usuarios de teléfono de la IP-PBX con los usuarios de Lync.

Routing Failover Trunk Esquema.jpg

Para ello contamos con la siguiente infraestrcutura:

  • 1 Mediation Server
  • 1 SBC
  • 1 Gateway
  • 1 IP-BPX
  • Varios ITSP

Debemos realizar las diferentes configuraciones antes de configurar las directivas de Voz, Usos de RTC y Rutas correspondientes:

  • Trunk SIP entre Lync y el ITSP1
  • Trunk SIP entre el SBC y el ITSP2
  • Trunk SIP entre el Gateway (Cisco en este caso) y el ITSP3
  • Direct SIP entre el SBC y la IP-PBX
  • Direct SIP entre el Gateway y la IP-BPX (podrías ser también con H.323)
  • Direct SIP entre el Gateway y el Mediation Server
  • Direct SIP entre el SBC y el Mediation Server

Y lo que queremos lograr es lo siguiente en base a dos criterios básicos (todos los usuarios estarían en el mismo país pero con llamadas Internacionales a cualquier país del mundo): Ahorro de Costes y Disponibilidad

  • Realizar llamadas externas a través de los 3 ITSP (ITSP1, ITSP2, ITSP3), para ello utilizaremos conmutación por error (varios usos de RTC y Rutas con un solo tronco)
  • Comunicar a los usuarios de Lync con los usuarios de la IP-PBX, primero a través del SBC y si falla a través del Gateway
  • Las llamadas a números nacionales se realizarán a través de la IP-PBX, puesto que tenemos una tarifa plana donde no tienen coste este tipo de llamadas , pero en el caso de que falle se tendrán que cursar a través de los ITSP (orden: ITSP1, ITSP2, ITSP3)

Para las configuraciones de los TRUNK SIP o´Direct SIP aqui os dejo algunos artículos que os pueden ser de interés:

Ahora toca configurar el entorno, desde la conectividad, TRUNK SIP, Planes de Marcado (Reglas de normalización) Directivas de Voz (Usos de RTC, Rutas). Si alguien se anima que deje un comentario en el blog y os ayudo a realizar la configuración necesaria para dar cumplimiento al objetivo principal: Ahorro de Costes y Disponibilidad. Esto podemos plantearlo como un ejercicio práctico que es muy probable que neceiste/quiera un cliente que tiene pensado migrar a Lync toda su infraestructura de Voz, pero que a su vez debe ir integrando Lync poco a poco.

Espero que os sea de utilidad!!!