Aller au contenu principal

6. Definitions

6 Definitions

Les termes suivants revêtent une signification particulière pour SIP.

  Address-of-Record (AOR) : un address-of-record (AOR) est un URI SIP ou SIPS qui pointe vers un domaine disposant d'un service de localisation capable de mapper l'URI vers un autre URI où l'utilisateur pourrait être disponible. Typiquement, le service de localisation est alimenté par des enregistrements. Un AOR est souvent considéré comme l'« adresse publique » de l'utilisateur.

  Back-to-Back User Agent : un agent utilisateur back-to-back (B2BUA) est une entité logique qui reçoit une requête et la traite en tant qu'agent utilisateur serveur (UAS). Afin de déterminer comment la requête doit être répondue, il agit en tant qu'agent utilisateur client (UAC) et génère des requêtes. Contrairement à un serveur mandataire, il maintient l'état du dialogue et doit participer à toutes les requêtes envoyées sur les dialogues qu'il a établis. Puisqu'il s'agit d'une concaténation d'un UAC et d'un UAS, aucune définition explicite de son comportement n'est nécessaire.

  Call (appel) : un appel est un terme informel qui fait référence à une communication entre pairs, généralement établie dans le but d'une conversation multimédia.

  Call Leg (branche d'appel) : autre nom pour un dialogue [31] ; n'est plus utilisé dans cette spécification.

  Call Stateful (avec état d'appel) : un mandataire est dit avec état d'appel s'il conserve l'état d'un dialogue de l'INVITE initial à la requête BYE terminale. Un mandataire avec état d'appel est toujours avec état de transaction, mais l'inverse n'est pas nécessairement vrai.

  Client : un client est tout élément de réseau qui envoie des requêtes SIP et reçoit des réponses SIP. Les clients peuvent ou non interagir directement avec un utilisateur humain. Les agents utilisateur clients et les mandataires sont des clients.

  Conference (conférence) : une session multimédia (voir ci-dessous) qui contient plusieurs participants.

  Core : le cœur désigne les fonctions spécifiques à un type particulier d'entité SIP, c'est-à-dire spécifiques soit à un mandataire avec état ou sans état, soit à un agent utilisateur ou à un registre. Tous les cœurs, sauf ceux du mandataire sans état, sont des utilisateurs de transaction.

  Dialog (dialogue) : un dialogue est une relation SIP pair-à-pair entre deux UA qui persiste pendant un certain temps. Un dialogue est établi par des messages SIP, tels qu'une réponse 2xx à une requête INVITE. Un dialogue est identifié par un identifiant d'appel, une étiquette locale et une étiquette distante. Un dialogue était anciennement connu sous le nom de branche d'appel dans la RFC 2543.

  Downstream (aval) : une direction de transfert de message au sein d'une transaction qui fait référence à la direction dans laquelle les requêtes circulent de l'agent utilisateur client vers l'agent utilisateur serveur.

  Final Response (réponse finale) : une réponse qui termine une transaction SIP, par opposition à une réponse provisoire qui ne le fait pas. Toutes les réponses 2xx, 3xx, 4xx, 5xx et 6xx sont finales.

  Header (en-tête) : un en-tête est un composant d'un message SIP qui transmet des informations sur le message. Il est structuré comme une séquence de champs d'en-tête.

  Header Field (champ d'en-tête) : un champ d'en-tête est un composant de l'en-tête du message SIP. Un champ d'en-tête peut apparaître sous la forme d'une ou plusieurs lignes de champ d'en-tête. Les lignes de champ d'en-tête consistent en un nom de champ d'en-tête et zéro ou plusieurs valeurs de champ d'en-tête. Plusieurs valeurs de champ d'en-tête sur une ligne de champ d'en-tête donnée sont séparées par des virgules. Certains champs d'en-tête ne peuvent avoir qu'une seule valeur de champ d'en-tête et, par conséquent, apparaissent toujours sous la forme d'une seule ligne.

  Header Field Value (valeur de champ d'en-tête) : une valeur de champ d'en-tête est une valeur unique ; un champ d'en-tête consiste en zéro ou plusieurs valeurs de champ d'en-tête.

  Home Domain (domaine d'origine) : le domaine fournissant le service à un utilisateur SIP. Typiquement, il s'agit du domaine présent dans l'URI de l'address-of-record d'un enregistrement.

  Informational Response (réponse d'information) : identique à une réponse provisoire.

  Initiator, Calling Party, Caller (initiateur, partie appelante, appelant) : la partie initiant une session (et un dialogue) avec une requête INVITE. Un appelant conserve ce rôle depuis le moment où il envoie l'INVITE initial ayant établi un dialogue jusqu'à la fin de ce dialogue.

  Invitation : une requête INVITE.

  Invitee, Invited User, Called Party, Callee (invité, utilisateur invité, partie appelée, appelé) : la partie qui reçoit une requête INVITE dans le but d'établir une nouvelle session. Un appelé conserve ce rôle depuis le moment où il reçoit l'INVITE jusqu'à la fin du dialogue établi par cet INVITE.

  Location Service (service de localisation) : un service de localisation est utilisé par un serveur de redirection ou mandataire SIP pour obtenir des informations sur les positions possibles d'un appelé. Il contient une liste de liaisons de clés d'address-of-record vers zéro ou plusieurs adresses de contact. Les liaisons peuvent être créées et supprimées de nombreuses façons ; cette spécification définit une méthode REGISTER qui met à jour les liaisons.

  Loop (boucle) : une requête qui arrive à un mandataire, est transférée, et arrive plus tard à nouveau au même mandataire. Lorsqu'elle arrive la seconde fois, son Request-URI est identique à la première fois, et les autres champs d'en-tête affectant le fonctionnement du mandataire sont inchangés, de sorte que le mandataire prendrait la même décision de traitement que la première fois. Les requêtes en boucle sont des erreurs, et les procédures pour les détecter et les traiter sont décrites par le protocole.

  Loose Routing (routage relâché) : un mandataire est dit à routage relâché s'il suit les procédures définies dans cette spécification pour le traitement du champ d'en-tête Route. Ces procédures séparent la destination de la requête (présente dans le Request-URI) de l'ensemble des mandataires à visiter en chemin (présent dans le champ d'en-tête Route). Un mandataire conforme à ces mécanismes est aussi connu sous le nom de routeur relâché.

  Message : données envoyées entre éléments SIP dans le cadre du protocole. Les messages SIP sont soit des requêtes, soit des réponses.

  Method (méthode) : la méthode est la fonction principale qu'une requête est censée invoquer sur un serveur. La méthode est portée par le message de requête lui-même. Des exemples de méthodes sont INVITE et BYE.

  Outbound Proxy (mandataire sortant) : un mandataire qui reçoit des requêtes d'un client, même s'il peut ne pas être le serveur résolu par le Request-URI. Typiquement, un UA est configuré manuellement avec un mandataire sortant, ou peut en apprendre un via des protocoles d'auto-configuration.

  Parallel Search (recherche parallèle) : dans une recherche parallèle, un mandataire émet plusieurs requêtes vers des positions possibles de l'utilisateur après réception d'une requête entrante. Plutôt que d'émettre une requête puis d'attendre la réponse finale avant d'émettre la requête suivante comme dans une recherche séquentielle, une recherche parallèle émet des requêtes sans attendre le résultat des requêtes précédentes.

  Provisional Response (réponse provisoire) : une réponse utilisée par le serveur pour indiquer une progression, mais qui ne termine pas une transaction SIP. Les réponses 1xx sont provisoires, les autres réponses sont considérées comme finales.

  Proxy, Proxy Server (mandataire, serveur mandataire) : une entité intermédiaire qui agit à la fois comme serveur et comme client dans le but de faire des requêtes au nom d'autres clients. Un serveur mandataire joue principalement le rôle de routage, ce qui signifie que sa tâche est de s'assurer qu'une requête est envoyée à une autre entité « plus proche » de l'utilisateur ciblé. Les mandataires sont aussi utiles pour faire respecter des politiques (par exemple, s'assurer qu'un utilisateur est autorisé à passer un appel). Un mandataire interprète, et si nécessaire, réécrit des parties spécifiques d'un message de requête avant de le transférer.

  Recursion (récursion) : un client fait une récursion sur une réponse 3xx lorsqu'il génère une nouvelle requête vers un ou plusieurs des URI dans le champ d'en-tête Contact de la réponse.

  Redirect Server (serveur de redirection) : un serveur de redirection est un agent utilisateur serveur qui génère des réponses 3xx aux requêtes qu'il reçoit, dirigeant le client vers un ensemble d'URI alternatif.

  Registrar (registre) : un registre est un serveur qui accepte les requêtes REGISTER et place les informations reçues dans ces requêtes dans le service de localisation pour le domaine qu'il gère.

  Regular Transaction (transaction régulière) : une transaction régulière est toute transaction avec une méthode autre que INVITE, ACK ou CANCEL.

  Request (requête) : un message SIP envoyé d'un client à un serveur, dans le but d'invoquer une opération particulière.

  Response (réponse) : un message SIP envoyé d'un serveur à un client, indiquant l'état d'une requête envoyée du client au serveur.

  Ringback (ton de rappel) : le ringback est la tonalité de signalisation produite par l'application de la partie appelante indiquant qu'une partie appelée est en train d'être alertée (sonne).

  Route Set (ensemble de routes) : un ensemble de routes est une collection d'URI SIP ou SIPS ordonnés qui représentent une liste de mandataires qui doivent être traversés lors de l'envoi d'une requête particulière. Un ensemble de routes peut être appris via des en-têtes comme Record-Route, ou être configuré.

  Server (serveur) : un serveur est un élément de réseau qui reçoit des requêtes afin de les traiter et renvoie des réponses à ces requêtes. Des exemples de serveurs sont les mandataires, les agents utilisateur serveurs, les serveurs de redirection et les registres.

  Sequential Search (recherche séquentielle) : dans une recherche séquentielle, un serveur mandataire essaie chaque adresse de contact en séquence, passant à la suivante seulement après que la précédente a généré une réponse finale. Une réponse finale de classe 2xx ou 6xx termine toujours une recherche séquentielle.

  Session : d'après la spécification SDP : « Une session multimédia est un ensemble d'émetteurs et de récepteurs multimédia et des flux de données circulant des émetteurs vers les récepteurs. Une conférence multimédia est un exemple de session multimédia. » (RFC 2327 [1]) (Une session telle que définie pour SDP peut comprendre une ou plusieurs sessions RTP.) Telle que définie, un appelé peut être invité plusieurs fois, par différents appels, à la même session. Si SDP est utilisé, une session est définie par la concaténation des éléments nom d'utilisateur SDP, identifiant de session, type de réseau, type d'adresse et adresse dans le champ origin.

  SIP Transaction (transaction SIP) : une transaction SIP survient entre un client et un serveur et comprend tous les messages de la première requête envoyée du client au serveur jusqu'à une réponse finale (non-1xx) envoyée du serveur au client. Si la requête est INVITE et la réponse finale est non-2xx, la transaction comprend également un ACK à la réponse. L'ACK pour une réponse 2xx à une requête INVITE est une transaction distincte.

  Spiral (spirale) : une spirale est une requête SIP qui est routée vers un mandataire, transférée plus loin, et arrive de nouveau à ce mandataire, mais cette fois diffère d'une manière qui entraînera une décision de traitement différente de la requête originale. Typiquement, cela signifie que le Request-URI de la requête diffère de sa précédente arrivée. Une spirale n'est pas une condition d'erreur, contrairement à une boucle. Une cause typique est le transfert d'appel. Un utilisateur appelle [email protected]. Le mandataire example.com le transfère vers le PC de Joe, qui à son tour le transfère vers [email protected]. Cette requête est mandatée de retour vers le mandataire example.com. Cependant, ce n'est pas une boucle. Puisque la requête cible un utilisateur différent, elle est considérée comme une spirale et est une condition valide.

  Stateful Proxy (mandataire avec état) : une entité logique qui maintient les machines à états de transaction client et serveur définies par cette spécification pendant le traitement d'une requête, aussi connu sous le nom de mandataire avec état de transaction. Le comportement d'un mandataire avec état est défini plus loin à la section 16. Un mandataire (avec état de transaction) n'est pas identique à un mandataire avec état d'appel.

  Stateless Proxy (mandataire sans état) : une entité logique qui ne maintient pas les machines à états de transaction client ou serveur définies par cette spécification lorsqu'elle traite les requêtes. Un mandataire sans état transfère chaque requête reçue en aval et chaque réponse reçue en amont.

  Strict Routing (routage strict) : un mandataire est dit à routage strict s'il suit les règles de traitement Route de la RFC 2543 et de nombreuses versions de travail antérieures de cette RFC. Cette règle provoquait la destruction par les mandataires du contenu du Request-URI lorsqu'un champ d'en-tête Route était présent. Le comportement de routage strict n'est pas utilisé dans cette spécification, au profit d'un comportement de routage relâché. Les mandataires effectuant un routage strict sont aussi connus sous le nom de routeurs stricts.

  Target Refresh Request (requête de rafraîchissement de cible) : une requête de rafraîchissement de cible envoyée dans un dialogue est définie comme une requête pouvant modifier la cible distante du dialogue.

  Transaction User (TU) (utilisateur de transaction) : la couche de traitement de protocole qui réside au-dessus de la couche transaction. Les utilisateurs de transaction incluent le cœur UAC, le cœur UAS et le cœur mandataire.

  Upstream (amont) : une direction de transfert de message au sein d'une transaction qui fait référence à la direction dans laquelle les réponses circulent de l'agent utilisateur serveur vers l'agent utilisateur client.

  URL-encoded : une chaîne de caractères encodée selon la RFC 2396, section 2.4 [5].

  User Agent Client (UAC) (agent utilisateur client) : un agent utilisateur client est une entité logique qui crée une nouvelle requête, puis utilise la mécanique d'état de transaction client pour l'envoyer. Le rôle de UAC ne dure que pour la durée de cette transaction. En d'autres termes, si un logiciel initie une requête, il agit en tant que UAC pour la durée de cette transaction. S'il reçoit une requête plus tard, il assume le rôle d'agent utilisateur serveur pour le traitement de cette transaction.

  UAC Core (cœur UAC) : l'ensemble des fonctions de traitement requises d'un UAC résidant au-dessus des couches transaction et transport.

  User Agent Server (UAS) (agent utilisateur serveur) : un agent utilisateur serveur est une entité logique qui génère une réponse à une requête SIP. La réponse accepte, rejette ou redirige la requête. Ce rôle ne dure que pour la durée de cette transaction. En d'autres termes, si un logiciel répond à une requête, il agit en tant que UAS pour la durée de cette transaction. S'il génère une requête plus tard, il assume le rôle d'agent utilisateur client pour le traitement de cette transaction.

  UAS Core (cœur UAS) : l'ensemble des fonctions de traitement requises à un UAS résidant au-dessus des couches transaction et transport.

  User Agent (UA) (agent utilisateur) : une entité logique qui peut agir à la fois comme agent utilisateur client et comme agent utilisateur serveur.

Le rôle de UAC et UAS, ainsi que des serveurs mandataires et de redirection, sont définis transaction par transaction. Par exemple, l'agent utilisateur initiant un appel agit en tant que UAC lors de l'envoi de la requête INVITE initiale et en tant que UAS lors de la réception d'une requête BYE de l'appelé. De même, le même logiciel peut agir en tant que serveur mandataire pour une requête et en tant que serveur de redirection pour la requête suivante.

Les serveurs mandataires, de localisation et de registre définis ci-dessus sont des entités logiques ; les implémentations PEUVENT les combiner dans une seule application.