Pular para o conteúdo principal

OmniMessage IMS Frontend

Camada de transporte SIP para OmniMessage - lida com a entrada e saída de mensagens em redes IMS

O Que Faz

Este é um frontend SIP leve que atua como uma camada de transporte entre redes IMS e o backend OmniMessage. Todo o processamento de mensagens, lógica de roteamento e lógica de negócios é tratado pelo OmniMessage - este frontend simplesmente:

  • Recebe mensagens SIP REGISTER e encaminha dados de assinantes para o OmniMessage
  • Recebe SMS de Origem Móvel (MO) via SIP MESSAGE e encaminha para o OmniMessage
  • Recupera SMS de Terminação Móvel (MT) do OmniMessage e envia via SIP MESSAGE
  • Relata o status de entrega de volta ao OmniMessage
  • Lida com detalhes do protocolo SIP (cabeçalhos, confirmações, etc.)

Arquitetura

O frontend IMS consiste em dois componentes principais:

Manipulação do protocolo SIP:

  • SIP REGISTER - Extrai dados do assinante e encaminha para o OmniMessage
  • SIP MESSAGE - Recebe SMS MO e encaminha para o OmniMessage
  • SIP MESSAGE - Envia SMS MT do OmniMessage para os assinantes
  • SIP NOTIFY - Lida com notificações de eventos
  • Respostas UAC - Captura confirmações de entrega e encaminha para o OmniMessage

Camada de transporte do backend OmniMessage:

  • insert_location() - Envia dados de registro do assinante para o OmniMessage
  • insert_message() - Envia mensagens MO recebidas para o OmniMessage
  • get_queue() - Recupera mensagens MT pendentes do OmniMessage
  • process_message() - Envia atualizações de status de entrega para o OmniMessage
  • frontend_register() - Registra este frontend com o OmniMessage

Todo o processamento de mensagens, decisões de roteamento, enfileiramento, armazenamento e lógica de negócios acontece no OmniMessage. Este frontend é puramente um adaptador de transporte SIP.

Configuração

Toda a configuração é armazenada no arquivo config.yaml.

Parâmetros de Configuração​

api_base_url - URL base para a API do backend OmniMessage

  • Formato: https://hostname:port
  • Exemplo: https://10.5.198.200:8443
  • Usado para todas as chamadas da API do backend (insert_location, insert_message, get_queue, etc.)

location - Identificador para esta instância do frontend IMS

  • Formato: identificador no estilo FQDN
  • Exemplo: smsc01.mnc001.mcc001.3gppnetwork.org
  • Usado para identificar este frontend no sistema backend
  • Deve ser único entre todos os frontends

s_cscf_sip_uri - URI SIP S-CSCF para roteamento de mensagens (opcional)

  • Formato: sip:hostname:port
  • Exemplo: sip:127.0.0.2:5060
  • Se definido, todas as mensagens SIP MESSAGE de saída são roteadas através deste S-CSCF
  • Se não definido, as mensagens são roteadas diretamente para o domínio IMS

ims_domain - domínio IMS para roteamento de assinantes

  • Formato: nome do domínio IMS
  • Exemplo: ims.mnc001.mcc001.3gppnetwork.org
  • Usado para construir URIs SIP para endereçamento de assinantes
  • Usado quando s_cscf_sip_uri não está configurado

Fluxo de Mensagens

Fluxo SIP REGISTER​

Fluxo de SMS de Origem Móvel (MO)​

Fluxo de SMS de Terminação Móvel (MT)​

Polling e Cooldown de Flush

O frontend utiliza dois mecanismos para verificar mensagens MT a serem entregues:

  1. Polling periódico (rtimer) - O módulo rtimer do Kamailio aciona Database_flush() em um intervalo fixo (configurado em kamailio.cfg). O intervalo padrão é de 2 segundos.

  2. Flush acionado por eventos - Quando uma resposta UAC é recebida que não corresponde a um SMS MT rastreado (por exemplo, uma resposta de ACK de MO-SMS), Database_flush() também é chamado imediatamente.

Para evitar que esses dois mecanismos se sobreponham e façam chamadas de API redundantes, um cooldown de flush é implementado usando um arquivo de timestamp compartilhado (/tmp/smsc_ims_last_flush). Cada chamada para Database_flush() grava o timestamp atual neste arquivo. Antes que o rtimer dispare, ele verifica o tempo de modificação do arquivo - se um flush ocorreu nos últimos FLUSH_COOLDOWN segundos (padrão: 1 segundo), o polling do rtimer é pulado.

Essa abordagem de arquivo compartilhado é necessária porque o Kamailio gera vários processos de trabalho, cada um com seu próprio interpretador Python. Variáveis de instância não são compartilhadas entre processos, então o arquivo atua como um estado compartilhado entre processos.

O intervalo do rtimer é configurado em kamailio.cfg:

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