Introducción
Recursos en la Red (RenR) es una empresa tecnológica que desarrolla su actividad en el campo de los medios de comunicación, especialmente en el sector prensa. Pertenece al Grupo Editorial Prensa Ibérica (EPI), compuesto por 19 diarios repartidos por la geografía española y varias empresas relacionadas con el sector como pueden ser rotativas, distribuidoras, artes gráficas y editoriales. En la actualidad el grupo EPI se está expandiendo a otros medios como son la radio y la TV.
RenR gestiona todas las necesidades tecnológicas del grupo EPI, entre otras: la red corporativa que conecta todas las empresas del grupo; todos los servicios sobre redes TCP/IP típicos como DNS, FTP, e-mail y servidores web; el desarrollo de un gestor de contenidos web con el que se sirven todas las Ediciones Digitales de los diarios del grupo; el desarrollo de un sistema completo para la edición de los diarios en papel, que incluye una gestión del flujo de trabajo (workflow), un editor colaborativo, una fototeca, un servicio de recepción e indexación de teletipos de las agencias de noticias, un gestor para la publicidad, etc. Todos éstos servicios tienen una política de soporte 24/7.
Otro producto importante es un sistema de TPVs para quioscos y otros puntos de venta de prensa, con las siguientes funcionalidades: recarga de teléfonos de pre-pago de los principales operadores españoles y algunos servicios de llamadas internacionales; recarga de tarjeta de transporte urbano en ciertas ciudades; venta de entradas para parques temáticos, conciertos y otros eventos; gestión básica de la contabilidad del quiosco y control de ventas; etc. Actualmente hay instalado un parque de 12000 unidades, con un objetivo estimado de unas 25000. RenR tiene un call-center que atiende el soporte al usuario final de éste servicio durante horario de oficina (fines de semana y festivos incluidos).
En el mundo de la prensa escrita trabaja con calendarios y tiempos muy ajustados: los diarios tienen que estar maquetados, escritos y filmados en ficheros PDF o EPS de alta resolución a tiempo para ser enviados por FTP a la rotativa en el rango horario que ésta haya asignado a cada uno para su impresión. Si un diario no está listo para imprimir en el momento indicado, los demás tendrán preferencia sobre él y se le relegará al último puesto en la cola, con lo que probablemente no esté impreso a tiempo para que la distribuidora lo recoja y lo reparta a todos los puntos de venta a primera hora de la mañana. Por otra parte, las propias rotativas también incurren en penalizaciones si son ellas quienes por cualquier motivo técnico retrasan el proceso. Este ajustado ciclo de producción se repite 365 días al año.
Por éste motivo los sistemas y el software responsabilidad de RenR son críticos para sus clientes: cualquier error debe ser resuelto en cuestión de minutos, o toda la planificación se retrasa. Y el principal medio de comunicación en esos momentos cruciales es el teléfono, convirtiendo así a la centralita en un sistema tan crítico como el servidor de correo o la propia red de datos.
Necesidad de alta disponibilidad en Asterisk
RenR comenzó a investigar las posibilidades que Asterisk ofrece a finales del 2005, iniciando un cuidadoso proceso de migración a mediados de 2006, en el que se integró un servidor Asterisk con la centralita analógica usando una tarjeta PCI con 2 interfaces RDSI PRI. De esta forma, se pudo comenzar a hacer pruebas y aprovecharse de todas las características de Asterisk como las colas de llamadas, buzones de voz y la programación de horarios, pero manteniendo todavía todos los teléfonos analógicos a través de la centralita antigua. Pero pocos días después de introducir el servidor Asterisk en producción, éste comenzó a dar problemas por culpa de un chip de memoria RAM defectuoso. Se hizo patente que hacía falta una solución de alta disponibilidad.
Dada la amplia experiencia de RenR en la implantación de clusters de servidores Linux, replicar el Asterisk en un modo activo/pasivo no presentaba ningún problema. La única pieza que faltaba era una forma de pasar la línea RDSI de un servidor a otro cuando uno de ellos fallara. El fonebridge2 lo hizo posible, “desconectando” las líneas físicas de los servidores y permitiendo enviar las tramas TDMoE al servidor que correspondiera.
Configuración actual y planes de futuro
RenR finalizó su migración a un sistema VoIP completo, eliminando la centralita antigua e implantando teléfonos VoIP en todos los puestos de trabajo a mediados de 2007. El sistema actual está compuesto por:
- 2 servidores Pentium IV con 1Gb de RAM corriendo Asterisk, en configuración de cluster activo/pasivo (detalles técnicos aquí)
- 1 fonebridge2
- 1 línea PRI RDSI
- ~70 teléfonos VoIP
- varias colas de llamadas
- algunas extensiones tienen programada una redirección a un móvil de guardias fuera del horario de oficina para el soporte 24/7
- otras son dirigidas a un buzón de voz
- multiconferencias, etc.
El sistema soporta una media de 10 llamadas concurrentes durante el horario de oficina, con picos de hasta 25.
En la actualidad RenR está instalando servidores Asterisk con una configuración similar en el resto de empresas del grupo, lo que permitirá a EPI eliminar por completo los costes de las numerosas llamadas internas. En una segunda fase, está planificado enrutar también las llamadas externas a través de la red VoIP resultante hasta la centralita más cercana al teléfono de destino, recortando así también los gastos en llamadas al exterior.
El uso de Asterisk ha permitido a la empresa mejorar su soporte telefónico de varias maneras. Desde su implantación, Asterisk proporciona en tiempo real información sobre el número de llamadas atendidas así como llamadas en espera en alguna cola, métricas útiles para extraer conclusiones sobre la calidad del servicio de soporte. Algunos proyectos en curso incluyen el uso del API de programación de Asterisk para integrarlo en el sistema de soporte y gestión de tickets de incidencias de la empresa, de forma que cuando llegue una llamada el sistema extraiga los datos de la cuenta y le muestre en pantalla al operador que vaya a
atenderla los datos de incidencias del cliente; y la integración con el sistema de control de acceso, presencia y gestión de vacaciones, lo que permitirá a las operadoras del call-center saber si una persona está o no en la oficina, así como enrutar directamente a otra persona del mismo departamento las llamadas directas a la extensión de un empleado que esté de vacaciones.
Otro software relacionado con Asterisk en uso en RenR:
- FreePBX para la administración vía web de la centralita
- Flash Operator Panel
- Un conjunto de scripts para controlar el proceso Asterisk con daemontools
- Una función para el dialplan que permite cambiar la programación según un calendario de días festivos
Muy interante y útil. Merece la cerveza!
Hola, como se puede hacer para soportar varias llamadas concurrentes sobre un mismo número de teléfono a través de Asterisk. Creo que con una línea análogica normal no es posible. Para eso hay que utilizar a lo mejor líneas de RDSI, que no se cuantas pueden soportar. De todas formas me pregunto como hacen para que bajo un mismo número se puedan recibir cientos de llamadas a la vez por ejemplo en un call center.
Por cierto muy bueno el artículo, te mereces una caja de cruzcampo bien fresquita.
@Pablo: Hola Pablo.
La verdad es que no soy ningún entendido en telefonía, me metí lo justo para instalar varios Asterisk en la empresa donde trabajaba y hace ya como un año que no toco el tema. Pero voy a tratar de aclarártelo hasta donde yo he visto:
En la práctica la impresión que tengo es que la relación entre el “medio físico” (la línea analógica o cada uno de los canales del primario RDSI) y cada nº de teléfono concreto no es una relación 1:1 fija. En el caso de una línea analógica lo que pasa es que si tienes ya la línea ocupada no te puede entrar otra llamada, sea para ese mismo número o para algún otro. Y de todas formas, no sé si el operador puede “enrutar” distintos nºs a una misma línea normal, aunque no veo por qué no y de hecho sospecho que si que podría.
Sin embargo con un primario RDSI te puede entrar una llamada para cualquiera de tus nºs externos por cualquiera de los 30 canales, pudiendo incluso llegarte simultáneamente llamadas para el mismo nº por distintos canales (lo que preguntabas), la relación nº-canal no es fija. De hecho a la hora de enrutar las llamadas a una extensión VoIP (o a una cola, contestador o lo que sea) no te fijas en el canal por el que ha entrado, si no en el nº de destino.
Espero haberte aclarado la duda :-) y gracias por el comentario.
@Pablo ahora mismo te explico como funciona eso:
cuando llamamos a un mismo numero de telefono varias personas (atención al cliente de cualquier gran empresa) estamos llamando a un numero cabecera de un primario, y la llamada salta a cualquiera de los canales libres. Esto mismo se puede hacer con varias lineas RDSI, cada una tiene su numero propio, pero hay una que es la cabecera y se producen saltos de linea en la llamada entrante hasta que encuentra una linea libre. Espero haberte aclarado la duda. Si necesitas cualquier aclaracion o duda al respecto comentalo.
Salu2.
Hola, me podrian ayudar en algo. Tengo montado 2 servidores asterisk , necesito hacer 30 llamadas concurrentes es decir ocupar los 30 canales pero cada vez que ocupe un canal o una linea esta quede en espera y así sucesivamnete hasta llegar al canal o a la linea Nº30, cual es la configuracion en el servidor 1 (del cual genero las llamadas) en el archivo extensions.conf
Muchisimas gracias.