RFC 3261 SIP: Session Initiation Protocol Junho 2002
a Seção 12 para obter mais informações sobre o uso de campos-cabeçalhos Record-Route em um endpoint.
Usar Record-route pode ser exigido por alguns serviços onde o proxy necessitar observar todas mensagens de um diálogo. Contudo, Ele retarda e prejudica o processamento e escalabilidade e assim proxy's só deve pôr Record-route se for necessário a um serviço particular.
O processo Record-Route é projetado para funcionar em qualquer requisição SIP que inicia um diálogo. O INVITE é a única de tais requisições nessa especificação, mas extensões ao protocolo PODEM definir outras.
5. Adicionando Campos-Cabeçalhos Adicionais
O proxy PODE adicionar quaisquer outros campos-cabeçalhos apropriados à cópia nesse ponto.
6. Pós-processar a informação de roteamento
Um proxy PODE ter uma política local obriga que uma requisição visite um conjunto específico de proxy's antes de ser entregue ao destino. Um proxy PRECISA garantir que todos esses proxy's sejam roteadores menos rígidos (loose). Geralmente, isso só pode ser conhecido precisamente se os proxy's estiverem dentro do mesmo domínio administrativo. Esse conjunto de proxy's é representado por um conjunto de URI's (cada qual contém o parâmetro lr). Esse conjunto PRECISA ser colocado no campo-cabeçalho Route da cópia à frente de quaisquer valores existentes, se estiver presente. Se o campo-cabeçalho Route estiver ausente, ele PRECISA ser adicionado, contendo essa lista de URI's.
Se o proxy tiver uma política local que obriga que a requisição visite um proxy específico, uma alternativa para colocar um valor Route no campo-cabeçalho Route é ignorar a lógica de encaminhamento do item 10 abaixo, e ao invés disso, enviar a requisição ao endereço porta, e transporte a esse proxy específico. Se a requisição tiver um campo-cabeçalho Route, essa alternativa NÃO PODE ser usada a menos que seja sabido que o proxy next-hop seja um roteador loose (menos rígido). Caso contrário, essa abordagem PODE ser usada, mas o mecanismo para inserção do Route acima é preferido pela sua robustez, flexibilidade, generalidade e consistência de operação. Além disso, se o Request-URI contiver um URI do SIPS, o TLS PRECISA ser usado para se comunicar com esse proxy.
Se a cópia tiver um campo-cabeçalho Route, o proxy PRECISA inspeccionar a URI no seu primeiro valor. Se esse URI não contiver um parâmetro lr, o proxy PRECISA modificar a cópia da seguinte forma:
Rosenberg, et. al. Standards Track [Página 103]
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