Télécopie et VoIP


         Quand on est relié à l'internet par l'intermédiaire d'une Livebox, Freebox ou autre Câblebox, on bénéficie généralement, et le plus souvent exclusivement, de la téléphonie en VoIP liée à l'abonnement. C'est plutôt économique et les communications sont en général d'une qualité satisfaisante.
         Puisque notre box met à notre disposition une ou deux prises téléphoniques, on peut être tenté d'utiliser l'une d'elles comme représenté ci-dessous pour émettre et/ou recevoir des télécopies :



synop1.gif


            Même si je connais une personne, abonnée chez Free, qui s'en satisfait, les fournisseurs d'accès et opérateurs de téléphonie ne garantissent pas le fonctionnement de cette méthode dont les résultats sont variables. Parmi les facteurs défavorables le plus souvent et légitimement invoqués figure certainement le codec audio mis en œuvre par l'ATA (Adaptateur pour Téléphone Analogique) inclus dans la box et le caractère aléatoire de la transmission des flux de données sur un réseau qui n'offre pas, comme le réseau téléphonique commuté, un canal unique entièrement dédié à la communication en cours.
        Pour réduire la bande passante consommée, les codecs audio mis en œuvre dans les box ne sont en effet habituellement pas ceux qui permettraient une transmission suffisamment fidèle des signaux échangés par les fax. L'utilisateur n'a pas le choix du codec qu'il utilise et n'en est souvent même pas informé.
        En outre, les paquets de données transportant ces signaux subissent des retards parfois très importants et, ce qui est plus grave, variables, en cours de route. Il arrive même que certains paquets n'arrivent jamais à destination.
         
        Pour ceux qui lisent l'anglais, ces raisons et quelques autres sont clairement développées au début de cet exposé : http://www.soft-switch.org/foip.html . On y apprend aussi qu' un protocole nommé T.38 a été conçu pour transmettre les télécopies « over IP », mais ce n'est pas ce dont je vais vous parler, pas plus que je ne vous parlerai des services commerciaux qui se chargent d'acheminer par fax (peut-être en T.38) les documents que vous leur envoyez par tout autre moyen. Ces solutions de substitution sont certainement excellentes et conviennent aux utilisateurs qui n'ont pas envie de se compliquer l'existence, mais ne méritent pas d'être décrites ici puisque leurs fournisseurs se chargent parfaitement de le faire.

        Si on trouvait un moyen pas trop onéreux d'imposer l'utilisation d'un codec audio approprié, il pourrait être intéressant de voir si cela ne suffirait pas à rendre possible la transmission de télécopies « over VoIP ». C'est ce que j'ai fait et que je me propose d'exposer ci-après. Attention toutefois, ces procédés ne vous réussiront pas forcément, vous êtes avertis. Ceux qui auront la patience de lire la suite jusqu'au bout découvriront l'existence de problèmes supplémentaires qui n'étaient pas prévus au départ de mon aventure et je n'ai probablement pas tout vu.

Solution avec un ATA séparé et un compte de VoIP chez un autre opérateur

        Le principe est le suivant :

synop2.gif


        Un véritable ATA du commerce est ici utilisé, l'ordinateur n'ayant pour seul rôle que d'en assurer la configuration lors de sa mise en service. L'un et l'autre sont interconnectés en ethernet via le routeur inclus dans la box. Comme les ATA du commerce présentent généralement au moins deux ports FXS, le téléphone peut utiliser un de ceux-ci ou rester sur celui de la box, ce dernier choix ayant ma préférence.

        J'ai personnellement utilisé un exemplaire du populaire, quoique aujourd'hui commercialement obsolète, PAP2T de la marque Linksys et n'ai d'autre compte de VoIP que celui souscrit il y a quelques années chez OVH. Sur le site de cet opérateur sont justement données des instructions très utiles, adaptées à la France, pour configurer le PAP2T dans la perspective de l'envoi et la réception de télécopies. 
