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.
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:
- FreePBX for an easy, web-based administration
- Flash Operator Panel
- A set of scripts to run Asterisk via DJB’s daemontools
- A dialplan function to easily program different timetables according to a holidays calendar

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.
y gracias por el comentario.
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
@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.