Téléphonie sur IP : Pour quoi faire ?

Pascal Mouret Centre de Ressources Informatiques Université de Provence 3, pl Victor Hugo 13331 Marseille Cedex Pascal.Mouret@up.univ-mrs.fr Date: 13 Octobre 2003

Résumé L'Université de Provence dispose depuis septembre 2001 d'une installation de téléphonie sur IP. L'objet de cet article est de donner, au travers de l'expérience acquise depuis, quelques éléments d'évaluation quant à la pertinence et la mise en oeuvre effective d'une telle technologie. La réflexion principale exposée ici est que la notion de téléphonie sur IP recouvre plusieurs domaines d'application distincts, en ce sens qu'ils peuvent être mis en oeuvre de façon relativement indépendante les uns par rapport aux autres. Ce document a pour but de détailler ces différents domaines, leurs apports, et leurs implications, et se veut un guide pratique pour qui s'intéresse à la téléphonie sur IP en général et/ou envisage de la mettre en oeuvre. Il ne prétend évidemment pas répondre à toutes les questions, mais l'objectif est de poser les problématiques importantes, et d'y apporter des éléments de réponse ou de réflexion. Nous parlerons ainsi ici des trois problématiques suivantes : - IP jusqu'au poste téléphonique : déploiement de postes IP, gestion des IPBX (auto-commutateurs IP), - IP sur les liaisons inter-commutateurs : Comment profiter d'IP entre plusieurs sites ou plusieurs entités sans forcément déployer de téléphones et "auto-commutateurs" IP, - les nouveaux services : notamment la messagerie unifiée. Nous nous attachons à faire, pour chacun, un état des avantages et des inconvénients, des volumes financiers et des prérequis à la mise en place, en essayant de remettre ces éléments en perspective d'un déploiement réel.

Mots clefs Téléphonie, auto-commutateurs, IPBX, passerelles, gatekeeper, voix sur IP, qualité de service

1 Introduction L'Université de Provence dispose depuis septembre 2001 d'une installation de téléphonie sur IP (cf. annexe). A partir de cette base, divers tests ont été réalisés depuis, permettant d’avoir une idée plus précise des différents éléments à considérer afin d’assurer le succès de la généralisation d’une telle installation. L'objet de cet article est de donner, au travers de l'expérience ainsi acquise, quelques éléments d'évaluation quant à la pertinence et la mise en oeuvre effective d'une telle technologie. La réflexion principale exposée ici est que la notion de téléphonie sur IP recouvre plusieurs domaines d'application distincts, en ce sens qu'ils peuvent être mis en oeuvre de façon relativement indépendante les uns par rapport aux autres. Ce document a pour but de détailler ces différents domaines, leurs apports, et leurs implications, et se veut un guide pratique pour qui s'intéresse à la téléphonie sur IP en général et/ou envisage de la mettre en oeuvre. Il ne prétend évidemment pas répondre à toutes les questions, mais l'objectif est de poser les problématiques importantes, et d'y apporter des éléments de réponse ou de réflexion. Dans un premier chapitre, nous présentons les principes généraux de cette technologie ainsi que les techniques mises en oeuvre, entre autres : numérisation de la voix, codecs, protocoles de transport, protocoles de signalisation, principe d'établissement d'un appel, routage d'appel, etc ... Le chapitre suivant est consacré aux postes téléphoniques IP. Ce sont évidemment les premières choses que l'on se représente au sujet de la téléphonie sur IP. Le premier apport d'un poste IP est certainement l'indépendance géographique : On peut déplacer son poste, ou mieux, son numéro d'appel, dans tout un réseau. Egalement, on n'est plus tributaire d'un type de terminal d'appel, les communications pouvant être prises en compte sur tout matériel IP approprié. Ainsi, on voit que l'on change radicalement d'optique, puisque l'on passe d'un principe de « un numéro d'appel par bureau » à « un numéro par personne » ! Nous parlons également des apports importants induits, notamment sur l'administration téléphonique, puisqu'un seul (groupe de) IPBX peut assurer la gestion de l'ensemble des téléphones d'une université indépendamment des sites de déploiement.

Cela étant, il s'agit là de la partie la plus sensible, car la plus visible, d'un déploiement de téléphonie sur IP. De fait, nous traitons ici aussi, par exemple, des problématiques d'acceptation de ces nouveaux outils ou de qualité et de continuité de service, et de leurs implications techniques. Enfin, nous exposons quelques points à prendre en compte quant à une éventuelle mixité des types de téléphonie, IP ou classique, notamment au niveau de l'interconnexion et du plan de numérotation. Au chapitre 4, nous abordons les liaisons inter-autocommutateurs en IP, qui sont la concrétisation d'un des avantages les plus attendus de la téléphonie sur IP, à savoir la réduction des coûts. Leur mise en place est complètement indépendante de la mise en place de postes IP. C'est ce que nous avons également testé à l'Université de Provence, où les deux sites principaux, à Aix et Marseille, peuvent passer leurs communications téléphoniques en IP. Cette partie là est très certainement plus aisée à mettre en oeuvre que la précédente. Encore faut-il bien aborder les problèmes induits, entre autres ceux liés au plan de numérotation encore, à la gestion de la liaison (doit-elle être transparente pour les utilisateurs ? Ou son utilisation doit-elle procéder d'un choix individuel pour chaque personne et chaque appel ?), à l'exploitation éventuelle d'accès multiples vers l'extérieur, ou à la facturation. C'est ce que nous nous efforçons d'expliciter dans cette partie. Nous exposons également quelques réflexions sur la projection de cette problématique vers l'interconnexion d'entités administratives différentes. Le dernier chapitre concerne, quant à lui, les nouveaux services, à savoir ici essentiellement la messagerie unifiée. Celle-ci est souvent associée à la téléphonie sur IP, elle est née avec, mais elle n'en dépend absolument pas. Nous précisons ici notamment dans quelle mesure elle peut être mise en oeuvre, les interactions avec les systèmes de messagerie existants et avec les postes téléphoniques ... Nous abordons ici également la gestion distante des téléphones (par web). Pour terminer, nous présentons en forme de conclusion quelques éléments de réflexion sur la conduite d'un tel projet, en espérant avoir ainsi fait un large tour d'horizon de la question.

2 Principes généraux

2.1 Principes de base Une installation téléphonique, à l’université (ou en entreprise), qu’elle soit classique ou sur IP, s’appuie sur les mêmes principes : On dispose de terminaux téléphoniques (poste téléphonique bien sûr, mais aussi télécopieur, modem, etc …). Ces terminaux sont raccordés à un autocommutateur (appelé aussi PABX, pour Private Automatic Branch eXchange, en téléphonie classique, ou IPBX, pour IP Branch eXchange, en téléphonie sur IP). L’autocommutateur est un central téléphonique automatique, qui relie des lignes entre elles, que ce soit des liaisons locales (reliées à un terminal téléphonique) ou des lignes extérieures (à destination d’autres autocommutateurs). Une de ses fonctions premières est le routage d’appel : Quand une demande d’établissement de communication arrive sur une de ses entrées (en provenance d’un poste téléphonique ou d’une ligne d’interconnexion), il doit déterminer sur quelle sortie envoyer cette demande puis l’acheminer. Il gère également la taxation, les différentes fonctionnalités avancées telles que, par exemple, le rappel automatique, les différents types de renvois automatiques, les signaux de double appel, etc … Sur les différentes lignes de l’autocommutateur circulent donc deux types d’informations : - la signalisation (numéro composé sur le terminal, signal d’appel, …), qui sert à « gérer » la communication, - la communication proprement dite. (Note : Pour un autocom, intérieur = postes téléphoniques qu’il gère, extérieur = le reste) Là où la téléphonie IP s’éloigne de la téléphonie classique, c’est évidemment le support de ces transmissions d’informations. En téléphonie classique, une ligne est matérialisée par un câble. A chaque terminal correspond un câble dédié qui vient se raccorder sur un emplacement physique de l’autocommutateur. Il en est de même pour les autres liaisons. En téléphonie sur IP, toutes ces informations sont susceptibles de passer sur un même câble ou groupe de câbles, elles passent directement via le réseau IP de l’université. Il est à noter qu’en téléphonie classique, toute communication passe donc forcément par le PABX, alors qu’en téléphonie sur IP, la communication se fait directement de poste à poste (cf. Figure 1 et Figure 2).

