Aller au contenu principal

Configuration du Plan de Numérotation & Routage des Appels

📖 Retour à la Documentation Principale

Guide complet sur la configuration du plan de numérotation XML, la logique de routage des appels et les variables du plan de numérotation.

Documentation Connexe

Documentation de Base

Flux de Traitement des Appels

  • 🔢 Translation de Numéros - Normalisation E.164 (se produit avant le plan de numérotation)
  • 👥 Interface Sh - Données des abonnés récupérées pour les variables du plan de numérotation
  • 📡 SS7 MAP - Données MSRN/HLR dans les variables du plan de numérotation
  • 💳 Chargement en Ligne - Autorisation OCS dans le flux d'appel

Mise en Œuvre des Services

  • ⚙️ Services Supplémentaires - Mise en œuvre du transfert d'appel, blocage CLI dans le plan de numérotation
  • 📞 Messagerie Vocale - Routage de la messagerie vocale et dépôt/récupération dans le plan de numérotation
  • 🔊 Invitations TTS - Utilisation des invitations dans le plan de numérotation avec lecture

Surveillance


Configuration du Plan de Numérotation / Routage des Appels

Le TAS utilise des plans de numérotation XML avec un schéma compatible avec les formats de plan de numérotation XML de télécommunications standard, avec des variables peuplées par le TAS. Cela signifie que vous pouvez définir votre propre plan de numérotation selon vos besoins, avec la logique commerciale pour l'opérateur, mais avoir toutes les données requises telles que les Données du Référentiel, les informations de routage SS7, les identités IMPI / IMPU, la normalisation du plan de numérotation, etc.

Les plans de numérotation sont écrits dans priv/templates et prennent la forme :

  • mo_dialplan.xml - Plan de Numérotation des Appels Originaire Mobile
  • mo_emergency_dialplan.xml - Plan de Numérotation des Appels d'Urgence Originaire Mobile
  • mt_dialplan.xml - Plan de Numérotation des Appels Terminés Mobiles

Vous pouvez visualiser les Plans de Numérotation depuis l'interface Web.

Vue de Routage

Diverses variables sont définies par le TAS avant que le XML ne soit analysé, ces variables sont imprimées dans le journal au début de l'appel avec leurs valeurs actuelles et sont très utiles lors de la définition de votre propre logique d'appel.

Fondamentaux du Plan de Numérotation XML FreeSWITCH

OmniTAS utilise le même système de routage d'appels XML que le projet FreeSWITCH, ce qui permet un routage d'appels flexible pour répondre à vos besoins.

Cette section explique les concepts fondamentaux et fournit des exemples pratiques.

Structure de Base

Un plan de numérotation se compose d'extensions contenant des conditions et des actions :

<extension name="description-de-ce-que-cela-fait">
<condition field="${variable}" expression="regex-pattern">
<action application="app_name" data="parameters"/>
<anti-action application="app_name" data="parameters"/>
</condition>
</extension>

Les extensions sont évaluées dans l'ordre de haut en bas. Lorsqu'une condition correspond, ses actions s'exécutent.

Conditions et Correspondance Regex

Les conditions testent les variables par rapport aux expressions régulières. Si la regex correspond, les actions s'exécutent ; sinon, les anti-actions s'exécutent.

Correspondance exacte de base :

<condition field="${tas_destination_number}" expression="2222">
<action application="log" data="INFO Appel du numéro d'accès à la messagerie vocale"/>
</condition>

Correspondance de plusieurs numéros :

<condition field="${tas_destination_number}" expression="^(2222|3444|3445)$">
<action application="log" data="INFO Appel d'un service spécial"/>
</condition>

Correspondance de motifs avec groupes de capture :

<condition field="${tas_destination_number}" expression="^1(8[0-9]{9})$">
<!-- Correspond à 1 suivi de 8 et 9 autres chiffres -->
<action application="log" data="INFO Correspond à un numéro sans frais : $1"/>
<action application="bridge" data="sofia/gateway/trunk/${tas_destination_number}"/>
</condition>

Correspondance de préfixe :

<condition field="${tas_destination_number}" expression="^00">
<!-- Correspond à tout numéro commençant par 00 (international) -->
<action application="log" data="INFO Appel international détecté"/>
</condition>

Correspondance de plage :

<condition field="${msisdn}" expression="^5551241[0-9]{4}$">
<!-- Correspond à 55512410000 à 55512419999 -->
<action application="log" data="INFO Abonné dans la plage"/>
</condition>

Actions vs Anti-Actions

Les actions s'exécutent lorsqu'une condition correspond. Les anti-actions s'exécutent lorsqu'une condition ne correspond PAS.

<condition field="${cli_withheld}" expression="true">
<!-- S'exécute si le CLI est masqué -->
<action application="set" data="effective_caller_id_number=anonymous"/>
<action application="set" data="origination_privacy=hide_number"/>

<!-- S'exécute si le CLI n'est PAS masqué -->
<anti-action application="log" data="DEBUG CLI est normal"/>
<anti-action application="set" data="effective_caller_id_number=${msisdn}"/>
</condition>

L'attribut continue="true"

Par défaut, lorsqu'une condition d'extension correspond, le plan de numérotation arrête le traitement des extensions suivantes. L'attribut continue="true" permet de continuer le traitement vers l'extension suivante.

Sans continue (comportement par défaut) :

<extension name="First-Check">
<condition field="${tas_destination_number}" expression="^(.*)$">
<action application="log" data="INFO Traitement de l'appel"/>
</condition>
</extension>

<extension name="Never-Reached">
<!-- Cela NE S'EXÉCUTE JAMAIS car l'extension précédente a correspondu -->
<condition field="${tas_destination_number}" expression="^(.*)$">
<action application="log" data="INFO Cela ne s'imprimera pas"/>
</condition>
</extension>

Avec continue="true" :

<extension name="Print-Vars" continue="true">
<condition field="${tas_destination_number}" expression="^(.*)$">
<action application="info" data=""/>
</condition>
</extension>

<extension name="Check-Balance" continue="true">
<condition field="${hangup_case}" expression="OUTGOING_CALL_BARRED">
<action application="log" data="ERROR Solde insuffisant"/>
<action application="hangup" data="${hangup_case}"/>
</condition>
</extension>

<extension name="Route-Call">
<!-- Cette extension est toujours évaluée -->
<condition field="${tas_destination_number}" expression="^(.*)$">
<action application="bridge" data="sofia/gateway/trunk/${tas_destination_number}"/>
</condition>
</extension>

Utilisez continue="true" pour :

  • Extensions de journalisation/debugging
  • Définir des variables qui s'appliquent à plusieurs scénarios
  • Vérifications de validation qui ne routent pas l'appel

Applications Courantes

contrôle des appels

answer - Répondre à l'appel (envoyer 200 OK)

<action application="answer" data=""/>

hangup - Terminer l'appel avec une cause spécifique

<action application="hangup" data="NORMAL_CLEARING"/>
<action application="hangup" data="USER_BUSY"/>
<action application="hangup" data="NO_ANSWER"/>

bridge - Connecter l'appel à une autre destination

<!-- Pont vers la passerelle externe -->
<action application="bridge" data="sofia/gateway/trunk/+12125551234"/>

