Cuentas SMPP para clientes: binds, TPS, DLR y facturación

En el momento en que un cliente técnico pregunta “¿puedo hacer bind por SMPP?”, su plataforma deja de ser un panel web y, a sus ojos, se convierte en un operador. Las cuentas SMPP para clientes son la función que conquista a bancos, proveedores de OTP, otros agregadores y cualquier desarrollador que ya tenga una biblioteca cliente SMPP, y también son el punto donde una configuración descuidada hace más daño: un cliente sin límite de rendimiento, un bind receiver que nadie configuró, acuses que no llegan a ninguna parte, un libro mayor que el bind se salta. Esta guía es la lista de verificación para hacerlo bien, desde el bind que usted emite hasta la prueba que ejecuta antes de decirle al cliente que pase a producción.

Qué son en realidad las cuentas SMPP para clientes

Por la API HTTP, un cliente envía una petición por mensaje y recibe una respuesta. Por SMPP, el cliente abre una sesión TCP de larga duración con su servidor SMPP, se autentica una sola vez con un system_id y una contraseña, y transmite los mensajes por esa sesión como paquetes binarios llamados PDU. Su plataforma tiene que ejecutar un servidor SMPP (el de Smppcube escucha en el puerto 2775 y aparece en el diagrama de la página de la plataforma), aceptar el bind, validar cada submit_sm contra la cuenta del cliente, ponerlo en cola en el mismo pipeline que alimenta la API HTTP y, más tarde, devolver el acuse de entrega por esa sesión como un deliver_sm.

Así que una cuenta SMPP no es un producto aparte con su propia facturación. Es una credencial sobre una cuenta de cliente existente más un conjunto de límites: qué modos de bind, desde qué IP, cuántas sesiones, a qué velocidad. La credencial es la parte pequeña. Los límites son la cuenta.

Tipos de bind y qué permitir

SMPP define tres modos de bind, y la configuración de la cuenta debe indicar cuáles puede usar el cliente:

• Transmitter: solo envío. El cliente envía mensajes y recibe las respuestas de envío (el ID del mensaje), pero nada más. Es sencillo, y es la razón por la que se pierden acuses, porque un transmitter no tiene canal para un deliver_sm.
• Receiver: solo recepción. El cliente recibe acuses de entrega y mensajes entrantes (respuestas originadas en el móvil, si le enruta alguna) y no puede enviar.
• Transceiver: ambas cosas en una sola sesión. Es lo que la mayoría de las bibliotecas cliente modernas abren por defecto y lo que usted debería recomendar, porque una sola sesión transporta envíos y acuses a la vez y no hay nada que desajustar.

El patrón tradicional de un bind transmitter más un bind receiver sigue existiendo, normalmente porque una pila cliente más antigua se escribió así. Permítalo, pero cuéntelo como dos sesiones contra el límite de la cuenta, y asegúrese de que el bind receiver está realmente abierto antes de dar por hecho que los acuses se están entregando.

Los límites de sesión importan más de lo que se suele pensar. Un cliente que abre diez binds transceiver “por redundancia” ocupa diez posiciones de la tabla de conexiones de su servidor y puede empujar diez veces el rendimiento que usted pretendía. De dos a cuatro sesiones por cuenta es un valor por defecto sensato; un cliente que necesita más es un cliente que debería estar en un paquete superior.

Rendimiento, ventanas y throttling

En SMPP, el rendimiento depende de dos cosas: cuántas PDU puede tener el cliente en tránsito antes de esperar las confirmaciones (la ventana) y la tasa que usted permite. La guía de SMPP frente a HTTP explica por qué un solo bind bien gestionado puede empujar cientos de mensajes por segundo; lo que importa aquí es que, en su plataforma, quien recibe ese empuje es usted.

Asigne a cada cuenta SMPP un límite de mensajes por segundo que venga del contrato, no de lo que podría soportar su servidor. Un cliente que paga por 10 msg/s obtiene 10 msg/s; cuando lo supera, responda con el error de throttling que define el protocolo (ESME_RTHROTTLED) en lugar de poner en cola el exceso en silencio. Una biblioteca cliente bien escrita interpreta ese error como “reduzca la velocidad” y baja el ritmo. Una mal escrita sigue insistiendo, y su servidor debería cortar el bind tras infracciones repetidas y registrar el motivo, porque la alternativa es que el bucle de reintentos mal configurado de un cliente se convierta en la latencia de todos.

