RFC 3261 SIP: Session Initiation Protocol Junho 2002
o Recursos de segurança adicionais foram adicionados com o TLS, e esses são descritos em uma seção sobre considerações de segurança muito maior e completa.
o Na RFC 2543, um proxy não era exigido a encaminhar respostas provisionais de 101 a 199 upstream. Isso foi alterado para PRECISA. Isso é importante, já que muitos recursos subsequentes dependem da entrega de todas as respostas provisionais de 101 a 199.
o Pouco era dito a cerca do código-resposta 503 na RFC 2543. Desde então tem encontrado uso substancial em indicação de condições de falha ou de sobrecarga em proxy's. Isso exige tratamento um tanto especial. Especificamente, a recepção de uma 503 deve desencadear uma tentativa de contactar o próximo elemento no resultado de uma consulta DNS SRV. Também, a resposta 503 é só encaminhada upstream por um proxy sob certas condições.
o A RFC 2543 definia, mas não especificava suficientemente, um mecanismo para autenticação UA de um servidor. Isso foi removido. No lugar, os procedimentos de autenticação mútua da RFC 2617 são permitidos.
o Um UA não pode enviar um BYE para uma chamada até que ela tenha recebido um ACK ao INVITE inicial. Isso era permitido na RFC 2543 mas conduzia a uma potencial condição race.
o Um UA ou proxy não pode enviar CANCEL para uma transação até que ele receba uma resposta provisional à requisição. Isso era permitido na RFC 2543, mas levava a potenciais condições race.
o O parâmetro action em registros ficou obsoleto. Ele era insuficiente para quaisquer serviços uteis, e causava conflitos quando processamento de aplicação era aplicado em proxy's.
o A RFC 2543 tinha inúmeros casos especiais para multicast. Por exemplo, certas respostas eram suprimidas, timers eram ajustados, e assim por diante. Multicast agora tem um papel mais limitado, e a operação de protocolo não é afetado pela uso de multicast em oposição ao unicast. As limitações como resultado disso estão documentados.
o Autenticação básica foi removida completamente e seu uso proibido.
Rosenberg, et. al. Standards Track [Página 259]
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