Una aplicación puede enviar un texto antes de que el teléfono del destinatario sea accesible. Una conexión SMPP transporta ese envío y las operaciones posteriores que informan qué ocurrió.
¿Qué transporta la conexión?
SMPP transporta envíos de mensajes, mensajes entrantes y reportes de entrega entre sistemas conectados.
Tu aplicación puede conectarse a una pasarela que enruta el tráfico. También puede conectarse directamente a un centro de mensajes cuando el proveedor admite esa configuración.
La referencia de SMPP describe esos roles y operaciones. Un centro de mensajes almacena textos y los reenvía hacia los destinatarios.
Una pasarela entre tu aplicación y el centro agrega otro paso de enrutamiento. El nombre del protocolo por sí solo no indica cuántos sistemas manejan el mensaje.
¿Cómo funciona una sesión SMPP?
Tu cliente abre una conexión. Autentica la sesión y la mantiene disponible para operaciones de mensajes.
El paso de autenticación se llama bind. Una sesión transmitter envía mensajes. Una sesión receiver los recibe. Una sesión transceiver admite ambas direcciones.
Usa el tipo de sesión que tu flujo de trabajo requiera. Una conexión de solo envío no puede sustituir una sesión de recepción cuando necesitas operaciones entrantes.
Tu cliente debe recuperarse de una pérdida de conexión. También debe confirmar las operaciones que recibe. Rastrea las solicitudes pendientes de respuesta para que una respuesta retrasada se asocie con la solicitud correcta.
¿Una respuesta de envío demuestra la entrega?
Una respuesta de envío indica si el servicio conectado aceptó el envío, no si el teléfono recibió el texto.
La operación submit_sm envía un mensaje. Su correspondiente submit_sm_resp informa el resultado de esa solicitud.
Los mensajes entrantes y los acuses de recibo de entrega pueden llegar a través de deliver_sm. La referencia de acuses de recibo de entrega explica las operaciones de recibo y su contenido.
Mantén separado el resultado del envío del resultado de la entrega en tu aplicación. Un mensaje puede ser aceptado y después fallar porque el destinatario permanece inaccesible.
¿Qué cambia cuando uso HTTP API en su lugar?
HTTP expone operaciones de solicitud y respuesta sin requerir que tu aplicación gestione un bind SMPP.
Tu aplicación aún necesita manejar reintentos. También debe procesar los resultados de entrega posteriores. HTTP no convierte la entrega asíncrona de un operador en una garantía síncrona.
Con Bird, envías a través de POST /v1/sms/messages y rastreas el identificador de mensaje devuelto. La guía de envío explica la respuesta de aceptación 202. Eventos de SMS proporciona los reportes de entrega posteriores.
Esas responsabilidades de API son independientes de gestionar una conexión SMPP con un proveedor. APIs y pasarelas explica las capas.
¿Usar SMPP hace intercambiables a los proveedores?
Los proveedores no son intercambiables solo porque compartan un protocolo. Pueden admitir operaciones, codificaciones y límites diferentes.
Prueba las capacidades que tu aplicación usa antes de mover tráfico. Un bind exitoso no demuestra que cada operación requerida funcione en ese proveedor.
La referencia de pasarelas recomienda probar el soporte de implementación y el rendimiento. Mantén tus comprobaciones de entrega al cambiar de conexión, en lugar de tratar un nuevo endpoint como una migración completa.
¿Cuándo debería elegir SMPP?
Elige SMPP cuando un sistema existente necesite un bind persistente u operaciones entrantes específicas de SMPP.
- Usa HTTP para una aplicación nueva sin un requisito específico de SMPP.
- Usa SMPP cuando un sistema existente necesite un bind persistente u operaciones entrantes específicas de SMPP.
- Prueba el soporte del proveedor y los resultados de entrega antes de mover tráfico de producción.
En resumen
Tu cliente gestiona una sesión.
Autentica la conexión y se encarga de la recuperación cuando esa conexión falla.
Envío y entrega son operaciones diferentes.
Una respuesta de envío exitosa no demuestra que el dispositivo recibió el mensaje.
El soporte varía entre proveedores.
Prueba las operaciones, la codificación y la capacidad en lugar de asumir que el protocolo hace intercambiables a los proveedores.
HTTP puede evitar la gestión de sesión SMPP.
HTTP evita gestionar un bind SMPP, mientras tu aplicación sigue manejando los eventos de entrega.