RFC 3261 SIP: Session Initiation Protocol Junho 2002
(Decline) para indicar quando a parte chamada antecipa estar disponível novamente. O valor desse campo é um número inteiro positivo de segundos (em decimal) após o tempo da resposta.
Um comentário opcional pode ser usado para indicar informação adicional sobre o tempo de retorno de chamada. Um parâmetro "duration" opcional indica quanto tempo à parte chamada estará alcançável a partir do instante inicial de disponibilidade. Se nenhum parâmetro duration for fornecido, o serviço é assumido estar disponível indeterminadamente.
Exemplos:
Retry-After: 18000;duration=3600
Retry-After: 120 (I'm in a meeting)
20.34 Route
O campo-cabeçalho Route é usado para forçar roteamento para uma requisição através do conjunto de proxy's listados. Exemplos do uso do campo-cabeçalho Route estão na Seção 16.12.1.
Exemplo:
Route: <sip:bigbox3.site3.atlanta.com;lr>,
<sip:server10.biloxi.com;lr>
20.35 Server
O campo-cabeçalho Server contém informação sobre o software usado pelo UAS para tratar a requisição.
Ao revelar a versão específica do software do servidor pode permitir ao servidor se tornar mais vulneráveis a ataques contra o software que é conhecido por conter furos na segurança. Implementadores DEVE fazer o campo-cabeçalho Server uma opção configurável.
Exemplo:
Server: HomeServer v2
20.36 Subject
O campo-cabeçalho Subject fornece um resumo ou indica a natureza da chamada, permitindo filtragem de chamada sem ter de parse a descrição da sessão. A descrição da sessão não precisa usar a mesma indicação de assunto quando do convite.
A forma compacta do campo-cabeçalho Subject é s.
Rosenberg, et. al. Standards Track [Página 177]
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