Cómo diseñar e implementar una red VoIP corporativa

En un entorno empresarial altamente competitivo y dinámico, disponer de un sistema de comunicaciones de voz y datos eficaz y eficiente es clave para el éxito de cualquier organización. La tecnología de Voz sobre IP o VoIP ha revolucionado la forma en la que las empresas implementan su red interna de comunicaciones telefónicas. La tecnología IP proporciona una solución escalable, rentable y versátil, tanto para las necesidades de telefonía como de datos. Veamos cómo diseñar e implementar una red VoIP corporativa.

En este artículo exploraremos los pasos fundamentales para diseñar una red VoIP corporativa. En este estudio se verá cómo determinar las necesidades de interconexión de las distintas sedes de la empresa para las necesidades exclusivas de voz. Si fuese necesario, la empresa podrían ampliar estos circuitos para cubrir las necesidades del resto de datos IP de la empresa. De esta forma, se podría crear una red IP corporativa que cubriera todas las necesidades de comunicaciones internas de la empresa. Una de las ventajas adicionales de esta solución es la posibilidad de controlar las comunicaciones con el exterior de una forma más fácil y eficiente.

Por otro lado, una vez determinadas las necesidades de interconexión de las distintas sedes, existen distintas posibilidades de implementarlas. Una opción es implementar circuitos circuitos dedicados punto a punto. Esta conexión no supone la utilización en exclusiva de un medio, sino que simplemente garantizan un ancho de banda determinado entre los dos puntos interconectados. Alternativamente, también se pueden establecer circuitos virtuales de tipo VPN (Virtual Private Network) entre esos puntos. Estos circuitos utilizan internet para la conexión, pero cifran las comunicaciones de extremo a extremo, de forma que se garantiza igualmente la privacidad.

Por cierto, si no recuerda algunos de los conceptos tratados en este artículo, o está interesados en conocer con detalle cómo funciona la telefonía IP o VoIP, pueden consultar este contenido: VoIP. La telefonía de Internet.

Crear una red corporativa de VoIP

El gran reto de las redes corporativas es conseguir cumplir con las tres C: capacidad, calidad y coste. Esto es lo equivalente a las tres B de toda la vida: bueno, bonito y barato. Esto significa que el objetivo es disponer de una red que sea capaz de responder a todas las necesidades de comunicaciones de la empresa con una buena calidad de voz y a un coste reducido de implantación, operación y mantenimiento.

Como ocurre en la vida cotidiana, si queremos algo bueno y bonito, posiblemente tengamos que renunciar a que sea barato. O si encontramos algo barato y bonito, quizás no resulte ser tan bueno. En el caso de las redes, buscar ser excelentes en dos de las C suele significar sacrificar la tercera.

No obstante, el diseño de una red no se basa en los mismos parámetros que el de la compra de un artículo de consumo. En este caso, durante el proceso de estudio podemos evaluar cómo el cambio de un parámetro influye en los otros. Por ejemplo, si deseamos una red con más capacidad, podemos calcular cuál será el incremento del coste manteniendo la calidad. Igualmente, podemos calcular la disminución de calidad, si nos decidimos a mantener el coste (a base, por ejemplo, de ahorrar ancho de banda utilizando un codec distinto).

Dicho de otra forma, el proceso de diseño termina siendo una búsqueda de puntos de equilibrio: conseguir que el presupuesto sea ajustado para construir una red que cubra nuestras necesidades a corto o medio plazo con una calidad aceptable.

Quiere esto decir que el construir una red corporativa requiere una fase de estudio que permita decidir dónde se encuentra el punto de equilibrio en cada caso. Los pasos a dar son los siguientes, aunque no necesariamente en este orden:

Consideraciones de diseño. Las necesidades de cada empresa pueden ser muy distintas. Unas empresas son locales y otras multinacionales, para una empresa puede ser muy importante la calidad, mientras que para otra lo importante podría ser el coste. Antes de empezar a diseñar la red es necesario definir las necesidades a las que debe dar respuesta dicha red, así como decidir determinados criterios de diseño como son: codec, tecnología de red (SIP o H.323), supresión de silencio, etc.
Demanda de tráfico. Otro de los puntos importantes es cuantificar el tráfico esperado. Comprender de dónde procede y hacia dónde va el tráfico, en qué cuantía y cómo crecerá en un futuro.
Topología de la red. El cómo se interconectarán los distintos elementos de la red suele depender de su distribución geográfica, aunque también hay que tener en cuenta otros factores como la seguridad, la funcionalidad o el coste.
Selección de proveedores. Una vez definida la red, llega el momento de salir de compras. Elegir el proveedor adecuado para el equipamiento y la interconexión de la red es casi más importante que todo el proceso anterior. De hecho, este paso podría condicionar algunas de las decisiones anteriores.

