Resumen

  • recipient-list-invite está definido para el INVITE inicial enviado al URI de fábrica. El URI de conferencia devuelto en Contact identifica otro recurso y no acepta esa semántica en un re-INVITE.
  • Si el cliente exige la extensión en re-INVITE, el recurso de conferencia la rechaza con 420 Bad Extension y la identifica en Unsupported. Quitar Require no convierte el mismo cuerpo en una operación válida.
  • El 200 inicial acredita creación de la conferencia, incorporación del creador y comprensión de la lista; invitación, autenticación, admisión, diálogo, medios y estado de cada tercero siguen abiertos.

El mismo cuerpo llegó a una autoridad distinta

Una implementación puede reconocer perfectamente el XML y aun así rechazar la operación. Eso es lo que hace visible RFC 5366 cuando separa el URI de fábrica del URI de la conferencia.

La fábrica recibe una solicitud para producir un recurso nuevo. El cliente incluye una lista plana de participantes iniciales y declara la extensión requerida. Si todo sale bien, la respuesta entrega en Contact el URI real de la conferencia, marcado como focus. A partir de entonces, el diálogo se dirige a ese nuevo URI.

El re-INVITE no es una repetición del primer INVITE. Opera dentro de un diálogo ya establecido y puede modificar las características de los medios entre el cliente y el servidor. En la RFC no hay semántica asignada a una lista de destinatarios dentro de ese mensaje posterior.

Por eso el error no es «XML inválido». El cuerpo puede ser idéntico al que funcionó antes. Lo que cambió fue la combinación de método, fase y recurso. El URI de conferencia no promete interpretar esa lista como una nueva tanda de invitaciones.

Un registro de capacidades que diga solo «servidor compatible con RFC 5366» perdería la explicación. Hace falta conservar qué URI se consultó, qué operación se intentó, en qué diálogo, con qué etiqueta de opción y cuál fue la respuesta. La capacidad pertenece al punto de control que la anunció.

El 420 es una respuesta útil, no una caída de la sala

Cuando el re-INVITE contiene la lista y exige recipient-list-invite, el servidor de conferencia aplica el mecanismo normal de SIP para extensiones no soportadas. Devuelve 420 Bad Extension e incluye la etiqueta en Unsupported.

Ese recibo tiene un alcance estrecho. No afirma que la conferencia haya dejado de existir. No invalida el diálogo anterior. No demuestra que la fábrica carezca de la extensión. Tampoco informa si los invitados originales entraron. Declara que este recurso no admite esta extensión en esta operación.

La precisión se pierde con una taxonomía genérica de errores. Si el sistema traduce todo 420 como «función no disponible», un operador puede desactivar en toda la plataforma una capacidad que sigue siendo válida en la fábrica. Si lo traduce como «reintentar», puede crear un bucle que castigue al servidor por aplicar correctamente el contrato.

El encabezado Unsupported debe conservarse junto a la respuesta. También el URI de destino y el estado del diálogo. Solo así un analista puede distinguir una extensión desconocida de una extensión conocida pero fuera de su superficie autorizada.

El 420 ofrece incluso una señal de calidad: el servidor no inventó una interpretación para un cuerpo sin semántica. Rechazó la ambigüedad antes de convertirla en cambios de membresía difíciles de auditar.

El downgrade sintáctico no fabrica significado

Un cliente desesperado podría retirar Require y reenviar el re-INVITE. La solicitud dejaría de exigir que el receptor comprenda la extensión, pero el cuerpo no adquiriría por ello una función definida. Un parser podría ignorarlo, otro podría rechazarlo y una extensión futura podría darle un sentido diferente.

También sería peligroso sustituir el URI de conferencia por el de fábrica. El cliente ya no estaría modificando la sala existente; podría estar solicitando otra. Dos mensajes parecidos producirían dos recursos separados, con estados y participantes separados.

La recuperación correcta empieza por formular la intención. Si se quieren añadir personas a una conferencia existente, debe usarse un mecanismo de control descrito para ese fin en RFC 4579. Si se quiere crear otra conferencia, se invoca conscientemente la fábrica. Si solo se quieren cambiar codecs o direcciones de medios, se mantiene el re-INVITE sin lista.

El motor de automatización debe registrar esa decisión semántica. «Segundo intento exitoso» no basta si el segundo intento realizó otra operación. Idempotencia, deduplicación y métricas dependen de distinguirlas.

La fábrica no entregó una hoja de asistencia

La rapidez era el motivo del diseño: crear la conferencia y proporcionar el conjunto inicial en una sola operación. Sin embargo, el 200 que responde al primer INVITE no resume todos los efectos iniciados por ella.

La RFC limita su significado a tres afirmaciones. La conferencia fue creada. El UAC que envió la solicitud está en ella. El servidor entendió la lista. El código no informa si los demás usuarios pudieron ser incorporados.

