SMSC, pasarela SMS y servidor SMPP: qué hace realmente cada uno

Pregunte a tres proveedores qué venden y puede que oiga “un SMSC”, “una pasarela SMS” y “un servidor SMPP” para lo que parece el mismo producto. Las palabras no son intercambiables, y la confusión cuesta dinero: hay quien compra un servidor SMPP creyendo que llegará a los terminales, o presupuesta “un SMSC” cuando lo que necesita es una pasarela y dos contratos con operadores. Esta guía resuelve la cuestión de SMSC frente a pasarela SMS frente a servidor SMPP con definiciones claras, muestra cómo se conectan los tres en el recorrido real de un mensaje y termina con cuáles de ellos tiene que operar de verdad.

SMSC, pasarela SMS y servidor SMPP en un párrafo

Un SMSC vive dentro de la red de un operador móvil y entrega mensajes de texto a los teléfonos. Una pasarela SMS vive fuera de la red, recibe mensajes de aplicaciones y clientes, los enruta hacia la conexión de operador adecuada y recoge los acuses de entrega. Un servidor SMPP es un componente de una pasarela que permite a otros sistemas conectarse a ella mediante el protocolo SMPP, del mismo modo que la pasarela se conecta a los operadores. Los operadores gestionan los SMSC. Las empresas que envían o revenden mensajes gestionan pasarelas. Las pasarelas que atienden a clientes técnicos gestionan también servidores SMPP.

Todo lo que sigue es ese párrafo con los detalles completados.

SMSC: la máquina de almacenamiento y reenvío del operador

El centro de servicio de mensajes cortos (Short Message Service Centre) es la pieza de la red móvil responsable del SMS. Cuando un teléfono envía un texto, este va al SMSC del operador del remitente; el SMSC lo almacena, averigua dónde está el teléfono del destinatario y lo reenvía, con reintentos si el teléfono está apagado o fuera de cobertura. Ese comportamiento de “almacenar y reenviar” es la razón por la que un texto llega cuando usted vuelve a encender el teléfono, y quien lo hace es el SMSC.

De ahí se derivan tres cosas. El SMSC se comunica con los terminales a través del núcleo de señalización de la red (SS7, o Diameter en los núcleos más recientes), lo cual es una relación de telecomunicaciones, no un protocolo de internet. El SMSC pertenece al operador, y cada operador tiene el suyo; no existe un SMSC global. Y el SMSC es lo único en este artículo que puede poner un mensaje en un teléfono. Todo lo demás es una forma de hacer llegar un mensaje a un SMSC.

Las empresas llegan a un SMSC de una de dos maneras: a través de un agregador que ya tiene conexiones con muchos operadores, o directamente, con un contrato y un bind SMPP que proporciona el operador. En ambos casos la empresa es cliente del SMSC, no su operador. Los productos que se comercializan como “un SMSC para empresas” son pasarelas que aceptan binds SMPP; por sí solos no entregan a los terminales.

Pasarela SMS: el enrutador, el libro mayor y el panel

Una pasarela SMS es el sistema que gestiona una empresa para enviar mensajes a escala y, si revende, para que sus propios clientes envíen. El trabajo de la pasarela es todo lo que ocurre entre “se ha recibido un mensaje” y “aquí está el acuse”:

• Aceptar mensajes desde una consola web, una API HTTP, la carga de un archivo o un bind SMPP.
• Validarlos: reglas de identidad de remitente (sender ID), codificación, longitud, el saldo del cliente.
• Enrutar: elegir qué conexión de operador o qué agregador lleva este mensaje a este destino, según precio, calidad o contrato.
• Entregar por la conexión elegida, normalmente SMPP hacia un operador o agregador, a veces HTTP hacia un proveedor, respetando la tasa y la ventana de la conexión.
• Recoger los acuses y emparejarlos con los mensajes, para que “entregado”, “fallido” o “caducado” llegue al cliente y al libro mayor.
• Facturar: cobrar al cliente por mensaje, registrar el coste de la ruta y mostrar el margen.
• Generar informes para el cliente y para quien opera la pasarela.

La pasarela puede ser un único motor (Kannel es el de código abierto más conocido; gestiona binds, colas y acuses y nada por encima de eso) o una plataforma completa en la que el motor es una capa situada bajo un portal, una tabla de enrutamiento, tres modelos de facturación y una pila de informes. La página de la plataforma dibuja esa pila completa de Smppcube en un solo diagrama: NGINX, la consola PHP y la cadena de procesamiento en Node.js, las colas en Redis, MySQL como sistema de registro, MongoDB para el archivo histórico, Elasticsearch para las búsquedas y Kannel por debajo, comunicándose con los SMSC. Todo ello junto es “la pasarela SMS”. Kannel por sí solo es el motor de entrega.

Una pasarela también soporta las partes del negocio que no tienen nada que ver con los protocolos: cuentas de cliente, tarifarios por destino, saldos prepago y pospago, facturas, portales de revendedor y el margen por ruta que decide si la operación gana dinero. Esas partes son la razón por la que comprar una pasarela es una decisión distinta de descargar un motor.

Servidor SMPP: la puerta a la que se enlazan sus clientes

SMPP, el protocolo en el que se han estandarizado los operadores, es un protocolo cliente-servidor. Cuando su pasarela se enlaza con un operador, el lado del operador es el servidor SMPP y el suyo es el cliente. Cuando sus propios clientes quieren enlazarse con usted por SMPP, usted tiene que ser el servidor. Ese componente es el servidor SMPP: escucha en un puerto (el 2775 por convención), autentica los binds con un system_id y una contraseña, acepta paquetes submit_sm, devuelve identificadores de mensaje, aplica el límite de rendimiento de cada cuenta y envía los acuses de entrega de vuelta por la sesión.