Conviene destacar que el proceso de diseño no suele ser un camino inflexible. A veces, una conclusión puede llevar a replantearse alguna decisión anterior.

Consideraciones de diseño

La primera aproximación al diseño de la red debe ser realizar un boceto de las necesidades y consideraciones a tener en cuenta. Esto nos permitirá hacernos una idea de adónde queremos llegar y cómo vamos a realizarlo. Por ejemplo, puede que se tenga una limitación de presupuesto o unas necesidades específicas de comunicación. Todo esto condiciona el diseño de la red.

Entre las consideraciones previas a tener en cuenta en el diseño de una red de VoIP se encuentran las siguientes:

Dimensión. No es lo mismo diseñar una red para un edificio que una gran corporación con presencia internacional. El primer paso es hacerse una idea de las dimensiones de la red. Dependiendo de esto podremos plantearnos otras consideraciones. Por ejemplo, si la red corporativa se limita a un edificio, puede no tener sentido hablar de ahorro de ancho de banda.
Herencia. Aunque una red de VoIP se diseña para cubrir exclusivamente las necesidades de comunicaciones de voz de la empresa, puede que se tenga que compartir esta red IP con la red de datos existente. Igualmente, es necesario aclarar si se va a reutilizar alguna parte del equipamiento existente. Estas consideraciones limitarían el diseño de la red.
Evolución. Aunque tengamos claro las necesidades actuales de capacidad de la red, generalmente, suele ser aconsejable construir la red para cubrir las necesidades futuras en el plazo de uno o dos años, después de todo, no se puede estar ampliando la red cada día. Esta capacidad extra no sólo se podrá utilizar para absorber el crecimiento del tráfico a corto o medio plazo, sino que servirá también para absorber posibles sobrecargas puntuales de la red (no previstas) o, en determinados casos, paliar los efectos del fallo de un equipo. Desde este punto de vista, podría ser interesante considerar las necesidades de red a un año o diseñarla para que la carga real sea del orden del 70 u 80% de su capacidad total.
Tecnología. Existen distintas soluciones técnicas para la VoIP. Por ejemplo, se puede utilizar SIP o H.323, Megaco o MGCP un codec u otro. A falta de un mejor criterio, los protocolos favoritos a utilizar serían SIP y Megaco. No obstante, los proveedores de equipos tienen algo que decir a este respecto. Es posible que una buena oferta de un proveedor (que no admite los protocolos elegidos) justifique la utilización de otros protocolos.
Calidad. Por último, habría que decidir el tipo de calidad de servicio que se va a ofrecer. Desde este punto de vista tenemos que tomar distintas decisiones. En primer lugar, se tendría que definir si se va a utilizar un protocolo de QoS y, en caso afirmativo, cuál sería. Ya sabemos que RSVP ofrece la mejor calidad, pero también en bastante más complicado de implementar que DiffServ. MPLS puede ofrecer lo mejor de ambos sistemas. En cualquier caso, esta decisión está vinculada con el protocolo de nivel 2 que se va a utilizar (por ejemplo, ATM, Frame Relay o PPP). Por ejemplo, de utilizase ATM no sería necesario utilizar ningún protocolo QoS. Como generalmente se utiliza PPP, el protocolo MPLS podría ser una elección razonable. Otra de las decisiones es el codec a utilizar. Aunque G.711 es el codec que ofrece una mayor calidad, también es el que ocupa un mayor ancho de banda. Soluciones como G.723, G.726 o G.729 ofrecen una buena calidad utilizando un menor ancho de banda. Por otro lado, algunos codecs permiten definir el intervalo de paquetización. Utilizar grandes intervalos de paquetización (paquetes grandes) supone que el peso de la cabecera disminuya, por lo que también disminuye el ancho de banda necesario. No obstante, los paquetes grandes suponen un mayor retardo, lo que influye en la calidad. Generalmente, un intervalo de paquetización entre 20 y 40 milisegundos ofrece un buen equilibrio entre calidad y ancho de banda necesario. Por último, las técnicas de supresión de silencio permiten ahorrar un gran ancho de banda, aunque puede introducir algo de retardo. Idealmente, antes de tomar una decisión definitiva sobre las distintas decisiones que afectan a la calidad de servicio, podría ser conveniente realizar pruebas reales para comprobar su influencia en la topología real de la red.

