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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


tentar enviar a requisição ao local indicado no primeiro valor do campo-cabeçalho Route ao invés de adotar a política de enviar todas mensagens ao proxy sainte.

Isso garante que proxy's saintes que não adicionam valores de campo-cabeçalho Record-Route descartarão o caminho das requisições subsequentes. Isso permite às pontas remotas que não consegue resolver o primeiro URI de Route delegar essa tarefa a um proxy sainte.

O UAC DEVE seguir os procedimentos definidos em [4] para elementos stateful, tentando cada endereço até um servidor ser contatado. Cada tentativa constitui uma nova transação e, portanto, cada um carrega um valor diferente do campo-cabeçalho Via mais alto com um novo parâmetro branch. Além disso, o valor de transporte no campo-cabeçalho Via é definido para qualquer que seja o transporte que seja determinada para o servidor destino.


8.1.3 Processando Respostas

Respostas são primeiro processadas pela camada de transporte e então passadas até a camada de transação. A camada de transação executa seu processamento e, então, passa a resposta até o TU. A maioria do processamento de resposta no TU é específico de método. No entanto, existem alguns comportamentos gerais independentes do método.


8.1.3.1 Erros da Camada de Transação

Em alguns casos, a resposta retornada pela camada de transação não será uma mensagem SIP, mas sim um erro da camada de transação. Quando um erro de timeout é recebido da camada de transação, ele PRECISA ser tratado como se um código status 408 (Request Timeout) tivesse sido recebido. Se um erro fatal de transporte for relatado pela camada de transporte (em geral, devido a erros fatais ICMP no UDP ou falhas de conexão TCP), a condição PRECISA ser tratada como um código status 503 (Service Unavailable).


8.1.3.2 Respostas Não Reconhecidas

Um UAC PRECISA tratar qualquer resposta final que ele não reconheça como sendo equivalente ao código de resposta x00 dessa classe, e PRECISA ser capaz de processar o código de resposta x00 para todas as classes. Por exemplo, se um UAC recebe um código de resposta de 431 não reconhecido, ele pode seguramente assumir que houve algo errado com a sua requisição e tratar a resposta como se ele tivesse recebido um código resposta 400 (Bad Request). Um UAC PRECISA tratar qualquer resposta provisória diferente de 100 que ele não reconhece como 183 (Session Progress). Um UAC PRECISA ser capaz de processar respostas 100 e 183.





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

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.