Saltar al contenido principal

OmniMessage IMS Frontend

Capa de transporte SIP para OmniMessage - maneja el envío y recepción de mensajes en redes IMS

Qué Hace

Este es un frontend SIP ligero que actúa como una capa de transporte entre redes IMS y el backend de OmniMessage. Todo el procesamiento de mensajes, la lógica de enrutamiento y la lógica de negocio son manejados por OmniMessage - este frontend simplemente:

  • Recibe mensajes SIP REGISTER y reenvía datos de suscriptores a OmniMessage
  • Recibe SMS de origen móvil (MO) a través de SIP MESSAGE y reenvía a OmniMessage
  • Recupera SMS terminados en móvil (MT) de OmniMessage y envía a través de SIP MESSAGE
  • Informa el estado de entrega de vuelta a OmniMessage
  • Maneja detalles del protocolo a nivel SIP (encabezados, acuses de recibo, etc.)

Arquitectura

El frontend IMS consta de dos componentes principales:

Manejo del protocolo SIP:

  • SIP REGISTER - Extrae datos de suscriptor y reenvía a OmniMessage
  • SIP MESSAGE - Recibe SMS MO y reenvía a OmniMessage
  • SIP MESSAGE - Envía SMS MT desde OmniMessage a suscriptores
  • SIP NOTIFY - Maneja notificaciones de eventos
  • Respuestas UAC - Captura confirmaciones de entrega y reenvía a OmniMessage

Capa de transporte del backend de OmniMessage:

  • insert_location() - Envía datos de registro de suscriptor a OmniMessage
  • insert_message() - Envía mensajes MO entrantes a OmniMessage
  • get_queue() - Recupera mensajes MT pendientes de OmniMessage
  • process_message() - Envía actualizaciones de estado de entrega a OmniMessage
  • frontend_register() - Registra este frontend con OmniMessage

Todo el procesamiento de mensajes, decisiones de enrutamiento, encolado, almacenamiento y lógica de negocio ocurre en OmniMessage. Este frontend es puramente un adaptador de transporte SIP.

Configuración

Toda la configuración se almacena en el archivo config.yaml.

Parámetros de Configuración​

api_base_url - URL base para la API del backend de OmniMessage

  • Formato: https://hostname:port
  • Ejemplo: https://10.5.198.200:8443
  • Usado para todas las llamadas a la API del backend (insert_location, insert_message, get_queue, etc.)

location - Identificador para esta instancia de frontend IMS

  • Formato: identificador estilo FQDN
  • Ejemplo: smsc01.mnc001.mcc001.3gppnetwork.org
  • Usado para identificar este frontend en el sistema backend
  • Debe ser único entre todos los frontends

s_cscf_sip_uri - URI SIP S-CSCF para enrutamiento de mensajes (opcional)

  • Formato: sip:hostname:port
  • Ejemplo: sip:127.0.0.2:5060
  • Si está configurado, todos los SIP MESSAGE salientes se enrutan a través de este S-CSCF
  • Si no está configurado, los mensajes se enrutan directamente al dominio IMS

ims_domain - Dominio IMS para enrutamiento de suscriptores

  • Formato: nombre de dominio IMS
  • Ejemplo: ims.mnc001.mcc001.3gppnetwork.org
  • Usado para construir URIs SIP para la dirección de suscriptores
  • Usado cuando s_cscf_sip_uri no está configurado

Flujo de Mensajes

Flujo SIP REGISTER​

Flujo de SMS de Origen Móvil (MO)​

Flujo de SMS Terminados en Móvil (MT)​

Polling y Tiempo de Enfriamiento de Flush

El frontend utiliza dos mecanismos para verificar mensajes MT para entregar:

  1. Polling periódico (rtimer) - El módulo rtimer de Kamailio activa Database_flush() a intervalos fijos (configurado en kamailio.cfg). El intervalo predeterminado es de 2 segundos.

  2. Flushing basado en eventos - Cuando se recibe una respuesta UAC que no coincide con un SMS MT rastreado (por ejemplo, una respuesta ACK de SMS MO), Database_flush() también se llama de inmediato.

Para evitar que estos dos mecanismos se superpongan y realicen llamadas a la API redundantes, se implementa un tiempo de enfriamiento de flush utilizando un archivo de marca de tiempo compartido (/tmp/smsc_ims_last_flush). Cada llamada a Database_flush() escribe la marca de tiempo actual en este archivo. Antes de que se active el rtimer, verifica el tiempo de modificación del archivo: si se realizó un flush dentro de los últimos FLUSH_COOLDOWN segundos (predeterminado: 1 segundo), se omite el polling del rtimer.

Este enfoque de archivo compartido es necesario porque Kamailio genera múltiples procesos de trabajo, cada uno con su propio intérprete de Python. Las variables de instancia no se comparten entre procesos, por lo que el archivo actúa como estado compartido entre procesos.

El intervalo del rtimer se configura en kamailio.cfg:

modparam("rtimer", "timer", "name=ta;interval=2;mode=1;")