​Seguro que muchos de vosotros os habréis encontrado en la situación de asesorar a vuestros clientes de que ITSP eligir, si el más barato, el que mejor soporte tiene (24x7x365), el que mejor calidad de llamada u otros valores que son importantes para vosotros. Muchas veces o en la mayoría la decisión de contratar a vuestro ITSP se decanta más por el precio que por la calidad (soporte y llamadas), y en un ámbito terrorial regional o naciona «podría» ser lo más razonable, siempre y cuando entre en las espectativas del cliente, pero que ocurre cuando el cliente tiene varias o cientos de sedes y usuarios en distintas países del mundo … (pulsar en la imagen para verla a tamaño completo)

 

Con esto podremos garantizarnos que podemos conectar directamente nuestro Mediation Server con el ITSP si necesidad de un SBC, que es recomendable (el SBC) en ciertas ocasiones, pero si podemos evitar la adquisición de hardweare mejor que mejor. Además, debemos poder disponer de informes de llamadas y poder realizar ciertas gestiones directamente desde la plataforma que nos presente el ITSP. Si es un ITSP certificado por MSFT, ya sabemos que será 100% compatible con Lync, por lo que garantizaremos que sabe lo que necesitamos para configurar el TRUNK SIP  y tráfico RTP. Esto es muy importante, porque sino os encontraréis con muchos problemas:

Esto que para los ingenieros de Lync es trivial, para los ITSP no especializados en Lync no es tan trivial entenderlo y adaptar sus configuraciones, por lo que una mala elección del ITSP podría retrasarnos nuestro  proyecto de Lync e incurrir en gastos imprevistos. Esto si hablamos de un proyecto nacional, en el cual no tenemos sedes en distintos paises, sólo con llamadas internacionales. Porque al final nosotros enviamos y recibimos las llamadas por el mismo ITSP y la configuración se reduce a un plan de marcado, directiva de voz, ruta y configuración de tronco … El coste de llamada está claramente definido, porque se suele tener una regla de oro en cuanto a las llamadas 80% llamadas nacinoales y 20% llamadas internacionales, por lo que la gestión es sencilla. Si a esto le añadimos que solo tenemos una sede y distintos usuarios en dispersos geográficamente por el mismo territorio, pues no tendremos problemas. El «problema» viene cuando nuestros clientes aumentan el número de sedes y además se van posicionando distintos continentes, en donde se asientan con nuevas sedes con decenas o cientos de usuarios a los que debemos ofrecerles el mismo servicio de telefonía. Además, todos los usuarios pueden hacer llamadas nacionales e internacionales en cualquier país en el que se encuentren y, aquí es donde nos encontramos con los siguientes problemas:

Y además de todo esto, debemos tener en cuenta el despligue de la topología de Lync que debemos realizar. No solo a nivel de Front-END y Mediation Server, sino de recursos como servidores físicos, teléfonos IP, etc… esto siempre complica el despliegue los servicios en cada país y, algo que ahora mismo no debería ser un problema se vuelve complejo no solo a nivel técnico sino también burocátrico. En este caso podemos pensar que ir contratando distintos ITSP por cada pais, porque así las llamadas nos saldrán más baratas y tendremos más inmediatez en cuanto al soporte y la gestión de cambios. Esto puede parecer así, pero al final todo se complica, porque si vamos contratando distintos ITSP necesitamos realizar más  configuraciones a nivel de Lync y de hardware que vamos a necesitar. Se pueden dar distintos casos, pero si pensamos en algo habitual como es tener una empresa por ejemplo en España y varias sedes repartidas por todo el mundo como os he mostrado en el mapa del principio del artículo. En este caso queremos realizar distintas llamadas basadas en el origen y destino de la misma:

• Origen España –> Destino USA
• Origen Venezuela –> Destino Colombia

