Resumen

  • RFC 3573 permite que un LAC anuncie a un LNS que un módem V.92 quedó en espera, el máximo negociado y su regreso. El aviso describe el acceso; no demuestra qué hizo el servidor ni si la aplicación sobrevivió.
  • El primer paquete válido tras el regreso puede adelantarse al mensaje H=0, porque datos y control viajan por canales independientes. Tratar la notificación como reloj de la realidad puede destruir la recuperación que pretendía proteger.

La llamada de voz entra mientras el archivo sigue bajando. V.92 permite poner en espera la llamada de datos, usar la misma línea telefónica y regresar sin marcar de nuevo. El equipo junto al módem servidor reconoce el cambio. El servidor que maneja la sesión PPP al otro lado de L2TP no lo ve.

Ese reparto explica RFC 3573. El LAC observa el medio físico; el LNS gobierna sesión, temporizadores, paquetes y contabilidad a través de la red. El documento, publicado en julio de 2003 y todavía clasificado Proposed Standard, crea un contrato pequeño entre ambos. Comparte capacidad, estado y límite temporal, pero deja la acción en manos locales.

Declarar capacidad no es cumplirla

El LNS inserta Modem On-Hold Capable en SCCRQ o SCCRP al abrir la conexión de control. Sin esa declaración, el LAC no puede enviar Modem-Status (MDMST). La negociación acredita que el receptor dice entender la extensión. No garantiza que reciba todas las transiciones, ejecute una política determinada o produzca un resultado correcto.

MDMST solo cabe dentro de una sesión establecida. Si el LNS ya envió Call-Disconnect-Notify, debe ignorar un estado que llegue a la vez o después. La descripción tardía del acceso no reabre un ciclo de vida cerrado.

Un máximo no es tiempo transcurrido

Al comenzar la espera, el LAC debería enviar H=1 con el máximo negociado. Cuando el módem vuelve, debería enviar H=0; si anunció la entrada, la salida es obligatoria. El AVP usa un bit Hold y cuatro bits Timeout dentro de dieciséis. Los valores cubren de diez segundos a dieciséis minutos e incluyen “sin límite”. Timeout solo vale con H=1.

El campo no mide cuánto duró la pausa. No prueba que el LNS haya instalado el mismo temporizador, retenido recursos o detenido el cobro. Tampoco promete que el enlace pueda recuperarse hasta el último segundo. Es un techo negociado en la capa de módem y comunicado por el LAC.

Por eso el registro debe conservar bits, interpretación, túnel, sesión, extremos, secuencia, marcas de tiempo, entrega, duplicados y desconexiones cercanas. Reducirlo a on_hold=true elimina precisamente las pruebas necesarias para explicar un desacuerdo.

La consecuencia pertenece al LNS

La RFC enumera opciones sin imponerlas. El LNS puede suspender LCP Echo, Link Quality Monitoring o Multilink PPP; descartar tráfico dirigido al cliente; abrir una sesión contable, pausarla o medir la espera por separado. Cada decisión afecta un plano diferente y algunas son incompatibles.

También advierte contra soluciones que simulan continuidad. Acumular paquetes sin presupuesto plantea cuánto guardar y qué hará TCP con la descarga tardía. Contestar keepalive en nombre del cliente inventa presencia. Y dejar de procesar paquetes válidos porque el estado guardado aún dice Hold es especialmente perjudicial: el dato de regreso puede llegar antes que H=0.

El plano de control describe el hecho con retraso variable. No posee su orden real. Si una implementación espera el aviso para aceptar datos, convierte una carrera normal entre canales en una interrupción fabricada.

Control correcto, servicio fallido

Una traza MDMST impecable puede coexistir con un TCP vencido, una aplicación abandonada, paquetes descendentes perdidos y una cuenta que siguió corriendo. Del mismo modo, una sesión ya puede transportar datos aunque el almacén de estado continúe en espera.

La solución no es elegir un único testigo. Hay que conservar por separado la negociación del módem, la observación del LAC, la entrega de MDMST, la versión de política del LNS, los paquetes por dirección, la reconexión, PPP, TCP, la aplicación y la contabilidad. Los identificadores de túnel y sesión unen los recibos; ninguno sustituye al siguiente.

La protección criptográfica tampoco amplía su significado. RFC 3573 depende de la seguridad de L2TP y permite ocultar AVP; RFC 3193 describe IPsec para L2TP. Esto ayuda a probar qué par transmitió ciertos bytes, no que el estado físico fuera cierto, la política acertada o el usuario terminara su tarea.

IANA mantiene el tipo de mensaje 17 y los atributos 53 y 54. La permanencia de un número demuestra coordinación del registro, no despliegue. El apéndice conserva valores privados de implementaciones tempranas y los declara históricos y no normativos.

Límite de evidencia

Este Artículo no identifica ISP, LAC, LNS, fabricante, abonado, operador telefónico, sesión, incidente, factura ni cuota de adopción. RFC 2661 aporta L2TP; RFC 1661, PPP; RFC 1989 y 1990, los mecanismos de sondeo citados; RFC 2865, 2866 y 2869, el contexto AAA; RFC 3193, la protección. RFC 3931 es solo contexto posterior de L2TPv3.

Running-Code Primacy y Minimum Initial Specification, de Lu Heng, son lentes editoriales declaradas: contrastar la declaración con la ejecución y mantener el contrato compartido por debajo de la política local. No son prueba de intención de los autores ni de despliegue.

La conclusión es operativa: la señal temporal sirve porque no es una orden ni un resultado. Guardar señal, decisión, paquetes posteriores y desenlace impide que una línea en espera se convierta, por comodidad administrativa, en continuidad vendida.

Fuentes