Enregistrement V.29 (puis V.27ter, à priori) du Minitel :
v29_recording.wav
On remarque la présence d’une tonalité 1700 Hz avant les données V.29 et 1800 Hz avant les données V.27ter (ou inversement, mais le premier c’est du V.29). Mais plus étrangement, on remarque aussi des données présentes en plein milieu sans cette tonalité…
L’un des problèmes si on voulait implémenter ça en VoIP serait la gestion de la latence (et sa variation) et de l’écho.
Analyse des données : https://www.nathaan.com/minitel/tvr/fichiers/20250111_v29_recording.html
Les « 4 paires de données courtes » au milieu du fichier audio (qui n’ont pas de porteuse) ne sont pas décodées par spandsp (probablement pas de données ou pas valides ? pourquoi le Sillage les envoie et sans porteuse ?).
Le Minitel semble émettre des données dès la fin de la réception de données (quand il n’y a plus de son). Je crois avoir compris sur les docs que l’envoi de 15 « 1 » consécutifs permet de céder le droit d’émettre.
Avec mon installation totalement VoIP actuelle, je reçois côté serveur tout ce que j’émet avec un décalage de +/- 280ms, ce qui fait que je peux parfois recevoir mon propre droit d’émettre et donc que j’émet deux fois là où il ne faudrait pas. Il y a plusieurs façons de contourner ce problème, mais avec un protocole pareil, la latence risque d’être mon plus gros ennemi…
Il faudrait que j’essaye de retourner le Magis Club et de le faire communiquer avec le Sillage, mais comment le retourner en V.29…
EDIT : J’ai décidé d’envoyer manuellement des trames et j’ai pu recevoir quelques données qui m’indiquent qu’en plus de la surcouche LAPX/HDLC/X.25/X.32, il y a un protocole particulier dans le transfert données. Peut-être qu’il est décrit dans ces documents, mais en tout cas voilà quelques informations.
Adresse: 01
Commande: [20] I Information (N(S)=0 N(R)=1 P=0)
Données : 10 00 FB 00 00
Ci-dessus la première trame envoyée après la connexion. Adresse de destination 01 = le « serveur ». La deuxième trame (ci-dessous) m’a été envoyée qu’après avoir envoyé la même première trame
Adresse: 01
Commande: [22] I Information (N(S)=1 N(R)=1 P=0)
Données : 10 01 0B 00 06 42 07 07 43 06 06 01 00 00 00 13 53
J’ai immédiatement relevé le « 13 53 » qui correspond à « SEP 53 » => « Connexion ou deconnexion du modem. ». Pour le reste, pas la moindre idée.
Le Sillage et le Magis Club envoient exactement les mêmes données (pour ces 2 trames). La seule différence jusque là entre les deux, c’est que le Magis Club envoie davantage de « 01111110 » (séparateur), comme convenu dans la doc X.32
Peut-être ETS 300 223?
EDIT : Il s’agit du PLP (Packet Layer Protocol) défini dans l’ISO 8208, téléchargeable gratuitement depuis Publicly Available Standards
Analyse de la trame 1 :
1. General Format Identifier (sur 4 bits).
Ici, modulo 8, delivery confirmation=0,
"A/Q"-bit=0
.0 \ Logical Channel
01 / Identifier (12 bits)
0B Packet Type Identifier
Ici, CALL REQUEST
Address block:
0. Calling DTE Address Length (4 bits) en semi-octets
.0 Called DTE Address Length (4 bits) en semi-octets
(Ici il y aurait les adresses, mais elles sont vides)
06 Facility Length (les 6 octets suivants)
42 Flow Control Parameter Negotiation - packet sizes
0. Must be 0
.7 Packet size from called DTE: 2^7 = 128 bits
0. Must be 0
.7 Packet size from calling DTE: 2^7 = 128 bits
43 Flow Control Parameter Negotiation - window sizes
06 (bits 1-7=window size from called DTE -> 6) (unité?)
06 (bits 1-7=window size from called DTE -> 6) (unité?)
01 00 00 00 13 53 Call User Data -- que représente-t-il ?
Bon, à priori, les serveurs TVR ça sera pas pour demain.
Dissecteur Wireshark pour ça : wireshark/epan/dissectors/packet-x25.c at master · wireshark/wireshark · GitHub
