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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Com outras respostas 4xx, incluindo aquelas que ainda estão a ser definida, uma nova tentativa pode ou não ser possível dependendo do método e o caso de uso.


8.2 Comportamento do UAS

Quando uma requisição fora de um diálogo for processada por um UAS, há um conjunto de regras de processamento que são seguidos, independente do método. A Seção 12 dá diretrizes de como um UAS pode dizer se uma requisição está dentro ou fora de um diálogo.

Note que o processamento da requisição é atômica. Se a requisição for aceita, todas as mudanças de estado associado a ela PRECISAM ser executadas. Se ela for rejeitada, todas as mudanças de estado NÃO PODEM ser executadas.

UAS's DEVEM tratar as requisições na ordem dos passos que se seguem nessa seção (ou seja, começando com autenticação, depois, inspecionando o método, os campos-cabeçalhos, e assim por diante por todo o restante dessa seção).


8.2.1 Inspeção de Método

Uma vez que uma requisição seja autenticada (ou a autenticação seja ignorada), o UAS PRECISA inspecionar o método da requisição. Se o UAS reconhecer, mas não suportar o método de uma requisição, ele PRECISA gerar uma resposta 405 (Method Not Allowed). Procedimentos para gerar respostas são descritos na Seção 8.2.6. O UAS também PRECISA adicionar um campo-cabeçalho Allow à resposta 405 (Method Not Allowed). O campo-cabeçalho Allow PRECISA listar o conjunto de métodos suportados pelo UAS gerando a mensagem. O campo-cabeçalho Allow é apresentado na Seção 20.5.

Se o método for algum suportado pelo servidor, o processamento continua.


8.2.2 Inspeção de Cabeçalho

Se um UAS não compreender um campo-cabeçalho de uma requisição (ou seja, o campo-cabeçalho não for definido nessa especificação ou em qualquer extensão suportada), o servidor PRECISA ignorar esse campo-cabeçalho e continuar processando a mensagem. Um UAS DEVE ignorar quaisquer campos-cabeçalhos malformados que não sejam necessários ao processamento de requisições.


8.2.2.1 To e Request-URI

O campo-cabeçalho To identifica o destino original da requisição designado pelo usuário identificado no campo From. O destino original pode ou não ser o UAS que processa a requisição, devido ao encaminhamento de chamada ou outras operações de proxy. Um UAS PODE aplicar qualquer política que desejar para determinar se aceita requisições quando o campo-cabeçalho To 



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

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.