signalisation voix

Figure 1 – Téléphonie classique Figure 2 – Téléphonie sur IP

2.2 Signalisation La signalisation intervient avant l’appel (établissement de l’appel), éventuellement pendant l’appel (fonctions avancées, signal de double appel par exemple), et après l’appel (fin de la communication). Elle est acheminée via un ou plusieurs protocole(s) de signalisation. Les protocoles de signalisation sont bien évidemment différents selon que l’on travaille en analogique ou en numérique. Dans le premier cas, que ce soit entre PABX ou entre un PABX et un terminal, les protocoles sont normalisés : FXS FXO notamment (possibilités limitées, essentiellement numérotation (pas de fonctionnalités avancées), par impulsion ou fréquence vocale). En revanche, vers les postes téléphoniques numériques, on a en général un protocole propriétaire, ce qui fait que les postes téléphoniques doivent être du même constructeur que l’autocommutateur. On comprend d’ailleurs ici pourquoi les modems et autres télécopieurs doivent forcément être reliés sur des lignes analogiques. Par contre, du fait de la problématique d’interconnexion vers l’extérieur, il a bien fallu normaliser les protocoles de signalisation pour la communication numérique entre PABX. Un des protocoles les plus répandus est le protocole QSIG. Il existe en deux déclinaisons : QSIG de base et QSIG étendu. Quelle que soit la déclinaison, il est évident que l’ensemble de fonctionnalités proposées est très souvent largement moindre que celui disponible sur les protocoles propriétaires des constructeurs. On notera également que c’est le QSIG de base qui est le plus répandu. On ne précise d’ailleurs généralement pas « de base » lorsque l’on parle de QSIG, c’est implicite, tant le QSIG étendu semble rare ! Au niveau de la téléphonie sur IP, la problématique reste sensiblement la même. Cela dit, un certain nombre de protocoles normalisés existent pour prendre en compte spécifiquement la problématique IP. Un des objectifs poursuivi dans l’élaboration de ces protocoles est de pouvoir un jour avoir une interopérabilité entre n’importe quel terminal et n’importe quel autocommutateur. Le protocole le plus ancien et le plus utilisé à l’heure actuelle est décrit par la norme H323 [4]. Celle-ci, dérivée de H320 (visioconférence sur RNIS), a été adoptée par l’ITU-T en 1996 et traite de la signalisation de la voix mais aussi de la vidéo et définit un modèle pour la gestion de ces flux. Elle donne également une définition des composants de la voix (ou vidéo) sur IP, qui est largement reprise même en dehors de la norme. Elle décrit 4 types de composants : - les terminaux (par exemple poste téléphonique, ordinateur avec une application appropriée, …) ; - les passerelles (ou gateway), qui permettent de faire l’interface entre les équipements H323 et les équipements non H323, tels que les équipements de téléphonie classique ; - le « garde-barrière » (ou gatekeeper), qui permet notamment de gérer des fonctions de contrôle d’appel (par exemple, accepter ou refuser un appel, selon des règles prédéfinies) et de contrôle de flux, ainsi que d’établir la correspondance entre un numéro d’appel et un équipement ; - le MCU (Multipoint Conferencing Unit), qui permet de gérer les conférences multi-utilisateurs et dont nous ne parlerons pas ici. Ce que l’on décrit comme un IPBX reprend notamment les fonctions d’un gatekeeper, auxquelles il faut ajouter, entre autres, les fonctionnalités de gestion du parc des téléphones et de gestion des profils utilisateur. Néanmoins, étant issue du monde des télécoms, la norme H323 a une certaine lourdeur et un manque de flexibilité, au niveau notamment de la gestion de la signalisation, décriés par les tenants d’une approche plus « informatique ». La réponse la plus porteuse à l’heure actuelle à cette norme est le protocole SIP (Session Initiation Protocol) élaboré par l’IETF (RFC 3261). SIP a été défini de manière à pouvoir autoriser des extensions. Il propose une gestion nettement plus simple de la signalisation que H323, et offre en plus un certain nombre de fonctions avancées ouvrant la porte à cette nteropérabilité attendue entre terminaux IP et IPBX. Cf. [4] pour plus de détails sur l’évolution de ces protocoles.

L’établissement d’une communication en voix sur IP comprend également une étape supplémentaire, à savoir l’association d’une adresse IP à un numéro téléphonique, soit l’adresse IP du poste s’il s’agit d’un numéro de poste, soit l’adresse IP de l’équipement vers lequel la communication doit être acheminée (par exemple, la passerelle pour atteindre l’extérieur).

2.3

2.4

Transport de la voix Outre les protocoles de signalisation, les plus grosses différences entre la téléphonie classique et la téléphonie sur IP se situent au niveau du transport de la voix. En téléphonie sur IP, la voix est transportée au moyen de deux protocoles construits sur UDP (décrits dans le RFC 1889) :

• RTP (Real Time Protocol), qui a pour tâche de transporter les flux de données « temps réel » - Il indique le type de codage des données transportées et gère le bon séquencement des trames et gère la base de temps - et

• RTCP (Real Time Control Protocol), qui est dévolu au contrôle des flux RTP – il envoie périodiquement des statistiques d’émission et réception, ainsi que des informations indicatives sur la qualité de la session.

Les contraintes de temps réel imposent de maîtriser un certain nombre de paramètres, et notamment :

• la latence : il s’agit du délai de transmission d’un paquet de l’émetteur au récepteur. Ce temps doit être le plus court possible, idéalement en dessous de 150ms, quoique cela reste encore supportable jusqu’à environ 300ms. Ce délai dépend des différents éléments impliqués dans le traitement du son, ainsi que de l’infrastructure de transport (équipements traversés) ;

• la gigue : c’est la variation du délai de transmission. Elle provient essentiellement de l’infrastructure réseau, que ce soit du fait de chemins différents empruntés, ou du fait de charges ponctuelles du réseau. La gigue peut être contrôlée en plaçant un buffer de gigue, mais cela augmente la latence ;

• la perte de paquets : là aussi, elle provient essentiellement de surcharges de l’infrastructure. Elle est relativement bien tolérée, mais ne doit pas excéder 20%. Il est à noter que l’on n’entreprend jamais de ré-émettre les paquets perdus, sous peine d’une augmentation importante de la latence.

Avant d’être transportée, la voix doit être numérisée, puis le signal original doit être reconstitué à l’arrivée. Ce rôle est dévolu aux codecs (codeur-décodeur). La norme H323 en définit un certain nombre, de caractéristiques distinctes (le protocole d’établissement d’un appel en H323 prévoit également une phase de négotiation des codecs). Les plus courants sont :

• G711, qui ne réalise aucune compression, et nécessite une bande passante de 64kb/s, c’est le standard en téléphonie • G729, qui n’a plus besoin que de 8kb/s, mais induit un délai de 10ms, • G723, qui arrive à 6,3kb/s, mais avec 30ms de délai.

Physiquement, la fonction du codec est réalisée par un processeur spécialisé (DSP, Digital Sound Processor). Enfin, la plus grosse différence réside dans le fait qu’en téléphonie sur IP, la voix est acheminée sur un support partagé, par les flux voix mais également souvent par des flux d’autres applications non forcément temps réel. Cela implique donc de gérer, en plus des paramètres énumérés plus haut, les priorités relatives des différents flux. Ceci est le rôle de la QoS (qualité de service). Sans rentrer outre mesure dans les détails, la méthode a priori la plus appropriée à l’heure actuelle se base sur le modèle DiffServ (RFC 2475), et consiste à insérer dans chaque trame des informations de priorité (champ TOS). Chaque équipement traversé traite les paquets selon divers algorithmes privilégiant les flux les plus prioritaires. Le fait de fixer la priorité est appelé le « marquage » et doit s’effectuer au plus proche de la source. Le cas idéal consiste à gérer la QoS de bout en bout, à savoir marquer les paquets dès le premier équipement actif traversé, et à acheminer ceux-ci exclusivement via des équipements capables de prioritiser les flux.

