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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


8.1.3.3 Via's

Se mais de um valor do campo-cabeçalho Via estiver presente em uma resposta, o UAC DEVE descartar a mensagem.

A presença de valores do campo-cabeçalho Via adicionais que precedem o orginador da requisição sugere que a mensagem foi mal roteada ou possivelmente corrompida.


8.1.3.4 Processando Respostas 3xx

Quando da recepção de uma resposta de redirecionamento (por exemplo, uma resposta com código de status 301), os clientes DEVEM usar o(s) URI(s) no campo-cabeçalho Contact para formular uma ou mais requisições novas baseadas na requisição redirecionada. Este processo é similar àquele de um recursão de proxy na resposta classe 3xx, conforme detalhado nas Seções 16.5 e 16.6. Um cliente começa com um destino inicial definido contendo exatamente um URI, o Request-URI da requisição original. Se um cliente quiser formular novas requisições baseadas em uma resposta classe 3xx a essa requisição, ele coloca os URI(s) a tentar no destino definido. Sujeito às restrições nessa especificação, um cliente pode escolher quais URI's de Contact colocar no destino definido. Da mesma forma que a recursão de proxy, um cliente que processa respostas classe 3xx NÃO PODE adicionar qualquer URI fornecido ao destino definido mais de uma vez. Se a requisição original tinha um URI do SIPS no Request-URI, o cliente PODE escolher fazer recursão de um URI não-SIPS, mas DEVE informar ao usuário redirecionado do URI não seguro.

Qualquer nova requisição pode receber respostas 3xx que auto contém o URI original como um contato. Duas locais podem ser configurados para se auto redirecionar. Colocar qualquer URI dada no destino definido apenas uma vez impede loops infinitos de redirecionamento.

Como o destino definido cresce, o cliente PODE gerar novas requisições com as URI's em qualquer ordem. Um mecanismo comum deve ordenar o conjunto pelo valor do parâmetro "q" no campo-cabeçalho Contact. Requisições com URI's PODEM ser geradas em série ou em paralelo. Uma abordagem é processar grupos de q-valores diminuindo serialmente e processar as URI's em cada grupo de q-valor em paralelo. Outra é executar somente o processamento serial em ordem decrescente de q-valor, arbitrariamente escolhendo entre contatos de igual q-valor.

Se quando contactar um endereço na lista resultar em uma falha, como definido no parágrafo seguinte, o elemento se move ao endereço seguinte na lista, até a lista ficar esgotada. Se a lista se esgotar, então a requisição falhou.





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

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.