Sommaire [Comité Réseau des Universités]

Transcription

1 Sommaire 1. 1 Groupe de travail ToIP : membres, objectifs, réalisations Modèle économique et aspect migration 3. La téléphonie sur IP (ToIP) I. 1 Historique II. 1 Protocoles en jeu III. 1 Quels sont les plus? IV. Protocole : SIP 4. Les types de solutions 5. Maquettes I. 1 Plateforme IPBX II. 1 Interconnexion de sites en SIP 6. 1 Architecture réseau 7. Sécurité et Téléphonie sur IP (ToIP) 8. 1 Les aspects réglementaires 9. 1 Migration vers la ToIP 1 Groupe de travail ToIP : membres, objectifs, réalisations... Le groupe de travail téléphonie sur IP (ToIP) rassemble des ingénieurs des organismes de la communauté académique interessés par le déploiement de solutions de téléphonie sur les infrastructures de l'internet. Plusieurs d'entre eux ont déjà réalisé un déploiement de solution basée sur SIP (Session Initiation Protocol), standard de fait pour ce type de service réseau. 1.1 Organismes "représentés" CNRS INSERM INRIA SYRHANO MENESR GIP RENATER RAP IRD CRU 1.2 Objectifs du Groupe ToIP Partage de savoirs : le premier objectif est de partager les connaissances et les savoir-faire acquis par les personnes composant le groupe, permettant un élargissement des compétences de chacun. Ce champ de connaissances est également élargi aux aspects réglementaires et juridiques à prendre en compte dans la mise en œuvre d'un service de téléphonie au service d'une communauté aussi large que celle du monde de l'enseignement supérieur et de la recherche. Interconnexion des sites : dès que des sites ont déployé une solution de ToIP au profit de leurs usagers, ils cherchent assez naturellement à pouvoir étendre le service à d'autres établissements. Il est apparu assez naturel que RENATER puisse travailler sur ces aspects d'interconnexion de sites en mettant en place un routeur SIP central au sein d'une plate-forme de tests, qui interconnecte tous les sites qui le veulent. Documentation : pour que l'expérience acquise puisse être partagée par le plus grand nombre des administrateurs système & réseau de notre communauté, il est rapidement apparu nécessaire de rassembler dans un document aussi complet que possible les connaissances et les savoir-faire acquis. Ce document en est le résultat. Il pourrait -devrait?- être prolongé par des sessions de formation. 1.3 Réalisations & Evolutions Plate-forme expérimentale : la plate-forme d'interconnexion des sites permet de valider les solutions techniques à conseiller. Cela concerne actuellement une 1/2 douzaine de sites, soit plusieurs milliers de postes téléphoniques. Cette plate-forme devra permettre dans un proche Page 1 sur 39

2 avenir de valider les solutions de supervision/monitoring à mettre en place pour controler les conditions de réalisation du service de téléphonie aussi bien intra-sites qu'entre les sites euxmêmes. En parallèle, des tests de ToIP sur SIPv6 seront réalisés pour certifier les implantations de cette version du protocole. Service Pilote : à terme, si les expérimentations sont concluantes, la plate-forme expérimentale d'interconnexion pourrait devenir un service pilote, encourageant tous les sites académiques ayant installé une solution de ToIP (en propre ou via un opérateur de service) à s'interconnecter pour basculer -autant que possible- leurs flux téléphonie sur l'infrastructure IP de RENATER. 2 Modèle économique et aspect migration Ce chapitre fait une synthèse des différentes étapes du processus qui permet de passer de la téléphonie classique à la téléphonie sur IP. Pour chaque étape, on liste les points essentiels. Une solution IPBX ne remet pas en cause l architecture de coûts de la téléphonie classique puisqu il s agit du remplacement d un PABX analogique par un IPBX assurant des fonctions équivalentes et des services supplémentaires internes au site. L architecture générale du service n est modifiée que pour les appels intersites qui utilisent non plus les liens RTC mais le réseau de données. Dès lors que ce réseau est interne au site universitaire ou mutualisé au sein d un réseau de collecte ou de transport (ex RAP, RENATER, etc), ces appels basculent sur le réseau de données sous la forme de flux supplémentaires. Les appels extérieurs peuvent être des liens intra communautaires fédérés au sein d un réseau privé virtuel managé par une plate-forme mutualisée (OPENSER, ASTERISK etc) ou des liens vraiment extérieurs à la communauté. Dans ce dernier cas l établissement conserve l architecture existante et écoule ses appels vers le RTC au moyen de ses accès RNIS existants. L évolution de la ToIP permet de réduire ce flux et donc de limiter le nombre d abonnement à l opérateur d accès téléphonique. Le coût de l IPBX comprend un coût matériel et le coût des licences logicielles. Ces coûts varient en fonction de la capacité de la machine (nombre d utilisateurs) et de la richesse des services offerts. Ainsi les offres sont-elles extrêmement variables et comportent des options très diverses. Une solution de type Centrex (hébergé, externalisé) consiste à déporter la fonction téléphonique vers une plate-forme de service managée par un prestataire externe. L accès à la plate-forme est assuré via le réseau de données. Le site peut conserver un lien RTC par sécurité indépendamment du Centrex. Dans la version «extrême» la gestion du service téléphonique est ainsi complètement assurée par l opérateur du Centrex : celui-ci assure la gestion de tous les appels, des numéros, de l ensemble du routage, de tous les services. Dans la réalité, un service complètement externalisé intéresse surtout des TPE et ne saurait concerner des établissements de taille importante, qui ne délègueront certainement pas un service aussi sensible que le téléphone à un tiers. Les solutions mises aujourd hui en œuvre (Cf. paris V) reviennent à partager une plate-forme entre plusieurs sites d une même entité ou entre plusieurs entités, à des fins de mutualisation. Décomposition des coûts : 1. Coûts d'investissements I. Coûts de plate forme II. Coûts des terminaux/ remplacement des terminaux analogiques 2. Coûts de fonctionnement I. Coûts de maintenance II. Coûts d exploitation III. Création de nouveaux services IV. Gestion de l annuaire V. Gestion de la taxation VI. Statistiques, supervision VII. Applications propriétaires : centre d appels, serveurs vocaux etc 3. Les coûts de communications I. Les coûts d abonnement : raccordement au réseau local, maintien ligne RTC 4. Communications intersites I. Communications nationales/internationales II. Communications vers mobiles III. Communications vers numéros spéciaux Page 2 sur 39

3 IV. Coûts de portabilité des numéros 5. Coûts d infrastructures I. Câblage interne - mutualisation avec le réseau local informatique II. Equipements réseaux - switchs multi-vlan, avec POE intégré ou non III. Mise à niveau électrique : achat d onduleurs etc 3 Historique La téléphonie sur IP trouve peu à peu sa place dans le paysage des services informatiques disponibles pour les entreprises et le grand public. Les principaux avantages de la téléphonie sur IP sont liés à la mobilité et à la facilité de communication sur l'internet. Les premiers travaux portant sur la téléphonie sur IP datent du milieu des années 90, les applications portaient alors exclusivement sur les communications directes d'ordinateur à ordinateur. Ajourd'hui, la téléphonie sur IP, s'appuyant sur le succès du protocole IP, se retouve aussi bien dans le coeur des réseaux d'opérateurs que dans les entreprises. Parallèlement à cette intrusion non visible directement par les utilisateurs, on voit apparaître des terminaux de téléphonie sur IP sous diverses formes (téléphone fixe, mobile, bi-mode, téléphone logiciel sur PC,..). Ainsi, les acronymes VoIP ou ToIP, autrefois connus des informaticiens seuls, sont aujourd'hui familiers d'un public de plus en plus habitué à utiliser son PC pour téléphoner. 4 Protocoles standards et propriétaires Les équipements constituant un réseau de téléphonie sur IP s'interfacent par leurs implémentations logicielles de protocoles de communication. Ces protocoles sont définis par des organismes de standardisation, tels que l'ietf, l'itu ou l'etsi, qui ont publié les premiers standards au milieu des années 90. Deux types de protocoles se distinguent : les procotoles de signalisation, assurant les fonctions d'établissement et de fermeture de session, ou encore de localisation de service et d'utilisateur ; les protocoles de transport des flux voix (ou vidéo). Seul le protocole RTP (Real Time Protocol) est disponible aujourd'hui. Du côté des protocoles de signalisation, SIP (Session Initiation Protocol) semble avoir pris un ascendant définitif sur les concurrents historiques que sont H.323 (du nom du standard ITU correspondant) et MGCP (Media Gateway Control Protocol), et tous les matériels/logiciels de ToIP récents supportent ce protocole. Cependant, la téléphonie sur IP est en continuelle évolution et vient maintenant s'inscrire dans le cadre plus large des communications sur IP, qui incluent des applications comme la messagerie instantanée et la gestion de présence. Dans ce canevas étendu d'applications, un protocole comme XMPP (Jabber) pourrait se présenter comme un nouveau concurrent de SIP. La téléphonie sur IP fait certes l'objet d'une attention soutenue des organismes de standardisation, mais les implémentations logicielles ne s'appuient pas toutes sur les protocoles standard que sont SIP ou H.323. Ainsi, les instances de Skype, dont le code est fermé, communiquent via un protocole complètement propriétaire. De plus, dans le cadre de la téléphonie d'entreprise, certains services téléphoniques tels que le filtrage patron / secrétaire reposent souvent sur des matériels et logiciels implémentant des extensions propriétaires des protocoles standards. Ainsi, le protocole SIP, développé pour être simple et flexible, délègue explicitement le déploiement de services avancés aux programmeurs, ouvrant ainsi la voie vers les incompatibilités entre les piles logicielles SIP des constructeurs. 5 Interconnexion Malgré tout, les incompatibilités dues aux implémentations logicielles qui peuvent apparaître dans un dialogue protocolaire ne concernent pas les services de base. Sans offrir une palette élargie de services téléphoniques avancés, que ça soit en H.323, SIP ou MGCP, deux logiciels respectant les standards permettront de communiquer sur IP. Aujourd'hui, il n'est pas rare de voir les IP-PBX (PABX supportant au moins une interface IP) équipés d'une interface SIP dédiée : pour la gestion de postes téléphoniques SIP ; pour l'interconnexion avec d'autres IP-PBX. Dans le dernier cas, H.323 pourra aussi être utilisé, mais SIP est aujourd'hui le protocole destiné à interconnecter les IP-PBX entre eux, un peu comme Q.SIG fut envisagé pour l'interconnexion de PABX de Page 3 sur 39

4 marques différentes dans le monde de la téléphonie d'entreprise traditionnelle. 6 Logiciels libres et téléphonie sur IP Le monde du logiciel libre propose des implémentations logicielles des standards depuis plusieurs années. SIP, H.323, MGCP présentent ainsi des implémentations dont le code est exposé à tous. La qualité du logiciel ainsi développé dépend de programmeurs récurrents ou occasionnels et d'utilisateurs avancés, tous motivés pour soumettre le logiciel à un débogage rigoureux et y ajouter de nouvelles fonctionnalités. 6.1 Logiciels serveurs Les logiciels serveurs cités ici sont les plus populaires. Les mailing-lists de leurs projets de développement débordent de messages d'utilisateurs et de développeurs, et les dépôts de code CVS ou SVN sont quotidiennement mis à jour Asterisk Asterisk est un IP-PBX multiprotocole. Il présente des interfaces H.323, SIP et MGCP, mais n'est pas restreint aux protocoles classiques de ToIP, ainsi une implémentation Jingle (support ToIP sur une infrastructure XMPP - Jabber) est disponible dans la version 1.4, ouvrant ainsi les communications vers GoogleTalk. Si Asterisk est développé dans le sens d'une gestion de terminaux quelconques (un téléphone H.323 peut être enregistré sur Asterisk), SIP joue un rôle majeur dans le succès de ce logiciel. Asterisk n'assure pas les fonctions d'un proxy SIP, mais d'un Back-To-Back User Agent et d'un registrar : les terminaux SIP peuvent s'enregistrer sur un serveur Asterisk, et y envoyer les requêtes INVITE qui seront relayées. Par ailleurs, Asterisk dispose d'interfaces de téléphonie classiques : de nombreux types de cartes analogiques et numériques peuvent être insérées, permettant ainsi de se connecter aux liens opérateurs classiques ou aux PABX traditionnels OpenSER / SER SER (SIP Express Router) est un proxy et un registrar SIP. Il assure les fonctions de relayage des requêtes et résponses SIP, et des terminaux SIP peuvent s'y enregistrer. De multiples interfaces d'authentification, de provisionning et de stockage des CDRs (Call Detail Records) sont disponibles. SER (et OpenSER) peut ainsi être relié à des bases SQL et RADIUS. OpenSER est un fork de SER, le code (en licence GPL) de SER a été repris par un groupe de développeurs du projet à la fin de l'année 2005 pour constituer un nouveau logiciel. Le développement d'openser est très actif, et suit de près les nombreux standards publiés autour de SIP. Les fonctionnalités liées à la gestion de présence et à la messagerie instantanée sont ainsi incluses dans le serveur. 6.2 Logiciels clients De nombreux logiciels clients existent, dont le code n'est pas toujours accessible, même si on peut les télécharger librement. Citons parmi eux : XLite, SJPhone, Ekiga, Kapanga. Ces logiciels sont des softphones, des téléphones logiciels fonctionnant sur un ordinateur personnel, à même d'être gérés par les logiciels serveurs citer plus haut. Pour finir, on peut mentionner SIPP, une implémentation cliente simple et flexible du protocole SIP, utilisable dans le cadre exclusif de tests de serveurs SIP. 7 Protocoles en jeu Les protocoles de signalisation assurent la gestion des sessions multimédia (ouverture, fermeture, localisation de service,..). SIP, H.323, MGCP sont des exemples de protocoles de signalisation standards, mais d'autres protocoles propriétaires existent (ex. SCCP, Unistim respectivement pour Cisco et Nortel). SIP, standardisé par l'ietf, se répand chez les opérateurs de téléphonie (il a notamment été choisi dans le cadre de la convergence fixe - mobile par le 3GPP), chez les constructeurs de téléphonie d'entreprise et dans les logiciels libres. Il a pris un avantage net face aux concurrents que sont H.323 ou MGCP, mais devra cependant relever le défi de l'extension aux applications de communication sur IP que sont la messagerie instantanée et la gestion de présence, qui pourraient le mettre en concurrence avec des protocoles comme Jabber - XMPP. Du côté des protocoles de transport des flux média, seul RTP existe à l'heure actuelle. Page 4 sur 39

