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

RFC 3261                       SIP: Session Initiation Protocol                    Junho 2002





dar preferência às respostas que fornecem informações que afetam a re-submissão desta 

requisição, como respostas 401, 407, 415, 420 e 484 se a classe 4xx for escolhida. Um 

proxy que recebe uma resposta 503 (Service Unavailable) NÃO DEVE enviá-lo a upstream a 

menos que ele possa determinar que todas requisições subsequentes que ele pode proxyiar 

também vai gerar uma resposta 503. Em outras palavras, encaminhando uma Resposta 503 

significa que o proxy sabe que não pode atender todas requisições, não apenas aquela no 

Request-URI na requisição que gerou a resposta 503. Se a única resposta que foi recebida 

for uma Resposta 503, o proxy DEVE gerar uma Resposta 500 e encaminhá-la a upstream.





A resposta enviada PRECISA ser processadas como descrito nos passos "Agregando Valores 

no Campo-Cabeçalho Authorization" e "Record-Route".



Por exemplo, se um proxy encaminhou uma requisição a 4 lugares, e recebeu Respostas 503, 

407, 501 e 404, ele pode escolher encaminhar a resposta 407 (Proxy Authentication Required).



Respostas 1xx e 2xx podem ser envolvidas no estabelecimento de diálogos. Quando uma 

requisição não tiver um tag no campo-cabeçalho To, o tag presente no campo-cabeçalho To na 

resposta é usada pelo UAC para distinguir múltiplas respostas a um diálogo que cria 

requisição. Um proxy NÃO PODE inserir um tag no campo-cabeçalho To de uma resposta 1xx ou 

2xx se a requisição não tiver um. Um proxy NÃO PODE modificar o tag no campo-cabeçalho To 

de uma Resposta 1xx ou 2xx.



Como um proxy não pode inserir um tag no campo-cabeçalho To de uma Resposta 1xx a uma 

requisição que não contém um tag, ele não pode lançar respostas provisórias não-100 por 

conta própria. Contudo, ele pode ramificar a requisição para um UAS que partilha o mesmo 

elemento que o proxy. Este UAS pode retornar as suas próprias respostas provisórias, que 

entram em um diálogo early com o inicializador da requisição. O UAS não precisa ser um 

processo discreto do proxy. Ele pode ser um UAS virtual implementado no mesmo espaço de 

código que o proxy.



Respostas 3-6xx são entregues de salto-a-salto. Quando emitir uma resposta 3-6xx, o elemento 

está efetivamente agindo como um UAS, lançando sua própria resposta, normalmente baseado nas 

respostas recebidas a partir de elementos a downstream. Um elemento DEVE preservar o tag do 

campo-cabeçalho To quando simplesmente encaminhando uma resposta 3-6xx a uma requisição que 

não tenha um tag no campo-cabeçalho To.



Um proxy NÃO PODE modificar o tag presente no campo-cabeçalho To a qualquer resposta encaminhada a 

uma requisição que contenha um tag no campo-cabeçalho To.













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

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.