Hay dos cifras más que pertenecen a la cuenta. Un tamaño de ventana (de 10 a 20 PDU sin confirmar es lo habitual en un bind de cara al cliente; los operadores aguas arriba pueden permitir más) y un intervalo de enquire_link, el latido que mantiene viva una sesión inactiva. Comunique al cliente las tres cifras cuando emita las credenciales. El ticket de “SMPP no funciona” más común es una biblioteca cliente configurada para una ventana que su servidor no concede, que agota el tiempo de espera cada diez mensajes y lo notifica como un fallo de la plataforma.

Adónde van los acuses de entrega

Un acuse de entrega (DLR) por SMPP no es una respuesta al envío del cliente. Llega más tarde, sin que nadie lo solicite, como un deliver_sm en el bind receiver o transceiver del cliente, y el cliente lo empareja con el mensaje original mediante el ID de mensaje que su servidor devolvió en el momento del envío. De ahí se derivan tres cosas.

Primera: el acuse tiene que tener adónde ir. Si el cliente está conectado solo como transmitter y no tiene ningún bind receiver abierto, el acuse no tiene camino. Decida la política de antemano: exigir binds transceiver, retener los acuses durante un breve tiempo hasta que aparezca un bind receiver, u ofrecer un webhook como canal de acuses a los clientes que no pueden mantener un receiver. Descartar acuses en silencio es la única opción que volverá en forma de disputa.

Segunda: el acuse es suyo antes de ser del cliente. Su plataforma necesita el acuse del operador para liquidar el mensaje en el libro mayor, para mostrar el estado en la consola del cliente y para alimentar sus propios informes de calidad de entrega por ruta. Guárdelo, actualice el mensaje y después reenvíelo. Un diseño que solo retransmite los acuses al bind y no guarda nada es un diseño sin respuesta cuando el cliente dice “me cobraron 4.000 mensajes que nunca llegaron”.

Tercera: los acuses llegan aproximadamente al mismo ritmo que salieron los envíos, y los acuses de una campaña llegan después de la campaña. Un cliente que lanza 50.000 mensajes en cinco minutos recibirá 50.000 paquetes deliver_sm durante los diez minutos siguientes. Si su bind receiver tarda en confirmar, su cola de acuses salientes crece; conviértala en una cola con una profundidad visible en lugar de un búfer ilimitado, y configure alertas por antigüedad, para que un bind de cliente atascado aparezca en su panel antes de que el cliente abra un ticket.

Identidades de remitente, codificación y lo que los clientes hacen mal

Una cuenta SMPP también necesita un reglamento. ¿Qué direcciones de origen (identidades de remitente) puede usar el cliente, alfanuméricas o numéricas, y su servidor reescribe o rechaza una desconocida? ¿Qué codificaciones de datos (GSM 7-bit o UCS-2 para escrituras no latinas) y cómo se dividen los mensajes largos (concatenación UDH, que la biblioteca del cliente suele gestionar, aunque no siempre)? ¿Qué periodo de validez y qué indicador registered delivery exige usted para que los acuses se soliciten en primer lugar?

Estas reglas deberían residir en la cuenta y aplicarse en el momento del envío, devolviendo un código de error claro, en lugar de aceptar el mensaje y dejar que falle en silencio en el operador. Del mismo modo que una buena API HTTP devuelve un 400 con un motivo, un buen servidor SMPP rechaza el submit_sm con el estado correcto y deja que el cliente corrija su parte. Cada regla aplicada en su perímetro es una disputa que no tendrá más adelante.

Facturación por bind: la cuenta es dueña del libro mayor

Esta es la parte que falla cuando el servidor SMPP se acopla al lado de la plataforma en lugar de estar integrado en ella. Un mensaje que entra por SMPP debe tarificarse y descontarse exactamente igual que un mensaje que entra por la consola o por la API HTTP: el mismo plan de precios, el mismo saldo, el mismo margen registrado contra la misma ruta. Los tres modos de facturación de la guía de facturación (CreditRoute, WalletRoute y AutoRoute) se aplican a la cuenta, y el bind los hereda. Cuando el saldo llega a cero, el servidor SMPP debe rechazar el envío con un error adecuado en lugar de aceptar tráfico en una cola que nunca se pagará.

