# SMPP submit_sm: todos os campos obrigatórios

> O submit_sm (command_id 0x00000004) envia uma mensagem terminada no terminal do ESME para o SMSC. O seu corpo é uma sequência fixa de campos obrigatórios — endereçamento (TON/NPI + endereço), esm_class, protocol_id, priority_flag, agendamento, registered_delivery, data_coding, sm_length e short_message — opcionalmente seguidos de TLVs. O submit_sm_resp devolve o message_id do SMSC.

- URL canônico: https://www.broadnet.me/pt/reference/smpp-submit-sm
- Idioma: pt
- Última atualização: 2026-07-18
- Editor: BroadNet (https://www.broadnet.me)

Uma referência completa campo a campo de submit_sm — service_type, TON/NPI, esm_class, data_coding, registered_delivery, validity_period, short_message e o resto — com os valores que realmente importam.

## A ordem completa dos campos obrigatórios

O corpo do submit_sm é uma sequência fixa e ordenada — não há etiquetas de campo, pelo que a ordem e o tamanho são tudo. A tabela lista todos os parâmetros obrigatórios por ordem de transmissão. O short_message pode estar vazio quando o texto é transportado num TLV message_payload; não preencha ambos.

*Parâmetros obrigatórios de submit_sm (por ordem de transmissão)*

| # | Campo | Tipo | Notas |
|---|---|---|---|
| 1 | service_type | C-Octet String (6) | Categoria de serviço; geralmente vazia |
| 2 | source_addr_ton | Integer (1) | Tipo de número do remetente |
| 3 | source_addr_npi | Integer (1) | Plano de numeração do remetente |
| 4 | source_addr | C-Octet String (21) | Endereço do remetente / ID alfanumérico |
| 5 | dest_addr_ton | Integer (1) | Tipo de número do destinatário |
| 6 | dest_addr_npi | Integer (1) | Plano de numeração do destinatário |
| 7 | destination_addr | C-Octet String (21) | MSISDN do destinatário |
| 8 | esm_class | Integer (1) | Modo de mensagem + tipo + flag UDHI |
| 9 | protocol_id | Integer (1) | GSM TP-PID; geralmente 0 |
| 10 | priority_flag | Integer (1) | 0 (normal) – 3 (máximo) |
| 11 | schedule_delivery_time | C-Octet String (1\|17) | Vazio = imediato |
| 12 | validity_period | C-Octet String (1\|17) | Vazio = padrão SMSC |
| 13 | registered_delivery | Integer (1) | Solicitar relatório de entrega |
| 14 | replace_if_present_flag | Integer (1) | 0 = não, 1 = substituir |
| 15 | data_coding | Integer (1) | Codificação / DCS |
| 16 | sm_default_msg_id | Integer (1) | ID da mensagem predefinida; geralmente 0 |
| 17 | sm_length | Integer (1) | Comprimento de short_message (0–254) |
| 18 | short_message | Octet String (0–254) | O payload da mensagem |

## Endereçamento: TON e NPI

Cada um de source_addr e destination_addr transporta um Type of Number (TON) e um Numbering Plan Indicator (NPI). Para um MSISDN internacional use TON 1 (International) com NPI 1 (ISDN/E.164). Para um remetente alfanumérico use TON 5 (Alphanumeric) — o source_addr contém então até 11 caracteres GSM-7. Errar o TON/NPI é uma das principais causas de tráfego não entregue ou mal encaminhado.

*Valores comuns de TON e NPI*

| TON | Significado | NPI | Significado |
|---|---|---|---|
| 0 | Desconhecido | 0 | Desconhecido |
| 1 | Internacional | 1 | ISDN (E.163/E.164) |
| 2 | Nacional | 3 | Dados (X.121) |
| 3 | Específico da rede | 4 | Telex (F.69) |
| 4 | Número do assinante | 6 | Land Mobile (E.212) |
| 5 | Alfanumérico | 8 | Nacional |
| 6 | Abreviado | 9 | Privado |

## esm_class

O esm_class é um campo de bits que define o modo de mensagem, o tipo de mensagem e funcionalidades específicas do GSM. O bit mais importante para os remetentes é o UDHI (0x40): ative-o quando o short_message começa com um User Data Header, por exemplo um cabeçalho de concatenação. O bit 0x80 pede o reply path do GSM.

*Significado dos bits de esm_class (selecionados)*

| Bits | Campo | Valor → significado |
|---|---|---|
| 1–0 | Modo de mensagens | 0 padrão · 1 datagrama · 2 encaminhamento · 3 armazenamento e encaminhamento |
| 5–2 | Tipo de mensagem | 0 padrão · 0x04 relatório de entrega · 0x08 ack de entrega · 0x10 ack do utilizador |
| 6 | UDHI | 0x40 = short_message begins with a UDH |
| 7 | Caminho de resposta | 0x80 = set GSM reply path |

## data_coding, registered_delivery e validade

O data_coding seleciona a codificação de texto: 0x00 = predefinição do SMSC (tipicamente GSM 7-bit), 0x04 = binário de 8 bits, 0x08 = UCS-2 para Unicode. Os dois bits mais baixos de registered_delivery controlam os recibos: 0 = nenhum, 1 = recibo no sucesso ou falha final, 2 = apenas em falha. O validity_period e o schedule_delivery_time usam a forma absoluta YYMMDDhhmmsstnnp ou uma forma relativa; uma string vazia significa entrega imediata e a validade predefinida do SMSC. Mantenha o validity_period curto para OTPs, para que um código atrasado expire em vez de chegar obsoleto.

*data_coding — os valores que realmente usa*

| Valor | Codificação |
|---|---|
| 0x00 | Alfabeto padrão do SMSC (geralmente GSM de 7 bits) |
| 0x03 | Latin-1 (ISO-8859-1) |
| 0x04 | binário de 8 bits (octeto não especificado) |
| 0x08 | UCS-2 (UTF-16BE) — Unicode |

## A resposta

O submit_sm_resp (0x80000004) devolve o command_status e, em caso de sucesso, um message_id (C-Octet String, até 65 caracteres) que o SMSC atribui à mensagem. Guarde-o: é a chave que compara com o receipted_message_id no relatório de entrega. Atenção à variação de formato — alguns SMSCs devolvem o id em hexadecimal no submit e em decimal no DLR, por isso normalize ambos ao correlacionar.

## Perguntas frequentes

### Que TON/NPI uso para um remetente alfanumérico?

Use source_addr_ton = 5 (Alphanumeric) e source_addr_npi = 0 (Unknown). O source_addr contém então até 11 caracteres GSM-7. Os remetentes alfanuméricos são apenas para exibição e não podem receber respostas.

### Como peço um relatório de entrega no submit_sm?

Defina registered_delivery = 1 para obter um recibo na entrega final ou falha, ou 2 apenas em falha. Peça recibos apenas onde efetivamente os consome, pois DLRs não lidos desperdiçam débito.

### Qual é o comprimento máximo de short_message?

O campo short_message contém até 254 octetos, sendo sm_length a contagem exata. Para texto mais longo, ou segmente com um UDH em vários PDUs submit_sm ou transporte todo o conteúdo no TLV message_payload em vez do short_message.

### Posso definir short_message e message_payload em simultâneo?

Não. Preencha um ou outro. Os fornecedores rejeitam um submit_sm que transporte a mensagem tanto no campo obrigatório short_message como no TLV message_payload.

### Como envio uma mensagem Unicode?

Defina data_coding = 0x08 (UCS-2) e codifique o texto como UTF-16 big-endian no short_message. Um único SMS UCS-2 contém 70 caracteres; texto Unicode mais longo é segmentado a 67 caracteres por parte.

## Fontes

- [SMPP v3.4 specification — §4.4 submit_sm](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [3GPP TS 23.040 — SMS technical realization](https://www.3gpp.org/dynareport/23040.htm)

## Relacionados

- [deliver_sm SMPP e mensagens MO](https://www.broadnet.me/pt/reference/smpp-deliver-sm)
- [Esquema de codificação de dados (DCS)](https://www.broadnet.me/pt/reference/data-coding-scheme-dcs)
- [Segmentação SMS e UDH](https://www.broadnet.me/pt/reference/sms-segmentation-concatenation-udh)
- [Decodificador de PDU SMPP (ferramenta gratuita)](https://www.broadnet.me/pt/tools/smpp-pdu-decoder)
- [Produto API SMS](https://www.broadnet.me/pt/products/sms-api)