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.
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
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.
| # | 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.
| 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.
| 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.
| 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.
Especificações de origem
Os padrões publicados nos quais esta página se baseia. Abre num novo separador.