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
- 📋 README Principal - Vue d'ensemble et démarrage rapide
- 🔧 Guide de Configuration - Configuration des trunks SIP et des passerelles
- 🔧 Guide des Opérations - Tests de plan de numérotation et visualiseur de modèles
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
- 📊 Métriques du Plan de Numérotation - Métriques spécifiques au plan de numérotation et surveillance
- 📈 Référence des Métriques - Métriques générales du système
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 Mobilemo_emergency_dialplan.xml- Plan de Numérotation des Appels d'Urgence Originaire Mobilemt_dialplan.xml- Plan de Numérotation des Appels Terminés Mobiles
Vous pouvez visualiser les Plans de Numérotation depuis l'interface Web.

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 :
- Documentation du Plan de Numérotation FreeSWITCH : https://freeswitch.org/confluence/display/FREESWITCH/Dialplan
- FreeSWITCH mod_dptools : https://freeswitch.org/confluence/display/FREESWITCH/mod_dptools (référence complète des applications)
- Référence des Expressions Régulières : https://freeswitch.org/confluence/display/FREESWITCH/Regular+Expression
- Variables de Canal : https://freeswitch.org/confluence/display/FREESWITCH/Channel+Variables
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 traduittas_destination_number- numéro de destination traduiteffective_caller_id_number- numéro source traduit
Appels d'Urgence
hangup_case- "none"ims_private_identity- identité utilisateur privéeims_public_identity- identité utilisateur publiquemsisdn- numéro d'abonné (dépouillé de +)imsi- IMSI de l'identité privéeims_domain- domaine de l'identité privée
Appels MT (Terminés Mobiles)
ims_private_identity- identité utilisateur privéeims_public_identity- identité utilisateur publiquemsisdn- numéro d'abonné (dépouillé de +)imsi- IMSI de l'identité privéeims_domain- domaine de l'identité privéecall_forward_all_destination- destination CFA ou "none"call_forward_not_reachable_destination- destination CFNRcscscf_address- adresse S-CSCF ou "none"scscf_domain- domaine S-CSCF ou "none"no_reply_timer- délai d'attente pour aucune réponsehangup_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éeims_public_identity- identité utilisateur publiquemsisdn- numéro d'abonné (dépouillé de +)imsi- IMSI de l'identité privéeims_domain- domaine de l'identité privéeallocated_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 :
- URN de Service d'Urgence SIP URI : Détecte
<urn:service:sos>ou toute URI contenant "service:sos" - Correspondance du Numéro de Destination : Compare
Caller-Destination-Numberavec lesemergency_call_codesconfiguré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 :
- L'appel arrive au TAS
- Le module d'autorisation vérifie la destination par rapport aux motifs d'urgence
- Si une urgence est détectée :
- Le type d'appel est défini sur
:emergency - Le modèle
mo_emergency_dialplan.xmlest utilisé - L'autorisation OCS est généralement contournée
- L'appel est routé vers la passerelle PSAP
- Le type d'appel est défini sur
- 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éesip_invite_call_id=${sip_call_id}- Préserve l'identifiant d'appel pour le suivisip_copy_multipart=false- Empêche la copie de messages multipartsip_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 configurationallowed_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 :
-
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)
-
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é
-
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
-
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 :
- Vérifier MSRN : L'extension vérifie si la variable
msrnest définie (contient des chiffres) - 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é
- Pont vers MSRN : Router l'appel vers MSRN via la passerelle CS
- Utilise
ignore_early_media=ring_readypour un son de sonnerie cohérent - Préférence de codec : AMR (mobile), PCMA/PCMU (fixe)
- Passerelle :
sofia/gateway/CS_Gateway/+${msrn}
- Utilise
- 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
- MSRN est temporaire - Valide uniquement pour la durée de la configuration d'appel
- Réseau CS uniquement - MSRN est utilisé pour l'itinérance 2G/3G, pas pour l'itinérance VoLTE/IMS
- Priorité dans le flux MT - La vérification de MSRN se produit avant le routage IMS standard
- Fallback vers le transfert - Si le pont MSRN échoue, route vers la destination de transfert d'appel
- 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
truepour 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 Transfert | Variable | Quand Actif |
|---|---|---|
| Transfert d'Appel Inconditionnel (CFU) | call_forward_all_destination | Transfère toujours tous les appels immédiatement |
| Transfert d'Appel Occupé (CFB) | call_forward_not_reachable_destination | La ligne de l'abonné est occupée |
| Transfert d'Appel Sans Réponse (CFNRy) | call_forward_not_reachable_destination | L'abonné ne répond pas dans le délai d'attente |
| Transfert d'Appel Non Joignable (CFNRc) | call_forward_not_reachable_destination | L'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 :
- D'abord, récupère la configuration statique du HSS via l'interface Sh
- Ensuite, interroge le HLR via SS7 MAP pour les paramètres en temps réel
- 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 :
| Variable | Type | Exemple | Description |
|---|---|---|---|
call_forward_all_destination | Chaîne | "61412345678" | Numéro de destination CFU |
call_forward_not_reachable_destination | Chaîne | "61487654321" | Destination CFB/CFNRy/CFNRc |
no_reply_timer | Chaî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_UNCONDITIONALpour le suivi - Définit l'en-tête
History-Infopour identifier le numéro appelé d'origine - Exemple : L'abonné
61412345678a CFU vers61487654321- 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é
61412345678a CFNRy vers le numéro de messagerie vocale61487654321 - 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
61487654321avec 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
- Vérifiez toujours "none" - Utilisez regex
^(?!none$).*pour éviter de router vers la chaîne littérale "none" - Définir History-Info - Toujours définir lors du transfert pour un suivi approprié des appels
- Utiliser continue_on_fail - Permettre le fallback vers le transfert si la route primaire échoue
- Ajuster le format CLI - Formatage de préfixe national vs international (voir section CLI)
- 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 :
| Variable | Utilisation | Exemple |
|---|---|---|
msisdn | Numéro de l'abonné (sans +) | "61412345678" |
effective_caller_id_number | Numéro de l'appelant affiché | "+61412345678" ou "anonymous" |
effective_caller_id_name | Nom de l'appelant affiché | "+61412345678" ou "anonymous" |
origination_caller_id_number | CLI pour le volet sortant | "+61412345678" |
caller_id_number | Variable CLI standard FreeSWITCH | "+61412345678" |
sip_from_user | Partie utilisateur de l'en-tête SIP From | "0412345678" ou "+61412345678" |
cli_withheld | Drapeau de confidentialité | "true" ou "false" (chaîne) |
origination_privacy | Paramè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/GSM1831- 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 pays61 - 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,
61pour 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é (
:3pour+61,:2pour+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-Identityavec 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
- Utilisez
continue="true"pour les extensions CLI - Permet de multiples règles de formatage CLI - Définissez
sip_cid_type=pid- Requis pour la conformité au réseau IMS - Testez la masquage de CLI - Vérifiez que les préfixes
*67et#31#fonctionnent - Formatez selon la destination - Formatage CLI national vs international
- Supprimez les en-têtes propriétaires - Empêcher les fuites de données internes
- 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" />
Où 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 :
- AMR (Adaptive Multi-Rate) - Optimisé pour mobile, préféré pour cellulaire
- PCMA (G.711 a-law) - Standard fixe en Europe/international
- 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 distanttrue- Ignorer complètement le média précocefalse(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_readyfournit 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-InfoetDiversionpour 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 :
- L'appel MO Arrive : L'abonné A appelle l'abonné B (les deux on-net)
- Vérifier le Statut On-Net : Le TAS détermine que la destination est on-net via la variable
${on_net_status} - 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
- 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