Le protocole SIP

Introduction

La voix sur IP constitue actuellement l’évolution la plus importante du domaine des Télécommunications. Avant 1970, la transmission de la voix s’effectuait de façon analogique sur des réseaux dédiés à la téléphonie. La technologie utilisée était la technologie électromécanique (Crossbar). Dans les années 80, une première évolution majeure a été le passage à la transmission numérique (TDM).La transmission de la voix sur les réseaux informatiques à commutation de paquets IP constitue aujourd’hui une nouvelle évolution majeure comparable aux précédentes. Comme toutes les nouvelles technologies, la Voix IP présente à la fois risques et opportunités.

Au rang des opportunités.
La perspective de réduction des coûts est souvent citée en premier. Ce sont les communications entre sites distants d’une même entreprise qui sont ciblés.
L’autre atouts de la voix sur IP réside dans sa simplicité de gestion. En supprimant la nécessité actuelle de gérer 2 réseaux indépendants l’un pour la voix, l’autre pour les données, la Voix IP peut simplifier les tâches de gestion et de maintenance des réseaux d’entreprise .

Face à ces opportunités, il y a les risques.
La principale erreur serait que les administrateurs de réseaux informatiques considèrent que la voix étant transmise en paquets IP, il suffit de connecter les équipements Voix IP sur leurs réseaux déjà sécurisés pour rester sécurisé.
En effet, une infrastructure voix IP a des exigences et des contraintes en matière de sécurité et de qualité de service très différentes du trafic de données traditionnelles. La voix IP utilise l’allocation dynamique de port incompatible avec règles de sécurité généralement implémentées sur les pare-feux existants.
De plus la transmission de la voix sur IP exige des délais de transit et une fluidité d’acheminement qui nécessite également d’adapter le réseau existant.
La mise en œuvre de la voix IP nécessite donc des adaptations dont le coût doit être mis en regard des bénéfices attendus. Une mauvaise estimation du coût de ces adaptations peut fausser le bilan du projet et être en fait génératrice de surcoûts.
A tous cela il faut ajouté le fait qu'il est également préférable de choisir un système qui supporte les protocoles standards H323 et SIP ce qui facilitera leur intégration dans un environnement hétérogène existant par exemple ou la possibilité d’acquérir des postes Ip .
Notre choix d'étude vas se porter sur les protocole IP, nous détaillerons les considérations qui nous ont poussée à faire ce choix tous en apportant une compréhension au fonctionnement de ce protocole.

Standardisation SIP (Session Initiation Protocole)

H.323 possède une grande maturité que lui confère son avance et ses nombreuses expérimentations mais sa gestion est laborieuse de plus H.323 et mal adaptée au monde d'internet. Tandis que SIP est extrêment simple même à grand échelle de plus il a été conçu pour s'adapter à internet en particulier pour que le réseau supporte des montées en charge du nombre d'utilisateurs.

Pourrais-tu expliquer comment SIP s'y prend ?

Tous simplement parce que l'architecture de SIP repose sur plusieurs serveurs distincte, qui distribuent la charge du réseau en communiquant entre eux. De plus en cas de besoin, il suffit d'ajouter des serveurs disposant de fonctions dédiées pour collaborer avec ceux déjà en place. Ce qui confert à SIP une bonne évolutivité et flexibilité puisqu'on fonctionne un peu à la manière Orienté Objet.
SIP → Protocole de signalisation pour

  1. l'établissement
  2. le maintient
  3. la modification
  4. le gestion
  5. la fermeture

de sessions interactives entre utilisateurs pour la téléphonie et la vidéoconférence et plus généralement pour toutes les communications multimédia.
Il est à noter que le protocole SIP n'assure pas le transport des données utile sa fonction est d'établir la liaison entre interlocuteurs => assure simplement la signalisation.
De plus SIP se situe au niveau 7 de la couche d'OSI (la couche applicative) et fonctionne selon une architecture client-serveur.

Compatibilité

SIP s'intègre facilement avec d'autre protocoles standard du monde IP. Il a été conçu et prévu pour fonctionner avec différents applications parmi eux il y a

  1. la téléphonie
  2. la messagerie instantanée
  3. la vidéoconférence
  4. la réalité virtuelle
  5. les jeux vidéo

