Resumen

  • Auto;require se evalúa después de que la política del destino decide el modo: si no coincide, pide un rechazo. No concede autoridad al origen.
  • Require: answermode solo exige que el UAS entienda la extensión, mientras Priv-Answer-Mode solicita una política privilegiada más estricta.
  • Una aceptación automática de medio entrante no autoriza que un re-INVITE active después el micrófono. La dirección y la aceptación explícita deben quedar ligadas a cada estado del diálogo.

Una condición de fallo preservaba la verdad

Sin require, un llamante puede pedir modo automático y el UAS puede tratar la llamada como manual según su política. Esa flexibilidad es razonable para una conversación, pero no para una prueba de bucle que debe ejecutarse sin molestar a una persona. El modificador permite decir: «si no puedes usar el modo solicitado, no sustituyas otro resultado».

La condición no cambia la política. Primero se autentica la identidad, se consulta la autorización y se evalúa el riesgo del medio. Solo después se compara el modo escogido con el pedido. Si son distintos, llega el rechazo. Un 403 puede ser una ejecución correcta del contrato, no un fallo operativo.

Una plataforma que convierte todo rechazo en «auto-answer no disponible» pierde información. La causa puede ser identidad no autorizada, política de reunión, validación de certificado que necesita interacción, modalidad peligrosa o incapacidad técnica. El recibo debe conservar decisión y alcance.

Entender answermode no significaba obedecer Auto

Require: answermode usa la semántica general de SIP para exigir soporte de una extensión. No fuerza un comportamiento. RFC 5373 reconoce que SIP no dispone de una negociación capaz de obligar al UAS a actuar de una forma concreta.

La declaración answermode en REGISTER y las preferencias Accept-Contact ayudan a seleccionar contactos compatibles. Son evidencia de vocabulario y enrutamiento. No prueban que el dispositivo elegido tenga permiso para abrir su altavoz en ese instante, ni que sea el único contacto detrás de una dirección.

Conviene separar en el modelo: capacidad anunciada, contacto elegido, campos recibidos, autorización aplicada, modo realizado y observación del usuario. Mezclarlos produce un indicador verde antes de que exista la decisión que importa.

Priv solicitaba otra política

Priv-Answer-Mode no afirma privilegio. Pide que el UAS consulte la política excepcional, normalmente más estricta y cerrada por defecto salvo autenticación y autorización específicas. El ejemplo de la RFC lo compara con sudo: escribir el prefijo no añade al usuario a la lista administrativa.

Una misma identidad puede formular una petición ordinaria o urgente. Por eso el sistema no debe elevar todas sus llamadas automáticamente. Si aparecen ambos campos, el UAS prueba primero la autorización privilegiada y, si falla, procesa la solicitud ordinaria. El registro debe mostrar qué rama se usó.

Las referencias de identidad de 2008 requieren contexto histórico. RFC 4474 fue sustituida por RFC 8224. La tesis no es que un mecanismo concreto gobierne hoy todas las redes, sino que identificación y autorización son recibos separados.

El medio entrante y el saliente tenían riesgos distintos

Una reproducción entrante puede ser spam, ruido, gasto o agotamiento de batería. Un medio saliente activa captura y puede convertir el dispositivo en escucha remota. RFC 5373 impone por eso una frontera más dura al flujo originado por el UAS.

Sin aceptación explícita del usuario, el terminal no debe establecer medio saliente o bidireccional. El bucle diagnóstico queda exceptuado porque devuelve la señal de prueba y no la habitación. Para entrada automática, una identidad desconocida o no autorizada tampoco debería obtener reproducción.

La aceptación inicial no dura para siempre. Un diálogo que comenzó en recepción puede recibir un re-INVITE o UPDATE para volverse bidireccional. Aunque los campos Answer-Mode solo se definen para el INVITE inicial y su 200, la protección debe inspeccionar el estado posterior y exigir una nueva acción humana.

El primer 200 no eliminaba los demás teléfonos

El fork paralelo puede enviar el INVITE a varios contactos. La auto-respuesta aumenta la posibilidad de varios 200. SIP conserva el primer diálogo y envía BYE a los restantes, pero algún terminal perdedor puede haber reproducido medio antes del cierre.

Medir solo el diálogo ganador oculta esa superficie. Deben conservarse todas las ramas, el tiempo de cada 200, el inicio del medio y el BYE. La RFC no recomienda auto-answer cuando existe fork paralelo; no lo convierte en un problema resuelto por la selección de contacto.

La respuesta podía guardar silencio por privacidad

El 200 puede incluir Answer-Mode: Manual o Auto para informar cómo respondió el UAS. Revelar Manual puede delatar la presencia de una persona, por lo que la configuración predeterminada recomendada es omitir el campo.

Omisión significa «no divulgado», no «manual», «automático» ni «incompatible». Si el campo está presente, describe interacción con la interfaz. No demuestra escucha, comprensión, identidad humana o resultado de negocio.

Límite probatorio

El expediente debe unir identidad y método de autenticación, campo ordinario o privilegiado, ambos usos de require, contacto y ramas, transformaciones autorizadas del proxy, versión de política, respuesta, divulgación opcional, dirección SDP por versión, aceptación humana y paquetes realmente emitidos. Atención y resultado quedan aparte.

Así puede afirmarse que un UAS trató una petición conforme a una política. No puede afirmarse que la sintaxis tomó una decisión por la persona.