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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


U1 Envia:

INVITE sip:callee@domain.com SIP/2.0
Contact: sip:caller@u1.example.com

para P1. P1 é um proxy de saída. P1 não é responsável por domain.com, assim ele o busca no DNS e envia-o pra lá. Ele também adiciona um valor no campo-cabeçalho Record-Route: 

      INVITE sip:callee@domain.com SIP/2.0
      Contact: sip:caller@u1.example.com
      Record-Route: <sip:p1.example.com;lr>

P2 pega isso. Ele é responsável por domain.com assim ele executa um serviço de localização e reescreve o Request-URI. Ele também adiciona um valor no campo-cabeçalho Record-Route. Não há qualquer campo-cabeçalho Route, assim ele resolve o novo Request-URI para determinar para onde enviar a requisição:

      INVITE sip:callee@u2.domain.com SIP/2.0
      Contact: sip:caller@u1.example.com
      Record-Route: <sip:p2.domain.com;lr>
      Record-Route: <sip:p1.example.com;lr>

A parte chamada em u2.domain.com pega isso e responde com uma 200 OK:

      SIP/2.0 200 OK
      Contact: sip:callee@u2.domain.com
      Record-Route: <sip:p2.domain.com;lr>
      Record-Route: <sip:p1.example.com;lr>

O chamado em u2 também define seu URI do destino remoto de estado do diálogo como sip:caller@u1.example.com e seu conjunto rota como:

      (<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)

Essa é encaminhada por P2 para P1 para U1 como normal. Agora, U1 define seu URI do destino remoto de estado do diálogo como sip:callee@u2.domain.com e seu conjunto rota como:

      (<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)

Como todos os elementos do conjunto rota contém o parâmetro lr, U1 constrói a seguinte requisição BYE:

BYE sip:callee@u2.domain.com SIP/2.0
Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>





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

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.