Qué es SMPP
SMPP (Short Message Peer-to-Peer) es el protocolo abierto que la industria de telecomunicaciones usa para intercambiar SMS entre aplicaciones y centros de mensajes. La versión 3.4 es la más extendida. En una conexión SMPP, su plataforma actúa como ESME (External Short Message Entity) y mantiene una sesión TCP persistente con el centro de mensajes, por la que envía mensajes y recibe sus reportes de entrega sin abrir una conexión nueva por cada envío.
Por eso SMPP es la opción natural para agregadores, plataformas de comunicación y empresas con tráfico alto y continuo que ya cuentan con un gateway o con experiencia en telecomunicaciones.
Tipos de conexión (bind)
| Bind | Qué permite | Uso típico |
|---|---|---|
bind_transmitter | Solo enviar mensajes (submit_sm) | Sistemas que separan envío y recepción en sesiones distintas |
bind_receiver | Solo recibir (deliver_sm): reportes de entrega y mensajes entrantes | Procesos dedicados a conciliar DLR o recibir respuestas |
bind_transceiver | Enviar y recibir en la misma sesión | La opción más común en integraciones nuevas |
Mensajes del protocolo que conviene conocer
submit_sm: envía un mensaje. La respuestasubmit_sm_respdevuelve elmessage_idque identifica el envío.deliver_sm: entrega a su plataforma un reporte de entrega o un mensaje entrante (MO). Debe confirmarse condeliver_sm_resp.enquire_link: mantiene viva la sesión y detecta caídas.unbind: cierra la sesión de forma ordenada.
Throughput, ventanas y control de flujo
La capacidad de una conexión SMPP se expresa en mensajes por segundo (TPS) y depende del número de sesiones y de la ventana: cuántos submit_sm puede tener su plataforma pendientes de respuesta al mismo tiempo. Trabajar de forma asíncrona, con una ventana adecuada, permite aprovechar la capacidad sin esperar cada respuesta.
Cuando se supera la capacidad acordada, el centro de mensajes responde con errores de control de flujo como ESME_RTHROTTLED. Su plataforma debe reducir el ritmo y reintentar en lugar de desconectarse. En Grupo Tecnophone, el número de sesiones y la capacidad de cada conexión se dimensionan según el proyecto.
Reportes de entrega en SMPP
Para recibir el estado final de un mensaje se solicita en el campo registered_delivery del submit_sm. El reporte llega como un deliver_sm que referencia el message_id original y, por convención, incluye un texto con este formato:
id:a1b2c3d4 sub:001 dlvrd:001 submit date:2610121432 done date:2610121432 stat:DELIVRD err:000 text:...| Estado | Significado |
|---|---|
DELIVRD | Entregado al teléfono |
UNDELIV | No se pudo entregar (número inexistente, inactivo o rechazado por la red) |
EXPIRED | Venció el periodo de validez sin poder entregarse, por ejemplo con el equipo apagado |
REJECTD | Rechazado antes de intentar la entrega |
ACCEPTD | Aceptado sin confirmación de entrega final |
UNKNOWN | Estado no determinado |
DELETED | Eliminado antes de entregarse |
Los mismos estados se reflejan en los reportes que reciben los clientes de la API REST. Lo explicamos en detalle en reportes de entrega (DLR) y webhooks.
Codificación y mensajes largos
El campo data_coding indica el alfabeto: el valor 0 corresponde al alfabeto por defecto (GSM-7) y el 8 a UCS-2, necesario para caracteres fuera de GSM-7. Los mensajes que superan un segmento se envían concatenados mediante encabezado UDH, parámetros SAR o el campo message_payload. Vea cuántos caracteres tiene un SMS.
SMPP o API REST
| Criterio | API REST | SMPP |
|---|---|---|
| Esfuerzo de integración | Bajo | Medio-alto |
| Volumen | Bajo a alto | Alto y sostenido |
| Conexión | Una petición HTTPS por mensaje | Sesión persistente |
| Reportes de entrega | Webhooks | deliver_sm en la sesión |
| Perfil del equipo | Desarrolladores de aplicaciones | Equipos con experiencia en telecomunicaciones |
Si su caso es una aplicación que envía OTP, alertas o notificaciones, la API SMS REST suele ser la vía más rápida. SMPP conviene cuando ya opera un gateway o el volumen sostenido lo justifica.
Buenas prácticas de operación
- Enviar
enquire_linkperiódicamente y reconectar con espera progresiva ante caídas. - Respetar la ventana y la capacidad acordadas, y tratar el control de flujo como señal para bajar el ritmo.
- Registrar el
message_idde cada envío para conciliar reportes y facturación. - Confirmar siempre cada
deliver_smpara no recibir reportes duplicados. - Monitorear estados
UNDELIVyEXPIREDpor destino para depurar bases de datos.
Los parámetros de conexión, las credenciales y las IP autorizadas se definen durante la habilitación. Para conocer los requisitos de su proyecto, hable con nuestro equipo técnico.
