Llevo bastante tiempo detrás de una configuración similar a la que voy a comentar en este artículo, ​una configuración de un TRUNK SIP con un ITSP desde en Lync/Skype4B. Esto es algo sencillo y aparentemente no tiene nada de especial, pero cuando nuestro Mediation Server está configurado con una IP Privada (una red con un dispositivo configurado con NAT, una configuración más habitual) la cosa cambia ….. (pulsar en la imagen para verla a tamaño real)

El visio me ha salido demasiado grande, por lo que la imagen para verla con cierta calidad no he podido reducirla mucho, tiene un tamaño de 6MB. Por lo tanto, aquí os dejo el esquema en PDF, JPG y VSDX (formato Microsoft Visio) 

• Integración Lync-Skype4B con Asterisk.pdf
• Integración Lync-Skype4B con Asterisk_Esquema.jpg
• Integración Lync-Skype4B con vCloud SBC.vsdx

Para poder realizar todas las configuraciones que veréis a continuación, he contado con la colaboración de la gente de Nectar Company (http://www.nectarcompany.com), en especial de Carlos Presa (Software Developement Manager) y Daniel Rubio (VAR Channel Developer). Ambos han puesto tecnología (servidores virtuales para los SBC, Trunk SIP, DDI, etc..) y su tiempo para poder desarrollar en conjunto un SBC para dar servicio a clientes con Lync o Skype For Business. Desde aquí quiero agradecerles todo el esfuerzo que han realizado para que ahora estemos en disposición de ofrecer un SBC de garantías, en este caso para Lync y Skype For Business, puesto que para otras plataformas Nectar Company ya lleva años ofreciendo este servicio.

 

Antes de centrarme en la parte técnica, me gustaría poneros en situación para que conozcáis el porqué de este artículo y que me ha motivado a publicarlo. A priori debería ser una articulo más, su dibujito y sus capturas de pantalla, pero la realidad es que tiene un transfondo para mi muy importante que ahora os voy a comentar.  Todo empieza con la necesidad clara de que Lync o Skype For Business para las empresas sea sólo un sistema de mensajería, presencia y "poco más" (así es como lo perciben muchos clientes que no conocen esta pedazo de herramienta), sino una potente herramienta de Comunicaciones Unificadas la cual puede reemplazar con total garantías a las PBX tradicionales o Sistemas de VoIP  que sólo ofrecen telefonía (llamar/recibir). Para ello debemos conectar el mundo Lync/Skype4B con las PBX o ya directamente con algún ITSP que nos ofrezca troncales SIP y así cursar y recibir todas nuestras llamadas Voz a través de ellos. Antes de esto debemos analizar muy bien el impacto del cambio en el cliente, los pasos de adopción de la tecnología y además ver los elementos con los que debemos contar antes de migrar el sistema de voz de los clientes a Lync/Skype4B. Y además, debemos tomar una decisión importante, con que ITSP (Proveedor de Telefonía IP) nos vamos de la mano en esta aventura:

Aquí os dejo un artículo que había publicado en su momento: ¿Qué debemos tener en cuenta cuando elegimos un ITSP?).

Debemos analizar la utilización o NO de SBC para la integración de Lync/Skype4B con las IP-PBX de los clientes para mantener un entorno híbrido mientras no se haya migrado el 100% de los usuarios a Lync/Skype4B. Como en mi caso siempre he trabado con Cisco para esto, he utilizado en la mayoría de los casos hardware Cisco para ello, aqui os dejo algunos articulos que había publicado en su momento sobre este tema:

Aquí también os dejo un artículo que me parece interesante en este caso, en el cual vengo a mostrar una configuración de como configurar un entorno híbrido entre Lync y una o varias IP-PBX de un cliente utilizando para ello un Cisco CME 8.1: Migrar un entorno IP-PBX a Lync 2013. Esta configuración tiene una complejidad añadida, que es que la configuración es multisede con una VPN configurada tamibén con Routers Cisco y utilizando IPSec (Autenticación con Certificados Digitales): Cisco VPN IPSec Site-to-Site con Certificados Digitales

Por último no debemos dejar algunos de los detalles más importantes del proyecto, los cuales había comentado en este artículo (bajo mi punto de vista claramente): El Éxito o Fracaso de los Proyectos de Comunicaciones Unificadas con Lync

Repasado todo esto y habiendo realizado ciertos proyectos y pruebas, me faltaba una pieza para completar el puzzle: "Que Lync/Skype4B pueda realizar y recibir llamadas con un Troncal SIP con un ITSP sin SBC local y detrás de red con NAT". Seguramente estaréis pensando,  que chorrada!!!! esto se hace sin problemas, etc.. y estáis en lo cierto (pero a medias o por lo menos ), pero siempre dependemos de un proveedor que lo haga y  en muchos casos me he encontrado en que el ITSP no tenía soporte para configuraciones con Lync/Skype por varias razones:

