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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002
o   Proxy's não mais encaminha uma 6xx imediatemente ao recebê-la. Em vez disso, eles CANCEL-ariam branch's pendentes imediatamente. Isso evita uma condição race potencial que resultaria no UAC receber uma 6xx seguida por uma 2xx. Em todos os casos exceto essa condição race, o resultado seria o mesmo - a 6xx é encaminhada upstream.
o   A RFC 2543 não tratava o problema da fusão de requisição. Isso ocorre quando uma requisição bifurca em um proxy e depois junta-se de novo a um elemento. Tratamento da função é feito só no UA, e procedimentos são definidos para rejeitar todas exceto a primeira requisição.
28.2 Mudanças Funcionais Menores
o   Adicionou os campos-cabeçalhos Alert-Info, Error-Info e Call-Info para apresentação de conteúdo opcional aos usuários.
o   Adicionou os campos-cabeçalhos Content-Language, Content-Disposition e MIME-Version.
o   Adicionou um mecanismo "glare handling" para lidar com o caso onde ambas as partes enviam entre si um re-INVITE simultaneamente. Ele usa o novo codigo de erro 491 (Request Pending).
o   Adicionou os campos-cabeçalhos In-Reply-To e Reply-To para suportar o retorno de chamadas ou mensagens perdidas em momento posterior.
o   Adicionou o TLS e o SCTP como transportes válidos ao SIP.
o   Havia uma variedade de mecanismos descritos para tratar falhas a qualquer instante durante uma chamada; eles agora estão geralmente unificados. O BYE é enviado para terminar.
o   A RFC 2543 obrigava retransmissão de respostas a INVITE sobre o TCP, mas observava que isso era realmente necessário só para 2xx. Isso era um artifato de estratificação insuficiente de protocolo. Com uma camada de transação mais coerentemente definida aqui, isso não mais é necessário. Só respostas 2xx a INVITE's são retransmitidas no TCP.
o   Máquinas de transação cliente e servidor agora são controladas baseada em timeouts em vez de retransmitir contagens. Isso permite as máquinas de estado serem devidamente especificadas para o TCP e o UDP.
o   O campo-cabeçalho Date é usado em respostas a REGISTER para fornecer um meio simples para auto-configuração de datas em agentes-usuários.
o   Permitido a um registrador rejeitar pedidos de registro com prazos de expiração que são muito curtos em duração. Definiu o código-resposta 423 e o Min-Expires com esse propósito.
Rosenberg, et. al.          Standards Track                   [Página 260]


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.