Resumen

  • RFC 3261 identificó cada diálogo mediante Call-ID, tag local y tag remoto. La orientación cambia en el otro extremo: el tag local de un agente es el remoto de su par.
  • Un INVITE bifurcado podía crear varios diálogos tempranos o confirmados. Conservaban el Call-ID y el tag del iniciador, pero cada contestador añadía un To-tag diferente.
  • El diálogo guardaba el orden, la ruta y el destino para transacciones posteriores. Su identificador relacionaba contexto; no autenticaba a una persona ni probaba la entrega de medios.

La llamada singular era una ilusión de la interfaz

«Llamar» sugiere una secuencia simple: elegir una dirección, esperar una respuesta, conversar con un interlocutor. El encaminamiento SIP permitía que un proxy enviara el mismo INVITE al teléfono de mesa, al cliente móvil y a una pasarela. Varios equipos podían sonar y más de uno podía contestar.

La identidad de la transacción inicial no resolvía lo que venía después. Una transacción correlacionaba una petición, sus retransmisiones y sus respuestas durante un intercambio. ACK, una renegociación o BYE iniciarían nuevas transacciones. Cualquiera de los extremos podría emitir la siguiente petición; algunos proxies querrían conservar su lugar en la ruta; el terminal podría anunciar otra dirección de contacto.

SIP necesitaba, por tanto, el nombre de un contexto recordado, no solo el de un trabajo de mensajería.

RFC 2543, de marzo de 1999, llamó call leg a esa relación y la identificó con Call-ID, To y From. La norma ya veía el problema del fork: si la petición podía llegar a varios servidores de agente de usuario, cada respuesta incorporaba un To-tag para distinguir a los contestadores. Varias respuestas a un INVITE, con tags diferentes, representaban distintas ramas de llamada.

Pero el modelo dependía todavía del conjunto de los campos de dirección. El From-tag era opcional y Route/Record-Route no estaban especificados con suficiente precisión. SIP 2.0 mantuvo la posibilidad de bifurcar, pero aisló mejor el estado resultante.

El nombre completo no pertenecía al llamante

RFC 3261, publicado en junio de 2002, reemplazó el call leg por el diálogo: una relación SIP entre dos agentes de usuario que persiste durante cierto tiempo. Ese contexto ordena mensajes y aporta los datos necesarios para encaminar peticiones posteriores entre los pares.

En cada agente, el dialog ID consta de Call-ID, tag local y tag remoto. La perspectiva importa. El tag local de Alice es el tag remoto en Bob; el tag local de Bob es el remoto en Alice. Comparten dos valores opacos, pero no una orientación global de «local» y «remoto».

La petición inicial lleva Call-ID y From-tag: la mitad del identificador, según la explicación del propio RFC. Una respuesta capaz de establecer el diálogo agrega el To-tag. Para el iniciador, su From-tag se convierte en local y el To-tag recibido en remoto. El respondedor ve la relación al revés.

Esa distribución resolvió la bifurcación. Todas las ramas heredaban el Call-ID y el tag del iniciador; cada terminal aportaba su propio To-tag. Así, el llamante podía agrupar señalización relacionada sin mezclar estados de pares diferentes.

El Call-ID, por diseño, no bastaba. Los tags tampoco eran usuarios ni credenciales. RFC 3261 exigió que un tag generado fuese globalmente único y criptográficamente aleatorio, con al menos 32 bits de aleatoriedad. La propiedad reducía ambigüedades en el identificador; no autenticaba a Alice, no autorizaba a Bob ni verificaba el nombre mostrado.

El diálogo podía empezar antes de la respuesta final

En INVITE, una respuesta provisional de 101 a 199 con To-tag crea un early dialog. El iniciador puede mantener ya el estado específico de ese contestador cuando el resultado aún no está decidido. Un 2xx confirma el diálogo correspondiente. Un resultado fallido, o la ausencia de éxito en esa rama, termina el estado temprano bajo las reglas centrales.

En un fork pueden convivir varios early dialogs: un equipo sigue sonando, otro informa progreso y un tercero rechaza. Comparten la contribución del iniciador, pero sus tags remotos los separan. Incluso pueden llegar varios 2xx, produciendo varios diálogos confirmados que la aplicación debe reconocer y luego resolver.

PRACK responde a una pregunta cercana, no idéntica. Con RSeq y RAck hace fiable y ordena una respuesta provisional relevante. Los tags indican a qué contexto de par pertenece. La fiabilidad opera dentro de un early dialog ya nombrado; no crea el nombre.