Es, en otras palabras, una vía más de entrada a la pasarela. Los mensajes que llegan por el servidor SMPP van a la misma cola, la misma tabla de enrutamiento y el mismo libro mayor que los mensajes de la API HTTP y de la consola; la guía de SMPP frente a HTTP explica por qué una plataforma necesita ambos y en qué se diferencian en la práctica. Un servidor SMPP, en cambio, no es una ruta hacia los terminales: es una puerta de entrada, no de salida. Una empresa que solo necesita enviar nunca necesita uno. Una empresa que quiere tener como clientes a bancos, proveedores de OTP y otros agregadores lo necesita el día en que el primero de ellos lo pida.

Cómo se conectan los tres en el recorrido real de un mensaje

Si junta los tres, un mensaje que va del cliente de un revendedor hasta un teléfono sigue este camino:

1. El cliente envía el mensaje a la pasarela del revendedor, a través de la consola web, la API HTTP o un bind con el servidor SMPP del revendedor.
2. La pasarela lo valida, descuenta el saldo del cliente y elige una ruta para el destino.
3. El motor de la pasarela lo envía por un bind SMPP (o una llamada HTTP) a un agregador o directamente al operador de destino.
4. El SMSC del operador almacena el mensaje, localiza el teléfono y lo entrega.
5. El SMSC devuelve un acuse de entrega por la misma cadena; la pasarela lo empareja con el mensaje, liquida el libro mayor y lo reenvía al cliente (como un deliver_sm en su bind SMPP o como un webhook en su API).

Dos observaciones. Primera: el servidor SMPP del revendedor y el SMSC del operador nunca hablan entre sí; la pasarela que hay en medio habla SMPP como cliente aguas arriba y como servidor aguas abajo, y por eso las palabras se confunden. Segunda: la misma pasarela puede ser cliente de varios SMSC y agregadores a la vez, y esa es toda la base del enrutamiento: el mensaje toma la conexión más barata, la mejor o la contratada para ese destino.

Quién opera cada uno

	SMSC	Pasarela SMS	Servidor SMPP
Dónde vive	Dentro del núcleo de red de un operador móvil	En un servidor que controla la empresa (o alquilada como SaaS)	Dentro de la pasarela, como una de sus vías de entrada
Quién lo opera	Operadores móviles	Empresas, revendedores, agregadores, plataformas CPaaS	Pasarelas que atienden a clientes técnicos
Se comunica con	Terminales (vía SS7/Diameter) y pasarelas conectadas	SMSC, agregadores y proveedores HTTP aguas arriba; clientes aguas abajo	Clientes que se enlazan por SMPP
Llega a un teléfono por sí solo	Sí	Solo a través de un SMSC	No
Ejemplos	Los sistemas propios de los operadores	Kannel (motor); plataformas completas como Smppcube	Integrado en una plataforma, o añadido sobre un motor

La nota “alquilada como SaaS” de la columna de la pasarela señala la otra confusión habitual: un panel SMS alojado también es una pasarela, una que gestiona otra persona y a la que usted accede como inquilino. La guía de la pasarela autoalojada es la comparación honesta entre operar una usted mismo y alquilar un puesto en una.

Cuáles de ellos necesita operar

Si envía mensajes desde una sola aplicación (OTP, alertas, notificaciones) y no tiene clientes propios, no necesita ninguno de ellos. Una API HTTP de un agregador es una pasarela de la que usted es cliente; su única decisión es qué proveedor elegir.

Si revende mensajería, gestiona campañas para terceros u opera la mensajería de muchos equipos internos, necesita una pasarela. Alquilada o autoalojada es la siguiente pregunta, y depende de los datos, del margen y de la dependencia del proveedor más que de la tecnología; una licencia de pago único como la de Smppcube en su propio servidor es el extremo autoalojado de esa elección.

Si entre sus clientes hay alguien con una biblioteca cliente SMPP (bancos, proveedores de OTP, plataformas de marketing, otros agregadores), su pasarela necesita un servidor SMPP. Algunas plataformas lo incluyen; con un motor básico, lo añade usted mismo.

Usted no necesita un SMSC. No puede operar uno sin ser un operador, y tampoco le hace falta: el SMSC de cualquier operador es accesible mediante un bind o a través de un agregador. La versión práctica de “necesitamos un SMSC” es casi siempre “necesitamos una pasarela con un servidor SMPP y dos o tres contratos con operadores”, que es un problema mucho más pequeño y mucho más barato.

Nadie fuera de un operador gestiona un SMSC. Lo que gestionan las empresas es una pasarela, y a lo que se enlazan los clientes técnicos es al servidor SMPP de esa pasarela. Ponga orden en el vocabulario y la lista de la compra se ordena sola.

Una nota sobre los nombres que usan los fabricantes

Como los términos se solapan en el marketing, lea la lista de funciones y no la etiqueta. Un producto llamado “software SMSC” que enumera binds SMPP, enrutamiento y facturación es una pasarela. Un “servidor SMPP” que enumera cuentas de cliente, tarifarios y un portal es una pasarela con un punto de entrada SMPP. Una “pasarela SMS” que no es más que un endpoint REST sin tabla de enrutamiento es la API de un único proveedor. Ninguno de ellos es una mala compra; lo importante es saber qué hace antes de comparar precios y comprobar, sea cual sea su elección, que se ejecuta en un servidor al que usted puede acceder y que conserva registros que usted puede exportar.