Tests VoIP & Asterisk & SoftModem

Il y a déjà pas mal de sujets sur LE sujet. A mon tour !

… Et d’autres [LudoJoey/MiniPavi, etc …]

Nombreux sont ceux qui s’y sont essayés, rares sont ceux qui sont parvenus à de BONS (*) résultats hormis JHR/Hacker.

J’ai monté un environnement de test, j’ai des heures de tests et de mesures. Je vais, dans un premier temps, décrire ici l’environnement, le robot, puis les premiers résultats, actuellement conclusifs de « Je ne sais pas » …

  • Dernier RPi OS 64 bits version complète avec GUI (pas bien mais ne semble pas en cause)
  • Dernière distribution « PhreakNet » d’Asterisk V22 incluant PjSip, SpanDSP, APP_SoftModem
  • TCP (et non pas UDP)
  • Suppression d’écho désactivée (préco SteeveU)
  • Codec G711 aLaw (consensus des sachants - 8Kb/s) exclusif

==> Pour ceux qui ne suivraient pas, SpanDSP est LA librairie qui permet, entre autres, de détecter la porteuse et les bits transmis [canal montant] (les variations de fréquences reçues) sur une liaison VoIP, en conséquence, en (a)FSK (V23, c’est du (audio) Frequency Shift Keying)., mais aussi et surtout la génération de la porteuse et des bits du canal descendant (variations des fréquences envoyées). J’ai trouvé Not Black Magic: AFSK qui est pas mal pour décrire comment ça marche.

[Minitel] : J’utilise un M2 Alcatel Cv; (pas trouvé d’image propre) qui reste initialisé en veille en permanence.

[Câbles Ethernet] : 3 câbles de 2m « pro » (CAT à vérifier)

[ATA] : Assure la conversion Analogique <=> Numérique pour la liaison SIP. (Plus de détails sur sa configuration ici, plus tard)

[ASTERISK : APP_SoftModem] : Hormis les détails d’accès au serveur Telnet et de format (V23, 7 bits, 1 stop, parité paire) ne permet que de ‹ jouer › sur les niveaux TX et RX… Le SoftModem s’appuie exclusivement sur SpanDSP. J’ai trouvé assez peu d’information sur les paramètres utilisés dans la vraie vie.

  • Le versioning d’APP_SoftModem est malheureusement opaque. La version inclue à la distribution PhreakNet d’Asterisk comporte les mentions
    • 2010 de C.Groeger (Version originale, dérivée de APP_Fax)
    • 2018 de Rob O’Donnell (ajout d’options pour la parité)
    • 2021/2023 de A.Naveen (corrections pour compilation avec Asterisk v18, support du 45 et 50 Bps pour TDD, documentation XML)
  • Le source suggère des valeurs (float) par défaut de RX= -35 et TX= -28
  • John Newcombe (Telstar) suggère RX=2 et TX=2 avec un ATA Grandstream HT802 ==> Realy ?
  • KikiHC16 semble utiliser les valeurs par défaut @KiwiHC16 mais il utilise une carte Digium TDM410 en guise d’ATA et Asterisk v16
  • Je ne sais pas si quelqu’un d’autre a testé/décrit d’autres valeurs (et dans quel environnement - l’ATA et le Minitel (modem) utilisé doivent aussi avoir leur importance !) @ludojoey @nathaantfm
  • Comme un gros crétin, j’ai commencé à tester avec des valeurs RX/TX très éloignées (0 à +50) !

[ASTERISK : SPANDSP]
A voir

[ASTERISK : PJSIP]

  • Un Endpoint (« EndPoint/Point de terminaison » == Un compte client SIP) [ici 2000] est affecté à une ligne analogique de l’ATA.
  • Des EndPoints (1000,1001, 1002) sont affectés à divers clients SIP LinPhone ‹ pour test ›.