<!-- Pont vers une extension interne avec préférences de codec -->
<action application="bridge" data="{absolute_codec_string=AMR-WB,AMR,PCMA}sofia/internal/sip:user@domain.com"/>

<!-- Pont avec délai d'attente -->
<action application="bridge" data="{originate_timeout=30}sofia/gateway/trunk/${tas_destination_number}"/>
Variables et Données de Canal

set - Définir une variable de canal

<action application="set" data="my_variable=my_value"/>
<action application="set" data="sip_h_X-Custom-Header=CustomValue"/>
<action application="set" data="effective_caller_id_number=anonymous"/>

unset - Supprimer une variable de canal

<action application="unset" data="sip_h_P-Asserted-Identity"/>

export - Définir une variable et l'exporter vers B-leg (appel ponté)

<action application="export" data="sip_h_X-Account-Code=ABC123"/>
Médias et Invitations

playback - Jouer un fichier audio

<action application="playback" data="/sounds/en/us/callie/misc/8000/out_of_credit.wav"/>
<action application="playback" data="$${base_dir}/sounds/custom_prompt.wav"/>

sleep - Mettre en pause pendant un nombre de millisecondes spécifié

<action application="sleep" data="1000"/>  <!-- Pause de 1 seconde -->

echo - Écho audio au correspondant (test)

<action application="echo" data=""/>

conference - Placer l'appel dans une conférence

<action application="conference" data="room-${destination_number}@wideband"/>
messagerie vocale

voicemail - Accéder au système de messagerie vocale

<!-- Laisser un message vocal pour la boîte aux lettres -->
<action application="voicemail" data="default default ${msisdn}"/>

<!-- Vérifier la messagerie vocale avec authentification -->
<action application="voicemail" data="check auth default default ${msisdn}"/>
Journalisation et Débogage

log - Écrire dans le fichier journal

<action application="log" data="INFO Traitement de l'appel de ${msisdn}"/>
<action application="log" data="DEBUG Destination : ${tas_destination_number}"/>
<action application="log" data="ERROR L'appel a échoué avec la cause : ${hangup_cause}"/>

info - Déverser toutes les variables de canal dans le journal

<action application="info" data=""/>
Applications Diverses

say - Lecture de texte à voix haute du numéro

<action application="say" data="en number iterated ${tas_destination_number}"/>

send_dtmf - Envoyer des tons DTMF

<action application="send_dtmf" data="1234#"/>

Exemples Pratiques

Routage des Services d'Urgence :

<extension name="Emergency-911">
<condition field="${tas_destination_number}" expression="^(911|112)$">
<action application="log" data="ALERT Appel d'urgence de ${msisdn}"/>
<action application="answer" data=""/>
<action application="playback" data="/sounds/emergency_services_transfer.wav"/>
<action application="bridge" data="sofia/gateway/emergency_gw/${tas_destination_number}"/>
</condition>
</extension>

Routage Conditionnel Basé sur le Solde :

<extension name="Check-Credit">
<condition field="${hangup_case}" expression="OUTGOING_CALL_BARRED">
<action application="answer" data=""/>
<action application="playback" data="/sounds/out_of_credit.wav"/>
<action application="hangup" data="CALL_REJECTED"/>
</condition>
</extension>

Routage On-Net vs Off-Net :

<extension name="Route-Decision">
<condition field="${on_net_status}" expression="true">
<!-- On-net : routage à travers TAS -->
<action application="log" data="INFO Routage vers abonné on-net"/>
<action application="bridge" data="sofia/internal/+${tas_destination_number}@10.179.3.60"/>
<anti-action application="log" data="INFO Routage off-net"/>
<anti-action application="bridge" data="sofia/gateway/trunk/+${tas_destination_number}"/>
</condition>
</extension>

Gestion des Identités de Numéros Anonymes :

<extension name="CLI-Privacy" continue="true">
<condition field="${cli_withheld}" expression="true">
<action application="set" data="effective_caller_id_name=anonymous"/>
<action application="set" data="effective_caller_id_number=anonymous"/>
<action application="set" data="origination_privacy=hide_number"/>
</condition>
</extension>

Messagerie Vocale en Cas de Non-Réponse :

<extension name="Try-Bridge-Then-VM">
<condition field="${tas_destination_number}" expression="^(555124115\d{2})$">
<action application="set" data="call_timeout=30"/>
<action application="bridge" data="sofia/internal/${tas_destination_number}@domain.com"/>

<!-- Si le pont échoue, aller à la messagerie vocale -->
<action application="log" data="INFO Le pont a échoué, routage vers la messagerie vocale"/>
<action application="answer" data=""/>
<action application="voicemail" data="default default ${tas_destination_number}"/>
</condition>
</extension>

Routage par Plage de Numéros :

<extension name="Local-Numbers">
<condition field="${tas_destination_number}" expression="^([2-9]\d{2})$">
<!-- Extensions locales à 3 chiffres 200-999 -->
<action application="log" data="INFO Extension locale : $1"/>
<action application="bridge" data="sofia/internal/$1@pbx.local"/>
</condition>
</extension>

<extension name="National-Numbers">
<condition field="${tas_destination_number}" expression="^555\d{7}$">
<!-- Numéros mobiles nationaux -->
<action application="log" data="INFO Appel mobile national"/>
<action application="bridge" data="sofia/gateway/national_trunk/${tas_destination_number}"/>
</condition>
</extension>

<extension name="International">
<condition field="${tas_destination_number}" expression="^00\d+$">
<!-- Appels internationaux commençant par 00 -->
<action application="log" data="INFO Appel international"/>
<action application="bridge" data="sofia/gateway/intl_trunk/${tas_destination_number}"/>
</condition>
</extension>

Documentation Supplémentaire

Pour des détails complets sur chaque application :

Le wiki FreeSWITCH contient une documentation détaillée pour chaque application de plan de numérotation, y compris tous les paramètres et cas d'utilisation.

Variables du Plan de Numérotation

Variables définies par le TAS dans la logique du plan de numérotation XML :

