# O que é SMPP? A sessão do SMS

SMPP é o protocolo com que uma plataforma troca mensagens curtas com uma central de mensagens por uma sessão persistente. Um bind declara a direção, a sessão carrega uma janela de taxa e os recibos voltam como PDUs. Não é uma API de requisição e resposta.

- SMPP é uma sessão persistente com uma direção de bind declarada.

- Um bind carrega uma alocação de taxa e uma janela de requisições em voo.

- Uma PDU tem um cabeçalho de 16 bytes e um corpo que depende do comando.

- Os recibos chegam de forma assíncrona pela sessão; são pareados pelo message ID.

## Uma sessão, não uma chamada

O SMPP mantém uma conexão aberta entre a sua plataforma e uma central de mensagens. A plataforma se autentica uma vez, declara o que quer fazer e depois envia mensagens e recebe eventos pela mesma sessão. A central não espera uma nova requisição para enviar um recibo ou uma mensagem recebida; ela empurra uma PDU quando tem algo a informar.
Esse formato combina com um fluxo constante. O custo por mensagem é baixo porque o estado da sessão já está estabelecido e o canal de recibos já está aberto. Também significa que o seu cliente é dono de um estado que um cliente HTTP não tem: status do bind, janela em voo, temporização do keep-alive e comportamento de reconexão.

## O bind declara uma direção

Um bind é a sessão autenticada mais uma direção. Um bind transmissor envia mensagens. Um bind receptor recebe mensagens originadas no celular e recibos. Um bind transceptor faz as duas coisas em uma sessão. O provedor emite credenciais para cada bind e pode limitar quantos você pode abrir.
Escale adicionando binds, não empurrando um bind acima da alocação. Um bind carrega uma alocação de taxa e uma janela de requisições em voo. Se o seu pico precisa de mais, peça outro bind e distribua o tráfego. Um único bind forçado acima da janela produz limitação, timeouts e retentativas que parecem falha de rede mas nascem no cliente.

### Bind, envio, recibo

A sessão abre uma vez; cada envio recebe uma resposta com um message ID; o recibo chega depois pela mesma sessão.

Alt: Uma sequência da aplicação para uma requisição de bind, a central de mensagens, uma resposta de envio e um recibo de entrega.

A aplicação abre um bind e a central de mensagens responde. A aplicação envia uma mensagem curta com submit_sm e recebe submit_sm_resp com um message ID. Mais tarde, a central envia uma PDU deliver_sm com o recibo de entrega. A aplicação confirma com deliver_sm_resp. Um unbind fecha a sessão quando o trabalho termina.

| Item | Value | Note |
| --- | --- | --- |
| Primeiro estado · 1 | Aplicação (ESME) |  |
| Primeiro estado · 2 | bind_transceiver | Abrir a sessão |
| Primeiro estado · 3 | SMSC |  |
| Primeiro estado · 4 | submit_sm_resp | Aceito para entrega |
| Primeiro estado · 5 | Recibo de entrega |  |