Como ejemplo de cálculo, vamos a diseñar una red de voz sobre IP para una empresa con las siguientes consideraciones:

Tiene las oficinas centrales en Madrid, donde trabajan 450 empleados, y sedes en las siguientes ciudades: Sevilla 100 empleados, Bilbao 100, Barcelona 150, París 200, Londres 150, Ámsterdam 100 y Munich 150 empleados.
Para sus comunicaciones de voz dispone de centralitas en cada dependencia y cuenta con una red IP corporativa para sus comunicaciones de datos. La idea es interconectar las distintas centralitas mediante VoIP aprovechando los enlaces IP de la red de datos.
La red se diseñará para disponer de un 20% de capacidad sobrante. La carga real será, por tanto, un 80% de la capacidad total.
Se usarán los protocolos SIP, Megaco y MPLS
El codec será G.729 con intervalo de paquetización de 20 milisegundos y supresión de silencio.
Supondremos que el mes tiene 21 días laborables y que el 95% del tráfico se produce en estos días.

Necesidades de comunicación de la empresa del ejemplo. Diseño de una red VoIP empresarial — Necesidades de comunicación de la empresa del ejemplo

Demanda de tráfico

El diseño de una red de comunicaciones gira en torno a los flujos de tráfico a los que se desea dar respuesta. Esto significa que es importante conocer tanto el tráfico que entra y sale de cada una de las sedes de la empresa como el origen y destino de cada uno de ellos. La definición de estos flujos de tráfico, junto con las consideraciones anteriores, nos permitirá decidir la topología y dimensión de la red, así como el tipo de equipamiento necesario.

Para definir los flujos de tráfico, habría que conocer el número de sedes, su localización, número de usuarios por sedes y comportamiento de los usuarios. En el caso de que la red a diseñar sea una evolución de una red existente será fácil recabar toda esta información, bastará con consultar los datos del registro de llamada de las centralitas actuales. Estos registros se conocen como CDR (Call Detail Record, ‘Registro de los detalles de llamadas’). En su defecto se pueden comprobar los detalles de las facturas o, incluso, realizar mediciones.

Si de lo que se trata es de diseñar una red de la que se carecen antecedentes, habrá que recurrir a realizar estimaciones de uso. Estas estimaciones pueden realizarse de una manera simple suponiendo un tráfico medio por usuario y unos flujos básicos de tráfico (por ejemplo, el 80 por ciento de la comunicación se realizará con la sede central y el resto entre sedes); o se podrá profundizar más en estas estimaciones teniendo en cuenta la ubicación de los distintos departamentos y la interrelación entre ellos.

Por ejemplo, generalmente, los empleados de áreas comerciales suelen hacer un uso más intensivo de las comunicaciones que los de áreas técnicas. Un área de atención de reclamaciones suele tener la mayoría de las comunicaciones en entrada (es el cliente el que llama), mientras que para un área de televentas, la mayoría de las comunicaciones son en salida (es la empresa la que llama al cliente).

En nuestro ejemplo, el tráfico entre sedes está recogido en la tabla siguiente:

Tráfico entre sedes en miles de minutos al mes

La hora cargada

Desgraciadamente, las redes de comunicaciones no se utilizan de forma homogénea a lo largo del día. Hay determinadas horas del día en las que se utiliza la red de una forma masiva, mientras que a otras horas está siendo infrautilizada. En cualquier caso, la red hay que diseñarla para dar respuesta a sus usuarios en los momentos de máxima demanda. Los cálculos se realizan para la hora de máxima ocupación. Lo que se conoce como hora cargada o busy hour.