Un autre élément important concernant la compatibilité de SIP, c'est la possibilité d'utiliser SIP en conjonction avec d'autres protocoles qui caractérise SIP. En d'autre terme SIP peut se déployer se déployer ou s'intégrer aux différents protocoles suivants :

  • RTP => protocole qui se charge du transport des flux temps réel
  • RTCP => protocole qui fournit des informations dynamiques sur l'état du réseau.
  • RTSP => protocole pour contrôler la diffusion de flux multimédias en temps réel.
  • SDP => protocole qui founit la descfription d'une sessio, c'est-à-dire qu'il fournit les paramètres utiliser dans une communication SIP.
  • SAP => protocole pour la communication multcast, elle permet d'ajouter les spécifications d'une nouvelle session.
  • MIME => standard pour les descriptions de contenus , utilisé sur Internet.
  • RSVP => pour obtenir des garanties de qualité de service et effectuer des réservations de ressources.
  • HTTP => pour le traitement des pages web sur Internet.
  • MGCP => pour le contrôle des passerelles assurant la connectivité entre un réseau IP et un réseau téléphonique.

Bien que tous ces protocoles sont différents de SIP, ils n'intérfèrent pas avec la signalisation, ce qui fais que leur utilisation conjoint est possible sans pour autant être indispensable au bon fonctionnement de SIP. En d'autre terme chacun est indépendant mais collabore entre eux si besoin ce fais sentir.

Modularité

L un des objectifs que les concepteurs de SIP on poursuivie, c'étais de faire en sorte que SIP constitue une brique de base pouvant se combiner avec le maximum de protocoles tout en ayant une grand indépendance par rapport à lla couche de transport.
Ce qui fait que TCP et UDP sont très bien supporté pour l'envoi de messages SIP, chacun avec ses avantages et ses défauts. Nous allons juste touché un mot sur les avantages de ses protocoles avec SIP.

  • T.C.P. → Meilleur traversée des pare-feu qu'avec UDP (oui comme vous venez certainement de vous en doutez, SIP peut rencontrer des problèmes avec les parmètres de sécrité d'un réseau mais nous en parlerons dans la troisième partie de ce dossier )
  • U.D.P. → SIP à un meilleur contrôle sur les transmissions des messages et par conséquence sur l'enchaînement des messages. (Tous cela vas devenire plus claire dans les prochains chapitre)

Simplicité

SIP utilise un langage textuel très proche des protocoles HTTP et SMTP ce qui confère à SIP une très bonne intégrations à internet.
Avantages du langage textuel

  1. Il est interprété et non compilé d'où traitement des commandes plus rapide.
  2. L'implémentation de nouveau services ne nécessitent pas de compilateur pour interpréter les commandes.
  3. Facilité de maintenance des services et d'implémentation de nouveaux services.

Avantage de la simplicité de SIP

  • Le protocole est facile à embarquer dans les composants léger dotés de capacité réduites. De plus son implémentation est peu gourmande en ressources de traitement.

Architecture de SIP

Le protocole SIP s'appuie sur une architecture purement logicielle. Cette architecture s'articule autour de 5 entités, à savoir :

  1. Terminal utilisateur
  2. Serveur d'enregistrement
  3. Serveur de localisation
  4. Serveur de redirection
  5. Serveur Proxy

On peut distinguer 2 catégories (2 classes)

Les serveurs de redirection et proxy Qui facilitent le routage des messages de signalisation (redirection) et jouent le rôle d'intermédaire (proxy)
Les serveurs d'enregistrement et de localisation Qui ont pour fonction d'enregister ou de déterminer la localisation des abonnés du réseau.

Nous allons au cours de chapitre nous concentrer sur la compréhension et le rôle de ces 5 entités.
L'objectif ici est d'avoir une vue d'ensemble afin de pouvoir diagnostiquer des solutions ou suggérer des améliorations d'une architecture ToIP fonctionnement sous le protocole IP.

Le Terminal

