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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


16.7 Processando Resposta

Quando uma resposta for recebida por um elemento, ele primeiro tenta localizar uma transação cliente (Seção 17.1.3) que confere com a resposta. Se nenhuma for encontrada, o elemento PRECISA processar a resposta (mesmo que ela seja uma resposta informacional) como um proxy stateless (descrita abaixo). Se uma conferir for encontrada, a resposta será entregue a transação cliente.

Encaminhar respostas em que uma transação cliente (ou, mais geralmente qualquer reconhecimento tendo sido enviado a uma requisição associada) não foi encontrada melhora a robustez. Em particular, isso garante que respostas 2xx "atrasadas" para requisições INVITE sejam encaminhadas adequadamente.

Como transações clientes passam respostas à camada de proxy, o processamento seguinte PRECISA ocorrer:

1.  Busca o contexto apropriado de resposta

2.  Atualiza o timer C para respostas provisionais

3.  Remove o Via mais alto

4.  Adiciona a resposta ao contexto de resposta

5.  Verifica pra ver se essa resposta deve ser encaminhada imediatamente

6.  Quando necessário, escolhe a melhor resposta final no contexto de resposta

Se nenhuma resposta final foi transmitida após cada transação cliente associada ao contexto de resposta tenha terminado, o proxy precisa escolher e encaminhar a "melhor" resposta dentre aquelas que ele viu até aqui.

O processamento seguinte PRECISA ser executado sobre cada resposta que é encaminhada. É provável que mais de uma resposta a cada requisição seja enviada: pelo menos a cada uma resposta provisória e final.

7.  Agregar valores nos campos-cabeçalhos Authorization se necessário

8.  Opcionalmente re-escreve valores nos campos-cabeçalhos Record-Route

9.  Encaminha a resposta

10. Gera quaisquer requisições CANCEL necessárias






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

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.