http://guides.ovh.com/TelFaqPAP2TTips Notez que le codec G711a convient au moins aussi bien, en Europe, que le G711u préconisé.
        Si vous espérez recevoir des télécopies, il faut normalement créer une règle de NAT dans le routeur de la box afin qu'il aiguille vers votre ATA les requêtes reçues de l'extérieur. À ce propos, il peut être nécessaire d'affecter à l'ATA le port SIP 5062 plutôt que 5060, ce dernier étant parfois confisqué au profit exclusif de la téléphonie officielle du FAI. (Cas de SFR et de sa NeufBox). Ce paramètre est à définir dans la configuration de l'ATA. Avec certaines box, la création de règle NAT n'est pas nécessaire si la fonction UPNP est activée. Avec d'autres, il faut en plus activer STUN dans l'ATA. Renseignez vous auprès de votre fournisseur d'accès ou sur les forums d'utilisateurs.

        Si vous n'avez pas de télécopieur, ce n'est pas grave, vous allez pouvoir utiliser votre bon vieux fax-modem analogique, celui qui vous permettait d'accéder à l'internet et au minitel avant l'avènement de l'adsl. Les miens - car j'en ai une petite collection - sont pour la plupart de la marque Olitec très répandue en France, c'est donc naturellement un Olitec que j'ai choisi pour jouer le rôle de fax-modem, plus précisément un modèle Speed'Com 2000 v.90. Les modems Olitec sont, par certains aspects, un peu particuliers. Leurs dernières évolutions vers le v.90 ou v.92 et l'implémentation des fonctions vocales auraient été faites au détriment des fonctions les plus basiques comme le fax. Ne dédaignez donc pas les modèles simples même s'ils sont incapables de trafiquer à plus de 33600 bits/s. De toute façon le fax standard ne dépasse pas 14400 bits/s.
        Si votre ordinateur est apparemment dépourvu de port série, tout n'est pas forcément perdu car, souvent, ce port existe sur la carte mère et ne demande qu'à être raccordé au panneau arrière via la nappe et l'équerre qu'on peut, par exemple, prélever sur une épave d'ordinateur plus ancien. Si ce n'est pas le cas, vous avez encore la ressource d'ajouter une carte PCI adaptatrice qui vous fournira de un à quatre ports série. Il existe aussi des fax-modems qui se raccordent en USB, je ne sais pas s'ils sont utilisables sous Linux. Enfin, il est en principe possible d'utiliser un modem interne ou « winmodem » mais, sous Linux particulièrement, ce n'est guère recommandé.