Le terminal se trouve du coté des utilisateurs et a pour principale fonction de permettre à l'utilisateur d'appelé où d'être appelé.
Il peut se présenter sous deux formes :

  1. soit un composant physique (hardphone)
  2. soit un composant logiciel (softphone), en d'autre terme sous forme d'une application informatique.

Ça c'est pour le domaine visuelle mais d'un point de vue technique le terminal qu'on appel techniquement UA (User Agent) se compose de deux sous-entités :

UAC (User Agent Client) UAS (User Agent Server)
C'est la partie qui émet les appels Ou dans un langage plus technique, c'est la partie qui émet les requêtes C'est la partie qui reçois les appels.Ou dans un langage plus technique, c'est la partie qui trait les requêtes

Les échanges qui ont lieu entre un UAS et UAC (de préférences entre terminaux différent sans quoi nous risquons de nous trouver dans le cas de figure d'un terminal qui s'appel lui-même) constitue un dialogue.
Nous reviendrons plus tard sur ce qui se passe lors d'envoie de messages entre UAC et UAS appartenant à des UA différents.

Serveur d'enregistrement

Il est possible que deux U.A. Communique entre eux directement mais cela sous entendrais

  1. que chaque UA connaisse l'adresse IP de son correspondant
  2. que les adresses IP des ses deux UA ne change pas fréquement voir jamais, il serait donc préférable d'avoir une adresse fixe mais vue la conjoncture actuelle des adresses Ipv4 ça risque d'être compliqué de tous avoir une adresse IP fixe. Ok vous me direz et les adresses Ipv6. Mais pour le moment oublions les un peu juste le temps de comprendre l'importance du serveur d'enreistrement.

Comme nous pouvons le constater ces contraintes peuvent se réveller fastidieuse et source de beaucoup de porblèmes, surtout si le nombre de terminaux clients passe par miracle de 2 à 1000 terminaux où même plus.
La solution serait d'avoir un serveur d'enregistrement (Registrar Serveur) qui offre un moyen de localiser un correspondant avec souplesse tout en gérant la mobilité d'un utilisateur, de plus il peut supporter l'authentification des abonnés.

Euh !!! je n'ai pas très bien compris sont fonctionnement .

Ok prenons le cas de figure suivante :
Imaginons que nous avons un terminal client qui s'active dans un réseau IP, ce terminale vas commencer par transmettre une requête d'enregistrement au serveur d'enregistrement, cette requête aura pour objectif d'indiquer la présence et la position de la localisation courante de l UA dans le réseau.
Ensuite le Serveur d'enregistrement vas sauvegarder cette position en l'enregistrant auprès du serveur de localisation.

Serveur de localisation

Ce serveur contient la base de données de l'ensemble des abonnés qu'il gère. Cette base de donnée est renseignée,comme nous venons de le voir, par le serveur d'enregistrement. Ce qui fait que par leur comportement complémentaire, il arrive souvent que le serveur d'enregistrement et le serveur de localisation soient implémenter au sein d'une même entité.

Serveur de redirection

Le serveur de redirection (Redirect Server) agit en fait comme un intermédiaire entre le terminal du client et le serveur de localisation.

Pourrais-tu être un peu plus explicite STPl ?

Ok reprenons notre histoire du terminal qui s'active dans le réseau que nous avons vue plus haut et adaptons l'histoire pour mettre en évidence le rôle du serveur de redirection.
Imaginons pour une raison inconnue et sans importance pour le moment, que les administrateurs du réseau IP de notre terminal client ne souhaite plus communiquer l'adresse IP du serveur localisation.
Comme nous l'avons déjà vue le serveur de localisation peut être assimilé à une gros basse de données fournissant les informations de localisation de ses abonnées d'où gros problème.
La solution à cette situation serait de placer un serveur de redirection auprès duquel le terminal client devra adresser ses requêtes de localisation pour connaître la position courante d'un utilisateur qu'il souhaite joindre ainsi le terminal client n'aura plus besoin de connaître l'adresse IP du serveur de localisation.

Serveur Proxy

