RFC 3261 Português Página 102

RFC 3261 SIP: Session Initiation Protocol Junho 2002

O URI colocado no campo-cabeçalho Record-Route PRECISA resolver para o elemento inseri-lo (ou um adequado stand-in) quando os procedimentos do servidor de localização de [4] são aplicados a ele, de modo que as requisições subseqüentes alcançem o mesmo elemento SIP. Se o Request-URI contiver um URI do SIPS, ou o valor do campo-cabeçalho Route mais alto (após o pós-processamento abordado em 6) contiver um URI do SIPS, o URI colocado no campo-cabeçalho Record-Route PRECISA ser um URI do SIPS. Além disso, se a requisição não for recebida sobre o TLS, o proxy PRECISA inserir um campo-cabeçalho Record-Route. De forma similar, um proxy que recebe uma requisição sobre o TLS, mas gera uma requisição sem um URI do SIPS no Request-URI ou no valor do campo-cabeçalho Route mais alto (após o pós-processamento abordado em 6), PRECISA inserir um campo-cabeçalho Record-Route que não seja um URI do SIPS.

Um proxy em um perímetro de segurança PRECISA permanecer dentro do perímetro do diálogo.

Se o URI colocado no campo-cabeçalho Record-Route precisar ser reescrito, quando ele passa de volta em uma resposta, o URI PRECISA ser suficientemente distinto para colocar nesse momento. (A requisição pode espiralar através desse proxy, resultando em mais de um valor de campo-cabeçalho Record-Route sendo adicionado). Item 8 da Seção 16.7 recomenda um mecanismo para tornar o URI suficientemente distinto.

O proxy PODE incluir parâmetros no valor do campo-cabeçalho Record-Route. Esses serão ecoados em algumas respostas a requisição, como as respostas 200 (OK) ao INVITE. Tais parâmetros podem ser úteis para manter estado na mensagem ao invés do proxy.

Se um proxy necessitar estar no caminho de qualquer tipo de diálogo (como um straddling de um firewall), ele DEVE adicionar um valor no campo-cabeçalho Record-Route de cada requisição com um método que ele não compreende já que esse método pode ter semântica de diálogo.

O URI que um proxy coloca em um campo-cabeçalho Record-Route é válido só durante a vida-útil de todo diálogo criado pela transação na qual ele ocorre. Um proxy dialog-stateful, por exemplo, PODE recusar a aceitar requisições futuras com esse valor no Request-URI após o diálogo ter terminado. Proxy's não-diálogo-stateful, naturalmente, não têm noção de quando o diálogo foi encerrado, mas eles PODEM codificar a informação suficiente no valor para compará-la com o identificador de diálogo de futuras requisições e PODEM rejeitar requisições que não batem com essa informação. Endpoints NÃO PODEM usar um URI obtido a partir de um campo-cabeçalho Record-Route fora do diálogo no qual ele foi fornecido. Consulte

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

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.