[ASTERISK : DIALPLAN / EXTENSIONS]

  • Des extensions (« Extension » == Numéro d’appel) sont configurées sur le plan de numérotation interne (from-internal) pour utiliser le SoftModem sur le schéma : Set(VOLUME(TX)=XX)/Set(Volume(RX)=YY)/Answer()/Softmodem(<@IpDuRobot>,< PortDuRobot >,ld(7),s(1),e)/Hangup()
    • [Aujourd’hui !] Pour les numéros 3600 à 3619 : XX=4, YY=< Deux derniers chiffres de l’extension>
    • [Aujourd’hui !] Pour les numéros 3620 à 3639 : XX=< Deux derniers chiffres de l’extension>, YY=20

[Robot]
Sur ce RPi (initialement, j’avais prévu d’utiliser un autre RPi afin de laisser Asterisk 100% seul ; à l’usage, cette précaution semble inutile avec, au maximum, 2% de CPU mangés par Asterisk et 2% par le robot), j’ai fait un robot basé sur TCPSER et Python-TelnetServer d’OliverLSanz. Ce robot est constitué de plusieurs parties/fonctionalités :

  • Serveur Telnet : Destiné à s’interfacer avec le ‹ client › ouvert par APP_SoftModem lors des appels aux extensions où il est configuré [une fois que la connexion est établie (détection de porteuse) ou avant (dès la communication SIP est établie) ?]
    • Ce serveur est capable de prendre en compte plusieurs sessions simultanément.
    • Les émissions sont bufferisées en amont par le robot, cadencées de telle sorte que le moins de données possibles soient en transit dans les buffers de la pile IP.
  • Connexion série : Destinée à piloter le Minitel appelant
    • Etablissement de la communication (remise à l’état initial du terminal, numérotation pour appel de l’extension choisie, connexion du modem)
    • A tout moment, suivi de l’état du terminal (connexion, etc). En détail suivi des SEP50/53/59, interrogation du terminal avec les commandes protocoles adéquates.
    • Une fois la connexion établie, transmission de l’identifiant du port série (nécessaire au robot pour faire le lien entre la session Telnet et le port série correspondant). Permet aussi de valider un minimum de la qualité de la transmission montante.
    • Toutes les émission sont bufferisées en amont par le robot et cadencées de telle sorte que le moins de données possibles soient en transit dans l’ensemble des buffers série (et éventuellement des piles IP intermédiaires).
    • Toutes les émissions sont temporisées.
    • Evolutions prévues/possibles
      • Utilisation de 2 ports série/2 minitels afin de pouvoir tester les M1 qui ne disposent pas de numéroteur
      • Utilisation du mode RFC2217, supporté par TCPSER, afin de pouvoir faire un test distant
      • Plusieurs tests simultanés (avec plusieurs ports série/minitels numéroteurs)

Le robot répète autant de fois que souhaité (10, à aujourd’hui) les cycles de test.
Un cycle de test s’effectue sur une plage donnée d’extensions (3600 => 3619 à aujourd’hui) configurées différemment.
Un test fonctionne sur 2 phases :

  • L’établissement de la communication « Minitel <> SoftModem » sur l’extension donnée (en conséquence, un paramètre RX et TX spécifique)
    • Initialisation OK ou KO
    • Numérotation OK ou KO
    • Connexion OK ou KO
    • Identification du port série OK ou KO
  • Mesure (observation) de la qualité de la transmission descendante en cas de succès de la phase d’établissement de connexion
    • Deux séries de séquences de caractères sont utilisées successivement [numériques puis alphanumériques]
    • Pour chaque série de séquence de caractère, un certain nombre de salves (aujourd’hui, 21) de séquence de caractères (aujourd’hui, 120) sont transmises en sens descendant.
    • Entre chaque salve, un délais d’une seconde est imposé en plus de la durée de transmission de la séquence de caractères.
    • En cas de déconnexion, fin de l’observation
    • Comparaison du nombre de caractères entre la séquence envoyée et reçue
      • Si identique, comparaison des caractères entre la séquence envoyée et reçue
        • Si différent, échec noté pour cette série [BUG à corriger ici, il faudrait vérifier/noter l’absence/présence de caractères dans le sens montant]
        • Si identique, succès noté pour cette série et vérification de l’absence/présence de caractères dans le sens montant
      • Si différent, échec noté pour cette série [BUG à corriger ici, il faudrait vérifier/noter l’absence/présence de caractères dans le sens montant]
  • Log du résultat dans un CSV à chaque fin de test ou à chaque observation
    • Date/Heure
    • Numéro du cycle de test
    • L’état d’avancement du test (phase d’avancement)
    • Le numéro appelé
    • Succès de numérotation
    • Succès de connexion
    • Succès de correspondance ‹ port série › <=> ‹ Client Telnet ›
    • Numéro de session telnet
    • Numéro de la salve
    • Succès/Echec de la salve
    • Cause de l’échec (longueur, différence, caractères reçus)
    • Details

