Análise do protocolo SMPP usando o Wireshark
Este artigo mostrará como executar a análise do protocolo SMPP usando o Wireshark para Adobe Campaign Classic.
Descrição description
Ambiente
Adobe Campaign Classic (ACC)
Problema/Sintomas
Saiba como analisar o tráfego SMPP usando o Wireshark.
A maioria dos SMS-C (Short Message Service Centers) de alto rendimento são compatíveis com o protocolo SMPP versão 3.4. Esse protocolo permite enviar SMS e receber 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 de SMS-C.
Como o protocolo SMPP contém muitas partes deixadas para a interpretação da equipe de implementação, há diferenças entre SMS-C diferentes.
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 resolution
Capturando tráfego de rede sem o 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. Esta é uma amostra da linha de comando tcpdump para capturar a porta 12345 para outfile.pcap:
tcpdump -i any -w outfile.pcap tcp port 12345
O arquivo outfile.pcap pode ser aberto no Wireshark para análise adicional.
Este tópico pressupõe que você esteja familiarizado com as noções básicas do Wireshark: como capturar pacotes, definir filtros simples, ler detalhes do pacote. Uma breve introdução está disponível no How-To Geek - Como usar o Wireshark para capturar, filtrar e adicionar pacotes do 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 a ferramenta Seguir fluxo de TCP 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.
-
SMPPProtocol
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ários 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 remontará 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 pode ser encontrada na seção 5.1.2.1 da especificação SMPP (Conjunto de comandos SMPP).
Respostas SMPP
O protocolo SMPP exige que todos os comandos sejam reconhecidos por uma PDU de resposta:
BIND_TRANSMITTER é confirmado por BIND_TRANSMITTER_RESP, SUBMIT_SM é confirmado por SUBMIT_SM_RESP, etc.
Existe um tempo limite para as respostas, normalmente é de 10, 30 ou 60 segundos. A resposta pode conter uma confirmação positiva (command _status = 0) ou um erro (consulte 5.1.3 command_status, table 5-2 na especificação SMPP para obter 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 campanha, confirmada por um RESP BIND. Estas operações são descritas na seção 4.1 da especificação SMPP (operação BIND).
A operação de vinculação 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 login pode ser encontrado no campo system_id.
No Campaign, você deve ver um pacote BIND_TRANSMITTER ao iniciar uma transferência MT e um pacote BIND_RECEIVER quando nlsm s aciona 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 uma PDU DELIVER_SM com bits 2-5 de esm_class s clear (frequentemente, esm_class será simplesmente 0).
A PDU DELIVER_SM deve ser respondida rapidamente por uma PDU DELIVER_SM_RESP com o mesmo sequence_number.
Enviando 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 uma PDU SUBMIT_SM. O SMS-C deve responder rapidamente com uma PDU SUBMIT_SM_RESP: 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 registered_delivery (descrito na seção 5.2.17 da especificação) indica ao SMS-C se um SR é solicitado para este MT específico. Se você não receber SR para uma mensagem específica, verifique se o campo está definido corretamente na PDU SUBMIT_SM.
Codificação de MT
Cuidado: a codificação de SMS é um assunto complexo com muitas armadilhas e várias implementações.
A prática recomendada é sempre entrar em contato com o parceiro de SMS-C em caso de problemas de codificação. Seu parceiro de SMS tem um conhecimento preciso da codificação compatível e regras especiais que podem ser aplicadas devido a limitações em sua plataforma técnica. Faça com que eles verifiquem o que você envia para eles e o que eles enviam 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 Wikipedia 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 é compatível com o 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 campo 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. Verifique com o parceiro de SMS-C qual codificação está associada a data_coding = 0 (o Adobe Campaign só oferece suporte ao 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:
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 bons artigos sobre o 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 o 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 é 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 um PDU DELIVER_SM com bits 2-5 de esm_class set.
A PDU DELIVER_SM deve ser respondida rapidamente por uma PDU DELIVER_SM_RESP com o mesmo sequence_number. 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:
Os SRs são enviados somente se o campo registered_delivery estiver definido no MT.
Observação: o conector SMPP do Adobe Campaign Classic não lida com o SR que chega antes do pacote SUBMIT_SM_RESP. 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 sua plataforma.
Decifrando o campo short_message do SR
O campo de texto dos PDUs 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 de 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: esse campo é ignorado pelo Campaign porque não é útil, não é confiável e pode até ser completamente ilegível se o SMS foi enviado usando outra codificação que não ASCII alfanumérico puro. Este comportamento é normal.
- Os nomes de campos não diferenciam maiúsculas de minúsculas (por exemplo, id: sub: Text: pode também ser referido como ID: SUB: text:).
- O campo dlvrd geralmente não é confiável, a menos que documentado pelo parceiro de 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 campo stat pode ter outros valores que não os definidos no Apêndice B. Use o senso comum e a documentação do parceiro de SMSC para entender seu significado.
- O campo err é totalmente dependente do SMS-C e, na maioria das vezes, é documentado pelo parceiro de 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-C 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 uma 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.