RFC 3261 Português Página 68

RFC 3261 SIP: Session Initiation Protocol Junho 2002

11.2 Processamento de Requisição OPTIONS

A resposta a uma OPTIONS é construída usando as regras padrões para resposta SIP como discutido na Seção 8.2.6. O código resposta escolhido PRECISA ser o mesmo que teria sido escolhido se tivesse sido a requisição uma INVITE. Ou seja, uma 200 (OK) seria retornada se o UAS estiver pronto para aceitar uma chamada, uma resposta 486 (Busy Here) seria retornada se o UAS estivesse ocupado, etc. Isso permite que uma requisição OPTIONS seja usada para determinar o estado base de um UAS, o que pode ser uma indicação se o UAS aceitará ou não uma requisição INVITE.

Uma requisição OPTIONS recebida dentro de um diálogo gera uma resposta 200 (OK) que é idêntica a aquela construída fora de um diálogo e não tem qualquer impacto no diálogo.

Esse uso de OPTIONS tem limitações devido a diferenças no tratamento de requisições OPTIONS e INVITE no proxy. Enquanto uma INVITE bifurcada pode resultar em múltiplas respostas 200 (OK) sendo retornadas, uma OPTIONS bifurcada só irá resultar em uma única resposta 200 (OK), porque ela é tratada pelos proxy's usando o tratamento de não-INVITE. Ver Seção 16.7 para detalhes normativos.

Se a resposta a uma OPTIONS for gerada por um servidor proxy, o proxy retorna uma 200 (OK), listando as caapcidades do servidor. A resposta não contém um corpo de mensagem.

Campos-cabeçalhos Allow, Accept, Accept-Encoding, Accept-Language e Supported DEVEM estar presentes em uma resposta 200 (OK) a uma requisição OPTIONS. Se a resposta for gerada por um proxy, o campo-cabeçalho Allow DEVE ser omitido, porque esse é ambíguo já que proxy é um método agnóstico. Campos-cabeçalhos Contact PODEM estar presentes em uma resposta 200 (OK) e tem a mesma semântica que uma resposta 3xx. Ou seja, elas podem listar um conjunto de nomes alternativos e métodos para alcançar o usuário. Um campo-cabeçalho Warning PODE estar presentes.

O corpo da mensagem PODE ser enviado, o tipo dele é determinado pelo campo-cabeçalho Accept na requisição OPTIONS (application/sdp é o padrão, se o campo-cabeçalho Accept não estiver presente). Se os tipos incluem um que pode descrever capacidades de mídia, o UAS DEVE incluir um corpo na resposta para esse finalidade. Detalhes sobre a construção de tal corpo no caso de application/sdp são descritos em [13].

Rosenberg, et. al. Standards Track [Página 68]

Página Anterior

Tabela de Conteúdo

Página Seguinte



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.