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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


o proxy fizer recursão de todos os contatos em uma resposta 3xx, o proxy NÃO DEVE adicionar resposta resultante sem contato ao contexto resposta.

Removendo o contato antes de adicionar a resposta no contexto resposta impede que o próximo elemento upstream de repetir a localização que esse proxy já tentou.

Respostas 3xx podem conter uma mistura de URI's do SIP, SIPS, e não-SIP. Um proxy pode escolher fazer recursão das URI's do SIP e SIPS e colocar o resto no contexto resposta a ser retornado, potencialmente na resposta final.

Se um proxy receber uma resposta 416 (Unsupported URI Scheme) a uma requisição cuja esquema de Request-URI não for SIP, mas o esquema na requisição original recebida for SIP ou SIPS (isto é, o proxy mudou o esquema de SIP ou SIPS para outra coisa quando ele Proxy-iou uma requisição), o proxy DEVE adicionar uma nova URI ao conjunto destino. Esse URI DEVE ser uma versão do URI SIP daquele URI não-SIP que foi justamente tentada. No caso do URL tel, isso é feito colocando a parte assinantes do telefone do URL tel para onde a requisição anterior foi enviada. Consulte a Seção 19.1.6 para mais detalhes sobre a formação do URI's do SIP a partir de URL's tel.

Quanto a uma resposta 3xx, se uma proxy fizer "recursão" da 416 tentando um URI do SIP ou do SIPS em vez, a resposta 416 NÃO DEVE ser adicionada ao contexto resposta.

5.  Verifica Resposta para Encaminhamento

Até que uma resposta final seja enviada na transação servidor, as seguintes respostas PRECISAM ser encaminhadas imediatamente:

-  Qualquer resposta provisória que não seja 100 (Trying)

-  Qualquer resposta 2xx

Se a resposta 6xx for recebida, ela não é imediatamente encaminhada, mas o proxy stateful DEVE cancelar todas as transações clientes pendente como descrito na Seção 10, e ele NÃO PODE criar nenhum branch novo nesse contexto.

Essa é uma mudança em relação a RFC 2543, a qual obrigava que o proxy encaminhava a resposta 6xx imediatamente. Para uma transação INVITE, essa abordagem tinha o problema de que uma resposta 2xx poderia chegar com outro branch, nesse caso o proxy 






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

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.