RFC 3261 SIP: Session Initiation Protocol Junho 20027.5 Enquadramento de Mensagens SIPDiferente do HTTP, implementações SIP podem usar o UDP ou outros protocolos de datagrama não confiáveis. Cada datagrama carrega uma requisição ou uma resposta. Consulte a Seção 18 sobre restrições ao uso de transportes não-confiáveis.Implementações que processam mensagens SIP em transportes orientada a stream PRECISAM ignorar qualquer CRLF que aparecer antes da linha-início [H4.1].O valor do campo-cabeçalho Content-Length é usado para localizar o fim de cada mensagem SIP em uma stream. Ele sempre estará presente quando mensagens SIP forem enviadas em transporte orientado a stream.8 Comportamento Geral de Agente-UsuárioUm agente-usuário representa um sistema fim. Ele contém um cliente agente-usuário (UAC), que gera requisições, e um servidor agente-usuário (UAS), que os responde. Um UAC é capaz de gerar uma requisição baseado em algum estímulo externo (o usuário clicar em um botão, ou um sinal de linha PSTN) e processa uma resposta. Um UAS é capaz de receber uma requisição e gerar uma resposta baseado na entrada do usuário, estímulo externo, o resultado da execução de um programa, ou algum outro mecanismo.Quando um UAC envia uma requisição, a requisição atravessa alguns servidores proxy, que encaminhará a requisição à adiante para o UAS. Quando o UAS gerar uma resposta, a resposta é encaminhada de volta ao UAC.Procedimentos de UAC e de UAS dependem fortemente de dois fatores. O primeiro, baseado na requisição ou na resposta se estiver dentro ou fora de um diálogo, e o segundo, baseado no método de uma requisição. Diálogos são amplamente discutidos na Seção 12; eles representam uma relação peer-to-peer entre agentes-usuários e são estabelecidos por métodos SIP específicos, como o INVITE.Nessa seção, nós discutiremos as regras independente de método para o comportamento de UAC e de UAS quando processando requisições que estão fora de um diálogo. Isto inclui, naturalmente, requisições que se estabelecem em um diálogo.Procedimentos de segurança para requisições e respostas fora de um diálogo são descritos na Seção 26. Especificamente, existem mecanismos para UAS e UAC se autenticarem mutuamente. Um conjunto limitado de recursos de privacidade também são suportados através de criptografia de corpos de mensagem usando S/MIME.Rosenberg, et. al. Standards Track [Página 34]
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