Logiciel de télécopie

        Si vous possédez un télécopieur, cette section ne vous concerne pas, il s'utilise exactement comme sur le réseau commuté. En revanche, l'utilisation d'un fax-modem nécessite un logiciel adéquat. Après quelques errements, j'ai choisi efax-gtk dans sa version 3.2.11, qui est, à ma connaissance, l'outil le plus agréable pour exploiter, en mode graphique, toute la puissance du programme efax. Pour émettre seulement, la commande sendfax du paquet mgetty-sendfax convient également très bien mais ce logiciel ne gère que la classe 2 et il se trouve que les modems Olitec dont je dispose ne fonctionnent correctement, en réception, qu'en classe 1, et je souhaite aussi être en mesure de recevoir des télécopies. (La classe caractérise les échanges entre le modem et l'ordinateur, pas ceux entre fax.) Autre précieuse qualité, efax-gtk sait convertir et envoyer directement des documents aux formats pdf et postscript, ce qui libère l'utilisateur du souci d'une conversion préalable. Enfin, Efax-gtk permet d'émettre en l'absence de tonalité d'invitation à numéroter et de recevoir en l'absence de trains de sonnerie, ce qui facilitera grandement un autre mode d'utilisation que je décrirai plus loin. Efax-gtk prend en compte son propre fichier de configuration, indépendant de celui d'efax. Voici donc les lignes les plus utiles de mon fichier ~/.efax-gtkrc :


NAME: 0033972345678
         # (Car j'ai lu que certains fax n'aiment que les chiffres.)
NUMBER: 0033972345678
DEVICE: ttyS0
LOCK: /tmp
CLASS: 1

PAGE: a4                  
RES: fine
ADDR_IN_HEADER: No
REDIAL: No
RINGS: 1
DIALMODE: tone
INIT: S7=120 M2L2 %S1
CAPABILITIES: 1,3,0,2,0,0,0,0
LOG_FILE: efax-gtk.log
PARMS: -of -on -v ewin


        Les explications sur les paramètres sont données dans la page de man d'efax. Sous Mageia au moins, pour être autorisé à utiliser le device /dev/ttyS0 il faut appartenir au groupe dialup.
        Concernant l'émission, l'option -of impose un contrôle de flux « virtuel » entre ordinateur et fax-modem, ce qui s'avère indispensable avec mes modems Olitec. En cas d'échec de la transmission, il peut être avantageux de réduire le débit à 7200 bits/s en remplaçant par un 2 le chiffre 3 des « capabilities » qui correspond à 9600 bits/s car plus la vitesse choisie est faible plus la transmission est robuste. Si le vent vous est favorable, vous pouvez au contraire essayer de monter ce chiffre à 5 pour 14400 bits/s.
        Concernant la réception, la commande Hayes AT%S1 de la séquence d'initialisation est nécessaire avec les modèles Self-Memory qui, en son absence, enregistrent les fax dans leur mémoire flash d'où il est ensuite très difficile, voire impossible, de les extraire sous Linux. Cette commande, comme beaucoup d'autres, ne figure pas dans le livret qui accompagnait normalement les modems Olitec, je l'ai trouvée ici :
http://nicolas.ecarnot.free.fr/pub/docs/commandessm.txt
        Toujours pour la réception, vous aurez probablement intérêt à dé-commenter la ligne imposant l'emploi de la classe 1. Avec mon Olitec, c'est obligatoire.


        Bien entendu, on peut aussi bien utiliser efax en ligne de commande ou, de préférence, le script fax fourni par efax et les commandes « fax answer », « fax receive » et « fax send ». Comme la version 3.2.9 d'efax-gtk était boguée, c'est ce que je faisais lors de mes premiers essais et voici ce que j'avais mis dans mon fichier de configuration ~/.efaxrc :


FROM="0033972345678"
NAME=
"0033972345678"
PAGE=a4
DIALPREFIX="T"
INIT="-iZ -i&FE&D2S7=60 -i&C0"
RESET="-kZ"
SPKR="-iM2L2"
CLASSINIT="-o1"        # Class 1
TXCAP="-c 1,3,0,2,0,0,0,0"
RXCAP="-c 1,3,0,2,0,0,0,0"
RXINIT="%S1"
TXINIT=""
VERB="ewin"    # show errors, warnings, progress & negotiation
VERBLOG="chewmainrxtf"    # log everything
DATAOPT="-j&C1 -j+FCLASS=0 -jS7=60"


        J'attire ici l'attention des utilisateurs des distributions Mageia et Mandriva qui auraient installé le paquet man-pages-fr sur une petite coquetterie qui m'a longtemps induit en confusion. Quand vous consultez la page de man d'efax, vous êtes immédiatement invité à consulter d'abord celle de fax. Vous faites donc "man fax" et, là, vous tombez sur une page en langue française qui documente le programme mgetty+sendfax qui, pourtant, n'offre pas de commande du nom de « fax ». Ne faites pas comme moi, ayez le réflexe d'appeler la bonne page, par exemple en faisant "LANGUAGE=en man fax" ou équivalent.

Mode opératoire

        Pour envoyer un fax avec efax-gtk, il suffit de cliquer sur le bouton « UN seul document » ou « PLUSIEURS Documents » et de choisir le ou les documents pdf ou ps dans le navigateur qui s'est ouvert, de saisir le numéro du destinataire dans la barre « Annuaire FAX » et enfin de cliquer sur le bouton « ENVOYER FAX ».

        Pour se mettre en attente de réception, cliquer simplement sur le bouton « Mode VEILLE ». Les documents reçus seront enregistrés automatiquement dans le home de l'utilisateur sous forme d'images TIFF à raison d'une image par page.


        Je n'ai pas beaucoup utilisé ce système en dehors de quelques rapides essais. Je l'ai vite abandonné parce que la présence de l'ATA dans mon réseau local rendait inutilisables les softphones dont j'ai besoin de temps à autre pour des communications en visiophonie. Mais j'avais désormais la preuve que le net n'est pas un si mauvais média pour la transmission de télécopies, du moins avec Orange comme FAI et OVH comme opérateur de téléphonie. La porte était donc ouverte à une éventuelle utilisation d'un autre procédé plus original.


Solution avec Ekiga et un compte de VoIP chez un opérateur

         J'utilise présentement la distribution GNU/Linux Mageia 3 mais ce qui suit devrait être aisément transposable à Windows puisque les fabricants de modems analogiques fournissent les pilotes pour ce système d'exploitation ainsi que des programmes de télécopie et puisque Ekiga existe aussi en version pour Windows.
       Pour commencer, voici le montage à réaliser :



synop3.gif


          En ce qui concerne l'adaptateur 2fils / 4fils, on peut s'inspirer de ce qui est proposé vers le milieu de cette page :
http://www.epanorama.net/circuits/teleinterface.html#simplehybrid ou peut-être dans cette autre page :
http://www.sonelec-musique.com/electronique_realisations_ligne_tel_insert_001.html
        Pour ma part, j'ai pu obtenir d'excellents résultats avec un schéma simplissime parce que ma carte son, que j'utilise habituellement pour diffuser musique et sons divers avec des enceintes passives, est un modèle possédant une sortie amplifiée. Il s'agit d'une carte de bas de gamme qui fut très diffusée il y a, je pense, une petite dizaine d'années, une Creative Labs CT4810 avec circuit amplificateur TDA1517P. En l'occurrence, ce n'est pas la puissance qui est recherchée mais la très faible impédance - j'ai mesuré 0,33 ohm - du générateur que constitue sa sortie quand les cavaliers d'aiguillage sont positionnés comme il convient, c'est-à-dire 1-3,2-4. Voici ce schéma :


adaptateur1.gif


        Les valeurs des composants ne sont pas très critiques. Je les ai choisies en modifiant les valeurs de l'impédance standard, qui sont 270 ohms, 750 ohms et 150 nF, pour tenir compte de l'impédance finie de l'entrée ligne, supposée égale à 10000 ohms. Par exemple, j'ai choisi 136 nF parce que cette valeur s'obtient facilement avec 2 fois 68 nF en parallèle mais une 150 nF va aussi bien. Détail important, la sortie de la carte son étant stéréophonique, il faut choisir la voie gauche ou la voie droite mais éviter de relier les deux ensemble car, si vous oubliiez que votre interface est branchée et demandiez à votre ordinateur de lire de la musique, l'ampli de sortie risquerait d'en souffrir. Choisissez la voie gauche, qui correspond à la pointe du jack stéréo mâle. Le montage peut être fait sur une plaque pré-percée avec pistes ou pastilles de cuivre ou tout autre support, sur une barrette à cosses ou à vis ou des dominos, voire en l'air.

        J'ai également obtenu de bons résultats en remplaçant le dipôle RC (l'ensemble des trois composants R1, R2 et C) par une seule résistance de 620 ohms. Essayez, et si ça marche vous pourrez avec un peu d'habileté loger cette résistance dans la fiche jack associée à la prise d'entrée ligne. (La valeur théorique serait plutôt 640 ohms mais ce n'est pas une valeur standard dans les séries courantes.)

        Comme je sais que tout le monde ne dispose pas d'une carte son aussi musclée que la mienne, j'ai aussi réalisé (au brouillon) à votre intention et essayé avec succès un montage incluant des amplificateurs opérationnels, librement inspiré d'un de ceux du site epanorama cité plus haut. En voici le schéma :


adaptateur2.gif
       

        Plus simplement, un AOP monté en suiveur devrait abaisser suffisamment l'impédance d'une sortie ligne standard pour permettre l'utilisation du schéma précédent avec une carte son sans amplificateur, mais je n'ai pas essayé.

Logiciel de téléphonie


        La version 4.0.1 d'Ekiga est disponible depuis peu sous Mageia et d'autres distributions. Je ne l'ai pas encore beaucoup utilisée mais elle semble se comporter aussi bien que la 3.99 qui m'a servi pour mettre au point la méthode.
        Il faut bien entendu créer dans Ekiga un compte avec les références fournies par l'opérateur de téléphonie, identifiant et mot de passe notamment, et être enregistré chez cet opérateur, ce qui déjà permet de téléphoner. On peut aussi s'enregistrer chez ekiga.net si on veut tester sa configuration avec le robot d'Ekiga, sip:500@ekiga.net. Le robot d'Iptel est plus aimable car il répond à tout le monde : sip:echo@iptel.org et répète immédiatement ce que vous lui dîtes. Sip:music@iptel.org vous aide à identifier ce qui ne va pas si le test avec echo échoue.
        Pour la raison déjà citée, notamment pour les clients de SFR, il convient de préférer le port 5062 au 5060. Voici un aperçu de ma configuration d'Ekiga, j'espère ne rien oublier d'important :

Détection du réseau : activée
Compte activé : Mon compte OVH
Délai avant rejet des appels non répondus : 120 s
Codecs audio : Seuls PCMA et PCMU sont activés
Vidéo : Désactivée
Périphérique audio de  sortie : Ensoniq AudioPCI [ES1371 DAC1] (PTLIB/ALSA)
Périphérique audio d'entrée : Ensoniq AudioPCI [ES1371 DAC2/ADC] (PTLIB/ALSA)
Paramètres réglables seulement dans gconf-editor :
STUN est activé,  stun_server = stunserver.org
tcp_port-range : 30000-30100
udp_port_range : 5060-5100
listen_port : 5062

        Nota : Même si le périphérique audio se trouve être le périphérique par défaut, il peut ne pas être indifférent de choisir « default » ou de le désigner nommément dans la configuration d'Ekiga, le comportement d'ALSA risque de ne pas être le même. Par précaution, j'évite systématiquement « default » pour cette raison.

Réglages du son

        Avec alsamixer, dans le cas d'utilisation de ma carte son avec sortie amplifiée je règle :
Master = -18 dB
PCM = 0 dB
Line = M (muet)
Capture = 0 dB (choix line)
Toutes les autres entrées sont désactivées.

        Dans le cas d'utilisation d'une sortie ligne ordinaire, et donc nécessairement d'un adaptateur actif, il convient de régler Master à environ -6 dB. Toutes ces valeurs sont données à titre indicatif, vos propres essais vous conduiront probablement à adopter des valeurs plus ou moins différentes.

Logiciel de fax

        Pour l'émission, efax-gtk convient parfaitement, avec la configuration déjà décrite. La version 3.2.11 permet de recevoir un fax sans que le modem ait détecté un signal de sonnerie, ce qui n'était pas possible avec la version boguée 3.2.9 fournie par Mageia 2. On peut donc actuellement utiliser efax-gtk aussi bien pour la réception que pour l'émission.

Mode opératoire pour émettre

          Le modem Olitec est alimenté et relié à la carte son par l'intermédiaire de l'adaptateur 2fils/4fils. Efax-gtk et Ekiga sont en cours d'exécution.

        Dans efax-gtk, choisir le ou les documents à envoyer et laisser vide le champ « Annuaire FAX » puis cliquer sur le bouton « ENVOYER FAX ».  Dans une fenêtre pop-up surgit le message « No fax number specified. Do you want to send the fax on an open connection? », ne pas répondre pour l'instant.

        Dans ekiga, lancer l'appel vers le destinataire du fax. On voit que ce dernier décroche quand l'icône du combiné devient rouge.

        Dans efax-gtk, répondre à la question précédente en cliquant sur le bouton « Valider ».

        En fait, l'enchaînement chronologique de ces actions n'est pas critique si les time-out (120s dans ekiga et 120s dans efax-gtk sont choisis assez large.)

Mode opératoire pour recevoir

         Un appel est reçu par ekiga. On en est averti, soit par le pop-up à l'écran, soit par le signal sonore si on a pu diriger celui-ci vers une autre carte son.  Prendre la communication puis, sans attendre, cliquer dans efax-gtk sur le bouton « répondre à l'appel ».


Autres softphones et autres problèmes

        Ekiga n'est plus le seul softphone qui m'ait donné satisfaction dans ce rôle inhabituel de vecteur de télécopie. Qutecom s'est avéré tout aussi efficace ainsi que Linphone dans sa version 3.7 beta qui bénéficie depuis la mi-janvier 2014 d'un correctif concernant sa gestion du protocole SIP. Que Simon Morlat, le père de Linphone, en soit ici remercié. ZoIPer également, à la condition de désactiver la fonction fax (prévue pour travailler en T.38) dans sa configuration. Même X-Lite, exécuté sous Linux par l'entremise de Wine, s'en sort parfaitement.

        Mais mes échecs répétés antérieurement avec Linphone m'ont permis de mettre en évidence un problème inattendu qui se pose avec certains opérateurs et que ne résolvent pas tous les softphones. (Et que ne résout pas non plus l'ATA de mon modem routeur SpeedTouch 716v5). Quand un télécopieur répond à votre appel, il émet en ligne des tonalités particulières qui sont l'amorce normale du dialogue entre télécopieurs. L'opérateur (OVH dans mon cas) trop zélé, reconnaissant qu'il s'agit d'une conversation entre télécopieurs, propose alors l'utilisation du protocole T.38 et, si votre softphone ne décline pas fermement cette invite, se met illico à vous envoyer du T.38 que, bien sûr, aucun softphone (sauf peut-être Zoiper) ne sait retraduire en tonalités exploitables par votre propre télécopieur ou fax-modem. C'est alors le début d'un dialogue de sourds qui ne prend fin que lorsque l'un des deux terminaux, las d'attendre une réponse cohérente à ses signaux, se résout à raccrocher. Dans mon cas personnel, ce comportement de mon opérateur est d'autant plus navrant que je n'ai pas souscrit d'abonnement au service de fax qu'il propose et qu'il n'a donc aucune raison d'écouter, fût-ce par une machine, les signaux audio que j'échange avec mes interlocuteurs.
        Si votre opérateur ne propose pas le T.38, n'importe quelle version de Linphone vous conviendra tout aussi bien ainsi que, probablement, beaucoup d'autres softphones. Si, au contraire, le vôtre se comporte comme le mien, et si vous ne voulez d'aucun des cinq softphones sus-cités, il vous reste plusieurs solutions :
        - Obtenir de votre opérateur qu'il modifie la configuration de votre compte sur son UAS (User Agent Server),
        - Changer d'opérateur,
       
