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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


O proxy sem estado PODE usar qualquer técnica que gosta de garantir a unicidade de seus branch ID's através de transações. No entanto, o procedimento seguinte É RECOMENDADO. O proxy examina o branch ID no campo-cabeçalho Via mais alto da requisição recebida. Se ele começa com o cookie mágico, o primeiro componente do branch ID da requisição sainte é computado como um hash do branch ID recebido. Caso contrário, o primeiro componente do branch ID é computado como um hash do Via mais alto, o tag no campo-cabeçalho To, o tag no campo-cabeçalho From, o campo-cabeçalho Call-ID, o número CSeq (mas não do método), e o Request-URI da requisição recebida. Um desses campos sempre vai variar entre duas transações diferentes.

o Todas as outras transformações de mensagem especificadas na Seção 16.6 PRECISA resultar na mesma transformação de uma requisição retransmitida. Em particular, se o proxy insere um valor Record-Route ou empurra URI's no campo-cabeçalho Route, ele PRECISA colocar os mesmos valores em retransmissões da requisição. Quanto ao parâmetro branch do Via, isso implica que as transformações PRECISAM ser baseadas na configuração invariante de tempo ou propriedades invariante de retransmissão da requisição.

o Um proxy sem estado determina onde encaminhar a requisição, conforme descrito para proxy's stateful na Seção 16.6, Item 10. A requisição é enviada diretamente à camada de transporte, em vez de uma operação cliente.

Uma vez que um proxy sem estado precisa encaminhar requisições retransmitidas ao mesmo destino e adicionar parâmetros branch idênticos a cada um deles, ele só pode usar informações da mensagem em si e dados de configuração invariante de tempo para esses cálculos. Se o estado de configuração não for invariante no tempo (por exemplo, se uma tabela de roteamento é atualizado) quaisquer requisições que poderiam ser afetadas pela mudança não podem ser encaminhadas de modo sem estado durante um intervalo igual à janela de timeout da transação antes ou após a mudança. O método de processar requisições afetadas nesse intervalo é uma decisão de implementação. Uma solução comum é encaminhá-las na forma de transação stateful.

Proxy's sem estado NÃO PODEM executar processamento especial para requisições CANCEL. Elas são processados ​​pelas regras acima como quaisquer outras requisições. Em particular, um proxy sem estado aplica o mesmo processamento de campo-cabeçalho Route às requisições CANCEL que se aplica a qualquer outra requisição.



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

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.