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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


A transação INVITE é diferente daqueles outros métodos devido à sua duração estendida. Normalmente, a entrada humana é necessária, a fim de responder a um INVITE. Atrasos longos esperados ao enviar uma resposta justifica um handshake três-vias. Por outro lado, requisições de outros métodos são esperados completar rapidamente. Devido à confiabilidade da transação não-INVITE em um handshake duas-vias, TU's PRECISAM responder imediatamente às requisições não-INVITE.


17.1.1 Transação INVITE Cliente

17.1.1.1 Visão Geral da Transação INVITE

A transação INVITE consiste em um handshake três-vias. A transação cliente envia um INVITE, a transação servidor envia respostas, e a transação cliente envia um ACK. Para transportes não confiáveis ​​(como UDP), a transação cliente retransmite requisições em um intervalo que começa em T1 segundos e dobla após cada retransmissão. T1 é uma estimativa do tempo de ida e volta (round-trip time RTT), e esse padronizado em 500 ms. Quase todos os timers de transação aqui descritos escala com T1, e ao mudar T1 ajusta seus valores. A requisição não é retransmitida em transportes confiáveis. Após receber uma resposta 1xx, quaisquer retransmissões cessam por completo, o cliente espera por mais respostas. A transação servidor pode enviar respostas adicionais 1xx, que não são transmitidas de maneira confiável pela transação servidor. Eventualmente, a transação servidor decide enviar uma resposta final. Para transportes não confiáveis, essa resposta é retransmitida periodicamente, e para transportes confiáveis, ela é enviada uma vez. Para cada resposta final, que é recebida na transação cliente, a transação cliente envia um ACK, o propósito disso é matar retransmissões da resposta.


17.1.1.2 Descrição Formal

A máquina de estado para a transação INVITE cliente é mostrada na Figura 5. O estado inicial, "chamando", PRECISA ser introduzido quando o TU inicia uma nova transação cliente com uma requisição INVITE. A transação cliente PRECISA passar a requisição à camada de transporte para transmissão (ver Seção 18). Se um transporte não confiável estiver sendo usado, a transação cliente PRECISA iniciar o temporizador A com um valor T1. Se um transporte confiável estiver sendo usado, a transação cliente NÃO DEVE iniciar o temporizador A (Timer A controla retransmissões de requisição). Para qualquer transporte, a transação cliente PRECISA inciar timer B com um valor 64*T1 segundos (Timer B controla timeouts de transação).

Quando o temporizador A dispara, a transação cliente PRECISA retransmitir a requisição passando-a à camada de transporte, e PRECISA ressetar o timer com um valor 2*T1. A definição formal de retransmitir 





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

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.