Fundamentos de SMPP

O SMPP — Short Message Peer-to-Peer — é o protocolo binário e baseado em sessão que os agregadores e as operadoras disponibilizam para mensagens A2P de alto débito. Onde uma API REST é prática e sem estado, o SMPP é uma ligação TCP persistente construída para volume e baixa latência.

Uma ESME (External Short Messaging Entity — o seu lado) abre uma sessão com o SMSC e troca PDUs (Protocol Data Units). O protocolo é compacto e eficiente, motivo pelo qual continua a ser a espinha dorsal dos grandes remetentes mesmo quando o REST cobre o uso do dia a dia.

A versão mais utilizada é a SMPP v3.4; a v5.0 acrescenta sinalização de estado de congestionamento e parâmetros melhorados, mas é compatível com versões anteriores. Nunca deve assumir que uma funcionalidade da v5.0 está disponível até que a resposta ao bind o confirme.

Antes de enviar seja o que for, uma ESME tem de fazer bind — autenticar-se e declarar um papel. Um bind de transmissor apenas envia mensagens; um bind de recetor apenas recebe mensagens originadas no telemóvel e relatórios de entrega; um bind de transcetor faz ambos numa única ligação.

O transcetor é normalmente preferido porque reduz a metade o número de ligações e simplifica a correlação dos DLR com as submissões. O número de binds concorrentes e as mensagens por segundo (TPS) por bind são aprovisionados pelo fornecedor e têm de ser respeitados.

O bind transporta um system_id, password, system_type e address_range. Um address_range incompatível quebra silenciosamente o encaminhamento de MO e DLR em binds de recetor — um erro de integração clássico que não produz erros, apenas tráfego em falta.

Cada interação SMPP é um PDU com um cabeçalho de comando (comprimento, id de comando, estado, número de sequência) e um corpo. O cavalo de batalha é o submit_sm, que transporta uma única mensagem de saída.

Dois pares de campos decidem o endereçamento: source_addr com o seu TON/NPI (tipo de número / indicador do plano de numeração) e dest_addr com o seu próprio. Um sender ID alfanumérico usa TON 5; um MSISDN internacional usa TON 1, NPI 1. Errar isto faz com que o sender ID seja apresentado incorretamente ou a mensagem seja rejeitada.

O campo data_coding define a codificação — GSM de 7 bits (0), 8 bits (4), ou UCS-2 (8) para Unicode. As mensagens longas são concatenadas com bytes UDH no corpo ou com os parâmetros opcionais SAR (sar_msg_ref_num, sar_total_segments, sar_segment_seqnum); escolha um método e mantenha-o consistente, porque as rotas diferem quanto ao que aceitam.

O SMPP usa uma janela de transmissão: um limite ao número de PDUs submit_sm enviados antes de as respetivas respostas regressarem. Exceder a janela, ou o TPS aprovisionado, desencadeia o ESME_RTHROTTLED (0x58). A resposta correta é recuar com jitter, não repetir tentativas em ciclo contínuo.

Para detetar uma ligação TCP semiaberta, cada lado envia enquire_link num temporizador de inatividade (normalmente a cada 30–60 segundos) e espera um enquire_link_resp. Uma resposta em falta significa que a sessão está morta e deve ser refeito o bind com recuo exponencial.

O encerramento controlado usa unbind / unbind_resp. As desconexões inesperadas devem desencadear uma reconexão com recuo e novas tentativas idempotentes, para que uma janela perdida não cause submissões duplicadas e faturação duplicada.

Os relatórios de entrega chegam como PDUs deliver_sm. O texto do recibo no campo short_message transporta id, sub, dlvrd, a data de submissão, a data de conclusão, o estado final (DELIVRD, UNDELIV, EXPIRED, REJECTD) e um código de erro.

Correlacione o DLR com a sua submissão original usando o message_id do fornecedor, não apenas o texto do recibo — o message_id pode ser devolvido em hexadecimal no submit_resp mas em decimal no DLR, por isso normalize ambos os formatos.

Responda sempre com um deliver_sm_resp. Um DLR não confirmado é reenviado pelo SMSC e pode bloquear a janela de receção, por isso confirme prontamente mesmo que o processamento a jusante seja assíncrono.