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

domingo, 10 de julho de 2011

RFC 3261 Português Página 174

RFC 3261            SIP: Session Initiation Protocol           Junho 2002
20.25 Organization
O campo-cabeçalho Organization transmite o nome da organização para a qual o elemento SIP que emite a requisição ou resposta pertence
O campo PODE ser usado por software cliente para filtrar chamadas.
Exemplo:
      Organization: Boxes by Bob
20.26 Priority
O campo-cabeçalho Priority indica a urgência da requisição como percebido pelo cliente. O campo-cabeçalho Priority descreve a prioridade que a requisição SIP deve ter ao ser humano ou o seu agente ao receber. Por exemplo, pode ser tido em conta em decisões sobre o roteamento de chamadas e aceitação. Para essas decisões, uma mensagem contendo nenhum campo-cabeçalho Priority DEVE ser tratada como se especificado uma Prioridade "normal". O campo-cabeçalho Priority não influencia o uso dos recursos de comunicação como prioridade de encaminhamento de pacotes em roteadores ou acesso a circuitos em gateway's PSTN. O campo-cabeçalho pode ter os valores "non-urgent", "normal", "urgent" e "emergency", mas valores adicionais podem ser definidos em outro lugar. É RECOMENDADO que o valor "emergency" seja usado somente quando a vida, a integridade física ou a propriedade estão em perigo iminente. Do contrário, não há nenhuma semântica definida para esse campo-cabeçalho.
Existem os valores da RFC 2076 [38], com a adição de "emergency".
Exemplos:
Subject: A tornado is heading our way!
Priority: emergency
ou
Subject: Weekend plans
Priority: non-urgent
20.27 Proxy-Authenticate
Um valor de campo-cabeçalho Proxy-Authenticate contém um desafio de autenticação.
O uso desse campo-cabeçalho é definido em [H14.33]. Veja a Seção 22.3 para mais detalhes sobre seu uso.
Rosenberg, et. al.          Standards Track                   [Página 174]


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.