- Trouver un autre softphone qui sache dire NON,
        - Intercaler entre votre softphone et le monde extérieur un B2BUA comme Asterisk ou un proxy capable de transformer en message de refus le message d'acceptation de votre softphone. SIPProxy
http://sourceforge.net/projects/sipproxy/ est le logiciel idéal pour jouer ce rôle car il est facile à installer et à mettre en œuvre sur le même ordinateur où est déjà installé le softphone et consomme peu de ressources. Ce programme vous permet notamment, au moyen d'expressions rationnelles, de modifier le contenu des paquets SIP, qui ne sont rien d'autre que du texte humainement lisible, et qui sont à la VoIP ce que la signalisation est à la téléphonie traditionnelle. Voici comment je l'ai configuré pour pouvoir envoyer des télécopies avec Linphone 3.6.0, rien n'est plus clair que de vous livrer son fichier de configuration :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<SIPProxyConfig>
<ProxyMode>
<PBX ip="91.121.129.20" port="5060"/>             # 91.121.129.20 = l'IP du proxy d'OVH
<ProxySocket ip="192.168.1.6" port="5064"/>       # 192.168.1.6 = l'IP locale de mon pc
<Client ip="192.168.1.6" port="5062"/>            # 5062 = port d'écoute de Linphone
<Transformation fileRef="DefaultTransformationConfig.xml"/>
<DynamicTransformation fileRef="DynamicTransformationConfig.xml"/>
</ProxyMode>
<TestCaseMode>
<TestCaseSocket ip="127.0.0.1" port="5064"/>
<Target ip="192.168.1.6" port="5062"/>
<TestCaseDir path="TestCases"/>
</TestCaseMode>
</SIPProxyConfig>


