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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Como cada tentativa usa uma nova transação cliente, ela representa um novo branch. Assim, o parâmetro branch fornecido com o campo-cabeçalho Via inserido na etapa 8 PRECISA ser diferente para cada tentativa.

Se a transação cliente relatar falha ao enviar a requisição ou um tempo limite de sua máquina de estado, o proxy continua até o próximo endereço nesse conjunto ordenado. Se o conjunto ordenado se esgotar, a requisição não pode ser encaminhada a esse elemento no conjunto alvo. O proxy não precisa colocar nada no contexto de resposta, mas ao contrário, age como se esse elemento do conjunto alvo retornasse uma resposta 408 (Request Timeout) final.


8. Adicionar um valor no campo-cabeçalho Via

O proxy PRECISA inserir um valor no campo-cabeçalho Via na cópia antes dos valores de campo-cabeçalho Via existentes. A construção desse valor segue as mesmas orientações da Seção 8.1.1.7. Isto implica que o proxy irá computar o seu próprio parâmetro branch, que será globalmente único para esse branch, e conterá o cookie mágico necessário. Note que isso implica que o parâmetro branch será diferente para diferentes instâncias de uma requisição espiralada ou em loop através de um proxy.

Proxy's escolhendo detectar loops têm uma restrição adicional no valor que eles usam para construir o parâmetro branch. Um proxy escolhendo detectar loops DEVE criar um parâmetro branch separável em duas partes pela implementação. A primeira parte PRECISA satisfazer as restrições da Seção 8.1.1.7 conforme descrita acima. A segunda é usada para executar a detecção de loop e distinguir loops de espirais.

Detecção de laço é executado verificando que, quando uma requisição volta a um proxy, aqueles campos tendo impacto sobre o processamento da requisição não foram alterados. O valor colocado nessa parte do parâmetro branch DEVE refletir todos aqueles campos (incluindo quaisquer campos-cabeçalhos Route, Proxy-Require e Proxy-Authorization). Isso é para garantir que se a requisição for roteada de volta ao proxy e um desses campos muda, ela é tratada como uma espiral e não um loop (ver Seção 16.3). Uma maneira comum de criar esse valor é computar um hash criptográfico da tag de To, tag de From, do campo-cabeçalho Call-ID, o Request-URI da requisição recebida (antes da tradução), o cabeçalho Via mais alto, e o número de seqüência do campo-cabeçalho CSeq, em adição a quaisquer campos-cabeçalhos Proxy-Require e Proxy-Authorization que podem estar presentes. O 







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

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.