SMPP: la guía completa del protocolo.

Qué es SMPP y dónde encaja

Una sesión SMPP siempre tiene dos roles. El ESME (Entidad Externa de Mensajería Corta) es su aplicación: una plataforma de SMS masivos, un servicio de OTP, un sistema de alertas. El SMSC (Centro de Servicio de Mensajes Cortos), llamado MC (Centro de Mensajes) en la v5.0, es el nodo del operador o agregador que almacena y reenvía mensajes hacia y desde los terminales a través de la red móvil. La ESME se conecta al SMSC; el SMSC se conecta a la red SS7 / núcleo móvil.

SMPP es la columna vertebral de A2P (De la aplicación a la persona) mensajería: códigos de verificación, recibos, alertas, marketing, en contraposición a P2P Mensajería de texto (de persona a persona) entre dos teléfonos móviles. El tráfico A2P es de alto volumen, generado por máquinas y basado en la confirmación de entrega, que es precisamente para lo que se diseñó SMPP.

¿Por qué un protocolo TCP binario en lugar de HTTP? Un único enlace SMPP es un socket de larga duración. Una vez abierto, se evita el establecimiento de conexión TCP y TLS por mensaje, se pueden tener muchos mensajes en tránsito simultáneamente (ventanas asíncronas), y el SMSC envía las confirmaciones de entrega y los mensajes entrantes directamente a través de la misma conexión. Con un alto rendimiento sostenido, esto resulta mucho más eficiente que una API HTTP de solicitud/respuesta, razón por la cual los operadores y los grandes remitentes lo estandarizan.

Historial de versiones

• SMPP v3.3 — la primera versión ampliamente desplegada; introdujo el conjunto principal de PDU, pero es anterior a los TLV (parámetros opcionales) y al enlace del transceptor.
• SMPP v3.4 — la versión dominante en producción actualmente. Se añadieron el enlace del transceptor, parámetros TLV opcionales, message_payload y data_sm. Casi todas las integraciones reales que desarrollarás utilizan la versión 3.4.
• SMPP v5.0 — La versión más reciente. Cambia el nombre de SMSC a MC, añade PDU de difusión (broadcast_sm), señalización de estado de congestión y TLV más estandarizados. Su adopción es limitada; primero se recomienda dar soporte a la versión 3.4 y considerar la versión 5.0 como opcional.

Arquitectura y tipos de bind

La topología es simple: el ESME abre una conexión TCP con el SMSC/MC y se autentica con un identificador. system_id y passwordLa dirección en la que la sesión puede transportar tráfico se fija en el momento de la vinculación eligiendo una de tres opciones. modos de enlaceCada modo es una PDU de enlace diferente.

Un cuarto actor es enrutamientoEl SMSC decide, para cada mensaje, qué ruta o interconexión de operador descendente sigue un mensaje enviado hacia el terminal de destino, y a qué ESME vinculado pertenece un mensaje entrante (originado en el móvil).

En la red, SMPP funciona sobre TCP. El puerto predeterminado registrado por IANA es 2775 para conexiones simples. SMPPS — SMPP envuelto en TLS — no tiene un puerto estándar único; los proveedores lo exponen en el puerto que elijan (en la práctica se ven los puertos 3550, 8775 y 2776). Siempre utilice el puerto cifrado que su proveedor le asigne para producción.

El ciclo de vida de la sesión

Cada sesión SMPP sigue el mismo proceso: apertura de TCP, enlace, mantenimiento de la conexión, intercambio de mensajes y confirmaciones, y, finalmente, desvinculación y cierre. El diagrama siguiente muestra una sesión completa de transceptor: cada fila representa una PDU, la azul que fluye desde el ESME al SMSC, y la verde, que fluye de vuelta.

Dos detalles importantes. Primero, submit_sm_resp Devuelve inmediatamente y solo significa “aceptado para entrega”; el resultado real llega más tarde como un deliver_sm recibo. En segundo lugar, cada PDU de solicitud tiene un recibo correspondiente. _resp que se hace eco de su sequence_number, que es como las respuestas asíncronas se correlacionan con las solicitudes.

Anatomía de la PDU

