RFC 3261 Português Página 197 :: Admirável Mundo Novo




Muito Bem Vindo

Prezado Leitor, a proposta desse Blog é compartilhar conhecimento com as pessoas que trabalham com Linux, Asterisk, OpenSER, e com tecnologia de voz sobre a rede IP em geral, através de tutoriais, dicas, howto, notícias entre outros assuntos.

Atente para termo de uso do conteúdo do blog no rodapé da página.

domingo, 10 de julho de 2011

RFC 3261 Português Página 197

RFC 3261            SIP: Session Initiation Protocol           Junho 2002
22.3 Autenticação Proxy-a-Usuário
De forma similar, quando um UAC envia uma requisição a um servidor proxy, o servidor proxy PODE autenticar o originador antes da requisição ser processada. Se nenhuma credencial (no campo-cabeçalho Proxy-Authorization) for fornecida na requisição, o proxy pode desafiar o originador a fornecer credenciais ao rejeitar a requisição com um código status 407 (Proxy Authentication Required). O proxy PRECISA preencher a mensagem 407 (Proxy Authentication Required) com um valor de campo-cabeçalho Proxy-Authenticate aplicável ao proxy para o recurso requisitado.
O uso paralelo de Proxy-Authenticate e Proxy-Authorization que é descrito em [17], com uma diferença. Proxy's NÃO PODEM adicionar valores ao campo-cabeçalho Proxy-Authorization. Todos as respostas 407 (Proxy Authentication Required) PRECISAM ser encaminhadas upstream ao UAC seguindo os procedimentos para qualquer outra resposta. É responsabilidade do UAC adicionar o valor do campo-cabeçalho Proxy-Authorization que contém as credenciais para o realm do proxy que pediu para autenticação.
Se um proxy foi submeter uma requisição adicionando um valor no campo-cabeçalho Proxy-Authorization, seria necessário incrementar o CSeq na nova requisição. No entanto, isso faria que o UAC que submeteu a requisição original descartar uma resposta do UAS, conforme o valor do CSeq seria diferente.
Quando o UAC originador recebe a 407 (Proxy Authentication Required), ele DEVE, se for capaz, re-originar a requisição com as credenciais adequadas. Ele deve seguir os mesmos procedimentos para exibição do parâmetro "realm" que são fornecidos acima ao responder com 401.
Se nenhuma credencial para um realm puder ser localizado, UAC's PODE tentar repetir a requisição com um username "anonymous" e nenhuma senha (uma password "").
O UAC DEVE também cache as credenciais usadas na requisição re-originada.
A regra seguinte é RECOMENDADA para cache-ar a credencial do proxy:
Se um UA recebe um valor no campo-cabeçalho Proxy-Authenticate em uma resposta 401/407 a uma requisição com um Call-ID particular, ele deve incorporar as credenciais para esse realm em todas as requisições subsequentes que contêm o mesmo Call-ID. Essas credenciais NÃO PODEM ser cache-adas ao longo dos diálogos, contudo, se um UA for configurado com o realm do seu proxy saínte local, quando um existir, então o UA PODE cache-ar
Rosenberg, et. al.          Standards Track                   [Página 197]


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.



Nenhum comentário:




Creative Commons License
Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP
by Cléviton Mendes de Araújo is licensed under a Creative Commons Atribuição 2.5 Brasil License.