Análise do protocolo SMPP usando Wireshark

Descrição

Ambiente

Adobe Campaign Classic

Problema/Sintomas

Saiba como analisar o tráfego SMPP usando o Wireshark.

A maioria dos centros de serviços de mensagens curtas de alta throughput (SMS-C) é compatível com o protocolo SMPP versão 3.4. Esse protocolo permite o envio de SMS e o recebimento de informações sobre o delivery desses SMS. O protocolo SMPP está documentado na Especificação de Protocolo SMPP v3.4 disponível na Internet como um documento PDF.

Este artigo não substitui esta especificação: fornece dicas práticas sobre como interpretar a especificação do protocolo e combiná-la com a exibição do Wireshark para ajudar a solucionar problemas entre o Adobe Campaign e o parceiro SMS-C.

Como o protocolo SMPP contém muitas partes deixadas para a interpretação da equipe de implementação, há diferenças entre diferentes SMS-C.

Ao solucionar problemas, sempre entre em contato com o parceiro de SMS-C para obter informações ou para ajudá-lo a verificar o que você obtém. Se o SMS-C responder com um erro, seu parceiro de SMS-C será a melhor pessoa para dizer por que ele respondeu com o erro. Se estiver usando um simulador SMPP em vez de se conectar a um SMS-C real, você deve usar o código fonte (ou um depurador) para entender o que está acontecendo.

Resolução

Capturando tráfego de rede sem Wireshark

Se você não tiver acesso direto à máquina, talvez seja necessário capturar usando ferramentas de linha de comando, como tcpdump. Se você já conhece a porta TCP da conexão, coloque o filtro correto para evitar capturar todo o tráfego. Aqui está uma linha de comando tcpdump de amostra para capturar a porta 12345 para outfile.pcap:

tcpdump -i any -w outfile.pcap tcp port 12345

O arquivo outfile.pcap pode então ser aberto em Wireshark para mais análise.

Manipulação de Wireshark

Este tópico pressupõe que você esteja familiarizado com os conceitos básicos do Wireshark: como capturar pacotes, definir filtros simples, ler detalhes do pacote. Uma breve introdução está disponível em howjoin - Como usar o Wireshark para capturar, filtrar e pacotes Inspect.

Para filtrar o tráfego SMPP no Wireshark, há três recursos importantes:

• Use um filtro de exibição na porta do SMS-C.
  
  Por exemplo, se o SMS-C usar a porta 10000, use o seguinte filtro:
  tcp.port == 10000

• Para isolar pacotes por número de telefone ou por conteúdo de texto, use o recurso de pesquisa com as seguintes configurações:
  
  

• Use o Seguir fluxo de TCP ferramenta para isolar o fluxo em que você está trabalhando.
  
  Feche a janela de texto vermelha/azul que aparece porque ela é útil somente para protocolos de texto que não são relevantes para SMPP.

  

Protocolo SMPP
O protocolo funciona por TCP e é totalmente binário, o que significa que ferramentas especiais como o Wireshark (ou um editor hexadecimal) são necessárias para descriptografar o conteúdo do fluxo.

O fluxo é composto de PDUs independentes: cada PDU é uma mensagem que contém um comando, um status, um número de sequência e outras informações com base no comando.

Devido à natureza do TCP como um protocolo de fluxo, um pacote TCP pode conter mais de uma PDU e as PDUs podem se estender por 2 ou mais pacotes TCP. O Wireshark reorganizará as PDUs corretamente, de modo que seja mais transparente para o usuário do Wireshark.

Este é um exemplo de PDUs passando pela rede ao enviar um MT e depois receber um SR:

Observação: A lista de comandos padrão encontra-se na seção 5.1.2.1 da especificação SMPP (SMPP Command set).

Respostas SMPP
O protocolo SMPP requer que todos os comandos sejam reconhecidos por uma PDU de resposta:

BIND_TRANSMITTER é reconhecido por BIND_TRANSMITTER_RESP, SUBMIT_SM for reconhecido por SUBMIT_SM_RESP, etc.

