Skip to main content

Someone wanted to learn this too, so Grasp built them a personal learning path.

You can keep exploring this one or create your own

Configuration de l'identité de l'appelant PAI

Bonjour et bienvenue dans cette nouvelle leçon dédiée à l'intégration de Microsoft Teams Direct Routing.

Dans la leçon précédente, nous avons découvert le "couteau suisse" de l'AudioCodes SBC : les Message Manipulation Rules (MMR). Vous avez appris à construire des règles pour normaliser les numéros au format E.164 et à nettoyer l'en-tête Contact, qui sont des prérequis essentiels pour que Microsoft accepte vos appels.

Aujourd'hui, nous allons nous concentrer sur un en-tête SIP particulièrement important pour la gestion de l'identité : le P-Asserted-Identity (PAI). L'objectif de cette leçon est de vous apprendre à configurer sa transmission. C'est une compétence fondamentale, car la bonne gestion de cet en-tête détermine l'affichage du numéro chez l'appelé, la facturation par les opérateurs, et la conformité aux exigences légales.

Maîtriser le PAI est donc une étape clé pour devenir autonome dans le dépannage et la mise en œuvre de projets complexes, votre objectif principal.


1. Qu'est-ce que l'en-tête P-Asserted-Identity ?

Dans le monde SIP, plusieurs en-têtes peuvent transporter l'identité de l'appelant. Le plus commun est l'en-tête From. Cependant, le From est déclaratif : un utilisateur peut y mettre ce qu'il veut. Pour les services qui nécessitent une identité de confiance (comme la facturation d'un appel par un opérateur ou l'identification d'un utilisateur dans Teams), on utilise des en-têtes plus fiables.

Le P-Asserted-Identity (PAI), défini par la RFC 3325, est l'un de ces en-têtes de confiance. Il est inséré par un équipement de confiance (comme un SBC) qui a vérifié l'identité de l'appelant. Pour de nombreux systèmes, dont Microsoft Teams et la plupart des opérateurs, l'identité présente dans le PAI a priorité sur celle de l'en-tête From.

L'image ci-dessous illustre parfaitement ce concept.

P-Asserted-Identity (PAI) Header Priority in Caller ID Display
Cette image montre un appel SIP où le header `From` contient "John Doe" et le header `P-Asserted-Identity` contient "testpai12313". Le téléphone de l'appelé affiche "testpai12313", prouvant que le PAI est prioritaire pour déterminer l'identité affichée.

Pour le Direct Routing, Microsoft utilise le PAI pour identifier l'utilisateur Teams qui passe l'appel. Si cet en-tête est manquant ou mal formaté, l'appel sera rejeté.


2. Comment Gérer le P-Asserted-Identity sur un SBC AudioCodes ?

Il existe deux méthodes principales pour configurer le comportement du PAI sur votre SBC. Le choix dépend du niveau de contrôle dont vous avez besoin.

Méthode 1 : Le Paramètre Global dans l'IP Profile

C'est la méthode la plus simple et la plus directe. L'IP Profile que nous avons déjà configuré contient un paramètre qui définit le comportement par défaut du SBC pour l'en-tête PAI pour tout le trafic associé à ce profil.

Les options principales sont :

  • Pass Through : Le SBC ne touche pas à l'en-tête PAI. S'il est présent, il le laisse passer ; s'il est absent, il n'en ajoute pas.
  • Add : Le SBC ajoute un en-tête PAI s'il n'en existe pas déjà un. Il le construit généralement à partir des informations de l'en-tête From.
  • Remove : Le SBC supprime systématiquement l'en-tête PAI.

Dans le contexte de Teams, il est courant de devoir ajouter cet en-tête sur le flux d'appel sortant de votre PBX interne vers Teams, car le PBX ne le génère pas toujours.

La vidéo suivante montre où trouver et comment configurer ce paramètre.

Configuring Audiocodes SBC for Microsoft Teams Direct Routing

Cette vidéo montre la création d'un IP Profile. Portez une attention particulière au moment où le paramètre P-Asserted-Identity est configuré.

Regardez la section de 00:14:30 à 00:15:10. L'ingénieur crée un IP Profile pour un CUCM (l'équivalent de votre PBX interne) et change le paramètre 'P-Asserted-Identity Header Mode' en 'Add'. C'est l'approche la plus simple pour garantir que le PAI est toujours présent.

Méthode 2 : Contrôle Granulaire avec les Message Manipulation Rules (MMR)

La méthode de l'IP Profile est efficace mais manque de finesse. Que faire si vous devez :

  • Supprimer le PAI uniquement pour certains appels ?
  • Modifier le PAI car son format ne convient pas à la destination ? (Un cas très fréquent !)
  • Construire un PAI complexe à partir d'autres en-têtes ?

C'est là que les Message Manipulation Rules, que nous avons étudiées dans la leçon précédente, deviennent indispensables.

Scénario A : Supprimer le PAI

Imaginons que vous envoyez un appel de Teams vers un vieil équipement qui ne supporte pas le PAI. Vous pouvez créer une règle simple pour le supprimer.

  • Action Subject: Header.P-Asserted-Identity
  • Action Type: Remove

