Resumen

  • RFC 4103 y RFC 2198 permiten reparar texto T.140 mediante redundancia, pero la capacidad y la recuperación parcial no demuestran ausencia de pérdida. RFC 5194 conserva la indicación de texto perdido como parte de la experiencia.
  • La prueba debe distinguir llegada primaria, caracteres recuperados, pérdida residual, contenido mostrado y transcripción posterior. Suprimir el hueco mejora la apariencia y reduce la autoridad del resultado.

Una reparación sin recibo completo

La redundancia funcionó exactamente donde debía. Un paquete posterior contenía unidades recientes y permitió reconstruir buena parte de lo perdido. El fallo operativo apareció después: el producto convirtió «recuperación parcial» en «mensaje entregado» porque su modelo solo admitía éxito o fracaso.

El texto en tiempo real no tolera bien esa compresión. Un carácter perdido puede cambiar un número, un nombre o una negación. No se disuelve como una pequeña imperfección acústica. Si la aplicación elimina el hueco y une los extremos, fabrica una lectura más segura que la evidencia disponible.

RFC 5194 pide una indicación de pérdida cuando queda texto entrante sin recuperar. La marca no es ruido de interfaz. Es la frontera entre lo observado y lo inferido.

RFC 5194 define una conversación

El marco no llama tiempo real a cualquier texto transportado durante una llamada IP. Define una comunicación carácter a carácter y exige que los caracteres salgan tan pronto como sea posible. El almacenamiento de líneas completas no cumple el requisito de demora.

Por eso una transcripción final puede ser exacta y el servicio, deficiente. Si el emisor espera al retorno de carro, o el receptor espera a la puntuación, desaparecen la formación del turno, la vacilación y la posibilidad de responder mientras la otra persona escribe.

El documento considera bueno un segundo de demora extremo a extremo, aprecia reducciones hasta 300 ms y admite que unos dos segundos pueden resultar aceptables. No es una tabla universal de cumplimiento. Es evidencia de que la unidad relevante es el carácter a través de todo su recorrido.

El estado de llamada no tiene esa autoridad

SIP establece el diálogo. Oferta/respuesta y SDP acuerdan una descripción del medio. RTP transporta unidades con secuencia y tiempo. Ninguna de estas capas ve por sí sola lo que apareció ante una persona.

Un indicador connected puede ser verdadero mientras el texto no fluye. Un atributo text/red puede estar negociado mientras el emisor nunca usa redundancia. Un contador RTP puede crecer mientras el decodificador descarta el contenido. La voz puede funcionar mientras el texto permanece bloqueado.

La interfaz general debe resumir estados separados, no sustituirlos: medio negociado, primer carácter transmitido, primer carácter recibido, continuidad, recuperación, pérdida residual y progreso de presentación.

Tres resultados para una misma pérdida

Cuando falta una unidad, existen al menos tres hechos. Primero, el flujo primario tuvo un salto. Segundo, una generación redundante pudo reconstruir una parte o todo. Tercero, la presentación decidió cómo mostrar lo que quedó.

Juntarlos en delivered=true borra la causalidad. El operador no puede saber si la red fue limpia, si el mecanismo de reparación salvó la conversación o si la interfaz ocultó un vacío.

El recibo mínimo conserva la secuencia ausente, el paquete reparador, los caracteres reconstruidos, la pérdida que persistió y la señal mostrada. La transcripción puede indexar el resultado, pero debe retener la procedencia de cualquier zona incompleta.

El tiempo también puede perderse

Incluso sin caracteres ausentes, una implementación puede perder el ritmo. Un bloque enviado después de varios segundos conserva el alfabeto y destruye el intercambio. Medir solo el tránsito de red recompensa este defecto porque el paquete tardío cruza deprisa.

Conviene ligar entrada, emisión, llegada, decodificación y renderizado. Así queda visible si la espera nació en el editor, en el transporte, en la recuperación o en la interfaz. El parámetro cps de RFC 4103 expresa una capacidad o acuerdo de tasa; no prueba la cronología real.