Todo en una conexión SMPP es un PDUCada PDU comienza con un valor fijo encabezado de 16 bytes de cuatro enteros de 4 bytes (32 bits, big-endian), seguidos de un cuerpo específico del comando. Lea primero el encabezado y sabrá exactamente cómo leer el resto.

El cuerpo termina con cualquier número de TLV — Parámetros opcionales Codificados como Etiqueta (2 bytes), Longitud (2 bytes), Valor (Length bytes). Los TLV son la forma en que la versión 3.4 extendió el protocolo sin afectar a las versiones anteriores: message_payload, receipted_message_id, campos de concatenación sar_* y muchos más se transmiten como TLV.

El número_de_secuencia es la clave para el uso de ventanas. Debido a que SMPP es asíncrono, un ESME puede enviar muchas PDU submit_sm —cada una con un número de secuencia incremental— antes de que lleguen las respuestas. Cuando las PDU submit_sm_resp regresan, su número de secuencia indica a qué envío responde cada una. El número de PDU no confirmadas permitidas en tránsito es el tamaño de la ventana.

Referencia de PDUs principales

Estas son las operaciones que realmente utilizará. Cada solicitud tiene una PDU de respuesta cuyo command_id es el id de la solicitud con el bit más significativo activado (0x80000000), por lo que submit_sm 0x00000004 se corresponde con submit_sm_resp 0x80000004.

submit_sm campo por campo

submit_sm Es la PDU que enviará con mayor frecuencia. Su cuerpo es una secuencia de parámetros obligatorios y TLV opcionales. Estos son los campos que importan en la práctica.

Codificación y concatenación de datos

El data_coding El campo (el Esquema de Codificación de Datos, DCS) le indica al terminal cómo interpretar los bytes y decide cuántos caracteres caben en un SMS.

Un mensaje de más de un segmento se divide y se vuelve a ensamblar en el terminal mediante un UDH (Encabezado de datos de usuario) antepuesto a cada parte. El elemento de concatenación utiliza IEI 0x00 (referencia de 8 bits): un encabezado de 6 octetos que contiene un número de referencia, el número total de partes y el índice de esta parte. Esos 6 octetos son la razón por la que los límites por parte bajan a 153 (GSM de 7 bits) y 67 (UCS-2). Cuando envíe un UDH dentro de short_message, también debe activar el bit UDHI (0x40) en esm_class.

Hay dos maneras de enviar contenido largo: crear usted mismo las partes segmentadas por UDH (cada una un submit_sm con UDHI configurado), o entregar el cuerpo completo al SMSC en el message_payload TLV y permite la segmentación. Algunos SMSC aceptan en cambio los TLV sar_msg_ref_num / sar_total_segments / sar_segment_seqnum para describir la concatenación sin UDH.

Comprobantes de entrega (DLR)

