Configuration T.38 Fax sur SBC : guide de mise en service pour ProSBC

Le fax qui « fonctionne toujours sur la ligne analogique » cesse de fonctionner le jour où quelqu’un remplace le PRI par un trunk SIP, et le ticket atterrit chez l’ingénieur réseau qui n’a pas ouvert le menu fax du SBC depuis un an. T.38 était censé résoudre ce problème. En pratique, la fiabilité de T.38 repose sur une poignée de réglages dans le SBC, un chemin de tonalité propre depuis le terminal d’origine, et une NIC qui ne supprime pas silencieusement les paquets présentant des erreurs de somme de contrôle UDP.

Ce guide parcourt le panneau Fax Settings de ProSBC dans son intégralité, les contrôles NAT et codec associés, ainsi que les étapes de vérification qui transforment un déploiement T.38 instable en un déploiement fiable. Pour les fondements conceptuels sur ce qu’est T.38, en quoi UDPTL diffère de RTP, et pourquoi le fax cesse de fonctionner sur les réseaux VoIP, l’article explicatif Fax over IP (T.38) est le complément à lire en premier.

Liste de vérification avant de modifier le moindre réglage

La plupart des tickets « T.38 ne fonctionne pas » se résolvent par l’un de trois problèmes qu’aucun réglage du SBC ne corrigera : un terminal incapable de faire du T.38, une tonalité qui n’atteint jamais le SBC, ou une NIC qui supprime silencieusement des paquets. Vérifiez ces points avant de toucher au panneau Fax Settings.

Les deux terminaux peuvent réellement négocier T.38 ou G.711 passthrough. Un ATA, un serveur de fax ou une passerelle PRI qui ne prend en charge que le fax G.711 n’acceptera jamais un re-INVITE T.38, quelle que soit la configuration du SBC. Confirmez la prise en charge sur les deux legs dans la documentation du périphérique avant de déboguer le milieu de la chaîne.

Le chemin fax est identifié de bout en bout. Identifiez de quel NAP le fax provient, quel NAP le termine, l’opérateur intermédiaire, et si les messages re-INVITE traversent un pare-feu ou un dispositif NAT susceptible de réécrire le SDP. La manipulation d’en-têtes SIP en amont peut supprimer ou réécrire des attributs que ProSBC doit recevoir intacts.

Les déchargements NIC sont désactivés si vous avez déjà observé des erreurs de somme de contrôle UDP. Le Generic Receive Offload et le déchargement de somme de contrôle UDP sur la NIC du SBC sont un tueur de T.38 reconnu. Les tickets arrivent avec le symptôme « T.38 négocie, mais la page ne se termine jamais ». La correction se fait au niveau du système d’exploitation (désactivez les déchargements concernés avec ethtool), pas dans le panneau Fax Settings.

Un numéro de fax de test qui échoue de la même façon à chaque fois. Les pannes intermittentes produisent des traces intermittentes. Un appel de test reproductible depuis un télécopieur connu vers une destination connue, idéalement avec un document d’une seule page, est ce qui rend une capture tbsigtrace exploitable.

Où se trouvent réellement les réglages fax de ProSBC

Le comportement fax sur ProSBC est configuré par profil NAP, et non globalement. Le chemin dans le portail Web est Configuration By Web Portal Category → NAP Profiles → Fax Settings, et à l’intérieur de ce panneau, cinq pages de mode distinctes couvrent les variantes opérationnelles dont vous pourriez avoir besoin.

• Configure Fax T38 pour le relais T.38 de bout en bout entre deux terminaux qui le négocient tous les deux.
• Configure Fax Passthrough pour le fax G.711 analogique maintenu en audio de bout en bout.
• Configuring Fax Relay pour le mode relais fax/modem interne utilisé dans les déploiements de type passerelle.
• Configure Fax NSE pour l’interopérabilité Cisco Named Signaling Events, lorsque le côté distant attend une signalisation fax/modem basée sur NSE.
• Configure Fax VBD pour le passthrough voice-band-data utilisé dans certains environnements hérités.

