RFC 3261 Português Página 199 :: 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 199

RFC 3261            SIP: Session Initiation Protocol           Junho 2002
cada desafio, os servidores proxy que emitiram os desafios não encaminharão requisições ao UA, onde o usuário destino pode ser localizado e, portanto, as virtudes de bifurcar são perdidas enormemente.
Ao submeter novamente sua requisição em resposta a uma 401 (Unauthorized) ou 407 (Proxy Authentication Required) que contém múltiplos desafios, um UAC PODE incluir um valor de Authorization para cada valor de WWW-Authenticate e um valor de Proxy-Authorization para cada valor de Proxy-Authenticate ao qual o UAC deseja fornecer uma credencial. Como observado acima, várias credenciais em uma requisição DEVEM ser diferenciadas pelo parâmetro "realm".
É possível para múltiplos desafios associados com o mesmo realm aparecer na mesma 401 (Unauthorized) ou 407 (Proxy Authentication Required). Isso pode ocorrer, por exemplo, quando vários proxys dentro do mesmo domínio administrativo, que usam um realm comum, são alcançados por uma requisição que bifurca. Quando ele re-tenta uma requisição, um UAC PODE, portanto, fornecer múltiplas credenciais em campos-cabeçalhos Authorization ou Proxy-Authorization com o mesmo valor do parâmetro "realm". As mesmas credenciais DEVEM ser usadas com o mesmo realm.
22.4 O Esquema de Autenticação Digest
Essa seção descreve as modificações e esclarecimentos necessários ao aplicar o esquema de autenticação Digest do HTTP ao SIP. O uso do esquema SIP é quase completamente idêntico ao do HTTP [17].
Como a RFC 2543 é baseada no Digest do HTTP conforme definido na RFC 2069 [39], servidores SIP ao suportar a RFC 2617 PRECISA garantir que eles sejam retro-compatíveis com a RFC 2069. Procedimentos para essa retro-compatibilidade são especificados na RFC 2617. Note, no entanto, que servidores SIP NÃO PODEM aceitar ou requisitar a autenticação Básica.
As regras para autenticação Digest seguem aquelas definidas em [17], com o "HTTP/1.1" substituída por "SIP/2.0", além das seguintes diferenças:
1. O URI incluido no desafio tem a seguinte BNF:
URI = SIP-URI / SIPS-URI
2. O BNF na RFC 2617 tem um erro nesse o parâmetro 'uri' do campo-cabeçalho Authorization para autenticação Digest do HTTP
Rosenberg, et. al.          Standards Track                   [Página 199]


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.