Le serveur proxy est souvent appelé serveur mandataire à cause du rôle qu'il joue au sein d'une architecture, car il permet d'initier une communication à la place de l'appelant.
Il agit en fait pour le compte de l'appelant tous en remplissant les fonctions suivantes :

  1. localiser un correspondant
  2. réaliser éventuellement certains traitement sur les requêtes
  3. initier, maintenir et terminer une session vers un correspondant.

On distingue deux types de serveur proxy

  1. Proxy statefull → il maintient pendant tout la durée de la sessions l'état des connexions
  2. Proxy stateless → il ne sauvegarde aucun état de la connexion il s'occupe juste d'acheminer les messages indépendamment les uns des autres.

Mise en place de serveurs SIP

Il existe beaucoup de logiciels capable d'implémenter les divers fonctionnalités des différents serveurs SIP que nous venons de voir.
Nous allons juste en mentionner deux sous licence GPL et LGPL et fonctionnent exclusivement sur la plate forme Linux.

  1. SIP Express Router
  2. Partysip SIP Proxy Server

Il est à mentionner aussi que le nom de ses deux logiciels est trompeur, car chacun de ses logiciels est capables d'assurer le rôle des 4 serveurs que nous venons de voir.
En outre, ils peuvent déliver plusieurs services complémentaires comme :

  • l'authentification avec support de Diamètre ou Radius
  • la création de journaux d'activité (en le couplant à une base SQL)

Comment se connecter à des réseaux non-IP

Comme nous l'avons déjà vue SIP a été conçu initialement pour les réseaux à commutation de paquets de type IP.
Mais ceci dit beaucoup de ses utilisateurs souhaitent être joignable où soit joindre des terminaux qui sont connectés à des réseaux de natures différents.
Malheureusement SIP ne fournit pas de solution à cela et pour y parvenir il faut faire intervenir une entité tiers qui jouera le rôle de passerelle et qui aura pour fonction d'assurer la conversion des signaux d'un réseaux à un autre.
Nous verrons dans la seconde partie du rapport le protocole MGCP qui propose une manière de gérer ces fonctionnalités.
Mais pour l'heure content-t-on nous de savoir que la communication entre le monde IP et non-IP est possible uniquement en présence d'une entité intermédiaire qu'on appel passerelle (gateway) et que le protocole MGCP (Média Gatewway Control Protocol) à été conçu spécialement pour jouer se rôle.

L'adressage IP

File conducteur de ce chapitre

Pour pouvoir localiser un utilisateur il faut pouvoir l'identifier de manière univoque.
SIP propose des moyens très performants pour nommer les utilisateurs
Nous allons voir le concepts d'URI qui rassemble tous ses moyens d'identification.

Qu'est ce qu'une U.R.I. (Universal Ressource Identifier) ?

Une URI définit une syntaxe permettant de désigner de manière

  • univoque
  • formelle
  • normalisée

une ressource.

Cette ressource peut très bien un document textuel, audio, vidéo .
D'une manière plus généralisé nous pouvons dire que cette ressources peut être une entité logique ou une entité physique.
Mais peu importe la nature de cette ressource et peut importe que cette ressource soit déplacé ou supprimé, l'URI correspondant à cette ressource conservera de manière permanent la valeur descriptive de cette ressource.

Euh je n'ai pas tous saisie, en plus ça fais très académique ton explication. Est ce que tu pourrais rendre moin abstrait ton explication ?