Infrastructure réseau Pour terminer, en téléphonie sur IP, la signalisation comme la voix sont acheminées sur une infrastructure active, à l’inverse de la téléphonie classique où l’infrastructure est totalement passive. De fait, et cela n’étonnera personne, l’infrastructure réseau est la clef de voûte de tout le système. Outre les contraintes de temps réel et support partagé que nous venons de voir, il faut également considérer les questions liées à la continuité de service. En effet, une liaison filaire ne tombe jamais en panne ! Par contre, ce n’est pas le cas des équipements actifs ! D’autre part, il n’y a pas de mises à jour à faire sur une liaison filaire, contrairement aux équipements actifs. C’est d’ailleurs plus la problématique des mises à jour que celle des pannes qui est importante. En effet, dans des conditions normales d’utilisation, les équipements réseau ont maintenant un taux de panne relativement faible. Par contre, maintenir le réseau dans un bon état de fonctionnement impose des mises à jour relativement fréquentes. Mettre en place de la continuité de service devient d’autant plus pertinent que si toute la téléphonie est en IP, c’est l’ensemble des communications qui reposent sur cette seule infrastructure réseau ! La mise en place (d’un certain degré) de continuité de service induit un certain nombre de problématiques à considérer :

- Redondance des équipements, et bascule automatique si nécessaire ? - Surveillance active des équipements, pour prévenir les pannes ? - Mise en place de Garantie de Temps de Rétablissement ? Présence accrue d’équipes ? Il n’y a pas de solution immédiate à toutes ces questions, mais il s’agit là clairement d’un des chantiers majeurs sur lesquels nous avons d’ores et déjà à nous pencher.

3 Les postes téléphoniques IP Les premières choses que l'on se représente au sujet de la téléphonie sur IP sont évidemment les postes téléphoniques IP. Cela dit, comme nous allons le voir, il ne s'agit pas forcément de la partie la plus facile à mettre en œuvre, loin s'en faut !! Il s'agit de la partie la plus sensible, car la plus visible, d'un déploiement de téléphonie sur IP !!

3.1

3.2

Pour quoi faire ? Le premier apport des postes IP est certainement l'indépendance géographique : On peut déplacer son poste, ou mieux, son numéro d'appel, dans tout un réseau d’établissement. En effet, le numéro d'appel peut être mis en correspondance avec le numéro IP du poste - permettant de déplacer ce dernier au sein du réseau -, voire avec un nom d'utilisateur, ce qui permet de prendre un appel virtuellement n'importe où, sur n’importe quel terminal IP (téléphone ou non). En fin de compte, on voit que l'on change radicalement d'optique, puisque l'on passe d'un principe de « un numéro d'appel par bureau » à « un numéro par personne » ! Cela simplifie grandement les problématiques liées à la mobilité des personnels. On voit également qu’il peut y avoir là un message politique très fort, à savoir réaffirmer l’unité d’une université, celles-ci étant, on le sait bien, très souvent éclatées, géographiquement du moins. D’autre part, un poste IP n’étant qu’un terminal IP particulier, on voit qu’on n'est plus tributaire d'un type de terminal d'appel, les communications pouvant être prises en compte sur tout matériel IP approprié (en gros, disposant d’un micro et d’écouteurs). Cela permet d’apporter une souplesse plus grande. Enfin, comme nous le verrons au chapitre 5, on dispose également de la possibilité d’administrer son poste à distance, par une interface web par exemple. Vu du côté administrateurs, le plus gros avantage est à chercher du côté de l’économie de moyens, du fait d’une mutualisation des infrastructures : En effet, un seul (groupe d’) IPBX suffit pour administrer des postes téléphoniques IP même géographiquement éloignés. Il n’est donc plus nécessaire d’avoir un PABX par site, ni même parfois un PABX par bâtiment ! De même, passer en téléphonie sur IP dispense de déployer deux réseaux physiques parallèles et un seul support suffit ainsi aux données et à la voix ! Il n’y a donc qu’une seule infrastructure générique, au lieu de plusieurs infrastructures (câblage) dédiées, à déployer et maintenir.

Mise en œuvre En théorie, et même en pratique d’ailleurs, la mise en œuvre est relativement simple. Pour utiliser des terminaux téléphoniques IP, il faut (au moins) : - un autocommutateur : On n’est pas forcément obligé de prendre un IPBX, un grand nombre de PABX acceptent maintenant des cartes IP leur permettant de piloter des postes téléphoniques (il faut toutefois bien faire attention, car disposer d’une carte IP et gérer des terminaux téléphoniques IP sont deux choses bien différentes). Ce bémol étant mis, pour des raisons de facilité d’écriture, je parlerais d’IPBX pour désigner indifféremment ces deux cas. - une passerelle (uniquement si on a mis en place un IPBX), afin d’assurer les accès vers l’extérieur (sans quoi les heureux possesseurs de postes IP seront voués à ne communiquer qu’entre eux). Les terminaux IP doivent être déclarés auprès de l’IPBX. La procédure peut être plus ou moins aisée selon les constructeurs. Dans le principe, il suffit de brancher les postes IP sur le réseau pour qu’il soient identifiés par l’IPBX. Dans le cas du système installé à l’Université de Provence, les postes obtiennent une adresse IP à partir d’un serveur DHCP. De ce même serveur, ils récupèrent l’adresse d’un serveur TFTP où est stockée leur configuration propre ou une configuration standard si c’est la première fois qu’ils sont connectés. A partir de ces données, ils contactent l’IPBX pour être enregistrés. Parallèlement à cela, il faut définir des profils utilisateurs (numéro(s) de poste, restrictions d’accès (appels locaux seulement, ou nationaux, etc …), options de renvoi, etc …) via une interface utilisateur. Il suffit de rattacher un profil à un poste pour que celui-ci soit prêt à être utilisé. Dans le cas général, ce rattachement se fait via l’adresse Mac du poste. Si on dispose d’un système permettant l’authentification des utilisateurs sur les postes téléphoniques, le profil est rattaché à un nom d’utilisateur et est dynamiquement, et temporairement, associé à un poste chaque fois que l’utilisateur correspondant au profil s’y est correctement authentifié. Néanmoins, si la mise en œuvre est relativement aisée, un certain nombre de points doivent être étudiés profondément en amont et imposent quelques contraintes à bien considérer, ainsi que nous allons le voir dans les points suivants :

3.2.1 Le plan de numérotation

Il s’agit d’un point incontournable. De lui dépend en grande partie la facilité de mise en œuvre d’un installation de téléphonie sur IP. Cela est bien sûr déjà vrai sur une installation classique, mais une problématique supplémentaire survient ici dans le cas de la prise en compte sur un seul et unique système de différentes installations correspondant à plusieurs sites. Le plan de numérotation décrit l’affectation des différents numéros qu’il est possible de composer aux fonctions associées, à savoir les numéros de poste bien évidemment, mais également les fonctions complémentaires (accès extérieur, appel du standard, consultation de messagerie, renvois, …). Par exemple :

0N Appel extérieur (N correspond au numéro transmis à l’opérateur) 10 Renvoi immédiat 11 Renvoi sur occupation … 34xx Postes téléphoniques (x remplace un chiffre quelconque) 35xx Postes téléphoniques (idem) … 9 Appel opérateur (standard) …

Figure 3 – Exemple de plan de numérotation