Si la red tiene un historial previo, bastará consultarlo para conocer las cifras de tráfico en la hora cargada (registro CDR). Si no se dispone de historial, tendremos dos alternativas: la primera es hacer estimaciones según el perfil de los usuarios, y la segunda es dejarse llevar por las cifras generales. En un entorno de oficina, en la hora cargada se concentra entre el 15 y el 20 por ciento del tráfico total.

En determinados casos habría que tener en cuenta que el tráfico puede ser distinto para cada día de la semana. Para unas empresas la actividad máxima se concentra en un día, mientras que para otras las variaciones entre unos días y otros son pocas.

Ejemplo de perfil del tráfico en el entorno de una oficina

En el caso de nuestro ejemplo, vamos a suponer que en la hora cargada se concentra en 20 por ciento del tráfico y que el 95 por ciento del mismo se realiza en días laborables (21 días laborables al mes). Si las comunicaciones de Londres con el resto de las sedes se realizasen a través de París, el tráfico total del enlace Londres-París sería de 135.700 minutos al mes (entrante más saliente), suponiendo que este tráfico es el 80% del total (margen de seguridad del 20%), el tráfico total a cursar sería de 169.625 minutos, lo que supondría que el tráfico en la hora cargada o BHT (Busy Hour Traffic) sería 169.625×0,95×0,2/21= 1.535 minutos.

Erlang-B

Siguiendo con el ejemplo, en el caso de la conexión Londres-París, la pregunta que cabría hacerse a continuación sería, cuántos canales de voz haría falta implementar entre estas sedes para poder cursar esa cantidad de minutos. Existen dos respuestas extremas, igualmente incorrectas:

Se puede instalar un solo circuito y que cada empleado espere a que esté libre para realizar su llamada. El coste es bajo, aunque la calidad de servicio será pésima.
Se puede instalar un circuito por empleado. De esta forma, la calidad será excelente, aunque el coste quizás sea excesivo.

Entonces, cuál es la solución correcta. Este problema lo resolvió el danés Agner Krarup Erlang a principios de siglo XX. En su honor, el CCITT (Consultive Committee on Telephones and Telegraphs, ‘Comité consultivo sobre teléfonos y telégrafos’) le puso el nombre de erlang a la unidad que mide la intensidad de tráfico telefónico.

Un erlang representa un uso continuo de un canal telefónico en el periodo de una hora. Un erlang es, por tanto, 60 minutos de tráfico. Si se reciben 100 llamadas de 6 minutos de duración (600 minutos), estaremos hablando de un tráfico de 10 erlangs. Convertir un tráfico en minutos en erlangs es tan simple como dividir por 60. En nuestro ejemplo, el tráfico de 1.535 minutos en la hora cargada será igual a 1.535/60=25,58 erlangs.

Veamos ahora el concepto de probabilidad de pérdida o probabilidad de bloqueo. Si tenemos varios usuarios conectados a una centralita con una sola línea telefónica, en principio, podría suponerse que el tráfico de dicha línea en la hora cargada sería de 60 minutos (1 erlang). No obstante, esto supondría que cada conversación comienza inmediatamente después de que termina la anterior, cosa que, evidentemente, nunca ocurre, los usuarios no suelen sincronizarse a la hora de llamar por teléfono. Se llama probabilidad de bloqueo, probabilidad de pérdida o, por su término en inglés, blocking probability, a la probabilidad que tiene un usuario de que se encuentre la red ocupada al intentar establecer una llamada. En el ejemplo anterior, cuanto mayor sea el número de líneas de la centralita menor será la probabilidad de bloqueo.

Tabla simplificada de Erlang-B (erlang en hora cargada)

Pues bien, el señor A. K. Erlang relacionó matemáticamente el tráfico en erlang en la hora cargada, con la probabilidad de bloqueo y el número de líneas necesarias. Estas fórmulas matemáticas son algo complejas, por lo que se suelen utilizar métodos alternativos como: tablas de Erlang-B, macros para hojas de cálculo, programas específicos o calculadoras online de Erlang-B (como la que hay en www.erlang.com).

En las redes telefónicas se utiliza una probabilidad de bloqueo entre el 0.5 y el 1%. Mientras que el 0,5% ofrece una calidad aceptable, con el 1% la calidad es pobre. No obstante, para redes corporativas se utilizan cifras de hasta el 0,1 por ciento.

