Aller au contenu principal

OmniMessage IMS Frontend

Couche de transport SIP pour OmniMessage - gère l'envoi et la réception de messages dans les réseaux IMS

Ce Qu'il Fait

Ceci est un frontend SIP léger qui agit comme une couche de transport entre les réseaux IMS et le backend OmniMessage. Tout le traitement des messages, la logique de routage et la logique métier sont gérés par OmniMessage - ce frontend simplement :

  • Reçoit les messages SIP REGISTER et transmet les données des abonnés à OmniMessage
  • Reçoit les SMS d'origine mobile (MO) via SIP MESSAGE et les transmet à OmniMessage
  • Récupère les SMS terminés mobiles (MT) d'OmniMessage et les envoie via SIP MESSAGE
  • Signale le statut de livraison à OmniMessage
  • Gère les détails du protocole au niveau SIP (en-têtes, accusés de réception, etc.)

Architecture

Le frontend IMS se compose de deux composants principaux :

Gestion du protocole SIP :

  • SIP REGISTER - Extrait les données des abonnés et les transmet à OmniMessage
  • SIP MESSAGE - Reçoit les SMS MO et les transmet à OmniMessage
  • SIP MESSAGE - Envoie les SMS MT d'OmniMessage aux abonnés
  • SIP NOTIFY - Gère les notifications d'événements
  • Réponses UAC - Capture les confirmations de livraison et les transmet à OmniMessage

Couche de transport du backend OmniMessage :

  • insert_location() - Envoie les données d'enregistrement des abonnés à OmniMessage
  • insert_message() - Envoie les messages MO entrants à OmniMessage
  • get_queue() - Récupère les messages MT en attente d'OmniMessage
  • process_message() - Envoie des mises à jour de statut de livraison à OmniMessage
  • frontend_register() - Enregistre ce frontend auprès d'OmniMessage

Tout le traitement des messages, les décisions de routage, la mise en file d'attente, le stockage et la logique métier se déroulent dans OmniMessage. Ce frontend est purement un adaptateur de transport SIP.

Configuration

Toute la configuration est stockée dans le fichier config.yaml.

Paramètres de Configuration​

api_base_url - URL de base pour l'API backend OmniMessage

  • Format : https://hostname:port
  • Exemple : https://10.5.198.200:8443
  • Utilisé pour tous les appels API backend (insert_location, insert_message, get_queue, etc.)

location - Identifiant pour cette instance de frontend IMS

  • Format : Identifiant de style FQDN
  • Exemple : smsc01.mnc001.mcc001.3gppnetwork.org
  • Utilisé pour identifier ce frontend dans le système backend
  • Doit être unique parmi tous les frontends

s_cscf_sip_uri - URI SIP S-CSCF pour le routage des messages (optionnel)

  • Format : sip:hostname:port
  • Exemple : sip:127.0.0.2:5060
  • Si défini, tous les SIP MESSAGE sortants passent par ce S-CSCF
  • Si non défini, les messages sont routés directement vers le domaine IMS

ims_domain - Domaine IMS pour le routage des abonnés

  • Format : Nom de domaine IMS
  • Exemple : ims.mnc001.mcc001.3gppnetwork.org
  • Utilisé pour construire des URI SIP pour l'adressage des abonnés
  • Utilisé lorsque s_cscf_sip_uri n'est pas configuré

Flux de Messages

Flux SIP REGISTER​

Flux SMS d'Origine Mobile (MO)​

Flux SMS Terminés Mobiles (MT)​

Polling et Cooldown de Flush

Le frontend utilise deux mécanismes pour vérifier les messages MT à livrer :

  1. Polling périodique (rtimer) - Le module rtimer de Kamailio déclenche Database_flush() à un intervalle fixe (configuré dans kamailio.cfg). L'intervalle par défaut est de 2 secondes.

  2. Flushing basé sur les événements - Lorsqu'une réponse UAC est reçue qui ne correspond pas à un SMS MT suivi (par exemple, une réponse ACK MO-SMS), Database_flush() est également appelé immédiatement.

Pour éviter que ces deux mécanismes ne se chevauchent et ne fassent des appels API redondants, un cooldown de flush est mis en œuvre en utilisant un fichier de timestamp partagé (/tmp/smsc_ims_last_flush). Chaque appel à Database_flush() écrit le timestamp actuel dans ce fichier. Avant que le rtimer ne se déclenche, il vérifie le temps de modification du fichier - si un flush a eu lieu dans les FLUSH_COOLDOWN secondes précédentes (par défaut : 1 seconde), le polling rtimer est ignoré.

Cette approche de fichier partagé est nécessaire car Kamailio génère plusieurs processus de travail, chacun avec son propre interpréteur Python. Les variables d'instance ne sont pas partagées entre les processus, donc le fichier agit comme un état partagé entre processus.

L'intervalle du rtimer est configuré dans kamailio.cfg :

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