Claro, si buscamos un ITSP certificado por Microsoft (como era y es el caso de Interoute) no tendremos problemas, todo funcionará sin problemas. Pero si bien es cierto, que esto ISTP buscan clientes de cierto tamaño (volumen de llamadas), por lo que el coste del servicio con relación tipo de cliente no era lo esperado. Y claro, al final en los tiempos que corren hay muchísimas empresas que ofrecen troncales SIP, pero poco son los que tienen soporte para Lync/Skype4B (ojo, que funcione no quiere decir que tengan soporte o garantías del buen funcionamiento). Como comentaba, en muchas ocasiones me he pasado varias horas con los técnicos de soporte de varios ITSP y siempre llegaban a la misma conclusión: "Esto es un problema de Lync, NO nuestro" Y mi respuesta siempre era la misma: Esto con Interoute siempre ha funcionado a la primera, eso sí, siempre me habían pedido mi IP Pública y Privada en donde está el Mediation Server". Esta era la información que yo les podía ofrecer, porque realmente nunca he visto la parte de un operador. Pero claro, como discutir con alguien en donde las trazas de Wireshark decian que siempre se devolvía el tráfico a la IP Privada de mi Mediation Server y así era imposilbe (como es lógico). Pensad que siempre hablo del mismo escenario basado en algo similar a esto por parte del cliente que tiene una implementación de Lync/Skype4B (pulsar en la imagen para verla a tamaño real):

Desde mi experiencia es un entorno real en muchísimas empresas hasta cierto tamaño, una red con un Router/Firewall que tiene varias interfaces internas y que crea una DMZ para publicar cierto servicios y que luego vía redirección de puertos publicar otros desde la red local. Esto es más que común, incluso si DMZ. En el escenario que os muestro, tengo un router que tiene dos interfaces, una que será una zona DMZ en donde están los servidores del EDGE de Skype For Business y un Reverse-Proxy para publicar todos los servicios de Skype For Business, Exchange, etc.. y luego otra interface que es la que  da salida a Internet a los equipos internos de la LAN, algo más que trivial en las empresas pequeñas. Y como el Front-END o Pool de Mediation Server están dentro de la red local, pues si queremos que se accesible desde Internet tendremos que redireccionar el puerto que queramos en el router y enviarlo al Mediation Server en este caso para poder establecer un Troncal SIP con un ITSP. Esto es sencillo de entender, en la DMZ equipos que no tienen que estar en el dominio y la red LAN los equipos del dominio. Dicho esto, si queremos crea un Troncal SIP con un ITSP, debemos redireccionar las peticiones de internet que lleguen al puerto configurado en el Mediation Server (SIP: 5060, 5068, etc..) hacia el propio Mediation Server (IP Privada). Algo tan sencillo como eso, pero claro, ahí viene la dificultad, estar detrás de NAT y querer utilizar servicios de VoIP (tráfico RTP).

Esto se puede solucionar con un SBC y una IP Pública asociada directamente al SBC, pero yo no quiero SBC en lcoal cuando no son extrictamente necesarios y explico el porqué a continuación, pero antes os expongo algunas funcionalidades interesantes de los SBC:

Hay algunos beneficios más, pero me centro creo que en los más destacables e importantes. Ahora voy a tratar de rebatirlos uno a uno, seguramente esté equivocado, pero es mi forma de verlo:

Podríamos estar hablando de esto horas y no nos entenderíamos (porque seguro que hay gente que piensa de forma contraria a la mia, y no pretendo tener razón, solo argumentar mi criterio), por lo que cada uno saque las conclusiones que considere oportunas. Yo creo que el escenario en donde tenemos que tener un SBC es si o si con el tema del transcoding para interconectar Lync/Skype4B con otras plataformas internas del cliente, pero para crear un troncal SIP, NO. Estamos en un momento en donde todo está virtualizado, en donde traspasamos responsabilidades (vendita palabra: OutSourcing) a los proveedores para todo (IT, Nóminas, Contabilidad, RRHH, etc..) y queremos  un SBC en local? Yo sinceramente no lo veo, siempre y cuando no sea indispensable.  Espero que nadie se sienta atacado ni mucho menos por este comentario, creo que soy de los que me gusta que las cosas  vayan en la línea de como tiene que ir (VPN, Redes Wi-Fi, Redes Cables, etc.. con Certificados Digitales y más mecanimos de protección), pero hay que saber cuando es o no necesario. Y yo creo firmemente que tener un SBC en nuestro lado cuando lo puede tener el ITSP y manejarlo él, lo veo clarísimo. Además, cuando hay proveedores que lo hacen sin problema y con Lync/Skype4B funciona a la perfección.

