RFC 3261 SIP: Session Initiation Protocol Junho 2002
Comparação de campos-cabeçalhos To por equidade é idêntico à comparação de campos-cabeçalhos From. Ver a Seção 20.10 para as regras de parse um nome de exibição, URI e parâmetros URI, e parâmetros de campo-cabeçalho.
A forma compacta do campo-cabeçalho To é t.
Os seguintes são exemplos de campos-cabeçalhos To válidos:
To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
t: sip:+12125551212@server.phone2net.com
20.40 Unsupported
O campo-cabeçalho Unsupported lista os recursos não suportados pelo UAS. Ver a Seção 20.32 por motivação.
Exemplo:
Unsupported: foo
20.41 User-Agent
O campo-cabeçalho User-Agent contém informação sobre o UAC que originou a requisição. A semântica desse campo-cabeçalho é definida em [H14.43].
Ao revelar a versão especifica de software do agente-usuário pode permitir ao agente-usuário se tornar mais vulnerável a ataques contra software que é sabido conter furos na segurança. Implementadores DEVE tornar o campo-cabeçalho User-Agent uma opção configurável.
Exemplo:
User-Agent: Softphone Beta1.5
20.42 Via
O campo-cabeçalho Via indica o caminho tomado pela requisição até aqui e indica o caminho que deve ser seguindo em roteamento de respostas. O parâmetro branch ID nos valores do campo-cabeçalho Via serve como um identificador de transação, e é usado por proxy's para detectar loops.
Um valor do campo-cabeçalho Via contém o protocolo de transporte usado para enviar a mensagem, o hostname do cliente ou endereço de rede, e possivelmente a porta em que ele deseja receber respostas. Um valor do campo-cabeçalho Via pode também conter parâmetros como "maddr", "ttl", "received", e "branch", cujo significado e uso são descritos
Rosenberg, et. al. Standards Track [Página 179]
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