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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Se a resposta a uma requisição dentro de um diálogo é uma 481 (Call/Transaction Does Not Exist) ou uma 408 (Request Timeout), o UAC DEVE encerrar o diálogo. Um UAC também DEVE encerrar um diálogo se nenhuma resposta for recebida para a requisição (a transação cliente informaria ao TU sobre o timeout).

Para diálogos iniciados com INVITE, terminar o diálogo consiste em enviar uma requisição BYE.


12.2.2 Comportamento do UAS

Requisições enviadas dentro de um diálogo, como quaisquer outras requisições, são atômicas. Se uma requisição particular for aceita pelo UAS, todas mudanças de estado associadas a ela são executadas. Se a requisição for rejeitada, nenhuma mudança de estado é executada.

Note que algumas requisições, como INVITE's, afetam diversas partes do estado.

O UAS receberá a requisição da camada de transação. Se a requisição tem uma tag no campo-cabeçalho To, o núcleo UAS computa o identificador do diálogo correspondente à requisição e o compara com diálogos existentes. Se houver uma correspondência, essa é uma requisição em meio-a-um-diálogo. Nesse caso, o UAS primeiro aplica as mesmas regras de processamento para requisições fora de um diálogo, discutido na Seção 8.2.

Se a requisição tem uma tag no campo-cabeçalho To, mas o identificador de diálogo não bate com nenhum diálogo existente, o UAS pode ter quebrado e reiniciado, ou ele pode ter recebido uma requisição a um UAS (possivelmente falhado) diferente (os UAS's podem construir as tags do campo To de sorte que um UAS pode identificar que a tag era para um UAS ao qual ele está fornecendo recuperação). Outra possibilidade é que a requisição entrante foi simplesmente mal-roteada. Com base na tag do campo To, o UAS PODE tanto aceitar quanto rejeitar a requisição. Aceitando a requisição com tags do campo To aceitáveis fornece robustez, de modo que diálogos podem persistir mesmo com falhas. UA's que desejam suportar essa capacidade precisa levar em consideração algumas questões como a escolha de números de seqüência CSeq monotonicamente crescente mesmo entre reboots, reconstrução do conjunto de rotas, e aceitar timestamps do RTP fora-da-faixa e números de seqüência.

Se o UAS deseja rejeitar a requisição, porque ele não deseja recriar o diálogo, ele PRECISA responder à requisição com um código status 481 (Call/Transaction Does Not Exist) e passar isso a transação servidor.





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

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.