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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


8.  Adiciona um valor no campo-cabeçalho Via

9.  Adiciona um campo-cabeçalho Content-Length se necessário

10. Encaminha a nova requisição

11. Define o timer C


Cada um desses passos está detalhado abaixo:

1. Copiar requisição

O proxy começa com uma cópia da requisição recebida. A cópia PRECISA inicialmente conter todos os campos-cabeçalhos da requisição recebida. Campos não detalhados no processamento descrito abaixo NÃO PODEM ser removidos. A cópia DEVE manter a ordenação dos campos-cabeçalhos como na requisição recebido. O proxy NÃO PODE reordenar valores de campo com um nome comum de campo (ver Seção 7.3.1). O proxy NÃO PODE adicionar, modificar ou remover o corpo da mensagem.

Uma implementação real necessita não executar uma cópia; a exigência primária é que o processamento para cada próximo salto comece com a mesma requisição.


2. Request-URI

O Request-URI na linha inicial da cópia PRECISA ser substituído pelo URI desse destino. Se o URI contiver quaisquer parâmetros não permitidos em um Request-URI, elas PRECISAM ser removidos.

Essa é a essência da função de um proxy. Esse é o mecanismo pelo qual um proxy roteia uma requisição para seu destino.

Em algumas circunstâncias, o Request-URI recebida é colocado no conjunto destino sem ser modificada. Para esse alvo, a substituição acima é efetivamente uma no-op.


3. Max-Forwards

Se a cópia contiver um campo-cabeçalho Max-Forwards, o proxy PRECISA decrementar o seu valor por 1 (um).

Se a cópia não contiver um campo-cabeçalho Max-Forwards, o proxy PRECISA adicionar um com um valor de campo, o qual DEVE ser 70.

Alguns UA's existentes não fornecem um campo-cabeçalho Max-Forwards em uma requisição.




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

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.