Source: smpp.org: sessões SMPP e operações PDU (https://smpp.org/)

## A janela é o contrato

A janela é o número de requisições que o seu cliente pode ter em voo antes de esperar respostas. Não é uma sugestão. Envie mais do que a janela permite e a central limita você; continue tentando no mesmo ritmo e a fila cresce. Leia o código de resposta de cada envio, reduza o ritmo quando houver limitação e deixe a janela esvaziar antes da próxima rajada.
O tráfego de keep-alive mantém a sessão viva. Um cliente que nunca envia enquire_link pode ficar sobre uma conexão morta até o primeiro envio falhar. Um cliente que reconecta imediatamente após cada queda pode martelar o provedor. Use backoff, limite a taxa de reconexão e alerte quando o bind estiver fora por mais tempo do que o seu tráfego tolera.

### Uma PDU, campo a campo

O cabeçalho é fixo; o corpo depende do comando. Um submit_sm carrega endereços, codificação e um indicador de recibo.

Alt: Uma PDU submit_sm decodificada com o comprimento do comando, command ID, status, número de sequência e campos do corpo.

Toda PDU começa com um comprimento de comando de quatro bytes, um command ID de quatro bytes, um status de comando de quatro bytes e um número de sequência de quatro bytes. O corpo vem depois. No submit_sm ele carrega os endereços de origem e destino, a mensagem curta, a codificação de dados e o indicador de recibo registrado. Parâmetros opcionais viajam como campos tag-length-value.

| Item | Value | Note |
| --- | --- | --- |
| command_length | 53 |  |
| command_id | 0x00000004 |  |
| command_status | 0x00000000 |  |
| sequence_number | 1 |  |
| service_type |  |  |
| source_addr_ton | 1 |  |
| source_addr_npi | 1 |  |
| source_addr | 12345 |  |
| dest_addr_ton | 1 |  |
| dest_addr_npi | 1 |  |
| destination_addr | 15551234567 |  |
| esm_class | 0x00 |  |
| protocol_id | 0x00 |  |
| priority_flag | 0 |  |
| schedule_delivery_time |  |  |
| validity_period |  |  |
| registered_delivery | 0x01 |  |
| replace_if_present_flag | 0x00 |  |
| data_coding | 0x00 |  |
| sm_default_msg_id | 0x00 |  |
| sm_length | 4 |  |
| short_message | 54657374 |  |
| Texto | Test |  |

Source: Especificação SMPP v3.4, cabeçalho PDU e submit_sm (https://smpp.org/SMPP_v3_4_Issue1_2.pdf)

## Um dia na vida de uma mensagem

O cliente abre um bind transceptor e lê a resposta. Envia uma mensagem e guarda o message ID da resposta. A central encaminha a mensagem para a rede de destino. Minutos depois chega uma PDU deliver_sm com o recibo: o message ID original, um estado e muitas vezes um código de rede. O cliente confirma o recibo e concilia o estado com o seu próprio registro.
Cada passo tem um modo de falha. Um bind pode ser recusado por credenciais erradas ou por uma versão de interface incorreta. Um envio pode ser limitado, recusado ou aceito e falhar depois no recibo. Um recibo pode chegar depois de o código expirar. Projete o cliente para guardar o message ID, aceitar um recibo tardio e deixar o estado da aplicação como fonte de verdade sobre o que o usuário fez.

O decodificador roda no navegador; o recibo colado não sai de lá.

[Open the tool](/pt/tools/smpp-decoder/?src=learn-what-is-smpp&scenario=dlr-example&sample=id%3A0123456789+sub%3A001+dlvrd%3A001+submit+date%3A2610181200+done+date%3A2610181201+stat%3ADELIVRD+err%3A000+text%3ASeu+c%C3%B3digo+%C3%A9+123456)

### Decodifique um recibo antes de depurar uma rota

Cole um recibo de entrega no [decodificador SMPP e DLR](/pt/tools/smpp-decoder/) e leia os campos. Verifique o message ID, o estado, a data de conclusão e o código de erro. Se o estado não for DELIVRD, o código de erro, lido contra a tabela de códigos do provedor, pode indicar se o número, o celular ou a rede recusaram a mensagem. Faça isso antes de pedir ao provedor para mudar a rota.

## Recibos e depuração

Um recibo é assíncrono. Chega pela sessão como uma PDU deliver_sm, e o formato depende da central de mensagens. Implementações novas carregam o estado em um campo tag-length-value message_state. As antigas colocam um recibo de texto no campo da mensagem curta, com pares chave-valor como id, stat e err. Analise os dois em vez de assumir um.
Pareie pelo message ID, não pela ordem de chegada. Duas mensagens enviadas com um segundo de diferença podem voltar na ordem inversa, e uma retentativa pode produzir um duplicado. Guarde o ID no envio, atualize o registro quando o recibo chegar e ignore um segundo recibo para o mesmo ID, a menos que o estado seja mais recente. O [guia de conexão](/pt/resources/guides/smpp-http-connection/) converte isso em uma sequência operacional.

### Check what you learned

**Por que um segundo bind ajuda mais do que uma taxa de retentativa maior?**

Um bind carrega uma janela. Adicionar um bind adiciona capacidade; tentar de novo contra uma janela cheia adiciona fila e atraso.

**De onde vem o message ID?**

A central de mensagens o devolve em submit_sm_resp. Guarde-o e pareie o recibo posterior por esse ID.

**O que um recibo de entregue prova?**

Que a rede aceitou e entregou a mensagem no caminho até o celular. Não prova que uma pessoa a leu.

## FAQ

**Precisamos de SMPP para começar?**

Não. HTTP se integra em uma tarde; SMPP compensa quando o volume constante justifica uma sessão.

**O que é um bind?**

Uma sessão persistente com uma direção declarada: transmissor, receptor ou transceptor. Carrega uma alocação de taxa e fica aberta com trocas de keep-alive.

**O que é uma PDU?**

Protocol Data Unit: a mensagem binária que o SMPP troca. Toda PDU tem um cabeçalho de 16 bytes e um corpo que depende do comando.

**Podemos usar SMPP pela internet pública?**

Muitas vezes sim, com TLS e lista de IPs permitidos, mas pergunte ao provedor. Alguns ambientes usam uma conexão privada.

**Como mensagens longas são tratadas?**

Como segmentos concatenados com um cabeçalho de dados do usuário, ou como um TLV de payload que a rede segmenta. Teste o resultado no celular.

## Sources

- [smpp.org: sessões SMPP, operações de bind e recibos de entrega](https://smpp.org/) — Accessed: 2026-10-19
- [Especificação SMPP v3.4, Issue 1.2](https://smpp.org/SMPP_v3_4_Issue1_2.pdf) — Accessed: 2026-10-19
- [3GPP TS 23.040: realização técnica do serviço de mensagens curtas](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19

Updated: 2026-10-19