Cuando lo configures registered_delivery = 1El SMSC informa posteriormente del destino del mensaje enviándote un correo electrónico. deliver_sm con el bit de confirmación de entrega activado en esm_class (0x04El texto del recibo se encuentra en el campo short_message como una cadena de palabras clave conocida:

id:1a2b3c4d5e sub:001 dlvrd:001 submit date:2607251432 done date:2607251432 stat:DELIVRD err:000 text:Your code is 8

El id coincide con el message_id que recibió de vuelta en submit_sm_resp (también reflejado en el TLV 0x001E de receipted_message_id). El stat El campo contiene el estado final:

Siempre responde a un deliver_sm con un deliver_sm_respSi no lo hace, el SMSC reenviará el recibo y podría limitar o cancelar la conexión. Tenga en cuenta que el formato del recibo no está perfectamente estandarizado: los proveedores varían ligeramente en el orden de los campos y en el mapa de códigos de error.

Códigos de error / estado del comando

Cada PDU de respuesta lleva un command_status en su encabezado — un ESME_R* Código. Cero significa éxito; cualquier otro valor describe el motivo del rechazo de la solicitud. Estos son los códigos que encontrará con mayor frecuencia.

El registro completo, incluyendo los rangos de proveedores específicos, se puede buscar en el Referencia de códigos de error SMPP.

Rendimiento, segmentación y limitación de velocidad

El rendimiento en SMPP se mide en TPS — transacciones (submit_sm) por segundo — y está regido por dos cosas: la tasa que permite el SMSC y cuántos mensajes mantienes en tránsito. Como SMPP es asíncrono, no tienes que esperar a cada submit_sm_resp antes de enviar la siguiente PDU. El número de envíos no confirmados que permites a la vez es tu tamaño de la ventana (generalmente entre 10 y 100). Un rango mayor oculta la latencia de ida y vuelta y aumenta el TPS efectivo, hasta el límite máximo del SMSC.

• Respeta el acelerador. Cuando el SMSC devuelva ESME_RTHROTTLED (0x58), espere: haga una pausa y vuelva a intentarlo con retroceso exponencial en lugar de saturar el enlace, lo que puede provocar una desconexión.
• Mantener la conexión a un ritmo determinado. Envía un enlace de consulta aproximadamente cada 30 segundos mientras estés inactivo; si algunos mensajes quedan sin respuesta, asume que el enlace no funciona.
• Reconectar deliberadamente. Al desconectarse, vuelva a conectar y vuelva a vincular con retroceso y fluctuación; no utilice bucles cerrados. Registre los números de secuencia pendientes para poder conciliar las recepciones después de una reconexión.
• Escalar con ataduras, con cuidado. Un mayor TPS agregado generalmente proviene de múltiples vinculaciones, pero solo hasta el límite que su proveedor autoriza por cuenta.

Ejemplo de código

Un ejemplo ilustrativo del flujo de conexión → enlace → envío en pseudocódigo estilo Node. Las bibliotecas SMPP reales (por ejemplo, node-smpp, jSMPP para Java o python-smpplib) se encargan de la codificación de PDU; esto muestra la estructura de la sesión, no la API de una biblioteca específica.

import smpp from "smpp";

// 1. Open a TCP (or TLS) session to the SMSC.
const session = smpp.connect({
  // Host, port and bind credentials come with your test access.
  // Plain SMPP conventionally uses 2775; the TLS port is provided with your account.
  url: process.env.SMPP_URL!,             // e.g. smpp://<host>:2775 (plain) or smpps://<host>:<tls-port>
  auto_enquire_link_period: 30000,        // keepalive every 30s
});

// 2. Bind as a transceiver.
session.bind_transceiver(
  {
    system_id: "YOUR_SYSTEM_ID",
    password:  "YOUR_PASSWORD",
    system_type: "",
  },
  (pdu) => {
    if (pdu.command_status !== 0) {
      throw new Error("bind failed: 0x" + pdu.command_status.toString(16));
    }

    // 3. Submit a Unicode message, asking for a delivery receipt.
    session.submit_sm(
      {
        source_addr_ton: 5,                // alphanumeric Sender ID
        source_addr:      "BroadNet",
        dest_addr_ton:    1,               // international E.164
        destination_addr: "447700900123",
        registered_delivery: 1,            // request a DLR
        data_coding: 8,                    // UCS-2 (Unicode)
        short_message: "Your code is 8123",
      },
      (submitResp) => {
        // submit_sm_resp returns the SMSC message_id.
        console.log("accepted, message_id =", submitResp.message_id);
      }
    );
  }
);

// 4. Receive delivery receipts on the same session.
session.on("deliver_sm", (pdu) => {
  if ((pdu.esm_class & 0x04) === 0x04) {   // delivery-receipt bit
    console.log("DLR:", pdu.short_message.message);
  }
  session.send(pdu.response());            // ALWAYS deliver_sm_resp
});

BroadNet SMPP

BroadNet opera una pasarela SMSC de nivel operador que acepta enlaces SMPP v3.4 sobre TLS. Obtendrá: enlaces de transceptor, alto TPS con ventanas asíncronas, confirmaciones de entrega completas, Unicode y concatenación, y una conexión con credenciales y lista de direcciones IP permitidas para comunicarse con operadores de todo el mundo. Es el mismo protocolo que se enseña en esta página, configurado para rutas reales.

Preguntas frecuentes

Herramientas y documentación relacionadas