Siguiendo con el ejemplo anterior, para cursar 25,58 erlangs, suponiendo una probabilidad de bloqueo del 0,5 por ciento, el número total de canales (bidireccionales) necesarios será de 38.

Topología de red

La topología de red es la disposición física en la que se conectan los distintos nodos que forman la red. En principio, lo más conveniente es agrupar las sedes por proximidad geográfica, de modo que se concentre el tráfico de varias sedes en una única ruta. En cualquier caso, conviene tener presente que no siempre el camino más corto es el más económico. Un buen acuerdo con un operador puede resultar decisivo a la hora de definir la topología final de la red.

En nuestro ejemplo, vamos a concentrar las sedes centroeuropeas en París y las españolas en Madrid, interconectando finalmente las sedes de París y Madrid. Esta solución parece lógica desde el punto de vista de economía de medios, no obstante, desde el punto de vista de la seguridad deja mucho que desear. Si la conexión París-Madrid quedara fuera de servicio, la sede central dejaría de poder hablar con más de media empresa. Este inconveniente podría solventarse estableciendo una doble conexión entre París y Madrid que incluyera un doble equipamiento en estas ciudades. Evidentemente, esto supondría un mayor coste de red. Si, por la actividad de la empresa, fuese importante garantizar las comunicaciones, incluso, de las sedes periféricas, se podría optar por una topología en anillo, interconectando cada sede con las dos más próximas formando todas ellas un anillo.

Una vez fijada la topología de la red, habrá que definir cada uno de los elementos de red que harán falta en cada emplazamiento. En nuestro ejemplo, localizaremos un gateway en cada emplazamiento. En cuanto al número de MGC necesarios, uno sólo de estos equipos puede manejar del orden de 150.000 llamadas a la hora. Esto quiere decir que con uno es suficiente. No obstante, puede ser interesante instalar dos MGC por motivos de seguridad. En el caso de que falle uno de ellos, estará el otro. En este caso, cada MGC debe disponer de capacidad suficiente para afrontar esta sobrecarga.

A la hora de distribuir la carga entre los dos MGC hay que tener en cuenta que habrá llamadas que sólo ocupen a un MGC y otras que requiera que intervengan los dos MGC. Si nos decidimos por poner dos MGC, tendremos que decidir los gateways que controlará cada uno. En principio, esta decisión se puede tomar por cercanía.

Los gateways de señalización o SG están también limitados por el número de llamadas que pueden atender a la hora. Adicionalmente, los SG también están limitados por el número total de enlaces con la red telefónica (SS7). Un SG puede tener una capacidad de hasta 500.000 llamadas a la hora.

Por último, la gestión de la red se lleva a cabo desde un sistema conocido como EMS (Element Management System, ‘Sistema de administración de elementos’). Este sistema se conecta con cada uno de los elementos de la red para facilitar la supervisión y operación de los mismos (recibe las alarmas, estadísticas, etc.).

Ancho de banda necesario

Llegados a este punto, es hora de decidir el ancho de banda necesario en cada una de las rutas de la red. Conocemos el número de canales necesarios en cada ruta, pero nos falta convertir esas cifras a bits por segundo.

El ancho de banda necesario para una llamada depende de los siguientes parámetros:

