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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


o  sip:carol@chicago.com;security=on e sip:carol@chicago.com;security=off não são equivalentes


19.1.5 Formando Requisições a partir de um URI

Uma implementação precisa tomar cuidado ao formar requisições diretamente de um URI. URI's de cartões de visita, páginas web, e até mesmo de origens internas ao protocolo como contatos registrados podem conter campos-cabeçalhos ou partes do corpo inadequados.

Uma implementação PRECISA incluir qualquer parâmetro transport, maddr, ttl ou user no Request-URI da requisição formada. Se o URI contém um parâmetro method, seu valor PRECISA ser usado como método da requisição. O parâmetro method NÃO PODE ser colocado no Request-URI. Parâmetros URI desconhecidos PRECISA ser colocado no Request-URI da mensagem.

Uma implementação DEVE tratar a presença de quaisquer cabeçalhos ou partes do corpo no URI como um desejo de incluí-los na mensagem, e escolher honrar a requisição numa base por-componente.

Uma implementação NÃO DEVE honrar esses campos-cabeçalhos obviamente perigosos: From, Call-ID, CSeq, Via e Record-Route.

Uma implementação NÃO DEVE honrar quaisquer valores requisitados no campo-cabeçalho Route a fim de não serem usados como um agente involuntário em ataques maliciosos.

Uma implementação NÃO DEVE honrar requisições para incluir campos-cabeçalhos que podem fazê-lo anunciar falsamente sua localização ou capacidades. Esses incluem: Accept, Accept-Encoding, Accept-Language, Allow, Contact (em seu uso em diálogo), Organization, Supported e User-Agent.

Uma implementação DEVE verificar a precisão de quaisquer campos-cabeçalhos descritivos requisitados, incluindo: Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-Type, Date, Mime-Version e Timestamp.

Se a requisição formada da construção de uma mensagem a partir de um URI dado não é uma requisição SIP válida, o URI é inválido. Uma implementação NÃO PODE proceder a transmissão da requisição. Ao contrário, deve prosseguir o curso de ação devido a um URI inválido no contexto em que ocorre.

A requisição construída pode ser inválida de muitas maneiras. Essas incluem, mas não estão limitadas a, erro de sintaxe em campos-cabeçalhos, combinações inválidas de parâmetros URI ou uma descrição incorreta do corpo da mensagem.




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

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.