RFC 3261 Português Página 106

RFC 3261 SIP: Session Initiation Protocol Junho 2002

algoritmo usado para computar o hash é dependente da implementação, mas MD5 (RFC 1321 [35]), expressos em hexadecimal, é uma escolha razoável. (Base64 não é admissível a um token).

Se um proxy pretende detectar loops, o parâmetro "branch" que ele fornece PRECISA depender de toda informação que afetam o processamento de uma requisição, incluindo o Request-URI entrante e os campos-cabeçalhos que afectam a admissão ou o roteamento da requisição. Isso é necessário para distinguir requisições em loop a partir de requisições cujos parâmetros de roteamento mudaram antes de retornar a esse servidor.

O método da requisição NÃO PODE ser incluído no cálculo do parâmetro branch. Em particular, requisições CANCEL e ACK (para respostas não-2xx) PRECISAM ter o mesmo valor de branch da requisição correspondente as quais elas cancelam ou reconhecem. O parâmetro branch é usado para correlacionar aquelas requisições no servidor que as trata (ver as Seções 17.2.3 e 9.2).

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

Se a requisição for enviada para o próximo salto usando um transporte baseado em fluxo e a cópia não contiver nenhum campo-cabeçalho Content-Length, o proxy PRECISA inserir um com o valor correto no corpo da requisição (ver Seção 20.14).

10. Encaminhar a Requisição

Um proxy stateful PRECISA criar uma nova transação cliente pra essa requisição como descrito na Seção 17.1 e instruir a transação a enviar a requisição usando o endereço, porta e transporte, conforme determinado no passo 7.

11. Definir o timer C

A fim de tratar o caso onde uma requisição INVITE nunca gera uma resposta final, o TU usa um temporizador que é chamado de timer C. O timer C PRECISA ser ajustado para cada transação cliente quando uma requisição INVITE é proxy-ada. O temporizador PRECISA ser maior que 3 minutos. A Seção 16.7 no tópico 2 discute como esse temporizador é atualizado com respostas provisórias, e a Seção 16.8 discute o processamento quando ele é acionado.

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

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.