Résumé
- RFC 741 ne réduisait pas la voix par paquets à un flux d’échantillons : deux hôtes devaient d’abord s’accorder sur l’appel, le codage, le rythme d’envoi et l’état de disponibilité.
- Les quatre rôles directionnels de contrôle et de données, la négociation des codecs et l’attente d’une réponse humaine montrent ce que spécifiait NVP. Le témoignage de quatre sites ne prouve pas un déploiement généralisé.
Analyse
READY distinguait une connexion de la réponse humaine
Après la négociation initiale, le correspondant faisait sonner un signal et envoyait RINGING. La transmission ne commençait qu’après le signal READY envoyé lorsqu’une personne répondait. Le texte autorisait READY sans RINGING préalable, mais distinguait toujours la compatibilité technique de la disponibilité de la personne.
L’échange pouvait évoluer : l’un ou l’autre système pouvait demander une nouvelle négociation, tandis que les liens déjà attribués restaient fixes. Les paramètres antérieurs devaient être renégociés et les données vocales ignorées jusqu’au nouveau READY. Une requête ECHO facultative pouvait aider à mesurer le délai ; l’absence d’écho ne devait pas mettre fin à l’appel. C’était un point de mesure, pas une garantie de latence.
La limite compte si l’on présente RFC 741 comme un ancêtre direct de la téléphonie IP actuelle. Les champs WHO et WHOM correspondaient à l’hôte, à l’IMP et à une extension. Ils adressaient une unité de communication ; ils n’authentifiaient pas une personne et ne déterminaient pas son autorisation. La préface rattache la sécurité aux équipements de chiffrement existants, hors du protocole de contrôle d’appel. NVP expliquait comment établir et coordonner un échange vocal, pas comment fournir à lui seul un service téléphonique sécurisé.
En 1986, le guide RFC 980 plaçait NVP-II parmi les « protocoles hôtes mineurs ». Cette entrée documente un classement dans un catalogue, pas un usage opérationnel durable. Le constat historique est plus circonscrit : au milieu des années 1970, des chercheurs de l’ARPANET avaient fait fonctionner la voix entre plusieurs sites et spécifié les négociations, les identifiants et l’état humain nécessaires pour que des machines différentes puissent converser. Les données vocales ne circulaient qu’après l’accord des hôtes.
Quatre rôles logiques séparaient contrôle et parole
RFC 741 part d’un échec d’adéquation : le protocole hôte-à-hôte de l’ARPANET avait été conçu pour le transfert de données et ne convenait pas à la voix interactive. NVP séparait donc les messages de contrôle des données vocales. Le document appelle LINK les huit bits de poids fort d’un MESSAGE-ID de 12 bits, et SUB-LINK les quatre bits restants. Il s’agit d’identifiants de messages, pas de quatre circuits physiques ni de ports IP modernes.
Chaque communication vocale mobilisait quatre rôles directionnels. L transportait le contrôle de l’appelant vers le correspondant ; K transportait le contrôle en sens inverse. Les données vocales passaient sur L+1 dans le premier sens et sur K+1 dans l’autre. L et K étaient choisis dans la plage octale 340–375 et pouvaient même avoir la même valeur. La prise de contact initiale utilisait le lien 377.
Sur 377, l’appelant indiquait qui appelait qui et proposait K. Le correspondant pouvait refuser ou accepter en attribuant L. L’appelant envoyait alors un second message sur L, puis les deux systèmes négociaient leur compatibilité. L’un proposait des paramètres WHAT et des options HOW; l’autre acceptait ou refusait. Les paramètres pouvaient porter sur le vocodeur, la période d’échantillonnage, la version, la longueur maximale des messages et la taille des paquets de parole. Le document définissait notamment des possibilités LPC et CVSD : les machines n’avaient donc pas besoin d’être identiques, mais elles devaient trouver un choix commun.
De 1973 à 1977 : ce que le dossier permet d’établir
Un appel vocal ne commence pas lorsque le premier échantillon est envoyé. Un système doit trouver son correspondant, vérifier que les deux équipements peuvent échanger la même représentation de la parole, puis attendre que le destinataire soit prêt. Le transfert de fichiers peut répéter une information manquante ; dans une conversation en temps réel, une répétition tardive ne replace pas la parole au moment où elle devait être entendue.
Danny Cohen a rendu cette différence explicite dans RFC 741. La couverture porte la date du 22 novembre 1977. La page de titre identifie toutefois le texte comme NSC Note 68, datée du 29 janvier 1976 et révisant trois notes antérieures. Le projet Network Secure Communications de l’ARPA voulait démontrer la faisabilité d’une voix numérique bidirectionnelle, de qualité et à faible débit sur des réseaux à commutation de paquets. La préface précise que des équipements de chiffrement existants pouvaient protéger la parole numérisée : NVP contribuait au projet, mais n’était pas lui-même un protocole de chiffrement.
Les remerciements donnent un ancrage matériel au texte. Cohen écrit que NVP fut implémenté pour la première fois en décembre 1973 et utilisé depuis lors pour des communications vocales locales et inter-réseaux sur l’ARPANET. Il cite l’Information Sciences Institute, Lincoln Laboratory, Culler-Harrison et le Stanford Research Institute, avec plusieurs combinaisons de machines et de codage. C’est un témoignage précis de travail entre sites. Il ne donne ni nombre d’utilisateurs, ni volume d’appels, ni mesure de qualité, et ne démontre pas l’existence d’un service téléphonique général.
Sources
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
