Mensagem curta ponto a ponto

Short Message Peer-to-Peer (SMPP) no setor de telecomunicações é um protocolo aberto e padrão do setor projetado para fornecer uma interface de comunicação de dados flexível para a transferência de dados de mensagens curtas entre Entidades Externas de Mensagens Curtas (ESMEs), Entidades de Roteamento (REs) e SMSC.

O SMPP é frequentemente usado para permitir que terceiros (por exemplo, provedores de serviços de valor agregado, como organizações de notícias) enviem mensagens, muitas vezes em massa, mas também pode ser usado para peering de SMS. O SMPP é capaz de transportar mensagens curtas, incluindo EMS, notificações de correio de voz, Cell Broadcasts, mensagens WAP, incluindo mensagens WAP Push (usadas para entregar notificações MMS), mensagens USSD e outras. Devido à sua versatilidade e suporte a protocolos SMS não GSM, como UMTS, IS-95 (CDMA), CDMA2000, ANSI-136 (TDMA) e iDEN, o SMPP é o protocolo mais comumente usado para troca de mensagens curtas fora das redes SS7.

Histórico

SMPP (Short Message Peer-to-Peer) foi originalmente projetado pela Aldiscon, uma pequena empresa irlandesa que mais tarde foi adquirida pela Logica (desde 2016, após uma série de mudanças Mavenir). O protocolo foi originalmente criado por um desenvolvedor, Ian J Chambers, para testar a funcionalidade do SMSC sem usar equipamento de teste SS7 para enviar mensagens.

Em 1995, o ETSI incluiu o protocolo SMPP no relatório técnico TR 03.39.

Em 1999, a Logica entregou formalmente o SMPP ao SMPP Developers Forum, mais tarde renomeado como The SMS Forum.

O Fórum SMS foi dissolvido em 2007, com este anúncio: "O Fórum SMS, uma organização sem fins lucrativos com a missão de desenvolver, fomentar e promover SMS (serviço de mensagens curtas) em benefício da indústria global sem fio será dissolvida em 27 de julho de 2007. Como parte dos termos originais de transferência, a propriedade do SMPP voltou para a Mavenir.

Operação

Ao contrário do seu nome, o SMPP utiliza o modelo de operação cliente-servidor. O Centro de Atendimento de Mensagens Curtas (SMSC) normalmente atua como um servidor, aguardando conexões das ESMEs. Quando o SMPP é usado para peering de SMS, o MC remetente geralmente atua como um cliente.

O protocolo é baseado em pares de PDUs de solicitação/resposta (unidades de dados de protocolo ou pacotes) trocados por conexões OSI camada 4 (sessão TCP ou X.25 SVC3). A porta conhecida atribuída pela IANA para SMPP ao operar sobre TCP é 2775, mas vários números de porta arbitrários são frequentemente usados em ambientes de mensagens.

Antes de trocar qualquer mensagem, um comando de ligação deve ser enviado e confirmado. O comando bind determina em qual direção será possível enviar mensagens; bind_transmitter permite apenas que o cliente envie mensagens para o servidor, bind_receiver significa que o cliente receberá apenas as mensagens e bind_transceiver (introduzido no SMPP 3.4) permite a transferência de mensagens em ambas as direções. No comando bind o ESME se identifica usando system_id, system_type e senha; o campo address_range projetado para conter o endereço ESME geralmente é deixado em branco. O comando bind contém o parâmetro interface_version para especificar qual versão do protocolo SMPP será usada.

A troca de mensagens pode ser síncrona, onde cada par espera por uma resposta para cada PDU enviada, ou assíncrona, onde múltiplas solicitações podem ser emitidas sem espera e reconhecidas em uma ordem distorcida pelo outro par; o número de solicitações não confirmadas é chamado de janela; para obter o melhor desempenho, ambos os lados de comunicação devem ser configurados com o mesmo tamanho de janela.

Versões

O padrão SMPP evoluiu ao longo do tempo. As versões mais comumente usadas do SMPP são:

• SMPP 3.3 a versão mais antiga usada (apesar de suas limitações, ainda é amplamente utilizada); suporta apenas o GSM. Gera uma resposta imediata para cada mensagem enviada.
• SMPP 3.4 adiciona parâmetros opcionais de tag-length-value (TLV), suporte a tecnologias SMS não GSM e suporte ao transceptor (conexões únicas que podem enviar e receber mensagens). A troca de PDUs de solicitação e resposta SMPP entre um Transmissor ESME e SMSC pode ocorrer sincronizada ou assíncrona.
• SMPP 5.0 é a versão mais recente do SMPP; adiciona suporte para transmissão de células, controle de fluxo inteligente. A partir de 2023, não é amplamente utilizado.

A versão aplicável é passada no parâmetro interface_version de um comando de ligação.

