SMPP frente a API HTTP de SMSC: ¿cuál debería hablar su plataforma?

Cuando conecta una plataforma de mensajería con el mundo exterior, en realidad está eligiendo cómo dialoga con las operadoras, y las respuestas de uso extendido son dos. Una es SMPP, el protocolo binario de telecomunicaciones que lleva décadas transportando el SMS de aplicación a persona (A2P). La otra es una API HTTP, la misma lógica de petición y respuesta que impulsa el resto de la web. No son tanto rivales como herramientas para trabajos distintos, y la conclusión honesta, hacia la que avanza esta guía, es que cualquier cosa que usted llame una plataforma seria termina hablando ambos. Esto es lo que de verdad los separa, y por qué.

Qué es SMPP, y por qué las operadoras siguen usándolo

SMPP, o Short Message Peer-to-Peer, es un protocolo binario que se habla sobre una conexión TCP de larga duración, por convención en el puerto 2775. En lugar de abrir una conexión nueva por cada mensaje, como hace una petición web, un cliente SMPP establece una sesión persistente llamada bind, en uno de tres modos: transmitter (solo envío), receiver (solo recepción) o transceiver (ambos en una conexión). Una vez enlazado, transmite en flujo paquetes binarios compactos llamados PDU: un submit_sm para enviar un mensaje, un deliver_sm para recibir uno o un acuse de entrega, un enquire_link como latido (heartbeat) para mantener viva la sesión.

La razón por la que operadoras y grandes agregadores siguen estandarizándose en SMPP se reduce a la eficiencia a gran volumen. Un bind persistente elimina el sobrecoste de abrir conexión por cada mensaje, y SMPP admite ventana (windowing): quien envía puede poner varios mensajes en tránsito antes de esperar los acuses, así un solo bind sano sostiene de cientos a unos pocos miles de mensajes por segundo. Además está hecho a medida del dominio, con campos nativos para sender ID, codificación de datos, periodos de validez, envío programado y marcas de entrega registrada. Cuando su tráfico se mide en millones de mensajes al día, esa densidad y ese control no son un lujo: son la diferencia entre un servidor y diez.

El precio de tanta potencia es la complejidad. SMPP mantiene el estado, así que usted debe gestionar los bind, reconectar ante caídas, responder a los latidos, respetar la ventana y correlacionar los acuses asíncronos por el ID del mensaje. También tiende a exigir una relación de IP estable, y por eso los bind con las operadoras suelen ir detrás de una allowlist de IP o una pequeña VPN, en vez de en la internet abierta.

Dónde encajan las API HTTP de SMSC

Una API HTTP hace el canje opuesto. Usted envía una petición por mensaje (o por lote pequeño) a una URL, recibe de vuelta una respuesta JSON o de formulario, y no hay sesión que mantener. La autenticación es un token o una clave en una cabecera, los acuses de entrega vuelven como llamadas webhook a una URL que usted aloja, y todo atraviesa cortafuegos y balanceadores de carga corrientes sin gestión especial. Para un desarrollador, cablear un proveedor HTTP es una tarde; cablear una pila SMPP es un proyecto.

Es justo esa sencillez la que ha multiplicado los proveedores HTTP. Muchísimos proveedores regionales, agregadores de WhatsApp y RCS, y entrantes CPaaS más recientes exponen primero HTTP y SMPP solo bajo petición, o no lo exponen en absoluto. Para volúmenes bajos y medios, o para un país que usted alcanza a través de un único proveedor especializado, una ruta HTTP no es un compromiso a la baja: es la opción sensata. El sobrecoste por mensaje es mayor y el techo bruto de rendimiento es menor que un bind SMPP bien afinado, pero se escala del modo aburrido, en horizontal, haciendo más peticiones simultáneas; y para la mayoría de los revendedores ese techo queda muy por encima del tráfico real.

El límite honesto es control y coherencia. Cada proveedor HTTP inventa sus propios nombres de campo, su propia forma de expresar Unicode y mensajes largos, y su propio formato de llamada DLR. Hable con cinco proveedores HTTP y habrá integrado, en la práctica, cinco productos ligeramente distintos.

Las diferencias reales: rendimiento, DLR y codificación

Son tres los detalles técnicos que causan casi todo el dolor real, así que conviene ser preciso.

Rendimiento y control de flujo. El rendimiento de SMPP lo gobiernan el tamaño de la ventana y la latencia de ida y vuelta: con una ventana de, digamos, 10 PDU sin acusar y un enlace rápido, un bind empuja mucho tráfico, y las operadoras imponen una tasa contratada que usted no debe superar, so pena de throttling. El rendimiento de HTTP lo gobiernan cuántas peticiones simultáneas hace usted y el límite de tasa (rate limit) del proveedor, normalmente expresado en peticiones por segundo. La consecuencia práctica: SMPP premia un número reducido de conexiones persistentes bien gestionadas, mientras que HTTP premia un grupo de workers que hacen llamadas en paralelo. El diseño de la cola y de los workers de su plataforma cambia en consecuencia.