Ok, nous allons prendre un cas de figure de la vie de tous les jours pour faire une analogie avec le concept d'URI.
Prenons par exemple, deux personnes issue de la même famille et portant le même prénom.
(A première vue cette exemple peu sembler bizarre mais suivez le raisonnement jusqu'au bout vous allez comprendre ou nous voulons en venir ).
Donc compte tenue du fait que ses deux personnes sont identifiables par le même couples d'informations (Nom/Prénom) si jamais nous sommes amené à faire une recherche dans un annuaire on serait susceptibles de les confondre. Il faudrait donc trouver une solution pour pouvoir les identifier sans aucun ambiguïté.

Oui, mais si on ajoute d'autre identifiant comme l'age, la localisation, la profession. Est-ce que ça ne résous pas le problème de doublon que tu viens de présenter ?

Dans notre domaine d'application la réponse est :
non ça ne résous pas notre problème
la raison à cela est que ce sont tous des paramètres susceptibles d'évoluer et qui par conséquence ne constituent pas des propriétés discriminantes.
La véritable solution à notre problème serait d'attribuer un identifiant unique à chaqu'un de nos individus afin d'assurer une identité unique et ainsi nous permettre de les différencier avec certitudes. En d'autre terme le couple Nom/Prénom ne peut pas être utilisé et c'est donc elle la source de notre problème, il faut donc opter pour un meilleur choix.

Mais lequel ?

Vous ne trouvez toujours pas. Bon nous allons vous donner deux solutions en rapport avec la vie courante.

La première solution serait d'utiliser un numéro de sécurité sociale pour identifier nos deux individus.
La seconde solution serait de faire usage d'une adresse e-mail.

Ok mais je ne vois toujours pas quel est le lien entre les deux solutions que vous venez de présenter et le concept d'URI ?

Le lien avec le concept d'URI c'est que le numéro de sécurité sociale tous comme une adresse e-mail sont à la syntaxe près une forme d'URI permettant de désigner de manière unique une entité.
En d'autre terme une URI est un identifiant unique et réciproquement tous chaîne de caractères permettant d'identifier de manière unique une ressource est une URI.

J'ai compris !!! c'est donc identique aux URL (Unifrom Ressource Locator) que l'on manipule couramment dans l'adressage web pour joindre un site Internet ?

Non non et non. Une URL n'est pas identique à une URI mais correspond en faite à un sous-ensemble d'une URI.
Une URL à pour fonctions :

  1. de spécifier une méthode permettant d'accéder à une ressource (par exemple http,ftp)
  2. de spécifer une localisation relative à une ressource (par exemple : www.maressource.com)

Ce qui fait qu'une URL à environ que 40~50% des compétences d'une URI. Car une URI peut faire bien plus, elle peut identifier de manière unique une entité.
Vous vous demandez certainement pourquoi tous ce blabla sur le concept d'URI ce qui nous intéresse c'est de comprendre comment fonctionne SIP.

Euh pour dire vrai, je me disais que la prochaine fois j'éviterais de poser des questions .

Format des adresses SIP

Tout utilisateur SIP dispose d'un identifiant unique.
Cette identifiant vas constituer l'adresse de l'utilisateur ce qui nous permettra de le localiser.

Vous comprenez maintenant pourquoi la compréhension du concept d'URI s'avère important pour saisir l'importance et le rôle du format des adresses SIP.

Nous allons donc maintenant vous présenter et expliquer les différents parties du format des adresses SIP en partant de la syntaxe générale d'une adresse IP.

SIP : Identifiant [: Mot-De-Passe] @ Serveur [? paramètres]
Le mot-clé SIP spécifie le protocole à utiliser pour la communication La partie identifiant est nécessairement unique pour désigner l'utilisateur de manière univoque. La partie Mot-De-Passe est facultative et est le plus souvent utilisé pour s'authentifier auprès d'un serveur notamment à des fins de facturation. arobase La partie serveur spécifie le serveur chargé du compte SIP dont l'identifiant précède l'arobase. C'est ce serveur qui sera contacté pour joindre l'abonné correspondant. La partie paramètres est facultative. Les paramètres permettent soit de modifier le comportement du serveur (par exemple en utilisant un port différent de celui par défaut) soit de spécifier des informations complémentaires (par exemple la raison d'un appel) .

Localisation et résolution d'une adresse SIP

A la vue de la syntaxe générale d'une adresse IP, nous pouvons légitiment dire que d'une manière générale une adresse SIP se compose d'un champ utilisateur et d'un nom de domaine.

Par conséquent pour localiser un utilisateur, il faut d'abord contacter le serveur gérant le domaine puis solliciter ce serveur pour déterminer la position de l'utilisateur.

Rappelez-vous, que nous avons vue ensemble le serveur de localisation et aussi le serveur de redirection.
Nous allons donc pas plus nous attarder sur le sujet de localisation mais allons voir les différents format utiliser pour identifier un domaine afin d'introduire en scène une nouvelle entité, le serveur DNS, ce serveur n'a rien à voir avec les 5 entités, vue dans la chapitre 2, mais il s'avère utile dans une architecture VoIP.