La presentación transporta significado

T.140 incluye caracteres internacionales y operaciones como nueva línea, borrado y alerta. No son adornos. Una transcripción que conserva lo borrado, una conversión que sustituye caracteres o una interfaz que reordena turnos puede cambiar el significado aunque el texto resulte legible.

El archivo debe separarse del directo. Los eventos recibidos describen una entrada; los eventos presentados describen la experiencia; la transcripción es una proyección posterior. Usar la tercera para certificar las dos primeras otorga autoridad a la capa que menos realidad conserva.

Cada pasarela crea una frontera

RFC 5194 exige interfuncionamiento con telefonía de texto heredada y analiza redes móviles y mensajería instantánea. Una terminal antigua puede ser lenta, semidúplex y limitada a otro repertorio. Una pasarela de mensajería puede juntar caracteres hasta producir una burbuja.

La conversión puede ser necesaria. No debe ser invisible. El recibo de la pasarela debería nombrar protocolo de entrada y salida, regla de agrupación, tasa, cambio de dúplex, mapa de caracteres y tratamiento de pérdida.

Sin esa información, el sistema atribuye a «Internet» la demora introducida localmente o llama conversación a una secuencia de mensajes. Interoperar no significa fingir que ambos lados conservaron la misma semántica.

Voz, vídeo y texto no comparten un testigo

La combinación de medios es una fortaleza del marco. También crea un error de observación. La voz y el vídeo generan señales continuas; el texto puede guardar silencio legítimo. Un panel suele confiar en el medio más activo y declarar saludable toda la sesión.

La ausencia de caracteres puede significar que nadie escribe, que el emisor acumula, que el flujo está bloqueado o que el renderizador se detuvo. No hace falta inventar actividad para distinguirlos. Basta conservar negociación, recepción RTP, último evento, estado del renderizador y pérdida como campos separados.

Emergencia y conferencia

RFC 5194 contempla llamadas de emergencia y servicios de retransmisión. La obligación jurídica exacta depende de cada despliegue; aquí no se afirma cumplimiento. Sí puede afirmarse que llegar al destino, tener un relé y disponer de texto bidireccional son eventos distintos.

RFC 9071 recuerda otra frontera en conferencias: recibir una corriente combinada no equivale a atribuir cada intervención. Una transcripción legible sin identidad de participante puede ser inútil para comprender quién pidió ayuda o quién corrigió un dato.

Autoridad mínima

El esquema operativo propuesto —no impuesto por RFC 5194— guarda sesión, descripciones de medio, flujo y participante, tiempos de entrada a presentación, llegada original, reparación y pérdida, marca visible, salud por modalidad y cada transformación de pasarela.

La doctrina de capas de realidad de Heng Lu limita la autoridad de cada estado. Negociado habla del acuerdo. Recibido habla del transporte. Recuperado habla del decodificador. Mostrado habla de la interfaz. Completo solo puede pronunciarse si la cadena conserva evidencia suficiente.

La especificación inicial mínima protege estas diferencias interoperables. Los productos pueden innovar en diseño, almacenamiento y recuperación. No pueden convertir una frase limpia en autoridad sobre caracteres que nunca observaron.

Sources

  1. RFC 5194 HTML
  2. RFC 5194 texto
  3. Ficha RFC 5194
  4. Datatracker RFC 5194
  5. Historial RFC 5194
  6. Referencias RFC 5194
  7. Errata RFC 5194
  8. RFC 4103
  9. Ficha RFC 4103
  10. RFC 9071
  11. Ficha RFC 9071
  12. RFC 4351
  13. RFC 3550
  14. RFC 2198
  15. RFC 3261
  16. RFC 3264
  17. RFC 8866
  18. Heng Lu — capas de realidad
  19. Heng Lu — especificación inicial mínima
  20. Heng Lu — primacía del código operativo