Existe um tempo limite para respostas, normalmente é de 10, 30 ou 60 segundos. A resposta pode conter uma confirmação positiva (comando _status = 0) ou um erro (consulte 5.1.3 status_de_comando, quadro 5-2 na especificação SMPP para a lista de erros padrão). Na maioria das vezes, essas respostas são imediatas e o tempo limite da resposta não é atingido.

Diferencie erros de resposta SMPP e códigos de erro SR: o mesmo código de erro pode significar coisas diferentes no erro de resposta ou no campo de erro SR. Ao relatar um código de erro, você deve ter muito cuidado sobre onde o encontrou, pois o significado do valor depende do seu contexto.

Inicialização da conexão SMPP
A conexão SMPP é iniciada pela conexão usando TCP. Em seguida, uma operação BIND é enviada por uma campanha, reconhecida por um BIND RESP. Estas operações são descritas no ponto 4.1 da especificação SMPP (operação BIND).

A operação de vínculo faz a verificação de login/senha e troca informações sobre o nome da plataforma, a versão e outros campos descritos na especificação.

Observação: O logon pode ser encontrado no campo system_id .

No Campaign, você deve ver um BIND_TRANSMITTER pacote ao iniciar uma transferência MT e uma BIND_RECEIVER packet when nlsm s dispara uma conexão MO/SR.

Transmissor, receptor e transceptor: o conector SMPP para Campaign Classic funciona em um modo transmissor/receptor separado: há duas conexões TCP, uma para transmitir MT e outra para receber MO e SR. Observe que a conexão TCP é sempre iniciada pelo Campaign, mesmo para o modo receptor.

O SMPP também fornece um modo transceptor, mas esse modo não é implementado no conector SMPP para Campaign Classic.

O conector SMPP usa várias conexões em paralelo para transmitir o MT. Isso não pode ser controlado por causa da forma como o conector é projetado.

Recebendo MO
Quando o receptor está vinculado, o SMS-C pode enviar MO a qualquer momento. O MO é enviado usando um DELIVER_SM PDU com bits 2-5 de esm_clas s claro (muitas vezes, esm_class será simplesmente 0).

O *DELIVER_SM* A PDU deve ser respondida rapidamente por um *DELIVER_SM_RESP* PDU com o mesmo *número_sequência*.

Envio de MT
Para enviar um MT, o transmissor deve ser vinculado com êxito. Antes de mais nada, verifique se o processo de vinculação foi executado com êxito.

O MT é enviado em um SUBMIT_SM PDU. O SMS-C deve responder rapidamente com uma SUBMIT_SM_RESP PDU: esse pacote de resposta é especial porque contém a ID da mensagem no banco de dados do SMS-C (sempre inclua essa ID ao falar com o parceiro SMS-C para ajudá-lo a encontrar a mensagem mais rapidamente). Essa ID estará presente no SR e é a única maneira de corresponder o MT com seu SR correspondente.

O campo register_delivery (descrito no ponto 5.2.17 da especificação) indica ao SMS-C se é solicitada uma SR para este MT específico. Se você não receber SR para uma mensagem específica, verifique se o campo está definido corretamente na variável SUBMIT_SM PDU.

Codificação de MT
Cuidado: A codificação de SMS é um assunto complexo com muitas armadilhas e várias implementações.

Uma boa prática é sempre entrar em contato com o parceiro SMS-C em caso de problemas de codificação. Seu parceiro SMS tem um conhecimento preciso da codificação suportada e regras especiais que podem ser aplicadas devido a limitações em sua plataforma técnica. Faça-os verificar o que você enviou para eles e o que eles enviaram de volta para você. É o único caminho para uma interconexão bem-sucedida e estável.

As mensagens SMS usam uma codificação especial de sete bits, geralmente chamada de codificação GSM7. Consulte a Wikipédia GSM 03.38 (em inglês).

