RFC 3261 Português Página 51

RFC 3261 SIP: Session Initiation Protocol Junho 2002

que poderiam retardar ou parar completamente o processamento de chamadas em um UAS, efetivamente criando uma condição de negação de serviço; para obter mais informações consulte a Seção 26.1.5.

Os comportamentos mais importantes de um UAS stateless são os seguintes:

o Um UAS stateless NÃO PODE enviar respostas (1xx) provisional.

o Um UAS stateless NÃO PODE retransmitir respostas.

o Um UAS stateless PRECISA ignorar requisições ACK.

o Um UAS stateless PRECISA ignorar requisições CANCEL.

o tags do cabeçalho To PRECISAM ser geradas nas respostas de uma maneira stateless - de uma maneira que irá gerar o mesmo tag para a mesma requisição de forma consistente. Para obter informações sobre a construção de tag ver a Seção 19.3.

Em todos os outros aspectos, um UAS stateless se comporta da mesma maneira que um UAS stateful. Um UAS pode operar em um modo stateful ou stateless para cada nova requisição.

8.3 Servidores de Redirecionamento

Em algumas arquiteturas, pode ser desejável reduzir a carga de processamento em servidores proxy que são responsáveis pelo roteamento de requisições, e melhorar a robustez do caminho de sinalização, baseando-se no redirecionamento.

O redirecionamento permite aos servidores colocar informação de roteamento de uma requisição de volta em uma resposta ao cliente, assim saindo-se do loop de novas mensagens para essa transação e ainda ajudando a localizar o destino da requisição. Quando o orinador da requisição recebe o redirect, ele enviará uma nova requisição baseado no(s) URI(s) que recebeu. Propagando URI's do núcleo da rede para suas bordas, o redirect possibilita escalabilidade considerável de rede.

Um servidor redirect é logicamente constituído de uma camada de transação no servidor e de um usuário de transação que tem acesso a um serviço de localização de algum tipo (ver Seção 10 para mais informações sobre os registradores e os serviços de localização). Esse serviço de localização é efetivamente um base de dados contendo mapeamentos entre um URI simples e um conjunto de uma ou mais localizações alternativas no qual o destino desse URI pode ser encontrado.

Um servidor de redirecionamento não faz quaisquer requisições SIP por sua própria vontade. Após receber uma requisição diferente de CANCEL, o servidor ou recusa a requisição, ou reúne a lista de localizações alternativas do serviço

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

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.