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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


4. Encaminhar a requisição para cada alvo (Seção 16.6)

5. Processar todas as respostas (Seção 16.7)


16.3 Validação da Requisição

Antes que um elemento possa proxy-iar uma requisição, ele PRECISA verificar a validade da mensagem. Uma mensagem válida precisa passar pelas seguintes verificações:

1. Sintaxe Razoável

2. Esquema URI

3. Max-Forwards

4. (Opcional) Detecção de Loop

5. Proxy-Require

6. Proxy-Authorization

Se qualquer dessas verificações falhar, o elemento PRECISA se comportar como um servidor agente-usuário (ver Seção 8.2) e responder com um código de erro.

Observe que um proxy não é obrigado a detectar requisições mescladas e NÃO PODE tratar requisições mescladas como uma condição de erro. As pontas que recebem as requisições resolverá a mesclagem como descrito na Seção 8.2.2.2.


1. Verificação de Sintaxe Razoável

A requisição PRECISA ser bem formada suficientemente para ser tratada por uma transação servidor. Todos os componentes envolvidos no restante dessas etapas de Validação de Requisição ou na seção de Encaminhamento de Requisição PRECISA ser bem formados. Quaisquer outros componentes, bem-formados ou não, DEVEM ser ignorados e permanecem inalterados quando a mensagem for encaminhada. Por exemplo, um elemento não rejeitaria uma requisição por causa de um campo-cabeçalho Date malformado. Da mesma forma, um proxy não removeria um campo-cabeçalho Date malformado antes de encaminhar uma requisição.

Esse protocolo foi projetado para ser extendido. Extensões futuras podem definir novos métodos e novos campos-cabeçalhos a qualquer tempo. Um elemento NÃO PODE recusar-se a proxy-iar uma requisição porque ela contém um método ou um campo-cabeçalho a respeito do qual ele não conhece.





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

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.