RFC 3261 Português Página 104

RFC 3261 SIP: Session Initiation Protocol Junho 2002

- O proxy PRECISA colocar o Request-URI no campo-cabeçalho Route como o último valor.

- O proxy PRECISA então colocar o primeiro valor do campo-cabeçalho Route no Request-URI e remover esse valor do campo-cabeçalho Route.

Anexar o Request-URI ao campo-cabeçalho Route é parte de um mecanismo usado para passar a informação nesse Request-URI através de elementos de roteamento rígidos. "Encaixar" o valor do primeiro campo-cabeçalho Route no Request-URI formata a mensagem na forma em que um elemento de roteamento rígido espera recebê-la (com a seu próprio URI no Request-URI e o próximo local a visitar no valor do primeiro campo-cabeçalho Route).

7. Determinar Endereço, Porta e Transporte do Next-Hop

O proxy PODE ter uma política local de enviar a requisição a um específico endereço IP, porta e transporte, independente dos valores de Route e de Request-URI. Tal política NÃO PODE ser usada se o proxy não tiver certeza que o endereço IP, porta e transporte corresponde a um servidor que é um roteador menos-rígido. Contudo, esse mecanismo para enviar a requisição através de um next-hop específico NÃO é RECOMENDADO; em vez disso um campo-cabeçalho Route devem ser usado com esse fim como descrito acima.

Na ausência desse mecanismo primordial, o proxy aplica os procedimentos listados em [4] como segue para determinar para onde enviar a requisição. Se o proxy reformatou a requisição a enviar a um elemento de roteamento rígido como descrito na etapa 6 acima, o proxy PRECISA aplicar esses procedimentos ao Request-URI da requisição. Caso contrário, o proxy PRECISA aplicar os procedimentos ao primeiro valor no campo-cabeçalho Route, se houver, e depois no campo Request-URI. Os procedimentos produzirão um conjunto ordenado de tuplas (endereço, porta, transporte). Independentemente de qual URI será usado como entrada para os procedimentos de [4], se o Request-URI especificar um recurso SIPS, o proxy PRECISA seguir os procedimentos de [4] como se o URI de entrada fosse um URI do SIPS.

Como descrito em [4], o proxy PRECISA tentar entregar a mensagem com a primeira tupla nesse conjunto, e prosseguir no conjunto em ordem até a tentativa de entrega seja bem-sucedida.

Para cada tupla tentada, o proxy PRECISA formatar a mensagem quando apropriado pela tupla e enviar a requisição usando uma nova transação cliente conforme descrito nas etapas 8 a 10.

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

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.