Interopérabilité des méthodes DTMF : RFC2833 vs. In-band

Bonjour !

Dans la leçon précédente, nous avons vu comment résoudre les problèmes d'incompatibilité de codecs en configurant le transcodage sur le SBC. Nous avons appris à manipuler les flux audio pour que deux systèmes qui ne "parlent" pas le même codec puissent quand même communiquer.

Aujourd'hui, nous restons dans le domaine du média, mais nous nous attaquons à un autre problème d'interopérabilité très courant : la transmission des tonalités DTMF. L'objectif de cette leçon est de vous apprendre à assurer l'interopérabilité des méthodes DTMF, comme RFC 2833 et In-band.

Vous avez sans doute déjà utilisé ces tonalités en tapant sur votre clavier pour naviguer dans un menu vocal ("Tapez 1 pour le service client..."), entrer un code de conférence ou un mot de passe. Si ces signaux ne sont pas transmis correctement, ces services deviennent inutilisables. Vous apprendrez donc à diagnostiquer et à configurer le SBC AudioCodes pour qu'il agisse comme un traducteur de tonalités fiable.

1. Les Différentes Méthodes de Transport DTMF

En VoIP, il n'y a pas une, mais trois manières principales de transporter les tonalités DTMF d'un bout à l'autre d'un appel. Comprendre ces trois méthodes est la première étape pour résoudre les problèmes.

1. In-band (Dans la bande audio)

   • Comment ça marche ? Les tonalités DTMF sont simplement des sons générés et mélangés directement dans le flux audio principal (le flux RTP), comme la voix.
   • Avantages : C'est la méthode la plus simple, elle ne requiert aucune signalisation spéciale.
   • Inconvénients : Elle n'est fiable qu'avec des codecs sans compression comme le G.711 (PCMU/PCMA). Dès qu'un codec avec compression (G.729, Opus, AMR-WB) est utilisé, il risque de déformer la tonalité, la rendant méconnaissable pour le système récepteur. C'est une cause très fréquente d'échec des DTMF.

2. Out-of-band via RFC 2833 (ou RFC 4733)

   • Comment ça marche ? C'est la méthode la plus répandue et la plus fiable. Les tonalités ne sont pas envoyées comme de l'audio. À la place, des paquets RTP spéciaux, nommés "telephone-event", sont générés pour indiquer quel chiffre a été pressé, sa durée et son volume.
   • Avantages : C'est totalement indépendant du codec audio utilisé. Que l'appel soit en G.711 ou en Opus, les tonalités sont transportées de manière identique et fiable.
   • Comment est-ce négocié ? La capacité à utiliser RFC 2833 est annoncée et négociée dans le SDP (Session Description Protocol) lors de l'établissement de l'appel, via une ligne a=rtpmap:... telephone-event/8000.

3. Out-of-band via Signalisation SIP

   • Comment ça marche ? Les chiffres sont transportés directement dans des messages SIP (hors du flux RTP). Les méthodes les plus courantes sont SIP INFO et SIP NOTIFY. Le message SIP contient l'information du chiffre pressé.
   • Avantages : Également indépendant du codec.
   • Inconvénients : Moins standardisé que RFC 2833. Différents constructeurs (Cisco, Nortel) ont leurs propres implémentations de SIP INFO, ce qui peut causer des problèmes d'interopérabilité. C'est souvent utilisé en dernier recours ou pour des intégrations spécifiques.

Votre rôle en tant qu'administrateur de SBC sera de vous assurer que si un équipement envoie du DTMF en In-band, et que le destinataire attend du RFC 2833, le SBC fasse la conversion.

2. Comprendre la Négociation et la Structure de RFC 2833

Étant la méthode la plus importante, il est crucial de bien comprendre comment RFC 2833 fonctionne.

Comme vous l'avez lu, la clé de RFC 2833 est la négociation via le SDP. Lors d'un troubleshooting, la première chose à vérifier dans les traces (Wireshark) est que cette négociation a bien eu lieu sur les deux segments d'appel (entrant et sortant du SBC).

Une fois la négociation réussie, vous devriez voir des paquets RTP de type "telephone-event" pendant l'appel, comme le montre cette capture.

3. Configurer l'Interopérabilité DTMF dans les IP Profiles

Comme pour beaucoup de paramètres de signalisation et de média, la configuration du comportement DTMF se fait principalement dans l'IP Profile. C'est ici que vous indiquerez au SBC comment recevoir, traiter et envoyer les tonalités.

Synthétisons la démarche de configuration dans l'IP Profile (Setup > Signaling & Media > Coders & Profiles > IP Profiles) :

1. Méthode de transport préférée :

   • Sur un SBC AudioCodes, la méthode de transport DTMF est contrôlée par un paramètre clé : DTMFTransportType. Il se trouve dans la section SBC de l'IP Profile.
   • Les options courantes sont :
     • RTPRelay: C'est le mode RFC 2833. C'est le réglage que vous utiliserez dans 99% des cas.
     • Inband: Force le passage des tonalités en In-band. À n'utiliser qu'avec G.711 et si absolument nécessaire.
     • SIPInfo: Utilise la méthode SIP INFO.
     • Transcode: Le SBC détecte le DTMF (In-band ou RFC 2833) et le régénère sur l'autre leg de l'appel. C'est le mode le plus flexible. En général, c'est le meilleur choix (Transcode) car il permet au SBC de s'adapter.

