Caso de éxito: Solución de Asterisk Redundante para Grupo Editorial

[spanish]

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.

asteriskrenr-spanish.png

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:

[VERSIÓN PDF]

[/spanish]
[english]

Overview

Recursos en la Red (RenR) is a Spanish IT company specializing in the press/publishing sector. It is part of Grupo Editorial Prensa Ibérica (EPI), a publishing group comprised of 19 newspapers geographically spread across Spain and several other related businesses including printing press plants, press distribution, graphic design and book publishing companies[3]. EPI is currently expanding into other media such as radio and TV.

RenR manages all the IT needs of the EPI group, including an internal private network connecting all these companies; all the usual TCP/IP services like DNS, FTP, e-mail or web servers; the development of a CMS running the digital editions of all the group’s newspapers; the development of a full management and publishing suite for the printed editions, comprising of a workflow manager, a collaborative text editor, a photograph library, a news agency wire service reception and indexing system, etc. All these services have a 24/7 support policy.

Another important product is a POS system for kiosks and other newspaper selling points[4], capable of: recharging prepaid mobile phones of all major operators in Spain; recharging transport carts for several cities’ metropolitan transport services; selling admission tickets for theme parks, concerts, and other entertainment events; managing a basic accountability of the kiosk; etc. It currently has a deployed base of around 12000 units with an estimate target of over 25000. RenR has a call center handling the end-user support for this service during business hours.

The Publishing business is a business with very tight schedules: the press plants assign tight deadlines to each newspaper, so they have to be written, filmed to high-resolution PDF or EPS files, sent via FTP to the press plant and ready to go to print at that precise moment or they are pushed to the end of the queue. If this happens, the newspaper will not be ready soon enough for the distribution company to get it to the kiosks and other selling points in time. On the other hand, the press plants themselves can also incur heavy penalties if they are responsible for delaying the process because of any technical reasons. This production cycle is repeated 365 days a year.

Obviously, the systems and software RenR is responsible for are mission-critical for its clients. Any error has to be dealt with in minutes or the whole process can fall behind schedule. And the main communication channel during those highly critical moments is the telephone. This makes the PBX as important and crucial a system as the e-mail server or the network itself.

Asterisk High Availability Requirements

RenR knew of Asterisk by late 2005, and started a careful migration process in mid 2006 by integrating an Asterisk PBX in front of the company’s legacy PBX using a 2 ISDN PRI PCI card. This was a way to start testing and benefiting from some of Asterisk’s features like call queues, voicemail and programming, while still using the analog phones via the legacy PBX. But shortly after rolling the Asterisk PBX into production, a faulty RAM chip brought it down. A high availability solution was needed.

Given RenR’s expertise with Linux clusters, replicating the Asterisk system in an active/passive setup was not a problem. The only missing piece was a way to switch the ISDN lines from one server to the other if one of the servers went down. Enter the Redfone foneBRIDGE2 T1/E1 to TDMoE bridge. This device made it possible to detach the physical ISDN lines from the servers, acting as a “logical switch” sending the TDMoE frames to the “master” server.

Current setup and future plans

RenR finished its migration to a full VoIP implementation, removing the legacy PBX and rolling out VoIP phones, in mid 2007. Its current telephony system is comprised of:

  • 2 Pentium IV servers with 1Gb RAM running Asterisk in an active/passive fail-over configuration (in-depth technical details here)
  • 1 foneBRIDGE2
  • 1 PRI ISDN line
  • ~70 VoIP phones
  • several different call queues
  • some extensions have a programmed redirection to a mobile phone number outside business
  • hours for 24/7 support
  • other extensions are redirected to voicemail outside business hours
  • conference rooms, etc.

asteriskrenr.png

This system handles an average of 10 concurrent calls at any given time during business hours, with spikes of over 25.

RenR is currently installing Asterisk boxes with a similar setup in the rest of the group’s companies. This will allow the EPI group to cut costs to zero in the numerous internal calls. There are plans to route external calls through the resulting VoIP network to the PBX that is nearest to the destination, thus cutting costs on external calls too.

Asterisk is going to help the company improve its telephone support in many ways. It is already providing real-time statistics about the number of incoming calls and queued calls, useful to draw client-support quality metrics. Some ongoing projects include using Asterisk’s API to fully integrate it into an existing ticket/support management system, so that it will be able to retrieve all the client’s data and show open and past support issues on-screen to the call center operator taking the call; and integrating Asterisk into the company’s access control system and the holiday management system, allowing the call center operators to know who is at the office at any given moment, and automatically re-routing direct calls when someone is
on holiday.

Other Asterisk software in use at RenR include:

[PDF VERSION]
[/english]

5 pensamientos en “Caso de éxito: Solución de Asterisk Redundante para Grupo Editorial”

  1. 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.

  2. @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.

  3. @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.

  4. 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.

Deja un comentario