Le nom de domaine peut se présenter sous deux formats différents :

  • Soit nous avons une adresse IP alors le serveur est joignable directement.
  • Soit nous avons une chaîne de caractère du genre « monserveur.org » alors l'adresse IP du serveur sera déterminée après une résolution DNS.

Voilà ce troisième chapitre touche à sa fin mais avant d'entamer le prochain chapitre nous aimerions mettre en évidence les avantages de l'adressage SIP sans trop rentrer dans des considérations techniques.

Avantages de l'adressage SIP

Nous allons nous concentrer sur deux avantages concernant les adressages SIP

  1. L'adressage est indépendant de la localisation géographique de l'abonné. C'est là l'un des grands avantages dont tire profit les utilisateurs, à savoir la mobilité. En effet SIP à été conçu pour permettre de joindre quelqu'un avec une adresse SIP unique, quels que soient sa localisation et son terminal.
  2. Un utilisateur peut avoir plusieurs adresses SIP aboutissant toutes au même terminal. A première vue on pourrait croire que ses superflues à l'instar des gens qui se promènent avec plusieurs GSM sur eux. Mais en réalité ce n'est pas le cas et pour mieux nous faire comprendre rien de tel qu'un exemple pour illustrer notre penser.

Prenons par exemple le cas de figure d'un indépendant travaillant à son domicile et ne possédant qu'un seul terminal.
Cette indépendant souhaite être joignable par ses clients uniquement pendant la semaine (Lundi → Vendredi) .
Une solution pour lui serait de faire en sorte que son terminal soit référencer sur deux adresses distinctes, il lui sera alors possible d'activer la messagerie de son compte personnel pendant son travail (afin de son concentrer sur ses clients et son travail) tandis que le week-end il pourrait rediriger tous ses appels professionnel vers un centre de permanence.

Les messages SIP

Cette chapitre détaille le « langage SIP » afin de montrer comment s'effectuent les communications entre les interlocuteurs.
Les objectifs de ce chapitre sont double car il vise à fournir les bases de compréhension pour écrire une application SIP tout en offrant la possibilité de comprendre comment décrypter les échanges entre intervenants.

Notion de transaction

Une communication est constituée d'une succession de transactions qui ont lieu par le biais d'échanges de messages.
Les messages peuvent être de deux natures :

  • soit des requêtes
  • soit des réponses aux requêtes.

Mais peut import la nature d'un message, celui-ci doit toujours respecter ce type de format:

Ligne de requête ou d'état
En-tête
Corps du message

Nous allons voir plus en détails en détails les éléments constitutif d'un messages mais avant cela nous allons aborder un sujet qui vas s'avérer important pour décrypter les échanges enter intervenants.

Le champ VIA

Le champ VIA a pour objectif d'indiquer le chemin parcouru par un message entre un émetteur et son récepteur.
Mettons nous d'accord sur ce que nous entendons par chemin.
Un chemin désigne l'ensemble des nœuds intermédiaires par lesquels transite le message.

Oui mais concrètement comment fonctionne ton champs VIA, parce que la tous nous fournie juste des définitions ?

Eh ben quel surprise et nous qui pensions que t'avais décidé de ne plus poser des questions suites à ta dernière intervention.

J'ai changé d'avis, pourrais-tu répondre à ma question maintenant STPL ?

Nous allons pour rendre tous cela un peu plus claire prendre le scénario basique d'un terminal envoyant un message à un autre terminal.

Ce message vas suivre un chemin, constituée de nœuds, jusqu'à atteindre sa destination.
Vous pouvez voir les nœuds comme des gare et voir le message comme un train fessant escale dans chaque gare. Bien entendue ces très académique comme illustration car le routage d'informations est bien plus complexe que cela mais nous n'entrerons pas dans ce sujet.

Ceci dit, chaque nœud qui reçoit le message, lors du premier passage c'est-à-dire dans la direction terminal émetteur → terminal récepteur, vont l'enrichir avec un champ VIA possédant son numéro de noeud_de_transit et si un nœud détecte que son numéro de noeud_de_transit est déjà présent dans message il vas en déduire qu'une boucle à eu lieu et vas tenter d'en avertir l'émetteur ou tenter une autre route.

