Resumen

  • SDP distingue la versión del formato, v=0, de la versión de una descripción, sess-version, que debe aumentar cuando cambia esa sesión identificada.
  • El orden pertenece al tuple de origen. Comparar el decimal entre orígenes distintos o leer su forma de timestamp como hora autenticada elimina la procedencia necesaria para hablar de continuidad.

El relevo que parecía una actualización

Durante un failover, el controlador de respaldo puede emitir un SDP válido y usar una cifra más alta que el principal. También podría usar una más baja. Cada herramienta decide cómo asignar sus valores; el RFC no entrega a todos los creadores un contador común. El cambio de máquina altera parte de la identidad antes de que la versión entre en la comparación.

Guardar solo session_id y el máximo de version resulta tentador porque simplifica consultas y paneles. Pero mezcla tres hechos: cuándo llegó el documento, qué orden declaró su creador y quién autorizó la sucesión. La llegada no prueba revisión; la revisión no prueba mandato; el mandato no prueba que el receptor aplicara el cambio.

Hay dos versiones y solo una empieza por v=

RFC 8866 abre cada descripción con v=0. Ese cero identifica la versión del Session Description Protocol y no tiene versión menor. No debe subir cuando una llamada añade vídeo, retira un flujo o cambia de dirección.

La siguiente línea obligatoria, o=, reúne username, session ID, session version, network type, address type y unicast address. Aquí sess-version sí etiqueta una revisión de los datos. La herramienta creadora debe aumentarlo cuando modifica la descripción y el RFC recomienda asignarlo con un timestamp.

Si un sistema incrementa v=, anuncia un formato de protocolo que no existe. Si cambia el cuerpo y conserva sess-version, presenta dos estados como una revisión única. Ambos campos merecen almacenarse, pero nunca intercambiar significado.

Cinco piezas dan identidad a la sexta

El RFC vigente establece que username, session ID, network type, address type y unicast address forman juntos el identificador globalmente único de la sesión. Ningún componente basta por separado. Reutilizar un session ID en otro host no hereda la historia anterior. Un username no autentica a una persona. Una nueva dirección no adquiere continuidad por parecerse a la vieja.

RFC 2327 explicaba para qué servía originalmente el número. Handley y Van Jacobson indicaron que permitía a anuncios proxy decidir cuál de varias publicaciones de la misma sesión era más reciente. La frase decisiva es «de la misma sesión». Primero se establece la identidad; después se ordenan sus versiones.

Cuando una operación planeada cambia el tuple, hace falta otro artefacto: registro de migración con origen anterior y nuevo, autoridad, instante efectivo, estado transferido, excepciones y reversión. El número mayor no puede firmar el relevo.

En offer/answer, repetir versión obliga a repetir contenido

RFC 3264 impone una condición exacta para modificar una sesión. La nueva oferta conserva la línea o= previa, salvo que la versión aumenta en uno. Si no aumenta, el SDP debe ser idéntico al que ya llevaba ese número. Recibir otra vez la misma oferta es, en efecto, un no-op, aunque el answerer debe responder de manera válida.

De ahí sale una prueba reproducible. Mismo origen, misma versión y bytes diferentes no son una retransmisión ordinaria. El receptor debe conservar los dos hashes, señalar el conflicto y seguir su política de error. Elegir el último paquete oculta el incumplimiento y borra la evidencia.

Una versión nueva tampoco equivale a una sesión nueva en funcionamiento. Prueba que el creador declaró una modificación. La aceptación del answerer, el tráfico RTP y la experiencia del usuario siguen siendo resultados independientes.

Parecer timestamp no es certificar tiempo

RFC 8866 recomienda segundos desde el 1 de enero de 1900 UTC para asignar el session ID y aconseja también un timestamp para sess-version. Es una forma práctica de producir números distintivos y crecientes dentro de un creador. No es una autoridad horaria. El campo no acredita sincronización, hora de recepción ni competencia organizativa.

La seguridad se resuelve en otra frontera. El RFC advierte que una descripción solo merece confianza si llega de una fuente conocida y confiable mediante un transporte autenticado y protegido en integridad. Por eso el recibo debe unir el tuple declarado con el principal autenticado y la validación del canal. La sintaxis no autentica su propia afirmación.

El hash de SAP pertenece a otra capa

Session Announcement Protocol tiene en RFC 2974 sus propios campos de originating source y message identifier hash. Cambiar ese hash indica al receptor que debe analizar contenido modificado. Dentro del payload, SDP conserva su origin y su session version. La señal de cambio del transporte de anuncios no sustituye la genealogía de la descripción.

La separación es deliberada. SDP es un formato descriptivo, no un protocolo de transporte, y por sí solo no negocia contenido ni codificaciones. SIP offer/answer puede usarlo en una negociación limitada; SAP, HTTP o correo pueden distribuirlo. Recepción, identidad, decisión negociada y medio observado se conectan, pero no son una única casilla.

El lugar de Handley es colectivo

RFC 2327 nombra a Mark Handley y Van Jacobson. RFC 4566 fue obra de Handley, Jacobson y Colin Perkins. RFC 8866, que sustituyó al anterior en 2021, está firmado por Ali Begen, Paul Kyzivat, Perkins y Handley. Preservar esa autoría conjunta evita inventar un único creador y refleja la misma disciplina de procedencia que exige el protocolo.

Royal Society presenta a Handley como Professor of Networked Systems en UCL, autor de numerosos estándares de Internet y antiguo miembro de Internet Architecture Board. ACM SIGCOMM le concedió su premio de 2019 por contribuciones a multimedia, multicast, control de congestión, redes multipath y normalización de protocolos.

Lo que sí demuestra el número

Si se conservan identidad completa, bytes exactos y adquisición confiable, sess-version permite decir que un creador marcó una descripción como revisión posterior de esa misma sesión. En RFC 3264 también ayuda a detectar un contenido diferente con versión repetida o una modificación sin incremento.

No demuestra que otro origen sea sucesor, que el reloj sea correcto, que el emisor tenga autoridad, que la oferta haya sido aceptada, que los paquetes lleguen o que el servicio funcione para el usuario. Cada afirmación necesita una prueba diferente.

Fuentes