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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Note que Require e Proxy-Require NÃO PODEM ser usados em uma requisição CANCEL do SIP, ou em uma requisição ACK enviada devido a uma resposta não-2xx. Esses campos-cabeçalhos PRECISAM ser ignorados se estiverem presentes nessas requisições.

Uma requisição ACK para uma resposta 2xx PRECISA conter apenas aqueles valores dos campos Require e Proxy-Require que estavam presentes na requisição inicial.

Exemplo:

      UAC->UAS:   INVITE sip:watson@bell-telephone.com SIP/2.0
                  Require: 100rel

      UAS->UAC:   SIP/2.0 420 Bad Extension
                  Unsupported: 100rel

Esse comportamento garante que a interação cliente-servidor irá proceder, sem atraso quando todas as opções são entendidas por ambos os lados, e só ficará lento se as opções não forem entendidas (como no exemplo acima). Para um par cliente-servidor, bem combinado, a interação prosseguirá rapidamente, economizando tempo de ida e de volta muitas vezes exigido por mecanismos de negociação. Além disso, ele também remove ambigüidade quando o cliente exige recursos que o servidor não entende. Algumas características, como campos para gerenciamento de chamadas, são apenas de interesse dos sistemas fins.


8.2.3 Processando Conteúdo

Supondo que o UAS entende todas as extensões exigidas pelo cliente, o UAS examina o corpo da mensagem, e os campos-cabeçalhos que as descreve. Se houver alguns corpos cujo tipo (indicado por Content-Type), língua (indicado por Content-Language) ou codificação (indicado por Content-Encoding) não for entendido, e que parte do corpo não é opcional (conforme indicado pelo campo-cabeçalho Content-Disposition), o UAS PRECISA rejeitar a requisição com uma resposta 415 (Unsupported Media Type). A resposta PRECISA conter um campo-cabeçalho Accept que lista os tipos de todos os corpos que ele compreende, no evento que os tipos de corpos contidos na requisição não são suportados pelo UAS. Se a requisição continha codificações de conteúdo não compreendido pelo UAS, a resposta PRECISA conter um campo-cabeçalho Accept-Encoding listando as codificações compreendidas pelo UAS. Se a requisição continha conteúdo com línguas não entendidas pelo UAS, a resposta PRECISA incluir um campo-cabeçalho Accept-Language indicando línguas compreendidas pelo UAS. Além dessas verificações, a manipulação do corpo depende do método e tipo. Para mais informações sobre o processamento dos campos-cabeçalhos de conteúdo específico, consulte a Seção 7.4, bem como da Seção 20.11 até a 20.15.





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

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.