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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


20.5 Allow

O campo-cabeçalho Allow lista o conjunto de métodos suportados pelo UA que gera a mensagem.

Todos os métodos, incluindo ACK e CANCEL, compreendidos pelo UA PRECISAM ser incluídos na lista de métodos no campo-cabeçalho Allow, quando presentes. A ausência de um campo-cabeçalho Allow NÃO PODE ser interpretado significando que o UA ao enviar a mensagem não suporta nenhum método. Ao contrário, isso implica que o UA não está fornecendo nenhuma informação sobre quais métodos ele suporta.

Ao fornecer um campo-cabeçalho Allow em respostas aos métodos exceto OPTIONS reduz o número de mensagens necessárias.

Exemplo:

      Allow: INVITE, ACK, OPTIONS, CANCEL, BYE


20.6 Authentication-Info

O campo-cabeçalho Authentication-Info fornece autenticação mútua com HTTP Digest. Um UAS PODE incluir esse campo-cabeçalho em uma resposta 2xx a uma requisição que foi autenticada com sucesso usando digest baseado no campo-cabeçalho Authorization.

Síntaxe e semântica segue aquilo especificado na RFC 2617 [17].

Exemplo:

      Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"


20.7 Authorization

O campo-cabeçalho Authorization contém credenciais de autenticação de um UA. A Seção 22.2 dá uma visão geral do uso do campo-cabeçalho Authorization, e a Seção 22.4 descreve a syntaxe e semantica quando usado com autenticação HTTP.

Esse campo-cabeçalho, junto com o Proxy-Authorization, divide as regras gerais em múltiplos valores de campo-cabeçalho. Apesar de não uma lista separada por comma, esse nome de campo-cabeçalho pode estar presente várias vezes, e NÃO PODE ser combinado em uma única linha de cabeçalho usando as regras usuais descritas na Seção 7.3.







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

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.