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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


dentro do contexto da camada de transação é levar a mensagem enviada anteriormente à camada de transporte e passá-la à camada de transporte uma vez mais.

Quando o temporizador A dispara 2*T1 segundos depois, a requisição PRECISA ser retransmitida novamente (supondo que a transação cliente ainda está nesse estado). Este processo PRECISA continuar de sorte que a requisição seja retransmitida com intervalos que dobram após cada transmissão. Essas retransmissões só DEVEM ser feitas enquanto a transação cliente está no estado "calling".

O valor padrão para T1 é 500 ms. T1 é uma estimativa do RTT entre as transações cliente e o servidor. Elementos PODEM (embora NÃO SEJA RECOMENDADO) usar valores T1 menores dentro de redes privadas fechadas, que não permitem conexão com a Internet em  geral. T1 PODE ser escolhido maior, e isso É RECOMENDADO se for conhecido de antemão (como em links de acesso com alta latência) que o RTT é maior. Seja qual for o valor de T1, os algoritmos backoffs exponencial em retransmissões descritas nesta seção PRECISAM ser usados.

Se a transação cliente ainda estiver no estado "Calling" quando timer B dispara, a transação cliente DEVE informar o TU que um timeout ocorreu. A transação cliente NÃO PODE gerar um ACK. O valor de 64*T1 é igual à quantidade de tempo necessária para enviar sete requisições no caso de um transporte não-confiável.

Se a transação cliente receber uma resposta provisória enquanto no estado "Calling", ele transita para o estado "Proceeding". No estado "Proceeding", a transação cliente NÃO DEVE retransmitir a requisição por mais tempo. Além disso, a resposta provisória PRECISA ser passado ao TU. Todas as respostas provisórias adicionais PRECISAM ser passadas ao TU, enquanto no estado "Proceeding".

Quando em ambos os estados "Calling" ou "Proceeding", a recepção de uma resposta com código de status 300-699 PRECISA fazer que a cliente transação transite para o estado "Completed". A transação cliente PRECISA passar a resposta recebida ao TU, e a transação cliente PRECISA gerar uma requisição ACK, mesmo que o transporte seja confiável (orientações para construir o ACK da resposta são apresentados na Seção 17.1.1.3) e depois passar o ACK à camada de transporte para a transmissão. O ACK PRECISA ser enviado ao mesmo endereço, porta e transporte sobre qual a requisição original foi enviada. A transação cliente DEVE disparar o temporizador D quando ele entrar no estado "Completed", com um valor pelo menos 32 segundos para transporte não confiável, e um valor zero segundos para transporte confiável. O Timer D reflete a quantidade de tempo que a transação servidor pode permanecer no estado "Completed" quando transportes confiáveis forem usados. Isso é igual a Timer H na transação INVITE servidor, cujo




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

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.