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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Um exemplo do campo-cabeçalho WWW-Authenticate em um desafio 401 é:

      WWW-Authenticate: Digest
              realm="biloxi.com",
              qop="auth,auth-int",
              nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
              opaque="5ccc069c403ebaf9f0171e9517f40e41"

Quando o UAC que origina recebe a 401 (Unauthorized), ele DEVE, se for capaz, re-originar a requisição com as credenciais adequadas. O UAC pode exigir a entrada do usuário originador antes de prosseguir. Uma vez que as credenciais de autenticação tenham sido fornecidas (tanto diretamente pelo usuário, ou descoberto em um keyring interno), UA's DEVEM cache-ar as credenciais para um dado valor do campo-cabeçalho To e "realm" e tentar re-usar esses valores na próxima requisição a esse destino. UA's PODEM cache-ar as credenciais da maneira que gostariam.

Se nenhuma credencial para um realm puder ser localizada, UAC's PODEM tentar repetir a requisição com um username "anonymous" e sem senha (a password "").

Uma vez as credenciais tenham sido localizadas, qualquer UA que desejar autenticar-se com um UAS ou registrador -- geralmente, mas não necessariamente, após receber uma resposta 401 (Unauthorized) -- PODE fazê-lo assim ao incluir um campo-cabeçalho Authorization com a requisição. O valor do campo Authorization consiste de credenciais que contêm as informações de autenticação do UA para o realm do recurso sendo requisitado, bem como parâmetros exigidos no suporte de proteção a autenticação e a resposta.

Um exemplo do campo-cabeçalho Authorization é:

      Authorization: Digest username="bob",
              realm="biloxi.com",
              nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
              uri="sip:bob@biloxi.com",
              qop=auth,
              nc=00000001,
              cnonce="0a4f113b",
              response="6629fae49393a05397450978507c4ef1",
              opaque="5ccc069c403ebaf9f0171e9517f40e41"

Quando um UAC resubmete uma requisição com suas credenciais após receber uma resposta 401 (Unauthorized) ou 407 (Proxy Authentication Required), ele PRECISA incrementar o valor do campo-cabeçalho CSeq como seria normalmente ao enviar uma requisição atualizada.



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

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.