Pasarela SMS y módems GSM: cuando la tecnología antigua sigue siendo la más fiable

Tras la entrada sobre VoIP del verano, varias personas nos preguntaron si gestionamos también el SMS sobre infraestructura propia. La respuesta es: depende, y esta entrada trata justamente de qué depende. En los últimos meses hemos construido dos sistemas en los que la mensajería de texto no era una función complementaria, sino la columna vertebral del servicio, y en ambos apareció la misma pregunta: API de agregador o módems GSM propios.

¿Por qué un módem GSM, para empezar?

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 a su destino aunque el destinatario use un terminal de hace diez años.

Los argumentos a favor del módem GSM, en la práctica:

• El mensaje llega desde un número nacional. El mensaje enviado por un agregador aparece a menudo desde un número corto o con remitente alfanumérico, lo que algunos destinatarios toman por spam y algunas redes 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 esto 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 son reales, y volveremos sobre ellas al final.

El pool de módems y los comandos AT

Un módem puede enviar del orden de un mensaje por segundo, así que cualquier volumen serio requiere varios módems. Esto lo solemos resolver con módems USB o con equipos industriales de varias ranuras SIM, bajo Linux, a través de puerto serie.

Con los módems hablamos mediante comandos AT. Es un protocolo de texto que lleva décadas existiendo: AT+CMGS envía el mensaje, AT+CMGL lista los recibidos, AT+CSQ devuelve la intensidad de señal. Suena simple, pero en la práctica:

• cada fabricante de módems interpreta el estándar de una forma algo distinta, y los mensajes de error suelen ser poco informativos,
• hace falta el modo PDU (codificación binaria) para que los caracteres acentuados y los mensajes divididos en varias partes funcionen de forma fiable; el modo texto solo vale para demos,
• el puerto serie solo lo puede usar 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 arregla 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, que es dueño del puerto serie, toma las tareas de una cola común en Redis y escribe de vuelta el resultado. Así, la caída de un módem solo reduce la capacidad, no detiene el servicio.

Gestión de SIM e informes de entrega

Lo que subestimamos en el primer sistema: operar las tarjetas SIM es una tarea en sí misma. Hay que llevar registro de qué SIM está en qué módem, qué tarifa tiene asociada, 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 mantenemos 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 eso hay que solicitar el informe en el momento del envío y emparejar el informe entrante con el mensaje original mediante el identificador de mensaje de red. El identificador puede repetirse dentro de un mismo módem, así que el emparejamiento hay que acotarlo también por módem y ventana temporal.

Cola de mensajes y reintentos

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

• prioridad: un código de acceso de un solo uso no puede quedarse detrás de una campaña de marketing,
• reintento con espera exponencial, pero solo en los fallos de módem; un número inválido no va a mejorar al décimo intento,
• 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 de mensajes común, filtrado por inquilino.

El último punto lleva a otro tema: el SMS resulta realmente útil cuando no está solo. En los sistemas que construimos, la llamada, el SMS y la notificación web se apoyan en un modelo de eventos común. Si no cogen la llamada, sale un SMS; si responden al SMS, eso entra en la línea temporal del cliente. Cada vez vemos más este patrón como un requisito básico.

¿Cuándo conviene elegir un agregador?

Con franqueza: en la mayoría de los casos. El pool de módems propio merece la pena 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 volúmenes grandes (decenas de miles al día) o si simplemente no hay capacidad para pastorear módems, la API de agregador es la mejor opción: una llamada HTTP, un webhook de entrega y una factura a fin de mes.

Lo que hacemos en ambos casos: abstraer la capa de envío. La aplicación envía el mensaje a través de una interfaz interna, y que detrás haya un módem, un agregador o ambos (por ejemplo, módem para el ámbito nacional y agregador para el extranjero) es una cuestión de configuración. Eso es lo que permite que un fallo de módem o un cambio de proveedor no afecten a la lógica de negocio.