RFC 3261 SIP: Session Initiation Protocol Junho 2002
o O BNF de URL do SIP se tornou mais geral, permitindo um conjunto maior de caracteres na parte usuário. Além disso, regras de comparação foram simplificadas para ser essencialmente maiúsculas e minúsculas, e manipulação detalhada de comparação na presença de parâmetros foi descrito. A mudança mais substancial é que um URI com um parâmetro com o valor padrão não bate com um URI sem esse parâmetro.
o Removido a ocultação do Via. Ele tinha sérios problemas de confiança, uma vez que dependia do próximo salto para executar o processo de ocultação. Em vez disso, a ocultação do Via pode ser feito como uma escolha da implementação local em proxy's stateful, e assim não mais é documentado.
o Na RFC 2543, transações CANCEL e INVITE eram intercaladas. Elas estão agora separadas. Quando um usuário envia um INVITE e depois um CANCEL, a transação INVITE ainda termina normalmente. Um UAS necessita responder à requisição INVITE original com uma resposta 487.
o De forma similar, transações CANCEL e BYE foram intercaladas; a RFC 2543 permitia ao UAS não enviar uma resposta ao INVITE quando um BYE era recebido. Isso é disabilitado aqui. O INVITE original precisa de uma resposta.
o Na RFC 2543, UA's precisavam suportar apenas o UDP. Nessa RFC, UA's precisam suportar tanto o UDP quanto o TCP.
o Na RFC 2543, um proxy ao bifurcar só passava um desafio de elementos downstream no evento de múltiplos desafios. Nessa RFC, proxys são supostos colectar todos os desafios e colocá-los na resposta encaminhada.
o Nas credenciais Digest, o URI necessita estar entre aspas; isso não está claro desde a RFC 2617 e a RFC 2069 que são ambas inconsistentes nisso.
o O processamento SDP foi dividido em uma especificação separada [13], e especificado muito mais à fundo como um processo de troca oferta/aceite formal que é efetivamente tunelado no SIP. O SDP é permitido em INVITE/200 ou 200/ACK para implementações SIP basilar; a RFC 2543 aludia à habilidade de usá-lo em INVITE, 200 e ACK em uma transação simples, mas isso não foi especificado bem. Usos mais complexos do SDP são permitidos em extensões.
Rosenberg, et. al. Standards Track [Página 256]
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:
Postar um comentário