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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Isso difere ligeiramente da definição HTTP, a qual indica que quando não presente, nenhuma codificação pode ser usada, mas a codificação de identidade é preferida.

Exemplo:

      Accept-Encoding: gzip


20.3 Accept-Language

O campo-cabeçalho Accept-Language é usado em requisições para indicar as línguas preferidas para frases rasões, descrições de sessão, ou respostas de status transportadas nos corpos da mensagem na resposta. Se nenhum campo-cabeçalho Accept-Language estiver presente, o servidor DEVE assumir que todas as línguas são aceitas no cliente.

O campo-cabeçalho Accept-Language segue a síntaxe definida em [H14.4]. As regras para ordenar as línguas baseada no parâmetro "q" se aplicam ao SIP também.

Exemplo:

      Accept-Language: da, en-gb;q=0.8, en;q=0.7


20.4 Alert-Info

Quando presentes em uma requisição INVITE, o campo-cabeçalho Alert-Info especifica um toque alternativo ao UAS. Quando presente em uma resposta 180 (Ringing), o campo-cabeçalho Alert-Info especifica um tom ringback alternativo ao UAC. Um uso típico é para um proxy inserir esse campo-cabeçalho para fornecer um recurso de toque diferenciado.

O campo-cabeçalho Alert-Info pode introduzir riscos à segurança. Esses riscos e as formas de lidar com eles são discutidos na Seção 20.9, que discute o campo-cabeçalho Call-Info já que os riscos são idênticos.

Em adição, um usuário DEVE ser capaz de desabilitar esse recurso seletivamente.


Isso ajuda a evitar perturbações que poderiam resultar do uso desse campo-cabeçalho por elementos não-confiáveis​​.

Exemplo:

      Alert-Info: <http: moo.wav="" sounds="" www.example.com="">





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

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.