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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Permitindo o proxy ressetar o timer permite que o proxy estender a vida útil da transação dinamicamente baseado em condições atuais (como utilização), quando o timer disparar.


16.9 Tratando Erros de Transporte

Se a camada de transporte notificar a um proxy sobre um erro quando ele tenta encaminhar uma requisição (veja Seção 18.4), o Proxy PRECISA se comportar como se a requisição encaminhada recebeu uma resposta 503 (Serviço Indisponível).

Se o proxy é notificado sobre um erro quando encaminha uma resposta, ele descarta a resposta. O proxy NÃO DEVE cancelar qualquer transação cliente pendente associada com esse contexto de resposta devido a essa notificação.

Se um proxy cancelar sua transações clientes pendentes, um único cliente mal-comportado ou malicioso pode fazer que todas as transações falhem por meio do seu campo-cabeçalho Via.


16.10 Processando CANCEL

Um proxy stateful PODE gerar uma CANCEL para qualquer outra requisição que ele tenha gerado em algum instante (sujeito a receber uma resposta provisional essa requisição como descrito em seção 9.1). Um proxy PRECISA cancelar alguma transação cliente pendente associada a um contexto resposta quando ele recebe uma requisição CANCEL que confere.

Um proxy stateful PODE gerar requisições CANCEL para transações cliente INVITE's pendente baseadas no periodo especificado no campo-cabeçalho Expires do INVITE em curso. Contudo, isso é geralmente desnecessario já que as pontas remotas envolvidas cuidarão de sinalizar a ponta da transação.

Ao tempo que uma requisição CANCEL é tratada em um proxy stateful por sua própria transação-servidor, um novo contexto resposta não é criado por ele. Em vez disso, a camada proxy busca seus contextos respostas existentes pela transação-servidor que trata a requisição associada com essa CANCEL. Se um contexto resposta que bate for encontrado, o elemento PRECISA imediatamente retornar uma resposta 200 (OK) à requisição CANCEL. Nesse caso, o elemento está atuando como um servidor agente-usuário conforme definido na Seção 8.2. Além disso, o elemento PRECISA gerar requisições CANCEL para todas as transações clientes pendentes no contexto como descrito na Seção 16.7 passo 10.

Se um contexto resposta não for encontrado, o elemento não tem qualquer conhecimento da requisição ao qual aplicar a CANCEL. Ele PRECISA encaminhar a requisição CANCEL sem manter estado (ele pode ter encaminhado sem estado a requisição associada anteriormente).




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

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.