Guide de Configuration M3UA STP

← Retour à la Documentation Principale

Ce guide fournit une configuration détaillée pour utiliser OmniSS7 comme un Point de Transfert de Signalisation (STP).

Table des Matières

Qu'est-ce qu'un STP ?
Rôles Réseau STP
Activation du Mode STP
Configuration des Pairs
Support du Protocole M2PA
Routage par Code de Point
Routage par Titre Global
Fonctionnalités de Gestion des Routes
- Désactivation des Routes
- Routes DROP - Prévention des Boucles de Routage
Routage Avancé
Tester la Configuration
Métriques et Surveillance
Surveillance des Pairs M3UA

Qu'est-ce qu'un Point de Transfert de Signalisation (STP) ?

Un Point de Transfert de Signalisation (STP) est un élément réseau critique dans les réseaux de signalisation SS7 et basés sur IP qui achemine les messages de signalisation entre les nœuds du réseau.

Aperçu du Routage

Fonctions du STP

Routage de Messages : Achemine le trafic de signalisation SS7 en fonction du Code de Point de Destination (PC) ou du Titre Global (GT)
Traduction de Protocole : Relie les réseaux SS7 traditionnels aux réseaux M3UA/SCTP basés sur IP
Distribution de Charge : Distribue le trafic entre plusieurs destinations en utilisant un routage basé sur la priorité
Passerelle Réseau : Connecte différents réseaux de signalisation et fournisseurs de services
Masquage de Topologie : Peut réécrire des adresses pour masquer la topologie interne du réseau

Diagramme Réseau STP

Rôles Réseau STP Expliqués