Les profils sont nommés (une convention courante dans les déploiements réels est par exemple FAX_ISDN pour le profil historique côté PRI), et le même profil peut être rattaché à plusieurs NAP. Si vous reconfigurez un NAP d’un PRI vers un terminal SIP, le même profil fax le suit. C’est le schéma recommandé : configurer une fois, rattacher selon les besoins.

Choisir le bon mode

La cause principale des échecs de fax est le choix du mauvais mode pour les terminaux concernés. La décision est dictée par ce que chaque leg prend en charge, et non par ce que le SBC préfère.

Fax T38 est le bon choix lorsque les deux legs peuvent négocier T.38. Le SBC détecte la tonalité fax, envoie un re-INVITE et bascule le leg média en UDPTL. C’est l’option la plus résiliente sur les réseaux à pertes, car la redondance UDPTL reconstitue localement les paquets perdus sans retransmission.

Fax Passthrough s’applique lorsque les deux legs préfèrent G.711 et que le réseau entre eux est fiable. Aucun re-INVITE n’est émis, aucun transcodage n’est nécessaire, et les modems fax négocient sur un flux audio G.711 continu. Le passthrough est sensible à la perte de paquets ; la fiabilité du fax passthrough diminue à mesure que la perte de paquets et la gigue augmentent.

Fax NSE et Fax VBD existent pour des cas d’interopérabilité avec des fournisseurs spécifiques. Utilisez Fax NSE lorsque le côté distant est une passerelle Cisco attendant la signalisation NSE. Utilisez Fax VBD lorsque le déploiement spécifie un comportement voice-band-data sur un trunk particulier. Si ni le fournisseur ni la spécification n’exigent ces modes, laissez-les de côté.

Fax Relay est le mode relais fax/modem interne utilisé dans les topologies de type passerelle où ProSBC lui-même agit comme point de relais plutôt que de négocier avec une passerelle en aval. C’est le scénario le moins courant dans les déploiements SBC modernes, mais il reste documenté pour les migrations d’anciens systèmes.

Configuration de Fax T38, champ par champ

La page Configure Fax T38 expose un ensemble compact de champs, et ces mêmes champs reviennent suffisamment souvent dans les échanges avec le support technique pour que leur fonction soit bien comprise. La liste ci-dessous documente chaque champ avec sa valeur par défaut recommandée et la raison de s’en écarter.

Enable Fax/Modem Relay est la bascule principale. Elle doit être cochée pour que tout comportement T.38 prenne effet. Si elle est décochée, tous les autres champs du panneau sont inertes.

Detection Mode contrôle l’agressivité avec laquelle ProSBC écoute les tonalités fax dans le flux audio. Standard est la valeur par défaut documentée et celle observée dans les déploiements fonctionnels ; n’optez pour une alternative que si un fournisseur l’exige explicitement.

Relay Mode sélectionne entre T38 (re-INVITE vers UDPTL) et Passthrough (maintien du leg en G.711 de bout en bout). C’est le seul champ qui change le mode opérationnel du profil. Réglez-le sur T38 pour la procédure Fax T38 ; passez à Passthrough lorsque vous souhaitez réellement préserver le leg audio de bout en bout.

Modem vs Fax Distinction prend un seuil en millisecondes et contrôle la façon dont le détecteur distingue une tonalité fax d’une tonalité modem. Une valeur de 0 ms traite toutes les tonalités détectées comme du fax, ce qui est le bon point de départ pour les déploiements exclusivement fax. N’augmentez cette valeur que lorsque vous avez du trafic modem sur le même trunk et que ProSBC doit acheminer les deux différemment.

Prevent direct invite in T.38 gère le cas où le côté émetteur ouvre l’appel avec T.38 déjà dans son SDP initial plutôt que de commencer en audio puis d’envoyer un re-INVITE. Cochez cette case lorsque le côté distant ne peut gérer que la séquence audio-first et que vous avez une passerelle en amont qui émet toujours des INVITE T.38 directs. Laissez-la décochée lorsque les deux côtés gèrent le T.38 direct correctement.