Et voila surtout ce que j'ai mis dans le fichier DynamicTransformationConfig.xml, c'était le plus difficile :

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <TransformationConfig> <Definitions/> <TransformationRules> <Pbx2Client/> <Client2Pbx> <Rule isActive="true" regex="(SIP/2.0\ +200 OK)(\r\n)((.*\r\n)*)(Content-Type: application/sdp\r\n)((.*\r\n)*)(Content-Length: +\d+\r\n)((.*\r\n)*)(m=image.*\r\n)((.*\r\n)*)" replacement="SIP/2.0 488 Not Acceptable Here$2$3Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, SUBSCRIBE, NOTIFY, REFER, MESSAGE, INFO$2$6Content-Length: 0$2$2"/> </Client2Pbx> </TransformationRules> </TransformationConfig>

Enfin, pour être sûr que tous les messages SIP entre Linphone et le proxy d'OVH transitent bien par SIPProxy j'ai légèrement modifié la configuration de mon compte OVH dans Linphone comme suit :

[proxy_3] reg_proxy=<sip:192.168.1.6:5064> reg_route=<sip:192.168.1.6:5064> reg_identity=sip:0033972345678@sip.ovh.fr reg_expires=3600 reg_sendregister=1 publish=0 dial_escape_plus=0

ASTERISK, solution universelle


        Malheureusement, tous les softphones n'offrent pas à l'utilisateur la possibilité de définir un paramètre comme le « reg_route » ci-dessus ou autre « route ». Je n'ai notamment rien trouvé de tel dans les fichiers de configuration de SFLPhone et Twinkle et n'ai donc pas réussi à détourner vers SIPProxy leurs messages SIP. À ce jour, je n'ai pas trouvé de meilleure solution que d'installer Asterisk à bord du PC ou sont installés ces softphones récalcitrants ou d'un autre PC de mon réseau local. Asterisk est un B2BUA (Back To Back User Agent) très réputé dans le monde de la téléphonie en général et particulièrement dans celui de la téléphonie sur IP. Vous et votre softphone quelconque communiquez avec Asterisk et Asterisk se charge de la communication avec votre opérateur et votre interlocuteur final en refusant, par défaut, le T.38. On peut trouver cette solution un peu lourde car Asterisk est un gros programme qui occupe beaucoup de place sur le disque dur mais, en fait, il utilise peu de ressources quand on ne lui demande que des services élémentaires comme ce fut le cas dans mon exemple d'utilisation. Si on tient absolument à économiser de la mémoire, on peut parfaitement ne charger que les modules d'Asterisk strictement nécessaires, mais je n'ai pas encore fait le tri et je vous assure que mon Asterisk est très à l'aise avec tous ses modules sur l'eeePC où je l'ai installé sous Mageia 3. J'ai ainsi pu utiliser Twinkle (sous Debian Jessie) et SFLPhone (sous Fedora 18) pour envoyer depuis mon PC de bureau des documents de 36 pages bien chargées à la vitesse de 14400 bit/s avec zéro erreur dans toutes les pages.
        Je ne vous donne pas aujourd'hui mes fichiers de configuration d'Asterisk parce qu'ils ne sont pas complètement au point et que je n'ai pas encore réussi à recevoir des appels. Sachez seulement que je me suis très fortement inspiré de ceux proposés par mon opérateur :  http://guides.ovh.com/AsteriskEtForfaitOVH
        Sachez aussi qu'Asterisk permet d'établir des communications vocales, et donc « faxiales » sans le concours d'un softphone et même, à la rigueur, sans le concours d'un logiciel de télécopie, mais je n'ai qu'à peine commencé à explorer ces possibilités et, de toute façon, ce ne sera jamais aussi pratique qu'avec le softphone auquel on est habitué et un logiciel comme Efax-gtk.