[BUG : La dernière extension du dernier cycle n’est jamais testée, sauf à n’avoir qu’un seul cycle et une seule extension ?]

[Désolé, c’est très long, mais je voulais être précis]

Dans le post suivant, le condensé des résultats obtenus.
==> Après, on pourra discuter méthodologie et suggestion.

(*) BONs résultats : avec une ligne RTC normale/décente, il n’y avait juste ‹ jamais › d’erreur de transmission en V23. Je voudrais essayer de parvenir à 100% de succès pour au moins 10Ko transmis.

4 « J'aime »

Résultats des tests

28/01/2025 : TX de 0 à +50, RX=20, 10 cycles, 21 salves de 2 séquences de 120 caractères

  • 48,33% d’échec de connexion
  • 1302 salves observées en 1h35
  • Meilleurs résultats avec TX de 10 à 30
    • TX=0/RX=20:
      • 0% Succès
      • 1 échec de connexion
    • TX=10/RX=20:
      • 99,47% Succès TX (0 salve avec caractère reçus)
      • 1 échec de connexion
    • TX=20/RX=20 :
      • 98,02% Succès TX (4 salves avec caractère reçus)
      • 4 échecs de connexion
    • TX=30/RX=20 :
      • 98,02% Succès TX (4 salves avec caractère reçus)
      • 4 échecs de connexion
    • TX=40/RX=20 :
      • 0% Succès
      • 10 échecs de connexion
    • TX=50/RX=20 :
      • 0% Succès
      • 9 échecs de connexion

29/01/2025 : TX de +10 à +29, RX=20, 10 cycles, 21 salves de 2 séquences de 120 caractères

  • 13,00% d’échec de connexion
  • 6090 salves observées en 6h32
  • Succès TX global 98,75% → Pas de tendance claire 75 salves émises correctement mais avec au moins 1 caractère reçu
    • TX=10/RX=20:
      • 99,21% Succès (3 salves avec caractère reçus)
      • 1 échec de connexion
    • TX=11/RX=20:
      • 99,05% Succès TX (0 salve avec caractère reçus)
      • 5 échec de connexion
    • TX=12/RX=20 :
      • 99,32% Succès TX (0 salve avec caractère reçus)
      • 0 échecs de connexion
    • TX=13/RX=20 :
      • 99,29% Succès TX (1 salves avec caractère reçus)
      • 0 échecs de connexion
    • TX=14/RX=20 :
      • 98,57% Succès (6 salves avec caractère reçus)
      • 2 échecs de connexion
    • TX=15/RX=20 :
      • 98,81% Succès (3 salves avec caractère reçus)
      • 1 échecs de connexion

