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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


20.11 Content-Disposition

O campo-cabeçalho Content-Disposition descreve como o corpo da mensagem ou, para mensagens multi-partes, uma parte do corpo da mensagem deve ser interpretada pelo UAC ou UAS. Esse campo-cabeçalho do SIP estende o Content-Type do MIME (RFC 2183 [18]).

Vários novos "disposition-types" do campo-cabeçalho Content-Disposition são definidos no SIP. O valor "session" indica que a parte do corpo descreve uma sessão, tanto para chamadas ou early (pré-chamada) mídia. O valor "render" indica que a parte do corpo deve ser exibida ou, do contrário, processado pelo usuário. Note que o valor "render" é usado ao invés de "inline" para evitar a conotação de que o corpo MIME é exibida como parte da entrega para qualquer uso de toda a mensagem (já que os corpos MIME de mensagens SIP muitas vezes não são exibidos aos usuários). Por retro-compatibilidade, se o campo-cabeçalho Content-Disposition estiver faltando, o servidor DEVE assumir que corpos application/sdp de Content-Type estão a disposição de "session", enquanto outros tipos de conteúdo são "render".

O tipo disposition "icon" indica que a parte do corpo contém uma imagem adequada como uma representação icônica do chamador ou chamado que poderiam ser processado informacionalmente por um agente-usuário quando uma mensagem foi recebida, ou persistentemente, enquanto um diálogo acontece. O valor "alert" indica que a parte do corpo contém informações, como clipe de áudio, que devem ser processado pelo agente-usuário em uma tentativa de alertar o usuário para a recepção de uma requisição, geralmente uma requisição que inicia um diálogo; esse corpo alerta poderia por exemplo ser processado como um tom de toque para uma chamada de telefone após uma resposta provisória 180 Ringing ter sido enviada.

Qualquer corpo MIME com uma "disposition-tipe" que processa o conteúdo para o usuário só deve ser processado ​​quando uma mensagem foi devidamente autenticada.

O parâmetro handling, handling-param, descreve como o UAS deve reagir se receber um corpo de mensagem cujo tipo de conteúdo ou tipo de disposição que não compreende. O parâmetro tem valores definidos como "optional" e "required". Se o parâmetro handling estiver faltando, o valor "required" DEVE ser assumido. O parâmetro handling é descrito na RFC 3204 [19].

Se esse campo-cabeçalho estiver faltando, o tipo MIME determina a disposição de conteúdo padrão. Se não houver nenhum, "render" é assumido.

Exemplo:

      Content-Disposition: session



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

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.