Formato PDU (após versão 3.4)

As PDUs SMPP são codificadas em binário para maior eficiência. Eles começam com um cabeçalho que pode ser seguido por um corpo:

Cabeçalho PDU

Cada PDU começa com um cabeçalho. O cabeçalho consiste em 4 campos, cada um com comprimento de 4 octetos:

command_length

É o comprimento total do PDU em octets (incluindo o próprio campo command_length); deve ser ≥ 16 como cada PDU deve conter o cabeçalho 16 octet

command_id

Identifica a operação SMPP (ou comando). Se o bit mais significativo for limpo, esta é uma operação de solicitação. Caso contrário, é uma resposta.

command_status

Sempre tem um valor de 0 em pedidos; em respostas carrega informações sobre o resultado da operação

sequence_number

É usado para correlacionar solicitações e respostas dentro de uma sessão SMPP; permite comunicação assíncrona (usando um método de janela deslizante)

Todos os campos numéricos no SMPP usam a ordem big endian, o que significa que o primeiro octeto é o Byte Mais Significativo (MSB).

Exemplo

Este é um exemplo da codificação binária de uma PDU submit_sm de 60 octetos. Os dados são mostrados em valores de octeto hexadecimal como um único despejo e seguidos por um detalhamento do cabeçalho e do corpo dessa PDU.

Isso é melhor comparado com a definição da PDU submit_sm da especificação SMPP para entender como a codificação corresponde ao campo por definição de campo.

As divisões de valores são mostradas com decimais entre parênteses e valores hexadecimais depois disso. Onde você vê um ou vários octetos hexadecimais anexados, isso ocorre porque o tamanho do campo fornecido usa codificação de 1 ou mais octetos.

Novamente, ler a definição da PDU submit_sm da especificação tornará tudo isso mais claro.

Cabeçalho PDU

'command_length', (60)... 00 00 00 3C
"command_id", (4)... 00 00 00 04
'command_status', (0)... 00 00 00
'sequence_number', (5)... 00 00 00 05

Corpo da PDU

'service_type', ()... 00
'source_addr_ton', (2)... 02
'source_addr_npi', (8)... 08
'source_addr', (555)... 35 35 35 00
'dest_addr_ton', (1)... 01
'dest_addr_npi', (1)... 01
'dest_addr', (555555555)... 35 35 35 35 35 35 35 35 35 35 35 35 35 35 00
'esm_class', (0)... 00:00
'protocolo_id', (0)... 00:00
'priority_flag', (0)... 00:00
'schedule_delivery_time', (0)... 00
'validity_period' (0)... 00:00
'registered_delivery', (0)... 00
'replace_if_present_flag' (0)... 00
'data_coding', (3)... 03
'sm_default_msg_id', (0)... 00
'sm_length', (15)... 0F
'short_message', (Hello Wikipedia)... 48 65 6C 6F 20 57 69 6B 69 70 65 64 69 61

Observe que o texto no campo short_message deve corresponder ao data_coding. Quando o data_coding for 8 (UCS2), o texto deverá estar em UCS-2BE (ou sua extensão, UTF-16BE). Quando data_coding indica uma codificação de 7 bits, cada septeto é armazenado em um octeto separado no campo short_message (com o bit mais significativo definido como 0). SMPP 3.3 data_coding copiou exatamente os valores TP-DCS do GSM 03.38, o que o torna adequado apenas para alfabeto padrão GSM de 7 bits, UCS2 ou mensagens binárias; O SMPP 3.4 introduziu uma nova lista de valores data_coding:

O significado de data_coding=4 ou 8 é o mesmo do SMPP 3.3. Outros valores no intervalo de 1 a 15 são reservados no SMPP 3.3. Infelizmente, ao contrário do SMPP 3.3, onde data_coding=0 era inequivocamente o alfabeto padrão GSM de 7 bits, para SMPP 3.4 e superior o alfabeto padrão GSM de 7 bits está faltando nesta lista e data_coding=0 pode ser diferente para vários centros de serviço de mensagens curtas - pode ser ISO-8859-1, ASCII, alfabeto padrão GSM de 7 bits, UTF-8 ou até mesmo configurável por ESME. Ao usar data_coding=0, ambos os lados (ESME e SMSC) devem ter certeza de que consideram a mesma codificação. Caso contrário, é melhor não usar data_coding=0. Pode ser complicado usar o alfabeto padrão GSM de 7 bits, alguns centros de serviço de mensagens curtas exigem data_coding=0, outros, por exemplo. data_coding=241.

Peculiaridades

Apesar da sua ampla aceitação, o SMPP apresenta uma série de características problemáticas:

• Não. data_coding para o alfabeto padrão GSM 7-bit
• Significado não padronizado data_coding=0
• Suporte tio para codificação Shift-JIS
• Incompatibilidade de submit_sm_resp entre as versões SMPP
• Usando os recibos de entrega SMSC SMPP 3.3, especialmente a mensagem Formato de identidade neles

