Resumen

  • RFC 2543 exigía branch sobre todo cuando un proxy dividía una solicitud. RFC 3261 lo convirtió en un identificador obligatorio y único para la transacción.
  • z9hG4bK no oculta ni autentica: anuncia que la rama cumple la regla nueva y permite reservar el emparejamiento multiclave para tráfico heredado.
  • Una retransmisión conserva la rama; un intento nuevo recibe otra. CANCEL y el ACK de una respuesta no-2xx la reutilizan con límites precisos.

La rama antigua respondía a una pregunta más pequeña

Cuando un proxy SIP envía una misma invitación a varios destinos, necesita distinguir qué respuesta corresponde a cada copia. La RFC 2543 resolvió esa necesidad con el parámetro branch del Via. Era obligatorio para un proxy que bifurcaba y opcional para uno que sólo producía una salida. Bastaba que fuese único dentro del conjunto de solicitudes isomorfas.

La transacción no quedaba nombrada por ese valor solamente. Las respuestas se relacionaban con To, From, Call-ID, CSeq y la rama del primer Via. El modelo servía a la bifurcación, pero no autorizaba a un receptor a asumir que cualquier token recibido era único en todo tiempo y espacio.

El problema de evolución era concreto. Si se endurecía el significado de branch sin marcarlo, el servidor tendría que adivinar si el vecino siguió la norma nueva. El error podía mezclar una retransmisión con una operación distinta o ejecutar dos veces una sola intención.

Siete caracteres dijeron qué contrato estaba vigente

La RFC 3261 hizo obligatorio el branch del Via superior en 2002. Salvo CANCEL y ACK para respuestas no-2xx, cada solicitud del agente debía recibir un valor único en el espacio y en el tiempo.

Las ramas construidas así comienzan por z9hG4bK. La secuencia fue elegida por su improbabilidad en una implementación RFC 2543. No codifica servidor, ruta ni usuario. Su función es declarar que el resto del token nació bajo la promesa de unicidad de RFC 3261.

Por eso “magic cookie” no significa secreto. Es una marca de compatibilidad colocada dentro del campo cuyo contrato cambió. El receptor no consulta una autoridad ni identifica la marca del equipo: observa siete caracteres y elige una regla ejecutable localmente.

La coincidencia moderna siguió siendo una tupla

Con la cookie presente, una solicitud coincide con una transacción servidor por rama, sent-by del Via superior y método; ACK dispone de su excepción. sent-by evita que la duplicación accidental o maliciosa del token entre clientes convierta una rama en una identidad global.

Sin la cookie, el servidor conserva el camino antiguo y compara Request-URI, tags, Call-ID, CSeq y Via. La compatibilidad no reescribe la evidencia vieja: reconoce que prometía menos.

Las respuestas se asignan mediante la rama y el método del CSeq. El método no sobra porque CANCEL comparte la rama de la solicitud objetivo y, aun así, constituye otra transacción. Los flujos de la RFC 3665 muestran cada Via agregado por un proxy y retirado al regresar la respuesta. La rama pertenece a un salto transaccional, no a toda la llamada.

Repetir y volver a intentar son actos distintos

Cada destino que prueba un proxy con estado es un nuevo intento y recibe una rama nueva. Una retransmisión del mismo intento repite el token. Así el servidor encuentra estado existente y puede repetir su respuesta en vez de volver a ejecutar la solicitud.

Un proxy sin estado no sabe por memoria que ya vio el paquete. Si sorteara una rama diferente cada vez, una pérdida de respuesta multiplicaría transacciones. Debe derivar una parte estable de información y configuración invariantes durante la retransmisión. La aleatoriedad por sí sola no satisface simultáneamente unicidad y reproducibilidad.

El mismo diseño puede ayudar a separar un bucle de una espiral. Si una solicitud vuelve con los campos que gobiernan la decisión intactos, puede ser un bucle. Si cambió el destino lógico, el regreso puede ser válido. Un hash local comprime esa distinción; no prueba más de lo que sus entradas conservaron.

CANCEL apunta al mismo trabajo y termina por separado

CANCEL copia URI, Call-ID, tags, número CSeq, ruta, Via y branch de la operación pendiente. Cambia el método a CANCEL. Esa igualdad lleva la cancelación al mismo intento incluso a través de proxies sin estado.

Pero su respuesta no resuelve la transacción original. Un 200 confirma que CANCEL fue reconocido. El INVITE aún debe acabar con 487 si se detuvo a tiempo, con una respuesta ya decidida o con su propio vencimiento. RFC 3261 separó estas conclusiones que RFC 2543 había entremezclado. Compartir la referencia no comparte el compromiso.

El ACK cambió de dueño cuando hubo éxito

El ACK de una respuesta final no-2xx forma parte de la transacción INVITE. Reutiliza Via y branch y es absorbido por la máquina de estados que manejó el fracaso.

Un 2xx puede proceder de varios destinos que aceptaron una invitación bifurcada. Cada éxito debe llegar al agente llamante. Su ACK se maneja extremo a extremo por el núcleo del usuario, fuera de la transacción INVITE salto a salto, y construye un Via nuevo. La frontera evita que un proxy dé por terminado un conjunto de éxitos que pertenece al extremo.

Corregir la retención no cambió la identidad

La RFC 4320 corrigió respuestas y tiempos de transacciones no-INVITE. La RFC 6026 añadió el estado Accepted y Timer L para conservar suficiente estado después de un 2xx y absorber INVITE retransmitidos.

RFC 6026 todavía distingue un ACK heredado cuya rama carece de la cookie. La duración del estado puede cambiar sin alterar la pregunta previa: ¿qué promesa de identidad ofreció el mensaje? La RFC 5359 aporta ejemplos posteriores de servicios; no demuestra despliegue universal.

La cookie nunca fue una credencial

Escribir z9hG4bK está al alcance de cualquiera. El prefijo no autentica, no autoriza, no cifra y no garantiza que la cola sea única. Una coincidencia transaccional tampoco identifica un diálogo, una persona, la ruta completa ni el resultado de la llamada.

El valor del mecanismo reside precisamente en su modestia. Una especificación nueva hizo visible su supuesto, un receptor pudo validarlo en el lugar donde actuaba y el resto de las decisiones conservaron sus propias pruebas.

Fuentes y límites de la evidencia

El conjunto cerrado incluye RFC 2543, RFC 3261, RFC 3665, RFC 4320, RFC 5359 y RFC 6026. Prueban reglas, ejemplos y cambios; no miden conformidad actual, cuota de despliegue, calidad de llamadas ni colisiones reales por fabricante.