RFC 3261 SIP: Session Initiation Protocol Junho 2002
o Adicionado suporte completo ao IPv6 em URI's e no campo-cabeçalho Via. Suporte ao IPv6 no Via foi exigido porque seus parâmetros de campo-cabeçalho permite os caracteres colchetes retangulares e dois pontos. Esses caracteres anteriormente não eram permitidos. Na teoria, isso poderia causar problemas de interoperabilidade com implementações mais antigas. Contudo, nós temos observado que muitas implementações aceitam qualquer caractere ASCII não-controle nesses parâmetros.
o O procedimento DNS SRV agora está documentado em uma especificação separada [4]. Esse procedimento usa ambos os recursos de registros SRV e NAPTR e não mais combina dados de atravessar registros SRV como descritos na RFC 2543.
o Detecção de loop se tornou opcional, suplantado pelo uso obrigatório de Max-Forwards. O procedimento de detecção de loop na RFC 2543 tinha um sério bug que reportaria "spirals" como uma condição de erro quando não era. O procedimento de detecção de loop opcional é mais completo e corretamente especificado aqui.
o Uso de tags agora é obrigatório (elas eram opcionais na RFC 2543), as elas agora são os blocos de construção fundamentais de identificação de diálogo.
o Adicionado o campo-cabeçalho Supported, para permitir aos clientes indicar quais extensões são suportadas em um servidor, que pode aplicar essas extensões à resposta, e indicar uso delas com um Require na resposta.
o Parâmetros de extensão estavam ausentes na BNF para vários campos-cabeçalhos, e eles foram adicionados.
o Handling de construção Route e Record-Route era muito mal especificado na RFC 2543, e também não era a abordagem certa. Isso foi substancialmente retrabalhado nessa especificação (e feito muito mais simples), e isso é sem dúvida a maior mudança. Retro-compatibilidade ainda é fornecida para instalações que não usam "rotas pré-carregadas", onde a requisição inicial tem um conjunto de valores do campo-cabeçalho Route obtido de alguma forma fora do Record-Route. Nessas situações, o novo mecanismo não é interoperável.
o Na RFC 2543, linhas em uma mensagem poderiam ser terminadas com CR, LF ou CRLF. Essa especificação só permite CRLF.
Rosenberg, et. al. Standards Track [Página 257]
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