Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


credenciais para esse realm ao longo dos diálogos. Note que isso não significa que uma requisição futura em um diálogo poderia conter credenciais que não são necessárias por qualquer proxy no caminho do cabeçalho Route.

Qualquer UA que deseja autenticar-se a um servidor proxy - geralmente, mas não necessariamente, após receber uma resposta 407 (Proxy Authentication Required) - PODE fazer assim, incluindo um valor no campo-cabeçalho Proxy-Authorization com a requisição. O campo-cabeçalho Proxy-Authorization da requisição permite ao cliente identificar-se (ou seu usuário) a um proxy que exige autenticação. O valor do campo-cabeçalho Proxy-Authorization consiste de credenciais contendo as informações de autenticação do UA ao proxy e/ou realm do recurso sendo requisitado.

Um valor do campo-cabeçalho Proxy-Authorization se aplica só ao proxy cujo realm é identificado no parâmetro "realm" (esse proxy pode previamente ter exigido a autenticação usando o campo Proxy-Authenticate). Quando vários proxy's são usados em uma chain, um valor do campo-cabeçalho Proxy-Authorization NÃO PODE ser consumido por qualquer proxy cujo realm não bate com o parâmetro "realm" especificado nesse valor.

Note que se um esquema de autenticação que não suporta realms é usado no campo-cabeçalho Proxy-Authorization, um servidor proxy PRECISA tentar analisar todos os valores do campo-cabeçalho Proxy-Authorization para determinar se um deles tem o que o servidor proxy considera ser credenciais válidas. Porque essa é potencialmente muito demorado em grandes redes, servidores proxy DEVEM usar um esquema de autenticação que suporta realms no campo-cabeçalho Proxy-Authorization.

Se uma requisição for bifurcada (como descrito na Seção 16.7), vários servidores proxy e/ou UA's podem querer desafiar o UAC. Nesse caso, o servidor proxy bifurcando é responsável por agregar esses desafios em uma única resposta. Cada valor WWW-Authenticate e Proxy-Authenticate recebido nas respostas a requisição bifurcada PRECISA ser colocados na única resposta que é enviada pelo proxy bifurcando ao UA, a ordem desses valores no campo-cabeçalho não é significativo.

Quando um servidor proxy emite um desafio em resposta a uma requisição, não   proxy-ará a requisição até que o UAC tenha repetido a requisição com credenciais válidas. Um proxy ao bifurcar pode encaminhar uma requisição simultaneamente a vários servidores proxy que exigem autenticação, cada qual por sua vez, não encaminhará a requisição até que o UAC originador tenha se autenticado em seu realm respectivo. Se o UAC não fornecer credenciais para




Rosenberg, et. al.          Standards Track                   [Página 198]

Observações importantes a cerca dessa tradução:
A tradução de algumas terminologias do SIP:

User agent ficou como agente-usuário;
Header field como campo-cabeçalho;
Requests ficou em português como requisições no plural e no singular requisição.

Quanto às palavras/verbos usadas em documentos RFC's tramitando em trilha de 
padronizações, que obedecem as regras da RFC 2119/IETF, foram traduzidas
para o português conforme a seguir:

MUST:
    PRECISA, REQUERER, OBRIGAR, EXIGIR, FORÇAR, É OBRIGATÓRIO, É FORÇOSO, 
    NECESSITAR, É MANDATÓRIO.

MUST NOT:
    NÃO PODE, É PROIBIDO, É VEDADO.

SHOULD:
    DEVE, É RECOMENDADO.

SHOULD NOT:
    NÃO DEVE, NÃO É RECOMENDADO.

MAY:
    PODE, É OPCIONAL.