SMPP: o guia completo do protocolo.

O que é SMPP e onde se encaixa

Uma sessão SMPP sempre tem duas funções. ESME (Entidade externa de mensagens curtas) é a sua aplicação — uma plataforma de SMS em massa, um serviço OTP, um sistema de alertas. O SMSC (Centro de Serviço de Mensagens Curtas), chamado de MC (Centro de Mensagens) na versão 5.0, é o operador ou agregador nó que armazena e encaminha mensagens de e para aparelhos na rede móvel. O ESME se conecta ao SMSC; o SMSC se conecta ao núcleo SS7/móvel mais amplo.

O SMPP é a espinha dorsal do A2P (Aplicação para Pessoa) mensagens — códigos de verificação, recibos, alertas, marketing — em oposição a P2P Mensagens de texto (de pessoa para pessoa) entre dois aparelhos. A2P O tráfego é de alto volume, gerado por máquinas e baseado em relatório de entrega, que é exatamente o que o SMPP foi projetado para suportar.

Porque um protocolo TCP binário em vez de HTTP? Uma única conexão SMPP é um socket de longa duração. Uma vez aberta, você evita um handshake TCP e TLS por mensagem, pode ter várias mensagens em trânsito simultaneamente (janelas assíncronas), e o SMSC envia relatórios de entrega e mensagens de entrada diretamente de volta pela mesma conexão. Com alta taxa de transferência sustentada, isso é dramaticamente mais eficiente do que uma API HTTP de solicitação/resposta — e é por isso que operadoras e grandes remetentes a padronizam.

Histórico de versões

• SMPP v3.3 — a primeira versão amplamente implantada; introduziu o conjunto principal de PDUs, mas é anterior aos TLVs (parâmetros opcionais) e à vinculação do transceptor.
• SMPP v3.4 — a versão dominante em produção atualmente. Adicionado o bind do transceptor, parâmetros TLV opcionais, message_payload e data_sm. Quase todas as integrações do mundo real que você criar usarão a versão 3.4.
• SMPP v5.0 — a versão mais recente. Renomeia SMSC para MC, adiciona PDUs de broadcast (broadcast_sm), sinalização de estado de congestionamento e TLVs mais padronizados. A adoção é limitada; suporte primeiro à v3.4 e trate a v5.0 como opcional.

Arquitetura e tipos de ligação

A topologia é simples: o ESME abre uma conexão TCP com o SMSC/MC e autentica-se com um system_id e passwordA direção em que a sessão pode transportar tráfego é definida no momento da vinculação, escolhendo uma das três opções. modos de vinculaçãoCada modo é uma PDU vinculada diferente.

Um quarto ator é encaminhamentoO SMSC decide, por mensagem, qual rota ou interconexão de operadora downstream uma mensagem enviada utiliza em direção ao dispositivo de destino e a qual ESME vinculada uma mensagem de entrada (originada em dispositivo móvel) pertence.

Na rede, o SMPP funciona sobre TCP. A porta padrão registada na IANA é 2775 para conexões simples. SMPPS — SMPP encapsulado em TLS — não possui uma porta padrão única; os fornecedores o expõem numa porta da sua escolha (3550, 8775 e 2776 são comuns na prática). Sempre use a porta encriptada que o seu fornecedor atribui para produção.

O ciclo de vida da sessão

Toda sessão SMPP segue o mesmo padrão: abrir TCP, vincular, manter a conexão ativa, trocar mensagens e recibos, e então desvincular e fechar. O diagrama abaixo traça uma sessão completa de transceptor — cada linha representa uma PDU, em azul fluindo do ESME para o SMSC, e em verde fluindo de volta.

Dois detalhes importantes. Primeiro, submit_sm_resp "Devolve imediatamente" significa apenas "aceito para entrega" — o resultado real chega mais tarde como um deliver_sm recibo. Em segundo lugar, cada PDU de solicitação tem um correspondente _resp que ecoa o seu sequence_number, que é como as respostas assíncronas são correlacionadas com as solicitações.

Anatomia da PDU

Tudo numa conexão SMPP é um PDUCada PDU começa com um valor fixo Cabeçalho de 16 bytes de quatro inteiros de 4 bytes (32 bits, big-endian), seguidos por um corpo específico do comando. Leia o cabeçalho primeiro e você saberá exatamente como ler o resto.

O corpo termina com qualquer número de TLVs — parâmetros opcionais codificados como Tag (2 bytes), Comprimento (2 bytes), Valor (Comprimento bytes). Os TLVs são a forma como a v3.4 estendeu o protocolo sem quebrar versões anteriores: message_payload, receipted_message_id, campos de concatenação sar_* e muitos outros são todos usados como TLVs.

O número_de_sequência é a chave para a gestão de janelas. Como o SMPP é assíncrono, um ESME pode enviar muitos PDUs submit_sm — cada um com um número de sequência incremental — antes que qualquer resposta chegue. Quando os PDUs submit_sm_resp regressam, o seu número de sequência indica a qual submissão cada um responde. O número de PDUs não reconhecidos permitidos em trânsito é o tamanho da janela.