5 7.1 Signalisation Les protocoles de signalisation autres que SIP (H.323, MGCP) ne sont pas présentés ici en raison de l'omniprésence de SIP dans les équipements et logiciels utilisés dans le cadre des travaux du groupe SIP SIP (Session Initiation Protocol) a été défini par l'ietf dans le RFC 3261, et est toujours l'objet de différents groupes de travail à l'ietf. SIP a été conçu pour assurer la localisation de services et la gestion de sessions multimédia sur un réseau IP. En tant que protocole de signalisation, SIP n'est pas chargé de transporter les flux associés au média transporté, cependant, complété par le protocole SDP (Session Description Protocol), il offre un mécanisme de négociation de session multimedia. Aujourd'hui, les efforts de développement immédiat portent notamment sur la messagerie instantanée et la gestion de présence, étendant encore le champ des applications couvertes par le protocole. En fait, toute application nécessitant un mécanisme de gestion de session peut être l'objet d'un support SIP, ainsi on peut imaginer d'utiliser SIP pour l'établissement de sessions de jeux vidéo Format des messages Le format des messages SIP est basé sur celui utilisé pour HTTP. Tout comme pour HTTP, les messages SIP sont codés en ASCII, et le protocole présente un ensemble de requêtes (appelées méthodes dans la terminologie du protocole) auxquelles correspondent un ensemble de réponses basées sur un code de retour. Ci-après, les méthodes principalement utilisées : REGISTER pour s'enregistrer sur un serveur INVITE pour l'établissement de session ACK confirme l'établissement de la session BYE termine une session en cours La flexibilité est une des caractéristiques du protocole SIP, ce qui lui permet d'inclure facilement de nouvelles applications. Pour ce faire, de nouvelles méthode (ou requêtes) sont développée pour compléter le protocole SIP. Par exemple, pour la gestion de présence les méthodes SUBSCRIBE et NOTIFY ont été ajoutées. Du côté des réponses, on retrouve des codes similaires à ceux d'http : 100 Trying 180 Ringing 200 OK 404 Not Found 486 Busy etc Eléments fonctionnels L'architecture SIP repose sur trois éléments : User Agent (Client et Server), registrar et proxy. La notion de client et de serveur en SIP n'est pas aussi tranchée qu'en HTTP. Les fonctions UAS (User Agent Server) et UAC (User Agent Client) sont incluses dans tout terminal SIP de type téléphone physique ou logiciel. La fonction UAS permet de traiter les requêtes d'établissement et de fermeture de session et de répondre à partir des codes de retour disponibles. La fonction UAC permet d'émettre les requêtes d'établissement et de fermeture de session, et de traiter les réponses reçues de la part des autres éléments fonctionnels. Un User Agent SIP dispose des deux fonctions UAS et UAC Registrar Un serveur Registrar traite les requêtes d'enregistrement REGISTER émises par les terminaux SIP (User Agent). La possibilité offerte aux terminaux SIP de s'enregistrer sur un serveur permet de les localiser. En effet, une fois le processus d'enregistrement achevé, le serveur Registrar stocke l'adresse IP du terminal enregistré, qui sera retournée en réponse à une interrogation de recherche de la part d'une autre entité SIP. L'enregistrement d'un terminal SIP nécessite que ce dernier s'authentifie auprès du serveur Registrar. Page 5 sur 39

6 La méthode d'authentification repose sur la présentation d'un challenge au client, qui renvoie une réponse au serveur. Cette méthode est reprise sur l'authentification HTTP-Digest : Ci-dessous, une illustration du processus d'enregistrement : Proxy Un serveur Proxy sert d'intermédiaire entre deux terminaux désirant communiquer. Sur réception d'une requête d'établissement de session INVITE, le travail du serveur Proxy est de localiser l'uri SIP destinataire. Un serveur Proxy dessert généralement un domaine DNS donné, ce qui permet d'adresser des URIs SIP de la forme sip:prenom.nom@domaine plutôt que sip:[email protected]. L'interrogation DNS pour déterminer l'adresse IP du serveur Proxy lié à un domaine donnée se fait via des requêtes DNS SRV : Pour déterminer l'adresse IP d'un User Agent donné correspondant au domaine administré, un serveur Proxy peut interroger le Registrar associé, qui maintient une correspondance URI - adresse IP. L'exemple ci-dessous décrit un établissement de session classique en SIP. L'utilisatrice Alice (sip:[email protected]), souhaite communiquer avec Bob, enregistré sur le domaine biloxi.com (sip:[email protected]). Alice dispose d'un User Agent configuré pour solliciter le Proxy du domaine atlanta.com à l'établissement des sessions SIP. La requête INVITE initiale est relayée par des Proxys qui déterminent la localisation (adresse IP) de chaque Proxy intermédiaire ou User Agent seloin les mécanismes précédemment exposés. Le flux média RTP ne traverse pas les Proxys intermédiaires, ceux-ci n'interviennent que pour l'établissement de session. De même, en fonction de la configuration du Proxy (en-tête Record Route), la clôture de session peut se faire directement entre SIP User Agents. Page 6 sur 39

7 A titre d'exemple de Proxy et de Registrar, on peut citer les logiciels libres OpenSER et SER B2BUA Un SIP B2BUA (Back to Back User Agent) assure comme un proxy une fonction de relayage des requêtes d'établissement de session. Il dispose de surcroît de la possibilité d'établir des sessions, de les modifier et de les clore. Un SIP B2BUA est une sorte de relais intelligent, capable par exemple de maintenir des tables d'état des appels. A titre d'exemple de SIP B2BUA, on peut citer le logiciel libre Asterisk. 7.2 Transport média : RTP RTP (Real Time Protocol - RFC 1889) est le protocole utilisé pour transporter les données voix ou vidéo entre un ou plusieurs terminaux. Aucun well-known port n'est associé à ce protocole qui, transporté sur UDP, voit ses numéros de ports négociés lors d'une phase préalable d'établissement de session multimédia (SIP, H.323,..). Dans une communication point-à-point, deux flux RTP (un dans chaque sens) sont généralement établis. Les principaux champs constituant l'en-tête RTP sont le type de média transporté (ex. codec audio ulaw) et le numéro de séquence de chaque paquet, donnée indisponible dans les couches UDP et IP inférieures. Le standard prévoit un mécanisme de contrôle de la qualité du flux RTP établi, à l'aide du protocole complémentaire RTCP (Real Time Control Protocol). Ce protocole n'est cependant pas toujours implémenté. RTP n'offre pas nativement de mécanisme de sécurisation, disponible via SRTP (Secure Real Time Protocol - RFC 3711). SRTP permet de chiffrer le flux média transporté. Les éléments permettant de sécuriser le flux média sont doivent être négociés lors de l'établissement de session du type SIP ou H Quels sont les plus? En plus de traditionnel service de téléphonie, les services suivants sont possibles : Audio Conférence Messagerie unifiée (message vocal transmis vers courriel) Services fax2mail ou mail2fax Messagerie Instantanée SMS Visio Conférence Convergence fixe mobile, vous n'avez plus qu'un seul numéro de téléphone Page 7 sur 39

8 Protocole : SIP Le choix du protocole d'interconnexion des IP-PBX s'est naturellement porté sur SIP pour plusieurs raisons : les IP-PBX en place supportent tous ce procotole les logiciels libres envisagés pour constituer l'architecture supportent tous ce protocole, et certains exclusivement (SER, OpenSER) En fait, bien que H.323 fût encore disponible, la seule offre protocolaire commune à l'ensemble des IP- PBX considérés lors du choix de l'architecture était SIP. Interconnexion L'interconnexion d'ip-pbx hétérogènes nécessite, en amont d'un dialogue direct entre les deux IP-PBX via un protocole, la localisation de l'ip-pbx distant. Par exemple, dans un environnement regroupant un grand nombre d'ip-pbx abritant chacun une tranche de numéros distincts, comment solliciter l'ip-pbx assurant le service de connexion du numéro ? Si l'un des IP-PBX abrite l'ensemble de la tranche de numéros XX, c'est avec celui-ci qu'un dialogue SIP doit être établi. Pour répondre à ce problème, on peut : stocker un plan de numérotation sur tous les IP-PBX connectés stocker un plan de numérotation sur un équipement dédié à l'interconnexion La première méthode présente des limites évidentes en terme de flexibilité de configuration et de contrôle d'erreur et ne peut donc pas être retenue. La seconde est préférable, et a été préférée. L'équipement d'interconnexion choisi est le logiciel libre OpenSER : Ce logiciel est un proxy SIP permettant de router les requêtes SIP émises par les IP-PBX de chaque site. Alternativement à la localisation par un équipement centralisé, le service DNS peut être utilisé. Nous présentons plus loin cette possibilité, bien qu'elle n'ait pas été retenue pour interconnecter les IP-PBX de la maquette. Architecture Le proxy SIP constitue la clé de voûte de l'architecture globale. Chaque requête SIP INVITE d'établissement de communication émise par un IP-PBX local est traitée par le proxy selon l'algorithme suivant : si l'uri (Uniform Resource Indicator) contient un numéro de téléphone inclus dans une tranche de numéros connue relayer la requête vers l'ip-pbx correspondant sinon, renvoyer un message indiquant que le numéro est inconnu Not Found Ce principe de fonctionnement implique, de la part de chaque IP-PBX un traitement correct des messages d'échec afin relancer automatiquement l'appel sur un lien opérateur classique. De cette façon, l'utilisateur ayant émis l'appel n'a pas connaissance du fait que la communication transite sur l'internet ou sur un réseau d'opérateur. ENUM, une alternative non étudiée ENUM - Electronic Numbering - est défini dans la RFC La fonction de localisation repose sur le DNS, et permet de faire correspondre un numéro de téléphone à une URI SIP. Par exemple, pour correspondre avec un utilisateur au numéro , une requête DNS doit être émise pour résoudre e164.arpa. En réponse, une URI SIP sera renvoyée, par exemple sip: @provider.net. Les implémentations ENUM propriétaire sont marginales, seuls les logiciels libres comme OpenSER et Asterisk présentent du code utilisable bien qu'encore expérimental. 9 Les types de solution 9.1 Solutions commerciales Centrex Page 8 sur 39

9 Une solution de type Centrex consiste à déporter la fonction téléphonique d'une TGE ou d'une entreprise multi-sites vers une plate-forme de service managée par une seule entité. Cette plate-forme peut être hébergée au sein de l'entreprise (cf Paris v) ou externalisée et managée par une entité interne (cf Paris V) ou externe. Cette solution est aussi très prisée par les TPE qui se séparent ainsi des problèmes de gestion de la téléphonie. La plate-forme Centrex intègre tous les services classiques d'un PABX, fonctionalités téléphoniques, taxation, gestion de l'annuaire, etc. Elle intègre même la gestion des numéros d'urgence pour assurer la localisation géographiques des appels. Cette solution est en fait, dans le cas d'une TGE, la mutualisation des divers PABX ou IPBX gérés généralement site par site. Sa mise en place nécessite donc les mêmes pré-requis que pour la mise en place d'ipbx site par site avec en plus des liaisons réseaux externes de qualitées. C'est quasiment une étape obligatoire avant l'externalisation. Dans ce dernier cas, nous pouvons même imaginer que pour l'entreprise, le coût d'un poste inclu le coût des communications téléphoniques ainsi que le coût de location, regardez sur Internet, beaucoup d'entreprises de Centrex vous propose cette solution. Les solutions Centrex sont en général des solutions d'opérateurs et permettent la gestion indépendante de plusieurs enteprises. A l'origine, c'était l'idée de la mise en place d'une solution de ce type au sein de Rénater qui a permis la création de ce groupe de travail. * TPE : Très Petite Entreprise * TGE : Très Grande Entreprise IPBX La solution MITEL MITEL est une société canadienne basée à Ottawa. Elle a été fondée en Ces principaux bureaux se situent au Canada (siège social), aux Etats-Unis et au Royaume-Uni. C'est une société privée présente dans 70 pays sur les 5 continents Les solutions proposées s'adressent à toutes les types entreprises : de la petite entreprise jusqu'à la multinationale. Les différents produits proposés sont : téléphone IP, PABX IP et applications à valeur ajoutée pour l'entreprise (télétravail, mobilité,...). Mitel est un acteur majeur reconnu dans le déploiement des solutions de communications sur IP. La société possède un département recherche et développement Points forts plus de 30 années d'expertise et d'innovations dans le monde des télécommunications ; interopérabilité de leurs équipements avec ceux des autres constructeurs (gestion de nombreux protocoles de communication) ; 20 millions d'utilisateurs de leurs solutions répartis dans 90 pays ; Points faibles Equipements et applications associées autocommutateur IP Deux modèles sont proposés : l'icp 3300 peut gérer de 10 à utilisateurs et l'icp SX-200 peut gérer jusqu'à 600 utilisateurs. Les IPBX supportent le standard SIP. téléphone IP Différents types de téléphones sont disponibles : du plus basique au plus évolué en fonction de l'utilisation qui en sera faite : téléphone de base ; 5302 : téléphone SIP (il sera disponible en 2008), interface ethernet pour PC, codecs G711 et G729 ; 5212 : téléphone de milieu de gamme, 12 touches de ligne, mains libres (half-duplex), supporte SIP, interface ethernet pour PC, codecs G711 et G729 ; Page 9 sur 39

