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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Em todos os outros aspectos, requisições enviadas após a recepção de uma resposta de redirecionamento DEVE reusar os campos-cabeçalhos e corpo da requisição original.

Em alguns casos, valores do campo-cabeçalho Contact podem ser colocados na cache no UAC temporária ou permanentemente dependendo do código status recebido e a presença de um intervalo de expiração; ver Seções 21.3.2 e 21.3.3.


8.1.3.5 Processando Respostas 4xx

Alguns códigos de resposta 4xx exigem processamento específico do UA, independente do método.

Se uma resposta 401 (Unauthorized) ou 407 (Proxy Authentication Required) for recebida, o UAC DEVE seguir os procedimentos de autorização da Seção 22.2 e da Seção 22.3 para repetir a requisição com credenciais.

Se uma resposta 413 (Request Entity Too Large) for recebida (Seção 21.4.11), a requisição contém um corpo que é maior do que o UAS está disposto a aceitar. Se possível, o UAC DEVE repetir a requisição, ou omitindo o corpo ou usando um corpo de tamanho menor.

Se uma resposta 415 (Unsupported Media Type) for recebida (Seção 21.4.13), a requisição contém tipos de mídia não suportados pelo UAS. O UAC DEVE repetir o envio da requisição, dessa vez usando apenas o conteúdo com os tipos listados no campo-cabeçalho Accept na resposta, com codificações listadas no campo-cabeçalho Accept-Encoding na resposta, e com línguas listadas no campo-cabeçalho Accept-Language na resposta.

Se uma resposta 416 (Unsupported URI Scheme) for recebida (Seção 21.4.14), o Request-URI usou um esquema URI que não é suportado pelo servidor. O cliente DEVE repetir a requisição, dessa vez, usando uma URI do SIP.

Se uma resposta 420 (Bad Extension) for recebida (Seção 21.4.15), a requisição contém um campo-cabeçalho Require ou Proxy-Require listando uma tag opção para um recurso não suportado por um proxy ou UAS. O UAC DEVE repetir a requisição, dessa vez omitindo qualquer extensões listadas no campo-cabeçalho Unsupported na resposta.

Em todos os casos acima, a requisição é repetida criando uma nova requisição com as devidas modificações. Essa nova requisição constitui uma nova transação e DEVE ter o mesmo valor de Call-ID, To e From da requisição anterior, mas o CSeq deve conter um novo número de seqüência que é algo maior do que o anterior.





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

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.