La rama Via ocupa otro nivel. Identifica el trabajo de una transacción y sus retransmisiones. La tupla del diálogo persiste cuando esa transacción ha terminado y aparece en otras nuevas. Confundirlas borraría demasiado pronto el contexto o fusionaría peticiones distintas como si fueran un solo intercambio.

Tras la tupla había ruta, destino y secuencia

RFC 3261 no guardaba únicamente tres valores. El estado incluía números de secuencia local y remoto, URI de ambos extremos, remote target, una marca de seguridad y un route set ordenado.

Cada dirección llevaba su propio CSeq. El agente incrementaba la secuencia local al generar una nueva petición dentro del diálogo; el par conservaba el valor remoto y podía rechazar uno inferior. Un salto no constituía por sí mismo un error, pues una tentativa anterior podía haberse detenido ante el desafío de autenticación de un intermediario. La secuencia mostraba orden relativo, no la llegada de cada entero.

El route set registraba los proxies que habían pedido permanecer en el camino de señalización. El UAS lo tomaba de Record-Route en la petición y el UAC de la respuesta en orden inverso. Los flujos de RFC 3665 hacen visible la regla: Call-ID y los dos tags reaparecen en ACK, BYE y respuestas, mientras Route conserva los proxies seleccionados.

El remote target resolvía una cuestión distinta: a qué Contact actual enviar la siguiente petición. Se establecía al crear el diálogo y una petición exitosa de target refresh podía cambiarlo. Para un diálogo creado por INVITE, RFC 3261 definió re-INVITE como el mecanismo básico.

El movimiento del Contact no cambiaba la identidad del diálogo ni reescribía el route set. La tupla contestaba «qué contexto», la ruta «por qué intermediarios» y el objetivo «a qué dirección del par». Separar esas respuestas impidió convertir un campo cómodo en dueño de identidad, encaminamiento y movilidad a la vez.

La señalización no era el audio

Una vez establecido el diálogo, cualquier par podía iniciar una nueva transacción. El emisor asumía el papel UAC y el receptor UAS en esa operación, aunque hubiesen ocupado papeles contrarios en el INVITE original. La relación duradera era más simétrica que un intercambio cliente-servidor.

RFC 3264 dejó la negociación de medios al modelo SDP offer/answer. Ofertas y respuestas describen flujos, codecs, direcciones y puertos, mientras un protocolo superior como SIP enlaza los intercambios sucesivos. Más adelante pueden añadirse, eliminarse o modificarse medios dentro del mismo diálogo.

Un diálogo confirmado no demostraba que el audio llegara, ni identificaba una fuente RTP, ni certificaba calidad. Organizaba el contexto de señalización; el plano de medios debía aportar su propia evidencia.

RFC 4028 añadió temporizadores de sesión negociados y refrescos mediante re-INVITE o UPDATE. Permitió intervalos distintos —o ninguno— en diálogos nacidos del mismo INVITE. Cada refresco era una nueva transacción dentro del contexto. El éxito extendía la sesión; la falta de refresco podía llevar a BYE. La tupla no concedía permanencia indefinida.

Un diálogo podía contener varios usos

Las extensiones mostraron otra limitación de la idea «un diálogo, una llamada». INVITE establece un invite usage, pero SUBSCRIBE o REFER dentro del diálogo pueden añadir usos. RFC 5057 explica que comparten Call-ID, tags, CSeq, route set, contactos, remote target y marca segura, pero conservan estado específico, como la duración de cada suscripción.

Terminar normalmente un uso no obliga a borrar los demás. BYE puede cerrar el invite usage mientras sigue una suscripción de eventos; terminar esa suscripción no tiene por qué destruir la invitación. El diálogo es un recipiente de señalización común, no la promesa de una vida única para todas las relaciones de aplicación.

RFC 6665 lo concreta en las notificaciones de eventos. SUBSCRIBE y NOTIFY usan el diálogo, pero Event participa en la identificación de la suscripción concreta. Un SUBSCRIBE bifurcado puede crear diálogos independientes que se refrescan por separado. La tupla localiza el contexto compartido; no es la clave completa de cada uso.

La virtud del identificador estaba en su alcance limitado. Nombraba el contexto entre pares mientras acababan las transacciones, se movía el Contact, permanecía la ruta, cambiaban los medios y se añadían usos. No intentaba hacerse pasar por ninguno de ellos.