10 5224 : téléphone de milieu de gamme, 24 touches de ligne, mains libres (full-duplex), supporte SIP, interface ethernet pour PC, codecs G711 et G729 ; 5330 : téléphone haut de gamme, 24 touches de ligne, grand écran LCD, mains libres (full-duplex), supporte SIP, interface ethernet pour PC, codecs G711 et G729 ; 5340 : téléphone haut de gamme, 48 touches de ligne grand écran LCD rétro-éclairé, mains libres (full-duplex), supporte SIP, interface ethernet pour PC, codecs G711 et G729 ; téléphones DECT et Wifi ; 5310 : module d'audioconférence compatible avec les modèles 5224, 5330 et applications NuPoint : application de messagerie vocale et unifiée ; Teleworker : application de gestion des postes IP distants (télétravail, cf ci-dessous) ; Mobile extension : couplage du téléphone IP avec un téléphone DECT, Wifi ou GSM (cf ci-dessous) ; Quick Conférence : pont d'audioconférence ; Your Assistant : softphone et messagerie instantanée interne et sécurisée Fonctionnalités Supervision de lignes ; Groupe d'appels ; Audioconférence ; Transfert d'appels, mise en attente du correspondant. Liste non exhaustive des fonctionnalités avancées apportées par le PABX IP Mitel ICP 3300 : Hot Desk (mobilité) Un utilisateur, disposant d un profil Hot Desk, peut s identifier sur n importe quel téléphone du site ou à son domicile (cf Serveur Teleworker ci-dessous) : il s approprie le téléphone et récupère son environnement (extension, préférences et touches personnalisées). Record a Call Cette fonctionnalité permet d enregistrer une conversion téléphonique afin de la recevoir par mail (fichier audio en pièce jointe). Mobile extension Il s'agit de la convergence fixe-mobile : un seul numéro permet d être joint indifféremment sur n importe quel téléphone (fixe ou mobile). Voice Mail Tous les messages vocaux sont envoyés en attachement d un courrier électronique (fichier audio). Serveur Teleworker Il s'agit d'un proxy qui permet de s'affranchir des problèmes liés au NAT et aux parefeux. Un tunnel sécurisé, initié par le téléphone, est créé entre ce dernier et le serveur. Il est donc possible d'enregistrer des postes connectés à un LAN domestique. La session RTP est établie entre un téléphone IP et le Teleworker : un lien logique est créé entre le serveur et le PABX IP du site. Avec la fonction Hot Desk, l'utilisateur peut donc être joignable sur son numéro SDA depuis son domicile. Tenanting Virtualisation de l autocom : plusieurs sociétés utilisent des ressources partagées (routage téléphonique) et des ressources privées (sortie vers l opérateur téléphonique indépendante, gestion des modes jour/nuit). 10 Plateforme IPBX 10.1 Asterisk, un IPBX sur un CD Asterisk@home, Trixbox ou AsteriskNow sont des distributions Linux, tenant sur un seul CD, à base CentOS intégrant Asterisk ainsi qu'une interface web d'administration. L'intérêt de ces produits est d'être totalement intégrés et permettent ainsi la mise en œuvre rapide d'un IPBX. Asterisk peut, bien évidemment, être installé indépendamment de ces distributions et une version existe Page 10 sur 39

11 pour les plates-formes les plus communes Unix, Linux, Microsoft, Mac, etc Points forts Asterisk assure tous les services communément fournis par un PABX traditionnel : Contrôle des postes Droits d'accès Plan de numérotation Messagerie vocale Audio conférence Menus vocaux interactifs (IVR) Groupe d'appels Détails des communications ( Taxation ) Asterisk et les cartes d'interface analogique Digium et Sangoma proposent des cartes analogiques au format PCI pour l'ipbx Asterisk. Ces cartes, munies d'interfaces analogiques (FXO/FXS), permettent soit de connecter l'ipbx Asterisk au RTC, soit de connecter des téléphones analogiques à l'ipbx. C'est une façon simple et économique de se connecter au RTC ou de prolonger les services offerts par Asterisk vers une installation téléphonique analogique existante. Le FXO et le FXS vont toujours de paire, similaire à la prise mâle et femelle. Les téléphones analogiques se connectent aux ports FXS (Foreign exchange Station) et les lignes de votre opérateur téléphonique se branchent sur les ports FXO (Foreign exchange Office). Description des termes FXS et FXO Cartes analogiques Digium Cartes analogiques (et numériques) Sangoma La carte Digium TDM2400P a été testée avec l'ipbx Asterisk. Elle accepte jusqu'à 6 modules comportant chacun 4 FXS ou 4 FXO. Cette carte peut être pourvue en option de l'anti-echo. Un câble raccorde la carte à une unité de brassage rackable 19'' 1U 24-ports RJ-11. Cette carte est au format PCI Long, aussi il faut prévoir le boitier du PC en conséquence. La TDM400P existe en plusieurs références selon le nombre et le type de modules insérés. La désignation TDM24 est alors suivie par le nombre de modules FXS, puis le nombre de modules FXO, et enfin la lettre E si la carte est pourvue de l'anti-écho, ou d'un B si elle en est dépourvue. La TDM2412E (1*4 FXS, 2*4 FXO, anti-écho) coûte environ 1500 euros avec son unité de brassage 1U 24- ports RJ-11 et le câble pour les relier. Description de la carte Digium TDM2400P Description de l'unité de brassage 1U 24-ports RJ11 Description du câble pour raccorder la carte à l'unité de brassage 1U 24-ports RJ11 Configuration de la carte TDM2412E Les pilotes de périphériques téléphoniques Zapata (zaptel) et les bibliothèques PRI (libpri) sont nécessaires pour le fonctionnement des cartes analogiques. La configuration des canaux FXO/FXS se fait dans le fichier /etc/zaptel.conf Dans ce fichier : - un port FXO est défini par une signalisation FXS qu'il utilise - un port FXS est défini par une signalisation FXO qu'il utilise /etc/zaptel.conf : fxoks=1-4 ; type de prise de ligne FXS sur les ports 1-4 (ici ks indique le protocole de prise de ligne par tension métallique avec détection de déconnexion distante, Kewlstart ks est le protocole en vigueur sur la majorité des installations téléphoniques analogiques existantes en France) fxsks=17-24 ; type de prise de ligne FXO sur les ports loadzone=fr ; indications à utiliser pour le canal (défini dans zonedata.c) defaultzone=fr ; utiliser si aucune zone n'est spécifiée pour un canal Configuration d'asterisk Asterisk utilise le fichier /etc/asterisk/zapata.conf pour déterminer les paramètres et la configuration du matériel téléphonique installé dans le système. Le fichier /etc/asterisk/extensions.conf décrit la configuration du plan de numérotation sur lequel s'appuie Asterisk. /etc/asterisk/zapata.conf : [trunkgroups] ; définition des groupes d'agrégation Page 11 sur 39

12 [channels] ; configuration des canaux matériels busydetect=yes callprogress=yes language=fr ; définition des canaux FXS (groupe de canaux n 1) group=1 context=sortant ; utiliser le contexte [sortant] de extensions.conf signalling=fxo_ks ; utiliser la signalisation FXO pour les canaux FXS channel = > 1-4 ; téléphones analogiques connectés aux ports 1-4 ; définition des canaux FXO (groupe de canaux n 2) group=2 context=entrant ; les appels entrants vont dans [entrant] de extensions.conf signalling=fxs_ks ; utiliser la signalisation FXS pour les canaux FXO channel = > ; RTC connecté aux ports ; définition d'un canal FXO dédié aux numéros d'appel d'urgence (groupe de canaux n 3) group=3 context=entrant ; les appels entrants vont dans [entrant] de extensions.conf signalling=fxs_ks ; utiliser la signalisation FXS pour les canaux FXO channel = > 24 ; RTC connecté au port 24 /etc/asterisk/extensions.conf : [sortant] ; les appels vers le RTC sont dirigés dans ce contexte depuis zapata.conf exten = > _0XXXXXXXXX,1,Dial(Zap/g2/${EXTEN}) ; pour les numéros à 10 chiffres commençant par 0, appeller ce numéro sur le 1er canal ZAP libre parmi le groupe de canaux n 2 (i.e. le groupe de canaux FXO autre que 24ième port FXO) exten = > 18,1,Dial(Zap/24/18) ; pour atteindre les pompiers, systématiquement appeler le 18 sur le canal ZAP/24 dédié aux appels vers les numéros d'appel d'urgence [entrant] ; les appels depuis le RTC sont dirigés vers les bons terminaux exten = > s,1,answer ; répondre à un canal qui sonne exten = > ,1,Dial(Zap/2,10,r) ; pour un appel entrant sur la ligne , Asterisk fait sonner le téléphone branché sur le canal Zap/2 (i.e. sur le 2nd port FXS). La temporisation (2nd argument) est de 10 secondes pour cet extension. Le 3ème argument (la lettre r) force Asterisk à indiquer la sonnerie pour l'appelant et l'appelé. exten = > ,2,Voic ( @default) ; déclencher le répondeur si pas de réponse exten = > ,3,Hangup() ; raccrocher le canal exten = > ,1,Dial(Zap/1&SIP/ ) : ici on fait sonner le téléphone analogique branché sur le canal ZAP/1 (i.e. sur le 1er port FXS) et le téléphone SIP enregistré avec l'extension exten = > ,2,Voic ( @default) ; déclencher le répondeur si pas de réponse exten = > ,3,Hangup() ; raccrocher le canal exten = > ,1,Dial(Zap/3&Zap/4) ; ici on fait sonner deux téléphones quand l'extension est atteinte dans le plan de numérotation : le téléphone branché sur le canal ZAP/3 (i.e. sur le 3ème port FXS) et le téléphone branché sur le canal ZAP/4 (i.e. sur le 4ème port FXS) exten = > ,2,Hangup() ; raccrocher le canal Page 12 sur 39

13 10.2 IPBX MITEL : raccordement de SYRHANO à la maquette Présentation Une éxpérimentation de téléphonie sur IP a été menée à la fin de l'année 2005 sur le réseau régional haut-normand SYRHANO. Elle est décrite plus en détails dans le chapitre xxxxxxxxx. Le but de cette expérimentation est de sensibiliser les équipes techniques et de capitaliser de l'expérience pour des déploiements futurs mais également de valider l'interopérabilité des équipements de différents constructeurs en utilisant le protocole normalisé SIP. Au printemps 2006, des tests ont été menés pour raccorder la maquette mise en place sur SYRHANO à celle de RENATER Raccordement de l'expérimentation menée sur SYRHANO à la maquette mise en place sur RENATER Dans un premier temps, seul le CRIHAN a un lien logique IP avec la passerelle SIP (autocommutateur IP Mitel ICP 3300). Il s'agit dans un premier d'une expérimentation. Cet autocommutateur IP utilisé comme une passerelle SIP permet également d'établir des liens IP avec signalisation propriétaire Mitel pour raccorder des autres autocommutateurs de cette marque. Il est également possible d'enregistrer des téléphones en utilisant la signialisation propriétaire Mitel ou des téléphones SIP type Mitel, Cisco ou X-Lite (softphone). Un lien logique SIP a été créé entre la passerelle SIP (autocommutateur Mitel ICP 3300) et l'open SER RENATER. Au niveau de la table de routage, les appels transitent en priorité sur le réseau IP et en cas de défaillance de ce dernier les communications seront reroutées via le lien local du site vers l'opérateur. Schéma de principe du raccordement de SYRHANO à la maquette mise en place sur RENATER Page 13 sur 39

14 Page 14 sur 39

