Interfaçage des en-têtes de renvoi (Diversion, History-Info)

Bonjour !

Dans la leçon précédente, nous avons appris à garantir l'interopérabilité des tonalités DTMF, en nous assurant que les interactions de l'utilisateur avec les serveurs vocaux (SVI) se déroulent sans problème. Nous avons maîtrisé la conversion entre les différentes méthodes de transport DTMF au niveau du flux média.

Aujourd'hui, nous revenons à la couche de signalisation SIP pour aborder un autre défi d'interopérabilité essentiel. L'objectif de cette leçon est d'apprendre à adapter les headers de renvoi d'appel (Diversion, History-Info) entre différents systèmes. Vous découvrirez comment le SBC peut préserver les informations critiques sur la manière dont un appel a été transféré ou dévié, même lorsque les équipements des deux côtés de l'appel ne "parlent" pas le même langage de signalisation.

C'est un point crucial, par exemple, pour que le téléphone d'un réceptionniste affiche correctement le numéro de l'appelant initial lorsqu'un appel est renvoyé, et non le numéro de la personne qui a effectué le renvoi.

1. Pourquoi Adapter les Headers de Renvoi d'Appel ?

Imaginez ce scénario :

1. Un client (Alice) appelle votre numéro principal.
2. L'appel arrive sur un standard automatique qui le renvoie vers un agent (Bob).
3. Bob est occupé, donc son poste renvoie l'appel vers son collègue (Carol).

Comment le téléphone de Carol peut-il savoir que l'appel vient initialement d'Alice, et non de Bob ? C'est le rôle des headers SIP qui tracent l'historique des renvois. Les deux principaux sont Diversion et History-Info.

• Diversion Header (RFC 5806) : Historiquement, c'est le header le plus utilisé. Il indique qui a dévié l'appel et pour quelle raison. Il ne contient généralement que la dernière étape de déviation.

  • Exemple : Diversion: <sip:bob@monentreprise.com>;reason=user-busy

• History-Info Header (RFC 7044) : C'est une méthode plus moderne et plus riche. Elle peut contenir l'historique complet des déviations, chaque étape étant indexée.

  • Exemple : History-Info: <sip:bob@monentreprise.com>;index=1, <sip:carol@monentreprise.com>;index=1.1

Le problème d'interopérabilité :
Différents systèmes privilégient l'un ou l'autre.

• Microsoft Teams utilise abondamment le header History-Info pour signaler les transferts et les renvois.
• De nombreux opérateurs SIP (ITSP) et des PBX plus anciens ne comprennent que le header Diversion.

Sans intervention du SBC, si Teams envoie un appel renvoyé avec un header History-Info vers un ITSP qui attend un Diversion, l'information est perdue. Le destinataire final verra l'appel venir de la dernière personne ayant renvoyé, et non de l'appelant d'origine. Votre rôle est de configurer le SBC AudioCodes pour qu'il agisse comme un traducteur intelligent.

2. Méthode 1 : L'Interopérabilité Intégrée via les IP Profiles

AudioCodes fournit un mécanisme simple et direct pour gérer la conversion entre Diversion et History-Info. Cette configuration se trouve dans les IP Profiles.

Comme vous l'avez vu, vous pouvez contrôler très précisément le comportement du SBC avec deux paramètres dans l'IP Profile (Setup > Signaling & Media > Coders & Profiles > IP Profiles) :

• Diversion Header Mode
• History-Info Header Mode

Chacun peut être réglé sur :

• As Is : Laisse le header tel quel s'il est présent, ne fait rien sinon.
• Add : Si le header est absent, essaie de le créer à partir de l'autre header. S'il est présent, il est mis à jour.
• Remove : Supprime le header.

Exemple pratique (Teams vers ITSP) :

