RFC 3261 Português Página 113

RFC 3261 SIP: Session Initiation Protocol Junho 2002

O novo URI fornecido pelo proxy PRECISA satisfazer as mesmas restrições em URI's

colocados em campos-cabeçalhos Record-Route em requisições (veja passo 4 da Seção

16.6) com as seguintes modificações:

O URI NÃO DEVE conter o parâmetro transport a menos que o proxy saiba qual o

próximo elemento a upstream (em oposição a downstream) que estará no caminho de

requisições subsequentes suporta esse transporte.

Quando um proxy decide alterar o campo-cabeçalho Record-Route na resposta, uma das

operações que ele realiza é localizar o valor de Record-Route que ele inseriu. Se

a requisição espiralou, e o proxy inseriu um valor no Record-Route em cada iteração

da espiral, localizar o valor correto na resposta (que precisa ser a interação

adequada na direção inversa) é complicado. As regras acima recomendam que um proxy

que desejam reescrever valores nos campos-cabeçalhos Record-Route insere URI's

suficientemente distintas no campo-cabeçalho Record-Route de modo que o correto

pode ser selecionado para reescrever. Um mecanismo RECOMENDADO para alcançar isso é

o proxy anexar um identificador único para a instância proxy a parte usuário do URI.

Quando a resposta chegar, o proxy modifica o primeiro Record-Route, cujo

identificador bate com a instância proxy. A modificação resulta em URI sem esse

pedaço de dados anexados à parte usuário do URI. Na próxima iteração, o mesmo

algoritmo (buscar o valor do campo-cabeçalho Record-Route mais alto com o

parâmetro) irá corretamente extrair o valor campo-cabeçalho Record-Route

seguinte inserido por esse proxy.

Nem toda resposta a uma requisição a qual um proxy adiciona um valor do

campo-cabeçalho Record-Route irá conter um campo-cabeçalho Record-Route. Se a

resposta tiver um campo-cabeçalho Record-Route, ele irá conter o valor que o

proxy acrescentou.

9. Encaminhar resposta

Após realizar o processamento descrito nas etapas "Agregando Valores nos

Campos-Cabeçalhos Authorization" até "Record-Route", o proxy PODE executar

qualquer manipulação específica de recurso na resposta selecionada. O proxy

NÃO PODE adicionar, modificar ou remover o corpo da mensagem. Salvo especificado

em contrário, o proxy NÃO PODE remover quaisquer valores de campos-cabeçalhos que

não seja o valor do campo-cabeçalho Via discutido na Seção 16.7 Item 3. Em

particular, o proxy NÃO PODE remover qualquer parâmetro "received"

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

Página Anterior

Tabela de Conteúdo

Página Seguinte

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.