15 Evolutions possibles remplacement de l'autocom IP Mitel par un Open SER qui serait un routeur d'appels SIP régional à l'image de ce qui est mis en place pour la visioconférence avec les gatekeepers. raccorder d'autres sites SYRHANO à la passerelle SIP, notamment les participants à l'expérimentation menée en fin d'année Interconnexion de sites en SIP Après avoir mis en place des IPBX locaux, l'étape suivante fût leur interconnexion. Dans un premier temps celle-ci a aussi été assurée par un Asterisk, mais très rapidement le groupe est arrivé à la conclusion que ce n'était pas le produit qui conviendrait pour ce service. En effet Asterisk est avant tout un IPBX, avec beaucoup de fonctionnalités qui ne sont pas nécessaires pour assurer l'interconnexion d'ipbx. De plus Asterisk ne permet pas de manipuler facilement les URI SIP. C'est donc avec OpenSER que les divers sites de la maquette sont maintenant mis en relation. Conditions pour accéder à la plate-forme expérimentale d'interconnexion Tout ayant droit RENATER ayant un équipement disposant d'une interface IP et utilisant le protocole SIP peut avoir accès au service SIP de RENATER. Le site doit pouvoir justifier que les plages SDA qu'il demande à router lui sont bien attribuées. Les numéros routés sont composés de 10 chiffres. Principe de fonctionnement Page 15 sur 39

16 Le site souhaitant profiter du service afin d'acheminer ses appels à destination d'autres ayant droit RENATER, n'aura besoin de paramétrer son IPBX qu'une seule fois. Au moins 2 routes devront exister : une route vers RENATER une route vers l'opérateur 1. La route vers RENATER devra toujours être privilégiée en premier lieu. Si le numéro à 10 chiffres correspond à un site ayant déjà lui-même un peering SIP avec RENATER, la demande de mise en relation va être envoyée vers ce site. Si le numéro à 10 chiffres n'est pas connu par le SIP routeur RENATER, le message SIP 404 Not found cas Asterisk ou SIP 504 Server Timeout cas MITEL, est renvoyé au site appelant, c'est ce message qui permettra à l'ipbx appelant de prendre la route suivante. 2. La route suivante peut être n'importe quel autre fournisseur de service, telque que l'accès TDM. Vue d'ensemble de la maquette ToIP Divers types d'ipbx interopèrent au travers d'un routeur SIP central : Alcatel, Asterisk, Mitel Divers types de postes téléphoniques sont utilisés : des postes analogiques raccordés à des PABX traditionnels, et des postes IP (THOMSON ou CISCO) ou SIPphones connectés à un IPBX via le réseau local. VLAN séparés Actuellement les flux voix entre les divers sites sont mélangés avec le reste du trafic IP. Pour assurer une garantie et une qualité de service, il faut envisager de créer un VPN MPLS sur le réseau RENATER, éventuellement étendu aux réseaux de collecte, dédié à la téléphonie. Une classe de service pourra être associée à ce VPN, ayant une priorité supérieure au trafic des données. le VPN aura aussi pour effet de mieux protéger le trafic voix vis-à-vis des écoutes pour les communications non chiffrées. Réseau local L'utilisation d'un VLAN dédié est aussi conseillée sur le réseau local. elle permet de ne pas mélanger les flux voix et données et de pourvoir y associer une classe de service. Par ailleurs la plupart des téléphones IP possèdent un commutateur intégré permettant d'associer un VLAN à chaque port ainsi qu'une classe de service. Schéma de la maquette Page 16 sur 39

17 11 Architecture réseau L application téléphonie sur IP (ToIP) ne saurait se satisfaire d une infrastructure réseau de mauvaise qualité. Le transport de la voix sur IP est soumis à des contraintes temporelles pour atteindre la qualité du réseau téléphonique traditionnel que les applications classiques ignorent. Que ce soit au niveau du réseau local, du réseau de campus, ou du transport de bout-en-bout les applications voix sont très sensibles au temps de traversée du réseau (latence), au taux de perte et à la variation du délai de transmission des données (gigue) quand la charge des réseaux augmente. L architecture du réseau doit en plus satisfaire rigoureusement deux critères : fiabilité et disponibilité. Une bonne connaissance de son réseau et de sa qualité est indispensable pour aborder la mise en œuvre d une solution de ToIP, tout comme sa surveillance quotidienne Réseau local Dans ce chapitre, les différents composants du réseau sont passés en revue en donnant pour chacun les éléments à prendre en compte pour aller vers la mise en oeuvre de la ToIP Composants du câblage Le câblage désigne un ensemble de composants faisant partie de l infrastructure du bâtiment dans lequel ils sont installés : Les racks et baies des locaux techniques (avec alimentation électrique secourue) Les chemins de câbles des rocades et distributions terminales Les rocades («cuivre» ou «optique») intra-bâtiments et inter-bâtiments La distribution terminale Les répartiteurs informatiques et téléphoniques (bandeaux, connecteurs) Les boîtiers et prises terminales Les cordons de brassage Local technique courant faible L application ToIP ajoute des contraintes électriques supplémentaires dans la mesure où l on doit chercher à minimiser les risques d indisponibilité du service : Les postes téléphoniques IP seront en général pour des raisons de disponibilité et de sécurité, alimentés par les équipements réseaux. Une prise banalisée du réseau électrique n est en général pas secourue Le secours électrique devra être dimensionné en tenant compte de cet aspect Les locaux techniques devront disposer d une alimentation électrique sécurisée par des groupes électrogènes ou une double adduction électrique par exemple. Ils seront équipés d un secours électrique local Page 17 sur 39

18 composé d un onduleur et de batteries pour supporter les temps de montée en charge des groupes électrogènes centraux, la puissance fournie devra assurée une autonomie de 10 à 15 minutes. Ils seront alimentés par un circuit électrique secouru indépendant de celui des autres locaux du bâtiment avec autant de prises électriques qu il y a de baies prévues Règles d'ingénierie du câblage Un système de câblage structuré désigne l infrastructure de réseau de transmission d un bâtiment ou d un groupe de bâtiments. Il permet d établir une connexion entre les équipements de communication voix, données, images (VDI), les équipements de commutation, les systèmes de gestion de l information et d autres systèmes ou réseaux extérieurs. La réalisation d un câblage VDI représente un investissement dont la pérennité doit être assurée. Pour cette raison et quel que soit le type de bâtiment, neuf ou rénové, le câblage mis en place doit être : Reconfigurable : les configurations et reconfigurations topologiques à réaliser suivant les réseaux doivent pouvoir être effectuées de manière rapide, économique et sans modification structurelle du câblage ; Banalisé : les câbles de distribution, les prises et leurs conventions de raccordement doivent être identiques en tous points du site, quels que soient les topologies et les types de réseaux devant être supportés ; Universel : l infrastructure est adaptable au transport de tous les types d information (voix, données, images). Pour ce faire, ses composants doivent avoir des performances de transmission au moins égales à celles figurant dans la norme pour la classe supérieure d applications visées (en l occurrence la classe E pour ce chantier). «Avec 27 % des problèmes réseaux attribués aux infrastructures de câblage*, celles-ci ne doivent pas être négligées. En effet, la performance et la continuité de service de votre réseau dépendent directement de l état de l infrastructure de câblage.»*source : cabinet ICM Research. Les liaisons optiques sont généralement réservées, même si la distribution capillaire est en progression, aux rocades dans un bâtiment et aux liaisons entre bâtiments pour lesquelles les liaisons en cuivre sont interdites. La fibre optique, multimode ou monomode, doit être conforme aux normes EN et ISO/IEC Edition 2. La distribution «cuivre» est réalisée à partir de câbles écrantés 4 paires torsadées monobrins. Conformément aux standards EIA, ISO et CENELEC, un chemin de transmission (canal de câblage) entre les équipements se compose de 90 mètres de câbles, et de 10 mètres de cordons et 4 connecteurs. Les normes internationales définissent le type de câblage et les classes d application: Les normes ISO et EN font référence au canal de transmission, pas uniquement aux câbles et connecteurs comme la norme EIA/TIA. A titre d exemple voici les caractéristiques de la norme ISO 11801/2002 qui donne les performances attendues pour un canal de transmission : Page 18 sur 39

19 Un câblage existant doit au moins satisfaire les performances de la classe D, câblage catégorie 5E, qui autorise le Gigabit sur cuivre. Pour un nouveau câblage il convient de s orienter vers la classe E, câblage catégorie 6 ; on assurera que l installation prendra en compte l exigence des normes et le respect des règles de l art dans ce domaine, d autant que sa durée de vie moyenne est de huit ans Equipements réseaux Il est indispensable pour le trafic voix et pour les applications critiques de disposer d une infrastructure à haute disponibilité : Fonctionnalités de redondance et de recouvrement automatique en cas de panne pour une disponibilité 24!7 Gestion avancée de la bande passante pour optimiser les flux prioritaires Fonctionnalités de QoS identiques de la périphérie au cœur du réseau Mécanismes de mise en place automatisée pour les infrastructures de Téléphonie sur IP Les équipements réseaux devront donc garantir : Une fiabilité et une disponibilité proches de 100% impliquant la mise en place d éléments redondants (matrice de commutation, alimentations, ventilateurs ) voire d équipements asso-ciés à des mécanismes spécifiques (ex : VRRP). En effet, lorsque l utilisateur décroche le téléphone, il faut toujours : Avoir la tonalité Que l appel aboutisse Le minimum d interruption en cas de panne d un élément réseau La qualité de service de bout en bout : Pas de distorsion, pas d écho, pas de conversation «hachée» (latence, taux de perte, gigue) La mobilité des téléphones : PoE (Power over Ethernet, IEEE 802.3af) pour alimenter les téléphones ; cela ajoute des contraintes électriques au niveau des locaux techniques mais garantit la maîtrise complète au niveau des services courants faibles. Détection des téléphones IP automatiquement Intégration parfaite avec le WiFi Un certain niveau de sécurité : Protection contre les attaques vers le serveur de signalisation Protection contres les dénis de service Gestion de la confidentialité Une administration aisée et permettre leur supervision (SNMP par exemple) 11.3 Matériels téléphoniques La plupart des déploiements de ToIP se font de manière progressive pour des raisons techniques mais également financières : remise à niveau des réseaux, coût des téléphones IP. La mise en œuvre de téléphones IP s étale donc dans le temps, la plupart des usagers accèdent à la ToIP avec leur téléphone analogique à travers des passerelles. Deux catégories de téléphone IP sont utilisables : Téléphones matériels (hardphone) Téléphones logiciels (softphone) Page 19 sur 39

20 Certains projets font le choix de téléphones matériels, d autres choisissent le mélange ; les deux types de téléphones pouvant disposer des mêmes fonctionnalités Téléphones matériels Pour l utilisateur, surtout avec un adressage numérique comme dans la téléphonie classique, il y a peu de différences dans le mode de fonctionnement. Le poste téléphonique est raccordé au réseau local Ethernet au lieu du réseau téléphonique de l établissement. Au niveau réseau, ces équipements peuvent intégrer : Un commutateur Ethernet 2 ports 10/100 Mbps permettant la connexion au réseau local et la connexion d un PC. Ce dispositif est intéressant s il y a pénurie de prises réseau local. La fonctionnalité PoE (Power over Ethernet, 802.3af), l alimentation électrique étant fournie par l équipement réseau (commutateur, commutateur-routeur). Intéressant en association avec la haute disponibilité des équipements réseaux. Le protocole VLAN IEEE 802.1pq permettant la mise en œuvre de réseaux virtuels dédiés à la téléphonie par exemple. Le protocole TLS (Transport Layer Security, RFC 2246). Il permet l authentification des parties et la confidentialité des données sur Internet ; l authentification se fonde sur des certificats X509v3 ; il permet aussi de détecter la corruption des données. De plus, les données sont compressées. Des facilités de supervision (SNMP). Il est à noter qu à l heure actuelle la quasi-totalité des postes ne supportent que le protocole IPv4. Il y a pourtant une opportunité avec un adressage IPv6 de résoudre le problème de l adressage privé et de la traduction d adresses (NAT) puisqu on aurait systématiquement des adresses publiques pour tous les équipements Téléphones logiciels La téléphonie est alors une application sur le poste de travail de l utilisateur qui n utilise que les ressources de son ordinateur. Il existe des logiciels gratuits et payants. Dans le cas où le softphone est le seul téléphone de l utilisateur, il est évident que seul un logiciel bien maîtrisé par les administrateurs «téléphonie IP» peut être installé sur un poste de travail. Corriger un problème dans ce contexte logi-ciel peut s avérer complexe, l environnement de travail sur un ordinateur pouvant être très différent d un utilisateur à un autre Architecture logique La téléphonie est une application dont les flux doivent être bien maîtrisés au niveau du réseau, il est donc presque naturel de confiner ces flux dans des VLANs dédiés sur lesquels s appliqueront aisément les mécanismes de prioritisation et de sécurité au niveau des routeurs et des pare-feux. C est la solution couramment mise en œuvre par les campus lors de la mise en œuvre de la ToIP. Cependant si cela est assez simple avec les téléphones matériels sachant gérer le protocole 802.1pq, cela s avère pratiquement impossible avec les softphones puisque dans ce cas ce sont les postes de travail qui font office de postes téléphoniques. Au niveau de l adressage IP, en raison souvent du manque d adresse IPv4 les sites s orientent vers un adressage privé (RFC 1918) simplifiant la mise en œuvre au niveau local mais reportant le problème au niveau de l interconnexion ToIP avec l extérieur si l on veut que les communications se fassent de poste utilisateur à poste utilisateur ; l utilisation de NAT pouvant poser problème. Ces deux aspects, VLAN et adressage privé, montrent qu une étude sérieuse tant au niveau du déploiement initiale que des perspectives d évolutions au niveau des services (messagerie unifiée, visio-conférences...) doit être menée par les personnes en charge du réseau et de la ToIP. En règle générale, mais l arrivée des applications temps réel la rende indispensable, il faut mettre en oeuvre des outils de supervision et de monitoring du réseau pour en suivre le comportement et résoudre les problèmes. Notamment, si le mécanisme de prioritisation des flux à travers les classes de services IP est activé il faut disposer d un outil capable de superviser ce mécanisme Réseau de campus Pour garantir un service ToIP de qualité le réseau de campus doit impérativement évoluer vers un réseau à haute disponibilité et fiabilité : alimentation électrique, architecture physique, équipements réseaux. Il va de soi que la supervision du réseau de campus doit prendre en compte le monitoring de la prioritisation des flux afin de répondre aux exigences des applications temps réels nécessitant un traitement spécifique Le bout-en-bout Page 20 sur 39

