Resumo

  • A RFC 3487 exigiu que a indicação de prioridade SIP chamasse uma política nomeada, sem prescrever fila, preempção, reserva de capacidade ou duração.
  • O mesmo rótulo podia ter efeitos diferentes em gateway, rede de circuitos, proxy e receptor; reconhecimento, autorização, admissão e comunicação eram comprovantes separados.

Em uma emergência, «prioridade» parece uma instrução suficiente. Mas a chamada atravessa organizações e máquinas que não compartilham o mesmo estoque escasso. A RFC 3487, publicada em 2003 como documento Informativo, preferiu definir os limites da pergunta antes de escolher uma extensão SIP. O resultado foi uma interface fina: o pedido nomearia uma política, sem programar à distância o equipamento que a executaria.

O texto identificou cinco recursos. Gateways tinham poucos troncos para redes de comutação de circuitos. A própria rede comutada possuía caminhos e regimes como GETS e MLPP. A rede IP tratava sinalização e mídia por controles diferentes. O sistema receptor só aceitava determinado número de sessões. O proxy podia esgotar processamento mesmo com largura de banda disponível. Não existia obrigação de usar um único mecanismo para todos.

Cada superfície permitia outra resposta. Um gateway podia adiantar a tentativa ou escolher rota alternativa. A rede de circuitos podia preemptar uma chamada quando regras locais permitissem. O receptor podia anunciar uma espera prioritária. O proxy podia agendar, rejeitar ou descartar. A mesma marca não transferia ao originador o poder de escolher entre esses custos.

A topologia mudava o conjunto de decisões. A RFC separou IP de ponta a ponta, IP para rede comutada, rede comutada para IP e o percurso CSN-IP-CSN. No último, a origem talvez ignorasse o protocolo usado do outro lado. Com bifurcação SIP, nem o gateway sabia necessariamente se o destino seria IP, circuito ou ambos. O sinal viajava sem carregar um mapa completo.

Havia também diferentes graus de abertura no IP. Uma rede preparada para ETS podia alterar roteadores e reservas. Uma rede transparente apenas encaminhava pacotes válidos. Outra podia aceitar SIP/RTP e bloquear RSVP ou DSCP. Uma rede SIP restrita podia impedir novas extensões. O mecanismo precisava atravessar essa variedade sem depender de um único operador.

Daí nasceu a separação entre política e mecanismo. Uma chamada por valor detalharia no pedido: prioridade de fila, sem preempção, limite de três minutos. Uma chamada por referência indicaria uma política nomeada. O elemento que controlava o recurso decidiria a ação. Até a parcela de capacidade associada a cada nível continuava local.

Essa escolha admitia resultados diferentes. Se os pedidos prioritários fossem raros e a capacidade grande, esperar poderia causar menos dano que interromper alguém. Em outro nó, a preempção seria necessária. Num proxy, talvez bastasse enfileirar em vez de descartar. A RFC aceitou explicitamente que a mesma indicação preemptasse aqui e apenas alterasse a fila ali.

Os demais requisitos protegiam a portabilidade do sinal. Namespaces acomodariam regimes nacionais e privados. A indicação não dependeria de uma arquitetura, operadora ou endereço. Seria SIP válido em banda e funcionaria para vários métodos. Em CSN-IP-CSN, a tradução deveria preservar informação quando os dois lados usassem o mesmo regime; regimes distintos poderiam impor perda.

Descobrir suporte não era receber capacidade. Um terminal poderia consultar namespaces aceitos ou aprender após uma tentativa. Numa rede sem suporte, o padrão desejado era não piorar o tratamento em relação a uma chamada comum, embora a política local pudesse exigir marca e autenticação. Compatibilidade, permissão, admissão e êxito permaneciam independentes.

A identidade também não decidia tudo. A mesma pessoa fazia pedidos comuns e prioritários, e o nível dependia da situação e do julgamento humano. A RFC combinou identidade autenticada, escolha do usuário e política. Nome no campo From não era privilégio permanente; rótulo selecionado não era prova de autorização.

Segurança tornou-se parte do mecanismo. O abuso de prioridade podia consumir os recursos protegidos e prejudicar usuários legítimos. Autenticar cedo reduzia pacotes, computação e circuitos gastos por agentes não autorizados. Cada nó deveria verificar autorização sem depender apenas de confiança transitiva. Repetição, recorte e colagem e rebaixamento exigiam defesa própria.

Privacidade trouxe um paradoxo. Um socorrista podia usar equipamento alheio e não deveria revelar um segredo reutilizável. A presença do pedido prioritário já podia expor informação sensível. Dados necessários ao roteamento pediam proteção por salto; outros podiam ser protegidos de ponta a ponta. Indicação e autenticação tinham de continuar separadas.

A RFC 4412 mais tarde definiu Resource-Priority e Accept-Resource-Priority. Namespace e valor expressavam prioridade desejada, e OPTIONS podia divulgar valores aceitos. Mesmo assim, aceitar um valor não significava ter recursos nem concluir a comunicação. As RFCs 5115, 5478, 6401, 6735 e 8443 acrescentaram roteamento, registros, admissão e autorização sem transformar a marca em resultado.

Para reconstruir um caso, preserve ator, identidade, namespace, valor, método SIP e topologia. Depois identifique gateway, domínio comutado, proxy e receptor, registrando a versão de política consultada. Rota, fila, admissão, preempção, mídia e contato humano precisam de eventos próprios.

A separação de Heng Lu entre símbolo e execução ajuda a entender a arquitetura. O rótulo conseguiu ser comum porque permaneceu limitado. Ele levou uma pergunta entre domínios, mas não tomou o lugar de quem controlava o recurso. A RFC 3487 coordenou o vocabulário e conservou a responsabilidade local pelo ato.

Fontes