O que é SMPP? A sessão do SMS
SMPP sem jargão: binds, janelas, PDUs e o caminho do recibo, e por que o formato da sessão importa em volume.
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.
Fatos-chave
- 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.
Nesta página
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
- Aplicação (ESME)
- bind_transceiver Abrir a sessão
- SMSC
- submit_sm_resp Aceito para entrega
- Recibo de entrega
Descrição em texto
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.
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
- 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
Descrição em texto
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.
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.
Decodifique um recibo antes de depurar uma rota
Cole um recibo de entrega no decodificador SMPP e DLR 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 converte isso em uma sequência operacional.
Confira o que aprendeu
-
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.
As respostas aparecem sob demanda. Nada é pontuado, armazenado ou enviado.
Perguntas frequentes
Precisamos de SMPP para começar?
O que é um bind?
O que é uma PDU?
Podemos usar SMPP pela internet pública?
Como mensagens longas são tratadas?
Relacionado
- Conectar por SMPP e HTTP
Levar uma rota de teste à produção sem quebrar binds, janelas ou recibos: estado do bind, taxa, keep-alive, codificação, callbacks e falhas.
- Pacote de modelos de RFQ e RFP
Listas de campos para solicitações de SMS no atacado, eSIM e dados, IoT e conectividade com a China, com checklist online.
- Relatório de exemplo de teste de rota
Exemplo estático anonimizado de um relatório de teste de rota: o que um teste de rota verifica, como ler as falhas e o que aciona uma revisão.
Produtos relacionados
Coloque em prática
Informe o tráfego, o destino e a medição necessária; respondemos com o próximo passo.