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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Cada um dos passos acima são detalhados a seguir:

1.  Busca de Contexto

O proxy localiza o "contexto resposta" que ele criou antes de encaminhar a requisição original usando a chave descrita na Seção 16.6. As etapas de processamento restantes ocorrem nesse contexto.

2.  Atualiza timer C para respostas provisionais 

Para uma transação INVITE, se a resposta for uma resposta provisória com códigos de status de 101 a 199 inclusive (ou seja, todas menos a 100), o proxy PRECISA ressetar o timer C para essa transação cliente. O timer PODE ser ressetado com um valor diferente, mas esse valor PRECISA ser maior do que 3 minutos.

3.  Via

O proxy remove o valor do campo-cabeçalho Via mais alto da resposta.

Se nenhum valor do campo-cabeçalho Via permanecer na resposta, a resposta foi destinada a esse elemento e NÃO PODE ser encaminhada. O restante do processamento descrito nessa seção não é executada nessa mensagem, as regras de processamento UAC descritas na Seção 8.1.3 são seguidas vez (processamento da camada de transporte já ocorreu).

Isso acontecerá, por exemplo, quando o elemento gerar requisições CANCEL como descrito na Seção 10.

4.  Adiciona Resposta ao Contexto

Respostas finais recebidas são armazenadas no contexto de resposta até que uma resposta final seja gerada na transação servidor associada a esse contexto. A resposta pode ser uma candidata à melhor resposta final a ser retornada nessa transação servidor. Informação dessa resposta pode ser necessária para formar a melhor resposta, mesmo que essa resposta não seja escolhida.

Se o proxy escolher fazer recursão de todos contatos em uma resposta 3xx, adicionando-os ao conjunto destino, ele PRECISA removê-los da resposta antes de adicionar a resposta ao contexto resposta. Contudo, um proxy NÃO DEVE fazer recursão de um URI não-SIPS se o Request-URI da requisição original era um URI do SIPS. Se 







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

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.