Referência de PDUs principais

Estas são as operações que você realmente usará. Cada solicitação tem um PDU de resposta cujo command_id é o ID da solicitação com o bit mais significativo definido (0x80000000), portanto, submit_sm 0x00000004 corresponde a submit_sm_resp 0x80000004.

submit_sm campo por campo

submit_sm é a PDU que você enviará com mais frequência. O seu corpo é uma sequência de parâmetros obrigatórios e, em seguida, TLVs opcionais. Esses são os campos que importam na prática.

Codificação e concatenação de dados

O data_coding O campo (o Esquema de Codificação de Dados, DCS) informa ao aparelho como interpretar os bytes e decide quantos caracteres cabem num SMS.

Uma mensagem com mais de um segmento é dividida e remontada no aparelho usando um UDH (Cabeçalho de Dados do Utilizador) adicionado a cada parte. O elemento de concatenação usa IEI 0x00 (8 bits referência) — um cabeçalho de 6 octetos contendo um número de referência, a contagem total de peças e o índice desta peça. Esses 6 octetos são o motivo pelo qual os limites por peça caem para 153 (GSM 7 bits) e 67 (UCS-2). Ao enviar um UDH dentro de short_message, você também deve definir o bit UDHI (0x40) em esm_class.

Existem duas maneiras de enviar conteúdo longo: construir as partes segmentadas por UDH você mesmo (cada uma um submit_sm com UDHI definido) ou entregar o corpo inteiro ao SMSC no message_payload TLV e deixe-o segmentar. Alguns SMSCs, em vez disso, aceitam os TLVs sar_msg_ref_num / sar_total_segments / sar_segment_seqnum para descrever a concatenação sem um UDH.

Relatórios de entrega (DLR)

Quando você definir registered_delivery = 1, o SMSC posteriormente informa o destino da mensagem enviando-lhe um deliver_sm com o bit de relatório de entrega definido em esm_class (0x04O texto do recibo reside no campo short_message como uma string de palavra-chave conhecida:

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

O id corresponde ao message_id que você recebeu de volta em submit_sm_resp (também exibido no TLV receipted_message_id 0x001E). O stat O campo contém o estado final:

Sempre responda a um deliver_sm com um deliver_sm_resp; caso contrário, o SMSC reenviará o recibo e poderá limitar ou interromper a conexão. Observe que a formatação do recibo não é perfeitamente padronizada — os fornecedores variam ligeiramente na ordem dos campos e no mapeamento dos códigos de erro.

Códigos de erro/status do comando

Cada PDU de resposta carrega um command_status no seu cabeçalho — um ESME_R* código. Zero significa sucesso; qualquer outro valor descreve o motivo da recusa da solicitação. Esses são os que você encontrará com mais frequência.

O registo completo — incluindo intervalos de fornecedores específicos do fornecedor — pode ser pesquisado no Referência de códigos de erro SMPP.

Taxa de transferência, janelas e limitação de velocidade

A taxa de transferência em SMPP é medida em TPS — transações (submit_sm) por segundo — e é regido por dois fatores: a taxa permitida pelo SMSC e quantas mensagens você mantém em trânsito. Como o SMPP é assíncrono, você não precisa esperar por cada submit_sm_resp antes de enviar o próximo PDU. O número de envios não confirmados que você permite simultaneamente é o seu tamanho da janela (geralmente de 10 a 100). Uma janela maior oculta a latência de ida e volta e aumenta o TPS efetivo — até o limite máximo do SMSC.

• Respeite o acelerador. Quando o SMSC devolver ESME_RTHROTTLED (0x58), recue — faça uma pausa e tente novamente com recuo exponencial em vez de insistir na conexão vinculada, o que pode causar a desconexão.
• Mantenha a atividade num ritmo constante. Envie enquire_link aproximadamente a cada 30 segundos enquanto estiver ocioso; se algumas mensagens não forem respondidas, assuma que o link está inativo.
• Reconecte-se de forma consciente. Ao desconectar, reconecte e reassocie com backoff e jitter; não faça loops curtos. Monitorize os números de sequência pendentes para que você possa conciliar os recibos após uma reconexão.
• Escala com amarras, com cuidado. Um TPS agregado mais alto geralmente resulta de múltiplas conexões — mas apenas até o limite autorizado pelo seu fornecedor por conta.

Exemplo de código

Um exemplo ilustrativo do fluxo conectar → vincular → enviar em pseudocódigo no estilo Node.js. Bibliotecas SMPP reais (por exemplo, node-smpp, jSMPP para Java ou python-smpplib) lidam com a codificação de PDUs para você; isto mostra o formato da sessão, não a API de uma 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

A BroadNet opera um gateway SMSC de nível de operadora que aceita conexões SMPP v3.4 sobre TLS. Você obtém conexões de transceptor, alto TPS com janelas assíncronas, relatórios de entrega completos, Unicode e concatenação, e uma conexão com lista de permissões de IP e credenciais para alcançar operadoras em todo o mundo. É o mesmo protocolo ensinado nesta página — direcionado para rotas reais.

Perguntas frequentes

Ferramentas e documentos relacionados