Simulador de sessão SMPP.

Como uma sessão SMPP realmente funciona

1. 1 · Vincular. A sua aplicação abre uma conexão TCP com o SMSC e envia o comando bind_transceiver com um system_id e uma palavra-passe. Até que o SMSC responda com command_status 0, nenhuma outra comunicação será aceita.
2. 2 · Enviar. Cada mensagem é uma PDU submit_sm. A resposta fornece um message_id — que é uma aceitação, não uma entrega.
3. 3 · Recibo. Se você solicitou um, o SMSC posteriormente envia um deliver_sm contendo esm_class 0x04 e um corpo de recibo que faz referência a esse message_id.
4. 4 · Manter vivo. enquire_link a cada 30–60 segundos comprova que o socket ainda está utilizável. Se essa solicitação for perdida, o SMSC desconectará você.
5. 5 · Desvincular. Encerre a ligação educadamente para que a operadora não a considere uma desconexão anormal.

Perguntas que os engenheiros fazem

Este simulador envia SMS de verdade?

Não. Nada nesta página abre uma conexão ou envia uma mensagem para qualquer lugar. Cada PDU e cada resposta SMSC é calculada no seu navegador a partir dos valores que você digita, portanto, as mesmas entradas sempre produzem a mesma transcrição. É uma ferramenta de aprendizagem sobre o protocolo, não uma ferramenta de envio.

O que é um bind em SMPP ?

Um bind é o handshake de sessão entre um ESME (a sua aplicação) e o SMSC (a central de mensagens da operadora). O bind_transmitter só pode enviar dados, o bind_receiver só pode receber dados e o bind_transceiver faz ambos numa única conexão — que é o que a maioria das integrações utiliza. Nenhum outro dado é aceito na sessão até que o bind seja bem-sucedido.

O que faz o registered_delivery?

Definir registered_delivery como 1 solicita ao SMSC que confirme o resultado final. Essa confirmação chega posteriormente como um PDU deliver_sm separado, contendo esm_class 0x04 — o relatório de entrega — que faz referência ao message_id fornecido em submit_sm_resp. Sem ele, você fica a saber apenas que o SMSC aceitou a mensagem, não que um aparelho a recebeu.

Porque a minha mensagem se divide em vários segmentos?

Um único PDU SMS transporta 160 caracteres no alfabeto GSM-7 ou 70 no UCS-2. Textos mais longos são concatenados: cada parte cede 6 octetos para um cabeçalho de dados do utilizador, permitindo que o aparelho os remonte, resultando em 153 ou 67 caracteres por segmento. Um caractere árabe ou um emoji força toda a mensagem a usar o formato UCS-2, razão pela qual uma mensagem em árabe com 100 caracteres ocupa dois segmentos.

Qual a diferença entre submit_sm_resp e um comprovativo de entrega?

submit_sm_resp é síncrono e significa apenas que o SMSC aceitou a PDU e atribuiu a ela um `message_id`. O comprovativo de entrega chega de forma assíncrona, geralmente segundos ou minutos depois, e informa o resultado real — ENTREGUE, NÃO ENTREGUE, EXPIRADO, REJEITADO. Tratar submit_sm_resp como comprovativo de entrega é o erro mais comum numa primeira integração SMPP.

O que é uma janela SMPP e porque ela limita a minha taxa de transferência?

A janela define quantas PDU você pode ter enviado, mas não confirmado, numa conexão num determinado momento. Como SMPP é assíncrono, você não espera por cada submit_sm_resp antes de enviar o próximo — mas a janela limita o quanto você pode avançar na comunicação. Se mantida no valor padrão de 1, a conexão se degrada para solicitação/resposta e a sua taxa de transferência cai para uma mensagem por ida e volta, independentemente da taxa acordada com o operador.