RFC 3261 Português Página 98

RFC 3261 SIP: Session Initiation Protocol Junho 2002

para sip:John.Smith@company.com pode ser ambíguo em um proxy cujo serviço de localização tem múltiplos John Smiths listados. Consulte a Seção 21.4.23 para detalhes.

Qualquer informação na ou sobre a requisição ou o ambiente atual do elemento PODE ser usado na construção do conjunto alvo. Por exemplo, diferentes conjuntos podem ser construídos dependendo do conteúdo ou a presença de campos-cabeçalhos e corpos, a hora do dia da chegada da requisição, a interface na qual a requisição chegou, falta de requisições anteriores, ou mesmo o nível atual de utilização do elemento.

Como alvos potenciais são localizados através desses serviços, suas URI's são acrescentadas ao conjunto alvo. Alvos só podem ser colocados no conjunto alvo uma vez. Se um URI alvo já estiver presente no conjunto (baseado na definição de igualdade para o tipo de URI), ela NÃO PODE ser adicionada novamente.

Um proxy NÃO PODE adicionar alvos adicionais ao conjunto destino se o Request-URI da requisição original não indicar um recurso pelo qual esse proxy seja responsável.

Um proxy só pode alterar o Request-URI de uma requisição durante o encaminhamento se ele for responsável por esse URI. Se o proxy não for responsável por esse URI, ele não fará recursão em respostas 3xx ou 416 como descrito abaixo.

Se o Request-URI da requisição original indicar um recurso pelo qual esse proxy é responsável, o proxy PODE continuar a acrescentar alvos ao conjunto após iniciar o Encaminhamento de Requisição. Ele PODE usar qualquer informação obtida durante esse processamento para determinar novos alvos. Por exemplo, um proxy podem escolher incorporar contatos obtidos em uma resposta redirec (3xx) no conjunto destino. Se um proxy usar uma fonte de informação dinâmica enquanto constrói o conjunto destino (por exemplo, se ele consultar um registrador SIP), ele DEVE monitorar essa fonte durante o processamento da requisição. Novos locais DEVEM ser adicionados ao conjunto destino quando eles se tornam disponíveis. Como acima, qualquer URI fornecido NÃO PODE ser adicionado ao conjunto mais de uma vez.

Permitir um URI a ser adicionada ao conjunto só uma vez reduz tráfego de rede desnecessário e, no caso de incorporar contatos a partir de requisições redirect impede recursão infinita.

Por exemplo, um serviço de localização trivial é um "no-op, onde o URI do alvo é igual ao URI da requisição entrante. A requisição é enviada a um proxy do próximo salto específico para mais processamento. Durante o encaminhamento da requisição

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

Página Anterior

Tabela de Conteúdo

Página Seguinte



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.