RFC 3261 Português Página 135 :: Admirável Mundo Novo




Muito Bem Vindo

Prezado Leitor, a proposta desse Blog é compartilhar conhecimento com as pessoas que trabalham com Linux, Asterisk, OpenSER, e com tecnologia de voz sobre a rede IP em geral, através de tutoriais, dicas, howto, notícias entre outros assuntos.

Atente para termo de uso do conteúdo do blog no rodapé da página.

segunda-feira, 11 de julho de 2011

RFC 3261 Português Página 135

RFC 3261            SIP: Session Initiation Protocol           Junho 2002
retransmitida pela transação servidor; retransmissões de respostas 2xx são tratadas pelo TU. A transação servidor PRECISA então transitar ao estado "Terminated".
Enquanto no estado "proceeding", se o TU passar uma resposta com código de status 300-699 à transação servidor, a resposta PRECISA ser passada à camada de transporte para transmissão, e a máquina de estado PRECISA entrar no estado "Completed". Para transportes não confiáveis, o timer G é definido para disparar em T1 segundos, e não é definido para disparar para transportes confiáveis.
Essa é uma alteração da RFC 2543, onde as respostas eram sempre retransmitidas, mesmo sobre transportes confiável.
Quando o estado "Completed" for inserido, o timer H PRECISA ser definido para disparar em 64*T1 segundos para todos os transportes. O Timer H determina quando a transação servidor abandona a retransmissão da resposta. Seu valor é escolhido igual ao Timer B, a quantidade de tempo que uma transação cliente continuará a repetir o envio de uma requisição. Se o timer G disparar, a resposta é passada à camada de transporte uma vez mais para retransmissão, e o timer G é definido para disparar MIN (2*T1, T2) segundos. A partir daí, quando o timer G disparar, a resposta é passada ao transporte novamente para transmissão, e o timer G é reposto com um valor que duplica, a menos que o valor excede T2, caso em que é ressetado com o valor T2. Isso é idêntico ao comportamento de retransmitir requisições no estado "Trying" da transação não-INVITE cliente. Além disso, enquanto no estado "Completed", se uma retransmissão de requisição for recebida, o servidor DEVE passar a resposta ao transporte para retransmissão.
Se um ACK for recebido enquanto a transação servidor estiver no estado "Completed", a transação servidor PRECISA transitar ao estado "Confirmed". Como o Timer G é ignorado nesse estado, quaisquer retransmissões da resposta cessarão.
Se o temporizador H disparar, enquanto no Estado "Completed", isso implica que o ACK nunca foi recebido. Nesse caso, a transação servidor PRECISA transitar ao estado "Terminated", e PRECISA indicar ao TU que ocorreu uma falha na transação.
Rosenberg, et. al.          Standards Track                   [Página 135]


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.



Nenhum comentário:




Creative Commons License
Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP
by Cléviton Mendes de Araújo is licensed under a Creative Commons Atribuição 2.5 Brasil License.