Un bind SMPP es una puerta a la cuenta del cliente, no una cuenta aparte. Si el libro mayor no ve la puerta, la puerta es una fuga.

Donde SMPP sí se gana su propia línea comercial es en el paquete que rodea al bind: un compromiso mínimo mensual a cambio de un límite de rendimiento más alto, una cuota por cada sesión adicional, un recargo por una ruta dedicada o un código corto. Tarifique esos conceptos como condiciones de la cuenta, para que el libro mayor registre la cuota y el tráfico en el mismo extracto, y para que un cliente que pasa de HTTP a SMPP vea una sola factura con una línea más, no una relación nueva.

Alta de un cliente: el paquete de credenciales

Cuando se aprueba a un cliente para SMPP, envíe un único documento, y que sea el mismo documento cada vez:

1. Host, puerto y lo que se espera en cuanto a TLS si usted termina TLS delante del servidor SMPP.
2. system_id y contraseña (entregados por un canal distinto del correo que lleva todo lo demás).
3. Modos de bind permitidos y número máximo de sesiones.
4. Las direcciones IP desde las que aceptará binds, y cómo cambiarlas.
5. Límite de rendimiento en msg/s, tamaño de ventana, intervalo de enquire_link.
6. Identidades de remitente permitidas, reglas de codificación, gestión de mensajes largos, indicador registered delivery obligatorio.
7. Adónde van los acuses, y los códigos de error que debe esperar y gestionar.
8. La ruta de prueba y los números de prueba que debe usar antes de pasar a producción.

La mitad de estos datos son cifras que el ingeniero del cliente escribirá en un archivo de configuración en la próxima hora. Dárselas todas a la vez es la diferencia entre una integración de un día y un hilo de correos de dos semanas.

Pruebas antes de pasar a producción

Nunca active la cuenta SMPP de un cliente contra rutas reales. Ofrezca una ruta de prueba que acepte mensajes, genere un acuse verosímil tras un breve retraso y no cobre nada, y guíe al cliente por seis comprobaciones en ella: un bind en cada modo permitido; un mensaje individual y su acuse, emparejados por ID; un mensaje largo en una escritura no latina que llegue como un solo mensaje a un teléfono real; una ráfaga por encima del límite de rendimiento que produzca errores de throttling y una reducción de ritmo correcta; una identidad de remitente deliberadamente incorrecta que produzca el rechazo esperado; y una conexión caída seguida de una reconexión limpia. Solo entonces pase la cuenta a sus rutas reales, y hágalo con el límite todavía en vigor.

La misma ruta de prueba es la que usará más adelante para reproducir el problema de un cliente. Un cliente que dice “han dejado de llegar los acuses” puede hacer bind a la ruta de prueba, enviar un mensaje y ver cómo vuelve el acuse en la consola, lo que convierte un ticket vago en una comprobación de diez minutos de su bind receiver.

Cuándo un cliente no debería tener SMPP

No todos los clientes que piden SMPP deberían recibirlo. Un equipo de marketing que envía desde un navegador no tiene ningún uso para un bind; un desarrollador que envía 300 OTP al día está mejor servido por la API HTTP, que no necesita una sesión persistente y devuelve errores que puede leer. SMPP es para clientes con volumen, con una pila SMPP ya existente o con un motivo de cumplimiento normativo para mantener una relación directa por protocolo. Todos los demás reciben la API, y su cola de soporte se aligera por ello.

Lo que hace creíble la oferta es que por debajo es la misma plataforma, y con una licencia autoalojada el servidor SMPP va incluido en lugar de venderse como un nivel aparte. Un cliente que empieza con la API HTTP y crece hasta un bind SMPP conserva su cuenta, su saldo, su plan de precios y sus informes; el bind es un canal más hacia una cuenta omnicanal que también puede llevar su tráfico de WhatsApp y RCS en el mismo libro mayor. Esa continuidad es lo que un revendedor que alquila un panel normalmente no puede ofrecer, y es la razón discreta por la que los clientes técnicos se quedan.