Pour donner une idée de l’importance des fonctions complémentaires dans le plan, on pourra noter que plus de 50 préfixes « utiles » (et utilisés) ont été relevés au niveau du PABX de l’Université de Provence. Au dessus du plan de numérotation, on définit le plan de routage, qui associe à chaque élément du plan de numérotation l’équipement IP auquel transmettre la communication ou la demande d’activation/désactivation de fonction. Ainsi, en face de chaque numéro de poste local, on aura (dynamiquement) l’adresse IP du poste correspondant ; pour une liaison extérieure par exemple, on aura l’adresse IP de la passerelle vers laquelle acheminer l’appel. Il est à noter qu’un IPBX peut supporter plusieurs plans (de numérotation et de routage) distincts, en partitionnant l’ensemble des postes téléphoniques. Les plans peuvent être affectés à chaque sous-ensemble indépendamment des autres. Le fait d’avoir plusieurs plans de numérotation peut permettre de remplacer assez facilement plusieurs installations existantes sans changer les habitudes des utilisateurs. A priori, cela semble toutefois peu pérenne (sauf erreur de ma part, un utilisateur se servant de l’installation depuis plusieurs zones distinctes aurait alors plusieurs plans de numérotation à retenir !). Il est également possible d’avoir des plans de routage distincts, ce qui est assez utile lorsque l’on veut qu’une même fonction soit traitée par des équipements distincts en fonction de l’origine. L’exemple typique de ce besoin est illustré par le cas suivant, où une université (au hasard, l’Université de Provence), est répartie sur (au moins) deux sites, mettons un à Aix-en-Provence et un à Marseille, chacun disposant d’un accès extérieur propre (passerelle) et où l’on souhaite que les postes situés à Marseille empruntent la passerelle de Marseille pour passer les appels extérieurs, et que ceux d’Aix utilisent celle d’Aix (et ce pour des questions de répartition de charge notamment). Dans ce cas, le plan de numérotation est identique (par exemple, 0N pour l’accès extérieur, cf ci-dessus). Par contre, le routage se fera vers la passerelle d’Aix ou celle de Marseille selon le poste appelant. Dans tous les cas, le plan de numérotation doit être défini afin de pouvoir programmer l’IPBX. Il est à noter que les règles de routage doivent être programmées dans l’IPBX bien sûr mais également totalement ou partiellement dans tous les équipements par lesquels transitent les communications (passerelles entre autres). Il est donc important de bien préparer cela. Notamment, quand on mixe téléphonie classique et téléphonie sur IP, il est loin d’être inutile de dégager des blocs pour chaque type de téléphones. Avoir des numéros éparpillés implique d’écrire une règle de routage par numéro sur chaque équipement (IPBX, passerelle(s), PABX) !!! On en vient donc rapidement à des configurations assez rédhibitoires. Hormis cela, il n’y a pas de règle particulière. Les numéros de postes sont évidemment les numéros SDA attribués par l’opérateur. Les numéros de fonction sont ensuite à attribuer dans l’espace restant.

3.2.2 Installation mixte ou tout IP ?

Faut-il migrer toute son installation en IP ou une phase transitoire mixte (IPBX + PABX) doit-elle être envisagée ? Il est difficile de trancher. Le point que l’on a pu constater en défaveur de la phase mixte est que du fait de l’utilisation de protocoles de signalisation standards – et donc fonctionnellement moins riches - à l’interconnexion des deux installations, très peu de fonctionnalités avancées sont possibles au niveau des communications inter-zones, ce qui revient à établir une séparation franche entre les utilisateurs de téléphonie sur IP et ceux qui utilisent la téléphonie traditionnelle. D’autre part, il y a deux installations complètement distinctes à gérer, chacune générant des coûts humains et matériels non négligeables. Même si cela pourrait permettre une certaine souplesse et une certaine progressivité dans la mise en place, il ne semble donc pas pertinent de faire cohabiter des IPBX et des PABX sur une même installation. Par contre, si cette souplesse et cette progressivité sont des objectifs forts, il est certainement plus intéressant d’utiliser un PABX disposant de la possibilité

d’adjoindre des terminaux IP. On peut notamment penser au cas de sites devant renouveler leur PABX sans toutefois être immédiatement prêts à passer en tout IP, cette dernière solution peut raisonnablement s’envisager. Dans la plupart des autres cas, il semble plus cohérent de privilégier une solution homogène tout IP.

3.2.3 Continuité de service

Comme on l’a vu plus haut, la continuité de service est un élément quasi-incontournable dans une installation de téléphonie sur IP. Indépendamment du type de système utilisé, il apparaît notamment indispensable de pouvoir passer des appels d’urgence à tout moment (malgré le fait que nous n’ayons pas trouvé de réglementation sur cette problématique pour les réseaux d’entreprises). En téléphonie traditionnelle, cela se ramène à la problématique de continuité de fonctionnement du PABX. En téléphonie sur IP, la question est plus complexe : Il faut assurer le fonctionnement de l’IPBX mais, au-delà même de la continuité de fonctionnement de l’IPBX, il faut une continuité de fonctionnement jusqu’à l’IPBX, autrement dit, les équipements réseau traversés doivent fonctionner et le téléphone IP doit être alimenté en courant ! Il faut également, le cas échéant, une continuité de fonctionnement de l’IPBX jusqu’à la liaison externe (donc jusqu’à la passerelle). Au niveau de l’IPBX lui-même, la seule solution est de lui adjoindre un équipement en redondance. On notera que quand bien même il s’agit d’équipements fonctionnellement équivalents, le problème ne se pose pas ou peu au niveau des PABX, car, d’une part, il est difficilement envisageable de confier à un seul PABX la gestion de plusieurs sites distants, et donc de faire reposer l’ensemble d’une installation téléphonique sur un seul PABX, et d’autre part, parce qu’à l’inverse des IPBX qui ne sont généralement qu’une couche applicative au-dessus d’un système généraliste, un PABX repose plutôt sur un système propriétaire ou dédié, et donc présumé plus robuste. Au niveau de l’Université de Provence, nous avons pu mettre en place une solution équivalente, mais moins coûteuse, qui permet d’atteindre le même objectif. Cette solution, propriétaire, dénommée SRST (Survival Remote Site Telephony) permet d’assurer le secours d’un certain nombre de postes IP au moyen d’un logiciel supplémentaire ajouté dans les passerelles. En cas de perte du lien avec l’IPBX, les postes IP sont pris en charge de manière transparente au niveau de la passerelle au bout d’1 à 2 minutes, avec les fonctionnalités minimum pour passer un appel. Il est important de noter que, dans tous les cas de figure, la perte de l’IPBX n’entraîne pas la coupure des communications en cours. Il devient seulement impossible d’en établir de nouvelles. Pour ce qui est de la continuité de service au niveau de l’infrastructure réseau, la problématique n’est pas particulière à la téléphonie sur IP. Dans l’idéal, en cœur, c’est la redondance qui semble la plus pertinente. En périphérie, il ne nous semble pas déraisonnable de répartir les connexions sur un minimum de deux équipements distincts (avec une densité de ports adaptée) afin de rendre la perte d’un équipement moins sensible. Pour ce qui est de l’alimentation en courant des terminaux, nous en verrons plus loin quelques éléments. Dans tous les cas, il faut bien sûr mettre en relation le niveau d’exigence avec la proportion de téléphonie sur IP installée. Une solution de moindre coût qui pourra être retenue est de conserver des postes traditionnels à utiliser en cas de non-fonctionnement du système IP.

3.2.4 Qualité de service

Au-delà du fait qu’il faudrait, dans le cas idéal, faire de la QoS de bout en bout, il n’est peut-être pas inutile de rappeler qu’une communication téléphonique ne représente que 64kb/s de bande passante au maximum. Sur des réseaux à des débits maintenant de 100Mb/s au minimum, cela semble relativement peu, même multiplié par « un certain nombre d’ » utilisateurs. De fait, sur l’installation de l’Université de Provence, on ne constate que très peu de défauts, alors qu’on ne dispose pas (encore) de QoS de bout en bout. Cela dit, nous avons pu tester quelques « beaux » dysfonctionnements, et quand la liaison est mauvaise (ralentissements en un ou plusieurs points du réseau), la qualité de la communication se dégrade fortement. Dans les quelques cas que nous avons testés, cela revient à avoir de fréquentes et subites coupures franches du son, laissant une impression d’interruption de la communication (ce qui donne des conversations assez surréalistes ponctuées de « Allo » à tout bout de champ !) De fait, il en va un peu de la QoS comme d’une assurance : la plupart du temps, ça ne sert à rien, mais on est bien content de l’avoir quand il y a un problème !!

3.2.5 Problématique de l’acceptation

Le changement est très souvent source de problèmes. Or, ici, il s’affiche directement sous les yeux des utilisateurs et entre de plein pied dans leur quotidien. Même si il est clair que dans tout changement, il y a d’abord une première phase de rejet, avant de passer, éventuellement, à une phase d’acceptation, un certain nombre de points apparemment futiles peuvent compromettre la bonne marche d’une telle opération. Bien sûr, tous les points que l’on a vus auparavant sont importants. Les nouveaux outils ne seront pas acceptés si ils sont plus compliqués que les autres (même seulement en apparence) ou si ils fonctionnent « moins bien ». La finalité du changement est importante également : Cette question a souvent douché notre enthousiasme béat : « Quel intérêt [d’avoir ces nouveaux postes] ? » (parce qu’il ne vous aura pas échappé que l’utilisateur n’est aucunement impressionné par le fait que vous réussissiez à faire passer de la voix sur IP !). C’est notamment là qu’on

