RFC 3261 Português Página 194

RFC 3261 SIP: Session Initiation Protocol Junho 2002

Os requisitos para inclusão do Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate, e Authorization nas várias mensagens são idênticas àquelas descritas na RFC 2617 [17].

Como o SIP não tem o conceito de um URL canônico raiz, a noção de espaços de proteção é interpretada de forma diferente no SIP. A string realm sozinho define o domínio de proteção. Essa é uma mudança desde a RFC 2543, em que o Request-URI e o realm juntos definiam o domínio de proteção.

Essa definição anterior de domínio de proteção causava alguma confusão porque o Request-URI enviado pelo UAC e o Request-URI recebido pelo servidor que desafia poderiam ser diferentes, e de fato a forma final do Request-URI não podia ser conhecido pelo UAC. Além disso, a definição anterior dependia da presença de um URI do SIP no Request-URI e parecia descartar esquemas URI alternativos (por exemplo, o URL tel).

Operadores de agentes-usuários ou servidores proxy que autenticarão requisições recebidas PRECISAM aderir às seguintes orientações para criação de uma string realm para seu servidor:

o Strings realm PRECISAM ser globalmente únicas. É RECOMENDADO que uma string realm contém um hostname ou nome de domínio, seguindo a recomendação na Seção 3.2.1 da RFC 2617 [17].

o Strings realm DEVEM apresentar um identificador legivel a humanos que possa ser submetido a um usuário.

Por exemplo:

INVITE sip:bob@biloxi.com SIP/2.0
Authorization: Digest realm="biloxi.com", <...>

Geralmente, a autenticação do SIP é pensada para um realm específico, um domínio de proteção. Assim, para autenticação Digest, cada domínio de proteção tem seu próprio conjunto de nomes de usuário e senhas. Se um servidor não precisa de autenticação para uma requisição particular, ele PODE aceitar um username padrão, "anonymous", que não tem nenhuma password (password ""). De forma similar, UAC's que representam muitos usuários, como gateway's PSTN, PODEM ter seu próprio username e password específicos do dispositivo, em vez de contas para usuários específicos, para seu realm.

Enquanto um servidor pode legitimamente desafiar muitas requisições do SIP, existem duas requisições definidas por esse documento que requerem um tratamento especial para autenticação: ACK e CANCEL.

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

Página Anterior

Tabela de Conteúdo

Página Seguinte



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.