Resumen

  • RFC 3487 pidió que la indicación de prioridad SIP invocara una política nombrada, sin prescribir cola, expulsión, capacidad reservada ni duración.
  • Una misma etiqueta podía cambiar de efecto entre pasarela, red de circuitos, proxy y receptor; reconocerla no demostraba autorización, recursos ni comunicación lograda.

Una emergencia no vuelve homogénea a la red. Puede congestionar los enlaces, destruir capacidad, saturar una pasarela o llenar un centro receptor. En 2003, RFC 3487 no respondió con un interruptor llamado «prioridad». Antes de definir un mecanismo concreto, preguntó qué recurso era escaso y quién tenía autoridad para decidir sobre él.

La respuesta produjo cinco superficies. Las pasarelas disponen de un número finito de troncales hacia redes conmutadas. Esas redes tienen sus propios circuitos y sistemas como GETS o MLPP. La red IP transporta señalización y medios, pero la calidad de audio o vídeo no es una decisión de SIP. El receptor tiene un máximo de sesiones. El proxy consume cálculo de manera desigual según la petición. Una sola escasez aparente escondía cinco contabilidades.

Cada una admitía tratamientos distintos. La pasarela podía adelantar un intento o buscar una ruta alternativa. Una red de circuitos podía expulsar una llamada si lo permitían la regulación y el procedimiento local. El receptor podía avisar de que esperaba una llamada importante. Un proxy podía ordenar, rechazar o descartar. RFC 3487 negó que todos tuvieran que compartir mecanismo.

La ruta decidía cuáles de esas superficies aparecían. El documento separó IP a IP, IP a red conmutada, red conmutada a IP y el puente CSN-IP-CSN. En este último, el origen podía ignorar el protocolo de la red remota. El bifurcado SIP añadía destinos de distinta naturaleza. La etiqueta viajaba, pero no otorgaba al emisor conocimiento total del trayecto.

Tampoco todas las redes IP permitían el mismo cambio. Una red preparada para ETS podía modificar routers y reservas. Una red transparente solo transportaba paquetes válidos. Otra podía admitir SIP y RTP pero bloquear RSVP o DSCP. Una red SIP restringida podía prohibir extensiones. El diseño útil debía atravesar esas diferencias sin suponer un único operador.

La pieza central fue separar política y mecanismo. Una llamada por valor habría escrito en el mensaje instrucciones detalladas: poner en cola, no expulsar, limitar a tres minutos. La llamada por referencia nombraba una política. La entidad dueña del recurso resolvía cómo aplicarla. Hasta la fracción de capacidad para cada nivel quedaba bajo control local.

Así, una misma indicación podía provocar expulsión en un punto y solo evitar el descarte en otro. Cuando la demanda prioritaria era pequeña, esperar quizá causaba menos daño que terminar una conversación. Con otro tamaño de sistema, la expulsión podía ser necesaria. Esa variación no era un error de interoperabilidad, sino la consecuencia de conservar la decisión junto al recurso.

Los demás requisitos protegían la delgadez de la interfaz. Los espacios de nombres debían albergar regímenes nacionales y privados. La indicación no podía depender de una arquitectura, operador o dirección. Debía viajar como SIP válido y servir para varios métodos. Si ambos extremos de un puente usaban el mismo régimen, la traducción debía conservar información; con regímenes distintos, el RFC admitía pérdida.

Descubrir compatibilidad tampoco equivalía a obtener servicio. Un terminal podía consultar los espacios aceptados o aprender por una respuesta de rechazo. En una red sin soporte, el comportamiento deseable era no tratar la petición peor que una ordinaria, aunque una política local podía exigir marca y autenticación. Soporte, autorización, capacidad y finalización eran cuatro hechos.

La identidad no resolvía la autorización. La misma persona podía hacer comunicaciones normales y prioritarias; la elección dependía del contexto y del juicio humano. RFC 3487 combinó identidad autenticada, elección y política. Ni el campo From confería rango permanente ni la selección de una etiqueta demostraba derecho de uso.

Por eso la seguridad ocupó el centro. Abusar de la prioridad podía negar a los usuarios legítimos los recursos que el sistema pretendía proteger. Convenía autenticar pronto para reducir paquetes, cómputo y circuitos consumidos por un intruso. Cada nodo debía poder verificar autorización sin confiar ciegamente en la cadena. Repetición, copia parcial y degradación de nivel tenían amenazas propias.

La privacidad añadía tensión. Un trabajador podía usar un terminal ajeno sin entregar una contraseña reutilizable. El solo hecho de solicitar prioridad podía revelar información sensible. Los datos necesarios para enrutar requerían una protección distinta de los que podían cifrarse de extremo a extremo. Indicación y autenticador no debían fusionarse.

RFC 4412 concretó después la idea en Resource-Priority y Accept-Resource-Priority. Un espacio y un valor expresaban la prioridad deseada; OPTIONS podía anunciar valores. Pero aceptar un valor no implicaba recursos suficientes ni éxito. RFC 5115, 5478, 6401, 6735 y 8443 añadieron transporte de prioridad, nombres, admisión y autorización sin convertir la cabecera en recibo final.

La reconstrucción correcta empieza con actor, identidad, espacio, valor, método SIP y topología. Después registra cada pasarela, dominio conmutado, proxy y receptor, junto con la versión de política consultada. Ruta, cola, admisión, expulsión, asignación de medios y conversación efectiva siguen siendo sucesos independientes.

La distinción de Heng Lu entre símbolo y control ejecutable ayuda a leer esta historia. La etiqueta fue común porque no pretendió gobernarlo todo. Nombró una política portátil y dejó el acto a quien soportaba el coste del recurso. RFC 3487 coordinó una pregunta; nunca fingió que todas las redes debían contestarla igual.

Fuentes