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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002
que ele pode ter adicionado ao valor do próximo campo-cabeçalho Via ao processar a requisição associada a essa resposta. O proxy PRECISA passar a resposta à transação servidor associada ao contexto resposta. Isso resultará na resposta sendo enviada ao local agora indicado no valor do campo-cabeçalho Via mais alto. Se a transação servidor não mais estiver disponível para tratar a transmissão, o elemento PRECISA encaminhar a resposta de modo stateless enviando-a ao transporte servidor. A transação servidor pode indicar falha ao enviar a resposta ou sinalizar um timeout em sua máquina de estado. Esses erros serão registrados para propósitos de diagnóstico quando apropriado, mas o protocolo não requer nenhuma ação corretiva do proxy.
O proxy PRECISA manter o contexto resposta até que todas as suas transações associadas tenham sido terminadas, mesmo após encaminhar uma resposta final.
10. Gerar CANCEL's
Se a resposta encaminhada foi uma resposta final, o proxy PRECISA gerar uma requisição CANCEL a todas transações clientes pendentes associadas a esse contexto resposta. Um proxy também DEVE gerar uma requisição CANCEL para todas as transações pendentes do cliente associado a este contexto de resposta quando recebe uma resposta 6xx. Uma transação cliente pendente é aquela que recebeu uma resposta provisória, mas nenhuma resposta final (ela fica no estado proceeding) e não teve um CANCEL associado gerado pra ela. Geração de requisições CANCEL é descrito na Seção 9.1.
A exigência para CANCEL-ar transações clientes pendentes ao encaminhar uma resposta final não garante que um endpoint não receberá múltiplas respostas 200 (OK) a um INVITE. Respostas 200 (OK) a mais de um branch pode ser gerado antes que as requisições CANCEL possam ser enviadas e processadas. Além do mais, é razoável esperar que uma futura extensão possa substituir essa obrigação de lançar requisições CANCEL.
16.8 Processando o Timer C
Se timer C deve disparar, o proxy PRECISA tanto ressetar o temporizador com algum valor que desejar, quanto terminar a transação cliente. Se a transação cliente recebeu uma resposta provisória, o proxy PRECISA gerar uma requisição CANCEL que bate com essa transação. Se a transação cliente não recebeu uma resposta provisória, o proxy PRECISA se comportar como se a transação recebeu uma resposta 408 (Request Timeout).
Rosenberg, et. al.          Standards Track                   [Página 114]


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.