mesure, d’une part, l’importance de la préparation d’un tel « changement », et d’autre part, la nécessité que cela soit un projet d’établissement ! Ensuite, ce sont les « détails » : Par exemple, rien que la forme du combiné peut poser problème. Ainsi, on a eu la remarque que les nouveaux combinés étaient difficilement utilisables, car ils ne tenaient pas sur l’épaule ! Le bruit de la sonnerie joue aussi. Le fait que le téléphone aie maintenant plusieurs fils (alimentation électrique en plus) nous a pas mal été reproché également. Plus important, il y a les fonctionnalités disponibles (cf. point suivant). La qualité auditive est également un facteur déterminant. Même si la qualité est bonne l’immense majorité du temps, il n’est pas nécessaire qu’il y ait un grand nombre d’incidents pour que le produit soit décrié, voire rejeté. Les réseaux informatiques ont d’ailleurs une image de qualité moins grande que les réseaux téléphoniques, à un point tel que, ainsi qu’on a pu en faire le test sur quelques personnes, rien que le fait de leur faire croire que la communication qu’il sont en train de passer est acheminée sur un réseau informatique leur fait percevoir des imperfections dans la qualité auditive !!! Ce qui relativise d’ailleurs certaines de ces remarques (on peut considérer qu’on a des qualités équivalentes). On peut juste noter quelques fois des problèmes visiblement dus à la compression des silences, assez gênants car donnant l’impression d’une coupure de la communication, d’une façon identique à celle décrite plus haut. De fait, aussi futiles soit-ils en apparence, ces points doivent être complètement intégrés dans la préparation du projet, et être considérés avec une attention soutenue afin de ne pas en compromettre le bon déroulement. Peut-être ne serait-il d’ailleurs pas inutile de faire un premier test sur un échantillon d’utilisateurs ?

3.2.6 Fonctionnalités avancées

Un point qui nécessite une attention soutenue est le suivant : Si plus de 90% des utilisateurs n’utilisent que les fonctions standard des téléphones (messagerie + renvois divers au plus), les 10% restant utilisent des fonctionnalités plus évoluées. On peut citer les groupes (un seul numéro correspond à plusieurs téléphones, ceux-ci sonnant alternativement selon un algorithme choisi à l’avance), utilisés massivement dans les services étant en contact avec le public, les filtrages « patron-secrétaire » au niveau des chefs de service, l’interception d’appel, la conférence multi-postes, etc … Il s’agit de fonctionnalités disponibles sur les PABX, mais qui ne sont pas forcément implémentées dans tous les IPBX, quand bien même le fossé a tendance à se combler. Il peut arriver (c’était notre cas) que certaines de ces fonctionnalités nécessitent un serveur supplémentaire ou des licences supplémentaires, qu’il ne faut pas négliger. Enfin, un point important que nous avons pu (à nouveau) constater, relié au paragraphe précédent, est que les utilisateurs ont souvent complètement oublié les besoins qui ont justifié la mise en place de ces fonctionnalités au profit des solutions retenues. De fait, si il est une évidence qu’il n’est pas forcément nécessaire d’avoir strictement la même fonctionnalité mais que ce qu’il faut avant tout c’est répondre au besoin initial, il n’en est pas moins vrai qu’un travail de discussion préalable non négligeable doit être entrepris afin de faire admettre que la nouvelle solution est au moins aussi bonne que l’ancienne, sinon meilleure. On a pu constater qu’un des facteurs de défiance a priori vis à vis des postes IP venait de ces problèmes d’habitudes à changer. Il va sans dire que si on ne dispose d’aucune fonctionnalité correspondant au besoin, l’outil a de gros risques d’être complètement rejeté !

3.2.7 Auto-alimentation

Dans tous les cas, le poste téléphonique nécessite une alimentation. En téléphonie classique, celle-ci est fournie par le PABX. En téléphonie sur IP, deux cas sont possibles. On peut utiliser une alimentation extérieure : Dans ce cas, on dispose d’un cordon d’alimentation avec un transformateur. Nous avons pu constater (cf. plus haut) que cela posait des problèmes à nombre de gens, ne serait-ce que par le fait d’avoir un « fil en plus ». Cela a également un impact non négligeable sur les questions de continuité de service (problèmes de défaillance de l’alimentation). Une nouvelle possibilité commence à se répandre, beaucoup plus intéressante : Dans ce cas-là, le poste est alimenté au travers de la liaison IP par l’équipement de commutation auquel il est raccordé. Cette possibilité a récemment été normalisée (Juin 2003) par l’IEEE sous la référence 802.3af (PoE, ou Power over Ethernet). Il est à noter qu’elle peut être utile pour d’autres types de matériels tels que les bornes sans fil. A l’achat, cela est très peu cher : en septembre 2003, environ 10 à 15% de plus qu’un commutateur identique sans auto-alimentation. Si on ne dispose pas de tels commutateurs, on peut utiliser des panneaux additionnels qui s’intercalent entre l’équipement et la liaison. Le coût est là relativement plus élevé. Compter environ 3000€ pour 48 ports. L’avantage énorme de cette technique est que les utilisateurs se retrouvent dans le même schéma qu’avant, ce qui est « rassurant », mais surtout que tout le problème de la rupture d’alimentation se retrouve concentré en un seul point : l’armoire de répartition. De fait, cela devient le seul endroit qui nécessite une alimentation sécurisée ! La norme étant récente, il faut toutefois bien faire attention à choisir des matériels qui la respectent ou qui sont compatibles !

3.2.8 Micro-switches

Certains postes téléphoniques sont équipés d’un micro-switch. Ainsi, au lieu de brancher le poste téléphonique sur une prise réseau à part, il est possible de brancher le PC sur le téléphone, et de raccorder le poste au réseau informatique. Dans ce cas,

on n’utilise qu’une prise pour les deux équipements. Outre l’économie d’une prise (tous les bureaux n’en ont pas forcément été équipés d’un nombre suffisant), cela peut permettre une gestion plus aisée de la qualité de service. En effet, certains des postes que nous avons testés affectent automatiquement une priorité plus élevée au trafic voix et réalisent eux-même le marquage. Cela évite d’avoir à le réaliser au niveau des switches de répartition. Attention toutefois : Sur notre installation, et dans le cas d’une affectation des trafic données et voix à des vlans différents, la méthode d’affectation des numéros de vlan aux deux types de trafic est réalisée de manière propriétaire au niveau du switch de raccordement !! Ainsi, nous n’avons pas pu avoir accès à cette possibilité avec des commutateurs d’autres marques. Il peut être utile de vérifier ce point au préalable. Quant à la nécessité ou non de séparer les trafics voix et donnée, il nous semble pertinent d’effectuer cette séparation, ne serait-ce que pour limiter les « perturbations » au maximum. Sans cette séparation, on arrive à doubler le nombre d’équipements sur un même réseau et on peut de fait largement dépasser les limites imposées par les règles d’architecture des réseaux (il suffit de penser à l’augmentation du nombre de broadcasts).

3.2.9 Volumes financiers

L’installation réalisée à l’Université de Provence, avec 18 postes, un IPBX et deux passerelles (une et demi en fait) a représenté un volume d’environ 50K€. Si on extrapole ces coûts à l’échelle d’une Université (environ 1000 postes) aujourd’hui, il faut compter plutôt de l’ordre de plusieurs centaines de K€. C’est donc une opération assez coûteuse. Le poste le plus important, et de loin, est certainement celui des terminaux téléphoniques. Suivant les niveaux de fonctionnalités requis, les prix des terminaux peuvent facilement passer du simple au triple. On notera toutefois que, si, en 2001, les prix étaient franchement plus élevés que ceux des postes traditionnels, cette différence n’est maintenant plus significative. Dans tous les cas, et on n’a pas intégré le coût de la redondance, c’est un investissement important. Tout le monde semble s’accorder sur ce point : Il n’y a pas d’économie d’investissement à attendre aujourd’hui d’une installation de téléphonie sur IP. Par contre, une installation IP supporte des coûts d’évolution très faibles (à l’inverse d’un PABX auquel il faut rajouter régulièrement des cartes d’extension afin de brancher de nouveaux postes téléphoniques). Dans le même ordre d’idée, l’intégration d’un nouveau site représente des coûts très faibles comparés à l’acquisition d’un nouveau PABX. Enfin, il y a un gain non négligeable au niveau de l’administration, du fait de la mutualisation d’anciennes installations.

