RFC 3261 SIP: Session Initiation Protocol Junho 2002
Como qualquer outro elemento (incluindo proxy's) faria, ele resolve o URI que consta no valor do campo-cabeçalho Route mais alto usando DNS para determinar para onde enviar a requisição. Esse segue para P1. P1 percebe que não é responsável pelo recurso indicado no Request-URI de modo que não o altera. Ele vê que ele é o primeiro valor no campo-cabeçalho Route, então ele remove tal valor, e encaminha a requisição para P2:
BYE sip:callee@u2.domain.com SIP/2.0
Route: <sip:p2.domain.com;lr>
P2 também percebe que não é responsável pelo recurso indicado no Request-URI (ele é responsável por domain.com, e não por u2.domain.com), de modo que não o altera. Ele se vê no primeiro valor do campo-cabeçalho Route, assim remove-o e encaminha para o seguinte u2.domain.com baseado em uma consulta DNS verificando o Request-URI:
BYE sip:callee@u2.domain.com SIP/2.0
16.12.1.2 Atravesando um Proxy Strict-Routing
Nesse cenário, um diálogo é estabelecido através de quatro proxy's, cada qual acrescenta valores no campo-cabeçalho Record-Route. O terceiro proxy implementa os procedimentos strict-routing especificados na RFC 2543 e muitos mecanismos em progresso.
U1->P1->P2->P3->P4->U2
O INVITE ao chegar em U2 contém:
INVITE sip:callee@u2.domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p4.domain.com;lr>
Record-Route: <sip:p3.middle.com>
Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr>
O que U2 responde com uma 200 OK. Depois, U2 envia a seguinte requsição BYE para P4 baseado no primeiro valor campo-cabeçalho Route.
BYE sip:caller@u1.example.com SIP/2.0
Route: <sip:p4.domain.com;lr>
Route: <sip:p3.middle.com>
Route: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>
Rosenberg, et. al. Standards Track [Página 120]
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.
Nenhum comentário:
Postar um comentário