Sem data_coding para alfabeto padrão GSM de 7 bits

Embora o valor data_coding no SMPP 3.3 seja baseado no GSM 03.38, desde o SMPP 3.4 não há valor data_coding para o alfabeto GSM de 7 bits (GSM 03.38). Contudo, é comum que DCS=0 indique o alfabeto GSM de 7 bits, particularmente para conexões SMPP a SMSCs em redes móveis GSM. É ainda mais ambíguo se o alfabeto de 7 bits é compactado, como no GSM, permitindo o envio de 160 caracteres em 140 octetos, ou se cada caractere de 7 bits ocupa um octeto inteiro (com o bit mais alto definido como zero, como no ASCII).).

Significado não padronizado de data_coding=0

De acordo com SMPP 3.4 e 5.0 o data_coding=0 significa ″Alfabeto Padrão SMSC″. A codificação realmente depende do tipo de SMSC e de sua configuração.

Suporte pouco claro para codificação Shift-JIS

Uma das codificações no padrão CDMA C.R1001 é Shift-JIS usada para japonês. SMPP 3.4 e 5.0 especificam três codificações para japonês (JIS, ISO-2022-JP e Extended Kanji JIS), mas nenhuma delas é idêntica a CDMA MSG_ENCODING 00101. Parece que a codificação de pictograma (data_coding=9) é usada para transportar o mensagens em Shift-JIS no SMPP.

Incompatibilidade de submit_sm_resp entre versões SMPP

Quando um submit_sm falha, o SMSC retorna um submit_sm_resp com valor diferente de zero de command_status e ″empty″ message_id.

• SMPP 3.3 afirma explicitamente sobre o message_id field ′′′ Se ausente este campo deve conter um único byte NULL′′. O comprimento do PDU é de pelo menos 17 octets.
• SMPP 3.4 contém uma nota infeliz no SUBMIT_SM_RESP seção ′′′The submit_sm_resp PTU O corpo não é devolvido se o command_status campo contém um valor não zero.′′′ Então o comprimento do PDU é de 16 octets.
• SMPP 5.0 apenas especifica que message_id é um parâmetro obrigatório do tipo C-Octet string do submit_sm_resp mensagem. De acordo com a seção 3.1.1 Configurações NULL, ′′′A NULL string ′′′′′ é codificado como 0x00′′. O comprimento do PDU é de pelo menos 17 octets.

Para melhor compatibilidade, qualquer implementação SMPP deve aceitar ambas as variantes de submit_sm_resp negativo, independentemente da versão do padrão SMPP usado para a comunicação.

A intenção original dos cenários de erro foi que nenhum corpo seria retornado na resposta do PDU. Este foi o comportamento padrão exibido em todo o Aldiscon/Logica SMSC e também na maioria dos outros fornecedores. Quando o SMPP 3.4 estava sendo tomado pelo fórum da WAP, foram solicitados diversos esclarecimentos sobre se um corpo deveria ser incluído com a resposta NACKed e foram tomadas medidas para esclarecer isso em vários lugares na especificação, incluindo a submit_sm seção e também no bind_transceiver Secção. O que deveria ter sido feito foi adicionar a clarificação que eventualmente adicionamos em V5.0. que os corpos não devem ser incluídos em respostas de erro. Alguns fornecedores têm sido muito tolos em suas implementações, incluindo corpos em rejeitados bind_transmitter respostas, mas não sobre bind_transceiver respostas etc. A recomendação que eu faria aos vendedores.. como sugerido acima. aceitar ambas as variantes. Mas também é sábio deixar-se emitir NACKed submit_sm_resp e deliver_sm_resp PDUs com e sem um corpo vazio. No caso destes dois PDUs, esse corpo vazio vai parecer um único octet NULL no final do fluxo. A razão pela qual você pode precisar dessa capacidade de incluir o que eu chamo de corpos fictícios com pedidos NACKed é que o outro lado da equação pode ser incapaz ou não disposto a mudar sua implementação para tolerar o corpo desaparecido. (Trabalhei em três versões da especificação SMPP em Aldiscon/Logica e concebi a solução ESME para redes abertas)

—Cormac Long

ID da mensagem em recibos de entrega SMSC do SMPP 3.3

A única maneira de passar recibos de entrega no SMPP 3.3 é colocar as informações em formato de texto no campo short_message; entretanto, o formato do texto é descrito no Apêndice B do SMPP 3.4, embora o SMPP 3.4 possa (e deva) usar TLVs receipted_message_id e message_state para esse propósito. Embora o SMPP 3.3 afirme que o ID da mensagem é uma string C-Octet (Hex) de até 8 caracteres (mais a terminação '