Une fois le message arrivé à destination, le terminal récepteur se doit d'y répondre et pour se faire, il vas utiliser le champs VIA pour retracer le chemin inverse ainsi le message suivra la même route (plus besoin de gérer des états des liens de chaque connexion dans les serveurs proxy).

Et finalement pendant le chemin de retour chaque noeud recevant le message vont retirer leur champ VIA .

Exemple de champs VIA:
via : SIP / 2.0 / TCP noeud_de_transit : 12345

Bon maintenant que nous avons vue comment voyage un message nous pouvons nous concentrer sur les éléments constitutifs d'un message.

Notre étude partira du bas du tableau et nous allons étudier chaque champs .

Ligne de requête ou d'état
En-tête
Corps du message

Corps du message

Le corps d'un message SIP contient le descriptif complet des paramètres de la session concernée.
Parmi ces paramètres nous trouvons les informations suivantes :

  1. Informations générales sur la session tel que le nom, la date, l'objet de la session.
  2. Informations sur l'émetteur du message tel que le nom, l'e-mail, le numéro de téléphone.
  3. Informations réseau tel que les ressources nécessaire, le protocole, le port utilisé.
  4. La liste des flux multimédias utilisé comme l'audio, la vidéo, le texte.
  5. La liste des codages supportés (G 711, G 723, …) .
  6. Des informations de sécurité tel que le type de cryptage utilisé.

Tous ses informations ont pour but principal de permettre aux différents terminaux de se mettre d'accord sur la compatibilité des différents échanges qui auront lieu.

En-tête

Les en-têtes les plus couramment utilisés dans les messages SIP sont les suivants.

  1. En-tête généraux car elles ne sont pas spécifique à un type de message contrairement au 3 en-tête suivante.
  2. En-tête de requêtes, exclusivement employés pour les messages de requête.
  3. En-tête de réponse, exclusivement employés pour les messages de réponses.
  4. En-tête d'entité, exclusivement employés pour donner des informations descriptives sur le corps du message.

Ligne de requête ou d'état

Comme vous pouvez le constater deux cas de figure peuvent se présenter à nous :

  • soit nous avons affaires à un messages de type requête
  • soit nous avons affaires à un messages de types d'état.

Nous allons donc les étudier séparément.

Les requêtes SIP

La partie définissant la ligne de requête se compose de 3 champs

Ligne de requête
Méthode
URI
Version du protocole

Le concept d'URI ayant déjà été vue nous nous concentrerons sur la compréhension des deux autres champs.

Version du protocole

Le champs version du protocole a pour principale fonction de permettre aux différents entités traitent le message SIP de savoir si ils sont compatibles ou non.

En d'autre terme la compatibilité entre émetteur/récepteur n'est effective que si la version est strictement identique.
Actuellement, c'est-à-dire en 2010, nous en sommes à la version 2.0.

Au niveau syntaxique l'indication de la version doit se faire en spécifiant le mot-clé SIP suivi d'un espace puis du numéro de la version.

Exemple : SIP 2.0

Les méthodes d'une requête SIP

SIP n'utilise que 6 méthodes fondamentales pour formuler ses requêtes à ses 6 méthodes ont été rajoutées des méthodes supplémentaires destinées à apporter divers améliorations.

D'un point de vue technique ce qui distingue les méthodes fondamentals des méthodes supplémentaires c'est leurs implémentations par les différents entités.

En d'autre termes les méthodes fondamentales doivent être supportées par tous les terminaux et serveurs sollicités contrairement aux méthodes supplémentaires.