Problèmes de son et de carte son

 

        Je dois signaler que, au cours de mes nombreux essais avec Linphone, j'ai constaté une grossière anomalie affectant la fréquence d'échantillonnage. Une communication audio étant établie avec PCMA ou PCMU comme codec audio, il est en effet facile de capturer à l'aide de Wireshark les paquets RTP émis et d'en faire l'analyse, le logiciel se chargeant d'effectuer tous les calculs et d'afficher les résultats sous une forme explicite, voire de décoder et enregistrer le flux audio aux fins d'analyse avec, par exemple, Audacity. Ma configuration du son, matérielle et logicielle, étant ce qu'elle est habituellement, c'est-à-dire avec ALSA sans Pulseaudio, il s'est avéré que mon Linphone émettait, non pas 8000 échantillons par secondes mais, systématiquement, 7969. On conçoit intuitivement qu'un tel décalage pose un énorme problème quand il s'agit de communiquer avec le réseau téléphonique qui opère à 8000 ech/s précisément. (Notamment, à la réception, son décalé vers les aiguës et à trous.) Après avoir fait de nombreux essais avec diverses distributions Linux, j'ai découvert un peu par hasard que l'utilisation de Pulseaudio avait pour effet de ramener la fréquence d'échantillonnage de Linphone à sa valeur nominale de 8000 ech/s. Plus tard, j'ai trouvé une autre solution donnant le même résultat avec ALSA et sans Pulseaudio. Cette configuration est suggérée ici sur le site de Linphone mais de façon peu détaillée. Dans mon cas, il suffit d'introduire la ligne suivante à la section [sound] de mon fichier .linphonerc :

