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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Processar resposta conforme descrito na Seção 16.7 não se aplica a um proxy se comportando de modo stateless. Quando uma resposta chega de um proxy sem estado, o proxy PRECISA inspecionar o valor enviado por no primeiro valor do campo-cabeçalho Via (mais alto). Se esse endereço corresponde ao proxy, (que equivale a um valor esse proxy inseriu em requisições anteriores) o proxy PRECISA remover esse valor do campo-cabeçalho da resposta e encaminhar o resultado ao local indicado nos próximo valor do campo-cabeçalho Via. O proxy NÃO PODE adicionar, modificar ou remover o corpo da mensagem. Salvo especificado em contrário, o proxy NÃO PODE remover quaisquer outros valores de campo-cabeçalho. Se o endereço não corresponde ao proxy, a mensagem PRECISA ser silenciosamente descartada.


16.12 Sumário de Processamento de Campo-Cabeçalho Route no Proxy

Na ausência de política local em contrário, o processamento de um proxy executado sobre uma requisição que contém um campo-cabeçalho Route pode ser resumido nas seguintes etapas.


1.  O proxy irá inspecionar o Request-URI. Se esse indicar um recurso possuído pelo proxy, o proxy irá substituí-lo pelos resultados da execução de um serviço de localização. Caso contrário, o proxy não irá alterar o Request-URI.

2.  O proxy irá inspeccionar o URI no valor do campo-cabeçalho Route mais alto. Se esse indica esse proxy, o proxy remove-lo-á do campo-cabeçalho Route (esse nó de rota foi alcançado).

3.  O proxy irá encaminhar a requisição para o recurso indicado pelo URI no valor do campo-cabeçalho Route mais alto ou no Request-URI se nenhum campo-cabeçalho Route estiver presente. O proxy determina o endereço, a porta, e transporte a usar ao encaminhar a requisição aplicando os procedimentos descritos em [4] para esse URI.

Se nenhum elemento strict-routing for encontrado no caminho da requisição, a Request-URI sempre indicará o destino da requisição.


16.12.1 Exemplos

16.12.1.1 Trapezóide SIP Básico

Esse cenário é o trapezóide básico do SIP, U1 -> P1 -> P2 -> U2, com ambos os proxy's realizando record-route. Aqui está o fluxo.






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

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.