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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


informações desse Request-URI através do roteador estrito (ela será retornado ao Request-URI quando a requisição atingir um loose-router).

Um UAC DEVE incluir um campo-cabeçalho Contact em quaisquer requisições para atualização do alvo dentro de um diálogo, e a não ser que haja necessidade de mudá-la, o URI DEVE ser o mesmo que foi usado em requisições anteriores dentro do diálogo. Se o flag "secure" for true, esse URI PRECISA ser um URI do SIPS. Como discutido na Seção 12.2.2, um campo-cabeçalho Contact em uma requisição de atualização de alvo atualiza o URI do alvo remoto. Isso permite a um UA fornecer um novo endereço de contato, se o seu endereço mudar durante o diálogo.

No entanto, requisições que não são requisições para atualizar alvo não afetam o URI do destino remoto do diálogo.

O resto da requisição é formado conforme descrito na Seção 8.1.1.

Uma vez que a requisição seja construída, o endereço do servidor é computado e a requisição é enviada, usando os mesmos procedimentos para requisições fora de um diálogo (Seção 8.1.2).

Os procedimentos na Seção 8.1.2 resultará normalmente na requisição sendo enviada ao endereço indicado pelo valor do campo-cabeçalho Route mais alto ou o Request-URI se nenhum campo-cabeçalho Route estiver presente. Sujeito a certas restrições, eles permitem à requisição ser enviada a um endereço alternativo (como um proxy sainte padrão não representado no conjunto de rotas).


12.2.1.2 Processando as Respostas

O UAC irá receber respostas à requisição da camada de transação. Se a transação cliente retorna um timeout, isso é tratado como uma resposta 408 (Request Timeout).

O comportamento de um UAC que recebe uma resposta 3xx a uma requisição enviada dentro de um diálogo é o mesmo que se a requisição tivesse sido enviada fora de um diálogo. Esse comportamento é descrito na Seção 8.1.3.4.

Note, no entanto, que quando o UAC tenta localizações alternativas, ele ainda usa o conjunto de rotas do diálogo para montar o cabeçalho Route da requisição.

Quando um UAC recebe uma resposta 2xx a uma requisição para atualizar destino, ele PRECISA substituir o URI do alvo remoto do diálogo pelo URI do campo-cabeçalho Contact nessa resposta, se estiver presente.



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

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.