Referência do protocolo de mensagens.
Uma referência precisa e baseada em padrões para os protocolos que transportam SMS — escrita para os engenheiros que os implementam. Fundamentada nas especificações SMPP v3.4/v5.0 e 3GPP TS 23.038/23.040, com layouts de bytes reais, tabelas de campos e exemplos de formato de transmissão.
65 documentos sobre 9 protocolos
SMPP
O protocolo Short Message Peer-to-Peer (SMPP) é o protocolo de sessão binária que operadoras e agregadores expõem para mensagens A2P de alta taxa de transferência.
- Fundamentos
Visão geral do protocolo SMPP
O que é o SMPP, como funciona a sessão ESME↔SMSC, a diferença entre v3.4 e v5.0 e porque continua a ser o padrão para SMS A2P de elevado débito.
- Formato de transmissão
Anatomia do PDU SMPP: cabeçalho e corpo
A disposição exata de bytes de um PDU SMPP: o cabeçalho de 16 bytes (command_length, command_id, command_status, sequence_number), o corpo e como os campos são codificados.
- Sessão
Operações de bind SMPP e estados de sessão
Como uma sessão SMPP se autentica: bind_transmitter, bind_receiver e bind_transceiver, os campos system_id/password/system_type, interface_version, estados de sessão e unbind.
- Operações
SMPP submit_sm: todos os campos obrigatórios
Uma referência completa campo a campo de submit_sm — service_type, TON/NPI, esm_class, data_coding, registered_delivery, validity_period, short_message e o resto — com os valores que realmente importam.
- Operações
SMPP deliver_sm: mensagens MO e recibos
O deliver_sm transporta duas coisas do SMSC para o ESME: mensagens originadas no terminal (MO) e relatórios de entrega. Como distingui-las com esm_class e porque tem de responder sempre deliver_sm_resp.
- Erros
Códigos de erro command_status do SMPP
O campo command_status do SMPP e a gama de erros ESME_R*: o que significam os códigos comuns (ESME_RINVPASWD, ESME_RTHROTTLED, ESME_RMSGQFUL…) e como reagir a cada um.
- Formato de transmissão
Parâmetros opcionais TLV do SMPP
Os parâmetros opcionais do SMPP usam um formato Tag-Length-Value. A disposição de bytes do TLV mais as tags comuns: message_payload, receipted_message_id, message_state, user_message_reference e o conjunto de concatenação sar_*.
- Operações
Formato dos relatórios de entrega (DLR) do SMPP
O formato de texto do relatório de entrega do Apêndice B dentro do deliver_sm: id, sub, dlvrd, submit date, done date, stat, err e Text — mais as palavras-chave stat e os seus números message_state.
- Sessão
SMPP enquire_link, janela e limitação de taxa
Como o SMPP mantém uma sessão viva com enquire_link, como a janela limita os PDUs pendentes por confirmar e como ESME_RTHROTTLED e o TPS por bind governam o seu débito real.
- Segurança
Proteger o SMPP: TLS, autenticação e lista de IPs permitidos
O SMPP não tem cifra nativa. Como proteger um bind em produção: SMPP sobre TLS, autenticação por credenciais e por IP, listas de permissões e higiene de credenciais.
- Fundamentos
SMPP v3.4 vs v5.0: o que mudou
As diferenças práticas entre SMPP v3.4 e v5.0: controlo de congestão, operações de broadcast, estados de mensagem extra e TLVs — e porque a v3.4 continua a ser a interligação por omissão.
- Integração
Boas práticas de integração SMPP
Como construir uma integração SMPP que se mantém fiável em produção: estratégia de bind, disciplina de sequence_number, janela, repetições com recuo, idempotência, tratamento de DLR e reconexão.
Codificação SMS
Como o texto SMS é codificado na rede — GSM 7 bits, UCS-2, esquemas de codificação de dados, segmentação e as implicações de custo de cada caractere.
- Conjuntos de caracteres
O conjunto de caracteres GSM-7
O alfabeto predefinido GSM 7-bit completo da GSM 03.38: a tabela básica de 128 caracteres, a tabela de extensão baseada em escape (| ^ € { } [ ] ~ \ e form-feed) e como funciona o empacotamento de 7 bits.
- Conjuntos de caracteres
UCS-2 e SMS Unicode
Como o SMS transporta Unicode via UCS-2 (16 bits): o limite de 70 caracteres por mensagem única, 67 por segmento concatenado, o que força o UCS-2 e a ressalva dos pares de substituição para emoji.
- Codificação de dados
O data coding scheme (DCS)
O byte data-coding scheme que indica à rede como um SMS é codificado: GSM-7 (0x00), 8-bit (0x04), UCS-2 (0x08), mais as classes de mensagem (0/flash a 3/SIM) da GSM 03.38.
- Segmentação
Segmentação, concatenação de SMS e o UDH
Como o SMS longo é dividido e remontado: o User Data Header de 6 bytes, os resultantes 153 (GSM-7) e 67 (UCS-2) caracteres por segmento, o número de referência e o sequenciamento de segmentos.
- Custo
Deteção de codificação e custo do SMS
Como detetar se o texto é GSM-7 ou UCS-2, que caracteres forçam silenciosamente o UCS-2 e como a codificação determina a contagem de segmentos — e, portanto, o custo — de cada SMS que envia.
SS7 / MAP
O Sistema de Sinalização nº 7 e a camada MAP transportam SMS com terminação móvel, consultas HLR e gestão de mobilidade em redes centrais legadas.
- Fundamentos
Visão geral da pilha SS7: MTP, SCCP, TCAP, MAP, ISUP
Como a pilha SS7 está estruturada em camadas — transporte MTP1-3, endereçamento SCCP, transações TCAP e as user parts MAP e ISUP — e o que cada camada faz para SMS, chamadas e mobilidade.
- Transporte
MTP: o Message Transfer Part (níveis 1-3)
Os três níveis MTP que transportam o SS7: ligações físicas MTP1, ligação de dados com controlo de erros MTP2 (unidades de sinal MSU/LSSU/FISU) e encaminhamento por point code no MTP3 com partilha de carga e gestão de rede.
- Endereçamento
SCCP, global title translation e subsystem numbers
Como o SCCP estende o MTP3 com endereçamento por global title: o Called/Calling Party Address, a Global Title Translation (GTT), os subsystem numbers (HLR/VLR/MSC) e as classes sem ligação vs orientada à ligação.
- Transações
TCAP: transações, diálogos e componentes
Como o TCAP estrutura as trocas aplicacionais SS7: a subcamada de transação (Begin/Continue/End/Abort com transaction IDs), a parte de diálogo (application context) e a subcamada de componentes (Invoke, ReturnResult, ReturnError, Reject).
- MAP
Operações MAP: SRI-SM, ForwardSM, UpdateLocation e mais
As operações MAP que fazem funcionar as redes móveis: SendRoutingInfoForSM e MT-ForwardSM para SMS, UpdateLocation para roaming, ProvideSubscriberInfo e AnyTimeInterrogation para localização — com os seus opcodes da TS 29.002.
- Entrega de SMS
Fluxo de entrega de MT-SMS por SS7, passo a passo
O percurso completo de um SMS terminado no terminal sobre SS7: SMSC para HLR SendRoutingInfoForSM, o HLR devolve IMSI + MSC servidor, SMSC para MSC MT-ForwardSM, paging e entrega, e a repetição por subscritor ausente via MWD e AlertServiceCentre.
- Endereçamento
Point codes e endereçamento de rede SS7
Como o SS7 endereça pontos de sinalização: point codes ITU-T de 14 bits vs ANSI de 24 bits, a sua estrutura zone/network, a routing label OPC/DPC/SLS e como os point codes se relacionam com os global titles do SCCP.
- Segurança
Ameaças de segurança SS7 e as categorias GSMA FS.11
As principais classes de ataque SS7 — rastreio de localização, interceção de SMS/OTP, redirecionamento de chamadas e fraude — e como a GSMA FS.11 categoriza as mensagens MAP (categorias 1/2/3) para que as signalling firewalls as possam filtrar.
- Fundamentos
SS7 vs SIGTRAN: sinalização TDM sobre IP
Como o SIGTRAN se relaciona com o SS7 clássico: a mesma camada aplicacional MTP3/SCCP/TCAP/MAP, mas transportada sobre IP com SCTP e M3UA (ou SUA) em vez de ligações TDM MTP1/MTP2.
SIGTRAN
Sinalização SS7 transportada sobre IP — M3UA, SUA e SCTP — a ponte entre a sinalização TDM e os núcleos de pacotes modernos.
- Fundamentos
Visão geral do SIGTRAN: sinalização SS7 sobre IP
O que é o SIGTRAN: a framework do IETF (RFC 2719) para transportar sinalização SS7 sobre IP, usando transporte SCTP e camadas de adaptação (M3UA, SUA, M2PA) que preservam a pilha aplicacional MTP3/SCCP/TCAP/MAP.
- Transporte
SCTP: Stream Control Transmission Protocol
Como o SCTP funciona e porque o SIGTRAN o usa: entrega orientada a mensagens, multi-streaming para evitar head-of-line blocking, multi-homing para failover de caminho, o formato de pacote baseado em chunks e como difere do TCP.
- Adaptação
M3UA: camada de adaptação MTP3-User
Como o M3UA transporta SCCP e ISUP sobre SCTP: os papéis SG/ASP/AS, routing keys e routing contexts, classes de mensagem (Transfer, SSNM, ASPSM, ASPTM) e os modos IPSP vs signalling gateway.
- Adaptação
Camadas de adaptação M2PA e SUA
Mais duas camadas de adaptação SIGTRAN: o M2PA (RFC 4165) substitui o MTP2 para construir ligações STP baseadas em IP a correr MTP3 completo, e o SUA (RFC 3868) transporta SCCP-users (TCAP/MAP) diretamente sobre SCTP, contornando o MTP3.
- Arquitetura
Arquitetura de implementação SIGTRAN: SG, ASP, AS
Como se constrói uma rede SIGTRAN: o signalling gateway que faz a ponte entre TDM e IP, os application servers e os seus processos, as associações SCTP e os modos de redundância (override, load-share, broadcast) que dão disponibilidade de nível operador.
SIP / VoIP
O Protocolo de Iniciação de Sessão (Session Initiation Protocol) está por trás da voz programável, do trunking SIP e do controlo de chamadas VoLTE, além da pilha multimédia que o acompanha.
- Fundamentos
Visão geral do protocolo SIP
O que é o SIP e como funciona: um protocolo de sinalização de pedido/resposta baseado em texto (RFC 3261) que estabelece, modifica e termina sessões de média, os seus user agents, proxies e registrars, e as suas transações e diálogos.
- Pedidos
Métodos e pedidos SIP
Cada método de pedido SIP e o que faz: os seis métodos centrais da RFC 3261 (INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS) e as extensões comuns (INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE, PUBLISH).
- Respostas
Códigos de resposta SIP (1xx-6xx)
As seis classes de código de resposta SIP e as que importam: 1xx provisório (100 Trying, 180 Ringing), 2xx sucesso (200 OK), 3xx redireção, 4xx erro do cliente (404, 486), 5xx erro do servidor e 6xx falha global.
- Mensagens
Cabeçalhos SIP: Via, From, To, Call-ID, CSeq, Contact
Os cabeçalhos SIP essenciais e o que fazem: Via (com o parâmetro branch) para encaminhar respostas, From/To com tags, Call-ID, CSeq, Contact, Max-Forwards, e como os diálogos e transações são identificados a partir deles.
- Média
SDP: o Session Description Protocol
Como o SDP descreve uma sessão de média dentro do SIP: a estrutura de linhas v=/o=/s=/c=/t=/m=/a=, o modelo de oferta/resposta (RFC 3264), a negociação de codecs via rtpmap e os atributos de direção de média.
- Média
RTP e SRTP: o fluxo de média
Como a média flui depois de o SIP estabelecer uma chamada: o cabeçalho e conteúdo do RTP, os relatórios de qualidade RTCP, e a cifra e autenticação do SRTP com chaveamento via SDES ou DTLS-SRTP.
- Fluxo de chamada
Fluxo de chamada SIP: de INVITE a BYE
Uma chamada SIP completa percorrida passo a passo: INVITE com oferta SDP, 100 Trying, 180 Ringing, 200 OK com resposta SDP, o ACK de três vias, média RTP e o encerramento BYE/200 OK — mais como o CANCEL aborta uma chamada a tocar.
- Implementação
SIP trunking e o session border controller
O que é um SIP trunk e o papel do session border controller (SBC): travessia de NAT com STUN/TURN/ICE, ocultação de topologia via B2BUA, segurança e controlo de admissão na fronteira da rede, e transcodificação.
DIAMETER
O protocolo AAA e de sinalização por trás da mobilidade 4G/5G, políticas e tarifação (S6a, Gx, Gy), controlo IMS (Cx / Sh) e segurança de roaming Diameter na borda IPX.
- Fundamentos
Protocolo base DIAMETER: RFC 6733 explicado
Como funciona o protocolo base DIAMETER segundo a RFC 6733: o cabeçalho de mensagem de 20 bytes, os command codes e as flags R/P/E/T, a troca de capacidades CER/CEA, o watchdog DWR/DWA e o encerramento DPR/DPA, sobre SCTP ou TCP/TLS.
- Formato de mensagem
AVPs DIAMETER, tipos de dados e Result-Code
A anatomia de um AVP DIAMETER: código, flags V/M/P, comprimento, Vendor-Id opcional e dados; os tipos de dados base (Enumerated, Unsigned32, OctetString, Address, Time); os Grouped AVPs; e o modelo de erros Result-Code / Experimental-Result.
- Fundamentos
DIAMETER vs RADIUS: porque o DIAMETER substituiu o RADIUS
Porque é que o DIAMETER (RFC 6733) suplantou o RADIUS (RFC 2865) no AAA de operador: transporte SCTP fiável e failover, negociação de capacidades, um espaço de AVP de 32 bits muito maior, descoberta de pares, tratamento de erros mais rico e segurança mais forte — com uma tabela comparativa e notas de migração.
- Mobilidade (HSS)
DIAMETER S6a/S6d: mobilidade LTE para o HSS
Como a mobilidade LTE e a gestão de subscrição correm sobre DIAMETER S6a (MME↔HSS) e S6d (SGSN↔HSS) segundo a 3GPP TS 29.272: ULR/ULA, AIR/AIA, CLR/CLA, PUR/PUA e IDR/IDA, vetores de autenticação EPS-AKA, e as operações SS7 MAP que substituem.
- Política e tarifação
DIAMETER Gx e Gy: controlo de política e tarifação
Como o DIAMETER transporta o Policy and Charging Control: Gx (PCEF↔PCRF, CCR/CCA instalando regras PCC), Gy (tarifação online para o OCS com quota), e Rf (tarifação offline para o CDF) — mais os papéis PCRF/PCEF/OCS/OFCS, QoS/QCI e as interfaces Sy/Sd.
- IMS
DIAMETER Cx/Dx e Sh: registo IMS e o HSS
Como o registo e a autenticação IMS correm sobre DIAMETER Cx/Dx (S-CSCF/I-CSCF↔HSS) segundo a 3GPP TS 29.228/29.229 — UAR/UAA, MAR/MAA, SAR/SAA, LIR/LIA — mais a interface Sh (AS↔HSS) e como estas se ligam ao SIP REGISTER.
- Segurança
Segurança de roaming DIAMETER: DRA, DEA e a borda IPX
Como o encaminhamento e a segurança de interconexão DIAMETER funcionam na borda de roaming: o Diameter Routing Agent (DRA) e o Diameter Edge Agent (DEA), encaminhamento por realm, as classes de ameaça FS.19 (divulgação de informação, rastreio de localização, fraude), topology hiding e filtragem de AVP.
Canais de mensagens
Os canais de mensagens da camada de aplicação que as empresas utilizam para enviar mensagens são: RCS Business Messaging / MaaP, WhatsApp Business Cloud API, MMS (MM1 / MM4 / MM7), remetente verificado e com marca própria, e orquestração de canais alternativos.
- RCS
RCS Business Messaging e a plataforma MaaP
Como funciona o RCS Business Messaging: o Universal Profile da GSMA (RCC.07), a arquitetura Messaging-as-a-Platform (RCC.71), agentes verificados, descoberta de capacidades, fluxos MO/MT e eventos de tarifação — e em que difere a API de agente RBM de um bind SMPP.
- WhatsApp
WhatsApp Business Platform: Cloud API e templates
Como funciona a WhatsApp Business Platform: Cloud API vs On-Premises API, mensagens de template (HSM) vs mensagens de sessão, a janela de apoio ao cliente de 24 horas, as categorias marketing/utility/authentication, webhooks, níveis de qualidade do número e opt-in.
- MMS
Arquitetura MMS: as interfaces MM1, MM4 e MM7
Como funciona o MMS segundo a 3GPP TS 23.140 e o OMA MMS: o MMSC/servidor de relay, MM1 (telemóvel↔MMSC por WAP/HTTP), MM4 (MMSC↔MMSC por SMTP para inter-operador), MM7 (VASP↔MMSC por SOAP/XML), conteúdo MIME/SMIL, limites de tamanho e MMS A2P.
- Confiança e marca
Mensagens de remetente verificado e com marca
Como as marcas provam quem são em vários canais: RCS Verified Sender e agentes de negócio verificados, registo de sender ID da GSMA e verificação de marca, e certificados VMC com BIMI para logótipos verificados no e-mail — os controlos que combatem a falsificação e a personificação.
- Matriz de decisão
RCS vs SMS vs WhatsApp: uma matriz de decisão de canais
Uma comparação neutra em relação a fornecedores de RCS, SMS e WhatsApp para mensagens de negócio: funcionalidades, alcance e cobertura, encriptação ponta a ponta, confirmações de leitura e indicador de escrita, multimédia rica, modelos de custo, comportamento de fallback e restrições regulatórias — com orientação sobre quando usar qual.
- Orquestração
Fallback de canais e orquestração omnicanal
Como a entrega omnicanal encadeia em cascata os canais: verificações de capacidade, fallback RCS→SMS e WhatsApp→SMS, encaminhamento por menor custo versus melhor experiência, regras de repetição e timeout, e uma visão unificada de relatórios de entrega que concilia o estado em todos os canais.
- Interativas
Cartões ricos e mensagens interativas
Os blocos de construção interativos do RCS e do WhatsApp: cartões ricos e carrosséis, respostas e ações sugeridas, botões de resposta rápida e seletores de lista — com payloads JSON de exemplo para cada plataforma, além de orientação de UX e acessibilidade.
Numeração e identificação
A camada de numeração e identidade subjacente a cada mensagem e chamada: códigos E.164 / MSISDN, MCC-MNC / PLMN, identidade do assinante IMSI / IMEI, ENUM (E.164 → URI) e encaminhamento de portabilidade numérica móvel.
- Numeração pública
A numeração E.164 e o MSISDN explicados
Como funciona o plano de numeração internacional E.164 da ITU-T: indicativos de chamada de país, código nacional de destino (NDC) e número de assinante, o máximo de 15 dígitos, a estrutura do MSISDN e como normalizar números para E.164 no envio de mensagens A2P.
- Identidade de rede
Códigos MCC, MNC e PLMN explicados (E.212)
Como funciona o plano de identificação E.212 da ITU-T: o Mobile Country Code (MCC) de 3 dígitos e o Mobile Network Code (MNC) de 2 a 3 dígitos que se combinam numa identidade PLMN, como identificam a rede de origem, os intervalos de teste e em que difere o MCC-MNC do NDC do MSISDN.
- Identidade do assinante
IMSI, IMEI e identidade do assinante explicados
As identidades que distinguem um assinante de um dispositivo: o IMSI (MCC+MNC+MSIN, E.212), o IMEI (TAC+número de série), a chave de autenticação Ki, as identidades temporárias TMSI/GUTI, o SIM/USIM/eSIM (eUICC) e como o HLR mapeia o MSISDN no IMSI.
- Encaminhamento de números
ENUM: mapear números E.164 em URIs
Como o ENUM (IETF RFC 6116) mapeia números de telefone E.164 em URIs através do DNS: o domínio e164.arpa de dígitos invertidos, os registos NAPTR com reescrita por regexp, e a diferença entre ENUM público (de utilizador) e privado (de operador/infraestrutura) no encaminhamento de SIP e VoIP.
- Encaminhamento de números
Portabilidade de números móveis e encaminhamento
Como a portabilidade de números móveis (MNP) quebra a ligação entre um número marcado e a sua rede de origem: routing numbers (RN), All-Call-Query vs Onward Routing, bases de dados e dips MNP, e como a consulta HLR/MNP impulsiona o encaminhamento de menor custo e a entrega fiável.
API HTTP e webhooks
A camada HTTP/ REST acima dos protocolos de rede: design da API de mensagens REST, entrega de webhooks e verificação de assinatura HMAC, payloads de status/entrada, autenticação e assinatura, idempotência, limitação de taxa e erros problem+json — fundamentada em padrões (RFC 9457, rascunhos da IETF).
- Design de API
Design de API REST de mensagens: recursos, métodos, status codes
Como se modela uma API REST de mensagens baseada em normas: uma coleção messages, métodos HTTP e semântica de status codes segundo a RFC 9110, envio síncrono vs assíncrono (202 Accepted mais um callback de estado), negociação de conteúdo e versionamento em URL ou header — com uma tabela de trade-offs REST vs SMPP.
- Webhooks
Entrega e fiabilidade de webhooks: retries, ordenação, dead-letter
A arquitetura padrão de webhook/callback e o seu modelo de fiabilidade: entrega at-least-once, backoff exponencial com jitter nos retries, timeouts de entrega, garantias de ordenação, filas dead-letter, consumidores idempotentes e saúde do endpoint / circuit-breaking para proteger um recetor em falha.
- Segurança
Verificação de assinatura de webhook: HMAC-SHA256 e proteção contra replay
Como verificar que um webhook é autêntico e não adulterado: HMAC-SHA256 sobre o corpo em bruto, os headers de assinatura e timestamp, proteção contra replay com uma tolerância de timestamp e um nonce, comparação em tempo constante para derrotar timing attacks e rotação segura de segredos com chaves sobrepostas.
- Webhooks
Estado de mensagem (DLR) e payloads de webhook de entrada (MO)
Os esquemas de payload dos dois callbacks de mensagens centrais: o evento de estado de entrega (DLR) com o seu message id, enum de estado, motivo de erro e timestamps, e o evento de mensagem de entrada (MO) — mais uma taxonomia de tipos de evento e como um DLR HTTP mapeia num recibo deliver_sm SMPP.
- Segurança
Autenticação de API e assinatura de pedidos: tokens, HMAC, OAuth, mTLS
As formas padrão de autenticar uma API HTTP de mensagens: bearer tokens e API keys no header Authorization, assinatura HMAC de pedidos sobre um pedido canónico, âmbito e rotação de chaves, mutual TLS e OAuth 2.0 client-credentials para acesso máquina-a-máquina.
- Fiabilidade
Idempotência e rate limiting: chaves, 429, Retry-After, RateLimit
Dois padrões HTTP standards-track para clientes seguros e bem-comportados: o header Idempotency-Key (draft IETF) para submissão exactly-once com uma janela de desduplicação e replay da resposta, e rate limiting — 429 com Retry-After, os headers RateLimit / RateLimit-Policy (draft IETF), token buckets e backpressure do cliente.
- Design de API
Erros de API (problem+json) e paginação (cursor, header Link)
Duas normas que mantêm uma API HTTP previsível: RFC 9457 problem+json para erros legíveis por máquina (type, title, status, detail, instance) com uma taxonomia retryable-vs-terminal, e paginação — cursor vs offset, o header Link da RFC 8288 para next/prev e limites de tamanho de página.
Da especificação ao fio.
Estas referências descrevem os protocolos que BroadNet opera em nível de operadora desde 2003 — em 200+ países e com 1.000+ conexões de operadoras. Quando estiver pronto para enviar, a documentação e as ferramentas abaixo o guiarão da leitura ao envio.