Referencia del protocolo de mensajería.
Una referencia precisa y estandarizada sobre los protocolos de SMS, escrita para los ingenieros que los implementan. Basada en las especificaciones SMPP v3.4/v5.0 y 3GPP TS 23.038/23.040, incluye diagramas de bytes reales, tablas de campos y ejemplos de formatos de cableado.
65 documentos sobre 9 protocolos
SMPP
El protocolo de mensajes cortos entre pares (SMP) es el protocolo de sesión binaria que los operadores y agregadores exponen para la mensajería A2P de alto rendimiento.
- Fundamentos
Descripción general del protocolo SMPP
Qué es SMPP, cómo funciona la sesión ESME↔SMSC, la diferencia entre v3.4 y v5.0 y por qué sigue siendo el estándar para SMS A2P de alto rendimiento.
- Formato de trama
Anatomía de una PDU SMPP: cabecera y cuerpo
La disposición exacta en bytes de una PDU SMPP: la cabecera de 16 bytes (command_length, command_id, command_status, sequence_number), el cuerpo y cómo se codifican los campos.
- Sesión
Operaciones bind y estados de sesión en SMPP
Cómo se autentica una sesión SMPP: bind_transmitter, bind_receiver y bind_transceiver, los campos system_id/password/system_type, interface_version, estados de sesión y unbind.
- Operaciones
SMPP submit_sm: todos los campos obligatorios
Una referencia completa campo por campo de submit_sm: service_type, TON/NPI, esm_class, data_coding, registered_delivery, validity_period, short_message y el resto, con los valores que de verdad importan.
- Operaciones
SMPP deliver_sm: mensajes MO y confirmaciones de entrega
deliver_sm transporta dos cosas del SMSC al ESME: mensajes originados en móvil (MO) y confirmaciones de entrega. Cómo distinguirlos con esm_class y por qué siempre debes responder deliver_sm_resp.
- Errores
Códigos de error command_status de SMPP
El campo command_status de SMPP y el rango de errores ESME_R*: qué significan los códigos comunes (ESME_RINVPASWD, ESME_RTHROTTLED, ESME_RMSGQFUL…) y cómo reaccionar a cada uno.
- Formato de trama
Parámetros opcionales TLV de SMPP
Los parámetros opcionales de SMPP usan un formato Tag-Length-Value. La disposición en bytes del TLV más las etiquetas comunes: message_payload, receipted_message_id, message_state, user_message_reference y el conjunto sar_* de concatenación.
- Operaciones
Formato de las confirmaciones de entrega (DLR) de SMPP
El formato de texto de la confirmación de entrega del Apéndice B dentro de deliver_sm: id, sub, dlvrd, submit date, done date, stat, err y Text, más las palabras clave stat y sus números message_state.
- Sesión
SMPP enquire_link, ventana y limitación
Cómo SMPP mantiene viva una sesión con enquire_link, cómo la ventana limita las PDU pendientes sin confirmar y cómo ESME_RTHROTTLED y el TPS por bind rigen tu rendimiento real.
- Seguridad
Proteger SMPP: TLS, autenticación y listas de IP permitidas
SMPP no tiene cifrado nativo. Cómo proteger un bind en producción: SMPP sobre TLS, autenticación por credenciales e IP, listas de permitidos e higiene de credenciales.
- Fundamentos
SMPP v3.4 frente a v5.0: qué cambió
Las diferencias prácticas entre SMPP v3.4 y v5.0: control de congestión, operaciones de difusión, estados de mensaje adicionales y TLV, y por qué la v3.4 sigue siendo la interconexión por defecto.
- Integración
Buenas prácticas de integración de SMPP
Cómo construir una integración SMPP que siga siendo fiable en producción: estrategia de bind, disciplina de sequence_number, ventana, reintentos con espera, idempotencia, tratamiento de DLR y reconexión.
Codificación de SMS
Cómo se codifica el texto SMS en la red: GSM de 7 bits, UCS-2, esquemas de codificación de datos, segmentación y las implicaciones de coste de cada carácter.
- Juegos de caracteres
El juego de caracteres GSM-7
El alfabeto por defecto GSM de 7 bits completo de GSM 03.38: la tabla básica de 128 caracteres, la tabla de extensión basada en escape (| ^ € { } [ ] ~ \ y salto de página) y cómo funciona el empaquetado de 7 bits.
- Juegos de caracteres
UCS-2 y los SMS Unicode
Cómo transporta el SMS Unicode mediante UCS-2 (16 bits): el límite de 70 caracteres por mensaje individual, 67 por segmento concatenado, qué fuerza UCS-2 y la advertencia sobre pares suplentes para emojis.
- Codificación de datos
El esquema de codificación de datos (DCS)
El byte del esquema de codificación de datos que indica a la red cómo se codifica un SMS: GSM-7 (0x00), 8 bits (0x04), UCS-2 (0x08), además de las clases de mensaje (0/flash a 3/SIM) de GSM 03.38.
- Segmentación
Segmentación, concatenación y el UDH en SMS
Cómo se divide y reensambla un SMS largo: el User Data Header de 6 bytes, los 153 (GSM-7) y 67 (UCS-2) caracteres por segmento resultantes, el número de referencia y la secuenciación de segmentos.
- Coste
Detección de codificación y coste del SMS
Cómo detectar si un texto es GSM-7 o UCS-2, qué caracteres fuerzan UCS-2 de forma silenciosa y cómo la codificación determina el número de segmentos y, por tanto, el coste de cada SMS que envías.
SS7 / MAP
El sistema de señalización n.° 7 y la capa MAP transportan SMS terminados en dispositivos móviles, consultas HLR y gestión de movilidad a través de redes troncales heredadas.
- Fundamentos
Descripción de la pila SS7: MTP, SCCP, TCAP, MAP, ISUP
Cómo se estructura la pila SS7 —transporte MTP1-3, direccionamiento SCCP, transacciones TCAP y las partes de usuario MAP e ISUP— y qué hace cada capa para el SMS, las llamadas y la movilidad.
- Transporte
MTP: la Message Transfer Part (niveles 1-3)
Los tres niveles MTP que transportan SS7: enlaces físicos MTP1, enlace de datos con control de errores MTP2 (unidades MSU/LSSU/FISU) y enrutamiento por point code MTP3 con reparto de carga y gestión de red.
- Direccionamiento
SCCP, traducción de global title y subsystem numbers
Cómo SCCP amplía MTP3 con direccionamiento por global title: las Called/Calling Party Address, la Global Title Translation (GTT), los subsystem numbers (HLR/VLR/MSC) y las clases con y sin conexión.
- Transacciones
TCAP: transacciones, diálogos y componentes
Cómo TCAP estructura los intercambios de aplicación de SS7: la subcapa de transacción (Begin/Continue/End/Abort con transaction IDs), la porción de diálogo (application context) y la subcapa de componentes (Invoke, ReturnResult, ReturnError, Reject).
- MAP
Operaciones MAP: SRI-SM, ForwardSM, UpdateLocation y más
Las operaciones MAP que hacen funcionar las redes móviles: SendRoutingInfoForSM y MT-ForwardSM para SMS, UpdateLocation para itinerancia, ProvideSubscriberInfo y AnyTimeInterrogation para ubicación, con sus opcodes de TS 29.002.
- Entrega de SMS
Flujo de entrega de MT-SMS por SS7, paso a paso
El camino completo de un SMS terminado en móvil por SS7: SendRoutingInfoForSM del SMSC al HLR, el HLR devuelve IMSI + MSC de servicio, MT-ForwardSM del SMSC al MSC, paging y entrega, y el reintento por abonado ausente mediante MWD y AlertServiceCentre.
- Direccionamiento
Point codes y direccionamiento de red en SS7
Cómo direcciona SS7 los puntos de señalización: point codes ITU-T de 14 bits frente a ANSI de 24 bits, su estructura de zona/red, la etiqueta de enrutamiento OPC/DPC/SLS y cómo se relacionan los point codes con los global titles SCCP.
- Seguridad
Amenazas de seguridad de SS7 y las categorías de GSMA FS.11
Las principales clases de ataque SS7 —seguimiento de ubicación, interceptación de SMS/OTP, redirección de llamadas y fraude— y cómo GSMA FS.11 clasifica los mensajes MAP (categorías 1/2/3) para que los cortafuegos de señalización puedan filtrarlos.
- Fundamentos
SS7 frente a SIGTRAN: señalización TDM sobre IP
Cómo se relaciona SIGTRAN con el SS7 clásico: la misma capa de aplicación MTP3/SCCP/TCAP/MAP, pero transportada sobre IP con SCTP y M3UA (o SUA) en lugar de enlaces TDM MTP1/MTP2.
SIGTRAN
La señalización SS7 se transporta a través de IP (M3UA, SUA y SCTP, constituyendo el puente entre la señalización TDM y los núcleos de paquetes modernos.
- Fundamentos
Descripción de SIGTRAN: señalización SS7 sobre IP
Qué es SIGTRAN: el marco del IETF (RFC 2719) para transportar señalización SS7 sobre IP, usando transporte SCTP y capas de adaptación (M3UA, SUA, M2PA) que preservan la pila de aplicación MTP3/SCCP/TCAP/MAP.
- Transporte
SCTP: Stream Control Transmission Protocol
Cómo funciona SCTP y por qué SIGTRAN lo usa: entrega orientada a mensajes, multistreaming para evitar el bloqueo de cabecera de línea, multihoming para conmutación de trayecto, el formato de paquete basado en chunks y en qué difiere de TCP.
- Adaptación
M3UA: capa de adaptación de usuario de MTP3
Cómo M3UA transporta SCCP e ISUP sobre SCTP: los roles SG/ASP/AS, las routing keys y los routing contexts, las clases de mensaje (Transfer, SSNM, ASPSM, ASPTM) y los modos IPSP frente a pasarela de señalización.
- Adaptación
Capas de adaptación M2PA y SUA
Dos capas de adaptación más de SIGTRAN: M2PA (RFC 4165) reemplaza MTP2 para construir enlaces STP basados en IP que ejecutan un MTP3 completo, y SUA (RFC 3868) transporta usuarios de SCCP (TCAP/MAP) directamente sobre SCTP, evitando MTP3.
- Arquitectura
Arquitectura de despliegue de SIGTRAN: SG, ASP, AS
Cómo se construye una red SIGTRAN: la pasarela de señalización que puentea TDM e IP, los servidores de aplicación y sus procesos, las asociaciones SCTP y los modos de redundancia (override, load-share, broadcast) que dan disponibilidad de clase operador.
SIP / VoIP
El protocolo de inicio de sesión (SIP) que sustenta la voz programable, el enlace troncal SIP y el control de llamadas VoLTE, además de la pila de medios que lo acompaña.
- Fundamentos
Descripción general del protocolo SIP
Qué es SIP y cómo funciona: un protocolo de señalización de solicitud/respuesta basado en texto (RFC 3261) que establece, modifica y libera sesiones de medios, sus user agents, proxies y registrars, y sus transacciones y diálogos.
- Solicitudes
Métodos y solicitudes de SIP
Cada método de solicitud SIP y qué hace: los seis métodos básicos de RFC 3261 (INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS) y las extensiones comunes (INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE, PUBLISH).
- Respuestas
Códigos de respuesta de SIP (1xx-6xx)
Las seis clases de código de respuesta de SIP y las que importan: 1xx provisional (100 Trying, 180 Ringing), 2xx éxito (200 OK), 3xx redirección, 4xx error de cliente (404, 486), 5xx error de servidor y 6xx fallo global.
- Mensajes
Cabeceras de SIP: Via, From, To, Call-ID, CSeq, Contact
Las cabeceras SIP esenciales y qué hacen: Via (con el parámetro branch) para enrutar respuestas, From/To con etiquetas, Call-ID, CSeq, Contact, Max-Forwards y cómo se identifican diálogos y transacciones a partir de ellas.
- Medios
SDP: el Session Description Protocol
Cómo describe SDP una sesión de medios dentro de SIP: la estructura de líneas v=/o=/s=/c=/t=/m=/a=, el modelo offer/answer (RFC 3264), la negociación de códecs mediante rtpmap y los atributos de dirección de medios.
- Medios
RTP y SRTP: el flujo de medios
Cómo fluyen los medios una vez que SIP ha establecido una llamada: la cabecera y la carga de RTP, los informes de calidad RTCP, y el cifrado y la autenticación de SRTP con claves mediante SDES o DTLS-SRTP.
- Flujo de llamada
Flujo de llamada SIP: de INVITE a BYE
Una llamada SIP completa paso a paso: INVITE con oferta SDP, 100 Trying, 180 Ringing, 200 OK con respuesta SDP, el ACK en tres fases, medios RTP y el derribo BYE/200 OK, además de cómo CANCEL aborta una llamada que suena.
- Despliegue
SIP trunking y el session border controller
Qué es un SIP trunk y el papel del session border controller (SBC): traversal de NAT con STUN/TURN/ICE, ocultación de topología mediante B2BUA, seguridad y control de admisión en la frontera de red, y transcodificación.
DIAMETER
El protocolo AAA y de señalización detrás de la movilidad 4G/5G, la política y la tarificación (S6a, Gx, Gy), el control IMS (Cx / Sh) y la seguridad de roaming Diameter en el borde IPX.
- Fundamentos
Protocolo base DIAMETER: RFC 6733 explicado
Cómo funciona el protocolo base DIAMETER según RFC 6733: la cabecera de mensaje de 20 bytes, los command codes y las banderas R/P/E/T, el intercambio de capacidades CER/CEA, el watchdog DWR/DWA y el cierre DPR/DPA, sobre SCTP o TCP/TLS.
- Formato de mensaje
AVP, tipos de datos y Result-Code en DIAMETER
La anatomía de un AVP DIAMETER: código, banderas V/M/P, longitud, Vendor-Id opcional y datos; los tipos de datos base (Enumerated, Unsigned32, OctetString, Address, Time); los Grouped AVP; y el modelo de error Result-Code / Experimental-Result.
- Fundamentos
DIAMETER frente a RADIUS: por qué DIAMETER reemplazó a RADIUS
Por qué DIAMETER (RFC 6733) superó a RADIUS (RFC 2865) para el AAA de operador: transporte fiable SCTP y failover, negociación de capacidades, un espacio de AVP de 32 bits mucho mayor, descubrimiento de pares, manejo de errores más rico y seguridad más fuerte —con tabla comparativa y notas de migración.
- Movilidad (HSS)
DIAMETER S6a/S6d: movilidad LTE hacia el HSS
Cómo la movilidad LTE y la gestión de suscripción corren sobre DIAMETER S6a (MME↔HSS) y S6d (SGSN↔HSS) según 3GPP TS 29.272: ULR/ULA, AIR/AIA, CLR/CLA, PUR/PUA e IDR/IDA, los vectores de autenticación EPS-AKA, y las operaciones SS7 MAP que sustituyen.
- Política y tarificación
DIAMETER Gx y Gy: control de política y tarificación
Cómo DIAMETER transporta el control de política y tarificación: Gx (PCEF↔PCRF, CCR/CCA instalando reglas PCC), Gy (tarificación online al OCS con cuota) y Rf (tarificación offline al CDF) —más los roles PCRF/PCEF/OCS/OFCS, el QoS/QCI y las interfaces Sy/Sd.
- IMS
DIAMETER Cx/Dx y Sh: registro IMS y el HSS
Cómo el registro y la autenticación IMS corren sobre DIAMETER Cx/Dx (S-CSCF/I-CSCF↔HSS) según 3GPP TS 29.228/29.229 —UAR/UAA, MAR/MAA, SAR/SAA, LIR/LIA— más la interfaz Sh (AS↔HSS) y cómo se ligan al SIP REGISTER.
- Seguridad
Seguridad de roaming DIAMETER: DRA, DEA y la frontera IPX
Cómo funcionan el enrutamiento y la seguridad de interconexión DIAMETER en la frontera de roaming: el Diameter Routing Agent (DRA) y el Diameter Edge Agent (DEA), el enrutamiento por realm, las clases de amenaza de FS.19 (divulgación de información, rastreo de ubicación, fraude), la ocultación de topología y el filtrado de AVP.
Canales de mensajería
Los canales de mensajería de la capa de aplicación que utilizan las empresas son: RCS Business Messaging / MaaP, WhatsApp Business Cloud API, MMS (MM1 / MM4 / MM7), remitente verificado y de marca, y orquestación con respaldo de canal (fallback).
- RCS
RCS Business Messaging y la plataforma MaaP
Cómo funciona RCS Business Messaging: el GSMA Universal Profile (RCC.07), la arquitectura Messaging-as-a-Platform (RCC.71), los agentes verificados, el descubrimiento de capacidades, los flujos MO/MT y los eventos de facturación, y en qué se diferencia la API de agente RBM de un bind SMPP.
- WhatsApp
WhatsApp Business Platform: Cloud API y plantillas
Cómo funciona WhatsApp Business Platform: Cloud API frente a On-Premises API, mensajes de plantilla (HSM) frente a mensajes de sesión, la ventana de atención al cliente de 24 horas, las categorías marketing/utility/authentication, los webhooks, los niveles de calidad del número de teléfono y el opt-in.
- MMS
Arquitectura de MMS: las interfaces MM1, MM4 y MM7
Cómo funciona MMS según 3GPP TS 23.140 y OMA MMS: el MMSC/relay-server, MM1 (handset↔MMSC sobre WAP/HTTP), MM4 (MMSC↔MMSC sobre SMTP para inter-operador), MM7 (VASP↔MMSC sobre SOAP/XML), contenido MIME/SMIL, límites de tamaño y MMS A2P.
- Confianza y marca
Mensajería de remitente verificado y con marca
Cómo demuestran las marcas quiénes son en todos los canales: RCS Verified Sender y agentes de empresa verificados, registro de sender-ID de la GSMA y verificación de marca, y certificados VMC con BIMI para logotipos verificados en el correo: los controles que combaten la suplantación.
- Matriz de decisión
RCS frente a SMS frente a WhatsApp: una matriz de decisión de canal
Una comparación neutral entre RCS, SMS y WhatsApp para la mensajería de empresa: funciones, alcance y cobertura, cifrado de extremo a extremo, confirmaciones de lectura e indicador de escritura, contenido multimedia enriquecido, modelos de coste, comportamiento de fallback y restricciones regulatorias, con orientación sobre cuándo usar cada uno.
- Orquestación
Conmutación de canales y orquestación omnicanal
Cómo la entrega omnicanal hace cascada entre canales: comprobaciones de capacidad, fallback RCS→SMS y WhatsApp→SMS, encaminamiento de mínimo coste frente a mejor experiencia, reglas de reintento y timeout, y una vista de confirmaciones de entrega unificada que concilia el estado en todos los canales.
- Interactivo
Tarjetas enriquecidas y mensajería interactiva
Los componentes interactivos de RCS y WhatsApp: tarjetas enriquecidas y carruseles, respuestas y acciones sugeridas, botones de respuesta rápida y selectores de lista, con cargas útiles JSON de ejemplo para cada plataforma, más orientación de UX y accesibilidad.
Numeración e identidad
La capa de numeración e identidad subyacente a cada mensaje y llamada: códigos E.164 / MSISDN, MCC-MNC / PLMN, identidad del suscriptor IMSI / IMEI, ENUM (E.164 → URI) y enrutamiento de portabilidad numérica móvil.
- Numeración pública
La numeración E.164 y el MSISDN explicados
Cómo funciona el plan de numeración internacional E.164 de la ITU-T: códigos de país, código de destino nacional (NDC) y número de abonado, el máximo de 15 dígitos, la estructura del MSISDN y cómo normalizar números a E.164 para mensajería A2P.
- Identidad de red
Códigos MCC, MNC y PLMN explicados (E.212)
Cómo funciona el plan de identificación E.212 de la ITU-T: el Mobile Country Code (MCC) de 3 dígitos y el Mobile Network Code (MNC) de 2-3 dígitos que se combinan en una identidad PLMN, cómo identifican la red de origen, los rangos de prueba y en qué se diferencia el MCC-MNC del NDC del MSISDN.
- Identidad del abonado
IMSI, IMEI e identidad del abonado explicados
Las identidades que distinguen a un abonado de un dispositivo: el IMSI (MCC+MNC+MSIN, E.212), el IMEI (TAC+serie), la clave de autenticación Ki, las identidades temporales TMSI/GUTI, la SIM/USIM/eSIM (eUICC) y cómo el HLR asocia el MSISDN al IMSI.
- Enrutamiento de números
ENUM: asignación de números E.164 a URIs
Cómo ENUM (IETF RFC 6116) asigna números de teléfono E.164 a URIs mediante DNS: el dominio e164.arpa de dígitos invertidos, los registros NAPTR con reescritura por regexp, y la diferencia entre ENUM público (de usuario) y privado (de operador/infraestructura) para enrutamiento SIP y VoIP.
- Enrutamiento de números
Portabilidad numérica móvil y enrutamiento
Cómo la portabilidad numérica móvil (MNP) rompe el vínculo entre un número marcado y su red de origen: números de enrutamiento (RN), All-Call-Query frente a Onward Routing, bases de datos y dips MNP, y cómo la consulta HLR/MNP impulsa el enrutamiento de coste mínimo y una entrega fiable.
API HTTP y webhooks
La capa HTTP/ REST sobre los protocolos de red: diseño de API de mensajería REST, entrega de webhooks y verificación de firma HMAC, estado/cargas útiles entrantes, autenticación y firma, idempotencia, limitación de velocidad y errores problem+json — basado en estándares (RFC 9457, borradores de IETF).
- Diseño de API
Diseño de una API de mensajería REST: recursos, métodos, códigos de estado
Cómo se modela una API de mensajería REST basada en estándares: una colección de mensajes, métodos HTTP y semántica de códigos de estado según RFC 9110, envío síncrono frente a asíncrono (202 Accepted más un callback de estado), negociación de contenido y versionado por URL o por header, con una tabla comparativa REST frente a SMPP.
- Webhooks
Entrega y fiabilidad de webhooks: reintentos, orden, dead-letter
La arquitectura estándar de webhook/callback y su modelo de fiabilidad: entrega al menos una vez, backoff exponencial con jitter en los reintentos, timeouts de entrega, garantías de orden, colas dead-letter, consumidores idempotentes y salud del endpoint / circuit-breaking para proteger a un receptor que falla.
- Seguridad
Verificación de firma de webhooks: HMAC-SHA256 y protección contra repetición
Cómo verificar que un webhook es auténtico y no ha sido manipulado: HMAC-SHA256 sobre el cuerpo en bruto, los headers de firma y timestamp, protección contra repetición con una ventana de tolerancia de timestamp y un nonce, comparación en tiempo constante para frustrar ataques de temporización, y rotación segura de secretos con claves solapadas.
- Webhooks
Estado de mensaje (DLR) y payloads de webhooks entrantes (MO)
Los esquemas de payload de los dos callbacks de mensajería centrales: el evento de estado de entrega (DLR) con su id de mensaje, enum de estado, motivo de error y marcas de tiempo, y el evento de mensaje entrante (MO), más una taxonomía de tipos de evento y cómo un DLR HTTP se corresponde con un acuse deliver_sm de SMPP.
- Seguridad
Autenticación de API y firma de peticiones: tokens, HMAC, OAuth, mTLS
Las formas estándar de autenticar una API de mensajería HTTP: bearer tokens y claves de API en el header Authorization, firma de peticiones HMAC sobre una petición canónica, alcance y rotación de claves, TLS mutuo y OAuth 2.0 client-credentials para el acceso máquina a máquina.
- Fiabilidad
Idempotencia y limitación de tasa: claves, 429, Retry-After, RateLimit
Dos patrones HTTP en vía de estandarización para clientes seguros y bien educados: el header Idempotency-Key (borrador IETF) para un envío exactamente una vez con ventana de deduplicación y repetición de respuesta, y la limitación de tasa —429 con Retry-After, los headers RateLimit / RateLimit-Policy (borrador IETF), token buckets y contrapresión del cliente.
- Diseño de API
Errores de API (problem+json) y paginación (cursor, header Link)
Dos estándares que mantienen predecible una API HTTP: RFC 9457 problem+json para errores legibles por máquina (type, title, status, detail, instance) con una taxonomía de reintentable frente a terminal, y la paginación —cursor frente a offset, el header Link de RFC 8288 para next/prev, y límites de tamaño de página.
Desde la especificación hasta el cable.
Estas referencias describen los protocolos que BroadNet ha utilizado a nivel de operador desde 2003, en 200+ países y 1000+ conexiones de operadores. Cuando esté listo para enviar, la documentación y las herramientas que encontrará a continuación le guiarán desde la lectura hasta el envío.