• L'IP Profile appliqué à votre IP Group Teams (côté entrant) pourrait avoir History-Info Header Mode = As Is.
• L'IP Profile appliqué à votre IP Group ITSP (côté sortant) pourrait avoir :
  • Diversion Header Mode = Add (Crée le Diversion s'il n'existe pas, à partir du History-Info).
  • History-Info Header Mode = Remove (Nettoie le History-Info qui est inutile pour l'ITSP).

Cette méthode est idéale pour les conversions directes et simples.

3. Méthode 2 : Adaptation Avancée avec les "Message Manipulation Rules" (MMR)

Que se passe-t-il si la logique est plus complexe ? Par exemple, si vous devez convertir un header Referred-By (utilisé lors d'un transfert d'appel) en Diversion ? Ou si vous devez modifier une partie du contenu du header ? C'est là que les Message Manipulation Rules (MMR) entrent en jeu.

Les MMR vous donnent un contrôle total sur chaque partie d'un message SIP. Vous pouvez créer des règles pour ajouter, modifier ou supprimer n'importe quel header sous certaines conditions.

Ce document illustre une méthodologie de travail que vous devrez maîtriser :

1. Identifier le besoin : L'opérateur Swisscom exige un header Diversion, mais Teams envoie History-Info pour les renvois et Referred-By pour les transferts. C'est un problème d'interopérabilité classique.
2. Créer une séquence de règles : Pour le renvoi (Call Forward), les ingénieurs ont créé une chaîne de règles :
   • Rule 6 : Ajoute un header Diversion en copiant le contenu du header History-Info.
   • Rule 8 : Supprime le header History-Info original pour ne pas envoyer d'informations redondantes ou non comprises par l'opérateur.
   • Notez l'utilisation de Use Previous Condition. Cela signifie que la règle 8 ne s'exécute que si la règle 6 a été exécutée, créant ainsi une logique de "si... alors...".
3. Regrouper les règles dans un "Manipulation Set" : Toutes ces règles sont regroupées sous le Manipulation Set ID 4. Un "Set" est simplement une collection de règles que l'on peut appliquer ensemble.
4. Appliquer le "Manipulation Set" : Cette dernière étape est cruciale. Une fois votre ensemble de règles créé, vous devez l'assigner à un IP Group pour qu'il soit activé.

Pour voir une démonstration pratique de la création d'une règle de manipulation, vous pouvez regarder ce court extrait vidéo. Il montre comment un ingénieur crée une règle pour supprimer le header History-Info.

Conclusion

La gestion des headers de renvoi d'appel est un exemple parfait du rôle de "traducteur universel" que joue le SBC. Une mauvaise gestion de ces headers peut entraîner des problèmes de présentation du numéro, des erreurs de facturation et une expérience utilisateur dégradée.

Points clés à retenir :

• Les headers Diversion et History-Info transportent des informations sur la redirection des appels, mais ne sont pas universellement supportés.
• L'incompatibilité entre des systèmes comme Microsoft Teams (History-Info) et de nombreux opérateurs (Diversion) est un cas d'usage très fréquent pour le SBC.
• AudioCodes offre deux méthodes pour résoudre ce problème :
  1. Les IP Profiles (Diversion/History-Info Header Mode) : Idéal pour les conversions directes et simples entre les deux headers.
  2. Les Message Manipulation Rules (MMR) : Essentiel pour les scénarios complexes, conditionnels, ou pour convertir d'autres headers comme Referred-By.
• La méthodologie consiste à analyser le header entrant, déterminer le format sortant requis par la destination, et configurer la traduction via l'IP Profile ou les MMRs, puis appliquer cette configuration à l'IP Group concerné.

Aperçu de la prochaine leçon : Nous terminerons notre exploration de l'interopérabilité avancée en nous penchant sur une autre tâche de normalisation cruciale : "Filtrer les listes de codecs dans les messages SDP via les paramètres de l'IP Profile". Vous apprendrez à contrôler finement les codecs qui sont proposés et acceptés, pour éviter les échecs de négociation média.