ASP (Processus Serveur d'Application)

Rôle : Client se connectant à un SGP/STP distant
Direction : Connexion sortante
Cas d'Utilisation : Votre STP se connecte au STP d'un réseau partenaire

SGP (Processus Passerelle de Signalisation)

Rôle : Serveur acceptant les connexions des ASP
Direction : Connexion entrante
Cas d'Utilisation : Les réseaux partenaires se connectent à votre STP

AS (Serveur d'Application)

Définition : Regroupement logique d'un ou plusieurs ASP
But : Fournit redondance et partage de charge
Cas d'Utilisation : Plusieurs ASP servant la même destination

Activation du Mode M3UA STP

OmniSS7 peut fonctionner en différents modes. Pour l'utiliser comme un STP, vous devez activer le mode STP dans la configuration.

Changement en Mode STP

Le fichier config/runtime.exs d'OmniSS7 contient trois modes opérationnels préconfigurés. Pour activer le mode STP :

Ouvrir config/runtime.exs
Trouver les trois sections de configuration (lignes 53-174) :
- Configuration 1 : Mode STP (lignes 53-85)
- Configuration 2 : Mode HLR (lignes 87-123)
- Configuration 3 : Mode SMSc (lignes 125-174)
Commenter la configuration actuellement active (ajouter # à chaque ligne)
Décommenter la configuration STP (retirer # des lignes 53-85)
Personnaliser les paramètres de configuration selon les besoins
Redémarrer l'application : iex -S mix

Vérification de l'État du Pair M3UA

Configuration du Mode STP

La configuration STP complète ressemble à ceci :

config :omniss7,
  # Drapeaux de mode - Activer uniquement les fonctionnalit��s STP
  map_client_enabled: true,
  hlr_mode_enabled: false,
  smsc_mode_enabled: false,

  # Configuration de Connexion M3UA
  # Se connecter en tant qu'ASP (Processus Serveur d'Application) à un STP/SGW distant
  map_client_m3ua: %{
    mode: "ASP",
    callback: {MapClient, :handle_payload, []},
    process_name: :stp_client_asp,
    # Point de terminaison local (ce système)
    local_ip: {10, 179, 4, 10},
    local_port: 2905,
    # Point de terminaison STP/SGW distant
    remote_ip: {10, 179, 4, 11},
    remote_port: 2905,
    routing_context: 1
  }

Paramètres de Configuration à Personnaliser

Pour une référence complète de tous les paramètres de configuration, voir la Référence de Configuration.

Paramètre	Type	Par Défaut	Description	Exemple
`map_client_enabled`	Booléen	`true`	Activer le client MAP et les capacités de routage	`true`
`local_ip`	Tuple	Requis	Adresse IP de votre système	`{10, 179, 4, 10}`
`local_port`	Entier	`2905`	Port SCTP local	`2905`
`remote_ip`	Tuple	Requis	Adresse IP STP/SGW distante	`{10, 179, 4, 11}`
`remote_port`	Entier	`2905`	Port SCTP distant	`2905`
`routing_context`	Entier	`1`	ID de contexte de routage M3UA	`1`
`enable_gt_routing`	Booléen	`false`	Activer le routage par Titre Global (en plus du routage par PC)	`true`

Que Se Passe-t-il Lorsque le Mode STP est Activé

Lorsque map_client_enabled: true, l'interface web affichera :

✅ Événements SS7 - Journalisation des événements
✅ Client SS7 - Tests de fonctionnement MAP
✅ M3UA - État de la connexion
✅ Routage - Gestion des tables de routage ← Spécifique au STP
✅ Test de Routage - Test de routage ← Spécifique au STP
✅ Ressources - Surveillance du système
✅ Configuration - Visualiseur de configuration

Les onglets Liens HLR et Liens SMSc seront masqués.

Notes Importantes

Le protocole SCTP (protocole IP 132) doit être autorisé à travers les pare-feux
Le port M3UA par défaut est 2905 (norme de l'industrie)
Assurez-vous de disposer de ressources système suffisantes pour gérer le trafic de routage
Persistance du Routage : Toutes les routes configurées via l'interface Web ou l'API sont stockées dans la base de données Mnesia et survivent aux redémarrages
Fusion de Configuration : Les routes de runtime.exs sont chargées au démarrage et fusionnées avec les routes Mnesia
Après avoir changé de mode, vous devez redémarrer l'application pour que les modifications prennent effet
Interface Web : Voir le Guide de l'Interface Web pour gérer les routes via l'interface web
Accès API : Voir le Guide API pour la documentation de l'API REST et l'accès à Swagger UI

Mode STP Autonome

En plus des capacités de routage STP disponibles lorsque map_client_enabled: true, vous pouvez exécuter un serveur STP M3UA autonome qui écoute les connexions entrantes.

Activation du STP Autonome

Ajoutez cette configuration à config/runtime.exs :

config :omniss7,
  m3ua_stp: %{
    enabled: true,
    local_ip: {127, 0, 0, 1},    # Adresse IP à écouter
    local_port: 2905,             # Port à écouter
    point_code: 100               # Code de point propre à ce STP
  }

Paramètres de Configuration STP

Paramètre	Type	Par Défaut	Description	Exemple
`enabled`	Booléen	`false`	Activer le serveur STP autonome	`true`
`local_ip`	Tuple	`{127, 0, 0, 1}`	Adresse IP à écouter pour les connexions	`{0, 0, 0, 0}`
`local_port`	Entier	`2905`	Port à écouter	`2905`
`point_code`	Entier	Requis	Code de point SS7 propre à ce STP	`100`

Quand Utiliser le STP Autonome

Routage Pur : Lorsque vous avez uniquement besoin de routage M3UA sans fonctionnalité de client MAP
STP Central : Pour créer un routeur de signalisation central pour plusieurs éléments de réseau
Architecture Hub : Connecter plusieurs HLR, MSC et SMSC via un STP central

Remarque : Vous pouvez activer à la fois map_client_m3ua et m3ua_stp simultanément si vous avez besoin à la fois de connexions sortantes et de fonctionnalités STP entrantes.

Persistance des Tables de Routage (Mnesia)

Toutes les tables de routage (pairs, routes de Code de Point et routes de Titre Global) sont stockées dans une base de données Mnesia pour la persistance.

Comment Fonctionne le Routage

Routes runtime.exs : Les routes définies dans config/runtime.exs sous m3ua_peers, m3ua_routes et m3ua_gt_routes sont chargées au démarrage de l'application
Routes Interface Web : Les routes ajoutées via la page de Routage de l'Interface Web sont stockées dans Mnesia
Fusion des Routes : Au redémarrage, les routes runtime.exs sont fusionnées avec les routes Mnesia existantes (pas de doublons)
Persistance : Toutes les routes configurées via l'Interface Web survivent aux redémarrages de l'application

Type de Stockage Mnesia

Contrôlez comment les tables de routage sont stockées. Pour plus de détails sur la configuration de la base de données, voir Paramètres de Base de Données dans la Référence de Configuration.

config :omniss7,
  mnesia_storage_type: :disc_copies  # ou :ram_copies pour les tests

Type de Stockage	Description	Persistance	Cas d'Utilisation
`:disc_copies`	Stockage sur disque (par défaut)	Survit aux redémarrages	Environnements de production
`:ram_copies`	Seulement en mémoire	Perdu au redémarrage	Tests, développement

Par Défaut : :disc_copies

Emplacement de la Base de Données Mnesia

Mnesia stocke les tables de routage dans le répertoire Mnesia de l'application :

Emplacement : Mnesia.{node_name}/ (par exemple, Mnesia.nonode@nohost/)
Tables : m3ua_peer, m3ua_route, m3ua_gt_route

Gestion des Routes

Vous avez trois options pour gérer les routes :

Runtime.exs - Configuration statique chargée au démarrage
Interface Web - Gestion interactive des routes (voir Guide de l'Interface Web)
API REST - Gestion programmatique des routes (voir Guide API)

Meilleure Pratique : Utilisez runtime.exs pour la configuration de base et l'Interface Web pour les modifications dynamiques des routes pendant l'opération.

Configuration des Pairs M3UA

Les pairs représentent les points de terminaison de connexion M3UA (autres STP, HLR, MSC, SMSC). Ajoutez des pairs à config/runtime.exs.

Définition des Pairs M3UA

Exemple de Configuration de Pair

config :omniss7,
  m3ua_peers: [
    # Connexion sortante au STP Partenaire (rôle : :client)
    %{
      peer_id: 1,                           # Identifiant unique
      name: "Partner_STP_West",             # Nom descriptif
      role: :client,                        # :client pour sortant, :server pour entrant
      local_ip: {10, 0, 0, 1},             # IP locale à lier
      local_port: 0,                        # 0 = attribution dynamique de port
      remote_ip: {10, 0, 0, 10},           # IP du pair distant
      remote_port: 2905,                    # Port du pair distant
      routing_context: 1,                   # Contexte de routage M3UA
      point_code: 100,                      # Code de point de ce pair
      network_indicator: :international     # :international ou :national
    },

    # Connexion au HLR Local (rôle : :client)
    %{
      peer_id: 2,
      name: "Local_HLR",
      role: :client,
      local_ip: {10, 0, 0, 1},
      local_port: 0,
      remote_ip: {10, 0, 0, 20},
      remote_port: 2905,
      routing_context: 2,
      point_code: 200,
      network_indicator: :international
    },

    # Connexion entrante du MSC Distant (rôle : :server)
    # Pour le rôle :server, le STP attend une connexion entrante
    %{
      peer_id: 3,
      name: "Remote_MSC",
      role: :server,                        # Accepter la connexion entrante
      remote_ip: {10, 0, 0, 30},           # IP source attendue
      remote_port: 2905,                    # Port source attendu (0 = accepter de n'importe quel port)
      routing_context: 3,
      point_code: 300,
      network_indicator: :international
    },

    # Connexion entrante avec port source dynamique (pas de filtrage de port)
    %{
      peer_id: 4,
      name: "Dynamic_Client",
      role: :server,
      remote_ip: {10, 0, 0, 40},           # IP source attendue
      remote_port: 0,                       # 0 = accepter les connexions de n'importe quel port source
      routing_context: 4,
      point_code: 400,
      network_indicator: :international
    }
  ]

Vérification de l'État du Pair M3UA

Paramètres de Configuration des Pairs

Paramètre	Type	Requis	Description
`peer_id`	Entier	Oui	Identifiant numérique unique pour le pair
`name`	Chaîne	Oui	Nom lisible par l'homme pour les journaux et la surveillance
`role`	Atome	Oui	`:client` (sortant) ou `:server` (entrant)
`local_ip`	Tuple	Oui (client)	Adresse IP locale à lier
`local_port`	Entier	Oui (client)	Port local (0 pour dynamique)
`remote_ip`	Tuple	Oui	Adresse IP du pair distant
`remote_port`	Entier	Oui	Port du pair distant (0 pour entrant = accepter de n'importe quel port source)
`routing_context`	Entier	Oui	Identifiant de contexte de routage M3UA
`point_code`	Entier	Oui	Code de point SS7 de ce pair
`network_indicator`	Atome	Non	`:international` ou `:national`

Filtrage de Port Source pour les Connexions Entrantes

Pour les connexions entrantes (rôle : :server), le paramètre remote_port contrôle le filtrage de port source :

Port Spécifique (par exemple, remote_port: 2905) : N'accepter que les connexions de ce port source exact
- Fournit une sécurité supplémentaire en validant le port source
- Utiliser lorsque le pair distant utilise un port source fixe
N'importe quel Port (remote_port: 0) : Accepter les connexions de n'importe quel port source
- Utile lorsque le pair distant utilise des ports sources dynamiques/éphémères
- Ne valide que l'adresse IP source
- Plus flexible mais légèrement moins sécurisé

Exemple :

# Accepter uniquement de 10.5.198.200:2905 (port spécifique)
%{
  peer_id: 1,
  name: "Strict_Peer",
  role: :server,
  remote_ip: {10, 5, 198, 200},
  remote_port: 2905,
  # ... autre config
}

# Accepter de 10.5.198.200 avec n'importe quel port source
%{
  peer_id: 2,
  name: "Flexible_Peer",
  role: :server,
  remote_ip: {10, 5, 198, 200},
  remote_port: 0,  # Accepter de n'importe quel port source
  # ... autre config
}

Support du Protocole M2PA

OmniSS7 prend en charge à la fois les protocoles M3UA et M2PA pour le transport de signalisation SS7.

Qu'est-ce que M2PA ?

M2PA (MTP2 User Peer-to-Peer Adaptation Layer) est un protocole standardisé par l'IETF (RFC 4165) pour transporter les messages MTP3 SS7 sur des réseaux IP en utilisant SCTP.

M3UA vs M2PA : Principales Différences

Fonctionnalité	M3UA	M2PA
Architecture	Client/Serveur (ASP/SGW)	Pair-à-Pair
Cas d'Utilisation	Passerelle entre SS7 et IP	Liens directs point à point
Gestion de l'État de Lien	Niveau application (ASPUP/ASPAC)	Style MTP2 (Alignement, Vérification, Prêt)
Numéros de Séquence	Pas de séquençage inhérent	BSN/FSN de 24 bits pour livraison ordonnée
Déploiement Typique	Passerelle SS7 vers IP, STP	Liens de signalisation directs entre nœuds
RFC	RFC 4666	RFC 4165

Conseils de Sélection de Protocole

Recommandation : Utilisez M3UA par défaut. N'utilisez M2PA que lorsque cela est spécifiquement requis.

Quand Utiliser M3UA (Recommandé)

M3UA est le protocole recommandé pour la plupart des déploiements :

Déploiements STP : Implémentations standard de point de transfert de signalisation
Fonctions de Passerelle : Relier les réseaux SS7 avec la signalisation basée sur IP
Connexions d'Éléments de Réseau : Connecter HLR, MSC, SMSC et autres éléments de réseau à votre STP
Passerelle de Signalisation (SGW) : Passerelle centrale acceptant les connexions de plusieurs Serveurs d'Application
Topologies Flexibles : Architectures client/serveur avec contrôle centralisé
Réseaux Multi-Fournisseurs : Norme de l'industrie largement supportée (RFC 4666)

Utilisez M3UA pour connecter les éléments de réseau (HLR, MSC, SMSC, VLR, etc.) à votre STP.

Quand Utiliser M2PA (Cas Spéciaux Uniquement)

M2PA ne doit être utilisé que dans des scénarios spécifiques :

Liens STP-à-STP : Connexions directes point à point entre Points de Transfert de Signalisation dans un réseau multi-STP
Remplacement TDM Héritage : Remplacer les liens TDM SS7 traditionnels lorsque le système distant exige spécifiquement M2PA
Compatibilité MTP2 Requise : Lors de la connexion à des systèmes hérités qui imposent une gestion de l'état de lien de style MTP2
Exigence Partenaire : Lorsqu'un partenaire ou une interconnexion exige spécifiquement le protocole M2PA

Important : Ne pas utiliser M2PA pour connecter des éléments de réseau (HLR, MSC, SMSC) à votre STP - utilisez M3UA à la place. M2PA est conçu pour les interconnexions STP-à-STP où les deux côtés fonctionnent comme des nœuds de routage.

Configuration des Pairs M2PA

Les pairs M2PA sont configurés de la même manière que les pairs M3UA, avec un paramètre protocol supplémentaire.

Configuration des Pairs M2PA

Ajoutez des pairs M2PA à votre configuration m3ua_peers dans config/runtime.exs (oui, ils partagent la même section de configuration malgré le fait qu'ils soient des protocoles différents) :

Paramètres Clés pour M2PA :

Paramètre	Valeur	Description
`protocol`	`:m2pa`	Spécifie le protocole M2PA (par défaut `:m3ua` si omis)
`role`	`:client` ou `:server`	Direction de la connexion
`local_port`	Entier	Port SCTP local (le port standard M2PA est 3565)
`remote_port`	Entier	Port SCTP distant (le port standard M2PA est 3565)
`point_code`	Entier	Votre code de point
`adjacent_point_code`	Entier	Code de point du pair distant (spécifique à M2PA)

Remarque : M2PA utilise le port 3565 comme norme de l'industrie (différent du port 2905 de M3UA).

États de Lien M2PA

Les liens M2PA progressent à travers plusieurs états lors de l'initialisation :

Down - Aucune connexion établie
Alignment - Phase de synchronisation initiale (~1 seconde)
Proving - Vérification de la qualité du lien (~2 secondes)
Ready - Lien actif et prêt pour le trafic

La progression de l'état de lien assure une signalisation fiable avant l'échange de trafic.

Gestion des Pairs M2PA via l'Interface Web

La page Routage dans l'Interface Web fournit un support complet pour la gestion des pairs M2PA :

Naviguer vers la page de Routage
Sélectionner l'onglet "Pairs"
Cliquer sur "Ajouter un Nouveau Pair"
Choisir "M2PA (RFC 4165)" dans le menu déroulant Protocole
Remplir la configuration du pair :
- Nom du Pair (identifiant descriptif)
- Protocole : M2PA
- Rôle : client ou serveur
- Code de Point (votre PC)
- Adresses IP Locales/Distant
- Ports Locaux/Distant (typiquement 3565 pour M2PA)
- Indicateur de Réseau (international ou national)
Cliquer sur "Enregistrer le Pair"

La table des pairs affiche le type de protocole avec un code couleur :

Bleu - pairs M3UA
Vert - pairs M2PA

Comportement de Routage M2PA

Les pairs M2PA s'intègrent parfaitement au système de routage d'OmniSS7 :

Routes de Code de Point : Fonctionnent identiquement pour M2PA et M3UA
Routes de Titre Global : Entièrement supportées sur les liens M2PA
Priorité de Route : Les pairs M2PA et M3UA peuvent être mélangés dans les mêmes tables de routage
Relais de Message : Les messages peuvent arriver sur M2PA et être routés vers M3UA, et vice versa

Métriques M2PA

M2PA fournit des métriques Prometheus complètes pour surveiller la santé et le trafic des liens :

Métriques de Trafic :

m2pa_messages_sent_total - Total des messages MTP3 envoyés par lien
m2pa_messages_received_total - Total des messages MTP3 reçus par lien
m2pa_bytes_sent_total - Total des octets envoyés sur M2PA
m2pa_bytes_received_total - Total des octets reçus sur M2PA

Toutes les métriques de trafic sont étiquetées par : link_name, point_code, adjacent_pc

Métriques d'État de Lien :

m2pa_link_state_changes_total - Transitions d'état de lien (DOWN → ALIGNMENT → PROVING → READY)
- Étiquettes : link_name, from_state, to_state

Métriques d'Erreur :

m2pa_errors_total - Total des erreurs par type
- decode_error - Échecs de décodage de message M2PA
- encode_error - Échecs d'encodage de message M2PA
- sctp_send_error - Échecs de transmission SCTP
- Étiquettes : link_name, error_type

Accès aux Métriques :

Point de terminaison Prometheus : http://your-server:8080/metrics
Les métriques s'enregistrent automatiquement au démarrage de l'application

Meilleures Pratiques M2PA

Sélection de Port : Utilisez le port 3565 pour M2PA (norme de l'industrie)
Surveillance de Lien : Surveillez les changements d'état de lien via les métriques
Règles de Pare-feu : Assurez-vous que SCTP (protocole IP 132) est autorisé
Codes de Point : Assurez-vous que les codes de point adjacents sont correctement configurés des deux côtés
Indicateur de Réseau : Doit correspondre entre les pairs (international ou national)
Tests : Utilisez la page de Test de Routage pour vérifier la connectivité après configuration

Configuration du Routage par Code de Point

Le routage par Code de Point dirige les messages en fonction du Code de Point de Destination (DPC) dans l'en-tête MTP3.

Comprendre les Codes de Point dans la Pile de Protocole SS7

Les codes de point existent à différents niveaux de la pile de protocole SS7. Comprendre cette distinction est important :

Couches de la Pile de Protocole :

┌─────────────────────────────────────────┐
│  Couche d'Application (SCCP/TCAP/MAP)  │
├─────────────────────────────────────────┤
│  Couche MTP3                           │ ← Routage des Données Utilisateur
│  - Étiquette de Routage : DPC, OPC, SLS │ ← Utilisé pour le routage STP
│  - Octet d'Information de Service (SIO)│
├─────────────────────────────────────────┤
│  M3UA ou M2PA (Couche d'Adaptation)   │ ← Protocole de Transport
│  - Données de Protocole (contient MTP3)│
│  - Gestion de Réseau (DUNA/DAVA)       │ ← État du Réseau
├────────���────────────────────────────────┤
│  SCTP (Transport)                       │
└─────────────────────────────────────────┘

Deux Types de Codes de Point :

Codes de Point de Couche MTP3 (Utilisés pour le Routage) :
- Situés dans l'étiquette de routage MTP3 (DPC, OPC)
- Présents dans le paramètre Données de Protocole M3UA (tag 528)
- Présents dans les messages de Données Utiles M2PA
- Le STP utilise ces valeurs DPC pour les décisions de routage
- Elles déterminent où le message est finalement livré
Codes de Point de Couche M3UA (Utilisés pour la Gestion de Réseau) :
- Présents dans les messages de gestion M3UA (DUNA, DAVA, SCON, DUPU)
- Indiquent les codes de point affectés pour l'état du réseau
- Informer les pairs des destinations disponibles/non disponibles
- Non utilisés pour le routage des données utilisateur

Comment Fonctionne le Routage STP :

Pour les messages M3UA DATA : Le STP extrait le message MTP3 du paramètre Données de Protocole (tag 528), qui contient l'étiquette de routage MTP3 (DPC, OPC, SLS). Le DPC de la couche MTP3 est utilisé pour rechercher des routes.
Pour les messages de Données Utiles M2PA : Le STP extrait le message MTP3 du champ de données utilisateur M2PA, puis lit le DPC de l'étiquette de routage MTP3.
Messages de gestion M3UA : Les messages de gestion du réseau (DUNA, DAVA, SCON) contiennent les codes de point affectés au niveau M3UA pour signaler l'état du réseau entre les pairs.

Routes de Code de Point de Base

Ajoutez des routes à config/runtime.exs :

config :omniss7,
  m3ua_routes: [
    # Route tout le trafic pour le PC 100 vers le pair 1 (STP Partenaire)
    %{
      dest_pc: 100,                    # Code de point de destination
      peer_id: 1,                      # Pair à travers lequel router
      priority: 1,                     # Priorité (plus bas = plus haute priorité)
      network_indicator: :international
      # mask: 14                       # Optionnel : par défaut 14 (correspondance exacte)
    },

    # Route tout le trafic pour le PC 200 vers le pair 2 (HLR Local)
    %{
      dest_pc: 200,
      peer_id: 2,
      priority: 1,
      network_indicator: :international
    },

    # Exemple d'équilibrage de charge : PC 300 avec routes principale et de secours
    %{
      dest_pc: 300,
      peer_id: 3,                      # Route principale
      priority: 1,
      network_indicator: :international
    },
    %{
      dest_pc: 300,
      peer_id: 4,                      # Route de secours (numéro de priorité plus élevé)
      priority: 2,
      network_indicator: :international
    }
  ]

Remarque : Le champ mask est optionnel et par défaut à 14 (correspondance exacte). Ne spécifiez le mask que lorsque vous avez besoin d'un routage basé sur des plages (voir la section sur les Masques de Code de Point ci-dessous).

Logique de Routage

Le STP reçoit un message M3UA DATA ou un message de Données Utiles M2PA
Le STP extrait le message MTP3 du champ Données de Protocole (M3UA) ou Données Utiles (M2PA)
Le STP lit le Code de Point de Destination (DPC) de l'étiquette de routage MTP3
Recherche dans la table de routage pour un DPC correspondant (en tenant compte des masques)
Si plusieurs routes existent, sélectionne la route avec le masque le plus spécifique (valeur de masque la plus élevée), puis le numéro de priorité le plus bas
Enveloppe le message MTP3 dans M3UA DATA ou Données Utiles M2PA pour le pair de destination
Route le message vers le pair correspondant
Si le pair sélectionné est hors service, essaie la route de priorité la plus élevée suivante

Définition des Routes PC

Masques de Code de Point

Les codes de point sont des valeurs de 14 bits (plage 0-16383). Par défaut, les routes correspondent exactement à un seul code de point (masque /14). Cependant, vous pouvez utiliser des masques de code de point pour créer des routes qui correspondent à des plages de codes de point.

Comprendre les Masques

Le masque spécifie combien de bits les plus significatifs doivent correspondre entre le PC de destination de la route et le DPC du message entrant. Les bits restants peuvent avoir n'importe quelle valeur, créant une plage de codes de point correspondants.

Table de Référence des Masques :

Masque	Codes de Point Correspondants	Cas d'Utilisation
`/14`	1 PC (correspondance exacte)	Destination unique (par défaut)
`/13`	2 PCs	Petite plage
`/12`	4 PCs	Petite plage
`/11`	8 PCs	Petite plage
`/10`	16 PCs	Plage moyenne
`/9`	32 PCs	Plage moyenne
`/8`	64 PCs	Plage moyenne
`/7`	128 PCs	Plage moyenne-grande
`/6`	256 PCs	Grande plage
`/5`	512 PCs	Grande plage
`/4`	1,024 PCs	Très grande plage
`/3`	2,048 PCs	Très grande plage
`/2`	4,096 PCs	Plage extrêmement grande
`/1`	8,192 PCs	La moitié de tous les PCs
`/0`	16,384 PCs	Tous les PCs (route par défaut/de secours)

Exemples de Masques de Code de Point

Remarque : Le champ mask est optionnel dans tous les exemples. S'il est omis, il par défaut à 14 (correspondance exacte).

Exemple 1 : Code de Point Unique (Comportement par Défaut)

# Sans champ de masque (recommandé pour un PC unique)
%{
  dest_pc: 1000,
  peer_id: 1,
  priority: 1,
  network_indicator: :international
}
# Masque par défaut à 14 - Correspond à : Seulement PC 1000

# Masque explicite (même résultat)
%{
  dest_pc: 1000,
  peer_id: 1,
  priority: 1,
  mask: 14,                              # Correspondance exacte explicite
  network_indicator: :international
}
# Correspond à : Seulement PC 1000

Exemple 2 : Petite Plage

%{
  dest_pc: 1000,
  peer_id: 2,
  priority: 1,
  mask: 12,                              # Correspond à 4 PCs
  network_indicator: :international
}
# Correspond à : PC 1000, 1001, 1002, 1003

Exemple 3 : Plage Moyenne

%{
  dest_pc: 1000,
  peer_id: 3,
  priority: 1,
  mask: 8,                               # Correspond à 64 PCs
  network_indicator: :international
}
# Correspond à : PC 1000-1063 (64 codes de point consécutifs)

Exemple 4 : Route par Défaut/De Secours

%{
  dest_pc: 0,
  peer_id: 4,
  priority: 10,                          # Basse priorité (numéro élevé)
  mask: 0,                               # Correspond à tous les PCs
  network_indicator: :international
}
# Correspond à : Tous les codes de point (0-16383)
# Utiliser comme une route de secours/catch-all avec une faible priorité

Combinaison de Routes Spécifiques et Masquées

Vous pouvez combiner des routes spécifiques avec des routes masquées pour un routage flexible :

config :omniss7,
  m3ua_routes: [
    # Route spécifique pour le PC 1000 (prend la priorité)
    %{
      dest_pc: 1000,
      peer_id: 1,
      priority: 1,
      network_indicator: :international
      # masque par défaut à 14 (correspondance exacte)
    },

    # Route de plage pour les PCs 1000-1063
    %{
      dest_pc: 1000,
      peer_id: 2,
      priority: 1,
      mask: 8,                           # Correspond à 64 PCs
      network_indicator: :international
    },

    # Route par défaut/de secours pour tous les autres PCs
    %{
      dest_pc: 0,
      peer_id: 3,
      priority: 10,                      # Basse priorité
      mask: 0,                           # Correspond à tous les PCs
      network_indicator: :international
    }
  ]

Décision de Routage pour DPC 1000 :

Correspond à la route masque /14 (PC 1000 exactement) - Sélectionnée (la plus spécifique)
Correspond également à la route masque /8 (plage PC 1000-1063) - Ignorée (moins spécifique)
Correspond également à la route masque /0 (tous les PCs) - Ignorée (la moins spécifique)

Décision de Routage pour DPC 1015 :

Ne correspond pas à la route masque /14 (PC 1000 uniquement)
Correspond à la route masque /8 (plage PC 1000-1063) - Sélectionnée (correspondance la plus spécifique)
Correspond également à la route masque /0 (tous les PCs) - Ignorée (la moins spécifique)

Décision de Routage pour DPC 5000 :

Ne correspond pas à la route masque /14
Ne correspond pas à la route masque /8
Correspond à la route masque /0 (tous les PCs) - Sélectionnée (seule correspondance, route de secours)

Meilleures Pratiques

Omettre mask pour les Destinations Uniques : Pour des correspondances exactes de code de point, omettez complètement le champ mask (par défaut à /14)
Utiliser /14 Explicitement Seulement Lorsque Nécessaire : Ne spécifiez mask: 14 que lorsque vous devez le clarifier dans la documentation ou lorsque vous mélangez avec des routes de plage
Utiliser des Masques de Plage pour des Blocs Réseau : Routage de segments de réseau entiers vers des pairs spécifiques avec des masques /0 à /13
Utiliser /0 comme Route de Secours : Créer une route par défaut avec une faible priorité pour attraper le trafic non apparié
La Plus Spécifique Gagne : Le moteur de routage sélectionne toujours la correspondance de route la plus spécifique (valeur de masque la plus élevée) en premier
Priorité comme Critère de Détermination : Si plusieurs routes ont le même masque, le numéro de priorité le plus bas l'emporte

Configuration du Routage par Titre Global (GT)

Le routage par Titre Global permet un routage basé sur le contenu en utilisant des numéros de téléphone ou des valeurs IMSI au lieu de codes de point. Pour un routage avancé par Titre Global basé sur l'appelant/l'appelé, voir le Guide NAT de Titre Global.

Définition des Routes GT

Prérequis

Activer le routage GT : enable_gt_routing: true dans config/runtime.exs

Configuration des Routes GT

config :omniss7,
  # Activer le routage GT
  enable_gt_routing: true,

  m3ua_gt_routes: [
    # Route tous les numéros UK (préfixe 44) vers le pair 1
    %{
      gt_prefix: "44",                 # Préfixe de Titre Global à correspondre
      peer_id: 1,                      # Pair de destination
      priority: 1,                     # Priorité (plus bas = plus haut)
      description: "Numéros UK"        # Description pour la journalisation
    },

    # Route les numéros US (préfixe 1) vers le pair 2
    %{
      gt_prefix: "1",
      peer_id: 2,
      priority: 1,
      description: "Numéros US"
    },

    # Route plus spécifique : numéros mobiles UK commençant par 447
    %{
      gt_prefix: "447",                # La correspondance de préfixe la plus longue gagne
      peer_id: 3,
      priority: 1,
      description: "Numéros mobiles UK"
    },

    # Routage spécifique à SSN (optionnel)
    %{
      gt_prefix: "555",
      source_ssn: 8,                   # Correspond uniquement si SSN source = 8 (SMSC)
      peer_id: 4,
      dest_ssn: 6,                     # Réécrire SSN de destination à 6 (HLR)
      priority: 1,
      description: "Trafic SMS pour préfixe 61"
    }
  ]

Logique de Routage GT

L'algorithme de routage GT suit ce processus décisionnel :

Étapes de Routage :

Correspondance de Préfixe le Plus Long : Le STP trouve toutes les routes GT où le préfixe correspond au début du Titre Global
- Exemple : GT "447712345678" correspond à "44" et "447", mais "447" gagne (correspondance la plus longue)
Correspondance SSN (Optionnel) :
- Si source_ssn est spécifié, la route ne correspond que lorsque le SSN de la Partie Appelée SCCP est égal à cette valeur
- Si source_ssn est nil, la route correspond à n'importe quel SSN (wildcard)
Correspondance TT/NPI/NAI (Optionnel) :
- Si source_tt, source_npi ou source_nai sont spécifiés, les routes doivent correspondre à ces indicateurs
- Les valeurs nil agissent comme des wildcards (correspondent à n'importe quelle valeur)
Sélection Basée sur la Spécificité :
- Les routes avec des critères de correspondance plus spécifiques gagnent sur les wildcards
- Ordre de priorité : Longueur de Préfixe GT → SSN → TT → NPI → NAI → Numéro de Priorité
Réécriture des Indicateurs (Optionnel) :
- Si dest_ssn, dest_tt, dest_npi ou dest_nai sont spécifiés, le STP réécrit ces indicateurs
- Utile pour la normalisation des protocoles et l'interconnexion des réseaux
Retour au Code de Point :
- Si aucune route GT ne correspond, le STP revient au routage par Code de Point en utilisant le DPC

Routage Avancé GT : Type de Traduction, NPI et NAI

En plus de la correspondance de préfixe GT et de SSN, le STP prend en charge le routage et la transformation basés sur les indicateurs de Titre Global SCCP :

Type de Traduction (TT) : Identifie le plan de numérotation et le type d'adresse
Indicateur de Plan de Numérotation (NPI) : Définit le plan de numérotation (par exemple, ISDN, Données, Telex)
Indicateur de Nature d'Adresse (NAI) : Spécifie le format d'adresse (par exemple, International, National, Abonné)

Routage Avancé SS7

Correspondance (Indicateurs Source)

Les routes peuvent correspondre sur les indicateurs des messages entrants :

source_tt: Correspondre aux messages avec un Type de Traduction spécifique
source_npi: Correspondre aux messages avec un Indicateur de Plan de Numérotation spécifique
source_nai: Correspondre aux messages avec un Indicateur de Nature d'Adresse spécifique
Valeur nil = wildcard (correspond à n'importe quelle valeur)

Transformation (Indicateurs de Destination)

Les routes peuvent réécrire les indicateurs lors du transfert :

dest_tt: Transformer le Type de Traduction en nouvelle valeur
dest_npi: Transformer l'Indicateur de Plan de Numérotation en nouvelle valeur
dest_nai: Transformer l'Indicateur de Nature d'Adresse en nouvelle valeur
Valeur nil = préserver la valeur d'origine (pas de transformation)

Sélection Basée sur la Spécificité

Lorsque plusieurs routes correspondent, la route la plus spécifique est sélectionnée en utilisant cet ordre de priorité :

Correspondance de préfixe GT le plus long
SSN source spécifique sur SSN wildcard
TT source spécifique sur TT wildcard
NPI source spécifique sur NPI wildcard
NAI source spécifique sur NAI wildcard
Numéro de priorité le plus bas

Exemples de Configuration

config :omniss7,
  enable_gt_routing: true,

  m3ua_gt_routes: [
    # Exemple 1 : Correspondre et transformer le Type de Traduction
    %{
      gt_prefix: "44",
      peer_id: 1,
      source_tt: 0,      # Correspondre TT=0 (Inconnu)
      dest_tt: 3,        # Transformer en TT=3 (National)
      priority: 1,
      description: "Numéros UK : transformation TT 0→3"
    },

    # Exemple 2 : Correspondre NPI spécifique et transformer NAI
    %{
      gt_prefix: "1",
      peer_id: 2,
      source_npi: 1,     # Correspondre NPI=1 (ISDN/Téléphonie)
      source_nai: 4,     # Correspondre NAI=4 (International)
      dest_nai: 3,       # Transformer en NAI=3 (National)
      priority: 1,
      description: "Numéros US : International→National NAI"
    },

    # Exemple 3 : Routage combiné SSN et indicateurs
    %{
      gt_prefix: "33",
      source_ssn: 8,     # Correspondre au trafic SMSC
      source_tt: 0,      # Correspondre TT=0
      dest_ssn: 6,       # Réécrire SSN à HLR
      dest_tt: 2,        # Transformer en TT=2
      dest_npi: 1,       # Définir NPI=1 (ISDN)
      dest_nai: 4,       # Définir NAI=4 (International)
      peer_id: 3,
      priority: 1,
      description: "SMS français : Normalisation complète"
    },

    # Exemple 4 : Wildcard TT, NPI spécifique
    %{
      gt_prefix: "49",
      source_tt: nil,    # Correspondre à n'importe quel TT (wildcard)
      source_npi: 6,     # Correspondre NPI=6 (Données)
      dest_npi: 1,       # Transformer en NPI=1 (ISDN)
      peer_id: 4,
      priority: 1,
      description: "Normalisation du réseau de données allemand"
    }
  ]

Valeurs Courantes de TT/NPI/NAI

Type de Traduction (TT) :

0 = Inconnu
1 = International
2 = National
3 = Spécifique au Réseau

Indicateur de Plan de Numérotation (NPI) :

0 = Inconnu
1 = ISDN/Téléphonie (E.164)
3 = Données (X.121)
4 = Telex (F.69)
6 = Mobile Terrestre (E.212)

Indicateur de Nature d'Adresse (NAI) :

0 = Inconnu
1 = Numéro d'Abonné
2 = Réservé pour Utilisation Nationale
3 = Numéro Significatif National
4 = Numéro International

Exemple de Décision de Routage

Pour un message entrant avec :

GT : "447712345678"
SSN : 8
TT : 0
NPI : 1
NAI : 4

Avec ces routes configurées :

# Route A : Wildcard TT
%{gt_prefix: "447", peer_id: 1, priority: 1}

# Route B : TT spécifique
%{gt_prefix: "447", source_tt: 0, peer_id: 2, priority: 1}

# Route C : TT spécifique + NPI
%{gt_prefix: "447", source_tt: 0, source_npi: 1, peer_id: 3, priority: 1}

Résultat : La Route C est sélectionnée (la plus spécifique : correspond à GT + TT + NPI)

Le message est transféré avec des indicateurs transformés selon les valeurs dest_tt, dest_npi, dest_nai de la Route C.

Exemples de Routage GT

GT Appelé	SSN Source	TT	NPI	NAI	Route Correspondante	Raison
447712345678	6	-	-	-	"447" → pair 3	Correspondance de préfixe la plus longue
441234567890	6	-	-	-	"44" → pair 1	Correspondance de préfixe, aucune route plus spécifique
12125551234	6	-	-	-	"1" → pair 2	Correspondance de préfixe pour numéros US
555881234567	8	-	-	-	"555" (SSN 8) → pair 4	Correspondance GT + SSN, réécrit SSN à 6
555881234567	6	-	-	-	"555" (wildcard SSN) → pair X	Correspondance GT, pas de réécriture SSN
441234567890	6	0	1	4	"44" (TT=0) → pair 1	Correspondance GT + TT, transforme TT en 3
12125551234	8	0	1	4	"1" (TT=0, NPI=1, NAI=4)	Plus spécifique : correspondance GT+TT+NPI+NAI

Cas d'Utilisation Courants pour le Routage TT/NPI/NAI

Normalisation de l'Interconnexion Réseau
- Différents réseaux peuvent utiliser des conventions d'indicateur différentes
- Transformer les indicateurs au point d'interconnexion pour assurer la compatibilité
- Exemple : Le réseau partenaire utilise TT=0 pour international, votre réseau utilise TT=1
Conversion de Protocole
- Convertir entre des plans de numérotation lors du routage entre différents types de réseau
- Exemple : Route d'un réseau mobile (NPI=6) vers le PSTN (NPI=1)
Standardisation du Format d'Adresse
- Normaliser tout le trafic entrant pour utiliser des valeurs NAI cohérentes
- Exemple : Convertir tous les formats internationaux (NAI=4) en format national (NAI=3) pour le routage domestique
Routage Spécifique au Fournisseur
- Router en fonction du type de traduction vers différents fournisseurs de services
- Exemple : TT=0 route vers le Fournisseur A, TT=2 route vers le Fournisseur B
Intégration de Systèmes Hérités
- Les systèmes modernes peuvent utiliser des valeurs d'indicateur différentes de celles des systèmes hérités
- Transformer au STP pour maintenir la compatibilité avec les anciens systèmes

Fonctionnalités de Gestion des Routes

Désactivation des Routes

Les routes peuvent être temporairement désactivées sans être supprimées. Cela est utile pour les tests, la maintenance ou la gestion du trafic.

Drapeau Activé

Les routes par Code de Point et par Titre Global prennent en charge un drapeau enabled optionnel :

config :omniss7,
  m3ua_routes: [
    # Route active
    %{
      dest_pc: 100,
      peer_id: 1,
      priority: 1,
      network_indicator: :international,
      enabled: true  # Route active (par défaut si omis)
    },

    # Route désactivée (non évaluée lors du routage)
    %{
      dest_pc: 200,
      peer_id: 2,
      priority: 1,
      network_indicator: :international,
      enabled: false  # Route désactivée
    }
  ],

  m3ua_gt_routes: [
    # Route GT désactivée
    %{
      gt_prefix: "44",
      peer_id: 1,
      priority: 1,
      description: "Numéros UK - temporairement désactivés",
      enabled: false
    }
  ]

Comportement par Défaut :

Si enabled n'est pas spécifié, les routes sont par défaut enabled: true
Les routes désactivées sont complètement ignorées lors de la recherche de routes
Utilisez l'Interface Web pour activer/désactiver les routes sans modifier la configuration

Cas d'Utilisation :

Tester les modifications de flux de trafic
Fenêtres de maintenance temporaires
Tests A/B de différents chemins de routage
Déploiement progressif de nouvelles routes

Routes DROP - Prévention des Boucles de Routage

Les routes DROP (avec peer_id: 0) rejettent silencieusement le trafic au lieu de le transférer. Cela empêche les boucles de routage et permet un filtrage avancé du trafic.

Configuration des Routes DROP

config :omniss7,
  m3ua_routes: [
    # Route DROP pour un code de point spécifique
    %{
      dest_pc: 999,
      peer_id: 0,        # peer_id=0 signifie DROP
      priority: 1,
      network_indicator: :international
    }
  ],

  m3ua_gt_routes: [
    # Route DROP pour préfixe GT
    %{
      gt_prefix: "999",
      peer_id: 0,        # peer_id=0 signifie DROP
      priority: 99,
      description: "Bloquer la plage de test"
    }
  ]

Comment Fonctionnent les Routes DROP

Lorsqu'un message correspond à une route DROP :

Le moteur de routage identifie peer_id: 0
Le message est silencieusement rejeté (non transféré)
Un journal INFO est généré : "Route DROP correspondante pour DPC 999" ou "Route DROP correspondante pour GT 999"
La recherche de routage retourne {:error, :dropped}

Important : Le trafic rejeté est enregistré au niveau INFO pour la surveillance et le dépannage.

Cas d'Utilisation Courant : Liste Blanche de Préfixes

L'une des utilisations les plus puissantes des routes DROP est la liste blanche de préfixes - permettant uniquement des numéros spécifiques au sein d'une grande plage tout en bloquant tous les autres.

Le Modèle :

Créer une route DROP pour l'ensemble du préfixe avec un numéro de priorité élevé (par exemple, 99)
Créer des routes d'autorisation spécifiques pour des numéros individuels avec des numéros de priorité bas (par exemple, 1)
Étant donné que les numéros de priorité plus bas sont évalués en premier, les routes autorisées correspondent avant la route DROP
Tout numéro non explicitement autorisé est attrapé par la route DROP

Scénario Exemple :

Vous avez un préfixe GT 1234 qui représente une plage de 10 000 numéros (1234000000 - 1234999999), mais vous ne souhaitez router que 3 numéros spécifiques : 1234567890, 1234555000, et 1234111222.

config :omniss7,
  m3ua_gt_routes: [
    # Route DROP avec PRIORITÉ ÉLEVÉE (évaluée en dernier)
    %{
      gt_prefix: "1234",
      peer_id: 0,              # DROP
      priority: 99,            # Numéro élevé = faible priorité = évalué en dernier
      description: "Bloquer tous les 1234* sauf les numéros sur liste blanche"
    },

    # Routes d'autorisation spécifiques avec NUMÉROS DE PRIORITÉ FAIBLES (évaluées en premier)
    %{
      gt_prefix: "1234567890",
      peer_id: 1,              # Route vers le pair 1
      priority: 1,             # Numéro bas = haute priorité = évalué en premier
      description: "Numéro autorisé 1"
    },
    %{
      gt_prefix: "1234555000",
      peer_id: 1,
      priority: 1,
      description: "Numéro autorisé 2"
    },
    %{
      gt_prefix: "1234111222",
      peer_id: 1,
      priority: 1,
      description: "Numéro autorisé 3"
    }
  ]

Comportement de Routage :

GT Entrant	Routes Correspondantes	Route Sélectionnée	Action
1234567890	✅ "1234567890" (priorité 1) ✅ "1234" DROP (priorité 99)	"1234567890" (la plus spécifique, la plus haute priorité)	Routé vers le pair 1
1234555000	✅ "1234555000" (priorité 1) ✅ "1234" DROP (priorité 99)	"1234555000" (la plus spécifique, la plus haute priorité)	Routé vers le pair 1
1234111222	✅ "1234111222" (priorité 1) ✅ "1234" DROP (priorité 99)	"1234111222" (la plus spécifique, la plus haute priorité)	Routé vers le pair 1
1234999999	✅ "1234" DROP (priorité 99)	"1234" DROP (seule correspondance)	Rejeté + enregistré
1234000000	✅ "1234" DROP (priorité 99)	"1234" DROP (seule correspondance)	Rejeté + enregistré

Résultat :

✅ Seuls 3 numéros spécifiques sont routés vers le pair 1
❌ Tous les autres numéros 1234* sont silencieusement rejetés
📊 Tout le trafic rejeté est enregistré pour la surveillance

Journaux Générés :

[INFO] Route DROP correspondante pour GT 1234999999
[INFO] Route DROP correspondante pour GT 1234000000

Routes DROP pour les Codes de Point

Le même modèle de liste blanche fonctionne pour le routage par Code de Point :

config :omniss7,
  m3ua_routes: [
    # DROP toute la plage /8 (64 codes de point : 1000-1063)
    %{
      dest_pc: 1000,
      peer_id: 0,
      priority: 99,
      mask: 8,
      network_indicator: :international
    },

    # Autoriser des PCs spécifiques
    %{dest_pc: 1010, peer_id: 1, priority: 1, network_indicator: :international},
    %{dest_pc: 1020, peer_id: 1, priority: 1, network_indicator: :international},
    %{dest_pc: 1030, peer_id: 1, priority: 1, network_indicator: :international}
  ]

Résultat : Seules les PCs 1010, 1020 et 1030 sont routées. Tous les autres PCs dans la plage 1000-1063 sont rejetés.

Surveillance des Routes DROP

Vérifiez les Journaux :

# Surveillez le trafic rejeté
tail -f logs/app.log | grep "Route DROP correspondante"

# Sortie attendue :
[INFO] Route DROP correspondante pour GT 1234999999
[INFO] Route DROP correspondante pour DPC 1050

Via l'Interface Web :

Naviguez vers l'onglet Journaux du Système
Filtrer par niveau INFO
Rechercher "Route DROP correspondante"

Meilleures Pratiques :

⚠️ Surveillez régulièrement les journaux pour vous assurer que les routes DROP ne bloquent pas le trafic légitime
📝 Utilisez des champs description descriptifs pour documenter pourquoi les routes sont rejetées
🔢 Utilisez des numéros de priorité élevés (90-99) pour les routes DROP afin de garantir qu'elles soient des routes catch-all
✅ Testez le comportement des routes DROP avant de déployer en production
📊 Configurez des alertes pour des augmentations inattendues du trafic rejeté

Routage Avancé : Routage Basé sur SSN et Réécriture

Numéros de Sous-Système (SSN)

Les Numéros de Sous-Système identifient la couche d'application :

SSN 6 : HLR (Registre de Localisation de l'Abonné)
SSN 7 : VLR (Registre de Localisation Visiteur)
SSN 8 : MSC (Centre de Commutation Mobile) / SMSC (Centre de SMS)
SSN 9 : GMLC (Centre de Localisation Mobile Passerelle)

Exemple de Routage Basé sur SSN

Routage du trafic SMS vers différents HLR en fonction du préfixe de numéro :

m3ua_gt_routes: [
  # Route SMS pour les numéros UK vers HLR UK, réécrire SSN de 8 (SMSC) à 6 (HLR)
  %{
    gt_prefix: "44",
    source_ssn: 8,                    # Correspondre au SSN entrant 8 (SMSC)
    peer_id: 1,
    dest_ssn: 6,                      # Réécrire à SSN 6 (HLR)
    priority: 1,
    description: "SMS UK vers HLR"
  },

  # Route du trafic vocal pour les numéros UK (SSN 6) sans réécriture
  %{
    gt_prefix: "44",
    source_ssn: 6,                    # Correspondre au SSN entrant 6 (HLR)
    peer_id: 1,
    dest_ssn: nil,                    # Pas de réécriture de SSN
    priority: 1,
    description: "Trafic vocal UK"
  }
]

Tester la Configuration de Routage STP

Après avoir configuré les pairs et les routes, vérifiez votre configuration :

1. Vérifier l'État des Pairs

Via l'Interface Web :

Naviguez vers http://localhost
Vérifiez la page d'État M3UA
Assurez-vous que les pairs affichent État : ACTIF

Via la Console IEx :

# Obtenir tous les états des pairs
M3UA.STP.get_peers_status()

# Sortie attendue :
# [
#   %{peer_id: 1, name: "Partner_STP_West", status: :active, point_code: 100, ...},
#   %{peer_id: 2, name: "Local_HLR", status: :active, point_code: 200, ...}
# ]

2. Tester le Routage par Code de Point

# Envoyer un message M3UA de test au DPC 100
test_payload = <<1, 2, 3, 4>>  # Charge utile fictive
M3UA.STP.route_by_pc(100, test_payload, 0)

# Vérifiez les journaux pour la décision de routage
# Journal attendu : "Routage du message : OPC=... -> DPC=100 via pair 1"

Aperçu du Routage

3. Tester le Routage par Titre Global

# Rechercher manuellement la route GT
M3UARouting.lookup_peer_by_gt("447712345678")

# Sortie attendue :
# {:ok, {:m3ua_peer, 3, "UK_Mobile_Peer", ...}, nil}

# Rechercher la route GT avec SSN
M3UARouting.lookup_peer_by_gt("555881234567", 8)

# Sortie attendue avec réécriture SSN :
# {:ok, {:m3ua_peer, 4, "SMS_HLR_Peer", ...}, 6}

4. Surveiller les Métriques de Routage

Accédez aux métriques Prometheus à /metrics

Métriques clés :

# Messages reçus par pair
m3ua_stp_messages_received_total{peer_name="Partner_STP_West",point_code="100"} 1523

# Messages envoyés par pair
m3ua_stp_messages_sent_total{peer_name="Local_HLR",point_code="200"} 1498

# Échecs de routage
m3ua_stp_routing_failures_total{reason="no_route"} 5
m3ua_stp_routing_failures_total{reason="no_gt_route"} 2

Métriques et Surveillance STP

Métriques Disponibles

Métriques de Trafic par Pair :

m3ua_stp_messages_received_total - Total des messages reçus de chaque pair
- Étiquettes : peer_name, point_code
m3ua_stp_messages_sent_total - Total des messages transférés à chaque pair
- Étiquettes : peer_name, point_code

**Métriques d'Échec

Table des Matières​

Qu'est-ce qu'un Point de Transfert de Signalisation (STP) ?​

Fonctions du STP​

Diagramme Réseau STP​

Rôles Réseau STP Expliqués​

ASP (Processus Serveur d'Application)​

SGP (Processus Passerelle de Signalisation)​

AS (Serveur d'Application)​

Activation du Mode M3UA STP​

Changement en Mode STP​

Configuration du Mode STP​

Paramètres de Configuration à Personnaliser​

Que Se Passe-t-il Lorsque le Mode STP est Activé​

Notes Importantes​

Mode STP Autonome​

Activation du STP Autonome​

Paramètres de Configuration STP​

Quand Utiliser le STP Autonome​

Persistance des Tables de Routage (Mnesia)​

Comment Fonctionne le Routage​

Type de Stockage Mnesia​

Emplacement de la Base de Données Mnesia​

Gestion des Routes​

Configuration des Pairs M3UA​

Exemple de Configuration de Pair​

Paramètres de Configuration des Pairs​

Filtrage de Port Source pour les Connexions Entrantes​

Support du Protocole M2PA​

Qu'est-ce que M2PA ?​

M3UA vs M2PA : Principales Différences​

Conseils de Sélection de Protocole​

Quand Utiliser M3UA (Recommandé)​

Quand Utiliser M2PA (Cas Spéciaux Uniquement)​

Configuration des Pairs M2PA​

Configuration des Pairs M2PA​

États de Lien M2PA​

Gestion des Pairs M2PA via l'Interface Web​

Comportement de Routage M2PA​

Métriques M2PA​

Meilleures Pratiques M2PA​

Configuration du Routage par Code de Point​

Comprendre les Codes de Point dans la Pile de Protocole SS7​

Routes de Code de Point de Base​

Logique de Routage​

Masques de Code de Point​

Comprendre les Masques​

Exemples de Masques de Code de Point​

Combinaison de Routes Spécifiques et Masquées​

Meilleures Pratiques​

Configuration du Routage par Titre Global (GT)​

Prérequis​

Configuration des Routes GT​

Logique de Routage GT​

Routage Avancé GT : Type de Traduction, NPI et NAI​

Correspondance (Indicateurs Source)​

Transformation (Indicateurs de Destination)​

Sélection Basée sur la Spécificité​

Exemples de Configuration​

Valeurs Courantes de TT/NPI/NAI​

Exemple de Décision de Routage​

Exemples de Routage GT​

Cas d'Utilisation Courants pour le Routage TT/NPI/NAI​

Fonctionnalités de Gestion des Routes​

Désactivation des Routes​

Drapeau Activé​

Routes DROP - Prévention des Boucles de Routage​

Configuration des Routes DROP​

Comment Fonctionnent les Routes DROP​

Cas d'Utilisation Courant : Liste Blanche de Préfixes​

Routes DROP pour les Codes de Point​

Surveillance des Routes DROP​

Routage Avancé : Routage Basé sur SSN et Réécriture​

Numéros de Sous-Système (SSN)​

Exemple de Routage Basé sur SSN​

Tester la Configuration de Routage STP​

1. Vérifier l'État des Pairs​

2. Tester le Routage par Code de Point​

3. Tester le Routage par Titre Global​

4. Surveiller les Métriques de Routage​

Métriques et Surveillance STP​

Table des Matières

Qu'est-ce qu'un Point de Transfert de Signalisation (STP) ?

Fonctions du STP

Diagramme Réseau STP

Rôles Réseau STP Expliqués

ASP (Processus Serveur d'Application)

SGP (Processus Passerelle de Signalisation)

AS (Serveur d'Application)

Activation du Mode M3UA STP

Changement en Mode STP

Configuration du Mode STP

Paramètres de Configuration à Personnaliser

Que Se Passe-t-il Lorsque le Mode STP est Activé

Notes Importantes

Mode STP Autonome

Activation du STP Autonome

Paramètres de Configuration STP

Quand Utiliser le STP Autonome

Persistance des Tables de Routage (Mnesia)

Comment Fonctionne le Routage

Type de Stockage Mnesia

Emplacement de la Base de Données Mnesia

Gestion des Routes

Configuration des Pairs M3UA

Exemple de Configuration de Pair

Paramètres de Configuration des Pairs

Filtrage de Port Source pour les Connexions Entrantes

Support du Protocole M2PA

Qu'est-ce que M2PA ?

M3UA vs M2PA : Principales Différences

Conseils de Sélection de Protocole

Quand Utiliser M3UA (Recommandé)

Quand Utiliser M2PA (Cas Spéciaux Uniquement)

Configuration des Pairs M2PA

Configuration des Pairs M2PA

États de Lien M2PA

Gestion des Pairs M2PA via l'Interface Web

Comportement de Routage M2PA

Métriques M2PA

Meilleures Pratiques M2PA

Configuration du Routage par Code de Point

Comprendre les Codes de Point dans la Pile de Protocole SS7

Routes de Code de Point de Base

Logique de Routage

Masques de Code de Point

Comprendre les Masques

Exemples de Masques de Code de Point

Combinaison de Routes Spécifiques et Masquées

Meilleures Pratiques

Configuration du Routage par Titre Global (GT)

Prérequis

Configuration des Routes GT

Logique de Routage GT

Routage Avancé GT : Type de Traduction, NPI et NAI

Correspondance (Indicateurs Source)

Transformation (Indicateurs de Destination)

Sélection Basée sur la Spécificité

Exemples de Configuration

Valeurs Courantes de TT/NPI/NAI

Exemple de Décision de Routage

Exemples de Routage GT

Cas d'Utilisation Courants pour le Routage TT/NPI/NAI

Fonctionnalités de Gestion des Routes

Désactivation des Routes

Drapeau Activé

Routes DROP - Prévention des Boucles de Routage

Configuration des Routes DROP

Comment Fonctionnent les Routes DROP

Cas d'Utilisation Courant : Liste Blanche de Préfixes

Routes DROP pour les Codes de Point

Surveillance des Routes DROP

Routage Avancé : Routage Basé sur SSN et Réécriture

Numéros de Sous-Système (SSN)

Exemple de Routage Basé sur SSN

Tester la Configuration de Routage STP

1. Vérifier l'État des Pairs

2. Tester le Routage par Code de Point

3. Tester le Routage par Titre Global

4. Surveiller les Métriques de Routage

Métriques et Surveillance STP