Filtrage des Codecs SDP par Profil IP

Bonjour !

Dans la leçon précédente, nous avons vu comment le SBC AudioCodes peut agir comme un traducteur pour les headers de renvoi d'appel (Diversion et History-Info). Nous avons appris que les IP Profiles sont un outil essentiel pour réaliser cette normalisation de la signalisation SIP.

Aujourd'hui, nous allons nous attaquer à un autre problème d'interopérabilité fondamental, mais cette fois-ci, il concerne la partie Média du message SIP. L'objectif de cette leçon est d'apprendre à filtrer les listes de codecs dans les messages SDP via les paramètres de l'IP Profile.

Vous découvrirez comment forcer l'utilisation de codecs spécifiques et éviter les échecs d'appel dus à une incompatibilité de "langues" audio entre deux systèmes, comme un opérateur SIP et Microsoft Teams. C'est une compétence cruciale pour garantir que les appels s'établissent correctement et avec la qualité audio souhaitée.

1. Le Problème : L'Incompatibilité des Codecs dans le SDP

Lorsqu'un appel SIP est initié, le premier message INVITE contient une section appelée SDP (Session Description Protocol). C'est dans cette section que l'appelant propose une liste de codecs audio qu'il est capable d'utiliser (par exemple, G.711, G.729, SILK). C'est ce qu'on appelle l'offre SDP (SDP Offer).

Le destinataire de l'appel répond alors avec une réponse SDP (SDP Answer), en choisissant l'un des codecs proposés qu'il supporte également.

Que se passe-t-il si aucun codec n'est en commun ?
L'appel échoue. Le destinataire enverra typiquement un message d'erreur SIP comme 415 Unsupported Media Type ou 488 Not Acceptable Here, et l'appelant entendra une tonalité d'échec.

Exemple concret :

• Votre environnement Microsoft Teams est configuré pour privilégier le codec haute-fidélité SILK.
• Votre opérateur SIP (ITSP), lui, ne supporte que les codecs plus classiques comme G.711 et G.729.

Si un appel sortant de Teams vers l'opérateur envoie une offre SDP ne contenant que le codec SILK, l'opérateur la rejettera et l'appel échouera. Le rôle du SBC est de "nettoyer" cette offre SDP avant de la transmettre à l'opérateur pour s'assurer qu'elle ne contienne que des codecs que ce dernier comprend.

2. La Solution : Les "Allowed Audio Coders Groups"

Pour résoudre ce problème, AudioCodes utilise une fonctionnalité appelée "Allowed Audio Coders Groups". Il s'agit simplement de listes blanches de codecs que vous définissez. Lorsqu'un message SIP passe par le SBC, ce dernier inspecte l'offre SDP et la compare à la liste blanche que vous avez configurée. Il supprime alors de l'offre tous les codecs qui ne sont pas sur la liste avant de la transmettre à sa destination.

Comme vous l'avez lu, le principe est simple mais puissant. Vous garantissez ainsi que le destinataire ne recevra jamais une offre SDP avec un codec qu'il ne supporte pas.

3. Les Étapes de Configuration

La mise en place de ce filtrage se fait en deux étapes logiques, que nous allons détailler.

Étape 1 : Créer l' "Allowed Audio Coders Group"

D'abord, vous devez créer votre liste blanche de codecs.

À ce stade, vous avez défini une liste, mais elle n'est appliquée nulle part. Elle est inactive.

Étape 2 : Appliquer le Groupe à un IP Profile

C'est ici que la magie opère. Comme pour les headers Diversion/History-Info, c'est l'IP Profile qui active la fonctionnalité. L'IP Profile est appliqué à un IP Group, ce qui signifie que le filtrage de codecs ne s'appliquera qu'au trafic provenant de (ou allant vers) ce partenaire SIP spécifique.

En résumé, la chaîne logique est la suivante :

1. Un appel arrive d'un IP Group (ex: Teams).
2. Le SBC consulte l'IP Profile associé à cet IP Group.
3. Il voit qu'un Allowed Audio Coders Group y est défini.
4. Il filtre l'offre SDP de l'appel en fonction de ce groupe avant de l'envoyer à la destination.

4. Différence entre 'Coder Groups' et 'Allowed Audio Coder Groups'

Il est facile de confondre ces deux concepts qui ont des noms similaires. La distinction est essentielle.

• Coder Groups :

  • Rôle : Ils définissent la liste des codecs que le SBC peut utiliser lui-même. C'est sa propre "boîte à outils" de codecs.
  • Utilisation : Ils sont principalement assignés à des Media Realms. Le SBC utilise un codec de ce groupe lorsqu'il doit faire du transcodage (traduire un flux audio d'un codec vers un autre, par exemple de SILK vers G.711).
  • Analogie : C'est la liste des langues que le SBC sait parler.

• Allowed Audio Coder Groups :

  • Rôle : Ils agissent comme un filtre sur la signalisation SIP (le SDP) qui traverse le SBC.
  • Utilisation : Ils sont assignés à des IP Profiles pour restreindre les codecs proposés dans une négociation entre deux autres équipements.
  • Analogie : C'est la liste des langues que le SBC autorise deux personnes à parler entre elles à travers lui.

Vous utiliserez les Allowed Audio Coder Groups pour la plupart des scénarios d'interopérabilité, et les Coder Groups principalement lorsque vous aurez besoin de configurer le transcodage, un sujet que nous avons abordé dans la leçon sur la gestion de la compatibilité des codecs.

Conclusion

La maîtrise du filtrage des codecs est une compétence indispensable pour tout ingénieur VoIP travaillant sur des SBC. C'est souvent l'une des premières choses à vérifier lorsqu'un appel entre deux systèmes différents échoue sans raison apparente.

Points clés à retenir :

• Les incompatibilités de codecs dans les offres SDP sont une cause fréquente d'échec d'appel, se manifestant par des erreurs SIP 415 ou 488.
• AudioCodes fournit les "Allowed Audio Coder Groups" pour créer des listes blanches de codecs autorisés.
• La configuration se fait en deux temps :
  1. Créer l'"Allowed Audio Coders Group" et y ajouter les codecs souhaités.
  2. Appliquer ce groupe à un IP Profile via les paramètres Allowed Coders Group ID et Allowed Coders Mode.
• Il ne faut pas confondre les 'Allowed Audio Coder Groups' (filtres SDP pour IP Profiles) avec les 'Coder Groups' (capacités de transcodage pour Media Realms).

Aperçu de la prochaine leçon : Nous avons maintenant couvert tous les piliers de l'interopérabilité avancée sur AudioCodes : la normalisation des numéros (via les MMR), l'adaptation des headers SIP (Diversion, History-Info), la gestion des DTMF et, aujourd'hui, le filtrage des codecs. La prochaine leçon sera une synthèse de ce module : "Récapituler les points de contrôle d'interopérabilité". Nous y construirons une checklist méthodique à mémoriser, qui vous guidera lors du dépannage de problèmes d'interopérabilité complexes.