O SMPP v5.0 é retrocompatível com a v3.4 e acrescenta sinalização de controlo de congestão, operações de mensagens em broadcast (broadcast_sm e afins), um estado de mensagem extra (SKIPPED) e TLVs adicionais. Apesar disso, a v3.4 continua a ser a interligação dominante por ter suporte universal; a v5.0 é usada apenas onde ambos os pares a implementam.
bind_transceiverAbrir e autenticar a sessãobind_transceiver_respSessão aceitasubmit_smEnviar uma mensagemsubmit_sm_respAceito, ID da mensagem devolvidadeliver_smRelatório de entrega ou mensagem recebidadeliver_sm_respConfirmadoenquire_linkKeepalive em modo ocioso
O que a v5.0 acrescenta
A v5.0 é uma revisão incremental e retrocompatível da v3.4. As suas adições de destaque são o controlo de congestão (o SMSC anuncia a carga para que os ESMEs abrandem antes de serem limitados), uma família de operações de broadcast para mensagens de estilo cell-broadcast, um novo estado de mensagem SKIPPED e parâmetros opcionais extra. O formato de PDU central, o modelo de bind e submit_sm/deliver_sm não mudam, e é por isso que um ESME v3.4 consegue comunicar com um SMSC v5.0.
| Área | v3.4 | Adição da v5.0 |
|---|---|---|
| Controlo de congestionamento | Nenhum (reagir ao throttling) | congestion_state TLV — proativo |
| Broadcast | Não suportado | broadcast_sm / query_broadcast_sm / cancel_broadcast_sm |
| Estados da mensagem | 8 estados | Adiciona SKIPPED (9) |
| Parâmetros opcionais | Conjunto TLV v3.4 | TLVs adicionais |
| interface_version | 0x34 | 0x50 |
O que permaneceu igual
Os fundamentos são idênticos: o cabeçalho de 16 bytes, a codificação big-endian, os três tipos de bind, os estados de sessão, o keepalive enquire_link, as disposições de campo de submit_sm/deliver_sm e a gama de erros ESME_R* transitam todos. Os TLVs — introduzidos na v3.4 — continuam a ser o mecanismo de extensão. Esta continuidade é deliberada: a v5.0 foi desenhada para que as integrações v3.4 existentes continuem a funcionar.
Que versão usar
Use a v3.4 a menos que tenha uma razão concreta para usar a v5.0 e ambos os pares a suportem. A v3.4 é a opção segura e universal por omissão para a interligação A2P. Recorra à v5.0 quando precisar especificamente da sua sinalização de congestão ou operações de broadcast e o fornecedor confirmar o suporte. Confirme sempre a versão negociada a partir do bind_resp (o TLV sc_interface_version) em vez de assumir que uma funcionalidade está disponível.
Perguntas frequentes
O SMPP v5.0 é retrocompatível com a v3.4?
Sim. A v5.0 preserva o formato de PDU, o modelo de bind e as operações centrais da v3.4, pelo que um ESME v3.4 e um SMSC v5.0 conseguem interoperar. A versão é declarada em interface_version (0x34 vs 0x50).
Porque é que o SMPP v3.4 ainda é a versão mais comum?
Porque tem implementação universal e cobre completamente as necessidades das mensagens A2P. As adições da v5.0 — controlo de congestão, broadcast — são úteis em cenários específicos mas não são necessárias para tráfego MT/MO padrão, pelo que a maioria das interligações ficou na v3.4.
Qual é o principal benefício prático da v5.0?
Controlo de congestão proativo: o TLV congestion_state permite ao SMSC anunciar a sua carga para que um ESME cooperante abrande antes de atingir erros ESME_RTHROTTLED duros, dando um débito mais suave sob pressão.
Como sei que versão foi negociada numa sessão?
Leia o TLV sc_interface_version devolvido no bind_resp. Não assuma que as funcionalidades da v5.0 estão disponíveis só porque enviou interface_version 0x50 — o SMSC reporta o que realmente suporta.
Especificações de origem
Os padrões publicados nos quais esta página se baseia. Abre num novo separador.