La vidéo ci-dessous montre la création d'une telle règle.

Configuring Audiocodes SBC for Microsoft Teams Direct Routing

Cette partie de la vidéo montre comment créer une règle de manipulation spécifiquement pour supprimer le PAI.

Regardez de 00:21:40 à 00:22:35. L'opérateur crée une nouvelle règle de manipulation nommée 'remove pi'. L'Action Subject est header.P-Asserted-Identity et l'Action Type est Remove. C'est un exemple de base, mais fondamental.

Scénario B : Modifier le PAI (Le cas le plus courant pour le troubleshooting)

C'est ici que la véritable expertise entre en jeu. Les opérateurs et les systèmes comme Teams ont des exigences très strictes sur le format du PAI.

Par exemple, Microsoft envoie un PAI qui peut contenir deux URI : un tel: et un sip:. Certains opérateurs n'acceptent pas ce format et rejettent l'appel. Le SBC doit alors "nettoyer" cet en-tête pour ne garder qu'une seule URI dans le bon format.

Le guide de configuration suivant contient un excellent exemple pratique de ce type de manipulation.

[PDF] AudioCodes SBC for Swisscom Smart Business Connect Internet ...

Ce guide de configuration AudioCodes pour un opérateur suisse montre des manipulations PAI complexes, mais très réalistes, nécessaires pour assurer l'interopérabilité entre Teams et un ITSP.

Veuillez vous rendre à la section '4.17 Configure Message Manipulation Rules' (autour de la page 37). Lisez la description des règles avec les index 0 et 1 dans la table récapitulative finale (vers la page 46). Règle 0 : Copie la partie utilisateur du tel: URI dans le sip: URI. Règle 1 : Supprime l'index tel: URI. Lisez la colonne 'Reason for Introducing Rule' pour comprendre pourquoi cette manipulation est nécessaire : 'Swisscom SIP Trunk didn’t support such a format...'. C'est un cas de troubleshooting classique.

Cette lecture vous montre que la maîtrise des MMR pour le PAI ne consiste pas seulement à Add ou Remove, mais surtout à transformer l'en-tête pour le rendre compatible entre deux systèmes qui ne parlent pas exactement la même "langue" SIP.


3. Application des Règles de Manipulation

Comme nous l'avons vu dans la leçon précédente, une fois la règle créée, elle doit être assignée à un Manipulation Set ID, puis ce Set ID doit être appliqué à un IP Group dans la direction souhaitée (Inbound ou Outbound).

Le diagramme ci-dessous vous rappelle où ces manipulations s'insèrent dans le flux de traitement de l'appel.

Manipulation Flow in AudioCodes SBC
Ce diagramme illustre le parcours d'un message SIP. Les manipulations de l'en-tête PAI se produisent généralement dans les étapes "Message Manipulations" juste après la classification de l'appel (pour les messages entrants) ou juste avant d'être envoyé à la destination (pour les messages sortants).

Le processus est le suivant :

  1. Vous créez votre ou vos règles de manipulation pour le PAI (ex: Add, Remove, Modify).
  2. Vous leur assignez un Manipulation Set ID (ex: 11).
  3. Vous éditez l'IP Group concerné (ex: Teams_IPGroup).
  4. Vous entrez l'ID 11 dans le champ Inbound Message Manipulation Set (si la manipulation doit s'appliquer aux messages venant de Teams) ou Outbound Message Manipulation Set (si elle s'applique aux messages allant vers Teams).
  5. Vous appliquez et sauvegardez la configuration.

Conclusion

Aujourd'hui, nous avons exploré en profondeur la gestion de l'identité de l'appelant via l'en-tête P-Asserted-Identity. Vous savez maintenant non seulement ce qu'il est et pourquoi il est crucial, mais aussi comment le contrôler avec précision sur un SBC AudioCodes.

Points clés à retenir :

  • Le P-Asserted-Identity (PAI) est l'en-tête de confiance qui détermine l'identité de l'appelant, prioritaire sur l'en-tête From.
  • La gestion de base du PAI peut se faire via le paramètre P-Asserted-Identity Header Mode dans l'IP Profile.
  • Pour un contrôle fin et la résolution de problèmes d'interopérabilité, les Message Manipulation Rules (MMR) sont nécessaires pour ajouter, supprimer ou, le plus souvent, modifier le PAI.
  • Les scénarios de troubleshooting réels impliquent souvent de transformer le format du PAI pour satisfaire les exigences spécifiques de l'opérateur ou de Teams.

Aperçu de la prochaine leçon :
Maintenant que le SBC sait comment formater les messages pour Teams et gérer l'identité de l'appelant, l'étape finale de cette intégration de base est de lui dire où envoyer les appels. Dans la prochaine leçon, nous allons configurer le routage des appels entrants (de Teams vers votre PBX/ITSP) et sortants (de votre PBX vers Teams). Nous allons enfin faire sonner les téléphones

Can't find a good explanation? Sign up and we'll make it for you

Sign up