No protocolo SMPP, o texto GSM7 será expandido para oito bits por caractere para facilitar a solução de problemas. O SMS-C o compactará em 7 bits por caractere antes que seja enviado ao dispositivo móvel. Isso significa que o campo short_message do SMS pode ter até 160 bytes de comprimento no quadro SMPP, enquanto é limitado a 140 bytes quando enviado na rede móvel (o bit mais significativo é simplesmente descartado).

Em caso de problemas de codificação, veja alguns itens importantes a serem verificados:

• Primeiro, saiba quais caracteres pertencem a qual codificação. O GSM7 é famoso pelo seu apoio parcial a marcas diacríticas (acentos). Especialmente em francês, em que "é" e "è" fazem parte do GSM7, mas "ê", "â" ou "ï" não fazem parte. A situação não é melhor quando se trata de espanhol.
• O C com cedilha (ç) está presente apenas em maiúsculas no alfabeto GSM7, mas alguns telefones o renderizam em minúsculas ou em letras maiúsculas “inteligentes”: a recomendação geral é evitar completamente e remover o cedilha (ainda é bem legível em francês) ou alternar para UCS-2.
• Não use ASCII no SMS, a menos que solicitado explicitamente pelo parceiro de SMS-C: essa codificação desperdiça espaço porque tem caracteres de 8 bits e menos cobertura do que o GSM7.
• O Latin-1 nem sempre é compatível: verifique a compatibilidade com seu parceiro de SMS-C antes de tentar usar Latin-1.
• As tabelas de correspondência de idiomas nacionais não são compatíveis com o conector do Adobe Campaign Classic. Em vez disso, você deve usar UCS-2.
• UCS-2 e UTF-16 são frequentemente misturados por telefones. Esse é um problema para as pessoas que enviam emoji e outros caracteres raramente usados que não estão presentes no UCS-2.
• A codificação GSM7 não é suportada pelo Wireshark: caracteres especiais serão exibidos incorretamente. Se for necessário verificar se uma string GSM7 está corretamente codificada, você deve comparar códigos hexadecimais com a tabela GSM7.

O data_coding informa qual codificação é usada. O único problema é que o valor 0 significa a codificação padrão de SMS-C na especificação, mas em geral significa GSM7. Verificar com o SMS-C parceiro que a codificação está associada ao data_coding = 0 (o Adobe Campaign suporta apenas o GSM7 para data_coding = 0).

O tamanho máximo de uma mensagem depende de sua codificação. Esta tabela resume todas as informações relevantes:

Codificação	data_coding	Tamanho da mensagem (caracteres)	Tamanho da parte para SMS multiparte	Caracteres disponíveis
GSM7	0	160	152	Conjunto de caracteres básicos GSM7 + extensão (caracteres estendidos ocupam 2 caracteres)
Latino-1	3	140	134	ISO-8859-1
UCS-2 UTF-16	8	70	67	Unicode (varia de telefone para telefone)

Cabeçalho de dados do usuário (UDH)
O UDH (Cabeçalho de dados do usuário) é um pequeno cabeçalho binário adicionado ao texto de um SMS. Ele pode acionar recursos especiais como concatenação de SMS, tabelas de alternância de idioma nacional, logotipos/imagens (raramente usadas) ou push de WAP.

Como o UDH faz parte do campo de texto (campo SMPP short_message), ele reduz o tamanho efetivo de um SMS. Por exemplo, um UDH de SMS concatenado consumirá 6 bytes por parte do SMS (ou seja, 6 bytes reais de 8 bits, não caracteres de 7 bits), deixando espaço suficiente para apenas 152 caracteres de 7 bits por parte da mensagem.

A Wikipédia tem artigos legais sobre Cabeçalho de dados do usuário e SMS concatenado (em inglês).

Para saber se uma short_message contém um UDH, verifique os bits 6 e 7 de esm_class (consulte a seção 5.2.12 da especificação). O Wireshark analisa a UDH na interface e fornece informações precisas.

