O deliver_sm (command_id 0x00000005) é enviado do SMSC para o ESME para entregar quer uma mensagem originada no terminal (MO) quer um relatório de entrega (DLR). O seu corpo espelha o submit_sm. O campo esm_class distingue os dois: o bit 0x04 marca um relatório de entrega. O ESME tem de responder sempre com deliver_sm_resp.
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
Um PDU, duas funções
O deliver_sm é a contraparte SMSC-para-ESME do submit_sm e partilha a mesma disposição de corpo. Transporta quer uma mensagem MO de entrada (um subscritor a enviar SMS para o seu long number ou short code) quer um relatório de entrega que reporta o destino de uma mensagem que submeteu antes. O seu bind receiver ou transceiver trata de ambos; bifurca com base no esm_class para os encaminhar corretamente.
Distinguir MO de DLR com o esm_class
Os bits de tipo de mensagem do esm_class identificam o conteúdo. Uma mensagem MO simples tem os bits de tipo de mensagem do esm_class a zero. Um relatório de entrega ativa o bit 0x04. Quando 0x04 está ativo, o short_message contém o texto do recibo do Apêndice B (id, stat, err…) e o TLV receipted_message_id transporta normalmente o message_id original. Não interprete o texto do recibo como conteúdo de utilizador.
| esm_class (bits de tipo de mensagem) | Payload |
|---|---|
| 0x00 | Mensagem normal originada em dispositivo móvel (MO) |
| 0x04 | Relatório de entrega SMSC (DLR) |
| 0x08 | Relatório de entrega do SME |
| 0x10 | Confirmação manual/do utilizador pelo SME |
| 0x20 | Interrupção de conversa (CDMA coreano) |
| 0x40 | Notificação de entrega intermediária |
Responda sempre com deliver_sm_resp
Para cada deliver_sm o ESME tem de devolver um deliver_sm_resp (0x80000005) com sequence_number correspondente e ESME_ROK. Se não confirmar, o SMSC trata a entrega como falhada, reenvia-a e — porque os PDUs pendentes por confirmar contam contra a janela — pode bloquear toda a sessão. Confirme prontamente e faça o processamento pesado de forma assíncrona.
SMSC → ESME deliver_sm seq=88 esm_class=0x00 (MO: user text)
ESME → SMSC deliver_sm_resp seq=88 status=ESME_ROK
SMSC → ESME deliver_sm seq=89 esm_class=0x04 (DLR: id:... stat:DELIVRD)
ESME → SMSC deliver_sm_resp seq=89 status=ESME_ROKdata_sm como alternativa
O data_sm (0x00000103) é uma operação mais leve e simplificada que pode transportar mensagens MO e recibos usando TLVs (nomeadamente message_payload) em vez do campo fixo short_message. Algumas redes preferem-no para tráfego interativo ou de estilo WAP. O suporte é opcional e específico do fornecedor — confirme antes de depender dele.
Perguntas frequentes
Como distingo um relatório de entrega de uma mensagem MO de entrada?
Verifique o esm_class no deliver_sm. Se o bit de tipo de mensagem 0x04 estiver ativo, é um relatório de entrega e o short_message contém o texto do recibo do Apêndice B. Se esses bits estiverem a zero, é uma mensagem normal originada no terminal por um subscritor.
O que acontece se eu não enviar deliver_sm_resp?
O SMSC assume que a entrega falhou e reenvia o deliver_sm. Os PDUs não confirmados também consomem a sua janela, pelo que não responder pode bloquear a sessão e produzir processamento duplicado de MO/DLR.
O deliver_sm tem os mesmos campos que o submit_sm?
Sim — o deliver_sm reutiliza a disposição de corpo do submit_sm (service_type, endereçamento TON/NPI, esm_class, data_coding, short_message, e assim por diante). Só diferem a direção e a interpretação do conteúdo.
Uma única mensagem MO pode ser concatenada?
Sim. Mensagens de entrada longas chegam como vários PDUs deliver_sm com um cabeçalho de concatenação UDH (bit UDHI 0x40 do esm_class ativo) ou TLVs SAR. Remonte-as por número de referência e sequência tal como faria com os segmentos de saída.
Especificações de origem
Os padrões publicados nos quais esta página se baseia. Abre num novo separador.