21 Le bout en bout dans les applications temps réel est une question majeure, la figure montre que les flux audio entre deux utilisateurs traversent de nombreux réseaux qui peuvent avoir des politiques de prioritisation de flux différentes, voire absentes car certains réseaux estiment que la surcapacité répond au problème. Seule l évolution vers la réservation de ressources sur tout le trajet permettra de répondre complètement à cette problématique de qualité de service pour les applications temps réel. Sécurité et Téléphonie sur IP (ToIP) Au delà de la maîtrise des techniques et protocoles permettant le déploiement d'un service de téléphonie, il convient de s'interroger sur les mécanismes de sécurité des équipements et des communications dont on a besoin. Cette réflexion permet aussi de jeter un regard rétrospectif sur les mécanismes de sécurité mis en oeuvre dans la téléphonie classique (par opposition à ToIP)... pour autant que cet exercice ait jamais été réalisé. Les problèmes de sécurité dans la ToIP doivent être pris en compte, comme pour les autres applications informatiques, à plusieurs niveaux. En premier lieu, il convient de considérer les équipements matériels (hardphone / softphone), en second lieu, il faut s'intéresser aux aspects réseaux -qui n'ont la plupart du temps rien de spécifique à la téléphonie (traversée des NAT et firewalls, filtrages, VLAN dédié à la voix,...). Pour centrer l'exposé sur les éléments essentiels, on trouvera ci-dessous des éléments de réflexion sur trois notions : le contrôle d'accès aux ressources : physiques, VLAN, FW (stun, ice...), proxy... la signalisation et le contrôle : SIP, H323,... le transport : (S)RTP, (S)RTCP,... Nous terminerons ce chapitre sur la sécurité par quelques Recommandations. Contrôle d'accès aux ressources physiques, VLAN, FW (stun, ice...), proxy... Dans le premier cas, les dangers essentiels sont l'usurpation d'identité, les interceptions,... Dans le second, les écoutes, les DOS... se prémunir des attaques ARP mettre en place un filtrage des adresses MAC par port cloisonner via un VLAN dédié les communications VoIP contrôle d'accès au niveau IP La signalisation et le contrôle SIP étant le protocole de signalisation le plus répandu, nous présentons ici ses caractéristiques en terme de sécurité, et ne traitons pas des autres protocoles de signalisation standards ou propriétaires (H323, MGCP, SCCP, UNISTIM,...). Page 21 sur 39

22 SIP est adaptable à différentes couches de niveau transport (UDP, TCP, SCTP), qui déterminent fortement le niveau de sécurité de la connexion. Dans la pratique, on trouve des implémentations de SIP sur UDP et TCP, SIP sur SCTP restant encore marginalement implémenté. Historiquement, SIP était destiné à être utilisable sur UDP en priorité, ce qui explique que la grande majorité des logiciels SIP implémentent le protocole sur UDP. Confidentialité Les protocoles tels que IPSec, TLS et S/MIME offrent service de confidentialité par chiffrement (partiel ou total) des champs des datagrammes échangés. Cependant, on notera que dans le cadre d'une communication entre deux SIP User Agents séparés par des proxies, l'architecture SIP n'autorise pas le chiffrement complet des en-têtes SIP. En effet, ceux-ci doivent être accessible en lecture au moins par les proxies SIP traversés. Ainsi, TLS et IPSec pourront être utilisés dans le cadre de connexions point à point (hop by hop), par exemple pour sécuriser l'accès d'un SIP User Agent à un proxy ou registrar SIP. S/MIME sera par exemple utilisé pour sécuriser le corps (SDP - Session description Protocol) des messages SIP échangés entre deux SIP User Agents. Les implémentations des architectures protocolaires SIP/TLS et S/MIME sont encore rares. En revanche, l'utilisation de SIP sur IPSec ne nécessite aucun travail de développement sur le client SIP, et est de ce fait parfaitement exploitable en entreprise. Authentification L'authentification par mot de passe dans SIP permet au client de s'identifier vis à vis du serveur sans transmettre le mot de passe sur le réseau. En effet, un mécanisme de type challenge/response, similaire au protocole CHAP (Challenge Handshake Authentication Protocol), est utilisé. L'authentification par mot de passe est indépendante du protocole de transport utilisé (UCP, TCP, SCTP), mais elle ne permet pas d'authentifier le serveur vis à vis du client, exposant celui-ci à une attaque de type MiTM (Man in The Middle). Notons cependant que le mécanisme challenge/response ne permet pas à un tiers qui réussirait à mener ce type d'attaque de récupérer le mot de passe du client. TLS (Transport Layer Security) et IPSec offrent une authentification mutuelle, par le biais de certificats ou de secrets partagés. Ces protocoles fournissent ainsi des fonctions de confidentialité et d'authentification à SIP dans le cadre de communications point à point. Par exemple, l'accès externe au proxy SIP d'une entreprise peut être restreint aux clients VPN IPSec de celle-ci par des règles de filtrage simples. Le transport C'est lors des échanges de signalisation SIP, que sont négociés les codecs 1) et ports utilisés par le protocole de transport des données. Le protocole de transport des données (audio et/ou vidéo) le plus utilisé est RTP 2) issu du groupe Audio/Video Transport de l'ietf 3) et défini par les RFC ) puis ). Le protocole RCTP 6) assure le contrôle des données acheminées via RTP, mais n'offre aucune garantie quant aux délais de transmission. Description du paquet [RTP] : Version V: Ce champ identifie la version de RTP, la version actuelle est la version 2. Le protocole RTP/RCTP ne possédant aucun mécanisme de sécurisation il est donc susceptible de subir des attaques dont quelques unes sont décrites ci-dessous : Page 22 sur 39

23 Écoute clandestine Cette attaque est la plus simple à effectuer. RTP emploie des codecs standards pour coder des données audio qu'il transporte. La faiblesse principale de RTP exploitée ici est que l'information sur le codec utilisé est disponible dans l'en-tête de chaque paquet RTP dans le champ d'en-tête PT 7). Un attaquant ayant la capacité de capturer le trafic RTP n'a donc aucun problème pour enregistrer et décoder plus tard un flux RTP pour une écoute ultérieure. Un simple snifer réseau tel que ethereal peut reconstituer un échange téléphonique très facilement. Attaques par insertion de datagrammes RTP Ce type d'attaque en englobe plusieurs. La caractéristique commune est que des paquets RTP frauduleux remplacent les licites. Selon la forme des paquets RTP insérés, plusieurs résultats sont possibles. Attaques par collision SSRC Lorsque qu'un paquet de deux sources différentes arrive avec le même SSRC, RTP se trouve en situation de collision. Le mécanisme de gestion de la collision de RTP est simple : si une source découvre qu'une autre source emploie le même SSRC, elle doit envoyer un paquet RCTP BYE pour l'ancien identifiant SSRC et en choisir un autre de manière aléatoire. Si un récepteur découvre que deux sources utilisent le même SSRC, il peut garder les paquets de l'un et jeter les paquets de l'autre ; on s'attend à ce que les deux sources résolvent la collision de sorte que la situation ne dure pas. Analyse de la résolution de collision par RTP, 2 attaques de DoS 8) sont possibles : 1. L'attaquant «vole» le SSRC d'un des pairs et envoie ses propres paquets RTP à l'autre pair. Lors de la réception des paquets avec le même SSRC, le récepteur choisit d'accepter des paquets provenant d'une seule source. L'attaquant peut ainsi effectivement éjecter un utilisateur d'une session RTP. 2. L'attaquant envoie un message RTP avec le propre SSRC de la victime. La victime est obligée d'interrompre la session RTP courante afin de choisir un nouveau SSRC. Ceci a comme conséquence l'interruption de toute conversation impliquant la victime. Autre manipulation de SSRC La manipulation de SSRC peut également être employée d'une manière plus complexe et «plus innovatrice». Si un attaquant sait le SSRC d'un des pairs, il devrait pouvoir forger des messages avec les mêmes caractéristiques de SSRC et d'ip, mais avec des valeurs plus élevées de timestamp et de numéro de séquence que les légitimes. Le récepteur traitera les paquets de l'attaquant avant les paquets légitimes, les paquets légitimes seront considérés comme invalides puisqu'ils ont un timestamp plus ancien. Cette attaque a comme conséquence que le faux contenu audio est joué avant le légitime. Manipulation de codecs Le protocole RTP permet le changement de codec en cours de session, ceci permet à RTP de s'adapter dynamiquement à la qualité du réseau. Si la bande passante disponible diminue, la détection se fait par une augmentation du nombre de paquets perdus, RTP tentera de changer pour un codec prenant moins de bande passante. Des attaques de ce type peuvent conduire à un déni de service en abusant de ce dispositif. Un attaquant avec la capacité d'insérer des paquets valides dans un flux RTP peut dégrader la qualité de la conversation de deux manières opposées. D'abord, l'attaquant peut forcer un changement de codec voix vers un codec plus consommateur de bande passante. Ceci aura comme conséquence une utilisation plus élevée de bande passante, une augmentation de la perte de paquet et finalement peut détériorer la conversation à tel point que plus aucune données audio ne puissent être transmises dans le flux RTP. En second lieu, une attaque opposée est possible, où l'attaquant descend la qualité du codec ce qui peut rendre la conversation impossible. L'alternance rapide de ce type attaques peuvent planter les systèmes ou les forcer à consommer des ressources importantes dans ce processus et ainsi induire une latence importante dans les conversations. SRTP est le protocole à utiliser pour parer aux attaques décrites ci-dessus SRTP 9) offre la confidentialité, l'authentification de message, et la protection contre le rejeu pour les trafics RTP et RTCP. SRTP a été normalisé à l'ietf 10) par le groupe de travail Audio/Video Transport et défini par la RFC ). Page 23 sur 39

