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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


código de erro apropriado. Quando respondendo diretamente a uma requisição, o elemento está desempenhando o papel de um UAS e PRECISA se comportar como descrito na Seção 8.2.

Um proxy pode operar tanto no modo stateful quanto stateless para cada nova requisição. Quando no modo stateless, um proxy atua como um simples elemento de encaminhamento. Ele encaminha cada requisição downstream a um único elemento determinado tomando uma decisão para onde apontar e rotear baseado na requisição. Ele simplesmente encaminha cada resposta que ele recebe de upstream. Um proxy stateless descarta informação sobre uma mensagem uma vez que a mensagem tenha sido encaminhada. Um proxy stateful se lembra da informação (especificamente, o estado da transação) sobre cada requisição entrante e todas requisições que ele envia como resultado do processamento da requisição entrante. Ele usa essas informações para afetar o processamento de mensagens futuras associadas a essa requisição. Um proxy stateful PODE escolher "fork-ar" uma requisição, roteando-a para múltiplos destinos. Qualquer requisição que é encaminhada para mais de um local PRECISA ser tratada como stateful.

Em algumas circunstâncias, um proxy PODE encaminhar requisições usando transportes stateful (por exemplo, TCP) sem transação ser stateful. Por exemplo, um proxy PODE encaminhar uma requisição a partir de uma conexão TCP a outra transação sendo stateless tão logo ele coloque informação suficiente na mensagem para ser capaz de encaminhar a resposta adiante na mesma conexão que a requisição chegou. Requisições encaminhadas entre diferentes tipos de transportes onde TU do proxy precisa ter um papel ativo no sentido de garantir uma entrega confiável a um dos transportes PPRECISA ser encaminhada em transação sendo stateful.

Um proxy stateful PODE transitar para operação stateless a qualquer momento durante o processamento da requisição, contanto que ele não faça nada que, do contrário, lhe impeça de estar stateless inicialmente (bifurcando, por exemplo, ou gerando uma resposta 100). Ao executar essa transição, todo estado é descartado simplesmente. O proxy NÃO DEVE iniciar uma requisição CANCEL.

Muito do processamento envolvido quando agindo no modo stateless ou no stateful para uma requisição é idêntico. As próximas vários subseções são escritas do ponto de vista de um proxy stateful. A última seção chama atenção àqueles lugares onde um proxy stateless se comporta de forma diferente.


16.2 Proxy Stateful

Quando operando no do stateful, um proxy é puramente um mecanismo SIP de processamento de transações. Seu comportamento é modelado aqui em termos de transações servidor e cliente definidos na Seção 17. Um proxy stateful tem uma transação de servidor associada com uma ou mais transações clientes por um componente de processamento proxy da camada superior (ver figura 3), conhecida como um núcleo proxy. Uma requisição entrante é processada por uma transação servidor.



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

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.