RFC 3261 SIP: Session Initiation Protocol Junho 2002
Um corpo da mensagem contendo uma descrição de recursos de mídia PODE estar presente na resposta, a qual é formatada de acordo com o campo-cabeçalho Accept no INVITE (ou application/sdp se não estiver presente), o mesmo que um corpo de mensagem em uma resposta 200 (OK) a uma requisição OPTIONS.
Espera-se que a negociação não será frequentemente necessário, e quando um novo usuário está sendo chamado se juntar a uma conferência já existente, a negociação não pode ser possível. Cabe ao iniciador do convite decidir se deve ou não agir em uma resposta 606 (Not Acceptable).
Essa resposta status é retornada só se o cliente sabe que nenhum outro endpoint atenderá a requisição.
22 Uso da Autenticação HTTP
O SIP fornece um mecanismo stateless baseado em desafio para autenticação que é baseado na autenticação HTTP. A qualquer instante que um servidor proxy ou UA recebe uma requisição (com as exceções dadas na Seção 22.1), ele PODE desafiar o iniciador da requisição para fornecer uma garantia da sua identidade. Uma vez que o autor foi identificado, o destinatário da requisição DEVE determinar se este usuário está ou não autorizado a fazer a requisição em questão. Nenhum sistema de autorização é recomendado ou discutido nesse documento.
O mecanismo de autenticação "Digest" descrito nessa seção fornece autenticação de mensagens e proteção a respostas só, sem integridade de mensagem ou confidencialidade. Medidas de proteção acima e além daquelas fornecidas pelo Digest precisam ser tomadas para evitar atacantes ativos de modificar requisições e respostas do SIP.
Note que devido à sua segurança fraca, o uso de autenticação "Básica" foi descontinuado. Servidores NÃO PODEM aceitar credenciais usando o esquema "Básico" de autorização, e os servidores NÃO PODEM também desafiar com o "Básico". Essa é uma mudança desde a RFC 2543.
22.1 Infra-Estrutura
A infra-estrutura para autenticação do SIP se aproxima bastante daquela do HTTP (RFC 2617 [17]). Em particular, a BNF para auth-scheme, auth-param, challenge, realm, realm-value e credenciais é idêntica (embora o uso do "Básico" como um esquema não é permitido). No SIP, um UAS usa a resposta 401 (Unauthorized) para desafiar a identidade de um UAC. Adicionalmente, servidores registradores e redirect's PODEM fazer uso de respostas 401 (Unauthorized) para autenticação, mas proxy's NÃO PODEM, e em vez disso PODEM usar a resposta 407 (Proxy Authentication Required).
Rosenberg, et. al. Standards Track [Página 193]
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:
Postar um comentário