Después de  mi reflexión sobre tener los SBC en instalaciones On-Premises para troncales SIP, os sigo contando mi experiencia con los ITSP que no tiene "soporte" para Lync/Skype4B. Después de muchas horas de troubleshooting con los ITSP, como os comentaba, siempre llegaba a la misma conclusión: El problema lo tiene Lync/Skype4B!!! Y ya no sabía como explicarles que así lo tenía con otros ITSP y que funcionaba, pero claro esos ITSP tampoco nunca te dicen que hacen ellos (como es normal) para que funcione con Lync/Skype4B. Pero claro, aun entendiendo que el ITSP no me diga que hacen para que funcione, no puedo evitar sentirme frustado porque la gente no comparta su conocimiento (aquí no voy a entrar mucho que sino me voy a liar y mucho), porque esa es mi máxima en este blog: Artículos completos, claritos y con una carga gráfica lo suficientemente importante como para que cualquier persona pueda realizar las configuraciones que voy exponiendo. Yo siempre que me conecto a algún blog, no espero que nadie sea el primero en poner algo novedoso o el único, sino que alguien lo explique con el nivel de detalle necesario para que el resto lo podamos entender. Y esa máxima es la que he seguido y seguiré en este blog mientras a vosotros os parezcan interesantes los artículos publicados. Justo esto es lo que me ha motivado a buscar día y noche información para desplegar mi troncal SIP con un ITSP y mi Lync/Skype4B sin SBC local, que funcionase sin problemas y explicar con todo el nivel de detalle que pueda como podéis hacerlo y el porque no funciona el tráfico RTP detrás de NAT sin la configuración adecuada. Algo que llevo preguntando a mucha gente y nadie me da una repuesta, algunos ni contestan y otros me dicen que es problema de Lync/Skype4B (que no digo que no, pero … ya veréis en la segunda parte de este artículo que no es así).

Por todo esto y gracias a Nectar Company (http://www.nectarcompany.com), en especial de de Carlos Presa (Software Developement Manager) y Daniel Rubio (VAR Channel Developer) me he puesto manos a la obra para implementar un SBC para conectar por un lado al ITSP y por otro a Lync/Skype4B (detrás de NAT claramente) sin SBC local!!! Como os comentaba, me ha costado un poco porque me he tenido que poner con cosas que no he tocado nunca (ASTERISK, si si, habéis léido bien, ASTERISK), pero al final el trabajo y esfuerzo me ha dado muchas satisfacciones al ver que funciona perfectamente. Realmente, el escenario final es el que esquema que os he puesto al principio. Un SBC en donde se conectan varios clientes con Lync/Skype4B y luego el SBC al ITSP para enviar y recibir las llamadas que luego se entregarán y cursarán desde los servidores de Lync/Skype4B de cada cliente. Vamos, un vCloud SBC en toda regla. Y claro,  una vez que veía  que todo funcionaba bien, había que buscar un entorno de Alta Disponibilidad y hecho también, con varios niveles de redundancia:

• Varios SBC
• Varios Troncales SIP en cada SBC

De tal forma que en Lync/Skype4B se puedan configurar dos troncales SIP, uno por SBC y si falla uno de ellos se pasaría a utilizar el siguiente SBC. Así el cliente, simplemente configura el Troncal SIP, reglas de normalización, directiva de Voz, RTC, Rutas y Troncal  que necesite (pero el trabajo es trivial y muy sencillo.) Además, como los SBC los puedo manejar sin problema, todo va normalizado vía E.164 facilitando así el número de reglas que los técnicos de Lync/Skype4B tienen que realizar en sus instalaciones.

En los SBC como os comentaba, hay dos Troncales SIP por cada cliente (porque son los troncales por donde recibirán y cursarán las llamadas) que van o bien al mismo ITSP pero a plataformas diferentes (su Alta Disponibilidad) o bien a ITSP diferentes (aquí tendriamos un problema con las llamada entrantes, porque si falla el ITSP al cual hemos hecho la portabilidad no podremos recibir llamadas). Pensad que los SBC tendrán un troncal con el ITSP y otro con el cliente, por eso necesitamos varios troncales SIP hacia los ITSP y solo uno por SBC con el Lync/Skype4B.

Pues comentado esto, en el próximo artículo (es que sino este se hará muy extenso) comentaré con todo el nivel de detalle que pueda la configuración del entorno que he comentado.

Comentaros, que este servicio será comercializado por Nectar Company y ASIR INTRASITE por si alguien está interesado en probarlo, soló tenéis que solicitarlo bien dejando un comentario en este blog o desde la web de Nectar Company (http://www.nectarcompany.com), comentando que habéis visto el servicio del vCloud SBC en este blog. Además, os ayudaremos a configurar vuestros Lync/Skype4B si fuese necesario, pasarse al mundo de VoIP con Lync/Skype4B nunca será tan fácil.

Si bien es cierto que esta configuración será explicada con el nivel de detalle suficiente, para que luego vosotros los implementéis en donde queráis y así logremos que el conocimiento se extienda lo máximo posible. Si alguno se pone a ello y necesita ayuda, contar conmigo que estaré encantado. Y si además podéis enviar vuestros comentarios de como os ha ido, será todo un placer leeros.

Por último y antes de concluir este artículo, daros las gracias por seguir este humilde blog, para mi es un placer saber con vuestros comentarios que os agrada la información que expongo. Que siempre trato de ser muy claro y explícito en los comentarios, con la idea de llegar a todos los que invierten su tiempo en leer lo que un servidor escribe.

Ahora darme unos días para completar el siguiente y última parte de este artículo, seguro que os gustará.