29/01/2025 : TX=4, RX de 0 à +9, 10 cycles, 21 salves de 2 séquences de 120 caractères

  • 1,00% d’échec de connexion ==> Meilleur résultat pour le moment
  • 4117 salves observées en 4h02
  • Succès TX global 98,66% → Pas de tendance claire 46 salves émises correctement mais avec au moins 1 caractère reçu ==> Globalement, moins bon que le test précédent. Je remarque pour le moment de meilleurs résultats quand TX est proche de RX
    • TX=4/RX=0:
      • 98,81% Succès TX (5 salves avec caractère reçus)
      • 0 échec de connexion
    • TX=4/RX=1:
      • 97,86% Succès TX (3 salve avec caractère reçus)
      • 0 échec de connexion
    • TX=4/RX=2 :
      • 97,88% Succès TX (5 salve avec caractère reçus)
      • 1 échecs de connexion
    • TX=4/RX=3 :
      • 98,57% Succès TX (6 salves avec caractère reçus)
      • 0 échecs de connexion
    • TX=4/RX=4 :
      • 99,05% Succès TX (0 salves avec caractère reçus)
      • 2 échecs de connexion
    • TX=4/RX=5 :
      • 99,76% Succès TX (1 salves avec caractère reçus)
      • 0 échecs de connexion

==> Je ne poursuis pas la resaisie, une feuille excel serait plus simple !

Je n’ai pas énormément d’expérience au sujet de la qualité de connexion, tout ce que je peux ajouter, c’est que mon serveur uniquement basé sur PJSIP + SpanDSP utilise la valeur TX par défaut de -14 et une valeur RX réduite à -50 (par défaut -30, mais j’avais eu des retour d’échecs de connexion). La valeur -50 est peut-être extrême, ça pourrait sûrement être augmenté à -40…

J’essayerai d’ajouter des infos quand je retournerai dans ce terrain là…

1 « J'aime »

Ah - J’ai trouvé ici GitHub - freeswitch/spandsp: SpanDSP is a low-level signal processing library that modulates and demodulates signals commonly used in telephony, such as the "noise" generated by a fax modem or DTMF touchpad. une ref de version : « 20230620 140530 » et tes valeurs par défaut. ==> Celui que tu utilises ?

La distrib PhreakNet contiendrait une version « 20110122 075024 » … Moyen… Et je ne trouve pas le source - Si, enfin, rien à voir avec le truc sur GitHub, c’est directement dans app_softmodem.c - les valeurs par défaut sont RX= - 35 et TX = - 28.

Par contre, j’ai trouvé dans la distrib un spandspflow2pcap.py qui peut être intéressant.

spandsp/src/fsk.c at 933d40db635d6b2717dc4ee9cb3f72be06b0e8ee · freeswitch/spandsp · GitHub pour les valeurs par défaut en question (j’utilise pas app_softmodem.c, uniquement spandsp/fsk)

Si ça peut aider, sur MiniPavi j’utilise t=-28, r=-38, volume tx=2 et volume rx=4

Aussi j’ai remarqué que, selon les utilisateurs, le taux d’erreur peut varier et même être de 0%.

Donc la configuration du serveur ne fait pas tout. La configuration utilisateur aussi sans doute, ainsi que probablement le cheminement des paquets sur le réseau. Par exemple on peut peut être s’attendre à de meilleurs résultats si le serveur et le client sont chez le même fournisseur sip…

Ma config asterisk est dans le github de MiniPavi.

Côté ATA ne pas oublier de désactiver le jitter buffer adjustment (par exemple sur le SPA112). Généralement, le jitter s’ajuste en début d’appel donc ajouter un délai (comme le message de connexion sur Minipavi) permet d’aider contre ça. L’annulation d’écho doit aussi être désactivée. Même chose pour le serveur.

Généralement, c’est mieux de se dire qu’on ne puisse pas adapter la config du client et essayer de rendre la communication la meilleure possible côté serveur.

Ou même avoir des comportements indéterminés ! J’ai réussi à faire planter mon serveur avec un Grandstream HT801 et je n’ai pas réussi à reproduire ça avec un quelconque autre appareil (et je n’ai plus ce HT801).
Le plantage était dû à une erreur d’assertion, mais je n’ai aucune idée de comment il a pu atteindre cet état.