Acuses de entrega. Aquí es donde se rompen las integraciones ingenuas. En SMPP, el DLR no es una respuesta a su submit; llega más tarde, sin solicitarlo, como un deliver_sm en su bind, y usted debe reconducirlo al mensaje original por el ID que la operadora asignó al enviarlo. Si usted no está a la escucha, o pierde el bind, pierde los acuses. En HTTP, el DLR es una llamada que el proveedor hace por POST a su webhook, lo que significa que su endpoint debe ser accesible, idempotente (los proveedores reintentan) y capaz de correlacionar por su propia referencia. Mismo concepto, entregado, fallido, expirado, rechazado, desconocido, pero dos mecanismos del todo distintos que capturar de forma fiable.

Codificación de caracteres. El SMS es implacable aquí. El alfabeto GSM 03.38 mete 160 caracteres en un solo mensaje de 7 bits; salga de ahí (un emoji, muchos caracteres acentuados o no latinos) y el mensaje pasa a UCS-2, que solo alberga 70 por parte. Los textos más largos se parten en segmentos cosidos con una cabecera de datos de usuario (UDH), y cada segmento se tarifica. SMPP expone todo esto directamente por el campo data_coding y espera que usted lo haga bien. Los proveedores HTTP suelen intentar abstraerlo, pero lo hacen de forma incoherente, y un proveedor que degrada en silencio un mensaje Unicode o cuenta mal los segmentos le costará dinero sin avisar o le destrozará el texto. Sea cual sea el protocolo, la codificación es algo que su plataforma debe gestionar a propósito, no confiar en que el proveedor acierte.

Por qué una plataforma seria habla ambos

Junte esas diferencias y la conclusión se escribe sola. Su mejor ruta hacia un país puede ser un bind SMPP con una operadora nacional; la única ruta hacia el siguiente puede ser un especialista HTTP; el respaldo para ambos puede ser un tercer proveedor, en el protocolo que le toque ofrecer. Si su plataforma solo sabe hablar uno, sus opciones de enrutamiento se reducen a la mitad y sus negociaciones con proveedores quedan rehenes de una limitación técnica, en vez de guiarse por precio y calidad de entrega.

Por eso una pasarela madura ejecuta una pila SMPP y un cliente HTTP en paralelo, y por lo general expone ambos también a sus propios clientes: un servidor SMPP al que se enlazan los clientes técnicos, y una API HTTP para todos los demás. El verdadero valor de la plataforma no es ninguno de los dos protocolos: es la capa por encima de ellos, el motor de enrutamiento, la facturación, la normalización de los acuses de entrega, que hace invisible la elección de protocolo para quien envía un mensaje. Una plataforma autoalojada como Smppcube trae tanto un servidor SMPP de nivel operador como una API HTTP precisamente para que sea el operador, no el protocolo, quien decida cómo fluye el tráfico. Si está sopesando gestionar esa pila usted mismo, la guía de la pasarela autoalojada cubre el lado operativo.

Un único adaptador HTTP genérico de proveedores (cómo funciona de verdad)

La trampa de los proveedores HTTP, que cada uno es sutilmente distinto, tiene solución, y la solución es un patrón que vale la pena entender antes de comprar o construir. En lugar de escribir código a medida para cada proveedor, disperso por la base de código, usted define una sola interfaz interna, una única forma normalizada para envía un mensaje y aquí tienes un acuse de entrega, y luego escribe un adaptador delgado por proveedor que traduce entre las rarezas del proveedor y esa forma interna.

Cada adaptador posee exactamente las diferencias: cómo se autentica este proveedor, cómo llama a los campos de destino y texto, cómo quiere que se marque el Unicode, y cómo interpretar su llamada DLR particular hacia el conjunto común de estados de la plataforma. Todo lo que hay aguas arriba, la cola, el enrutador, la facturación, los informes, habla solo con la interfaz interna y no sabe ni le importa qué proveedor hay detrás. Incorporar un nuevo proveedor HTTP se vuelve entonces una configuración y un pequeño adaptador, no una reescritura; y añadir después proveedores de voz por API sigue exactamente el mismo patrón. Así es como una plataforma se mantiene abierta a docenas de proveedores regionales sin hundirse bajo sus incoherencias, y es el diseño que una pasarela autoalojada ya debería implementar, para que usted nunca toque el código de protocolo al añadir una ruta.

¿Cuál debería elegir?

Si es un revendedor cableando su primer proveedor y este ofrece HTTP, empiece por ahí: es más rápido de integrar, fácil de probar y suficiente para demostrar su negocio. Añada SMPP cuando el volumen, una relación con una operadora, o un cliente técnico que quiera enlazarse a usted hagan que valga la pena la maquinaria extra. Si es un agregador o un operador que maneja volúmenes serios y acuerdos directos con las operadoras, SMPP no es opcional: es el idioma que hablan sus proveedores.

El contrapunto honesto a todo esto: no elija protocolo en absoluto, si puede evitarlo. Elija una plataforma que ya hable ambos y esconda la diferencia, para que su energía vaya a la calidad de las rutas y a los clientes, en vez de a mantener una pila de protocolo binario. Ese es el sentido entero de comprar una pasarela en lugar de construir una, y puede ver dónde se sitúa una opción autoalojada, de propiedad total, en la página de precios. El protocolo debería ser un detalle que usted configura, nunca un muro contra el que construye su negocio.