Microsoft Lync Server
Header

Ayer MSFT ha publicado que ya podenos realizar video llamadas entre Lync 2013 y Skype (http://blogs.office.com/2014/12/05/video-calling-skype-lync-available-now/)​, por lo que había que probarlo, pero debemos cumplir varios requisitos:

Una vez cumplido los requisitos previos, ya podemos lanzar una videollamada de Skype a Lync o viceversa

7Lync-Skype Videollamadas-6.png

Y como vemos ya tenemos estamos conectados mediante una video llamada entre Lync y Skype, algo que ya estábamos esperando desde hace tiempo.

Lync-Skype Videollamadas-12.png

A nivel técnico la parte de seguridad es fundamental y MSFT así lo demuestra, soportando TLS y SRTP por defecto, además de STUN, TURN, ICE y video de alta calidad con el códec H.264 SVC.

Lync-Skype Videollamadas-14.png

De momento solo está soportada la videollamada entre Lync y Skype con el cliente de escritorio para Windows (iniciando sesión con una cuenta de MSFT), pero pronto llegará para el resto de plataformas. Ahora ya sabéis, os toca probarlo y configurar vuestra federación sí aún no lo habéis hecho!!!

Espero que os sea de utilidad!!!

Excelente noticia que tenemos por parte de MSFT, ya podemos tener videoconferencia entre Lync y Skype!!! http://blogs.office.com/2014/12/05/video-calling-skype-lync-available-now/

Today’s post was written by BJ Haberkorn, director of product marketing for the Lync Team
Editor’s Note:
The video calling with Lync requires Skype for Windows desktop client version 7.0.x.100.  We are experiencing issues with some browser versions where an older client is downloaded.  If you’ve downloaded at the link below, and the version is not 7.0.x.100, please download using a different browser.
 
In 2013, we enabled Lync users to contact people on Skype using instant messaging, presence, and audio calling right from your contact list. I’m happy to say that we’ve now taken the next step by adding video calling between Lync 2013 and the latest Skype for Windows desktop client, available for download here. Now Lync users can conduct everyday business and collaboration “face-to-face” with customers, partners and suppliers who use Skype.
Skye Lync video
The screenshot above shows a video call from the Lync perspective. Whether you’re using Lync or Skype, it’s an easy, familiar experience—you make the video call the same way you make any other call, with the same options for starting, stopping, re-sizing and maximizing video. (As you can see from the picture, Elaine and Sean are pretty excited about the update; Elaine blogged about it on Skype.com.)

The best of both

What’s not obvious from the screenshots is the work we’ve done in the underlying media stack to enable the connectivity. Lync and Skype have always delivered phenomenal voice and video experiences to business and consumer users across a wide range of environments and network conditions. Now, we’re taking the best of both to make both even better.
This includes built-in security, with enterprise class encryption of both media and signaling using TLS and SRTP, enabled by default. It includes connectivity, with standards-based traversal of personal and corporate firewalls using STUN, TURN and ICE. It includes high quality, scalable video using the industry standard H.264 SVC codec. Finally, it includes the SILK audio codec as the default choice for Lync to Skype calls. SILK is used for billions of minutes of audio calls every day, and provides a phenomenal balance between audio quality, bandwidth utilization and power consumption.
The provisioning guide for Lync-Skype connectivity includes instructions for both Lync Online and Lync Server 2013 customers to enable the capability, and the end user guide shows how to add contacts and make calls. The video calling requires an up-to-date Lync 2013 client on either Android, iOS or Windows. It works today with the latest Skype for Windows desktop client only, and requires that the Skype user sign in with their Microsoft account.

What’s next

As excited as we are about this, we know we have more work to do. We will extend support to the Skype clients on additional platforms, starting with Android and iOS in the coming months. We will add support for SkypeIDs and make it easier to find and add contacts from the worldwide Skype directory when the next version of Lync becomes Skype for Business in the first half of 2015. These planned improvements to Lync Skype connectivity are just one example of how Skype for Business will keep and improve on all of the capabilities of Lync.
Stay tuned for more updates on Skype for Business, by following our social channels (Facebook | Twitter | LinkedIn) and talking your Microsoft sales specialist or partner. We’d also love to see you at one of the worldwide Office 365 Summit events, where, starting in mid-January, we plan to share more details on Skype for Business.
— BJ Haberkorn

Introducing Skype for Business

Today’s post was written by Gurdeep Pall, corporate vice president for Skype.
Yesterday we kicked off a global conversation about how Microsoft is reinventing productivity—across the board—to create a world where people can truly make the most of their time and lead more fulfilling lives.  Connecting people across all of life’s moments—to talk, to share, to collaborate—is at the heart of helping people make the most of every moment.  To that end, and for our business customers, we are bringing together the familiar experience and user love of Skype with the enterprise security, compliance and control from Lync to create the most loved and trusted communications platform for doing things together.
A decade ago, Skype broke down the distance barrier by bringing people together from all over the world.  It forever changed the way people shared their lives by getting friends and family together to celebrate special moments and create extraordinary bonds.  Today, Skype is so much more.  It’s used by more than 300 million people for messaging, calling and sharing.  It lets people and groups connect in more spontaneous ways across multiple platforms to have fun and get things done.  From desktop, to mobile to TV—it’s for communicating throughout the day, every day.  Skype is a universal symbol of togetherness.
For the past 10 years, Microsoft has invested in the transformation of business, disrupting the status quo with Lync, by simplifying and unifying all of the different tools people used to communicate for work.  We made Lync a core part of Office to make it easy for people to connect with others to get work done.  Lync means the freedom to work anywhere. It’s like tapping someone on the shoulder to say “let’s chat” no matter where you are in the world.  Colleagues meet together and make decisions in an instant and IT Professionals rest easy knowing their end-users are supported by a secure platform for that they manage and control.   Today, thousands of organizations, large and small, count on Lync for voice, video and conferencing.
Skype for Business 1
 
In the first half of 2015, the next version of Lync will become Skype for Business with a new client experience, new server release and updates to the service in Office 365.  We believe that Skype for Business will again transform the way people communicate by giving organizations reach to hundreds of millions of Skype users outside the walls of their business.
Let’s take a peek at what’s to come:
 
Skype for Business 2
 
We’re really excited about how Skype for Business takes advantage of the strengths of both Skype and Lync. For example, as you can see in the screenshots, we’re adopting the familiar Skype icons for calling, adding video and ending a call. We’ve added the call monitor from Skype, which keeps an active call visible in a small window even when a user moves focus to another application.
At the same time, Skype for Business keeps and improves on all of the capabilities of Lync, including content sharing and telephony.  For example, transferring a call now takes only one touch or click instead of three.
We’re also making it easier to connect to people everywhere. Lync already offers instant messaging and audio calling with Skype users. Skype for Business adds video calling and the Skype user directory making it possible to call any Skype user on any device.
Current Lync Server customers will be able to take advantage of these capabilities simply by updating from Lync Server 2013 to the new Skype for Business Server in their datacenters. No new hardware is required.  For Office 365 customers, it’s even simpler.  We’ll do the required updates.  And because communications is mission-critical, this release meets a new bar for reliability and performance.
 
Skype for Business 3
 
Microsoft is already a market leader in communications. I’m confident that no other company in the world can connect people like Microsoft can. Stay tuned for more updates on Skype for Business and how we reimagine the technologies people use to communicate.  If you’re a current customer, ask your Microsoft sales specialist or partner about Skype for Business and follow our social channels (Facebook | Twitter | LinkedIn) for updates.

 

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

Microsoft Lync Phone Edition for Polycom CX500, Polycom CX600 and Polycom CX3000

Microsoft® Lync™ Phone Edition for Polycom® CX500, Polycom® CX600 and Polycom® CX3000 is the first generation of software designed specifically for the phones from Polycom to interoperate with Microsoft® Lync™ Server…  

Microsoft® Lync™ Phone Edition for Polycom® CX700 and LG-Nortel IP Phone 8540 is the next generation of software designed for the phones from Polycom and LG-Nortel to interoperate with Microsoft® Lync™ Server 2010 or Microsoft…
 
Microsoft® Lync™ Phone Edition for HP 4110 and HP 4120 is the first generation of software designed specifically for the phones from HP to interoperate with Microsoft® Lync™ Server 2010. and Microsoft® Lync™ Server 2013…
 
Microsoft® Lync™ Phone Edition for Aastra 6721ip and Aastra 6725ip is the first generation of software designed specifically for the phones from Aastra to interoperate with Microsoft® Lync™ Server 2010 or Microsoft® ….