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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


P4 não é responsável pelo recurso indicado no Request-URI assim ele vai deixá-lo isolado. Ele percebe que é o elemento no primeiro valor do campo-cabeçalho Route assim ele remove-o. Então ele prepara para enviar a requisição baseado no agora primeiro valor no campo-cabeçalho Route de sip: p3.middle.com, mas percebe que esse URI não contém o parâmetro lr, assim antes de enviar, ele reformata a requisição para ficar:

      BYE sip:p3.middle.com SIP/2.0
      Route: <sip:p2.example.com;lr>
      Route: <sip:p1.example.com;lr>
      Route: <sip:caller@u1.example.com>

P3 é um roteador strict, de modo que ele encaminha o seguinte a P2:

      BYE sip:p2.example.com;lr SIP/2.0
      Route: <sip:p1.example.com;lr>
      Route: <sip:caller@u1.example.com>

P2 vê que o request-URI é um valor colocado em um campo-cabeçalho Record-Route, portanto antes de mais processamento posterior, ele reescreve a requisição para ficar:

      BYE sip:caller@u1.example.com SIP/2.0
      Route: <sip:p1.example.com;lr>

P2 não é responsável por u1.example.com, então ele envia a requsição para P1 baseado na resolução no valor do campo-cabeçalho Route.

P1 percebe-se no valor do campo-cabeçalho Route mais alto, então remove-o, resultando em:

      BYE sip:caller@u1.example.com SIP/2.0

Como P1 não é responsável por u1.example.com e não há nenhum campo-cabeçalho Route, P1 vai encaminhar a requisição para u1.example.com baseado no Request-URI.


16.12.1.3 Reescrevendo Valores do Campo-Cabeçalho Record-Route

Neste cenário, U1 e U2 estão em diferentes espaços de nome privados e eles entram em um diálogo através do proxy P1, que atua como um gateway entre os espaços de nome.

      U1->P1->U2







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

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.