Manipulation Conditionnelle des Appels

Bonjour !

Dans nos leçons précédentes, nous avons exploré le "quoi" et le "comment" de la manipulation SIP. Vous avez appris à construire des règles pour Ajouter, Modifier ou Supprimer des en-têtes, et nous nous sommes spécialisés dans la normalisation de numéros, une tâche essentielle.

Aujourd'hui, nous allons nous concentrer sur une question tout aussi cruciale : "quand" ? L'objectif de cette leçon est de vous apprendre à utiliser des conditions pour appliquer une manipulation uniquement sur certains appels. C'est le "SI..." de la logique "SI... ALORS...", et c'est la clé qui transforme la manipulation SIP d'un outil brut en un scalpel chirurgical, vous permettant de résoudre des problèmes d'interopérabilité complexes avec une précision extrême.

La Puissance de la Manipulation Conditionnelle

Jusqu'à présent, les règles que nous avons imaginées s'appliquaient à tous les appels correspondant au type de message. Mais en pratique, ce n'est presque jamais ce que vous voulez. Vous voudrez plutôt :

• Modifier l'en-tête From uniquement si l'appel provient d'un PBX spécifique.
• Supprimer un en-tête non standard uniquement si l'appel est destiné à votre opérateur SIP (ITSP).
• Ajouter un en-tête d'identité uniquement si l'appel provient de Microsoft Teams.

Le paramètre Condition dans les "Message Manipulation Rules" (MMR) vous permet de faire exactement cela. Une règle ne sera exécutée que si la condition que vous définissez est évaluée comme vraie.

Anatomie d'une Condition

Dans l'interface AudioCodes, une MMR est structurée en deux parties principales : Match (la condition) et Action (ce qu'il faut faire). Le paramètre Condition fait partie de la section Match.

La syntaxe d'une condition suit généralement ce modèle :

Élément.Partie.Sous-partie Opérateur 'Valeur'

• Élément : header, param (paramètres internes de l'appel), body (corps SDP).
• Partie : Le nom de l'en-tête (From, Contact, P-Asserted-Identity) ou du paramètre (call.src.ip, call.dst.user).
• Sous-partie : Permet d'accéder à une partie spécifique, comme url.user pour l'utilisateur dans une URI SIP.
• Opérateur : == (égal), != (différent), contains (contient), > (supérieur à), < (inférieur à).
• 'Valeur' : La chaîne de caractères ou le nombre à vérifier, toujours entre apostrophes (').

Pour maîtriser cette syntaxe, la meilleure source est la documentation officielle.

Cas Pratiques : Résoudre des Problèmes Réels

Voyons comment appliquer ce concept à des scénarios que vous rencontrerez.

Scénario 1 : Interopérabilité avec un Opérateur (ITSP)

• Problème : Votre PBX interne ajoute un en-tête propriétaire, par exemple X-Internal-ID: 1234, à tous les appels sortants. Cet en-tête est utile pour votre suivi interne, mais votre opérateur SIP (ITSP) le rejette et renvoie une erreur 400 Bad Request.
• Solution : Créer une MMR qui supprime cet en-tête, mais uniquement pour les messages INVITE destinés à l'opérateur.

Comment identifier un appel vers l'opérateur ? L'une des méthodes est de cibler son adresse IP. Si le proxy de votre ITSP est à l'adresse 212.51.68.100, votre règle ressemblera à ceci :

Avec cette règle, l'en-tête sera supprimé pour les appels sortants vers l'opérateur, mais restera présent pour les appels internes (par exemple, entre le PBX et une autre branche de votre entreprise).

Scénario 2 : Intégration Microsoft Teams

• Problème : Pour des raisons de conformité, vous devez vous assurer que tous les appels entrants depuis Teams et dirigés vers votre centre de contact NICE contiennent un en-tête P-Asserted-Identity avec une valeur par défaut si celui-ci est manquant.
• Solution : Créer une MMR qui ajoute cet en-tête, mais uniquement pour les appels venant de Teams.

L'identification des appels de Teams est un cas d'école. Microsoft utilise des FQDN spécifiques dans les en-têtes SIP. Une condition très fiable est de vérifier la présence de pstnhub.microsoft.com dans l'en-tête Contact de l'INVITE entrant.

Votre règle pourrait alors être :

Ici, la condition assure que la manipulation est ciblée et ne touchera pas les appels venant d'autres sources comme votre ITSP.

Pour un autre exemple concret, je vous invite à analyser ce guide rapide.

Technique Avancée : Réutiliser une Condition

Imaginez que pour le Scénario 1 (l'opérateur ITSP), vous deviez non seulement supprimer l'en-tête X-Internal-ID, mais aussi modifier le format d'un autre en-tête, User-Agent. Devez-vous créer deux règles distinctes avec la même condition param.call.dst.ip == '212.51.68.100' ?

Non, ce serait inefficace. AudioCodes propose une fonctionnalité pour cela : le paramètre Row Role.

1. Vous créez votre première règle avec la condition et Row Role réglé sur Use Current Condition.
2. Pour les règles suivantes qui doivent utiliser cette même condition, vous laissez le champ Condition vide et réglez leur Row Role sur Use Previous Condition.

Exemple :

• Règle (Index 10)

  • Condition: param.call.dst.ip == '212.51.68.100'
  • Action Subject: header.X-Internal-ID
  • Action Type: Remove
  • Row Role: Use Current Condition

• Règle (Index 11)

  • Condition: (vide et ignoré)
  • Action Subject: header.User-Agent
  • Action Type: Modify
  • Action Value: 'AudioCodes-SBC'
  • Row Role: Use Previous Condition

Cette approche rend votre configuration plus propre, plus lisible et plus facile à maintenir.

Conclusion

Vous venez d'ajouter la pièce maîtresse à votre boîte à outils de manipulation SIP. La maîtrise des conditions est ce qui sépare une configuration basique d'une solution d'interopérabilité robuste et intelligente.

Points clés à retenir :

• Le paramètre Condition permet d'exécuter une règle de manipulation uniquement si un critère spécifique est rempli.
• C'est l'outil fondamental pour cibler des flux d'appels spécifiques (par IP, par en-tête, par contenu de message).
• La syntaxe permet de vérifier des en-têtes, des paramètres internes de l'appel, et même le corps SDP.
• Des opérateurs logiques (==, !=, contains) offrent une grande flexibilité pour définir vos critères.
• La fonction Row Role -> Use Previous Condition permet d'appliquer plusieurs actions sous une seule et même condition, optimisant ainsi votre configuration.

Prochaine Étape

Nous savons maintenant créer des règles individuelles, les rendre conditionnelles et même les enchaîner. Mais comment les organiser et les activer ? Dans la prochaine leçon, nous apprendrons à créer une "Manipulation Set" pour regrouper plusieurs de nos règles, puis nous verrons comment appliquer ce "Set" à une règle de routage ou à un "IP Group" pour le rendre enfin opérationnel sur le SBC.