Etude d'implémentation d'une solution VOIP sécurisée dans un réseau informatique d'entreprise. Cas de l'ISTA de Kinshasa

II.4.1.7 SCENERIOS DE COMMUNICATION

Nous allons illustrer la succession chronologique des messages de requêtes et de réponses dans les six scénarios classiques suivants :

1. Initialisation d'une communication directe ;

2. Enregistrement d'un terminal ;

3. Initialisation d'une communication avec un serveur proxy ;

4. Localisation par un serveur de redirection et initialisation d'appel directe ;

5. Modification dynamique d'une communication SIP ;

6. Terminaison d'une communication.

1. Initialisation d'une communication directe

Une communication peut s'effectuer directement entre deux correspondants, sans faire intervenir d'autres entités.

55

Dans ce cas, l'appelant doit connaître la localisation (sous forme d'adresse IP) de la personne qu'il souhaite contacter. La figure II.9 illustre ce scénario.

^{Terminal SIP}

^Appelant

^(UAC)

^{Terminal SIP}

^Appelé

^(UAS)

^Invite

¹⁸⁰

^RINGING

^{200 OK}

^ACK

^{Flux multimédia(audio, vidéo, texte..)}

Initiation d'une communication directe
Figure II.9 : Initiation d'une communication directe

Cette communication reflète la simplicité d'utilisation du protocole SIP. Quatre étapes seulement suffisent pour mettre en relation les deux utilisateurs :

¹

1. l'appelant (UAC) envoie un message (requête INVITE) proposant à son correspondant (UAS) d'initier une communication. Ce message contient les paramètres désirés pour établir la communication ;

2. dès que l'UAS reçoit le message, il en informe l'utilisateur appelant (le téléphone sonne, avec indication de l'appelant et du motif de son appel s'il a renseigné ce champ, ainsi que des services disponibles). Dans le même temps, il indique à l'appelant (par une réponse provisoire 180 RINGING) que l'appelé est en train d'être averti de l'appel ;

3. dès que l'appelé accepte l'appel (en décrochant), l'UAS informe l'appelant (par une réponse définitive 200 OK) que l'appel peut débuter. Ce message contient les paramètres que l'UAS supporte pour la session ;

4. l'UAC retourne à l'UAS un message d'acquittement (requête ACK) lui indiquant qu'il a pris note que l'appel peut débuter. Ce message comporte les paramètres fixés pour la session, qui tiennent compte de ces possibilités et de celles de l'UAS. Les intervenants sont ensuite mis en relation et peuvent communiquer.

56

2. Enregistrement d'un terminal

Lorsqu'un terminal est activé dans un réseau, sa première action consiste à se déclarer auprès d'un serveur d'enregistrement, de manière à être disponible si un appelant souhaite le joindre. Ce scénario est illustré à la figure II.10.

Figure II.10 : Enregistrement d'un terminal SIP

