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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002
o   Uso de Route em CANCEL e ACK não era bem definido na RFC 2543. Agora está bem especificado; se uma requisição tinha um campo-cabeçalho Route, suas CANCEL ou ACK para uma resposta não-2xx à requisição necessita transportar os mesmos valores do campo-cabeçalho Route. ACK's para respostas 2xx usam os valores de Route aprendidos do Record-Route das respostas 2xx.
o   A RFC 2543 permitia múltiplas requisições em um único pacote UDP. Esse uso foi removido.
o   Uso de tempo absoluto no campo-cabeçalho Expires e parâmetro foi removido. It caused problemas de interoperabilidade em elementos que não eram sincronizados no tempo, uma ocorrência comum. Tempos relativos são usados no lugar.
o   O parâmetro branch no value do campo-cabeçalho Via agora é obrigatório para todos os elementos usar. Ele agora faz o papel de um identificador único da transação. Isso evita as regras complexas e cheias de bug para identificação da transação da RFC 2543. Um cookie mágico é usado no valor do parâmetro para determinar se o salto anterior tem feito o parâmetro globalmente único, e comparação caem nas regras antigas quando não estiver presente. Portanto, a interoperabilidade é assegurada.
o   Na RFC 2543, encerramento de uma connexão TCP foi tornado equivalente a um CANCEL. Isso era quase impossível implementar (e problemático) para conexões TCP entre proxy's. Isso foi eliminado, de sorte que não há nenhum acoplamento entre o estado de conexão TCP e o processamento SIP.
o   A RFC 2543 era omissa se um UA poderia iniciar uma nova transação com um peer enquanto uma outra estava em progresso. Isso agora é especificado aqui. Isso é permitido a requisições não-INVITE, e não permitido a INVITE.
o   O PGP foi removido. Esse não era suficientemente especificado, e não era compatível com o PGP MIME mais completo. Ele foi substituido pelo S/MIME.
o   Adicionou o esquema URI "sips" para o TLS fim-a-fim. Esse esquema não é retro-compatível com a RFC 2543. Elementos existentes que recebem uma requisição com um esquema URI do SIPS no Request-URI rejeitará provalmente a requisição. Isso é realmente um recurso; isso assegura que uma chamada a um URI do SIPS só é entregue se todos os saltos do caminho puderem ser protegidos.
Rosenberg, et. al.          Standards Track                   [Página 258]


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.