3.2.10 Ce dont on ne parlera pas …

… car pas assez de recul : • Comment raccorder un fax ou un modem sur une installation de téléphonie sur IP ? Est-ce pertinent d’ailleurs ?

Deux pistes : remplacer les fax individuels par des serveurs de fax (voir chapitre 5) pour le premier cas, ou utiliser des adaptateurs téléphonique analogique / IP ? Ces derniers coûtent de l’ordre de 150€ pour deux ports analogiques (des densités plus importantes existent). Les fonctionnalités exactes sont à valider …

• Dans les installations disposant de plusieurs passerelles, est-il pertinent d’envisager un routage des appels extérieurs selon la destination (pour sortir au plus près et réduire les coûts) ?

• La taxation. Attention, celle-ci est parfois réalisée par des modules additionnels qui viennent entraîner un surcoût supplémentaire à l’installation.

3.3 Avant de passer à la suite Pour synthétiser tout cela, un projet de mise en place d’une installation de téléphonie sur IP est un projet lourd, qui nécessite une réflexion importante en amont. Il peut être également porteur d’un message politique fort. Si les coûts sont importants, on peut tout de même constater que les prix des différents équipements ont bien baissé. De plus, on arrive à une génération de produits où un grand nombre de problèmes ont été résolus. Aujourd’hui, et compte tenu des délais de réalisation d’un tel projet, envisager une installation de téléphonie sur IP semble tout à fait réaliste. Il est toutefois à noter que les problèmes sont maintenant reportés sur l’infrastructure. De fait, le tout IP semble encore relativement délicat aujourd’hui car assez contraignant. Néanmoins, compte tenu de ceci mais aussi des autres applications critiques émergentes, une refonte de la façon de considérer de nos réseaux (passer du « best effort » à une notion de qualité et continuité de service) semble aujourd’hui inéluctable. Une première approche raisonnable semble être de conserver un certain nombre de postes traditionnels permettant de communiquer même en cas de problèmes. Le nombre de ces postes reste évidemment lié au niveau d’exigence que l’on a fixé au réseau IP. D’autre part, les gains les plus forts vont se faire sentir en mutualisant plusieurs sites. Il faut certainement, de ce côté-là, profiter au maximum des opportunités, et pour ce faire, le premier élément à considérer est indubitablement la mise au point a priori (le plus tôt possible) d’un plan de numérotation cohérent. Enfin, outre les aspects économiques, il peut y avoir là un message politique très fort, à savoir réaffirmer l’unité d’une université, celles-ci étant, on le sait bien, très souvent éclatées, géographiquement du moins.

4 Interconnexion d'autocommutateurs en IP Un deuxième élément qui apparaît assez rapidement au niveau de la téléphonie sur IP est la possibilité de relier entre eux des sites distants via des liaisons IP existantes.

4.1

4.2

Pour quoi faire ? Ces liaisons inter-autocommutateurs en IP sont bien évidemment la concrétisation d'un des avantages les plus attendus de la téléphonie sur IP, à savoir la réduction des coûts. Leur mise en place est complètement indépendante de la mise en place de postes IP. On peut très bien interconnecter en IP des PABX traditionnels. C'est d’ailleurs en partie ce que nous avons également testé à l'Université de Provence, où les deux sites principaux, à Aix et Marseille, peuvent passer leurs communications téléphoniques en IP que ce soit à partir d’un poste traditionnel ou à partir d’un poste IP. On notera que ce n’est pas IP qui a permis d’apporter des liaisons inter-PABX, mais le fait est qu’auparavant ces liaisons étaient forcément dédiées, donc induisant des surcoûts dès qu’on sortait du périmètre du campus, et qu’il fallait faire appel à un opérateur. Avec IP, on peut mieux utiliser des liaisons déjà existantes et déjà payées. Un autre point moins évident, mais tout aussi intéressant est que l’ensemble des postes interconnectés ainsi peuvent être vus comme internes par chacun des PABX. Notamment, on peut définir des numéros internes, qui ne peuvent être appelés de l’extérieur. Sans la liaison, les postes d’un site sont considérés comme extérieurs par le PABX de l’autre site. Avec la liaison, ils sont vus comme internes et accèdent ainsi à ces numéros. De fait, on pourrait dire que l’ensemble des postes sont ainsi équivalents en termes d’accès (on notera que du fait des problèmes de signalisation vus plus haut, toutes les fonctions du PABX d’un des sites ne seront pas forcément accessibles aux terminaux de l’autre site).

Mise en œuvre Cette partie-là est très certainement plus aisée à mettre en oeuvre que la précédente. Elle ne met en jeu que des passerelles si on veut mixer téléphonie traditionnelle et téléphonie IP. Dans le cas où tous les sites à relier sont déjà en IP, il n’y a de fait aucun équipement supplémentaire à acquérir. Dans ce dernier cas, il s’agit simplement de rajouter les règles de routage adéquates sur chaque IPBX afin d’acheminer l’appel vers l’IPBX à l’autre extrémité. Si aucun des sites à relier n’est en téléphonie sur IP, soit tous les PABX peuvent se voir adjoindre des cartes IP et on se ramène au cas tout IP, soit certains ne peuvent pas en avoir et on se retrouve donc dans le cas mixte. Dans ce dernier cas, la passerelle sert à relier les mondes IP et téléphonie classique. On aura forcément un site en configuration mixte ne serait-ce que pour avoir l’accès extérieur vers le réseau public de téléphonie. Pour relier la passerelle au réseau de téléphonie classique, il faut disposer d’une interface adéquate, généralement une RNIS T2 (30 canaux), ou une T0 (2 canaux) pour des volumes de communications plus faibles, voire une liaison analogique. On doit évidemment avoir la même interface côté opérateur, ou côté PABX (dans ce dernier cas, une carte peut donc être à acheter). Quoi qu’il en soit, il faut impérativement s’assurer que l’on dispose d’un protocole de signalisation commun aux deux extrémités de la liaison. Pour des raisons de coût, et si le volume de communications simultanées sur la liaison ne le justifie pas, on peut ne pas utiliser tous les canaux d’un T2, ce qui se traduit par moins de DSP à acheter (si la passerelle permet une granularité à ce niveau). Puis, pour relier les différents éléments entre eux, deux cas sont possibles, considérant que chaque PABX a déjà une interface T2 reliée au réseau opérateur. Dans un premier cas, on défait cette liaison pour la relier à la passerelle, et on adjoint un deuxième T2 à la passerelle vers le réseau opérateur. Dans le second cas, c’est l’inverse, et c’est le PABX qui dispose de deux liaisons. Enfin, il convient de ne pas oublier de considérer la problématique de la compatibilité de la signalisation, afin de s’assurer qu’une fois raccordés, les équipements pourront bien dialoguer entre eux. Comme pour les terminaux IP, quelques autres points nécessitent également une préparation non négligeable :

4.2.1 Le plan de numérotation

Encore une fois, le plan de numérotation est très important. Ici, la problématique vient du fait que l’on doit mixer des plans de numérotations différents non forcément compatibles entre eux. En effet, rien n’interdit que les numéros SDA d’un site viennent recouvrir partiellement l’espace de numérotation des numéros SDA d’un autre site. S’ensuit un premier choix : Veut-on une numérotation abrégée pour tous les sites ? Et si oui, la veut-on directement avec les numéros SDA ou admet-on l’utilisation de certains préfixes ? Dans le premier cas, on n’échappe pas à une refonte du plan de numérotation. Cela implique de restituer à l’opérateur certaines des plages qui se recouvrent et d’acquérir de nouvelles plages compatibles avec la reste. Les recouvrements doivent évidemment être considérés sur l’ensemble du plan de numérotation, à savoir sur les numéros SDA bien sûr mais aussi sur les codes de fonctions. En conséquence, il va y avoir forcément des changements de numéros de téléphone pour tout ou partie d’un ou plusieurs sites, ce qui peut être assez lourd. En contrepartie, cela donne un plan plus clair.