2. Gestion de la charge utile (Payload) RFC 2833 :

   • Le paramètre RFC 2833 DTMF Payload Type est crucial. Par défaut, il est à 0 (passthrough), ce qui signifie que le SBC laisse les équipements négocier entre eux.
   • Quand le modifier ? Si vous avez un équipement qui requiert une valeur de payload spécifique (ex: 101) et ne la négocie pas correctement, vous pouvez la forcer ici. Par exemple, si vous mettez 101, le SBC proposera toujours 101 dans son SDP sortant pour cet IP Profile.

3. Gestion des méthodes multiples (scénarios avancés) :

   • Les paramètres Send Multiple DTMF Methods et Receive Multiple DTMF Methods sont des outils puissants pour des cas complexes.
   • Par exemple, si vous vous connectez à un vieux système qui supporte mal RFC 2833, vous pouvez activer Send Multiple DTMF Methods pour envoyer les tonalités à la fois en RFC 2833 et en SIP INFO, augmentant les chances que le message soit reçu.

4. Méthodologie de Troubleshooting

Face à un problème de DTMF, votre expérience sur Oracle SBC vous a déjà familiarisé avec l'analyse de traces. La méthode est similaire ici.

Symptôme 1 : Les tonalités ne sont pas du tout reconnues.

1. Analyse du SIP/SDP : Capturez un appel de test avec Wireshark ou les traces du SBC. Regardez les messages INVITE et 200 OK (ou 18x).

   • Le leg A (entrant) négocie-t-il une méthode DTMF ? (ex: telephone-event/8000 dans le SDP)
   • Le leg B (sortant) négocie-t-il une méthode DTMF ?
   • Les méthodes sont-elles les mêmes ? Si le leg A propose uniquement de l'In-band (pas de ligne telephone-event) et que le leg B attend du RFC 2833, le SBC est-il configuré pour transcoder le DTMF ? (DTMFTransportType = Transcode).

2. Analyse du RTP : Si RFC 2833 a été négocié des deux côtés, filtrez la capture Wireshark avec rtp.p_type == <payload_number> (ex: rtp.p_type == 101).

   • Voyez-vous des paquets RTP "telephone-event" arriver sur le SBC ?
   • Le SBC les envoie-t-il sur l'autre leg ? Si non, le problème est dans la configuration du SBC.

Symptôme 2 : Des chiffres sont tapés en double ("1" devient "11").

• Cause probable : Le DTMF est transporté par deux méthodes simultanément (souvent In-band avec G.711 + RFC 2833), et le récepteur traite les deux.
• Solution :
  1. Assurez-vous que seule une méthode est utilisée. Si vous utilisez RFC 2833, il faut supprimer la version In-band.
  2. Dans l'IP Profile, il y a un paramètre nommé DTMF Volume. En le réglant sur une valeur très basse ou sur "Mute", vous pouvez demander au SBC de "filtrer" et supprimer les tonalités In-band du flux audio avant de le relayer, ne laissant passer que les paquets RFC 2833.

Pour observer comment le SBC détecte les digits, vous pouvez aussi regarder les traces Syslog. Pour le DTMF In-band, vous verrez des messages comme ceux-ci, indiquant la détection et la durée du chiffre.

Conclusion

La gestion du DTMF est un aspect fondamental de l'interopérabilité en VoIP. Une mauvaise configuration peut paralyser l'accès à de nombreux services automatisés.

Points clés à retenir :

• Il existe trois méthodes de transport DTMF : In-band (non fiable avec la compression), RFC 2833 (fiable et standard, à privilégier), et SIP INFO (spécifique aux constructeurs).
• La configuration du comportement DTMF sur un SBC AudioCodes se fait principalement dans l'IP Profile.
• Le paramètre le plus important est DTMFTransportType, qui doit généralement être réglé sur Transcode ou RTPRelay (RFC 2833) pour assurer la conversion entre les différentes méthodes.
• Le troubleshooting d'un problème DTMF implique systématiquement l'analyse de la négociation SDP dans les traces SIP, suivie de la vérification du flux RTP pour les paquets telephone-event.
• Les problèmes de doubles chiffres sont souvent causés par une transmission simultanée en In-band (avec G.711) et via RFC 2833.

Vous êtes maintenant équipé pour diagnostiquer et résoudre les problèmes de DTMF les plus courants, en vous assurant que les interactions de vos utilisateurs avec les serveurs vocaux se déroulent sans accroc.

Aperçu de la prochaine leçon : Nous avons traité en profondeur deux aspects du média : les codecs et le DTMF. Dans la prochaine leçon, nous reviendrons à la signalisation SIP pour aborder un sujet plus avancé : "Adapter les headers de renvoi d'appel (Diversion, History-Info) entre différents systèmes". Nous verrons comment assurer que les informations de transfert et de renvoi d'appel sont correctement préservées et traduites lorsque l'appel traverse le SBC.