24 Solutions possibles pour pallier aux attaques sur RTP Comme cela est le cas pour certaines des attaques basées par SIP, la plupart des attaques basées sur RTP (sauf pour l'écoute clandestine) se fondent sur l'insertion de paquets RTP forgés et insérés au bon moment dans le flux RTP. Sans protection, RTP est considéré comme un protocole peu sûr, forger des paquets malveillants, les émettre aux bons moments est une technique triviale. Recommandations Nota : ce paragraphe pourrait (devrait?) être repris -au moins partiellement- dans les Recommandations du document général. Principe général (rappel) : s'il est louable de s'intéresser à de nouvelles technologies en vue d'offrir de nouveaux services à la communauté des usagers, il ne serait par contre pas responsable de négliger les mesures de sécurité nécessaires, d'une part pour mettre en oeuvre ce nouveau service et d'autre part pour s'assurer qu'il n'ouvre pas de nouvelles vulnérabilités dans le réseau et les services existants. Si la validation technique d'un protocole, d'un service... est une étape préliminaire essentielle, la prise en compte de LA sécurité en générale et de celle des nouvelles fonctionnalités à mettre en oeuvre, en particulier, ne l'est pas moins. Ce principe s'applique bien sûr à la ToIP pour plusieurs raisons : Les communications téléphoniques peuvent nécessiter un niveau plus ou moins important de confidentialité. De ce point de vue, il est donc important de s'assurer que seules les personnes censées être en communication, le sont effectivement... Les choix d'architecture réseau (VLAN dédié à la voix,...) et les possibilités de chiffrement -parmi d'autres- sont essentiels pour répondre à ce besoin. l'outil téléphonique n'a pas le droit de tomber en panne, la fiabilité de l'ensemble des dispositifs (logiciels et matériels) impliqués dans le service téléphonique est aussi crucial, tant il n'est pas concevable de pouvoir s'en passer -ne fut ce que pour une courte période. De même, la qualité de la voix -et donc les dispositifs qui permettent son acheminement dans des conditions optimales (mise en oeuvre de classes de service,...) et permettre un usage normal du service de téléphonie. La disponibilité est le dernier point de cette liste qui ne prétend pas être exhaustive, pour rappeler qu'il est prudent de prévoir des mécanismes de redondance (matérielle et logicielle) et de secours. Les paragraphes qui précèdent ont non seulement tenté d'éclairer sur les risques spécifiques liés à la mise en oeuvre de la ToIP sur un campus, mais aussi proposé quelques solutions pour s'en prémunir. Pour étendre cette réflexion, il nous apparaît indispensable que soit mis en place les dispositifs appropriés pour s'assurer que l'appel des numéros d'urgence soit toujours possible en cas de panne (notamment électrique). La durée de la situation d'urgence doit être estimée en fonction des contraintes locales à chaque site. 12 Les aspects réglementaires Le Code des Postes et des Communications Electroniques (CPCE) impose des obligations fortes à la fourniture du service téléphonique au public. Le présent chapître apporte d'une part des éléments d'information généraux relatifs à ces problématiques et, d'autre part, s'essaie à formuler quelques recommandations de bon sens Qualification réglementaire Il n'existe pas à ce jour de réglementation particulière à la ToIP : les textes ne créent pas de catégorie particulière pour celle-ci et la règlementation s applique à l offre du service téléphonique au public de manière générale. La qualification du service de ToIP qui est progressivement mis en oeuvre au sein de la communauté enseignement supérieur et recherche n'est donc pas anodine. Le CPCE définit (Art L.32 7))le service téléphonique au public comme l'exploitation commerciale pour le public du transfert direct de la voix en temps réel, entre utilisateurs fixes ou mobiles. Ainsi le code conduit à plusieurs interrogations : - la ToIP est-elle un service de téléphonie? - le service est-il rendu au public? - Y a t-il une exploitation commerciale du service? - Qui est responsable de l'exploitation du service? Le service rendu tel qu il est envisagé à ce stade serait bien un service de téléphonie (transfert direct de la Page 24 sur 39

25 voix en temps réel ) dès lors que le niveau de service associé n'est pas du best effort, mais met en oeuvre des solutions techniques permettant de garantir la transmission des données avec un niveau de qualité de service élevé. La qualification commerciale de l'exploitation du service ne saurait être retenue puisqu'en l'espèce l'activité des réseaux ESR ne relèvent pas d'une activité commerciale. Le service rendu ne vise pas le public au sens large mais une communauté d'utilisateurs telle que l'arcep en a donné la définition : ensemble de personnes physiques ou morales constituant une communauté d'intérêt expressément identifiable par sa stabilité, sa permamnence et son antériorité à l'usage effectif du service. Toutefois la taille de la communauté ESR et une certaine mouvance des utilisateurs finals (lorsqu'il s'agit d'étudiants) n'assure pas une réponse définitive à la question de la stabilité. Notamment, lorsqu une université offre des accès Internet en libre accès à des étudiants (bornes Wifi), la question de l ouverture au public n est pas dénuée de pertinence. Si le gestionnaire du service de ToIP souhaite en réserver l'usage à un groupe fermé d'utilisateurs, il lui revient d'assurer un contrôle effectif du groupe qu'il dessert. Il est absolument nécessaire que l établissement soit à même de contrôler les accès au réseau, par une authentification individualisée permettant une reconnaissance individuelle des utilisateurs. Il importe aussi que l établissement impose un engagement individuel de chaque utilisateur pour éviter toute utilisation frauduleuse du service. La notion de responsabilité dans la fourniture du service est particulièrement délicate. Dans le cas d'un service externalisé auprès d'un prestataire, on peut considérer que c'est ce dernier qui fournit le service, le représentant du réseau universitaire se contentant d'un rôle de simple acheteur d'une solution mise en oeuvre par un tiers. Mais, dès lors que l'architecture retenue implique davantage l'action de l'organisme, il est difficile de ne pas le tenir pour responsable du service vis-à-vis de ses utilisateurs Appels d'urgence L article L de la loi dispose : «I. L'établissement et l'exploitation des réseaux ouverts au public et la fourniture au public de services de communications électroniques sont soumis au respect de règles portant sur [...]: f) L'acheminement gratuit des appels d'urgence. A ce titre, les opérateurs sont tenus d'assurer l'accès gratuit des services d'urgence à l'information relative à la localisation de l'équipement du terminal de l'utilisateur, dans la mesure où cette information est disponible ;» Dans la partie réglementaire («Règles portant sur l acheminement et la localisation des appels d urgence») il est précisé : «L'opérateur prend les mesures nécessaires pour acheminer gratuitement les appels d'urgence à partir des points d'accès publics, des points d'abonnement et des points d'interconnexion, vers le centre compétent correspondant à la localisation de l'appelant, en fonction des informations et listes transmises par les représentants de l'etat dans les départements. Il ne reçoit pas de compensation financière de la part de l'etat à ce titre. L'opérateur s'abstient de faire figurer sur les factures les numéros appelés à ce titre. Afin de permettre la transmission des informations relatives à l'acheminement des appels d'urgence, l'opérateur communique ses coordonnées, avant l'ouverture du service dans un département, au préfet de ce département. Il agit de même à chaque modification de ces coordonnées. On entend par appels d'urgence les appels à destination des numéros d'appel d'urgence des services publics chargés : - de la sauvegarde des vies humaines ; - des interventions de police ; - de la lutte contre l'incendie ; - de l'urgence sociale. La liste des numéros d'appel d'urgence est précisée par l'autorité de régulation des communications électroniques et des postes dans les conditions prévues à l'article L Lors d'un appel d'urgence, l'opérateur transmet aux services de secours les données de localisation de l'appelant, lorsque les équipements dont il dispose lui permettent de connaître ces données. On entend par données de localisation l'adresse de l'installation téléphonique, l'adresse de provenance de l'appel ou, dans le cas du service mobile, le lieu géographique de provenance de l'appel le plus précis que lesdits équipements sont en mesure d'identifier.» (-D 98-8) Il convient de souligner que ces obligations s appliquent aux exploitants de réseaux ouverts au public et fournisseurs de services de communications électroniques au public. Toutefois il ne doit pas y avoir de régression de service par rapport à l existant : un organisme privé (entreprise, administration etc.) a des obligations en matière de sécurité vis-à-vis de ses employés et doit mettre en place des procédures d appels vers les services de secours en interne. Dans le cas où le service est externalisé auprès d'un opérateur, il importe de s assurer que celui-ci respecte bien les obligations prévues par les textes : à cet effet prévoir dans les cahiers des charges l acheminement de numéros permettant d accéder aux services d urgence sur chacun des sites en fonction de la localisation de ceux-ci. Page 25 sur 39

26 12.3 Interception d'appels Les obligations en matière de téléphonie sont celles qui s'appliquent en matière de respect de la correspondance privée et les communications sont soumises à ce titre au secret des correspondances privées. La CNIL rappelle sur son site les principes généraux s'appliquant en entreprises : l écoute ou l enregistrement de conversations téléphoniques des employés sur le lieu de travail sont généralement interdites compte tenu des risques d atteinte aux libertés et à la vie privée des salariés ou des agents publics concernés. Ils ne peuvent être réalisés qu'en cas de nécessité reconnue et doivent être proportionnés aux objectifs poursuivis. S'agissant des opérateurs (au sens règlementaire), la loi prévoit une obligation relative à l'interception des appels : «III. - L'opérateur met en place et assure la mise en œuvre des moyens nécessaires à l'application de la loi nº du 10 juillet 1991 relative au secret des correspondances émises par la voie des communications électroniques par les autorités habilitées en vertu de ladite loi. Dans ce cadre, l'opérateur désigne des agents qualifiés dans les conditions décrites dans le décret nº du 28 janvier 1993 relatif à la désignation des agents qualifiés pour la réalisation des opérations matérielles nécessaires à la mise en place des interceptions de correspondances émises par voie des communications électroniques autorisées par la loi nº du 10 juillet 1991 précitée. Les moyens mis en œuvre doivent permettre d'effectuer les interceptions à partir du territoire national.» (D.98-7) Ainsi la mise en oeuvre de dispositifs permettant les interceptions d'appels n'a de caractère obligatoire que sur un réseau public. Le cas échéant, il convient de bien distinguer le partage des rôles en fonction de l architecture retenue (service internalisé ou externalisé), du type d acteurs (habilitation de personnels) et de la capacité des équipements : déterminer la localisation de dispositifs d interception (site ou plate-forme externe?) et le niveau de responsabilité des différents acteurs : au niveau de quel équipement? prévoir une procédure de désignation d agents qualifiés pour effectuer la mise en place des interceptions Conservation des données Le code pose le principe de l'effacement des données relatives au trafic. Les opérateurs de communications électroniques, et notamment les personnes dont l'activité est d'offrir un accès à des services de communication au public en ligne, effacent ou rendent anonyme toute donnée relative au trafic Les obligations portant sur les opérateurs ont été étendues aux personnes qui, au titre d'une activité professionnelle principale ou accessoire, offrent au public une connexion permettant une communication en ligne par l'intermédiaire d'un accès au réseau, y compris à titre gratuit, sont soumises au respect des dispositions applicables aux opérateurs de communications électroniques en vertu du présent article. Cet ajout dans le texte de la loi incite à élargir aux réseaux universitaires les dispositions concernant la conservation des données, le terme de public tel qu'il est utilisé ci-dessus devant manifestement être interprêté dans son sens courant. Une modification importante a été introduite concernant le principe de la conservation des données de connexion : * pour une durée maximale d une année dans deux cas : - des besoins de recherche d infractions pénales - des fins de facturation * pour une durée maximale de trois mois dans un cas : - des fins de sécurisation des réseaux et installations Un opérateur peut aussi utiliser les données de trafic en vue de commercialiser des services ou de localiser l'utilisateur, amis avec le consentement express de celui-ci (sauf pour les appels d'urgence). Les données faisant l'objet d'une conservation sont définies par décret ( ) et sont notamment les suivantes : - Les informations permettant d'identifier l'utilisateur ; - Les données relatives aux équipements terminaux de communication utilisés ; - Les caractéristiques techniques ainsi que la date, l'horaire et la durée de chaque communication ; - Les données permettant d'identifier le ou les destinataires de la communication. - les données permettant d'identifier l'origine et la localisation de la Page 26 sur 39

27 communication. Tableau résumant la réglementation pour les FAI : 12.5 Points connexes Une série d'obligations, outre celles citées ci-avant, s'imposent aux fournisseurs du service téléphonique au public : règles portant sur l identification de la ligne appelante ;conditions de permanence, de qualité et de disponibilité du réseau et du service ; prescriptions exigées par l'ordre public, la défense nationale et la sécurité publique etc. Dès lors que la communauté enseignement supérieur/recherche considère qu'elle ne relève pas de cette qualification règlementaire (service au public), ces règles n'ont pas de caractère obligatoire. Toutefois il conviendra de veiller à respecter la confidentialité et la neutralité des données transmises (contenu proprement dit des communications). Par ailleurs il convient pour l'acheteur public d'être vigilant dans l'allotissement du marché de téléphonie : un même lot (par exemple d'acheminement d'appels téléphoniques) ne peut pas être attribué à deux opérateurs différents. Dès lors, si un établissement souhaite choisir un opérateur pour la ToIP et un autre opérateur pour une liaison de secours via le réseau téléphonique commuté, il doit définir un lot pour chaque service. S'il n'est pas possible de définir un tel allotissement, alors c'est le même opérateur qui doit fournir l'ensemble de la prestation. 13 Migration vers la ToIP 13.1 CAS 1 : Valenciennes Contexte L'université a étudiants, et 5 sites géographiques dont 3 sont raccordés sur un réseau régional capables de supporter du trafic VoIP (service QoS fourni par le prestataire), et 2 raccordés sur le campus principal par des liaisons à 1 Gb/s. Un environnement téléphonique de 1500 postes (1200 SDA) composé de PABX Alcatel (4200, 4300, 4400, OmniPCX). Les équipements sont vieux, la moitié des équipements ne sont plus maintenus par le constructeur depuis 4 ans (le prestataire téléphonique assure toutefois la maintenance par du matériel d'occasion). Compte tenu des nouvelles normes européennes, les nouvelles générations de postes ne sont plus compatibles avec les anciennes versions de PABX. Que se passera t-il lors du renouvellement des contrats de maintenance? Pourquoi une migration vers la ToIP? L'ajout de nouveaux postes téléphoniques nécessitent de passer de nouveaux câbles cuivre à travers le campus universitaire (coût de la prestation entre 300 et 500 " par poste). Actuellement les communications inter-sites utilisent le réseau téléphone des opérateurs ou des liaisons louées, le coût est important. Un PABX central doit être remplacé. L'université dispose d'une infrastructure réseau IP haut débit entre tous les sites. Page 27 sur 39

28 Coûts Environ 150 K" TTC pour 210 postes, un CallManager, deux routeurs (passerelle avec T2), des passerelles pour téléphones analogiques et Fax (210 ports), un PC de taxation, des armoires réseau et quelques commutateurs; Schémas des infrastructures Une première phase a permis de déployer de la téléphonie IP (une centaine de postes) sur le campus principal et sur un site distant. Un CallManager Cisco assure les fonction d'ipbx pour les 2 sites. Il est situé sur le site principal. Une passerelle permet d'assurer l'interconnexion avec les Alcatel. Le site distant dispose d'une passerelle qui permet d'assurer en secours (rupture de la liaison IP entre les deux sites) les fonctions de base du CallManager pour un nombre restreint de poste mais suffisant. Tous les postes n'ont pas été remplacés, de plus il fallait reprendre un nombre relativement important de Fax. Des passerelles assurent l'interconnexion des ces téléphones et Fax sur le réseau IP. Tous les ports des commutateurs ont une configuration automatique pour prendre en compte la CoS (Classe de service de niveau 2). Sur la Page 28 sur 39

29 liaison IP, en Gigabit Ethernet, il n'est pas utile de mettre en place de la QoS IP. Une liaison Q-Sig est réalisée par un T2 privé entre une passerelle et le PABX Alcatel principal. Les téléphones IP communiquent avec les autres téléphones numériques et analogiques du campus. Un mapping est effectué pour appeler tous les postes internes sur une numérotation à 4 chiffres Aspects réseau 1. Vlan dédié 2. sécurité effectuée par un Firewall Checkpoint 3. QoS avec priorité aux flux VoIP à travers le réseau régional Problématique Pas de problème majeur rencontré. Quelques difficultés à faire fonctionner l'ensemble des Fax connectés sur les passerelles (VG) liés à l'impédance. Le problème est presque résolu, un seul Fax pose des problèmes. Quelques problèmes rencontrés aussi au niveau des transferts d'appel des postes analogiques connectés sur les passerelles configurés en MCGP. Problème résolu avec SCCP Conclusion L'université a été confronté à une situation d'urgence suite à des dégâts liés à l'eau. Une décision rapide a dû être prise pour assurer une continuité du service téléphonique. Une étude sur la ToIP venait d'être menée et à facilité beaucoup la démarche. De plus l'architecture réseau mis à niveau constamment a été un élément primordial dans la réussite du projet. En peu de temps la migration ToIP a été effectuée sans problème majeur. Le déploiement va se poursuivre. Plus de 200 postes IP seront opérationnels en 2008, répartis sur les 5 sites distants. La QoS IP sera mise en place sur des liaisons à 10M. Une redondance sera assurée au niveau du CallManager. D'un point de vue qualité, la ToIP apporte un confort significatif au niveau du son Cas 2 : Rennes Contexte une université ( étudiants, 5000 personnels, 12 sites) avec des autocommutateurs vieillissants, répartis sur tous les sites. un MAN et des fibres disponibles un réseau régional capable de faire transiter des flux audio un réseau téléphonie analogique saturé et/ou vieillissant Pourquoi une migration vers la ToIP? Cette solution, quoique peu mature en l'an 2000, semblait la seule en mesure de répondre à plusieurs problématiques : intégration dans le système d'information de l'université appui sur l'annuaire LDAP suppression du cablage spécifique téléphonie acheminement des communications intra-établissement et inter-sites sans recourir aux opérateurs un personnel garde le même numéro de téléphone durant tout son parcours à l'université, quelque soit sa localisation ou son service à terme, utilisation de protocoles ouverts Coûts A l'époque, le cout d'acquisition s'est élévé à 3,8 MF. 300 postes IP seulement ont été acquis, pour minimiser le budget. La société EADS+NORTEL ont remporté le marché, pour un équipement comprenant: Centre de gestion Messagerie vocale Call server 35 SMG (autocom analogique/ip) pour raccordement des postes analogiques 300 postes IP propriétaires Problèmatique de déploiement Page 29 sur 39

30 Seul le basculement a posé des difficultés lourdes en termes d'organisation. Il s'est effectué en une nuit pour les 4000 postes concernés sur 6 sites. La mise au point de la solution a nécessité environ un an : problème de QOS configuration réseau interaction réseau et téléphonie La situation est devenue réellement stable au bout de trois mois, avec des bugs et mises au point durant deux ans, sur des cas ponctuels. Le bilan au bout de 6 ans est en demi-teinte : La maintenance par l'intégrateur est très correcte concernant les aspects strictement matériels Dès que c'est un bug logiciel qu'il faut corriger, l'intégrateur n'a aucun poids et la société Aastra peut prendre des mois pour le traiter. Les 35 matériels de type SMG (autocommutateur analogique/ip) arrivent en fin de vie en 2009, avec une capacité de maintenance jusqu'en 2011/2012 par l'intégrateur. Ceci amène à se poser la question de la durée de vie de ces matériels, notablement plus courte que les autocommutateurs traditionnels. Le système de messagerie vocale (Call Pilot - Nortel) n'est plus maintenu, suite au divorce EADS- NORTEL, fournisseur commun de la solution, à l'origine. Le passage à une autre solution est couteux ( 60Keuros ). Les économies de communication intra-établissements ont été importantes jusqu'à l'apparition du dégroupage et à la chute des communications locales et nationales. Le système est souple et l'administration devrait encore se simplifier avec l'utilisation de postes SIP, qui deviendront, ni plus, ni moins, des terminaux informatiques, gérés à distance. Le positionnement de petits onduleurs dans quelques noeuds réseaux stratégiques a été impératif. Intégration complète de tous les sites (y compris sites distants sur d'autres départements) sur le même plan de numérotation et sur la même infrastructure centrale Un annuaire LDAP dédié à la téléphonie, synchronisé avec la base de données du serveur Centre de Gestion. Les informations sont à jour Problématique utilisateurs Faire comprendre que sans réseau, il n'y a plus de téléphone Faire intégrer systématiquement le cout des téléphones IP propriétaires dans les budgets matériels : à 240 euros le poste IP, de nombreuses entités ont eu des difficultés à trouver les financements Aspect réseaux La politique de l'université a été fixée ainsi pour les nouvelles constructions : Pour un bureau de deux personnes, trois prises réseau, celles-ci servant à la fois pour un poste téléphonique IP et un ordinateur ou une imprimante. Nouveau profil dans l'équipe téléphonique et/ou informatique : L'équipe téléphonie a intégré le CRI et s'est formé «sur le terrain». Après 4 ans, il est apparu des difficultés d'évolution, le référentiel du ministère n'intégrant toujours pas ces fiches de postes. Cette situation a été résolue début La formation est un réel problème : l'acquisition de compétences informatique, indispensables pour la téléphonie sur IP, requiert des cycles longs Evolution Pour pallier à l'obsolescence de la solution, il a été décidé de : faire évoluer les solutions logicielles qui proposent le support de SIP. Ceci permettra à terme la suppression des SMG et le remplacement cadencé sur plusieurs années des postes analogiques par des postes SIP. faire évoluer les serveurs Call Server et Centre de Gestion encore une fois, pour gagner environ 6 ans. Au bout de ce délai, on espère avoir sur le marché des solutions ouvertes adaptées à notre structure (Asterisk, Opensrv, etc) Conclusion Un projet où la situation de précurseur a fait «essuyer les platres» au début du projet Une infrastructure qui rend le service attendu, avec 4000 postes analogiques et environ 700 postes IP propriétaires Une évolution vers les solutions libres ou les protocoles ouverts, pour pouvoir maintenir la solution à un coût raisonnable, tout en augmentant la pérrenité. Page 30 sur 39

