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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


16.11 Proxy Sem Estado

Quando atuando como Proxy statelessly, um Proxy é um simples encaminhador de mensagem. Muito do processamento executado quando agindo Proxy statelessly é a mesma que quando se comportando como Proxy stateful. As diferenças são detalhadas aqui.

Um proxy stateless não tem qualquer noção de uma transação, ou de contexto de resposta usado para descrever o comportamento do Proxy stateful. Em vez disso, o Proxy stateless pega mensagens, tanto requisições quanto respostas, diretamente da camada de transporte (Veja a seção 18). Como resultado, proxy's stateless não transmitem mensagens por conta própria. Ele, contudo, encaminham todas as retransmissões que eles recebem (ele não possuem a capacidade para distinguir uma retransmissão de uma mensagem original). Além do mais, ao tratar uma requisição de modo stateless, É PROIBIDO a um elemento gerar suas próprias respostas 100 (Trying) ou qualquer outra resposta provisional.

Um proxy stateless PRECISA validar uma requisição conforme descrito na Seção 16.3.

Um proxy stateless PRECISA seguir os passos de processamento de requisição descrito na Seção 16.4 e 16.5 com a seguinte exceção:

o Um proxy stateless PRECISA escolher um e somente um destino do conjunto destino. Essa escolha PRECISA somente depender dos campos na mensagem e de propriedades invariante de tempo do servidor. Em particular, uma requisição retransmitida PRECISA ser encaminhada a algum destino a cada vez que ele é processado. Além disso, requisições CANCEL e ACK não-Routed PRECISAM gerar a mesma escolha que de seus INVITE's associados.

Um proxy stateless PRECISA seguir os passos de processamento de requisição descritos na Seção 16.6 com as seguintes exceções:

o A exigência por branch ID's únicos através do espaço e do tempo se aplica a proxy's stateless também. Contudo, um Proxy stateless não pode simplesmente usar um gerador de número randômico para computar o primeiro componente do branch ID, como descrito na Seção 16.6 item 8. Isso é porque retransmissões de uma requisição precisa ter o mesmo valor, e um Proxy stateless não pode dizer um retransmissão da requisição original. Portanto, o componente do parâmetro branch que o torna único PRECISA ser o mesmo toda vez que uma requisição retransmitida for encaminhada. Assim para um Proxy stateless, o parâmetro branch PRECISA ser computado como uma função combinatória de parâmetros da mensagem que são invariante na retransmissão.



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

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.