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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Ao contrário de uma transação INVITE, a transação não-INVITE não tem tratamento especial à resposta 2xx. O resultado é que apenas uma resposta simples 2xx a um não-INVITE é sempre entregue a um UAC.


17.1.2.2 Descrição Formal

A máquina de estado para a transação não-INVITE cliente é mostrado na Figura 6. É muito semelhante à máquina estado para INVITE.

O estado "Trying" é introduzido quando o TU inicia uma nova transação cliente com uma requisição. Ao entrar nesse estado, a transação cliente DEVE definir timer F para disparar em 64*T1 segundos. A requisição PRECISA ser passada à camada de transporte para transmissão. Se um transporte não confiável estiver em uso, a transação cliente PRECISA definir timer E para disparar em T1 segundos. Se timer E disparar enquanto estiver ainda nesse estado, mas esse tempo com um valor MIN(2*T1, T2). Quando o timer disparar novamente, ele é ressetado com um MIN(4*T1, T2). Esse processo continua de sorte que as retransmissões ocorram com um intervalo de crescimento exponencial que atinge em T2. O valor padrão de T2 é 4s, e ele representa a quantidade de tempo que uma transação não-INVITE servidor vai demorar para responder a uma requisição, se ele não responder imediatamente. Para os valores padrão de T1 e T2, isso resulta em intervalos de 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc..

Se Timer F dispara enquanto a transação cliente ainda estiver no estado "Trying", a transação cliente DEVE informar ao TU sobre o timeout, e então ele DEVE entrar no estado "Terminted". Se uma resposta provisória for recebida enquanto no estado "Trying", a resposta PRECISA ser passada ao TU e, em seguida, a transação cliente DEVE passar ao estado "Proceeding". Se uma resposta final (códigos de status 200-699) for recebida enquanto no estado "Trying", a resposta PRECISA ser passada ao TU, e a transação cliente PRECISA transitar para o estado "Completed".

Se Timer E disparar enquanto no estado "Proceeding", a requisição PRECISA ser passada à camada de transporte para retransmissão, e Timer E PRECISA ser ressetado com um valor de T2 segundos. Se timer F disparar enquanto no estado "Proceeding", o TU PRECISA ser informado de um timeout, e a transação cliente PRECISA transitar ao estado encerrado. Se uma resposta final (códigos de status 200-699) for recebido enquanto no estado "Proceeding", a resposta PRECISA ser passada ao TU, e a transação cliente PRECISA transitar ao estado "Completed".

Quando a transação cliente entra no estado "Completed", PRECISA definir Timer K para disparar em T4 segundos para transportes não confiáveis e zero segundos para transportes confiáveis. O estado "Completed" existe para bufferizar quaisquer retransmissões de resposta adicional que possa ser recebida (esse é o porque da transação cliente permanece ali apenas para 



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

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.