Resumen

  • La línea o= de SDP coloca una identidad de sesión junto a un sess-version distinto; una descripción nueva puede conservar la misma sesión.
  • SDP exige aumentar la versión cuando cambia la descripción. Offer/Answer concreta la regla: una oferta modificada conserva el resto de o= y suma uno, mientras que una versión repetida debe llevar SDP idéntico.
  • El número sirve para detectar material atrasado. No autentica al remitente, no acepta la oferta ni demuestra consentimiento, conectividad o ejecución.

La continuidad tenía dos dimensiones

Las sesiones multimedia viven más que una de sus descripciones. Una conferencia cambia de horario; una llamada añade vídeo, pone el audio en espera o mueve la dirección de recepción. Quien recibe el texto necesita saber si la conversación sigue siendo la misma y si la copia recibida es la revisión vigente.

Un único identificador no bastaba. Renovarlo con cada cambio habría roto la historia común. Mantenerlo sin un dato de revisión habría permitido que una copia antigua desplazara a una nueva.

SDP reunió ambas coordenadas en la línea de origen:

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

El nombre, el identificador de sesión, los tipos de red y dirección y la dirección de origen forman el linaje. sess-version distingue descripciones dentro de ese linaje. Comparar números antes de verificar el tuple completo mezcla sesiones que no comparten historia.

El origen no era una credencial

username puede ser un nombre de acceso, pero también un guion. Para proteger la privacidad, la especificación moderna permite usar un nombre arbitrario y una dirección privada siempre que el tuple conserve unicidad global.

Por tanto, o= no certifica a una persona ni a una organización. La dirección de origen tampoco tiene que ser la dirección del medio. Dos textos con el mismo sess-id y coordenadas distintas no son automáticamente revisiones de una sola sesión.

La herramienta creadora asigna el identificador. Usar una marca basada en la época NTP es una recomendación práctica contra colisiones, no una prueba de hora exacta, propiedad de dirección o instante de creación.

La revisión se decidía en cada extremo

Cuando cambia una descripción, SDP obliga a elevar sess-version. Un receptor puede guardar el tuple, la versión y la huella de la copia aceptada, y evitar que una publicación atrasada sustituya a otra posterior.

No hace falta un registro mundial de revisiones. Cada agente dispone de evidencia suficiente para decidir dentro de una identidad que ya reconoce. Esa autonomía es limitada: SDP general pide un aumento, no necesariamente +1; una cifra con aspecto temporal no es un reloj civil; versiones de tuples diferentes no comparten orden.

El número es evidencia relativa. Solo afirma algo después de probar que las dos descripciones pertenecen al mismo origen lógico y a las reglas de la misma aplicación.

Offer/Answer convirtió el aumento en una secuencia

SDP nació como formato descriptivo. Offer/Answer añadió la forma en que dos agentes llegan a una vista común, apoyándose en un protocolo superior como SIP para transportar mensajes, mantener contexto y resolver el orden.

Una oferta que modifica la sesión debe repetir su línea o= anterior, salvo la versión, que aumenta exactamente uno. Las partes estables conservan el linaje del agente; el paso único declara su siguiente revisión.

Si la versión no cambia, el SDP debe ser idéntico al asociado a esa versión. Se permite repetir una oferta sin cambios y el receptor sigue obligado a contestarla de forma válida. Lo que no se permite es esconder bytes nuevos bajo el número anterior.

Así aparece un invariante de auditoría muy preciso: dos cuerpos distintos bajo el mismo (origen, versión) son evidencia contradictoria. El último en llegar no gana por ese solo hecho.

Offer/Answer exige además que identificador y versión se representen como enteros con signo de 64 bits y que la versión inicial quede por debajo de 2^62 - 1 para evitar el rollover. La cautela pertenece a este modelo, no crea aritmética circular para todo SDP.

Una revisión nueva seguía siendo una propuesta

El número no decide la aceptación. El otro agente puede aceptar formatos compatibles, rechazar flujos o hacer que la señalización rechace la oferta completa. Si se rechaza, la sesión vuelve a su estado descriptivo anterior.

Tampoco resuelve la concurrencia. Un agente no envía una oferta nueva mientras espera respuesta o mientras debe responder a la oferta del par. Si ambos ofrecen a la vez aparece glare, que resuelve el protocolo superior. “Gana el número mayor” no forma parte del mecanismo.

Una respuesta válida documenta acuerdo descriptivo, no resultado material. No prueba llegada de paquetes, funcionamiento del códec, apertura del firewall, consentimiento humano, legalidad de una grabación ni culminación comercial.

Ser más reciente no era ser confiable

Un atacante también puede escribir un entero enorme. Por eso Offer/Answer requiere que la señalización aporte autenticación de extremo a extremo e integridad para ofertas y respuestas. El receptor conserva su política local de admisión y consentimiento.

Las pruebas no son intercambiables. Autenticación identifica una fuente reconocida; integridad protege el traslado; el tuple declara un linaje; la versión declara una revisión; el estado de Offer/Answer declara propuesta, aceptación o rechazo; la telemetría de medios declara el efecto observado.

SDP no creó autoridad numérica. Creó una separación útil entre identidad y cambio, suficiente para rechazar material viejo sin entregar al autor del contador el control de todas las decisiones posteriores.

Fuentes y límites de la evidencia

La secuencia normativa está en RFC 2327, RFC 4566, RFC 8866 y RFC 3264. Establecen gramática y Offer/Answer, no el comportamiento actual de productos, la identidad de un emisor vivo ni la entrega efectiva del medio.