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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Uma requisição pode chegar com um maddr que confere com o proxy, mas por uma porta ou transporte diferente daqueles indicada no URI. Essa requisição necessita ser encaminhada ao proxy usando a porta e o transporte indicados.

Se o primeiro valor no campo-cabeçalho Route indicar esse proxy, o proxy PRECISA remover esse valor da requisição.


16.5 Determinando Alvos da Requisição

Em seguida, o proxy calcula o(s) alvo(s) da requisição. O conjunto de alvos tanto será pré-determinado pelo conteúdo da requisição quanto serão obtidos de um serviço de localização abstrato. Cada destino no conjunto é representado por um URI.

Se o Request-URI da requisição contiver um parâmetro maddr, o Request-URI PRECISA ser colocada no conjunto de alvo como o único URI alvo, e o proxy PRECISA proceder conforme descreve a Seção 16.6.

Se o domínio do Request-URI indicar um domínio pelo qual esse elemento não é responsável, o Request-URI PRECISA ser colocado no conjunto de alvo como o único alvo e, o elemento PRECISA prosseguir com a tarefa de Encaminhar a Requisição (Seção 16.6).

Existem muitas circunstâncias nas quais um proxy possa receber uma requisição para um domínio pelo qual ele não é responsável. Um proxy firewall tratando as chamadas saintes (a forma como proxy's HTTP manipular requisições saíntes) é um exemplo de onde isso é provável de ocorrer.

Se o alvo definido para a requisição não foi pré-determinado como descrito acima, isso implica que o elemento é responsável pelo domínio no Request-URI, e o elemento PODE usar qualquer mecanismo que ele deseja para determinar para onde enviar a requisição. Qualquer um desses mecanismos pode ser modelado como acessando um Serviço de Localização abstrato. Isso pode consistir na obtenção de informações a partir de um serviço de localização criado por registrador SIP, lendo um banco de dados, consultando um servidor de presença, usando outros protocolos, ou simplesmente executando uma substituição de algoritmo no Request-URI. Ao acessar o serviço de localização construído por um registrador, o Request-URI PRECISA ser primeiro ser posta em ordem canônica como descrito na Seção 10.3 antes de ser usada como um índice. A saída desses mecanismos é usada para construir o alvo definido.

Se o Request-URI não fornecer informações suficientes ao proxy determinar o conjunto destino, ele DEVE retornar uma resposta 485 (Ambiguous). Essa resposta DEVE conter um campo-cabeçalho Contact contendo os URI's de novos endereços a ser tentado. Por exemplo, um INVITE 



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

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.