Un mensaje por segundo: una pasarela SMS con módems GSM propios

Un módem GSM puede enviar del orden de un SMS por segundo. De esa cifra se deriva casi cualquier decisión de diseño de una infraestructura de SMS propia. Tras la entrada sobre VoIP de este verano, varias personas nos preguntaron si también gestionamos el SMS con equipos propios. La respuesta: depende. En los últimos meses hemos construido dos sistemas en los que la mensajería de texto era la columna vertebral del servicio, y en ambos surgió la misma pregunta: API de agregador o módems GSM propios.

El canal más antiguo

El SMS es el canal de mensajería digital más antiguo que todo el mundo sigue usando. No requiere aplicación, ni conexión de datos, ni smartphone. Un código de un solo uso, un recordatorio de cita o una alerta llegan aunque el destinatario use un terminal de hace diez años.

En la práctica, cuatro argumentos favorecen el módem GSM:

• El mensaje llega desde un número nacional. Lo que se envía a través de un agregador aparece a menudo desde un número corto o con remitente alfanumérico. Algunos destinatarios lo toman por spam y algunas redes lo filtran.
• Es bidireccional. A una tarjeta SIM real se le puede responder, y la respuesta llega al mismo sitio desde el que salió la pregunta. En atención al cliente, eso es esencial.
• Coste predecible. Hasta cierto volumen, una tarifa de empresa con SMS ilimitados o con un paquete amplio sale más barata que el precio por unidad.
• Independencia. El sistema no depende de la disponibilidad de una API externa.

Las desventajas también existen. Volvemos sobre ellas al final.

Pools de módems y comandos AT

A un mensaje por segundo, cualquier volumen serio exige varios módems. Usamos módems USB o equipos industriales con varias ranuras SIM, bajo Linux, a través de puerto serie.

Con los módems se habla mediante comandos AT, un protocolo de texto con décadas de historia: AT+CMGS envía el mensaje, AT+CMGL lista los recibidos, AT+CSQ devuelve la intensidad de señal. Sobre el papel, sencillo. En la práctica:

• cada fabricante interpreta el estándar de forma algo distinta, y los mensajes de error suelen decir poco,
• los caracteres acentuados y los mensajes divididos en varias partes solo funcionan de forma fiable en modo PDU (codificación binaria); el modo texto vale para una demo,
• el puerto serie solo admite un proceso a la vez, así que el acceso a cada módem hay que serializarlo,
• los módems se cuelgan de vez en cuando, y solo los recupera un reinicio a nivel USB o un ciclo de alimentación.

Por eso el pool lo gestiona un servicio aparte. Un worker por módem es dueño del puerto serie, toma las tareas de una cola común en Redis y escribe de vuelta el resultado. Si un módem cae, se reduce la capacidad y el servicio sigue funcionando.

Las SIM, un trabajo aparte

En el primer sistema subestimamos el trabajo que dan las tarjetas SIM. Hay que llevar registro de qué SIM está en qué módem, qué tarifa tiene, cuántos mensajes han salido por ella en un periodo dado y cuándo caduca la recarga o el cupo. Los operadores pueden suspender las SIM con un tráfico anormalmente alto, así que repartimos la carga de forma uniforme entre los miembros del pool y fijamos un límite diario por SIM.

El informe de entrega (delivery report) es una de las grandes ventajas del envío basado en SIM. La red confirma si el mensaje llegó al terminal, no solo que la central lo aceptó. Para ello hay que solicitar el informe al enviar y emparejar después el informe entrante con el mensaje original mediante el identificador de mensaje de red. Ese identificador puede repetirse dentro de un mismo módem, de modo que el emparejamiento debe acotarse también por módem y ventana temporal.

Colas y reintentos

El envío de SMS es asíncrono. La aplicación no espera a que el mensaje salga: lo pone en una cola y consulta su estado más tarde. Al diseñar la cola tenemos en cuenta:

• la prioridad: un código de acceso de un solo uso no puede esperar detrás de una campaña de marketing,
• los reintentos con espera exponencial, pero solo ante fallos de módem; un número inválido no mejorará al décimo intento,
• la idempotencia: el mismo mensaje al mismo número no sale dos veces dentro de una ventana temporal,
• los mensajes salientes y las respuestas entrantes van a un registro común, filtrado por inquilino.

Este último punto abre otro asunto. El SMS rinde de verdad cuando no va solo. En los sistemas que construimos, la llamada, el SMS y la notificación web comparten un modelo de eventos. Si nadie coge la llamada, sale un SMS. Si alguien responde al SMS, la respuesta entra en la línea temporal del cliente. Cada vez más, tratamos este patrón como un requisito básico.

A favor del agregador

En la mayoría de los casos, el agregador es la mejor opción. Un pool de módems propio compensa si el número nacional, la bidireccionalidad o la independencia son un requisito de negocio concreto, y si hay alguien que opere el hardware. Para envíos internacionales, para grandes volúmenes (decenas de miles al día) o simplemente cuando nadie tiene tiempo de pastorear módems, se impone la API de agregador: una llamada HTTP, un webhook de entrega y una factura a fin de mes.

En los dos casos abstraemos la capa de envío. La aplicación manda los mensajes a través de una interfaz interna. Que detrás haya un módem, un agregador o ambos (módems para el tráfico nacional y agregador para el extranjero, por ejemplo) es una cuestión de configuración. Así, un fallo de módem o un cambio de proveedor no tocan la lógica de negocio.