RFC 3261 Português Página 134 :: 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 134

RFC 3261            SIP: Session Initiation Protocol           Junho 2002
A transação cliente DEVE informar ao TU que uma falha ocorreu no transporte, e a transação cliente DEVE transitar diretamente ao estado "Terminated". O TU tratará os mecanismos de failover descrito em [4].
17.2 Transação Servidor
A transação servidor é responsável pela entrega de requisições ao TU e a transmissão confiável de respostas. Ele consegue isso através de uma máquina de estado. Transações servidor são criadas pelo núcleo quando uma requisição é recebida, e manipulação de transações é desejado para essa requisição (isso nem sempre é o caso).
Quanto às transações cliente, a máquina de estado depende se a requisição recebida é uma requisição INVITE.
17.2.1 Transação INVITE Servidor
O diagrama de estado para a transação INVITE servidor é mostrado na Figura 7.
Quando uma transação servidor é construída para uma requisição, ela entra no estado "Proceeding". A transação servidor PRECISA gerar uma resposta 100 (Trying) a menos que ela saiba que o TU vai gerar uma resposta provisória ou final dentro de 200 ms, nesse caso ela PODE gerar uma resposta 100 (Trying). Essa resposta provisória é necessária para saciar retransmissões de requsição rapidamente a fim de evitar o congestionamento da rede. As respostas 100 (Trying) são construídas de acordo com os procedimentos da Seção 8.2.6, exceto que a inserção de tags no campo-cabeçalho To da resposta (quando nenhuma estava presente na requisição) é rebaixado de PODE para NÃO DEVE. A requisição PRECISA ser passada ao TU.
O TU passa quaisquer respostas provisórias à transação servidor. Tão logo a transação servidor entre no estado "Proceeding", cada uma dessas PRECISA ser passada à camada de transporte para transmissão. Elas não são enviadas de forma confiável pela camada de transação (elas não são retransmitidas por ela) e não causar uma mudança no estado da transação servidor. Se uma retransmissão de requisição for recebida enquanto no estado "Proceeding", a resposta provisória mais recente que foi recebida do TU PRECISA ser passada à camada de transporte para retransmissão. Uma requisição é uma retransmissão se ela conferir com a mesma transação servidor baseado nas regras da Seção 17.2.3.
Se, durante o estado "Proceeding", o TU passar uma resposta 2xx à transação servidor, a transação servidor PRECISA passar essa resposta à camada de transporte para transmissão. Ela não é
Rosenberg, et. al.          Standards Track                   [Página 134]


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.