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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


2. Verificação do Esquema URI

Se o Request-URI tem um URI cujo esquema não é compreendido pelo proxy, o proxy DEVE rejeitar a requisição com uma resposta 416 (Unsupported URI Scheme).


3. Verificação do Max-Forwards

O campo-cabeçalho Max-Forwards (Seção 20.22) é usado para limitar o número de elementos que uma requisição SIP podem atravessar.

Se a requisição não contiver um campo-cabeçalho Max-Forwards, essa verificação é passada.

Se a requisição contiver um campo-cabeçalho Max-Forwards com um valor de campo maior que zero, a verificação é passada.

Se a requisição contiver um campo-cabeçalho Max-Forwards com um valor de campo zero (0), o elemento NÃO PODE encaminhar a requisição. Se a requisição foi para OPTIONS, o elemento PODE agir como o destino final e responder conforme a Seção 11. Caso contrário, o elemento PRECISA retornar uma resposta 483 (Too many hops).


4. Verificação do Opcional de Detecção de Loop

Um elemento PODE verificar loops de encaminhamento antes de encaminhar uma requisição. Se a requisição contiver um campo-cabeçalho Via com um enviado por valor que iguala a um valor colocado em requisições anteriores pelo proxy, a requisição foi encaminhada por esse elemento antes. A requisição tanto entrou em loop quanto é legitimamente enrolada em espiral através do elemento. Para determinar se a requisição entrou em loop, o elemento PODE executar cálculo com o parâmetro branch descrito na etapa 8 da Seção 16.6 nessa mensagem e compará-lo com o parâmetro recebido nesse campo cabeçalho Via. Se os parâmetros conferirem, a requisição entrou em loop. Se eles diferirem, a requisição está em espiral, e o processamento continua. Se um loop for detectado, o elemento PODE retornar uma resposta 482 (Loop Detected).


5. Verificação de Proxy-Require

Extensões futuras a esse protocolo podem introduzir características que exijam tratamento especial por proxy's. Endpoints irão incluir um campo-cabeçalho Proxy-Require em requisições que usam esses recursos, informando ao proxy não processar a requisição a menos que o recurso seja entendido.





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

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.