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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Se a requisição tiver um campo-cabeçalho Proxy-Require (Seção 20.29) com um ou mais tags option que esse elemento não entende, o elemento PRECISA retornar uma resposta 420 (Bad Extension). A resposta PRECISA incluir um campo-cabeçalho Unsupported (Seção 20.40) listando aquelas tags option que o elemento não entendeu.


6. Verificação de Proxy-Authorization

Se um elemento exige credenciais antes de encaminhar uma requisição, a requisição PRECISA ser inspecionada como descrito na Seção 22.3. Essa seção também define o que o elemento precisa fazer se a inspeção falhar.


16.4 Pre-processando Informação de Rota

O proxy PRECISA inspecionar o Request-URI da requisição. Se o Request-URI da requisição tiver um valor que esse proxy previamente colocou em um campo-cabeçalho Record-Route (ver Seção 16.6 item 4), o proxy PRECISA substituir o Request-URI da requisição pelo último valor do campo-cabeçalho Route e remover esse valor do campo-cabeçalho Route. O proxy PRECISA então proceder como se ele recebesse essa requisição modificada.

Isso só acontecerá quando o elemento enviando a requisição ao proxy (o que pode ter sido uma ponta) é um roteador estrito. Essa reescrita quando se recebe é necessária para permitir a retro-compatibilidade com aqueles elementos. Isso também permite aos elementos seguindo essa especificação preservar o Request-URI através dos proxy's de roteamento estrito (ver Seção 12.2.1.1).

Essa exigência não obriga um proxy manter estado, a fim de detectar URI's que ele colocou anteriormente em campos-cabeçalhos Record-Route. Em vez disso, um proxy precisa só colocar informações suficientes naquelas URI's para reconhecê-las como valores que forneceu quando elas aparecem depois.

Se o Request-URI contiver um parâmetro maddr, o proxy PRECISA verificar pra ver se o seu valor está no conjunto de endereços ou domínios para o qual o proxy está configurado a ser responsável. Se o Request-URI tiver um parâmetro maddr com um valor para o qual proxy é responsável, e a requisição for recebida usando a porta e transporte indicados (explicitamente ou por padrão) no Request-URI, o proxy PRECISA retirar o maddr e qualquer porta não-padrão ou parâmetro transport e continuar processando como se esses valores não estivessem presentes na requisição.








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

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.