Il y a aussi le problème des modems.
Les modems informatiques sont ceux qui fonctionnent le plus mal par expérience.

Cordialement.

Déjà, ce qui m’agace, c’est que je n’arrive pas à vraiment voir ce que j’ai comme SanDSP dans cette foutue distrib ! En fait, si, plus ou moins - c’est intégré au noyau Debian pour ARM (donc, RPiOS) et autres, sous le nom de « libspandsp2 » mais, c’est vraiment flou :

  • Un ChangeLog de 01/2019 mentionne « 0.0.6+fdsg2 ». La première entrée en 0.0.2 est de 01/2005. Il est seulement fait mention de soft-switch.org sur la 0.0.4 de 12/2007.
  • Un autre ChangeLog pour ARM64 de 01/2023 ne mentionne rien de spécial
  • Sur SoftSwitch (SteeveU), il y a bien un (le ?) source en 0.0.6 dont la dernière modif (entre autres, support du 64 bits) remonte à 2014. [Dev abandonné mais le dernier snapshot date de 01/2018 ?].
  • Il me semble que la grosse différence entre les versions 32 et 64 bits est [serait] qu’en 32 bits, les conversions sont sur des entiers alors qu’en 64 bits, c’est en flottant.

Sur le GitHub de FreeSwitch, SanDSP semble maintenue (dernière modif en 01/2024). Il me semble que c’est maintenant « libsandsp3 ». Le source me parait organisé assez différemment et les fonctionnalités sont plus évoluées (début de support du V150 [ModemOverIP] par ex !), mais, là non plus, pas de ChangeLog clair.

==> Dejà là, je suis dans le doute : choisir la librairie en V2 ou V3 [et quelle incidence sur la qualité RX/TX] ???

[HS] Dans mes recherches linuxiennes, j’ai trouvé « GStreamer » [pas compris exactement à quoi ça sert], disponible sur toutes les distributions, qui utilise SanDSP. Il inclut un décodeur télétexte. Je n’ai pas creusé plus.

Tu as deux setups ? Comment as-tu déterminé -28/-38 ?