El focus debería intentar añadirlos. Cada intento puede producir una transacción distinta, una redirección, un desafío de autenticación, una regla de admisión y un diálogo. Un destino puede no existir. Otro puede rechazar. Otro puede aceptar señalización pero no negociar los medios requeridos. Otro puede incorporarse y salir antes de la primera notificación observada por el creador.

La palabra «invitado» tiene que conservar su etapa. En lenguaje cotidiano puede significar persona nombrada, solicitud enviada, llamada contestada o miembro presente. El sistema técnico debe evitar que esas acepciones se fusionen.

Una tabla útil separa: objetivo solicitado, URI normalizado, INVITE emitido, respuesta final, identidad autenticada, decisión de admisión, diálogo establecido, medios utilizables y presencia observada. El 200 inicial solo llena las columnas de creación y del creador.

La lista y el SDP comparten envoltorio, no resultado

El INVITE inicial puede ser multipart porque transporta una descripción de sesión y la lista. La cercanía física de los cuerpos no crea una transacción colectiva de medios.

El SDP del mensaje inicial participa en la negociación entre el creador y el servidor. Las invitaciones generadas hacia los demás usuarios contienen descripciones relacionadas con sus propios diálogos. El éxito de la primera oferta-respuesta no garantiza la compatibilidad, el transporte o la reproducción de los otros.

Esta distinción es relevante en accesibilidad y seguridad. El creador puede tener audio cifrado mientras un invitado no completa el intercambio. Otro puede ser admitido solo con audio, aunque la conferencia ofrezca vídeo. Un indicador global de «medios negociados» ocultaría esas diferencias.

Cada diálogo necesita su huella de SDP, resultado de oferta-respuesta, contexto de seguridad y observación de tráfico. La presencia en el documento de conferencia tampoco sustituye esas pruebas: el focus puede representar una relación lógica sin demostrar que la persona oyó o habló.

El focus decide después de la lista

El creador controla la solicitud de incorporación; no controla en solitario la admisión. Las conferencias aplican reglas sobre identidades, roles y tipos de medios. Para hacerlo, el focus autentica al participante potencial y evalúa la política vigente.

La dirección colocada en la lista y el principal que responde pueden no coincidir. Hay desvíos, dispositivos compartidos y representaciones de identidad. Preservar solo el valor final borra lo que pidió el creador; preservar solo la dirección inicial borra a quién admitió el focus.

El rastro debe mantener al menos al creador autenticado, el URI solicitado, el extremo que respondió, el principal autenticado, la versión de política y la decisión. Si hay transformación o redirección, debe conservarse el enlace.

RFC 5363 añade la obligación de autenticar y autorizar a quienes invocan servicios de listas y de respetar listas opt-in. Esa disciplina reduce abuso de la expansión, pero no convierte una lista autorizada en autorización de cada participante. Son decisiones en niveles diferentes.

El estado de conferencia llega por otro canal

Quien quiera saber qué pasó con los otros usuarios debe acudir a mecanismos generales como el paquete de eventos de conferencia de RFC 4575. Esa fuente observa el estado del focus después de la creación, no devuelve retroactivamente un significado más amplio al 200.

Las notificaciones pueden ser completas o parciales y llevan una secuencia. Una actualización parcial depende de una base anterior. Si el receptor perdió una versión, no puede sumar los fragmentos y declarar una nómina completa.

Además, el tiempo importa. Una persona presente en una versión puede haber salido. Una invitación fallida puede reintentarse y producir una incorporación posterior. Un usuario añadido por otra vía no aparecerá en la lista inicial pero sí en el estado.

Por eso conviene reconciliar tres conjuntos: solicitado, procesado por el focus y observado. Las diferencias no son automáticamente errores; son información sobre fase, política y tiempo. Lo peligroso es hacerlos iguales por conveniencia.

«Lista entendida» no significa «estructura conservada»

RFC 4826 permite jerarquías y referencias relativas. RFC 5366 solo necesita una lista plana y aconseja no usar esas funciones. La fábrica puede descartar información adicional.

El recibo de comprensión no acredita que una jerarquía haya sido desarrollada según la intención del cliente o que cada anotación se conserve. Para auditar, deben guardarse los bytes originales, la versión de parser, la lista normalizada, los descartes y el conjunto sobre el que se generaron intentos.

Las reglas de to, cc, bcc y anonimización gobiernan el historial que ve cada invitado. Esas reglas pertenecen al análisis específico de RFC 5364. En RFC 5366, la clave es que el historial de destinatarios no es una prueba del conjunto que finalmente se incorporó.

Límite de la evidencia

Las fuentes describen normas y registros, no el despliegue de una marca concreta. Los flujos de ejemplo no son capturas. Este artículo no afirma que un proveedor confunda fábrica y conferencia ni que exista un incidente real.

Lo que sí queda establecido es una regla de autoridad: reconocer una extensión no otorga a todos los recursos el poder de ejecutarla. La respuesta debe leerse desde el URI y la fase que la produjeron.