11. Querying for Capabilities
11 Querying for Capabilities
OPTIONS est une méthode de requête utilisée pour interroger les capacités d'un agent utilisateur ou d'un proxy. Elle est similaire à OPTIONS de HTTP/1.1. Le serveur de destination répond avec un 200 (OK) accompagné d'un corps de message décrivant ses capacités.
Les requêtes OPTIONS permettent d'interroger la capacité d'établir un appel sans établir l'appel. Par exemple, un agent utilisateur client (UAC) peut envoyer un OPTIONS à l'agent utilisateur serveur (UAS) d'un utilisateur particulier pour découvrir les extensions prises en charge, les codecs, etc. Cependant, cette approche n'est pas recommandée (NOT RECOMMENDED) comme vérification d'accessibilité, car les capacités du protocole de description de session (SDP) peuvent également être utilisées pour vérifier l'accessibilité. À la place, il est recommandé (RECOMMENDED) d'envoyer un INVITE contenant une offre et d'observer la réponse d'erreur (ou de succès). La raison « entre guillemets » est qu'un UAC ne peut pas effectuer d'authentification avant d'envoyer un INVITE, donc un attaquant pourrait facilement forger une requête OPTIONS pour permettre au UAC d'interroger facilement la présence du destinataire. Par conséquent, le comportement SIP traditionnel brise la vérification d'accessibilité basée sur OPTIONS, car il force l'authentification du destinataire pour maintenir le pair-à-pair de l'appel.
Les requêtes OPTIONS peuvent être envoyées à la fois d'un UAC à un UAS et d'un UAC à un proxy. (Comme un UAS est un point de terminaison agissant comme proxy ou serveur de redirection, envoyer un OPTIONS à un proxy est logiquement équivalent à l'envoyer à un UAS.) Une telle requête PEUT (MAY) être utilisée pour interroger les capacités de n'importe quel point de terminaison dans le domaine identifié par le Request-URI de la requête (suivant le comportement du proxy de la section 16).
11.1 Construction d'une requête OPTIONS
Une requête OPTIONS est créée en utilisant le modèle d'entité défini dans [4], l'adresse de destination étant le Request-URI. Aucun champ d'en-tête Require ou Proxy-Require supplémentaire ne peut être inclus dans cette requête (MUST NOT).
Le champ d'en-tête Accept de cette requête PEUT (MAY) spécifier un format qui est préféré (SHOULD) à tout autre moyen de description de capacité.
11.2 Traitement des requêtes OPTIONS
La réception d'une requête OPTIONS est traitée de la même manière qu'une requête non-INVITE. Un UAS conforme à cette spécification renvoie une réponse 405 (Method Not Allowed) pour toute méthode reçue si la requête est par ailleurs INVALID. Par conséquent, un serveur ne prenant pas en charge la capacité de la méthode OPTIONS DEVRAIT (SHOULD) renvoyer 405 (Method Not Allowed) lors de la réception d'une requête OPTIONS.
11.3 Génération d'une réponse à OPTIONS
La construction d'une réponse 200 (OK) à une requête OPTIONS suit les procédures décrites à la section 8.2.6. Le corps de la réponse est optionnel (OPTIONAL). Si le corps est vide, le 200 (OK) inclut uniquement les champs d'en-tête requis (à l'exception de Contact). Les champs d'en-tête Allow, Accept, Accept-Encoding, Accept-Language et Supported sont recommandés (RECOMMENDED) pour décrire les capacités du UAS. Le corps du message PEUT (MAY) être utilisé pour une description plus détaillée des capacités. Un tel corps peut être dans n'importe quel format approprié, et doit (MUST) essentiellement fournir des informations permettant au destinataire de comprendre les capacités prises en charge et de décider s'il les utilise.
11.4 Interrogation d'un proxy avec OPTIONS
Lorsqu'un proxy reçoit une requête OPTIONS, il DEVRAIT (SHOULD) renvoyer une réponse 200 (OK) décrivant les capacités qu'il prend en charge. La description des capacités du proxy ne DEVRAIT (SHOULD) être renvoyée que pour une requête OPTIONS dont le Request-URI a une adresse correspondant au domaine de responsabilité du proxy. Le code de réponse 501 (Not Implemented) DEVRAIT (SHOULD) être renvoyé si le proxy ne prend pas en charge une telle requête. En d'autres termes, lorsque le cœur est du côté proxy, le proxy traite la requête comme pour toute autre requête et génère une réponse. Si le proxy reçoit sa propre requête OPTIONS et ne peut pas la résoudre vers son domaine de responsabilité, il DEVRAIT (SHOULD) renvoyer 404 (Not Found) (si l'URI ne peut pas être résolu). Si le proxy reçoit sa propre requête OPTIONS et peut la résoudre vers son domaine de responsabilité mais ne souhaite pas décrire ses capacités, il DEVRAIT (SHOULD) renvoyer 405 (Method Not Allowed).