Les 6 méthodes fondamentales

  1. Invite : Cette méthode permet d'initier une communication en y invitant un ou plusieurs participant(s). Une autre utilisation de cette méthode consiste à renégocier dynamiquement de nouveaux paramètre de session. Par exemple, si durant une session déjà établie, l'un des interlocuteurs souhaite enrichir la voix par de la vidéo, il peut le faire via une requête d'invitation.
  2. ACK : Cette méthode sert à confirmer les paramètres de session, elle peut être utilisé dans 2 cas de figure :
          • soit elle fait suite à l'acceptation d'un appel par l'appelé
          • soit elle fait suite à une réponse de localisation fournie par un serveur de redirection.
  3. Options : Cette méthodes permet d'interroger un serveur SIP, y compris l'entité UAS sur différentes information. Cette méthode se compose globalement de deux volets, l'état du serveur et ses capacités. Avec cette méthode il est possible d'obtenir des informations sur un serveur concernant le types de média, le codecs supporté .
  4. BYE : Cette méthode permet de terminer une session et par conséquence de libérer une communication. Les deux grandes particularités de cette méthodes sont que : cette requête peut-être émise indifféremment par l'appelant ou par l'appelé et que cette requête n'attente pas d'acquittement.
  5. Cancel : Cette méthode contrairement à ce qu'on pourrait penser n'interrompe pas une session mais elle indique tous simplement qu'un réponse n'est plus attendue et qu'il n'est donc pas nécessaire de traiter la requête.
  6. Register : Cette méthode permet d'enregistrer son adresse IP auprès d'un serveur d'enregistrement. Cette enregistrement aura une durée de vie limité dans le temps d'où le fait que chaque terminal doit périodiquement rafraichir cette entrée, sous peine de voir le serveur de localisation la supprimé de sa base de donnée. Par défaut la durée est d'une heure.

Il les est important de signaler ici que cette adresse IP sera utile pour faire une correspondance avec l'adresse SIP et par conséquence d'assurer le service de localisation.

Les réponses SIP

La partie définissant la ligne d'état se compose de 3 champs.

Ligne d'état (réponses à la requête)
Version
Code d'état
Raison

La compréhension du champs version étant déjà vue elle ne sera donc pas abordé.

Raison

C'est un message textuel expliquant brièvement le code d'état de la réponse.

Code d'état d'une réponse SIP

C'est un code numérique à 3 chiffres spécifiant la réponse donnée à la requête.
Il existe 6 classes de réponse dans lesquelles sont répertoriés tous les messages de retour possible.

Les 6 classes d'une réponse SIP

  1. La classe 1xx : Messages d'informations. => Cette classe a pour objectif d'indiquer qu'une requête est en cours de traitement en d'autre terme c'est une réponse temporaire qui est purement informative.
  2. La classe 2xx : Messages de succès. => Cette classe a pour objectif d'indiquer qu'une requête a bien été reçu, qu'elle est comprise et acceptée par le serveur.
  3. La classe 3xx : Messages de redirections. => Cette classe à pour objectif de décrire qu'une autre action doit être effectuer avant de finaliser la requête. On y retrouve généralement des informations sur un service proposé ou imposé pour satisfaire l'appel. Par exemple : une de classe 3xx peut être envoyé à l'appelant pour l'obliger à utiliser un proxy pour pouvoir contacter l'appelé.
  4. La classe 4xx : Messages d'erreurs. => Cette classe est loin la plus grosse des 6 classe et rassemble :
          • des erreurs du client (exemple : si l'appelé est occupé et ne peux prendre l'appel)
          • des erreurs de requêtes ne pouvant être prise en charge (exemple une requête qui nécessite un temps de traitement trop long)
          • des erreurs de syntaxe (exemple si un serveur ne supporte pas la forme de l'URI indiqué dans la requête)
  5. La classe 5xx : Messages d'erreur du serveur => Dans cette classe se trouve tous les codes d'état indiquant qu'une requête ne présent pas d'erreur mais c'est plus tot serveur qui n'arrive pas à la traiter. Généralement ceci peut être du au faite que le service n'est plus disponible sur le serveur sollicité.
  6. La classe 6xx : Messages d'échec général. =>Ici ce n'est pas un serveur mais tous les serveurs qui ne peuvent pas traiter la requête. Ceci peut être du au faite qu'ils sont tous occupé, inaccessibles ou tous simplement parce qu'ils refusent tous l'appel.
Sauf mention contraire, le contenu de cette page est protégé par la licence Creative Commons Attribution-ShareAlike 3.0 License