Na captura de tela acima, você pode ver o cabeçalho de dados do usuário no campo de mensagem (1), as informações contidas no UDH (2) e algumas informações extras não pertencentes ao pacote, mas computadas pelo Wireshark (3): o campo Short Message body é especialmente interessante, pois contém a mensagem completa remontada pelo Wireshark.

Recebendo SR
Quando o receptor está vinculado, o SMS-C pode enviar SR a qualquer momento. O SR é enviado usando uma PDU DELIVER_SM com bits 2-5 de esm_class definido.

O DELIVER_SM A PDU deve ser respondida rapidamente por um DELIVER_SM_RESP PDU com o mesmo número_sequência. Para encontrar o MT correspondente a este SR, procure por um SUBMIT_SM_RESP com a mesma ID. Por exemplo, este é o MT que corresponde ao SR:

O SR é enviado somente se a variável register_delivery é definido no MT.

Observação: O conector SMPP do Adobe Campaign Classic não lida com o SR que chega antes do SUBMIT_SM_RESP pacote. A especificação não proíbe explicitamente esse comportamento, mas é considerada um comportamento incorreto (significaria que a mensagem foi recebida antes de ser enviada). Se você encontrar esse caso com muita frequência, peça ao seu parceiro de SMS-C para corrigir a plataforma dele.

Decifrando o campo short_message do SR
O campo de texto dos PDUs do SR tem uma codificação especial descrita no Apêndice B da especificação do protocolo SMPP. Infelizmente, esse formato é apenas uma recomendação sem fazer parte do protocolo, mesmo que a maioria dos SMS-C respeitem mais ou menos esse mesmo formato.

Você deve solicitar diretamente ao parceiro SMS-C uma documentação de sua própria implementação e verificar novamente se ela corresponde ao que você vê no Wireshark. Na maioria das vezes, os implementadores de SMS-C nem conhecem sua implementação e isso gera problemas e mal-entendidos. Não hesite em solicitar ajuda ao parceiro de SMS-C caso tenha dúvidas sobre esse campo (especialmente os códigos de erro).

O formato básico é o seguinte:

id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:EEE
Text:........

Estas são as diretrizes gerais para a leitura da linha acima:

• A id é a mesma que foi enviada no SUBMIT_SM_RESP do MT correspondente.
• Você pode ignorar problemas no campo de texto: este campo é ignorado pelo Campaign porque é inútil, não confiável e pode até ser completamente ilegível se o SMS foi enviado usando outra codificação que não o ASCII alfanumérico puro. Este comportamento é normal.
• Os nomes de campos não fazem distinção entre maiúsculas e minúsculas (por exemplo, id: sub: Texto: também pode ser anotado como ID: SUB: texto:).
• O dlvrd geralmente não é confiável, a menos que documentado pelo parceiro do SMS-C.
• As datas podem ter qualquer fuso horário, tornando-as praticamente inúteis, ou simplesmente estão incorretas porque o relógio do servidor remoto está desligado.
• O stat O campo pode ter outros valores que não os definidos no apêndice B. Use o senso comum e a documentação do parceiro SMSC para entender seu significado.
• O err depende completamente do SMS-C e, na maioria das vezes, é documentado pelo parceiro SMS-C. Geralmente, o código 000 significa sucesso, enquanto qualquer outro código indica erros. O campo geralmente é numérico, mas também pode ser hexadecimal.

Vários SRs para o mesmo MT
Alguns SMS-Cs enviam vários SRs para o mesmo MT para rastrear o progresso do MT na rede. Isso é inútil porque, na maioria das vezes, o cliente deseja saber apenas quando a mensagem foi recebida (geralmente, esse é o último SR).

Na dúvida, trabalhe somente no último SR recebido do SMS-C para encontrar o estado de uma mensagem.

Janela SMPP
Como as operações e respostas são assíncronas, você pode otimizar as taxas de transferência enviando vários PDUs de operação antes de aguardar as respostas. O número de mensagens que não têm resposta é chamado de janela.

Exemplo de transmissão com uma janela máxima de 4:

A implementação atual não controla a janela e espera que o SMS-C remoto seja rápido o suficiente para lidar com o MT.