alsadev=plughw:0,0

ce qui permet ensuite de choisir comme périphérique de capture et d'écoute sous l'onglet des paramètres multimédia de Linphone  « ALSA: plughw:0,0 ». À titre d'information, voici le contenu complet de ma section sound :


[sound]
alsadev=plughw:0,0
playback_dev_id=ALSA: plughw:0,0
ringer_dev_id=ALSA: Ensoniq AudioPCI
capture_dev_id=ALSA: plughw:0,0
local_ring=/usr/local/share/sounds/linphone/rings/sweet.wav
remote_ring=/usr/local/share/sounds/linphone/ringback.wav
echocancellation=0
dc_removal=0
eq_active=0
echolimiter=0

Ainsi que les sections [net], [sip] et [rtp] également importantes :

[net]
download_bw=0
upload_bw=0
firewall_policy=2
mtu=0
stun_server=stunserver.org
adaptive_rate_control=0
nat_address=

[sip]
sip_port=5062
guess_hostname=1
contact="moi" <sip:gegetel@192.168.1.6:5062>
inc_timeout=60
use_info=0
use_ipv6=0
default_proxy=3
register_only_when_network_is_up=1
sip_tcp_port=0
use_rfc2833=0
media_encryption=none
sip_tls_port=0
in_call_timeout=0
delayed_timeout=4
register_only_when_upnp_is_ok=0
only_one_codec=1

