Resumen
- RFC 741 no trataba la voz por paquetes como una simple corriente de muestras: dos hosts debían acordar la llamada, la codificación, el ritmo y la disponibilidad antes de iniciar el flujo de habla.
- Sus cuatro funciones direccionales de control y datos, la negociación de códecs y la espera de una respuesta humana muestran lo que NVP especificaba. El informe de cuatro centros no demuestra un despliegue generalizado.
Análisis
Tres fechas y cuatro centros: qué clase de historia cuenta RFC 741
El texto conserva varias capas de tiempo que conviene no confundir: la implementación descrita en los agradecimientos, la nota técnica que está en la portada y la fecha del RFC publicado. Leerlas por separado evita convertir una prueba documentada en una historia de adopción general.
Danny Cohen plasmó esa diferencia en RFC 741. La cubierta lleva fecha de 22 de noviembre de 1977, pero la portada identifica el texto como NSC Note 68, fechado el 29 de enero de 1976 y revisión de tres notas anteriores. El proyecto Network Secure Communications de ARPA buscaba demostrar voz digital bidireccional, de calidad y bajo caudal sobre redes de conmutación de paquetes. El prefacio explica que equipos de cifrado ya existentes podían proteger el habla digitalizada. NVP era una parte del proyecto, no el mecanismo de cifrado.
Los agradecimientos aportan un punto de apoyo operativo. Cohen afirma que NVP se implementó por primera vez en diciembre de 1973 y que desde entonces se había usado para voz en tiempo real, local y entre redes, sobre ARPANET. Enumera Information Sciences Institute, Lincoln Laboratory, Culler-Harrison y Stanford Research Institute, con distintas combinaciones de máquinas y codificadores. Es un testimonio concreto de trabajo entre centros, pero no un censo de usuarios, una medición de calidad ni evidencia de que existiera un servicio telefónico general.
De una llamada inicial al acuerdo sobre la voz
RFC 741 parte de un desajuste: el protocolo host-to-host de ARPANET se había optimizado para transferir datos y no servía para voz interactiva. NVP separó los mensajes de control de los datos de voz. El RFC denomina LINK a los ocho bits superiores de un MESSAGE-ID de 12 bits y SUB-LINK a los cuatro inferiores. Son identificadores lógicos de mensajes; no representan cuatro cables físicos ni puertos IP actuales.
Cada conversación usaba cuatro funciones direccionales. L llevaba control de quien llamaba a quien recibía la llamada; K llevaba control de vuelta. La voz viajaba en un sentido por L+1 y en el contrario por K+1. L y K se escogían dentro del rango octal 340–375 y podían coincidir. El primer contacto se hacía por el enlace 377.
En 377, quien llamaba identificaba a ambas partes y proponía K. El receptor podía rechazar la llamada o aceptarla y asignar L. Entonces el iniciador enviaba otra llamada por L y comenzaba la negociación de compatibilidad. Un lado proponía parámetros WHAT y opciones HOW; el otro las aceptaba o rechazaba. Entre los parámetros posibles estaban el vocoder, el período de muestreo, la versión, la longitud máxima del mensaje y el tamaño de las parcelas. El documento describía opciones como LPC y CVSD: los dos extremos no tenían que ser idénticos, pero sí encontrar una configuración común.
El acuerdo técnico no era todavía una conversación
Después de la negociación inicial, el receptor hacía sonar una campana y enviaba RINGING. La voz empezaba cuando una persona respondía y el sistema enviaba READY. El RFC permitía READY sin una RINGING previa, pero mantenía la diferencia entre una conexión compatible y una persona lista para hablar.
La llamada podía cambiar de configuración. Cualquiera de las partes podía solicitar una renegociación después de asignar los enlaces. Los enlaces permanecían fijos, pero había que negociar de nuevo los parámetros anteriores e ignorar los datos de voz hasta recibir READY. Una petición ECHO opcional podía ayudar a medir el retardo; la especificación no exigía soporte y decía que la falta de respuesta no debía terminar la llamada. Era una herramienta de observación, no una garantía de latencia.
Por eso conviene evitar llamar a RFC 741 un estándar temprano de VoIP actual. Los campos WHO y WHOM representaban el host, el IMP y una extensión. Servían para direccionar unidades de comunicación, no para autenticar personas ni decidir quién tenía permiso para hablar. El objetivo de voz segura pertenecía al proyecto completo y dependía de equipos de cifrado existentes, fuera del protocolo de control. NVP coordinaba un intercambio de voz; no era por sí mismo un servicio telefónico seguro.
En 1986, RFC 980 colocó NVP-II entre los «protocolos host menores». Esa clasificación indica dónde lo situó un catálogo, no cuántas redes lo seguían ejecutando. La conclusión histórica más sólida es limitada: a mediados de los años setenta, investigadores de ARPANET ya habían probado voz entre varios centros y descrito la negociación, los identificadores y la disponibilidad humana que permitían conversar a máquinas distintas. Las parcelas de voz no empezaban a circular hasta que los hosts se ponían de acuerdo.
Fuentes
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