En este caso además queremos que los usuarios de España muestren un DDI de USA, para que los clientes a los que se llamadan puedan devolver la llamada a ese DDI y para ellos sea una llamada de ámbito nacional. En cuanto a los usuarios de Venezuela queremos que puedan realizar llamadas a Colombia y también a otros países de otros continentes. Si os fijáis en el mapa veréis que el Mediation Server (y el resto de servidores de la topología están en el CPD de Madrid) enviará la llamada hacia nuestro ITSP en UKA, que tenemos un enlace de datos correctamente dimensionando y adecuado para el número de llamadas simultáneas a través de ese TRUNK SIP. Luego ya será el ITSP quien se encargará de enviar la llamada hacia su destino, pasando la comunicación a través de sus enlaces de FIBRA y ese enlace a noostros no nos afecta, porque ya es un tramo del operador y que él se encarga de mantenerlo correctamente dimensionado y configurado (QoS). Al ser un proveedor internacional suele tener presencia en los países más importantes, por lo que tendrán grandes centros de datos para dar servicios de VoIP, Internet, Virtualización, etc… y nos podrán ofrecer una calidad impecable que otros ITSP solo de ámbito local no pueden. Si en vez de tener un ITSP con presencia en varios contienentes queremos ir contratando ITSP locales, tendremos otro problema si por ejemplo queremos desde España enviar una llamada a Venezuela por una ITSP Venezolano, puesto que la llamada la enviaríamos desde España hasta el TRUNK SIP de Venezuela utilizando las conexiones de datos que tengamos en las distintas sedes, y todos sabemos que «cruzar el charco» tiene un LAG importante, por lo que sería muy complicado mantener una o varias llamadas de voz.

Con esta reflexión rápida, si pensamos en Lync como sistema de Telefonía IP para una empresa de ámbito internacional, debemos tener en cuenta para cada usuario o delegación en el país en que se encuentre puede necesitar las diferentes configuraciones:

• Negociación de códec de audio (G.711u-Law, G.711a-Law)
• Planes de marcado diferentes
• DDI para cada país
• Negociación de tarifas por cada país

Lo que al principio nos parece razonable como es ir elegiendo proveedores de Voz locales, se vuelve en muchos escenarios en nuestra contra. Para ello debemos tener claro cual sería el ámbito de las llamadas y origen-destino de las mismas, porque de ahí sacaremos un diseño efectivo de nuestro sistema de Voz: Centralizado, Distribuido o Mixto. Si tenemos usuarios en España y queremos enviar y recibir llamadas de USA desde España, lo mejor es contratar un ITSP de ámbito internacional, puesto que optimizaremos nuestras comunicaciones y configuraciones:

• Comunicaciones: Nosotros debemos preocuparnos por tener un enlace disponible para el TRUNK SIP con el ITSP, luego ya es el ITSP quien debe enviar los paquetes de Voz hacia su destino pero a través de sus líneas de Fibra
• Configuraciones: Las reglas de marcado se reducirán al máximo, porque nosotros solo configuraremos las reglas de normalización necesarias para enviar las llamadas la ITSP y luego él se encargará de enviar la llamada al destino con sus planes de marcado. Imaginaros tener que hacer esto por cada país, no pararíamos de crear planes de marcado, etc…
• Códecs: Nosotros nos tenemos que preocupar de negociar el códec con nuestro ITSP en un único TRUNK SIP, simplificando la configuración y necesidad de adquisición de hardware para transcoding, etc..
• Tarifas: La negociación del precio de las llamadas se hará con único ITSP, y cuanto más llamadas mejor será el precio de las mismas.
• DDI: El proveedor se encargará de negociar los DDI de cada país en donde él tenga presencia, nosotros únicamente debemos asignarlo a un usuario o grupo de respuesta

Si todo esto que se simplifica con un ITSP de ámbito internacional queremos hacerl contratando distintos ITSP será  todo lo contrario:

• Gestión de tarifas por operador
• Planes de marcado para cada ITSP
• Códecs por cada ITSP
• DDI por cada proveedor
• Líneas de datos adecuadas para el SIP TRUNK por cada ITSP