Le serveur de localisation maintient dans sa base de données une entrée associant l'identifiant d'un utilisateur avec sa position dans le réseau (adresse IP du terminal de l'utilisateur, port utilisé par l'application SIP et identifiant de l'utilisateur sur ce poste).

3. Initialisation d'une communication SIP avec un serveur proxy

Les étapes et messages envoyés pour initier une session entre deux correspondants dans le cas où un proxy est utilisé sont illustrés à la figure II.11. Dans cet exemple, Anne souhaite ouvrir une session avec Brigitte. Comme elle ne connaît pas la localisation de cette dernière, elle sollicite son proxy afin de la déterminer.

Figure II.11 : Initialisation d'un appel avec un proxy

57

Les étapes suivantes sont nécessaires :

1. Anne compose sur son terminal l'adresse SIP de Brigitte. Cette dernière n'est pas nécessairement une adresse IP, mais peut être un identifiant qu'il faut résoudre. Un message d'invitation (requête INVITE) est envoyé de l'UAC d'Anne vers son serveur proxy SIP. L'adresse du proxy d'Anne peut être configurée sur son terminal ou être automatiquement distribuée, par DHCP par exemple. À la réception de ce message, le serveur proxy d'Anne utilise la partie domaine de l'adresse SIP de Brigitte pour déterminer le serveur en charge de la gestion du compte de Brigitte (c'est-à-dire en charge du domaine de Brigitte). À cette fin, un serveur DNS peut être sollicité pour localiser le serveur proxy de Brigitte. En parallèle, le serveur proxy informe Anne qu'il prend en charge la requête et tente de la mettre en relation. La réponse temporaire 100 TRYING indique à cette dernière que le message a été reçu et qu'il est en cours de traitement ;

2. Routage du message d'invitation. Le serveur proxy d'Anne transmet l'invitation au serveur proxy de Brigitte après l'avoir localisé. C'est le message d'invitation original qui est intégralement relayé du proxy d'Anne vers celui de Brigitte. La seule modification apportée au message par le premier serveur proxy concerne le champ VIA, qui liste l'ensemble des machines parcourues lors de l'acheminement du paquet, et auquel il ajoute sa propre adresse réseau (en plus de celle d'Anne, qui y figure initialement) ;

Le serveur proxy de Brigitte informe le serveur proxy d'Anne (par un message de réponse temporaire 100 TRYING) de la réception de la requête et de la tentative d'initialisation. Parallèlement, il recherche la localisation du terminal de Brigitte en utilisant le service de localisation. Une fois la position du terminal dans le réseau trouvée, il lui transmet l'invitation d'Anne. À nouveau, ce message est conforme à l'original, et seul le champ VIA a été enrichi de l'adresse du serveur proxy de Brigitte ;

3. Le terminal de Brigitte sonne,(éventuellement un softphone) et reçoit l'invitation et la fait connaître à l'utilisateur Brigitte, le plus souvent par une sonnerie. En parallèle, il indique à son proxy (par un message 180 RINGING) que l'appel est en train d'être notifié à Brigitte et que la communication est en attente de son acceptation. Ce message informatif est relayé jusqu'à l'émettrice Anne, qui reçoit généralement un retour audio ou visuel (une tonalité de sonnerie particulière le plus souvent). L'utilisation du champ d'en-tête VIA permet de remonter de proche en proche jusqu'à Anne selon le même chemin ;

4. Brigitte répond au téléphone. On suppose le cas où Brigitte a choisi de répondre à l'appel. À l'instant où elle décroche, l'UAS retourne à l'UAC un message 200 OK pour l'informer que l'appel est accepté. Ce message est relayé par les différents proxys. À ce stade, la communication n'a pas encore débuté, et aucun son n'est transmis ;

58

5. Le terminal d'Anne confirme les paramètres d'appel. En tenant compte des capacités prises en charge par les correspondants, le terminal d'Anne envoie un message d'acquittement ACK qui spécifie les paramètres définitifs à utiliser lors de cette session. Notons que le message d'acquittement peut passer directement d'un interlocuteur à l'autre, sans transiter par les serveurs proxy. À ce stade, chacun des utilisateurs a pu apprendre la localisation exacte de son interlocuteur, et il n'est donc plus nécessaire de recourir aux serveurs proxy. Toutes les transactions qui suivent sont effectuées directement, de poste utilisateur à poste utilisateur.

Ainsi, les serveurs proxy sont sollicités au minimum. De la même manière, pour ne pas saturer les serveurs proxy inutilement, les flux de données multimédias ne transitent jamais par eux.

À la réception de ce message, la communication entre les interlocuteurs peut débuter. Tous ces échanges n'ont réclamés que quelques millisecondes, imperceptibles pour les intervenants.

Globalement, on retrouve dans cet appel, les trois phases fondamentales de l'appel direct entre les correspondants :

1. Requête INVITE : invitation de l'appelant ;

2. Réponse 200 OK : acceptation par l'appelé ;

3. Acquittement ACK : confirmation par l'appelant.

Il s'agit des trois messages nécessaires à la modification dynamique d'une communication SIP. Les autres messages concernent essentiellement la localisation ou sont à titre informatif.

59

4. Localisation par un serveur de redirection et initialisation d'appel direct

La figure II.12 illustre le scénario où un serveur de redirection est utilisé par le terminal appelant afin de localiser son correspondant et pour l'échange qui s'ensuit. L'objectif est toujours de mettre en relation le terminal d'Anne avec celui de Brigitte, mais par un autre moyen.

Figure II.12 : Localisation avec un serveur de redirection et initialisation d'appel direct

Dans la première étape, le terminal d'Anne sollicite le serveur de redirection pour déterminer sa localisation. Une fois cette recherche effectuée, la réponse est envoyée directement au terminal d'Anne, lequel initie l'appel lui-même, en contactant le serveur proxy de Brigitte.

Les étapes qui suivent sont identiques à celles du scénario précédent avec l'initialisation d'appel par un serveur proxy, si ce n'est que ce dernier n'intervient pas dans les échanges intermédiaires.

5. Modification d'une communication SIP

Lorsqu'un utilisateur est en communication, il peut arriver qu'il souhaite modifier les paramètres de cette communication tout en la conservant active. Par exemple, s'il commence un téléchargement et que son débit risque de diminuer en conséquence, il peut souhaiter utiliser un codec moins gourmand. Dans un autre cas, l'utilisateur peut vouloir enrichir la communication audio avec une diffusion vidéo. Ou encore, il peut souhaiter inviter à une conférence un nouveau correspondant, qui ne supporte pas le codec utilisé par les autres conférenciers.

Ces cas sont parfaitement envisageables avec le protocole SIP, qui offre, rappelons-le, une très grande souplesse. À tout moment, l'appelant ou l'appelé peut envoyer un nouveau message d'invitation, avec la requête INVITE, afin de renégocier les paramètres de la communication. Bien sûr, dans ce contexte, le message n'a pas pour objectif d'inviter à une nouvelle session, mais d'utiliser de nouveaux paramètres.

60

C'est pour cette raison qu'on nomme RE-INVITE ce type de requête d'invitation. Du reste, la communication en cours n'est pas interrompue par la réception de cette requête. S'il accepte les modifications sollicitées dans la requête d'invitation, le récepteur confirme son accord par l'envoi d'une réponse 200 OK, qui sera ensuite acquittée par le demandeur, comme pour l'initiation d'une communication (voir figure II.13). Dans ce contexte, cette requête ne fait pas sonner le poste de l'interlocuteur puisque la communication est déjà en cours.

^{Terminal SIP}

^{Terminal SIP}

^Invite

^{200 OK}

^ACK

Figure II.13 : Requête RE-INVITE acceptée

Le demandeur qui en prend connaissance ne peut effectuer la modification désirée et doit soit se contenter des paramètres de la session actuelle, soit faire une nouvelle offre, en suggérant l'utilisation d'autres paramètres.

61

Dans le cas contraire, où le récepteur ne supporte pas ou ne souhaite pas accepter la modification de la session en cours, il reste libre de le faire, sans pour autant mettre fin à la communication, en envoyant un message de réponse 488 NOT ACCEPTABLE HERE, comme l'illustre la figure II.14.

^{Terminal SIP}

^{Terminal SIP}

^Invite

^{488 not Accepte Hare}

Figure II.14 : Requête de RE-INVITE refusée

6. Terminaison d'une communication SIP

La figure II.15 illustre la terminaison d'une session à l'initiative de n'importe quelle entité souhaitant mettre fin à l'appel.

^{Terminal SIP Terminal SIP}

^{Flux multimédia(audio, vidéo, texte..)}

^Bye

^200OK

Figure II.15 : Terminaison d'une Communication

1

9 J. Luc Koch, B.Dalibard. 2004, « téléphonie sur IP », www.rtcip.fr/IMG/pdf/livre_blanc_learning consulté le 20 Décembre 2012 a 15h45

62

Cette opération ne comporte que les deux étapes très simples suivantes :

1. Un message (requête BYE) est envoyé pour indiquer au correspondant que la session va être clôturée ;

2. Le correspondant répond à cette requête en validant la prise en compte de cette demande par une réponse 200 OK. La communication entre les intervenants est alors rompue.

II.5 AVANTAGES ET INCONVENIENTS DU PROTOCOLE SIP⁹ II.5.1 AVANTAGES

L'implémentation de la VoIP avec le protocole de signalisation SIP (Session Initiation Protocol) fournit un service efficace, rapide et simple d'utilisation. SIP est un protocole rapide et léger. La séparation entre ses champs d'en-tête et son corps du message facilite le traitement des messages et diminue leur temps de transition dans le réseau.

Les utilisateurs s'adressent à ces serveurs Proxy pour s'enregistrer ou demander l'établissement de communications. Toute la puissance et la simplicité du système viennent de là. On peut s'enregistrer sur le Proxy de son choix indépendamment de sa situation géographique. L'utilisateur n'est plus "attaché" à son autocommutateur.

Une entreprise avec plusieurs centaines d'implantations physique différente n'a besoin que d'un serveur Proxy quelque part sur l'Internet pour établir "son" réseau de téléphonique "gratuit" sur l'Internet un peu à la manière de l'émail. Les dizaines de milliers d'autocommutateurs peuvent être remplacés par quelques serveurs proxy.

On imagine bien la révolution. Mais comme d'habitude rien n'empêchera de remplacer un autocommutateur par un serveur Proxy réduisant ainsi l'intérêt du système. SIP est un protocole indépendant de la couche transport. Il peut aussi bien s'utiliser avec TCP que le protocole UDP.