31 13.3 CAS 3 : SYRHANO-CRIHAN déploiement fin 2005 Une présentation du déploiement de leur téléphonie a été présentée au séminaire X-Aristote du 27 avril Contexte Une maquette évolutive de téléphonie sur IP a été mise en place dans le but d'interconnecter plusieurs sites raccordés sur le réseau régional SYRHANO. Cette maquette, mise à jour régulièrement du point de vue logiciel et matériel, sera un banc d'essai multi-constructeurs. Les participants à cette maquette initiale sont des établissements d'enseignement supérieur et de recherche : INSA de Rouen CORIA CRIHAN Université de Rouen Université du Havre Pourquoi migrer vers la ToIP? Acquérir des compétences en téléphonie sur IP pour préparer la migration vers IP des systèmes de téléphonie des établissements. Démontrer la capacité de déploiement d'un service de téléphonie sur IP en parallèle aux systèmes conventionnels actuellement en service dans les établissements. Démontrer l'interopérabilité des systèmes de téléphonie sur IP et en préciser les limites en fonction de l'évolution de la normalisation. Préparer et vérifier l'adéquation des infrastructures de communications (épines dorsales, réseaux d'établissements) au transport de services sensibles nécessitant une bonne qualité et une haute disponibilité. Préparer la convergence des services sur IP (vers le tout IP ), comme la visioconfé-rence, les systèmes de messagerie instantanée, les SIP-phones logiciels, le partage de documents, etc. Mutualiser un nouveau service sur le réseau régional SYRHANO pour les communications inter-sites. À terme, proposer des services applicatifs associés. Déployer une infrastructure SIP régionale, avec les outils associés (annuaires, etc.) Expérimenter de nouveaux usages (télétravail, mobilité) Les difficultés rencontrées lors du déploiement Difficultés de communication et de compréhension entre les informaticiens et les téléphonistes : les deux services sont concernés par cette évolution et doivent travailler ensemble. Intégration du PABX IP au système existant : gestion des classes de services et classes de restrictions, mise en place des boîtes vocales et routage téléphonique entre les deux autocoms. Formation des personnels indispensable. Formation des utilisateurs à l'utilisation des nouveaux équipements. Définition de l interconnexion des PABX IP (full mesh ou équipement central, plan de numérotation entre les sites) Coûts Chaque site a reçu, pour débuter l'expérimentation, un autocom IP et dix téléphones IP avec les licences d'utilisation associées (mobilité, messagerie vocale, interface E1 et trunk IP). Cet ensemble a un coût d'environ " Description de la maquette et configuration locale à cahque site Le schéma ci-dessus présente la maquette mise en place sur SYRHANO : Page 31 sur 39

32 Afin de minimiser les interactions entre la maquette et le réseau de production, le PABX IP est installé en coupure entre le RTC et le PABX traditionnel de chacun des sites. Sans aucune configuration sur les équipements existants, les communications entre les sites SYRHANO sont routées via IP. Avec une route statique configurée sur l'ancien PABX vers les préfixes téléphoniques attribués aux postes IP, il est possible d'utiliser des numéros abrégés entre les postes existants et les nouveaux postes IP. Les PABX IP de chacun des sites sont également logiquement (tunnel IP) raccor-dés entre eux en full mesh. La signalisation entre ces équipements est propriétaire. En fonction de l évolution de la normalisation et de la disponibilité des produits, la plate-forme pourra évoluer vers une architecture ouverte et le protocole de signalisation utilisé sera SIP. Plan de numérotation adopté Numérotation décimale : pas de nom de domaine SIP pour le moment. Utilisation des numéros SDA des sites : numérotation à 10 chiffres pour assurer la résilience en cas de défaillance d un lien IP. Mise en place de route-list : la résilience est transparente pour l utilisateur. Il compose le numéro de son correspondant, celui ci est routé via le lien IP si ce dernier est actif, dans le cas contraire il transite via le réseau téléphonique classique. Différentes étapes de l'épérimentation : Etape 1 : raccordement des différents équipements en utilisant la signalisation propriétaire (Minet pour Mitel et Skinny pour Cisco). Etape 2 : raccordement des équipements en utilisant le protocole SIP ; dans cette situation la signalisation est moins riche (pas de possibilité de supervision de ligne,...), tests d interopérabilité entre des équipements de constructeurs différents (Cisco et Mitel pour notre expérimentation). Etape 3 : utilisation généralisée du protocole SIP ; enregistrement de softphones, de téléphones IP, intégration du pont de visioconférence à la maquette,... Chaque site a reçu : Un PABX IP avec une capacité de raccordement de plusieurs équipements analogiques et deux interfaces E1 (raccordement RTC et PABX conventionnel). Une dizaine de téléphones IP (full duplex, avec haut-parleur intégré pour mains li-bres), avec les licences d'utilisation. Les licences d utilisation pour environ 20 boîtes vocales. Des licences HotDesk (renvoi des appels, etc.) : cette fonctionnalité permet de définir un environnement personnel par utilisateur avec des préférences et des fonctionnalités. L utilisateur pourra ainsi les récupérer sur un autre poste téléphonique IP. Les licences requises pour interconnecter plusieurs PABX IP. Les licences requises pour utiliser les interfaces E1. Page 32 sur 39