Quels essais as-tu fait pour décider de descendre RX à -50 ?

  • Je trouve -14/-30 dans le « fsk.c » de 2014, du dernier snapshoot de SanDSP 0.0.6 sur soft-switch.org.
  • Les valeurs 2/2 (Telstar) ou 4/2 (MiniPavi #2) me semblent très éloignées

TX = 4, 2, -28, -14
RX = 2, -30,-35 , -38, -50 … C’est bien large

(en gras, les valeurs par défaut de ‹ mon › SoftModem [PhreakNet])
(en italique, les valeurs par défaut des dernières versions de SanDSP [0.0.6 de 2014 et 3.0.0])

Autant recompiler spandsp soit même, je crois pas que la version du fork de freeswitch soit dans des repos ou en tout cas pas à jour.
La version fixed point existe sûrement pour l’utilisation sur des microcontrôleurs ou anciens processeurs qui ont des jeux d’instructions plus limités.
Pour changer ces valeurs, j’ai repris le struct dans mon fichier .c (voir minitelserver/minitelserver.c at 2403b044cda02a471b5b3376e1bc7eeec53aa70f · NathaanTFM/minitelserver · GitHub) et je l’ai utliisé dans l’initialisateur (minitelserver/minitelserver.c at 2403b044cda02a471b5b3376e1bc7eeec53aa70f · NathaanTFM/minitelserver · GitHub)

Les valeurs TX et RX négatives sont en dbm0 (je crois?), les valeurs « 4 » ou « 2 » ne sont pas dans la même unité (souvent c’est des réglages entre -5 et 5, représente sûrement un multiplicateur derrière, j’en sais rien j’ai pas ce paramètre dans mon serveur)

Oui pour les valeurs négatives en DBM0 - Pour les valeurs positives, rien n’indique le contraire. Pour le moment, je ne suis pas encore parvenu à suivre tout le processus de conversion, ni à voir où ces paramètres entrent en jeu.

Je vais essayer de voir comment se comportent les valeurs suivantes … C’est vraiment très empirique. Je ne serais pas surpris qu’il y ait une influence entre TX et RX … :
TX = 4, 2, -14, -14, -28, -28
RX = 2, 2, -30, -50, -35 , -38

==> Faudrait effectivement, par la suite, en absence de résultat probant avec la librairie intégrée, essayer avec la V3

Alors, avec les valeurs négatives, j’ai 100% d’échec, le minitel ne se connecte jamais !

Le meilleur résultat est avec TX=4, RX=2 [conf MiniPavi #2] avec « seulement » 4 erreurs; pour TX=2, RX=2, il y a quand même 22 erreurs et 1 échec de connexion. Faut creuser …

Où règles tu ces paramètres ? (TX=4, RX=2)

Ce sont les paramètres d’APP_SoftModem … Exactement le même machin que ‹ ton › ‹ tx_level › et ‹ min_level › de ‹ fsk_spec_t › que tu as dans ton ‹ minitel_client › et que tu passes à ‹ fsk_tx_init() › et fsk_rx_init().

Moi, je le règle avec l’extension configurée dans Asterisk … en fonction du numéro appelé, j’ai un réglage différent [pour tester facilement …].

Après, c’est le berdol de SpanDSP, en particulier de l’un des deux ‹ dds_xxx.c ›, transformées de Fourier, Goertzel trucmuche, puis conversion aLaw/µLaw et enfin, passage dans le toyo. Je n’ai pas encore tout compris.

  • Il n’y a aucun traitement particulier sur les valeurs d’entrées
  • Il y a un changement entre la v0.0.6 de 2014 et la v0.0.6 de 2018 sur l’allocation mémoire (à priori, sans importance)
  • Il y a des changements entre la v0.0.6 de 2014 et la (ta) v3 sur dds_xxx.c :
    • Sur la détection de porteuse où il semble maintenant y avoir des seuils (en principe, ne concerne que la réception !)
    • Un appel à ‹ db_to_amplitude_ratio() › un peu partout et que je suis encore infoutu de trouver, en lieu et place de ‹ calculs savants › en ligne.

Ce qui est super avec ce code, c’est la documentation qui l’accompagne - c’est pas ce qui prends de la place !

L’init, en v3 :
freeswitch/spandsp/dds_int.c:
SPAN_DECLARE(int16_t) dds_scaling_dbm0(float level)
{ return (int16_t) (db_to_amplitude_ratio(level - DBM0_MAX_SINE_POWER)*32767.0f);
}

… Et en v0.0.6/2014:
dds_int.c:
SPAN_DECLARE(int16_t) dds_scaling_dbm0(float level)
{ return (int16_t) (powf(10.0f, (level - DBM0_MAX_SINE_POWER)/20.0f)*32767.0f);
}
SPAN_DECLARE(int16_t) dds_mod(uint32_t *phase_acc, int32_t phase_rate, int16_t scale, int32_t phase)
{ int16_t amp;
amp = (int16_t) (((int32_t) dds_lookup(*phase_acc + phase)*scale) >> 15);
*phase_acc += phase_rate;
return amp;
}
SPAN_DECLARE(int16_t) dds_lookup(uint32_t phase)
{ uint32_t step;
int16_t amp;

phase >>= DDS_SHIFT;
step = phase & (DDS_STEPS - 1);
if ((phase & DDS_STEPS))
    step = DDS_STEPS - step;
amp = sine_table[step];
if ((phase & (2*DDS_STEPS)))
    amp = -amp;
return amp;

}

  • dds_mod() et dds_lookup() semblent inchangées
  • Il me semble qu’on appelle jamais le code en flottant [dds_modf() et dds_saling_dbm0f()]

Quant à DBM0_MAX_SINE_POWER, j’ai fini par le trouver dans ‹ dtmf.c › !

dtmf.c:
#if defined(SPANDSP_USE_FIXED_POINT)
#define DTMF_THRESHOLD 10438 /* -42dBm0 /

#define DTMF_POWER_OFFSET 68.251f /
10log(256.0256.0DTMF_SAMPLES_PER_BLOCK) /
#else
#define DTMF_THRESHOLD 171032462.0f /
-42dBm0 [((DTMF_SAMPLES_PER_BLOCK
32768.0/1.4142)10^((-42 - DBM0_MAX_SINE_POWER)/20.0))^2 => 171032462.0] /

#define DTMF_POWER_OFFSET 110.395f /
10
log(32768.032768.0DTMF_SAMPLES_PER_BLOCK) */
#endif

telephony.h:
#define DBM0_MAX_POWER (3.14f + 3.02f)
#define DBM0_MAX_SINE_POWER (3.14f)
/* This is based on the ITU definition of dbOv in G.100.1 */
#define DBOV_MAX_POWER (0.0f)
#define DBOV_MAX_SINE_POWER (-3.02f)

1 « J'aime »

Bon, j’ai voulu voir ce que donnent les valeurs TX+4/RX+2 qui semblent prometteuses.

Bilan … Bof ! J’ai augmenté le nombre de séquences testées de 20 à 200 histoire d’avoir un jeu de données plus significatif - résultats ci-dessous.

Durée du test : 2h
Nombre d’échecs de connexion : 1 (sur un total de 10 cycles)
Nombre de séquences effectivement testées : 3217 (environ 377Ko)
Nombre de succès de transmission : 3168 (98,48%, environ 371Ko)
Nombre de séquences comportant des caractères ‹ parasites › reçus : 17
Nombre de séquences comportant des erreurs de transmission : 48 (1,49%)
…Séquences reçues avec un nombre de caractères différents : 38
…Séquences reçues avec le bon nombre de caractères mais comparaison erronée : 10

==> Je ne constate aucune cohérence dans la fréquence de survenue des erreurs. Au minimum, 16 secondes entre deux erreurs; au maximum, 14 minutes …

Je peux tenter de rejouer avec un jitter buffer fixe et sans jitter buffer, voir s’il y a un impact.
==> Je reste ouvert à toute suggestion sur ce qui pourrait être fait/essayé pour tenter d’améliorer ces mesures. Après, il ne me restera que wireshark … Bof bof, ça fait un gros paquet de données à analyser - Quelqu’un a déjà essayé ?

1 « J'aime »

Pour ma part sur MiniPavi, j’ai choisi mes réglages de façon empirique, à force d’essai (et j’en ai fait !) .
Au final, j’ai conclu qu’il n’y avait pas de réglage parfait : un même réglage me donnait de très bons résultats un jour, et le lendemain, avec le même équipement, des résultats bien plus mauvais…
D’où ma décision alors d’implémenter la PCE, ne trouvant aucun réglage suffisamment correct qui dure dans le temps.
Concernant les appels sortants (vers IUT, Hytrel, Notel, etc), le réglage differe pour chacun (l équipement distant semble jouer un rôle)

1 « J'aime »

Bonjour,

J’ai testé le deuxième numéro de MiniPavi avec mon modem Olitec Fax et Voix 33600, et le logiciel Olicom sur Macintosh LC 475.

Ça fonctionne très bien :slight_smile:

Par contre, il faudrait donner aussi le deuxième numéro sur Wikipedia, car là il est un peu dur à trouver



Je possède plusieurs minitels, modems et émulateurs. Je pourrais peut-être faire des essais de connexions avec vous pour voir le comportement de différents matériels si ça vous intéresse.

Cordialement.

1 « J'aime »

Pas très satisfaisant … D’où ma ‹ campagne de tests ›.

Nécessairement. Pourtant, dans la vraie vie d’avant, et avec des kilomètres de cuivre entre le modem et l’autocom local (et sans prendre en compte la liaison vers le PAVI), tout marchait « parfaitement » bien, hormis pour les cas extrêmes de ligne très dégradée où la PCE servait à quelque chose. Là, on a le modem, 3 mètres de câble et l’ADC/DAC de l’ATA - ça devrait quand-même mieux marcher que ce qu’on observe.

Dans les possibles :

  • Mauvais réglage/paramétrage ATA : Bof, marchait très bien sur Hacker
  • Pb réseau : Bof, mes tests sont 100% local, cuivre, sur un RPi dédié ==> Néanmoins, ça peut se vérifier (1 petit drop de temps en temps ?)
  • Mauvaise mise en forme du signal [ou mauvais timing ‹ de temps en temps › - Linux n’est pas un OS temps-réel - Je me souviens que CISCO impose 100% de réservation de ressources et des CPU bien costauds pour un environnement CUCM virtualisé - peut-être pas pour rien] conduisant à des aberrations furtives : J’y crois plus. Bien que SpanDSP 0.0.6 soit ‹ universel ›, on le pousse dans ses derniers retranchements - la transmission de FAX ou de CID est bien plus permissive et tolérante à quelques errements sporadiques.
  • Bug dans APP_SoftModem : J’y crois pas, ce serait bien pire, et puis, de ce que j’en ai vu, il n’y a rien de sorcier dedans.

Dans tous les cas, je ne vois qu’une stratégie pour tenter une amélioration : des tests rigoureux.

@Polo : A ce stade, avant de chercher à essayer tous les couples ATA/modems de la terre pour trouver/confirmer un fonctionnement stable, il est nécessaire de conserver le même modem témoin [Ici, Cv;] et le même ATA [PAP2] pour tous les essais. Si jamais ‹ ça marche › en local un jour, il sera alors temps de complexifier la matrice des possibles.

Même test relancé avec jitter-buffer ‹ max › et fixe - On verra la différence ce soir.

2 « J'aime »

Il faudrait enregistrer (en sans perte) une connexion avec un taux de perte non négligeable pour l’analyser
Jitter buffer fixe est très important

1 « J'aime »

Je crois que pour son système, jhr de HACKER avait fait plusieurs tests avec différents modems de Christian QUEST.

Cordialement.

Alors, il faudrait quand même faire des captures, un jour, histoire de voir la tête du signal représenté en TCP (pour espérer comprendre l’influence des paramètres TX/RX).

Durée du test : 2h20
Nombre d’échecs de connexion : 0 (sur un total de 10 cycles)
Nombre d’échecs d’identification : 1 (sur un total de 10 cycles)
Nombre de séquences effectivement testées : 3618 (environ 424Ko)
Nombre de succès de transmission : 3618 (100,00%, environ 424Ko)
Nombre de séquences comportant des caractères ‹ parasites › reçus : 0
Nombre de séquences comportant des erreurs de transmission : 0 (0,00%)
…Séquences reçues avec un nombre de caractères différents : 0
…Séquences reçues avec le bon nombre de caractères mais comparaison erronée : 0

==> Bin, c’est plutôt pas mal : La seule anomalie constatée concerne « beaucoup » (*) de cochonneries reçues sur le canal montant, immédiatement après la connexion, lors du 4ème cycle de tests (sur 10).

==> Je vais relancer ce test avec le jitter buffer fixé au minimum, et une seconde fois sans. Nous verrons ce que ca donne [mieux ?, pareil ?, pire ?].
==> Je peux aussi, après, ‹ durcir › le test en modifiant la taille des séquences (passer de 120 caractères à 1200 … Nous amènerait à près de 22h30 pour le cycle de tests…)

(*) Beaucoup : Normalement, on reçoit côté Telnet :

  • < SEP >0x53/dev/ttyblablabla< 0x0D > (avec éventuellement des cochonneries avant/sur < SEP >)
  • On espère trouver un ‹ /dev/ttyblablabla › valide (envoyé côté série) et dans un délais raisonnable. Sinon, erreur et on recommence.