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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002
Exemplo:
      Record-Route: <sip:server10.biloxi.com;lr>,
                    <sip:bigbox3.site3.atlanta.com;lr>
20.31 Reply-To
O campo-cabeçalho Reply-To contém um URI de retorno lógico que pode ser diferente do campo-cabeçalho From. Por exemplo, o URI PODE ser usado para retornar chamadas não atendidas ou sessões não estabelecidas. Se o usuário deseja permanecer anônimo, o campo-cabeçalho DEVEM ou ser omitidos da requisição ou preenchido de tal forma que não revele qualquer informação privada.
Mesmo que o "display-name" estiver vazio, a forma "name-addr" PRECISA ser usado se o "addr-spec" contém uma vírgula, uma interrogação ou ponto e vírgula. Questões de sintaxe são discutidas na Seção 7.3.1.
Exemplo:
      Reply-To: Bob <sip:bob@biloxi.com>
20.32 Require
O campo-cabeçalho Require é usado por UAC's para dizer aos UAS's sobre opções que o UAC espera do UAS suportar, a fim de processar a requisição. Apesar de um campo-cabeçalho opcional, o Require NÃO PODE ser ignorado se estiver presente.
O campo-cabeçalho Require contém uma lista de tags option, descrito na Seção 19.2. Cada tag option define uma extensão SIP que PRECISA ser entendida para processar a requisição. Freqüentemente, ele é usado para indicar que um conjunto específico de campos-cabeçalhos de extensão precisam ser entendidos. Um UAC em conformidade com essa especificação PRECISA só incluir tags option que correspondem ao trâmite de padronização de RFC's.
Exemplo:
Require: 100rel
20.33 Retry-After
O campo-cabeçalho Retry-After pode ser usado com uma resposta 500 (Server Internal Error) ou 503 (Service Unavailable) para indicar quanto tempo o serviço é esperado estar indisponível ao cliente que requisita e com uma resposta 404 (Not Found), 413 (Request Entity Too Large), 480 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy) ou 603
Rosenberg, et. al.          Standards Track                   [Página 176]


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.