Codec utilizado. Los diferentes codecs utilizan distinto ancho de banda para una misma duración de la llamada. Aunque G.711 es el codec que ofrece una mayor calidad, también es el que ocupa un mayor ancho de banda. Soluciones como G.723, G.726 o G.729 ofrecen una buena calidad utilizando un ancho de banda considerablemente menor. En nuestro ejemplo, utilizaremos el codec G.729 que opera a 8 Kbps.
Cabeceras de los protocolos. Cada paquete de voz dispone de distintos tipos de cabecera. La información de la voz lleva una cabecera RTP, otra UDP y una última IPv4. La cabecera RTP son 12 octetos, la UDP son 8 y la IPv4 son un mínimo de 20 octetos (sin incluir campos opcionales). El total suma 40 octetos. Adicionalmente habría que sumarle la cabecera de la capa 2 y la cabecera de MPLS (si se utiliza). Si se utiliza PPP como capa 2, la cabecera sería 2 octetos. En el caso de utilizar MPLS habría qua sumar otros 4 octetos. Por tanto, en este caso, el tamaño total de las distintas cabeceras es de 46 octetos.
Intervalo de paquetización. Cuanto menor es el intervalo de paquetización, mayor es el número de paquetes que hay que enviar por unidad de tiempo, por lo que, mayor será el ancho de banda necesario, ya que cada paquete tiene que incorporar su cabecera. No obstante, los paquetes grandes suponen un mayor retardo, lo que influye en la calidad. Por último, el intervalo de paquetización depende también del codec elegido. No todos los codecs admiten seleccionar el intervalo de paquetización (por ejemplo, G.723.1 utiliza muestras de 30 milisegundos, sin posibilidad de cambiarlo). Un intervalo de paquetización entre 20 y 40 milisegundos suele ofrecer un buen equilibrio entre calidad y ancho de banda. En el caso de nuestro ejemplo se va a utilizar el codec G.729 con muestras de 20 milisegundos. Como cada muestra tiene 20 octetos, cada paquete tendría un tamaño de 66 octetos (528 bits) que habría que transmitir cada 20 milisegundos. El resultado es que se requiere un ancho de banda de 26,4 Kbps por canal de voz.
Protocolo RTCP. Este protocolo necesita del orden del 5% del total del ancho de banda. En el caso del ejemplo, incrementaría el ancho de banda hasta los 27,72 Kbps por canal de voz.
Supresión de silencio. La supresión de silencio es una buena herramienta para reducir el ancho de banda necesario. Una conversación típica contiene un 80 por ciento de voz y un 20 por ciento de silencio. Esto quiere decir que cada participante habla una media del 40 por ciento del tiempo, o lo que es lo mismo, en cada sentido de la comunicación sólo requiere el 40 por ciento del ancho de banda total. Durante los periodos de silencio, el codificador de voz genera periódicamente una trama SID (Silence Descriptor, ‘Descriptor de silencio’), pero esta trama es tan pequeña que puede ignorarse a efectos de cálculo del ancho de banda. Aunque la supresión de silencio incorpora cierto retardo adicional, puede ser interesante su uso si se desea reducir el coste de la red. Por ejemplo, podría incluirse exclusivamente en las rutas de larga distancia. En el ejemplo, si se incorporara la supresión de silencio, se utilizaría un ancho de banda de 11,09 Kbps en cada dirección, 22,18 Kbps por conversación.
Probabilidad de colisión. Si sólo se utilizara el factor de actividad para calcular la influencia de la supresión de silencio en el ancho de banda, no se tendría en cuenta la probabilidad de que el número de usuarios que hablan simultáneamente supere el factor de actividad. Esto es, la probabilidad de que el número de usuarios que están hablando simultáneamente sea superior al 40% marcado por el factor de actividad, aunque sea durante cortos periodos de tiempo. Para evitar que esto afecte a la calidad de servicio (aumento del retardo o pérdida de paquetes), se podría calcular el número total de usuarios que hablarán simultáneamente mediante una función de distribución binómica. Otra forma de ponderar este efecto es incrementar el ancho de banda necesario en un porcentaje.
Señalización. También hay que tener en cuenta el ancho de banda ocupado por la señalización y las labores de operación y mantenimiento de la red. Como regla general, el tráfico entre el MGC y los gateways (MG o SG) viene a ser del orden del 5% del tráfico total de voz (sin considerar la supresión de silencio). Adicionalmente, si se cuenta con más de un MGC se necesitará un cierto ancho de banda para su interconexión. Este ancho de banda será también del orden del 5 por ciento del tráfico de voz.
Operación y mantenimiento. La cantidad de información que intercambia cada elemento de red con el EMS dependerá de muchos factores, incluida la frecuencia y tipo de estadísticas que se desea disponer, frecuencia y número de intercambio de datos de registros (por ejemplo para facturación), número de comandos enviados a cada elemento de red, número de alarmas generadas, etc. En realidad, no existe una regla general al respecto, en nuestro ejemplo vamos a suponer 10 Kbps por elemento de red.