Detection Type couvre le réglage fin du détecteur. « Silence suppression off » est la valeur par défaut documentée et recommandée ; la suppression de silence interagit mal avec les tonalités fax et est à l’origine de plus de tickets d’incident qu’elle n’en résout.

Codec sélectionne le codec du leg audio utilisé avant le re-INVITE. PCMU (G.711 µ-law) est la valeur par défaut documentée et le codec sur lequel convergent les déploiements fonctionnels. Réglez-le pour qu’il corresponde au codec côté opérateur sur votre leg audio ; n’inscrivez pas G.729 ici, car le fax ne survit pas à la compression avec perte.

Attributs SDP T.38 que vous verrez sur le réseau

Lorsque le re-INVITE se déclenche et que le leg média bascule en UDPTL, le corps SDP annonce un ensemble spécifique d’attributs T.38. Connaître les valeurs par défaut accélère considérablement le traçage du flux d’appel, car chaque valeur ci-dessous est quelque chose que vous pouvez rechercher dans une capture et comparer à ce qui est attendu.

• m=image <port> udptl t38 est la ligne média qui signale le basculement de l’audio RTP vers UDPTL.
• a=T38FaxVersion:0 est la version offerte par défaut. La plupart des terminaux fax négocient la version 0 avec succès ; les surcharges de version existent mais sont rarement nécessaires.
• a=T38MaxBitRate:14400 est le débit binaire modem maximal offert, correspondant au fax V.17 standard.
• a=T38FaxRateManagement:transferredTCF place la gestion du Training Check Frame du côté distant plutôt que localement.
• a=T38FaxMaxBuffer:200 et a=T38FaxMaxDatagram:200 décrivent les tailles de tampon et de datagramme offertes.
• a=T38FaxUdpEC:t38UDPRedundancy déclare la redondance UDPTL comme méthode de correction d’erreurs, l’option qui compense la perte de paquets en transportant des copies de paquets IFP précédents.

Capturez d’abord un appel fax fonctionnel sur votre propre déploiement pour confirmer exactement ce que ProSBC offre dans votre environnement. La normalisation côté opérateur peut réécrire n’importe laquelle de ces valeurs avant qu’elles ne quittent le SBC, et les valeurs observées côté opérateur peuvent différer de celles observées côté terminal.

NAT, Force Passive Mode et le piège que la plupart des gens rencontrent

La configuration NAT au niveau du NAP interagit avec T.38 d’une manière qui piège de nombreux déploiements. Le réglage pertinent est Remote Method for RTP sur la page de configuration NAT du NAP, et l’une de ses valeurs, Force Passive Mode, modifie le moment où ProSBC ouvre le port RTP.

Avec Force Passive Mode activé, ProSBC attend que le premier paquet RTP arrive du côté distant avant d’ouvrir son port RTP. Ce comportement est correct pour les scénarios de traversée NAT où le côté distant se trouve derrière un pare-feu à état et ProSBC doit apprendre l’adresse traduite à partir du trafic observé. L’inconvénient est que si le côté distant n’envoie jamais en premier, le port ne s’ouvre jamais, et la négociation T.38 semble réussir au niveau SIP mais aucun paquet UDPTL ne circule.

Le diagnostic est simple : une capture tbsigtrace qui montre l’échange re-INVITE et 200 OK aboutissant correctement, aucun paquet UDPTL dans aucune direction, et l’appel qui finit par expirer. La correction dépend de la topologie. Lorsque ProSBC fait effectivement face à un pair NATé, Force Passive Mode est le bon choix et le côté émetteur doit être configuré pour envoyer le premier paquet. Lorsque ProSBC fait face à une passerelle non NATée, Force Passive Mode est le mauvais choix et la Remote Method doit être réglée sur une valeur qui permet à ProSBC d’ouvrir le port immédiatement.

Quand G.711 passthrough est la bonne réponse

Fax Passthrough n’est pas un repli pour un déploiement T.38 défaillant ; c’est un choix différent avec ses propres compromis. Les conditions qui favorisent le passthrough sont spécifiques et méritent d’être vérifiées avant de basculer le Relay Mode.