33 Services supplémentaires apportés La mise en place de la novuelle solution de téléphonie a permis de prospoer aux utilisateurs de nouvelles fonctionnalités : Hot Desk (mobilité) Un utilisateur, disposant d un profil Hot Desk, peut s identifier sur n importe quel téléphone du site ou à son domicile (cf Serveur Teleworker ci-dessous) : il s approprie le téléphone et récupère son environnement (extension, préférences et touches personnalisées). Record a Call Cette fonctionnalité permet d enregistrer une conversion téléphonique afin de la recevoir par mail (fichier audio en pièce jointe). Mobile extension Il s'agit de la convergence fixe-mobile : un seul numéro permet d être joint indifféremment sur n importe quel téléphone (fixe ou mobile). Voice Mail Tous les messages vocaux sont envoyés en attachement d un courrier électronique (fichier audio). Serveur Teleworker Il s'agit d'un proxy qui permet de s'affranchir des problèmes liés au NAT et aux parefeux. Un tunnel sécurisé, initié par le téléphone, est créé entre ce dernier et le serveur. Il est donc possible d'enregistrer des postes connectés à un LAN domestique. La session RTP est établie entre un téléphone IP et le Teleworker : un lien logique est créé entre le serveur et le PABX IP du site. Avec la fonction Hot Desk, l'utilisateur peut donc être joignable sur son numéro SDA depuis son domicile. Tenanting Virtualisation de l autocom : plusieurs sociétés utilisent des ressources partagées (routage téléphonique) et des ressources privées (sortie vers l opérateur téléphonique indépendante, gestion des modes jour/nuit) Aspect réseaux Chaque site adopte la même politique. Page 33 sur 39

34 Vlan et adressage Un Vlan dédié à la téléphonie a été mis en place. Dans le cadre de notre expérimentation, il s agit de communications inter-sites directes : tous les téléphones IP et les PABX IP ont donc des adresses IP publiques. Il faut également modifier la configuration de certains serveurs DHCP dans le cadre de l utilisation du switch intégré au téléphone IP : ajout d options dans les serveurs DHCP et paramétrage des équipements réseaux (commutateurs). Pare feux Il est nécessaire d'ouvrir plusieurs ports (liste fournie dans la documentation du constructeur) : pour la signalisation des appels et pour les data (voix). Qualité de service Au niveau de l épine dorsale de SYRHANO, des fonctionnalités de gestion de la qualité de service seront activées (classes de service). En fonction des besoins, ces mêmes classses de services seront mises en place sur les réseaux d établissements Impact sur la charge de travail Dans chaque établissement, le service réseaux a vu sa charge de travail augmenter. C'est elle qui a en charge la gestion du PABX IP et des téléphones IP. Cela demande un gros investissement au départ afin d'assimiler les compétences du téléphoniste pour l'informaticien mais après l'installation et le paramétrage des différents équipements, la gestion de l'ensemble requiert peu de temps. L'avantage est la maîtrise des équipements. Il est possible de modifier la table de routage du PABX IP sans faire appel à une société de maintenance Conclusion De nouvelles fonctionnalités ont été proposées aux utilisateurs. La gestion des équipements est assurée par le personnel technique de l'établissement. Il n'est plus nécessaire de faire appel à une société tierce pour intervenir et modifier la configuration du PABX. Acquisition d'éxpérience sur ces nouvelles technologies CAS 4 : Migration vers la ToIP Grenoble Universités Contact : Raoul Dorge GRENET Contexte Un projet de renouvellement du réseau téléphonique est actuellement mené par Grenoble Universités pour le compte des 3 établissements : univ. P. Mendès-France, univ. Stendhal et l'institut National Polytechnique de Grenoble. Ce projet porte sur ~ 5000 lignes téléphoniques Pourquoi une migration vers la VoIP? D'une part, le parc actuel était vieillisant (Opus 4300 pour 80% des usagers, maintenance de plus en plus délicate), d'autre part, l'architecture était assez hétérogène (outre les 4300, il y a aussi des Alcatel 4400 et des Matra/Nortel, soit une dizaine d'autocoms). La solution retenue permet de déployer aussi bien des postes IP que des postes traditionnels (via des médiagateways). Le choix de la technologie a été laissé libre aux établissements. Ainsi l'inp a fait le choix vers la VoIP (pour une bonne partie de leurs usagers) alors que les 2 universités ont fait confiance aux technologies classiques et éprouvées Etude des solutions Un projet pilote, réalisé mi-2005, a permis, via un appel d'offre, de comparer les offres et services de 3 intégrateurs. Ce projet pilote était clairement positionné comme brique de base du projet actuel. Les ressources téléphoniques avait donc été dimensionné en conséquence (excepté les licences) Services supplémentaires apportés Le projet a pour but de renouveler à l'identique, c'est à dire que les postes analogiques sont conservé alors que les postes numériques sont remplacés (par un poste numérique ou son équivalent IP). Cet objectif principal a été étendu par : - généralisation de la messagerie vocale (tout le monde peut Page 34 sur 39

35 prétendre a une boite vocale) - couplage IMAP de la messagerie vocale pour pouvoir écouter un message vocal depuis son client de messagerie - passerelle fax pour envoyer/recevoir des fax depuis son client de messagerie - téléphonie logicielle (softphone) pour répondre à des besoins de mobilité - SVI (Serveur Vocal Interactif) Ces derniers services restent encore à développer, la priorité actuelle étant le renouvellement de l'infrastructure de base Coûts Environ 820 k" ttc qui comprend : - prestation (importante) de câblage (et fourniture de baies) - médiagateways (et leurs batteries) - postes téléphoniques (IP et numérique) - postes opératrices - licences Ne sont pas compris : - les matériels réseau (commutateurs et convertisseurs) - les onduleurs pour secourir les équipements réseaux Problèmatique de déploiement Projet segmenté en 4 tranches (inégales), nous sommes toujours en cours de déploiement de la 1ère tranche (la plus importante). Globalement, le déploiement se passe bien, voire très bien pour l'ampleur de projet. Il y a bien sur quelques cas particuliers à résoudre et qui prennent relativement beaucoup de temps : fax, modem, alarmes. Prestataire sérieux, compétent et réactif. De même, pour la partie cablage (distribution sur bandeau RJ45 avec mise en Y ), très bonne prestation du technicien. D'autre part, difficultés pour synchroniser l'avancement du chantier avec l'opérateur public (source d'encombrement de nos liens internes) Aspect réseaux Tout le transport se fait sur IP, avec un sité principal (Campus de St Martin d'hères) et 5 sites de l'agglomération grenobloise. Sur le campus, déploiement d'une infrastructure dédiée commutée (niveau 2). Sécurité traitée par acl statique Cohabitation de l'ancien système et du nouveau Interconnexion par T Nouveau profil dans l'équipe téléphonique et/ou informatique Au niveau de la DSI-Grenoble Universités, équipe de 3 personnes dont 1 vrai téléphoniste (complémentarité des compétences). Montée en compétence progressive pour les personnes d'origine informatique Schémas Page 35 sur 39

36 Page 36 sur 39

37 13.5 CAS 5 : Université de Lille1 A mettre en forme Opération téléphonie initiée suite au constat d'un très vieil autocom centralisé sur le campus à remplacer. Dès le début de l'étude, la To/IP n'a bien entendu pas été écartée. Les solutions autocom sont maintenant des solutions réparties. Le réseau IP étant opéré par le CRI, compte tenu d'un très haut taux de disponibilité demandé pour la téléphonie et devant l'impossibilité pour le CRI d'entrer dans des systèmes d'astreintes pour les week-end, vacances et jours fériés, il a été décidé de créer un réseau téléphonie séparé opéré par la société retenue. Société retenue : INEO COM PABX : IP-PBX Alcatel OmniPCX La To/IP n'a pas été totalement écartée et 200 postes tél/ip ont été commandés. L'utilisateur qui a un poste tél/ip le choisit en connaissance de cause, il sait que la disponibilité est la même que pour le réseau data. Les différents autocoms sont interconnectés par fibres optiques dédiées, par liens T2 privés en QSIG ABC- F (ABC = Alcatel Business Communications amélioré compatible avec le standard QSIG-GF) et sont répartis sur les différents secteurs du campus. Un bon nombre de ces PABX ont un lien T2 opérateur (secours). PABX ont été placés dans les mêmes locaux techniques que ceux hébergeant les équipements réseaux. Réfection des locaux avec climatisation et onduleur pour les PABX. Page 37 sur 39

38 2 autocoms déportés par liaison éthernet 100 Mb/s : CUEEP Lille et IAE Lille Tous les PABX ont un raccordement sur un VLAN spécifique USTL sur lequel transite les info de services, taxation, annuaire,... DHCP pour les tel / IP Nous n'avons pas réussi à mettre en évidence l'intérêt de mettre en place la QoS, nous ne l'avons donc pas déployé. Annuaire : conforme LDAP et une procédure de synchronisation avec l'annuaire USTL opéré par le CRI est en place Messagerie unifiée avec connecteur messagerie, client Web Plan de numérotation très peu modifié avec passage des numéros courts de 4 à 5 chiffres pour les évolutions. Mise en service To/IP fin 2006 L'opération de basculement s'est déroulée correctement sans problèmes notables. Pas de problème à ma connaissance pour les tél/ip Un correspondant téléphone pour le campus (un ASI), interlocuteur direct USTL pour la société INEO. Toute la partie téléphonie USTL est opérée par la société INEO Com CAS 6 : Université de Nancy2 Contact : Vincent Mathieu Contexte/Résumé On a fait un appel d'offre il y a un an. Le prestataire chosi est axians Nancy. Axians est déja notre prestataire et celui du ciril pour tout le matériel réseau. On a choisi le callmanager de cisco (version 5). Il y a 2 callmanager en redondance / partage de charge, sur 2 sites différents, et 2 passerelles voix également sur 2 sites différents. Pour le moment, une T2 completel est raccordé à chaque passerelle. C'est très large pour le moment, mais au fur et à mesure de l'extension de la toip, on sera amené à rajouter de nouvelles T2, mais on se limitera à 2 passerelles. Ces passerelles sont également en partage de charge. Les appels sortants peuvent emprunter l'une ou l'autre passerelle, les appels entrants également : on a une sda de 2000 numéros, completel balance les appels entrants vers l'une ou l'autre passerelle indiféremment. On procède par petits pas : - on a équipé un campus (le Pole Lorrain de Gestion, la ou je travaille) au début de cette année (en fait, depuis octobre-novembre, et c'est en prod réelle depuis le 1er janvier). Environ 200 postes. - au second semestre, on équipe un IUT, et on remplace divers petits standars éparpillés à droite ou à gauche. - et ainsi de suite. Fin 2009, on devrait avoir couvert toute l'université en toip, soit près de 2000 postes Pourquoi une migration vers la ToIP? PABX en fin de vie. La ToIP semble mure maintenant, il aurait été dommage de 'partir' sur de la téléphonie traditionnelle. Et une souplesse qui nous permet d'équiper facilement en téléphonie de nouveaux locaux Etude des solutions Un appel d'offre. Seulement 2 réponses : - une offre cisco (callmanager) - une offre alcatel Services supplémentaires apportés Pour le moment, par rapport à un pabx moderne, pas grand chose (sauf une fonctionnalité de meeting intéressante). Mais les vieux pabx que nous remplacons n'offraient quasiment pas de services en dehors d'une téléphonie basique ; la mise en oeuvre de la ToIP apporte donc des plus aux utilisateurs Coûts - infrastructure réseau : remplacement de switchs traditionnels par des switchs PoE - cout en infrastructure ToIP assez faible : 2 callmanager et 2 passerelles voix. - cout des postes téléphoniques élevés - en fait, on fait une économie très importante sur les couts d'abonnement (nombreuses T2 louées sur les différents campus) et de maintenance des autocoms. Page 38 sur 39

39 Problématique de déploiement On procède par étape : campus par campus, en fonction de la vétusté des équipements, et des économies potentielles. Les postes IP sont équipés de switchs internes avec 2 pattes ethernet ; il sont raccordés au réseau via une prise RJ45 reliée à un switch POE, et le PC de l'utilisateur est raccordé à l'autre patte ethernet. Le paramétrage du callmanager est réalisé en central. Les informaticiens de campus installent les postes en coupure des PC. ils disposent d'une interface web d'administration des switchs permettant de préciser que le port de switch supporte un téléphone ip Aspect réseau - 2 call manager, sur 2 sites différents - 2 passerelles voix (cisco 2811) sur 2 sites différents - un vlan serveurs téléphonie pour les 2 call manager et les 2 passerelles - un vlan téléphonie par campus - un vlan téléphonie wifi Chaque poste accepte 2 vlans : un vlan voix et un vlan data pour le PC raccordé Cohabitation de l'ancien systeme Nous avons commandé une nouvelle SDA de 2000 numéros, pour accueillir à terme l'ensemble de la téléphonie de l'université. Il y a donc changement du plan de numérotation Nouveau profil dans l'équipe téléphonique et/ou informatique La téléphonie classique n'était pas gérée auparavant : chaque campus était autonome, il n'y avait pas de personnel dédié. Il fallait faire appel à un prestataire pour toute modification relative au téléphone. C'est maintenant l'équipe système et réseau de l'université (4 personnes en tout) qui prend en charge cette activité. Pour le moment, à personnel constant... La ressource téléphonique est maintenant mutualisés : serveurs (call manager et passerelles), raccordements T2,... Nous avons du développer une application permettant une refacturation interne des couts téléphoniques. nous sommes également en train de développer une interface web permettant de déléguer les opérations courantes (classes d'appel des postes,...) à des correspondants de campus. 1) codeur/decodeur 2) Realtime Transport Protocol 3), 10) 4) 5) 6) Realtime Control Transport Protocol 7) Payload Type 8) Denial of Service 9) Secure Realtime Transport Protocol 11) Page 39 sur 39