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

RFC 3261                      SIP: Session Initiation Protocol                     Junho 2002



teria de encaminhar a 2xx. O resultado foi que o UAC poderia receber uma resposta 

6xx seguida por uma resposta 2xx, que nunca deveria ser permitido de acontecer. 

Sob as novas regras, ao receber uma 6xx, um proxy lançará uma requisição CANCEL, a 

qual geralmente resultará em respostas 487 a partir de todas transações clientes 

pendentes e, então, nesse ponto a 6xx é encaminhada a upstream.



Após uma resposta final ter sido enviada na transação servidor, as respostas 

seguintes PRECISAM ser encaminhadas imediatamente:



-  Qualquer resposta 2xx a uma requisição INVITE



Um proxy stateful NÃO PODE encaminhar imediatamente quaisquer outras respostas. Em 

particular, um proxy stateful NÃO PODE encaminhar qualquer resposta 100 (Trying). 

Aquelas respostas que são candidatas para encaminhamento depois como a "melhor" 

resposta terem sido recolhidas como descrito na etapa "Adicionar Resposta ao 

Contexto".



Qualquer resposta escolhida para encaminhamento imediato PRECISAM ser processadas 

como descrito nos passos "Agregar Valores no Campo-Cabeçalho Authorization" até 

"Record-Route".



Essa etapa, combinada com a próxima, assegura que um proxy stateful irá encaminhar 

exatamente uma resposta final a uma requisição não-INVITE, e não exatamente uma 

resposta não-2xx e nem uma ou mais respostas 2xx a uma requisição INVITE.



6.  Escolhendo a melhor resposta



Um proxy stateful PRECISA enviar uma resposta final a uma transação servidor do 

contexto resposta, se nenhuma resposta final foi imediatamente encaminhada pelas 

regras acima e todas transações clientes nesse contexto resposta tenham sido 

terminadas.



O proxy stateful PRECISA escolher a "melhor" resposta final entre as recebidas e 

armazenadas no contexto resposta.



Se não houver nenhuma resposta final no contexto, o proxy PRECISA enviar uma 

resposta 408 (Request Timeout) à transação servidor.



Do contrário, o proxy PRECISA encaminhar uma resposta a partir das respostas 

armazenadas no contexto resposta. Ele PRECISA escolher das respostas classe 6xx se 

existir no contexto. Se não houver respostas classe 6xx presentes, o proxy DEVE 

escolher entre a classe de resposta mais baixa armazenada no contexto resposta. O 

proxy PODE escolher qualquer resposta dentro dessa classe escolhida. O proxy DEVE 















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

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.