Choisissez le passthrough lorsque les deux terminaux préfèrent le comportement fax-depuis-analogique en G.711, lorsque le réseau entre eux affiche une perte de paquets régulièrement inférieure à 1 %, lorsque l’opérateur intermédiaire supprime le SDP T.38 ou offre toujours du G.711, ou lorsqu’un terminal est un ATA analogique qui n’implémente pas du tout T.38. La configuration se trouve dans le même panneau Fax Settings ; la modification consiste simplement à régler Relay Mode sur Passthrough plutôt que T38, avec le codec du leg audio maintenu sur PCMU et la suppression de silence désactivée.

Le compromis est la sensibilité à la perte de paquets. T.38 avec redondance UDPTL reconstitue les paquets manquants sans retransmission. G.711 passthrough ne le fait pas : les échantillons perdus deviennent des coupures audio, et un modem fax tentant de s’entraîner à travers une coupure audio échouera tout simplement. Si votre transport perd occasionnellement des paquets, T.38 se dégradera progressivement là où le passthrough échouera. La comparaison des codecs G.711 et G.729 couvre le contexte codec plus large si vous évaluez d’autres chemins audio sur le même trunk.

Vérification de l’appel fax

La procédure de vérification que le support TelcoBridges demande lors du dépannage de problèmes de fax est la même que celle que vous devriez exécuter vous-même avant d’ouvrir un ticket. Elle produit les artefacts qui prouvent ce qui s’est réellement passé sur le réseau.

1. Augmentez les niveaux de trace sur les processus concernésUtilisez tbx_cli_tools_remote pour régler le niveau de trace à 1 sur gateway, toolpack_engine et tbsyslog. Tapez T puis 1 à l’invite pour chacun. Le niveau de trace 1 est suffisant pour la négociation fax sans inonder les journaux.
2. Démarrez une capture de paquets tbrouterLa capture doit couvrir les deux NAP impliqués dans le chemin fax. Confirmez que la capture est en cours avant de passer l’appel.
3. Passez l’appel fax défaillantUtilisez le numéro de test reproductible identifié lors de la liste de vérification préalable. Un document d’une seule page est suffisant et produit une trace plus propre qu’une transmission multipage.
4. Arrêtez la capture et exportez la trace d’appelArrêtez tbrouter, exportez la trace d’appel depuis le portail Web et générez un tbreport cadré sur la date et la fenêtre horaire de l’appel défaillant.
5. Examinez ce que la trace montre réellementLe schéma complet est le suivant : 200 OK sur l’INVITE audio initial, tonalité fax détectée, re-INVITE avec SDP T.38, 200 OK sur le re-INVITE avec des attributs T.38 correspondants, la ligne m basculant vers m=image <port> udptl t38, le CNG arrivant avant la première trame DIS, et les paquets IFP circulant dans les deux directions avec la structure de redondance UDPTL intacte.

Une trace qui s’arrête en deçà de l’une de ces étapes vous indique exactement où chercher ensuite. Pas de re-INVITE signifie que le détecteur du leg audio ne s’est jamais déclenché. Un re-INVITE sans trafic UDPTL signifie un problème de NAT ou de port RTP, avec Force Passive Mode en tête de la liste des suspects. Du UDPTL qui circule mais des pages qui échouent pointe généralement vers des erreurs de somme de contrôle UDP sur la NIC ou un CNG arrivant après la trame DIS.

Schémas de pannes courants et comment les corriger

La plupart des échecs de fax en production correspondent à l’un d’un petit nombre de schémas. La liste ci-dessous est tirée des résolutions de support sur des déploiements ProSBC réels et associe chaque schéma à sa correction.

Erreurs de somme de contrôle UDP sur la NIC du SBC constituent le tueur de fax le plus fréquent. Le symptôme est une négociation T.38 qui aboutit correctement, suivie de paquets IFP que le noyau supprime avant que l’application ne les voie. La correction se fait au niveau du système d’exploitation : désactivez le déchargement de somme de contrôle UDP et le Generic Receive Offload sur l’interface. La documentation de dépannage SBC de TelcoBridges documente les étapes ; la même correction qui résout les problèmes DTMF résout également la perte de paquets T.38.

