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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


da Seção 16.6, item 6, a identidade desse próximo salto, é expresso como um URI do SIP ou do SIPS, é inserida como o valor do campo-cabeçalho Route mais-alto na requisição.

Se o Request-URI indicar um recurso nesse proxy que não existe, o proxy PRECISA retornar uma resposta 404 (Not Found).

Se o conjunto destino permanecer vazio após aplicar todas as anteriores, o proxy PRECISA retornar uma resposta de erro, a qual DEVE ser a resposta 480 (Temporarily Unavailable).


16.6 Encaminhando Requisição

Assim como o conjunto destino é não-vazio, um proxy PODE iniciar encaminhando a requisição. Um proxy stateful PODE processar o conjunto em qualquer ordem. Ele PODE processar múltiplos alvos em série, permitindo a cada transação cliente ser concluída antes de começar a próxima. Ele PODE disparar transações clientes para cada alvo em  paralelo. Ele também PODE arbitrariamente dividir o conjunto em grupos, processar grupos em série e processar os alvos em cada grupo em paralelo.

Um mecanismo comum para ordenação é usar o parâmetro qvalue de alvos obtidos de campos-cabeçalhos Contact (veja Seção 20.10). Alvos são processados do qvalue maior para o menor. Alvos com iguais qvalues, podem ser processados em paralelo.

Um proxy stateful precisa ter um mecanismo para manter o conjunto destino quando respostas são recebidas e associar as respostas a cada requisição encaminhada com a requisição original. Para os propósitos desse modelo, esse mecanismo é um "contexto de resposta" criado pela camada proxy antes de encaminhar a primeira requisição.

Para cada destino, o proxy encaminha a requisição seguindo essas etapas:

1.  Fazer uma cópia da requisição recebida

2.  Atualizar o Request-URI

3.  Atualizar o campo-cabeçalho Max-Forwards

4.  Opcionalmente adiciona um valor no campo-cabeçalho Record-Route

5.  Opcionalmente adiciona campos-cabeçalhos adicionais

6.  Pós-processa informação de roteamento

7.  Determina o endereço, porta e transporte do next-hop





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

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.