Précédent Sommaire Suivant
Les échanges client-serveur se font à l’aide de requêtes. Nous avons déjà entrevues les requêtes INVITE, ACK, BYE, REGISTER et URI. Les quatre premières appartiennent aux 6 méthodes SIP( auxquelles il faut ajouter les requêtes OPTIONS et CANCEL). La requête URI constitue un type à part de requête que nous détaillerons au paragraphe II.7.4.
Les méthodes non supportées par un PS ou un RS sont traitées en tant que méthodes OPTIONS. Les méthodes non supportées par un UAS ou RG sont ignorées et une réponse de code 501 est renvoyée à l’émetteur de la requête.
Etudions en détails ces 6 méthodes :
· INVITE : indique que l’application ou utilisateur est invité à participer à une session. Le Corps du message décrit cette session(média supportés par l’appelant entre autres). En cas de réponse favorable à l’invitation, l’invité doit spécifier également les médias qu’il supporte dans son Corps du message. Un serveur est tenu de répondre à une telle invitation, identifiée par son CALL-ID, par une réponse OK(code200). Si un UAS reçoit une requête INVITE avec un numéro de séquence Cseq supérieur à celui de la dernière requête INVITE de même CALL-ID reçue, celui-ci doit mettre à jour cette dernière. Cette méthode doit être supportée par les PS,RS, UAS et UAC.
· ACK : confirme que le client a reçu une réponse définitive à une requête INVITE. Les réponses de code 2xx sont acquittées par les UAC et les autres types de réponses définitives par les premiers PS ou UAC les ayant reçues. La requête ACK possède, dans son Corps de message, une description définitive de la session que doit utiliser l’appelé. Si le Corps du message est vide(car il est optionnel), l’appelé utilise le descripteur de session de la requête INVITE. Après avoir envoyé une réponse de code 3xx, 4xx, 5xx ou 6xx, un PS doit déterminer si la requête ACK lui est destinée ou si elle est destinée à un autre PS. Cette détermination se fait en examinant le paramètre tag de l’URL TO.
Le ACK lui est destiné si :
1)le tag de l’URL TO de la requête ACK est égal au tag de l’URL TO de la réponse ;
2)l’URL FROM, le CALL-ID et le Cseq de la requête ACK sont égaux à ceux de la réponse.
Cette méthode doit être supportée par les PS, RS, UAS et UAC.
· OPTIONS : un PS en mesure de contacter l’UAS appelé, doit répondre à une requête OPTIONS en précisant ses capacités à contacter l’UAS. Si l’UAS ne supporte pas cette méthode, il renvoie une réponse Busy (code600) au PS. Cette méthode doit être supportée par les PS, RS, UAS, RG et UAC.
· BYE : est utilisée par l’UAS de l'appelé pour signaler au PS local qu’il ne souhaite plus participer à la session. Si la requête INVITE contient une URL CONTACT, l’appelé envoie la requête BYE directement à cette adresse plutôt qu’à l’URL FROM. Cette méthode doit être supportée par les PS et devrait être supportée par les RS et UAS.
· CANCEL : la requête CANCEL est envoyée par un UAC ou un PS pour annuler une requête non validée par une réponse finale d’état. Par exemple, un PS peut envoyer une requête CANCEL aux destinataires n’ayant pas retourné une réponse finale après avoir reçu une réponse 2xx ou 6xx du PS. Par contre, un PS qui reçoit une requête d’erreur la retransmet à tous les destinataires qui y sont reliés. Les CALL-ID, Cseq, URL TO de la requête CANCEL sont les mêmes que ceux de la requête l’ayant générée. Pour distinguer une réponse à une requête CANCEL et une réponse à la requête originale, l’en-tête général est de type Cseq dans le format du message de la requête CANCEL. Quand un RS ou un UAS a reçu une requête CANCEL, il renvoie à l’émetteur une réponse OK(code 200) si la transaction existe bien et une réponse Transaction Does Not Exist(code 481) sinon. Cette méthode doit être supportée par le PS et devrait l’être par tous les autres types de serveurs SIP.
· REGISTER : cette méthode est utilisée par le client pour enregistrer l’adresse listée dans l’URL TO par le serveur auquel il est relié. Les requêtes sont traitées par le client dans l’ordre où elles arrivent et celui-ci devra éviter d’envoyer une nouvelle requête REGISTER tant qu’il n’aura pas traîté la précédente. Le client doit définir une adresse d’enregistrement du type Utilisateur@Domaine . Cette méthode assure un service de localisation.