Variables Courantes (Tous Types d'Appels)

Configuration Initiale :

  • destination_number - numéro de destination traduit
  • tas_destination_number - numéro de destination traduit
  • effective_caller_id_number - numéro source traduit

Appels d'Urgence

  • hangup_case - "none"
  • ims_private_identity - identité utilisateur privée
  • ims_public_identity - identité utilisateur publique
  • msisdn - numéro d'abonné (dépouillé de +)
  • imsi - IMSI de l'identité privée
  • ims_domain - domaine de l'identité privée

Appels MT (Terminés Mobiles)

  • ims_private_identity - identité utilisateur privée
  • ims_public_identity - identité utilisateur publique
  • msisdn - numéro d'abonné (dépouillé de +)
  • imsi - IMSI de l'identité privée
  • ims_domain - domaine de l'identité privée
  • call_forward_all_destination - destination CFA ou "none"
  • call_forward_not_reachable_destination - destination CFNRc
  • scscf_address - adresse S-CSCF ou "none"
  • scscf_domain - domaine S-CSCF ou "none"
  • no_reply_timer - délai d'attente pour aucune réponse
  • hangup_case - "none" ou "UNALLOCATED_NUMBER"
  • msrn - MSRN de PRN (si en itinérance) ou numéro transféré de SRI (si le transfert d'appel est actif)
  • tas_destination_number - Remplacement de la destination de routage (défini sur MSRN ou numéro transféré)

Appels MO (Originaire Mobile)

  • hangup_case - "none", "OUTGOING_CALL_BARRED", ou "UNALLOCATED_NUMBER"
  • ims_private_identity - identité utilisateur privée
  • ims_public_identity - identité utilisateur publique
  • msisdn - numéro d'abonné (dépouillé de +)
  • imsi - IMSI de l'identité privée
  • ims_domain - domaine de l'identité privée
  • allocated_time - temps alloué par l'OCS (si le chargement en ligne est activé)
  • cli_withheld - chaîne "true" ou "false"
  • on_net_status - chaîne "true" ou "false" (si la destination est on-net)
  • msrn - MSRN pour les abonnés en itinérance (si applicable)
  • tas_destination_number - Remplacement MSRN (si en itinérance)

Appels d'Urgence

Les appels d'urgence sont contrôlés par le paramètre de configuration emergency_call_codes et sont automatiquement détectés lors de l'autorisation de l'appel.

Configuration

Configurez les codes d'appel d'urgence dans votre fichier de configuration TAS :

Paramètres de configuration :

  • emergency_call_codes : Liste des numéros de services d'urgence à détecter
  • Codes courants : "911" (États-Unis), "112" (UE), "000" (AU), "999" (UK), "sos"
  • Ces codes sont vérifiés en plus des URN d'urgence SIP (par exemple, <urn:service:sos>)
  • Le système effectue une comparaison exacte par rapport au numéro de destination

Exemples de valeurs de configuration :

  • Déploiement aux États-Unis : ["911", "933"] - 911 pour les urgences, 933 pour les tests
  • Déploiement européen : ["112", "999"]
  • Déploiement australien : ["000", "106"] - 000 pour les urgences, 106 pour le relais de texte
  • Multi-région : ["911", "112", "000", "sos"]

Comment Fonctionne la Détection d'Urgence

Le système vérifie deux conditions :

  1. URN de Service d'Urgence SIP URI : Détecte <urn:service:sos> ou toute URI contenant "service:sos"
  2. Correspondance du Numéro de Destination : Compare Caller-Destination-Number avec les emergency_call_codes configurés

Si l'une ou l'autre condition est vraie, l'appel est classé comme urgence.

Flux de Traitement

Détails du Flux d'Appel :

  1. L'appel arrive au TAS
  2. Le module d'autorisation vérifie la destination par rapport aux motifs d'urgence
  3. Si une urgence est détectée :
    • Le type d'appel est défini sur :emergency
    • Le modèle mo_emergency_dialplan.xml est utilisé
    • L'autorisation OCS est généralement contournée
    • L'appel est routé vers la passerelle PSAP
  4. Les métriques sont enregistrées avec l'étiquette call_type: emergency

Routage du Plan de Numérotation

Définissez le routage des appels d'urgence dans priv/templates/mo_emergency_dialplan.xml. Ce modèle détermine comment les appels sont routés vers votre PSAP (Point d'Appel de Sécurité Publique) ou URI SIP en fonction des exigences de votre marché.

Exemple de plan de numérotation d'urgence :

<extension name="Emergency-SOS">
<condition field="${destination_number}" expression="^(911|912|913|sos)$">
<action application="log" data="ALERT Appel d'urgence de ${msisdn}"/>
<action application="answer" data=""/>
<action application="bridge" data="sofia/gateway/psap_gw/${destination_number}"/>
</condition>
</extension>

Meilleures Pratiques

  • Inclure toujours "sos" dans votre liste de codes d'urgence pour la compatibilité avec l'URN SIP
  • Inclure tous les numéros d'urgence locaux pour votre juridiction (par exemple, 911, 112, 000, 999)
  • Tester régulièrement le routage d'urgence à l'aide du Simulateur d'Appel
  • Contourner l'OCS pour les appels d'urgence afin de garantir qu'ils se connectent toujours (configuré via skipped_regex)
  • Configurer la passerelle PSAP avec haute disponibilité et redondance
  • Surveiller les métriques des appels d'urgence pour garantir la fiabilité du système

Appel Mobile Originaire On-Net à un Abonné Mobile Terminant On-Net

Lorsqu'un abonné appelle un autre abonné sur votre réseau (appel on-net), l'approche appropriée est de router l'appel MO à travers le TAS pour un traitement MT. Cela garantit que la partie appelée reçoit un traitement complet de l'appel MT, y compris le transfert d'appel, la messagerie vocale, le routage MSRN pour l'itinérance, et tous les autres services d'abonné.

Pourquoi Router MO vers MT ?

Sans traitement MT (routage direct) :

  • Les paramètres de transfert d'appel de la partie appelée sont ignorés
  • Pas de messagerie vocale en cas de non-réponse
  • Pas de routage MSRN pour les abonnés en itinérance
  • Logique de service d'abonné manquante

Avec traitement MT (routage vers TAS) :

  • Support complet du transfert d'appel (CFU, CFB, CFNRy, CFNRc)
  • Messagerie vocale en cas d'occupation/non-réponse
  • Routage MSRN pour les abonnés CS en itinérance
  • Expérience complète de service d'abonné
  • Suivi correct de l'état de l'appel pour les deux parties

Mise en Œuvre

Le plan de numérotation MO vérifie si la destination est on-net (desservie par votre TAS), et si c'est le cas, il route l'appel de retour vers le TAS lui-même. Le TAS reçoit cela comme un nouvel appel MT et le traite via le modèle mt_dialplan.xml.

Exemple de fragment de plan de numérotation :

<extension name="On-Net-Route">
<condition field="${on_net_status}" expression="true">
<action application="log" data="DEBUG Appel MO On-Net - Routage de retour dans le TAS" />

<!-- Nettoyer les en-têtes pour le routage interne -->
<action application="set" data="sip_copy_multipart=false"/>
<action application="set" data="sip_h_Request-Disposition=no-fork"/>

<!-- Route de retour vers le TAS (devenant un appel MT) -->
<action application="bridge"
data="{absolute_codec_string='AMR-WB,AMR,PCMA',originate_retries=1,originate_timeout=60,sip_invite_call_id=${sip_call_id}}sofia/internal/${tas_destination_number}@${sip_local_network_addr}" />
<action application="hangup" data="" />
</condition>
</extension>

Paramètres clés :

  • ${sip_local_network_addr} - Adresse IP du TAS (par exemple, 10.179.3.60)
  • ${tas_destination_number} - MSISDN de la partie appelée
  • sip_invite_call_id=${sip_call_id} - Préserve l'identifiant d'appel pour le suivi
  • sip_copy_multipart=false - Empêche la copie de messages multipart
  • sip_h_Request-Disposition=no-fork - Assure un traitement séquentiel

Flux d'Appel :

Configuration Importante :

  • L'adresse IP du TAS (par exemple, 10.179.3.60) doit être dans votre liste de configuration allowed_sbc_source_ips
  • Cela permet au TAS de recevoir des appels de lui-même pour un traitement MT
  • Sans cela, le TAS rejettera l'appel comme venant d'une source non autorisée

Utilisation de MSRN pour les Abonnés en Itinérance 2G/3G

Lorsqu'un abonné est en itinérance dans un réseau 2G/3G à commutation de circuit (CS), le TAS doit obtenir un MSRN (Numéro de Téléphone Mobile en Itinérance) pour router l'appel entrant vers l'emplacement actuel de l'abonné. Cette section explique comment fonctionne la récupération et le routage de MSRN.

Qu'est-ce que MSRN ?

MSRN (Numéro de Téléphone Mobile en Itinérance) est un numéro de routage temporaire attribué par le VLR (Registre de Localisation Visiteur) du réseau visité pour router les appels vers un abonné en itinérance. Il agit comme un numéro de destination temporaire qui pointe vers l'emplacement actuel de l'abonné dans le réseau CS.

Flux de Récupération de MSRN

Le TAS récupère les données MSRN via le protocole SS7 MAP (Mobile Application Part) en utilisant un processus en deux étapes :

Détails de Mise en Œuvre

Étape 1 : Envoyer les Informations de Routage (SRI)

Le TAS interroge le HLR via SS7 MAP pour obtenir des informations de routage pour l'abonné appelé.

Scénarios de Réponse SRI :

  1. MSRN directement dans SRI - Abonné en itinérance avec MSRN déjà disponible

    • La réponse inclut : MSISDN, GMSC, IMSI et MSRN
    • Exemple de MSRN : 61412345678 (format de numéro mobile australien)
  2. IMSI + numéro VLR - Abonné enregistré dans le réseau CS (nécessite PRN)

    • La réponse inclut : MSISDN, GMSC, IMSI et numéro MSC/VLR
    • Indique que l'abonné est dans le réseau CS mais que le MSRN doit être demandé
  3. IMSI seulement (pas de VLR) - Abonné non dans le réseau CS (uniquement IMS/PS)

    • La réponse inclut : MSISDN, GMSC, IMSI
    • Indique que l'abonné est enregistré uniquement dans IMS/4G, pas dans le réseau CS
  4. Transfert d'appel actif - SRI renvoie des informations de transfert

    • La réponse inclut la raison du transfert (inconditionnel, occupé, non-réponse, non joignable)
    • La réponse inclut le numéro transféré.

Étape 2 : Fournir le Numéro d'Itinérance (PRN) - Si Nécessaire

Si SRI renvoie IMSI + VLR mais pas de MSRN, le TAS envoie une demande PRN au VLR pour obtenir le MSRN.

Le VLR alloue un MSRN temporaire de son pool et le renvoie au TAS. Ce MSRN n'est valide que pour cette configuration d'appel spécifique.

Exemple de Réponse PRN : MSRN 61412345678

Variable de Plan de Numérotation : msrn

Une fois que le MSRN est récupéré via SS7 MAP, il est défini comme une variable de plan de numérotation qui peut être utilisée dans le plan de numérotation MT.

Variable : ${msrn}

  • Type : Chaîne (numéro E.164 sans le +)
  • Exemple : "61412345678" (format mobile australien)
  • Utilisation : Routage des appels vers des abonnés en itinérance CS
  • Défini par : Processus de récupération des données HLR pendant le traitement de l'appel MT

Routage vers MSRN dans mt_dialplan.xml

La variable MSRN est utilisée dans le modèle de plan de numérotation MT pour router les appels vers des abonnés en itinérance.

Logique du plan de numérotation :

  1. Vérifier MSRN : L'extension vérifie si la variable msrn est définie (contient des chiffres)
  2. Définir les paramètres de délai d'attente :
    • Délai d'attente de progression : 10 secondes pour recevoir des médias précoces
    • Délai d'attente de réponse du pont : Utilise le minuteur de non-réponse configuré de l'abonné
  3. Pont vers MSRN : Router l'appel vers MSRN via la passerelle CS
    • Utilise ignore_early_media=ring_ready pour un son de sonnerie cohérent
    • Préférence de codec : AMR (mobile), PCMA/PCMU (fixe)
    • Passerelle : sofia/gateway/CS_Gateway/+${msrn}
  4. Fallback en cas d'échec : Si le pont échoue, router vers la destination de transfert d'appel

Exemple de fragment de plan de numérotation :

<extension name="Route-to-CS-MSRN" continue="false">
<condition field="msrn" expression="^(\d+)$">
<!-- Configurer les délais d'attente -->
<action application="set" data="progress_timeout=10" />
<action application="set" data="bridge_answer_timeout=${no_reply_timer}" />

<!-- Pont vers MSRN via passerelle CS -->
<action application="bridge"
data="{ignore_early_media=ring_ready,absolute_codec_string='AMR,PCMA,PCMU',continue_on_fail=true,originate_retries=1,originate_timeout=60}sofia/gateway/CS_Gateway/+${msrn}" />

<!-- Fallback vers la messagerie vocale/destination de transfert d'appel -->
<action application="bridge"
data="sofia/internal/${call_forward_not_reachable_destination}@${local_ip_v4}" />
</condition>
</extension>

Points Clés

  1. MSRN est temporaire - Valide uniquement pour la durée de la configuration d'appel
  2. Réseau CS uniquement - MSRN est utilisé pour l'itinérance 2G/3G, pas pour l'itinérance VoLTE/IMS
  3. Priorité dans le flux MT - La vérification de MSRN se produit avant le routage IMS standard
  4. Fallback vers le transfert - Si le pont MSRN échoue, route vers la destination de transfert d'appel
  5. HLR remplace Sh - MSRN du HLR a la priorité sur les données d'abonné Sh

Configuration

L'intégration SS7 MAP doit être activée dans la configuration du TAS :

Paramètres requis :

  • enabled : Défini sur true pour activer les requêtes SS7 MAP
  • http_map_server_url_base : URL de votre passerelle SS7 MAP (par exemple, "http://10.1.1.100:5001")
  • gmsc : Numéro de la MSC passerelle pour les demandes SRI/PRN (par exemple, "61400000000")
  • timeout_ms : Délai d'attente de la requête en millisecondes (par défaut : 5000 ms)

Voir Documentation SS7 MAP pour des détails complets sur la configuration.


Utilisation des Données de Transfert d'Appel

Les paramètres de transfert d'appel déterminent comment les appels sont routés lorsque la destination principale est indisponible. Le TAS récupère les données de transfert d'appel de deux sources : l'interface Sh (HSS) et SS7 MAP (HLR), les données HLR ayant la priorité.

Types de Transfert d'Appel

Le système prend en charge quatre types de transfert d'appel :

Type de TransfertVariableQuand Actif
Transfert d'Appel Inconditionnel (CFU)call_forward_all_destinationTransfère toujours tous les appels immédiatement
Transfert d'Appel Occupé (CFB)call_forward_not_reachable_destinationLa ligne de l'abonné est occupée
Transfert d'Appel Sans Réponse (CFNRy)call_forward_not_reachable_destinationL'abonné ne répond pas dans le délai d'attente
Transfert d'Appel Non Joignable (CFNRc)call_forward_not_reachable_destinationL'abonné est non joignable/hors ligne

Sources de Données

1. Interface Sh (HSS)

Configuration statique stockée dans le profil d'abonné HSS.

Le TAS récupère les paramètres de transfert d'appel du HSS via l'interface Sh pendant le traitement de l'appel. Ce sont les paramètres provisionnés/par défaut pour l'abonné.

Exemple de données récupérées :

  • call_forward_all_destination : destination CFU (par exemple, "61412345678")
  • call_forward_not_reachable_destination : destination CFB/CFNRy/CFNRc (par exemple, "61487654321")
  • no_reply_timer : secondes avant que CFNRy ne se déclenche (par exemple, "20")

2. SS7 MAP (HLR)

Données en temps réel du HLR, qui peuvent différer de HSS si l'abonné a modifié les paramètres via des codes USSD/MMI (par exemple, en composant *21* codes).

Le TAS interroge le HLR via SS7 MAP pendant la configuration de l'appel pour obtenir les paramètres de transfert actifs/courants.

La réponse de transfert HLR inclut :

  • forwarded_to_number : Le numéro de destination pour le transfert (par exemple, "61412345678")
  • reason : Type de transfert (inconditionnel, occupé, sans réponse, non joignable)
  • notification flags : Indique s'il faut notifier la partie appelante, la partie transférée, etc.

Mapping vers les variables de plan de numérotation :

  • Si la raison est inconditionnelle → Définit call_forward_all_destination
  • Si la raison est occupée, sans réponse ou non joignable → Définit call_forward_not_reachable_destination

Priorité de Fusion des Variables

Les données HLR remplacent les données Sh lorsqu'elles sont toutes deux présentes.

Le TAS récupère les données d'abonné des deux sources pendant le traitement de l'appel MT :

  1. D'abord, récupère la configuration statique du HSS via l'interface Sh
  2. Ensuite, interroge le HLR via SS7 MAP pour les paramètres en temps réel
  3. Fusionne les données, les valeurs HLR ayant la priorité sur les valeurs Sh

Cela garantit que les modifications récentes de l'abonné (via des codes USSD) sont respectées même si le HSS n'a pas encore été mis à jour.

Variables de Plan de Numérotation

Disponibles dans les appels MT :

VariableTypeExempleDescription
call_forward_all_destinationChaîne"61412345678"Numéro de destination CFU
call_forward_not_reachable_destinationChaîne"61487654321"Destination CFB/CFNRy/CFNRc
no_reply_timerChaîne"20"Délai d'attente en secondes pour CFNRy

Valeurs par défaut :

  • Si non configuré : "none" (chaîne)
  • Vérifier la présence : Utiliser regex ^(?!none$).* pour correspondre à toute valeur sauf "none"

Transfert d'Appel dans mt_dialplan.xml

Exemple 1 : Transfert d'Appel Inconditionnel (CFU)

Routage de TOUS les appels entrants immédiatement vers la destination de transfert. La destination de transfert est généralement un numéro hors réseau, donc elle utilise une passerelle externe.

Passerelle utilisée : sofia/gateway/ExternalSIPGateway (votre passerelle PSTN/interconnexion)

Exemple de modèle :

<extension name="Check-Call-Forward-All">
<condition field="${call_forward_all_destination}" expression="^(?!none$).*">
<action application="log" data="INFO Transfert d'Appel Tout Défini pour rediriger vers ${call_forward_all_destination}" />

<!-- Définir l'en-tête History-Info pour le transfert d'appel -->
<action application="set" data="sip_h_History-Info=<sip:${destination_number}@${ims_domain}>;index=1.1" />

<!-- Marquer l'identifiant d'appel pour indiquer le type de transfert d'appel -->
<action application="set" data="sip_call_id=${sip_call_id};CALL_FORWARD_UNCONDITIONAL" />

<!-- Pont vers la destination de transfert hors réseau -->
<action application="bridge"
data="{absolute_codec_string='AMR-WB,AMR,PCMA,PCMU',originate_retries=1,originate_timeout=60}sofia/gateway/ExternalSIPGateway/+${call_forward_all_destination}" />
</condition>
</extension>

Points clés :

  • Utilise une passerelle externe car le transfert est généralement vers un numéro hors réseau
  • Marque l'identifiant d'appel avec ;CALL_FORWARD_UNCONDITIONAL pour le suivi
  • Définit l'en-tête History-Info pour identifier le numéro appelé d'origine
  • Exemple : L'abonné 61412345678 a CFU vers 61487654321 - tous les appels sont immédiatement transférés

Exemple 2 : Transfert d'Appel Sans Réponse/Non Joignable

Utilisé comme solution de secours lorsque le pont vers la destination primaire échoue (l'abonné ne répond pas, est occupé ou non joignable).

Exemple de fragment de plan de numérotation :

<!-- Après que le pont vers MSRN ou IMS échoue... -->
<action application="log" data="INFO Échec du pont d'appel - Routage vers la Destination de Transfert d'Appel Sans Réponse" />

<!-- Définir History-Info pour indiquer le transfert -->
<action application="set" data="sip_h_History-Info=<sip:${destination_number}@${ims_domain}>;index=1.1" />

<!-- Route vers la destination de transfert -->
<action application="bridge"
data="{absolute_codec_string='AMR,PCMU,PCMA',originate_timeout=65}sofia/gateway/ExternalSIPGateway/${call_forward_not_reachable_destination}" />

Scénario d'exemple :

  • L'abonné 61412345678 a CFNRy vers le numéro de messagerie vocale 61487654321
  • Un appel entrant tente d'atteindre l'abonné
  • Pas de réponse après 20 secondes (no_reply_timer)
  • L'appel est transféré vers 61487654321 avec l'en-tête History-Info préservant la destination d'origine

En-tête History-Info

L'en-tête SIP History-Info suit le transfert d'appel :

<action application="set" data="sip_h_History-Info=<sip:${destination_number}@${ims_domain}>;index=1.1" />

But :

  • Indique que l'appel était à l'origine pour ${destination_number}
  • Permet aux systèmes en aval d'identifier les appels transférés
  • Utilisé par les systèmes de messagerie vocale pour déposer dans la bonne boîte aux lettres

Exemple dans le routage de la messagerie vocale :

<extension name="Voicemail Route" continue="false">
<condition field="${tas_destination_number}" expression="^(555121|555122)$">
<!-- Extraire le numéro de téléphone de l'History Info -->
<action application="set" data="history_info_value=${sip_i_history_info}"/>
<action application="log" data="DEBUG Numéro de Dépôt de Messagerie Vocale pour ${history_info_value}" />

<!-- Déposer la messagerie vocale au parti appelé d'origine, pas au numéro de messagerie vocale -->
<action application="voicemail" data="default default ${history_info_value}"/>
</condition>
</extension>

Comment cela fonctionne :

  • Numéros de service de messagerie vocale : 555121, 555122 (codes courts génériques)
  • Lorsque l'appel est transféré vers la messagerie vocale, l'History-Info contient la destination d'origine
  • Le système de messagerie vocale extrait le numéro d'origine de l'en-tête History-Info
  • La messagerie vocale est déposée dans la boîte aux lettres du parti appelé d'origine, pas du numéro de service de messagerie vocale

Meilleures Pratiques

  1. Vérifiez toujours "none" - Utilisez regex ^(?!none$).* pour éviter de router vers la chaîne littérale "none"
  2. Définir History-Info - Toujours définir lors du transfert pour un suivi approprié des appels
  3. Utiliser continue_on_fail - Permettre le fallback vers le transfert si la route primaire échoue
  4. Ajuster le format CLI - Formatage de préfixe national vs international (voir section CLI)
  5. Tester les boucles de transfert - Assurez-vous que les destinations de transfert ne créent pas de boucles de routage

Gestion de l'Identité de l'Appelant (CLI)

Le TAS gère la présentation et le formatage de l'Identification de la Ligne Appelante (CLI) tout au long du flux d'appel, en traitant les demandes de confidentialité, la normalisation des préfixes et les exigences de formatage spécifiques au réseau.

Variables CLI

Variables CLI de base dans les plans de numérotation :

VariableUtilisationExemple
msisdnNuméro de l'abonné (sans +)"61412345678"
effective_caller_id_numberNuméro de l'appelant affiché"+61412345678" ou "anonymous"
effective_caller_id_nameNom de l'appelant affiché"+61412345678" ou "anonymous"
origination_caller_id_numberCLI pour le volet sortant"+61412345678"
caller_id_numberVariable CLI standard FreeSWITCH"+61412345678"
sip_from_userPartie utilisateur de l'en-tête SIP From"0412345678" ou "+61412345678"
cli_withheldDrapeau de confidentialité"true" ou "false" (chaîne)
origination_privacyParamètre de confidentialité"hide_number"

Confidentialité CLI (Masqué/Anonyme)

Méthodes de Détection

Le TAS détecte les demandes de confidentialité CLI par trois méthodes :

1. Préfixe Bloqué dans le Numéro Composé

L'abonné compose un préfixe avant le numéro de destination pour bloquer son ID d'appel.

Préfixes courants :

  • *67 - Standard nord-américain
  • #31# - Standard européen/GSM
  • 1831 - Format alternatif

Le TAS vérifie si le numéro composé commence par l'un des préfixes CLI bloqués configurés. Si détecté, la variable cli_withheld est définie sur "true".

Exemple : L'abonné compose *67555 1234 - le préfixe *67 est détecté et supprimé, l'appel se poursuit vers 5551234 avec CLI masqué.

2. Anonyme dans l'En-tête From

L'équipement utilisateur (UE) définit le nom de l'appelant sur "anonyme" dans l'en-tête SIP From.

Le TAS vérifie le champ Caller-Orig-Caller-ID-Name (insensible à la casse) pour la chaîne "anonyme". Si trouvé, cli_withheld est défini sur "true".

3. En-têtes de Confidentialité SIP

Le S-CSCF peut définir des en-têtes Privacy: id dans le SIP INVITE, qui sont honorés par le plan de numérotation.

Mise en Œuvre du Plan de Numérotation

Le plan de numérotation vérifie la variable cli_withheld et définit toutes les variables liées à la CLI en conséquence.

Exemple de fragment de plan de numérotation :

<extension name="Manage-Caller-ID" continue="true">
<condition field="${cli_withheld}" expression="true">
<!-- CLI est masqué - défini sur anonyme -->
<action application="log" data="DEBUG Détection de CLI masqué" />
<action application="set" data="effective_caller_id_name=anonymous" />
<action application="set" data="effective_caller_id_number=anonymous" />
<action application="set" data="origination_caller_id_number=anonymous" />
<action application="set" data="origination_privacy=hide_number" />

<!-- CLI n'est PAS masqué - utiliser le MSISDN normal -->
<anti-action application="log" data="DEBUG CLI est normal (non masqué)" />
<anti-action application="set" data="effective_caller_id_number=${msisdn}" />
</condition>
</extension>

Remarque : Cette extension utilise continue="true" afin que le traitement de l'appel continue vers les extensions de routage même après que la CLI soit définie.

Format CLI : National vs International

Différentes destinations peuvent nécessiter différents formats de CLI en fonction des exigences de votre réseau.

Exemple : Format National

Pour les appels nationaux dans votre pays, vous devrez peut-être présenter la CLI sans le code du pays.

Exemple de fragment de plan de numérotation (réseau mobile australien) :

<extension name="Outgoing-Call-CLI-National" continue="true">
<condition field="${msisdn}" expression="^61(.*)$">
<action application="log" data="Définir la source CLI sur $1 pour national" />
<action application="set" data="effective_caller_id_number=$1"/> <!-- 0412345678 -->
<action application="set" data="effective_caller_id_name=$1"/>
<action application="set" data="sip_from_user=$1"/>
<action application="set" data="sip_cid_type=pid"/>
</condition>
</extension>

Comment cela fonctionne :

  • Regex ^61(.*)$ capture tout après le code du pays 61
  • Entrée : msisdn="61412345678" → Sortie : $1="412345678" ou "0412345678"
  • Présente la CLI au format national pour les appels domestiques

Exemple : Format International

Pour les appels internationaux, présentez la CLI au format E.164 complet avec le préfixe +.

Exemple de fragment de plan de numérotation :

<extension name="Outgoing-Call-CLI-International" continue="true">
<condition field="${tas_destination_number}" expression="^61(.*)$">
<action application="log" data="L'appel est national" />

<!-- L'anti-action s'exécute lorsque la destination n'est PAS nationale -->
<anti-action application="log" data="Définir la source CLI pour international" />
<anti-action application="set" data="effective_caller_id_number=+${msisdn}"/> <!-- +61412345678 -->
<anti-action application="set" data="effective_caller_id_name=+${msisdn}"/>
<anti-action application="set" data="sip_from_user=+${msisdn}"/>
<anti-action application="set" data="sip_cid_type=pid"/>
</condition>
</extension>

Comment cela fonctionne :

  • La condition vérifie si la destination commence par le préfixe national (par exemple, 61 pour l'Australie)
  • <anti-action> s'exécute lorsque la condition ne correspond PAS (appel international)
  • Ajoute le préfixe + pour un format E.164 complet lors des appels internationaux

Format CLI pour le Transfert d'Appel

Lors du routage vers des destinations de transfert d'appel, vous devrez peut-être ajuster le format CLI en fonction de que ce soit pour des numéros on-net ou off-net.

Exemple : Ajustement du préfixe CLI pour le transfert

<!-- Ajuster le format CLI si nécessaire pour la destination de transfert -->
<action application="set" data="effective_caller_id_number=${effective_caller_id_number:3}"/>
<action application="set" data="effective_caller_id_name=${effective_caller_id_name:3}"/>

Découpage de Chaîne : ${variable:N} supprime les N premiers caractères

  • Entrée : effective_caller_id_number="+61412345678" avec :3 → Sortie : "412345678"
  • Entrée : effective_caller_id_number="+61412345678" avec :1 → Sortie : "61412345678"

Cas d'utilisation :

  • Supprimer + pour le transfert national : Utiliser :1
  • Supprimer le code du pays pour le format local : Utiliser l'offset approprié (:3 pour +61, :2 pour +1, etc.)

SIP P-Asserted-Identity (PAI)

Le paramètre sip_cid_type=pid contrôle comment l'identité de l'appelant est présentée :

<action application="set" data="sip_cid_type=pid"/>

Effet :

  • Définit l'en-tête SIP P-Asserted-Identity avec les informations de l'appelant
  • Utilisé pour l'assertion de l'identité de l'appelant dans un réseau de confiance
  • Standard pour les réseaux IMS

Suppression des En-têtes Propriétaires

Pour éviter de divulguer des informations internes du réseau, les plans de numérotation doivent supprimer les en-têtes propriétaires ou internes avant de router les appels hors réseau.

Exemple : Nettoyage des en-têtes avant le routage externe

<action application="set" data="sip_copy_multipart=false"/>
<action application="set" data="sip_copy_custom_headers=false"/>
<action application="unset" data="sip_h_P-Internal-Correlation-ID"/>
<action application="unset" data="sip_h_P-Access-Network-Info"/>
<!-- Ajouter d'autres en-têtes spécifiques au fournisseur ou internes si nécessaire -->

But :

  • Empêche les données de routage internes d'atteindre les réseaux externes
  • Supprime les en-têtes propriétaires spécifiques au fournisseur
  • Meilleure pratique en matière de confidentialité et de sécurité
  • Réduit la taille des messages SIP

En-têtes courants à supprimer :

  • Identifiants de corrélation/suivi internes
  • Informations sur le réseau d'accès (peut révéler la topologie du réseau)
  • En-têtes P spécifiques au fournisseur
  • En-têtes d'application personnalisés destinés à un usage interne uniquement

Meilleures Pratiques

  1. Utilisez continue="true" pour les extensions CLI - Permet de multiples règles de formatage CLI
  2. Définissez sip_cid_type=pid - Requis pour la conformité au réseau IMS
  3. Testez la masquage de CLI - Vérifiez que les préfixes *67 et #31# fonctionnent
  4. Formatez selon la destination - Formatage CLI national vs international
  5. Supprimez les en-têtes propriétaires - Empêcher les fuites de données internes
  6. Gérez anonymement avec soin - Le routage et l'affichage doivent fonctionner avec une CLI anonyme

Pont vers les Passerelles

Le TAS établit des ponts d'appels vers des passerelles externes (noyau IMS, PSTN, etc.) en utilisant l'application bridge de FreeSWITCH avec des paramètres soigneusement configurés pour la négociation de codec, la gestion des délais d'attente et la logique de réessai.

Configuration de la Passerelle

Les passerelles sont configurées en tant que trunks SIP vers des systèmes externes. Le TAS utilise une seule interface SIP pour tout le trafic, avec différentes passerelles définies pour différentes destinations.

Exemple de configuration de passerelle :

<gateway name="CS_Gateway">
<param name="proxy" value="10.1.1.100:5060"/>
<param name="register" value="false"/>
<param name="caller-id-in-from" value="true"/>
<param name="extension-in-contact" value="true"/>
</gateway>

Voir Guide de Configuration pour la configuration complète de la passerelle.

Syntaxe de Pont

Les appels sont établis vers les passerelles en utilisant la syntaxe suivante :

Syntaxe de base :

<action application="bridge" data="sofia/gateway/NOM_PASSERELLE/NUMERO_DESTINATION" />

Avec paramètres :

<action application="bridge" data="{param1=value1,param2=value2}sofia/gateway/NOM_PASSERELLE/NUMERO_DESTINATION" />

NOM_PASSERELLE est le nom de la passerelle définie dans votre configuration (par exemple, IMS_Core, PSTN_Primary, International_Gateway).

Paramètres de Pont

Sélection de Codec

absolute_codec_string - Liste de codecs priorisée pour la négociation :

<action application="bridge" data="{absolute_codec_string='AMR,PCMA,PCMU'}sofia/gateway/IMS_Gateway/+${msisdn}" />

Ordre de priorité des codecs :

  1. AMR (Adaptive Multi-Rate) - Optimisé pour mobile, préféré pour cellulaire
  2. PCMA (G.711 a-law) - Standard fixe en Europe/international
  3. PCMU (G.711 μ-law) - Standard fixe en Amérique du Nord

Utilisation du modèle : priv/templates/mt_dialplan.xml:80, mo_dialplan.xml:124, mo_dialplan.xml:202

Configuration des Délais d'Attente

originate_timeout - Nombre maximum de secondes à attendre pour une réponse (inclut la sonnerie) :

<action application="set" data="originate_timeout=60"/>
<action application="bridge" data="{originate_timeout=60}sofia/gateway/CS_Gateway/+${msisdn}" />

progress_timeout - Secondes à attendre pour 180/183 (média précoce/sonnerie) :

<action application="set" data="progress_timeout=10" />

bridge_answer_timeout - Secondes à attendre pour 200 OK après le début de la sonnerie :

<action application="set" data="bridge_answer_timeout=${no_reply_timer}" />

leg_progress_timeout - Délai d'attente de progression par voie :

<action application="set" data="leg_progress_timeout=${no_reply_timer}" />

Exemple de modèle : priv/templates/mt_dialplan.xml:73-76

<action application="set" data="progress_timeout=10" />
<!-- Combien de temps attendons-nous entre l'INVITE et un 200 OK (y compris RINGING) -->
<action application="set" data="bridge_answer_timeout=${no_reply_timer}" />
<action application="set" data="leg_progress_timeout=${no_reply_timer}" />

Variable : ${no_reply_timer} provient des données de l'abonné (typiquement 20-30 secondes)

Gestion des Réessais et des Échecs

originate_retries - Nombre de tentatives de réessai :

<action application="bridge" data="{originate_retries=1}sofia/gateway/CS_Gateway/+${msisdn}" />

continue_on_fail - Continuer l'exécution du plan de numérotation après un échec de pont :

<action application="set" data="continue_on_fail=true" />
<action application="bridge" data="{continue_on_fail=true}sofia/gateway/CS_Gateway/+${msisdn}" />
<!-- Les actions suivantes s'exécutent si le pont échoue -->
<action application="log" data="INFO Le pont a échoué - routage vers la messagerie vocale" />

hangup_after_bridge - Raccrocher A-leg lorsque B-leg raccroche :

<action application="set" data="hangup_after_bridge=true"/>

Gestion des Médias Précoces

ignore_early_media - Contrôler le comportement des médias précoces :

<action application="set" data="ignore_early_media=ring_ready" />
<action application="bridge" data="{ignore_early_media=ring_ready}sofia/gateway/CS_Gateway/+${msisdn}" />

Options :

  • ring_ready - Générer un son de sonnerie local, ignorer le média précoce distant
  • true - Ignorer complètement le média précoce
  • false (par défaut) - Passer le média précoce (annonces, tonalités)

Pourquoi utiliser ring_ready ? - Empêche l'appelant d'entendre des annonces ou des tonalités du réseau distant

Exemple de modèle : priv/templates/mt_dialplan.xml:78-79

<action application="set" data="ignore_early_media=ring_ready" />
<action application="bridge" data="{ignore_early_media=ring_ready,...}sofia/gateway/CS_Gateway/+${msrn}" />

Gestion des appelants on-net vs off-net :

<extension name="Route-to-IMS-Sub-Early-Media" continue="true">
<condition field="${on_net_caller}" expression="true">
<!-- Appelant on-net - utiliser ring_ready -->
<action application="log" data="INFO Appelant on-net ${effective_caller_id_number} - utilisant ignore_early_media=ring_ready"/>
<action application="set" data="ignore_early_media=ring_ready"/>

<!-- Appelant off-net - fournir un son de sonnerie instantané -->
<anti-action application="log" data="INFO Appelant off-net ${effective_caller_id_number} - définition d'un son de sonnerie instantané"/>
<anti-action application="set" data="instant_ringback=true"/>
<anti-action application="set" data="ringback=${fr-ring}"/>
<anti-action application="set" data="transfer_ringback=${fr-ring}"/>
</condition>
</extension>

Remarque : La variable ${on_net_caller} est définie en fonction du plan de numérotation de votre réseau d'abonnés. Vous pouvez également utiliser des motifs regex pour correspondre à vos plages de numéros spécifiques.

Paramètres d'Identité de l'Appelant

sip_cid_type=pid - Utiliser P-Asserted-Identity pour l'identité de l'appelant :

<action application="set" data="sip_cid_type=pid" />
<action application="bridge" data="{sip_cid_type=pid}sofia/gateway/CS_Gateway/+${msisdn}" />

Modèles de Pont Courants

Modèle 1 : Routage vers un Abonné IMS via Domaine IMS

Routage d'un appel MT vers un abonné IMS en l'envoyant vers le domaine IMS (S-CSCF résoudra et routera).

Exemple de modèle :

<extension name="Route-to-IMS-Sub" continue="false">
<condition field="destination_number" expression="^(.*)$">
<action application="set" data="continue_on_fail=true" />
<action application="set" data="hangup_after_bridge=true"/>
<action application="set" data="progress_timeout=10" />

<!-- Combien de temps attendons-nous entre l'INVITE et un 200 OK (y compris RINGING) -->
<action application="set" data="bridge_answer_timeout=${no_reply_timer}" />
<action application="set" data="leg_progress_timeout=${no_reply_timer}" />

<!-- Envoyer l'appel au domaine IMS (S-CSCF résout) -->
<action application="set" data="ignore_early_media=ring_ready" />
<action application="set" data="sip_cid_type=pid" />

<action application="bridge"
data="{absolute_codec_string='AMR-WB,AMR,PCMA,PCMU',ignore_early_media=ring_ready,continue_on_fail=true,sip_cid_type=pid,originate_retries=1,originate_timeout=${no_reply_timer},sip_invite_call_id=${sip_call_id}}sofia/internal/${msisdn}@${ims_domain}" />

<!-- Fallback vers le transfert d'appel si le pont échoue -->
<action application="log" data="INFO Échec du pont d'appel - Routage vers la Destination de Transfert d'Appel Sans Réponse" />
<action application="set" data="sip_h_History-Info=<sip:${destination_number}@${ims_domain}>;index=1.1" />
<action application="set" data="sip_h_Diversion=<sip:${destination_number:2}@${ims_domain}>;reason=busy" />

<!-- Routage vers la passerelle hors réseau pour le transfert d'appel -->
<action application="bridge"
data="{absolute_codec_string='AMR-WB,AMR,PCMU,PCMA',originate_timeout=65,originate_retries=0}sofia/gateway/ExternalSIPGateway/${call_forward_not_reachable_destination}" />
</condition>
</extension>

Points clés :

  • Routage vers ${msisdn}@${ims_domain} (par exemple, 5551234567@ims.mnc380.mcc313.3gppnetwork.org)
  • Le noyau IMS (S-CSCF/I-CSCF) gère le routage final vers l'abonné
  • ignore_early_media=ring_ready fournit un son de sonnerie cohérent
  • En cas d'échec, utilise la passerelle externe pour le transfert d'appel hors réseau
  • Définit les en-têtes History-Info et Diversion pour le suivi du transfert d'appel

Modèle 2 : Routage vers MSRN (Itinérance CS)

Routage vers un abonné en itinérance via le réseau CS :

Modèle : priv/templates/mt_dialplan.xml:67-80

<extension name="Route-to-CS-MSRN" continue="false">
<condition field="msrn" expression="^(\d+)$">
<action application="set" data="continue_on_fail=true" />
<action application="set" data="hangup_after_bridge=true"/>
<action application="set" data="progress_timeout=10" />
<action application="set" data="bridge_answer_timeout=${no_reply_timer}" />
<action application="set" data="leg_progress_timeout=${no_reply_timer}" />

<!-- Envoyer l'appel vers MSRN via Passerelle -->
<action application="set" data="ignore_early_media=ring_ready" />
<action application="set" data="sip_cid_type=pid" />
<action application="bridge"
data="{ignore_early_media=ring_ready,absolute_codec_string='AMR,PCMA,PCMU',continue_on_fail=true,sip_cid_type=pid,originate_retries=1,originate_timeout=60}sofia/gateway/CS_Gateway/+${msrn}" />
</condition>
</extension>

Modèle 3 : Routage On-Net (MO vers MT via TAS)

Lorsqu'un abonné appelle un autre abonné on-net, l'appel doit être routé de retour vers le TAS pour un traitement MT complet. Ce modèle est critique pour garantir que les appels on-net reçoivent le même traitement de service que les appels MT externes.

Pourquoi ce modèle est requis :

Sans routage de retour vers le TAS, les appels on-net contournent complètement le traitement MT, ce qui signifie :

  • Les paramètres de transfert d'appel ne seraient pas respectés
  • Pas de messagerie vocale en cas de non-réponse
  • Pas de routage MSRN pour les abonnés en itinérance
  • La logique de service d'abonné serait ignorée
  • Le suivi des appels et les CDR seraient incomplets

En routant l'appel MO de retour vers le TAS en tant que nouvel appel MT, l'abonné de destination bénéficie d'un traitement complet de service.

Exemple de modèle :

<extension name="On-Net-Route">
<condition field="${on_net_status}" expression="true">
<action application="log" data="DEBUG Appel MO On-Net - Routage de retour dans le TAS" />

<!-- Nettoyer les en-têtes pour le routage interne -->
<action application="set" data="sip_copy_multipart=false"/>
<action application="set" data="sip_h_Request-Disposition=no-fork"/>

<!-- Route de retour vers le TAS (devenant un appel MT) -->
<action application="bridge"
data="{absolute_codec_string='AMR-WB,AMR,PCMA,PCMU',originate_retries=1,originate_timeout=60,sip_invite_call_id=${sip_call_id}}sofia/internal/${tas_destination_number}@${sip_local_network_addr}" />
<action application="hangup" data="" />
</condition>
</extension>

Comment cela fonctionne :

  1. L'appel MO Arrive : L'abonné A appelle l'abonné B (les deux on-net)
  2. Vérifier le Statut On-Net : Le TAS détermine que la destination est on-net via la variable ${on_net_status}
  3. Route vers le TAS : Pont vers sofia/internal/${tas_destination_number}@${sip_local_network_addr}
    • Utilise l'adresse IP du TAS comme destination
    • Préserve l'identifiant d'appel pour le suivi
  4. Traitement MT : Le TAS reçoit l'appel comme un nouvel appel MT et traite mt_dialplan.xml
    • Vérifie les paramètres de transfert d'appel (CFU, CFB, CFNR