L’autre alternative est l’utilisation de préfixes. En d’autres termes, au lieu d’utiliser directement le numéro SDA du correspondant, on va préfixer celui-ci par un code indiquant le sous-ensemble de sites à considérer. Exemple : Appel vers Site 1 Site 2 Site 1 N° poste N° poste Site 2 N° poste N° poste

Appel vers Site 1 Site 2 Site 1 N° poste Préfixe2+N° posteSite 2 Préfixe1+N° poste N° poste

Figure 4 – Numérotation sans préfixage Figure 5 – Numérotation avec préfixes

4.2.2 Sélection implicite

Doit-on obliger les utilisateurs à utiliser forcément les liaisons IP là où elles existent ou leur donne-t’on le choix ? En d’autres termes, reroute-t’on de manière transparente vers les liaisons IP les numéros utilisés auparavant ou donne-t’on le choix d’utiliser la liaison IP en proposant un préfixe à cette fin ? La contrainte majeure liée à la première solution réside dans le fait que l’on se doit d’assurer un service à la hauteur de celui qui était assuré auparavant. Cela n’est pas forcément gagné d’avance. Il faut bien considérer que des problèmes répétés dans un cas comme celui-ci peuvent être assez perturbants et entraîner des réactions fortes de la part des utilisateurs. L’avantage de la « sélection explicite » est que c’est l’utilisateur qui fait le choix de prendre ou non la liaison IP, en toute connaissance de cause (il est informé des risques de perturbations, mais également des coûts financiers qui lui incombent dans les deux cas). On peut noter d’ailleurs que dans ce cas, on peut privilégier un type de liaison par rapport à l’autre en lui affectant des numéros abrégés (éventuellement préfixés), l’autre nécessitant l’utilisation d’un préfixe devant le numéro abrégé du numéro complet. Exemple (Cas d’un appel de Marseille vers Aix, mcdu correspond aux quatre chiffres du numéro de poste) : Numéro composé Cas classique Cas IP avec sél. implicite Cas IP avec sél. explicite 044295mcdu Liaison classique Liaison IP (par défaut) Liaison classique (#1)mcdu Impossible ? Liaison IP (par défaut) Liaison IP (par défaut)

Figure 6 – Sélection implicite ou explicite

L’inconvénient majeur de la sélection explicite est que, pour diverses raisons (souvent l’habitude mais aussi parfois parce qu’il y a eu un problème un jour), tous les utilisateurs ne feront pas le choix de la liaison IP, d’où des économies forcément moindres. On n’a pas ce problème en « sélection implicite » mais la liaison se doit alors d’être irréprochable !

4.2.3 Liaison de secours

Compte tenu de la fiabilité a priori moins grande de la technologie IP, il peut être utile de mettre en place des liaisons de secours pour permettre un acheminement des communications même en cas de perte de la liaison principale. Il s’agit là simplement de règles supplémentaires au niveau du routage. La nouvelle route s’active lorsque la destination indiquée dans la route principale n’est pas joignable. Il est à noter que cela n’intervient qu’à l’établissement de la connexion. Le seul symptôme visible de l’utilisateur est donc a priori un temps d’attente un peu plus long avant d’atteindre son correspondant. D’autre part, rien n’impose que la liaison de secours ait les mêmes caractéristiques que la liaison principale (elle peut, par exemple, ne pas permettre autant d’appels simultanés). Elle peut également être une liaison IP aussi ou une liaison classique. Dans ce dernier cas, il faut bien considérer le fait qu’il y aura donc un coût d’utilisation du secours, et il n’est sans doute pas inutile de voir sur quel compte cela va être imputé (selon la configuration de la taxation), de se poser la question de savoir si c’est aux utilisateurs ou à l’Université dans son entier de supporter de tels surcoûts et de prévenir les utilisateurs ou prévoir les budgets (qui ne devraient pas être faramineux d’ailleurs).

4.2.4 Volumes financiers

Il s’agit d’une installation beaucoup plus légère que la précédente. Chaque liaison nécessite une passerelle sur chaque site (sauf si déjà installée pour une autre liaison bien sûr). Le coût par passerelle (avec une unique liaison T2) peut être estimé à environ 10K€. Une carte T2 pour un autocommutateur revient à peu près au même prix. Une liaison complète revient donc à « seulement » quelques dizaines de K€, ce qui peut être assez rapidement amorti par le gain sur le coût des communications inter-sites.

4.2.5 Ce qu’on a déjà dit avant

On retrouve certaines problématiques abordées dans le chapitre précédent : • la QoS et la continuité de service : les mêmes conclusions s’imposent, • la taxation : le seul élément supplémentaire, a priori, à considérer ici est la synthèse des informations de plusieurs

passerelles. Il s’agit de quelque chose que nous n’avons absolument pas testé.

4.2.6 Ce dont on ne parlera pas

• Dès que l’on a des passerelles connectées à un même opérateur dans des zones de tarification différente, ou connectées à plusieurs opérateurs distincts, il est tentant de réduire les coûts en routant les appels extérieurs vers la passerelle la plus appropriée. C’est techniquement faisable et a priori relativement simple si on peut se baser sur les premiers chiffres du numéro de téléphone pour effectuer avec certitude le bon choix …

• Lorsque l’on interconnecte un grand nombre de sites, se pose le problème de l’explosion des tables de routages. En effet, pour chaque plage de numéro, on doit programmer l’ensemble des passerelles. De fait, tout changement sur un site doit être immédiatement répercuté sur l’ensemble, ce qui peut être rapidement très lourd. De même, si le nombre de sites disposant d’installations de téléphonie sur IP augmente, on peut être tenté de les contacter en téléphonie sur IP. Il va de soi que l’on ne peut même pas envisager de connaître leur plan de numérotation de manière exacte ni même de référencer l’ensemble des plans de numérotation dans l’ensemble des équipements. L’idéal serait de disposer de (une hiérarchie) de matériels, vraisemblablement des gatekeepers, auprès desquels chaque site enregistre ses numéros avec la passerelle associée, et que chaque site consulte pour prendre des décisions de routage sur des numéros qu’il ne connaît pas.

4.3 Conclusion

5.1

Son faible coût et ses perspectives d’économies importantes font certainement de la liaison IP inter-autocommutateurs une des applications les plus intéressantes et les plus faciles à mettre en œuvre dans la « galaxie » téléphonie sur IP. A l’inverse de la mise en place de terminaux IP, cela n’impose pas vraiment de refonte d’architecture, et est donc plus aisé à concevoir. Dans la mesure où elle ne remet pas en cause les autres étapes, c’est très certainement la première brique pour construire une installation de téléphonie sur IP. Là aussi, on voit que le plan de numérotation est primordial.

5 Les nouveaux services Souvent associée à la téléphonie sur IP, on trouve la messagerie unifiée. Encore une fois, on notera que l’on peut parfaitement faire de la messagerie unifiée sans avoir de téléphonie sur IP. Les quelques autres points dont nous parlerons également ici ont été apportés par la vision « informatique » qui a guidé le développement de la téléphonie sur IP, mais ne s’y limitent pas forcément.

Messagerie unifiée La justification de la messagerie unifiée réside dans l’observation que nous disposons tous de différents canaux de communications et que tous disposent de mécanismes indépendants de collecte des messages (messagerie vocale pour le téléphone, messagerie électronique, télécopies, …). Ceci impose une consultation indépendante de chacun des récepteurs de ces messages. L’idée de la messagerie unifiée est d’avoir un récepteur unique pour tous les messages quels que soient leur type. La messagerie électronique est le récepteur universel (quoique la messagerie vocale puisse recueillir certains types de messages aussi puis les restituer via une synthèse vocale). L’idée est extrêmement séduisante : il suffit de consulter sa messagerie électronique (donc d’où qu’on soit dans le monde) pour connaître le contenu des messages vocaux qui ont été laissés sur son téléphone de bureau ou bien des fax arrivés au bureau, etc ... Au delà même de la consultation, il y a mise en commun des messages (espace commun de stockage), et de fait un message vocal, par exemple, lu à partir de la messagerie électronique puis effacé de ce même endroit n’est plus disponible sur le téléphone. Dans le principe, elle est extrêmement simple. Un système de messagerie unifiée n’est ni plus ni moins qu’un système de stockage relié à des interfaces vers les différents médias de communication. Par contre, il faut pouvoir gérer la signalisation (encore) des différents postes. En effet, il agit sur des fonctionnalités non standards et il est donc très important de s’assurer de sa compatibilité avec le système de téléphonie (IP ou non IP). En effet, une des raisons les plus évidentes est qu’il y a souvent un témoin de messagerie sur le poste téléphonique et que le simple fait de lire un message depuis la messagerie électronique doit éteindre ce témoin sur le poste téléphonique. La messagerie électronique est généralement gérée au moyen du protocole IMAP. Le système testé à l’Université de Provence nécessitait cependant de maintenir un serveur de messagerie Windows à côté du serveur « normal » qui était sous Unix, et n’a pas été conservé, pour cette raison ainsi qu’à cause du fait qu’il n’était compatible qu’avec les téléphones IP. Il existe néanmoins des systèmes qui sont totalement compatibles avec Unix/IMAP. Lorsque l’on souhaite utiliser la messagerie unifiée avec des postes traditionnels, on va avoir en plus d’un serveur de gestion de messages, une sorte de passerelle qui va permettre le raccordement physique des bus en provenance des PABX. Cela implique donc des cartes sur le PABX. Le dimensionnement du bus est à évaluer en fonction du nombre d’appels simultanés vers la messagerie en provenance de ces PABX. Enfin, pour la gestion des fax, les solutions incluent généralement un serveur de fax.

Au niveau prix, plusieurs éléments rentrent en ligne de compte. Dans les évaluations que nous avons demandées, celui-ci est généralement fonction du nombre de boites de messagerie actives, du nombre de lignes simultanées sur la messagerie, ainsi que de l’activation ou non de la fonction fax. Il est à noter que le nombre de boites de messagerie est généralement assez faible par rapport au nombre d’utilisateurs. Les évaluations que nous avons faites en fin 2001 donnaient des prix de l’ordre de 30-50K€ pour 100 utilisateurs, 8 liaisons simultanées, plate-formes matérielles comprises, auxquels il faut ajouter le coût des interfaces côté PABX.

5.2 Autres apports Un certain nombre d’habitudes ou façon de penser liées à l’informatique ont permis l’émergence de nombre de fonctionnalités intéressantes au niveau de la téléphonie. Certains de ces aspects induits par l’approche réseau ont été repris par les constructeurs de PABX.

5.2.1 Gestion distante

Un des avantages importants arrivés dans le sillage de la téléphonie sur IP est la gestion distante par interface web, pour les administrateurs comme pour les utilisateurs. Ainsi, pour un administrateur, cela n’impose plus d’avoir une console physiquement reliée au PABX, et rend de fait complètement réaliste le fait d’avoir un seul (groupe d’) équipements pour gérer l’installation téléphonique de plusieurs sites. Pour l’utilisateur, il est maintenant possible de configurer son poste téléphonique, mettre en place les renvois, etc …, depuis n’importe où. Il est nécessaire de bien vérifier la possibilité pour chacun de configurer les postes dépendant de son utilisateur et vérifier les niveaux de fonctionnalités.

5.2.2 Personnalisation des postes

Sur les postes que nous avons testés, il était possible de créer des applications maison, en XML, affichables sur les afficheurs des postes. Seuls les postes de milieu et haut de gamme disposent de cette fonctionnalité. L’énorme avantage est de pouvoir ainsi enrichir les fonctions du terminal. Le contenu XML est accédé à partir d’une simple URL.

6 Conclusion L’impression générale au travers de ces différents essais est que, finalement, la téléphonie sur IP, c’est possible. Autant il y a quelques années, de nombreux problèmes subsistaient, autant aujourd’hui l’ensemble apparaît nettement viable. On voit également bien les différents niveaux de service que l’on peut apporter, et le fait que certains, moyennant une étude approfondie, peuvent constituer un plus très rapidement pour une université. Un point non abordé jusqu’ici et qui est souvent central dans l’appréhension de tels projets est qu’ils sont à l’interface de deux domaines jusqu’ici distincts et gérés la plupart du temps par des services distincts. On a donc une dimension de restructuration des services informatiques et téléphoniques qui n’est pas simple à mener. Toutefois, cela semble inévitable. Si il est une tendance que l’on ne peut nier, c’est que la partie infrastructure (jusqu’aux équipements actifs) tend à s’unifier. Seuls les services au dessus font encore partiellement la différence. Comme on l’a vu plus, certains projets (liaisons inter-commutateurs par exemple) peuvent être menée relativement « facilement », mais il vrai que, pour assurer la pérennité de tels projets, cela nécessite une préparation politique conséquente et une implication des décideurs importante. Enfin, parallèlement à cela, il n’est pas inutile de préparer le terrain « techniquement », en menant une réflexion notamment sur les plans de numérotation, mais aussi sur la qualité de nos réseaux. Les coûts, quoique parfois élevés, restent comparables à ceux d’installations traditionnelles, et il semble donc sensé de bien se préparer pour envisager les différents renouvellements de matériels téléphoniques également sous l’angle de la téléphonie sur IP.

Annexe A : L’installation de l’Université de Provence A l’initiative du chargé de mission réseau de l’Université de Provence, le Centre de Ressources Informatiques a entrepris d’expérimenter la téléphonie sur IP dans le courant de l’année 2001. Le matériel, de marque Cisco, a été installé en septembre 2001, d’abord pour une phase de test, puis a été conservé et est actuellement effectivement utilisé. Le matériel nécessaire à l’évaluation d’une solution de messagerie unifiée a également été testée dans les mois qui ont suivi, mais celle-ci n’a pas été retenue. L’installation actuelle comprend : - un Call Manager (IPBX) situé sur le site de Marseille St-Charles. - un ensemble d’IP-phones répartis sur les sites de St-Charles, Aix, et Château-Gombert. - une passerelle H.323 (routeur avec attachement E1/PRI sur le PABX local) sur le site St-Charles. - une passerelle H.323 (routeur avec attachement E1/PRI sur le PABX local) sur le site Aix.

Figure 7 – L’installation de l’Université de Provence

Les plans de numérotation existants étant incompatibles du fait de recouvrements, le plan de numérotation résultant est un peu complexe :

- Appel poste classique vers poste classique : XXXX (=SDA) - Appel poste IP vers poste IP : XXXX - Appel poste classique vers poste IP : XXXX - Appel tous postes vers poste classique Aix via IP : #1XXXX - Appel tous postes vers poste classique Marseille via IP : #2XXXX - Appel tous postes Marseille vers tous postes Aix via liaison opérateur : 0044295XXXX - Appel tous postes Aix vers tous postes Marseille via liaison opérateur : 0049110XXXX - Appel tous postes vers l’extérieur (via opérateur) : 0+Numero complet

Il a été décidé de ne pas mettre en place d’utilisation transparente des liaisons inter-commutateur, ce qui a mené à la mise en place de préfixes. Pour des raisons techniques non maîtrisées à l’époque, un espace de numérotation spécifique pour les postes IP a été mis en place. Cela ne semble pas pertinent du tout (l’idée est de pouvoir utiliser postes IP et postes traditionnels indifféremment), et il envisagé de modifier cela, probablement lors de la refonte du plan de numérotation.

Références [1] Société IT.CAL, L’actualité dans la Voix sur IP. Séminaire, Mars 2001 (http://www.itcal.com/analyses/20010301.pdf) [2] Jean-Claude Merlin, La téléphonie sur Internet. Rapport Ministère de l 'Economie, des Finances et de l 'Industrie, SEI,

Conseil Général des Technologies de l 'Information(CGTI), Avril 1999 (http://www.telecom.gouv.fr/documents/merlin/rap_merlin0499_1.htm)

[3] Jean-Luc Archimbaud, Philippe Leca, Téléphonie sur IP : Bilan UREC et résultat de quelques tests. Dans Actes du congrès JRES99, Montpellier, Novembre - Décembre 1999. (http://www.urec.cnrs.fr/telip/telip-article-jres.pdf)

[4] Guy Bisiaux, Bernard Rapacchi, Déploiement de la visioconférence dans un établissement : Etat de l’art et évolution des protocoles. Dans Actes du congrès JRES2001, Lyon, Décembre 2001, pp 37-50 (http://www.jres.org/Archives/JRES2001/jres2001CD.pdf)

[5] Cisco Systems, Telephony Signaling (http://www.cisco.com/pcgi-bin/Support/browse/index.pl?i=Technologies&f=792)