Además de aumentar la complejidad técnica también lo hará la burocrática, por lo que si tenemo un escenario como el comentado anteriormente, lo suyo es buscar un proveedor que tenga cobertura internacional Ahora bien, es posible tener una sede central en España y sucursales en distintos países las cuales su ámbito principal de emisión y recepción de llamadas sea local, entonces aquí el planteamiento cambiará, puesto que el tráfico de datos no se hará más allá del proveedor local, por lo que lo suyo sería configurar un TRUNK SIP con un ITSP local para todas las llamadas locales. Para ello lo suyo sería configurar un Sitio de Sucursal con funciones de supervivencia, el cual configuraremos con registrador para los usuarios de Lync de ese país y además el TRUNK SIP con el ITSP local. Aquí tendremos que configurar sus planes de marcado, directivas de voz, rutas, etc… pero aquí es necesario para no tener que enviar la llamada a España para enviarla al ITSP Internacional y luego enviarla de vuelta al país en donde nos encontramos. Si lo hiciésemos así estaríamos utilizando las líneas de datos de forma incorrecta, aumentando la utilización de la misma sin tener porqué.  Aquí lo suyo es tener un ITSP local y que se envíen las llamadas a través de él. Esto difiere del concepto de que desde España (sitio central) tengamos que hacer llamadas a otro país, puesto que si tenemos que configurar un TRUNK SIP con el operador local de ese país tendremos que tener un enlace de calidad entre nuestro Lync y ese ITSP y como os comentaba antes, atravesar el charco u otros países con líneas de datos convencionales siempre será un problema, de ahí que lo suyo es tener un ITSP que sea capaz de llegar a través de sus líneas de fibra y que él mismo entregue las llamadas localmente y nosotros preocuparnos del TRUNK SIP entre nuestro Mediation Server y su servidor que sería con líneas de datos ya optimizadas y dedicadas para ello.

En el caso de recepción de llamadas desde DDI de otros países es lo mismo, nosotros solo debemos preocuparnos de nuestro TRUNK SIP con el operador, pero con su sede más cercana a nuestro país de tal forma que nos garantizamos una buena conectividad. Además, de que nuestros planes de marcado, reglas de normalización, etc.. serán las que tengamos con nuestro ITSP no con el resto de operadores del mundo, para eso ya tenemos al ITSP que se encarga de realizar las reglas de conversión necesarias antes de enviárnolas a nosotros.

Como véis la idea es tener claro el tipo de llamadas que haremos, el origen/destino de las mismas y las líneas de datos a utilizar. Si podemos hacer que el ITSP se encargue de todo, no lo dudéis, que se encargue él que tiene sistemas más complejos y dedicados para ello que nosotros. Ahora bien, seguro que se os ocurrirá la pregunta de .. ¿Qué ocurre si el ITSP tiene algún problema con el TRUNK SIP o con sus líneas de Fibra? Claramente tendremos el sistema caído durante este tiempo, pero os aseguro que si esto ocurre seguro que todos tendriamos otros problemas. Pensad que ellos utilizan líneas de Fibra que conectan a distintos operadores en todo el mundo, con caudales garantizados de GB y además súper redundados. Pero si aún así nos os vale esto, puesto tendríamos que contratar un segundo o tercero ITSP para tener un plan de contingencia para las llamadas salientes, porque las entrantes si tenemos los DDI portadas en un operador es el quien nos la pueden enviar. Y con esto se me ocurre comentaros que con  un solo ITSP (en condiciones claro) al resolución de problemas será más fácil, porque tener muchos proveedores siempre dificulta la resolución de problemas.

Esto es puede contar de muchas formas, pero vamos, yo lo tengo claro, optimizar los recursos pasar por tener un ITSP de ámbito internacional y con líneas de fibra propias a poder ser y certificado por MSFT si utilizamos Microsoft Lync. Ahora es cuestión de que vosotros analicéis vuestra situación o la de vuestro cliente y busquéis la mejor opción.

Espero que os haya sido de utilidad!!!