RFC 3261 Português Página 52

RFC 3261 SIP: Session Initiation Protocol Junho 2002

local e retorna uma resposta final classe 3xx. Para requisições CANCEL bem-formadas, ele DEVE retornar uma resposta 2xx. Essa resposta finaliza a transação SIP. O servidor redirect mantém o estado da transação por uma transação SIP completa. É da responsabilidade dos clientes detectar loops de encaminhamento entre os servidores de redirecionamento.

Quando um servidor redirect retorna uma resposta 3xx a uma requisição, ele preenche a lista de (um ou mais) localizações alternativas no campo-cabeçalho Contact. Um parâmetro "expires" adicionado aos valores do campo-cabeçalho Contact também pode ser fornecido para indicar a vida útil dos dados de Contact.

O campo-cabeçalho Contact contém URI's que fornece as novas localizações ou nomes de usuário a tentar, ou pode simplesmente especificar parâmetros adicionais de transporte. Uma resposta 301 (Moved Permanently) ou 302 (Moved Temporarily) pode também fornecer a mesma localização e nome de usuário que foi destinado pela requisição inicial, mas especificar parâmetros adicionais de transporte, tais como um servidor diferente ou endereço multicast a tentar, ou uma mudança do transporte SIP de UDP para TCP ou vice-versa.

No entanto, os servidores redirect NÃO PODEM redirecionar uma requisição para uma URI igual àquela do Request-URI, ao contrário, desde que o URI não aponta pra si mesma, o servidor PODE proxy-ar a requisição ao destino no URI, ou PODE rejeitá-la com uma 404.

Se um cliente estiver usando um proxy sainte, e esse proxy realmente redireciona requisições, um potencial surge para loops de redirecionamento infinito.

Note que o valor de um campo-cabeçalho Contact também PODE se referir a um recurso diferente do que aquele originalmente chamado. Por exemplo, uma chamada SIP conectada ao gateway PSTN pode precisar entregar um anúncio especial de informação, como "O número que vocâ discou foi alterado".

Um campo-cabeçalho Contact de resposta pode conter qualquer URI apropriado indicando onde a parte chamada pode ser alcançada, não se limitando ao URI's do SIP. Por exemplo, ele poderia conter URI's para telefones, fax, ou irc (se elas fossem definidas) ou um mailto: URL (RFC 2368 [32]). A Seção 26.4.4 discute as implicações e limitações para redirecionar um URI do SIPS para um URI não-SIPS.

O valor do parâmetro "expires" de um campo-cabeçalho Contact indica quanto tempo o URI é válida. O valor do parâmetro é um número indicando segundos. Se esse parâmetro não for fornecido, o valor do campo-cabeçalho Expires determina quanto tempo o URI é válida. Valores malformados DEVEM ser tratados como equivalente a 3600.

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

Página Anterior

Tabela de Conteúdo

Página Seguinte



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.