RFC 3261 SIP: Session Initiation Protocol Junho 2002
Alternativamente, um servidor recebendo uma requisição OPTIONS com um valor 0 de campo-cabeçalho Max-Forwards PODE responder a requisição independentemente do Request-URI.
Esse comportamento é comum ao HTTP/1.1. Esse comportamento pode ser usado como uma funcionalidade "traceroute" para verificar as capacidades dos servidores individuais no hop enviando uma série de requisições OPTIONS com valores Max-Forwards incrementados.
Como é o caso de comportamento geral do UA, a camada de transação pode retornar um erro por timeout, se OPTIONS não produzir nenhuma resposta. Isso pode indicar que o destino está inalcançável e, portanto, indisponível.
Uma requisição OPTIONS PODE ser enviada como parte de um diálogo estabelecido para consultar pares a cerca de capacidades que podem ser usadas mais tarde no diálogo.
11.1 Construção de Requisição OPTIONS
Uma requisição OPTIONS é construído usando as regras padrões para uma requisição SIP como discutido na Seção 8.1.1.
Um campo-cabeçalho Contact PODE estar presentes em uma requisição OPTIONS.
Um campo-cabeçalho Accept DEVE ser incluído para indicar o tipo de corpo da mensagem que o UAC deseja receber na resposta. Tipicamente, isso é definido com um formato que é usado para descrever as capacidades de mídia de um UA, tais como o SDP (application/sdp).
A resposta a uma requisição OPTIONS é assumida como escopo ao Request-URI na requisição original. No entanto, somente quando uma OPTIONS é enviada como parte de um diálogo estabelecido é que ele garantiu que futuras requisições serão recebidas pelo servidor que gerou a resposta ao método OPTIONS.
Exemplo de requisição OPTIONS:
OPTIONS sip:carol@chicago.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip:carol@chicago.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>
Accept: application/sdp
Content-Length: 0
Rosenberg, et. al. Standards Track [Página 67]
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