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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


PODE aparecer em ambas as formas longas e curtas dentro da mesma mensagem. Implementações PRECISAM aceitar ambas as formas longas e curtas de cada nome de cabeçalho.


7.4 Corpos

Requisições, incluindo novas requisições definidas em extensões a essa especificação, PODEM conter corpos de mensagens salvo dito em contrário. A interpretação do corpo depende do método de requisição.

Para mensagens de resposta, o método de requisição e código de status de resposta determinam o tipo e a interpretação de qualquer corpo de mensagem. Todas as respostas PODEM incluir um corpo.


7.4.1 Tipo de Corpo de Mensagem

O tipo de mídia Internet do corpo da mensagem PRECISA ser fornecido pelo campo-cabeçalho Content-Type. Se o corpo for submetido a qualquer codificação, como compressão, então isso PRECISA ser indicado pelo campo-cabeçalho Content-Encoding; do contrário, Content-Encoding PRECISA ser omitido. Se for aplicável, o conjunto de caracteres do corpo da mensagem é indicado como parte do valor do campo-cabeçalho Content-Type.

O tipo MIME "multipart" definido na RFC 2046 [11] PODE ser usado dentro do corpo da mensagem. Implementações que enviam requisições contendo corpos de mensagem multipart PRECISAM enviar uma descrição de sessão como um corpo de mensagem não-multipart se a implementação remota requisitar isso através de um campo cabeçalho Accept que não contém multipart.

Mensagens do SIP PODEM conter corpos binários ou partes do corpo. Quando nenhum parâmetro charset for fornecido pelo remetente, subtipos de mídia do tipo "texto" são definidos para ter um valor charset padrão "UTF-8".


7.4.2 Tamanho do Corpo da Mensagem

O tamanho do corpo em bytes é fornecido pelo campo-cabeçalho Content-Length. Seção 20.14 descreve o conteúdo necessário desse campo-cabeçalho em detalhes.

A codificação de transferência "fragmentada" do HTTP/1.1 NÃO PODE ser usada com o SIP. (Nota: A codificação fragmentada modifica o corpo de uma mensagem a fim de transferi-la como uma série de blocos, cada um com seu próprio indicador tamanho).






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

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.