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

RFC 3261                      SIP: Session Initiation Protocol                     Junho 2002





Ao passo que isso não faz qualquer diferença aos elementos upstream se o proxy substituiu 

o tag presente no campo-cabeçalho To em uma resposta 3-6xx encaminhada, preservar o tag 

original pode ajudar a depuração.



Quando o proxy está agregando informações de várias respostas, escolher um tag para o 

campo-cabeçalho To dentre elas é arbitrário, e gerar um novo tag para o campo-cabeçalho 

To pode tornar a depuração mais fácil. Isto acontece, por exemplo, quando combinando 

desafios 401 (Unauthorized) e 407 (Proxy Authentication Required), ou combinando valores 

de campo-cabeçalho Contact nas respostas 3xx não criptografadas e não autenticadas.





7.  Agregando Valores no Campo-Cabeçalho Authorization



Se a resposta escolhida for uma 401 (Unauthorized) ou 407 (Proxy Authentication Required), 

o proxy PRECISA coletar quaisquer valores nos campos-cabeçalho WWW-Authenticate e 

Proxy-Authenticate de todas as outras respostas 401 (Unauthorized) e 407 (Proxy 

Authentication Required) recebidas até aqui nesse contexto resposta e adicioná-los a esta 

resposta sem modificação antes de encaminhar. A resposta 401 (Unauthorized) ou 407 (Proxy 

Authentication Required) resultante pode ter vários valores de campos-cabeçalho WWW-Authenticate 

e Proxy-Authenticate.



Isto é necessário porque alguns ou todos os destinos para os quais a requisição foi 

encaminhada pode ter requisitado credenciais. O cliente precisa receber todos estes 

desafios e fornecer as credenciais para cada um deles quando ele repetir a requisição. 

A motivação para esse comportamento é previsto na Seção 26.





8.  Record-Route



Se a resposta selecionada tiver um valor no campo-cabeçalho Record-Route inicialmente 

previsto por esse proxy, o proxy PODE escolher reescrever o valor antes de encaminhar 

a resposta. Isto permite que o proxy forneça diferentes URI's por conta própria aos 

próximos elementos a upstream e a downstream. Um proxy pode escolher por usar esse 

mecanismo por qualquer motivo. Por exemplo, é útil em servidores com múltiplas interfaces 

de rede.



Se o proxy recebeu a requisição sobre o TLS, e a enviou através de uma conexão não-TLS, 

o proxy PRECISA reescrever a URI no campo-cabeçalho Record-Route para ser um URI do SIPS. 

Se o proxy recebeu a requisição através de uma conexão não-TLS, e a enviou sobre o TLS, 

o proxy PRECISA reescrever o URI no campo-cabeçalho Record-Route para ser um URI do SIP.















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

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.