CNG arrivant après DIS signifie que le côté émetteur a envoyé l’établissement de l’appel plus vite que sa tonalité, et le détecteur de ProSBC a soit manqué le CNG entièrement, soit l’a détecté trop tard pour déclencher le re-INVITE. ProSBC ne fabrique pas de CNG ; la correction se situe sur le terminal émetteur ou la passerelle en amont, souvent en ajustant le timing de génération de tonalité de ce périphérique ou en changeant son mode fax.

Des paquets T.38 apparaissent toujours alors que vous vouliez du passthrough : cela indique que le champ Relay Mode est encore réglé sur T38. Basculer le champ de T38 à Passthrough supprime le re-INVITE et maintient le leg en G.711.

Un en-tête Diversion inséré par un script de routage empêche l’acceptation côté distant. Plusieurs déploiements ProSBC utilisent des scripts Ruby pour l’interrogation STIR/SHAKEN (le script ClearIP en est un exemple). Les anciennes versions du script injectent un en-tête Diversion que certaines passerelles de gestion de fax rejettent. La correction consiste à mettre à jour vers le script actuel ; le support TelcoBridges a distribué des versions corrigées pour le chemin ClearIP, et le même principe s’applique à tout script de routage personnalisé qui touche la ligne de requête sur les appels fax.

RTP bloqué après le re-INVITE se ramène à la configuration NAT du NAP. Force Passive Mode exige que le côté distant envoie le premier paquet RTP ; s’il ne le fait pas, aucun RTP ne circule dans aucune direction. La correction consiste soit à aligner Force Passive Mode sur la topologie NAT réelle, soit à s’assurer que le côté distant est configuré pour initier le RTP.

La couche SIP signale une MEGACO Error 442 (erreur de syntaxe dans la commande) dans les traces internes. Cela indique un SDP mal formé, souvent un espace ou un caractère parasite entre les attributs, sur le chemin entre le contrôleur de passerelle média du SBC et sa passerelle média. C’est un symptôme interne plutôt qu’un défaut visible par le client, mais s’il apparaît dans les traces de support en même temps qu’un fax échoué, le SDP doit être examiné et la source de la malformation identifiée.

Notes spécifiques aux fournisseurs

La bibliothèque de documentation ProSBC inclut une page de configuration dédiée à 3CX en tant que récepteur de fax T.38 (« Configuration for 3CX PBX Server with the ProSBC to receive T38 Faxes » dans la section de provisionnement 3CX). Cette page est la référence adéquate lorsque 3CX est du côté réception d’un chemin fax ; la configuration qu’elle décrit s’articule avec les réglages Fax T38 côté ProSBC.

Pour les autres intégrations PBX (Asterisk, FreePBX, FreeSWITCH, FusionPBX, VitalPBX, Yeastar, Wildix, Brekeke, Sippy, Cisco UCM, Avaya IP Office, VoIP.ms), les pages d’intégration par fournisseur dans la documentation ProSBC font autorité. Le comportement fax interagit avec la gestion fax propre à chaque PBX, et le chemin le plus sûr est le schéma d’intégration documenté pour ce fournisseur spécifique plutôt qu’une hypothèse générique « T.38 devrait juste fonctionner ».

Questions fréquentes

Conclusion

Un fax T.38 fiable sur un SBC se résume à quatre choses bien faites. Le bon mode pour ce que chaque terminal prend réellement en charge, avec Fax T38 comme choix par défaut et Passthrough comme alternative réfléchie. Un chemin de tonalité propre pour que le CNG atteigne ProSBC avant la trame DIS. Une configuration NAT qui ne bloque pas le port RTP derrière un décalage Force Passive Mode. Et une NIC avec le déchargement de somme de contrôle UDP désactivé, pour que le noyau ne supprime pas silencieusement les paquets que l’application tente de recevoir.

Le panneau Fax Settings de ProSBC expose les contrôles ; tbsigtrace et tbreport fournissent la preuve. Une fois que ces éléments correspondent à une trace de référence fonctionnelle, T.38 cesse d’être une fonctionnalité instable et s’intègre à la base standard du trunk SIP.