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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


4. Record-Route

Se esse proxy deseja permanecer no caminho de futuras requisições em um diálogo criado por essa requisição (assumindo que a requisição cria um diálogo), ele PRECISA inserir um valor no campo-cabeçalho Record-Route na cópia antes de qualquer valores do campo-cabeçalho Record-Route existentes, mesmo que um campo-cabeçalho Route já esteja presente.

Requisições que estabelece um diálogo pode conter um campo-cabeçalho Route pré-carregado.

Se essa requisição já faz parte de um diálogo, o proxy DEVE inserir um valor no campo-cabeçalho Record-Route se ele quiser continuar no caminho de futuras requisições no diálogo. Em operação endpoint normal conforme descrito na Seção 12, esses valores de campo-cabeçalho Record-Route não terão qualquer efeito no conjunto de rotas usada pelos endpoints.

O proxy permanecerá no caminho se ele escolher não inserir um valor no campo-cabeçalho Record-Route em requisições que já são parte de um diálogo. Contudo, ele seria removido do caminho quando um endpoint que falhou reconstitui o diálogo.

Um proxy PODE inserir um valor no campo-cabeçalho Record-Route em qualquer requisição. Se a requisição não iniciar um diálogo, as pontas irão ignorar o valor. Consulte a Seção 12 para obter detalhes de como endpoints usam valores no campo-cabeçalho Record-Route para construir campos-cabeçalhos Route.

Cada proxy no caminho de uma requisição escolhe se quer adicionar ou não um valor no campo-cabeçalho Record-Route de forma independente - a presença de um campo-cabeçalho Record-Route em uma requisição não obriga esse proxy adicionar um valor.

O URI colocado no valor do campo-cabeçalho Record-Route PRECISA ser um URI do SIP ou do SIPS. Esse URI PRECISA conter um parâmetro lr (ver a Seção 19.1.1). Esse URI PODE ser diferente para todo destino ao qual a requisição é encaminhada. O URI NÃO DEVE conter o parâmetro transport a menos que o proxy tenha conhecimento (como em uma rede privada) que o próximo elemento downstream que estará no caminho de requisições subseqüentes suporte esse transporte.

O URI que esse proxy oferece será usado por algum outro elemento para tomar uma decisão de roteamento. Esse proxy, em geral, não tem nenhuma forma de saber as capacidades desse elemento, por isso que ele precisa se limitar aos elementos obrigatórios de uma implementação SIP: URI's do SIP e tanto transporte TCP como UDP.






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

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.