[rtp]
audio_rtp_port=7078
video_rtp_port=9078
audio_jitt_comp=60
video_jitt_comp=60
nortp_timeout=30
download_ptime=0
upload_ptime=0
audio_adaptive_jitt_comp_enabled=0
video_adaptive_jitt_comp_enabled=0
rtcp_enabled=0


   
Cette configuration particulière du son semble dégrader la réponse en fréquence qui devient identique à celle d'Ekiga mais les télécopies sont transmises de façon reproductible à la vitesse de 14400 bits/s et quasiment sans erreurs et c'est bien le principal. (Essais répétés effectués avec un document de 36 pages bien chargées.) Sans doute les égaliseurs inclus dans les télécopieurs et les fax-modems y sont ils pour quelque chose. La copie d'écran ci-dessous illustre cette différence initiale entre réponses en fréquence qui reste assez mystérieuse à mes yeux. Une histoire de plugin ALSA, m'a-t-on suggéré.


Ekiga-Linphone-reponses.gif


        Enfin, raffinement suprême, j'ai ajusté la fréquence d'horloge de ma carte son de manière telle que la lecture d'un fichier audio synthétisé à une fréquence quelconque produise un signal à cette fréquence exacte. Cela nécessite un fréquencemètre bien étalonné et se réalise, dans le cas habituel d'une fréquence trop élevée, par adjonction d'un condensateur ajustable d'une cinquantaine de pF entre une patte du quartz et la masse. Je ne prétendrai pas que cette opération soit réellement indispensable mais elle ne peut qu'être favorable à une transmission sans erreurs.


Remerciements

        Je remercie les amis qui ont accepté de réaliser avec moi divers essais et mesures qui m'ont permis de mettre hors de cause les problèmes de temps de propagation et de gigue que j'ai longtemps soupçonnés d'être responsables de mes difficultés, ainsi que les contributeurs innombrables qui partagent leurs connaissances sur les forums usenet et sur la toile en général, puisque c'est là que j'ai puisé l'essentiel de celles (les connaissances) que je n'ai fait que rassembler ici de façon plus ou moins cohérente.

        Merci de me faire part de vos avis, critiques constructives, suggestions et questions sur le sujet de cette page en m'écrivant à l'adresse suivante : geo.cherchetout@laposte.net  Je ne serai pas forcément capable de répondre à vos questions mais je pourrai toujours les répercuter ici dans l'espoir que quelqu'un d'autre y réponde.      


Auteur : Gegetel ~ Première édition : 21 juin 2013 ~ Dernière modification : 20 février 2014



Valid HTML 4.01 Transitional