Una vez calculado el ancho de banda necesario en cada ruta, habrá que elegir el ancho de banda comercial que le corresponde a cada una. Generalmente, los operadores ofrecen anchos de banda múltiplos de 1 Mbps, por lo que, si como resultado de los cálculos anteriores nos saliera que una ruta necesita 1,6 Mbps, esto querrá decir que se tendría que contratar un enlace de 2 Mbps. En nuestro ejemplo, como la red de VoIP va a compartir la infraestructura existente de datos, habrá que incrementar el ancho de banda de los enlaces con las nuevas necesidades.

Aunque en el ejemplo de cálculo nos hemos centrado en la red interna entre sedes, en una red corporativa habría que tener en cuenta las conexiones de cada sede con la red telefónica tradicional, tanto para los circuitos de voz como los de señalización. En este último caso, habría que calcular el número de enlaces SS7 entre los gateways de señalización, SG, y la red telefónica. Teniendo en cuenta que un enlace SS7 (ISUP) puede manejar unas 30 llamadas por segundos, lo que equivale a 100,000 llamadas a la hora, esto nos permitirá calcular el número total de enlaces necesarios. Hay que tener en cuenta que se necesita un enlace SS7 distinto para cada operador con el que nos conectemos.

Selección de productos y proveedor

Una vez dimensionada la red es la hora de elegir el equipamiento y el suministrador de los mismos. Generalmente, el primer paso en el proceso de selección supone preparar un documento donde se describan las características (funcionalidad y capacidades) de cada elemento. Este documento se conoce como RFI (Request for Information, ‘Solicitud de información’) o RFP (Request for Proposal, ‘Solicitud de propuesta’).

A la hora de elegir el equipamiento es importante tener en cuenta una serie de factores que no están directamente relacionados con la funcionalidad de los mismos pero que resultan igualmente importantes:

Redundancia. Generalmente, los equipos de red se componen de un conjunto de tarjetas que son intercambiables dependiendo de la funcionalidad que se necesite. Existen tarjetas de gestión, tarjetas multimedia, de interconexión, fuente de alimentación, ventilador, etc. Para garantizar el funcionamiento continuo del equipo, es necesario disponer de cierto grado de redundancia de los distintos componentes. Por ejemplo, si son necesarias siete tarjetas multimedia se debería tener instaladas ocho (una de respaldo) y tener en reserva una novena (repuesto). Esto permitiría que, si falla una tarjeta, se podría desviar el tráfico por la de respaldo mientras se procede a sustituir la tarjeta estropeada por la de repuesto.
Disponibilidad. La disponibilidad de un nodo de red suele ser del 99,999%. Esto significa que sólo puede estar fuera de servicio unos 5 minutos al año (de media). Otra forma de expresar la disponibilidad de un equipo es mediante el valor MTBR (Mean Time between Failure, ‘Tiempo medio entre fallos’) expresado en años. Generalmente, este valor es del orden de décadas.
Alarmas y estadísticas. Para una buena gestión de la red es importante disponer de un conjunto completo de estadísticas e informes del funcionamiento de la red (cuando ocurren los picos de ocupación, duración media de la llamada, etc.). Esta información es imprescindible para comprender el detalle de la operación de la red y poder tomar las decisiones necesarias que permitan garantizar su correcto funcionamiento. Por otro lado, es importante detectar el fallo de un componente lo antes posible, incluso, antes de que esto ocurra.

Por último, otro aspecto importante a tener en cuenta es la experiencia y potencial del proveedor (tamaño de la empresa, base instalada de equipos VoIP, especialización, etc.). Dado el caso, podría ser rentable pagar un poco más por los equipos, si esto supone tiempos de provisión o implantación más cortos, mejores facilidades de formación o una garantía de soporte técnico en tiempo real.

Más información sobre los servicios de telefonía VoIP

Aquí se ha expuesto de forma resumida cómo diseñar e implementar una red VoIP corporativa. Si está interesado en conocer más sobre los servicios de VoIP o sobre el funcionamiento de esta tecnología, en este blog se dispone de muchos otros contenidos relacionados. El tema está ampliamente desarrollado en el artículo VoIP. La telefonía de Internet. En cualquier caso, por favor, utilice el buscador de contenidos que tenemos en la cabecera de este blog.

Estos son algunos otros artículos que pueden ser de interés:

REF: VOIP PG230