Vous êtes sur la page 1sur 39

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

 

17/06/08 12:24

 

Sommaire

 

1. 1 Groupe de travail ToIP : membres, objectifs, réalisations

 

2. 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 

 

INSERMOrganismes "représentés"   CNRS   INRIA SYRHANO     MENESR   GIP RENATER

INRIA"représentés"   CNRS   INSERM SYRHANO     MENESR   GIP RENATER

SYRHANO 

 
 

MENESR 

 

GIP RENATER   

 

RAP 

 

IRD  MENESR   GIP RENATER   RAP   CRU 1.2 Objectifs du Groupe ToIP   Partage

CRUMENESR   GIP RENATER   RAP   IRD 1.2 Objectifs du Groupe ToIP   Partage de

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.l'enseignement supérieur et de la recherche.   Documentation : pour que l'expérience acquise puisse

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.de tests, qui interconnecte tous les sites qui le veulent. 1.3 Réalisations & Evolutions   Plate-forme

1.3

Réalisations & Evolutions

 
Plate-forme expérimentale : la plate-forme d'interconnexion des sites permet de valider les solutions techniques à

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

 

http://www.cru.fr/activites/groupes_travail/voip/document

 

Page 1 sur 39

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

17/06/08 12:24

 

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 eux- mê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

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

http://www.cru.fr/activites/groupes_travail/voip/document

Page 2 sur 39

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

 

17/06/08 12:24

 

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.de localisation de service et d'utilisateur ;     Du côté des protocoles de signalisation, SIP

 

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.pour la gestion de postes téléphoniques SIP ;     Dans le dernier cas, H.323 pourra

 

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

 

http://www.cru.fr/activites/groupes_travail/voip/document

 

Page 3 sur 39

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

 

17/06/08 12:24

 

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.

 

6.1.1

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.

6.1.2

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.

http://www.cru.fr/activites/groupes_travail/voip/document

Page 4 sur 39

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

17/06/08 12:24

 

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.

7.1.1 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.

7.1.1.1

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 pour s'enregistrer sur un serveur

INVITE pour l'établissement de session pour l'établissement de session

ACK confirme l'établissement de la session confirme l'établissement de la session

BYE termine une session en cours 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

Trying100

180

Ringing180

OK200

200

Not Found404

404

486

Busy486

etc.Trying 180 Ringing OK 200 Not Found 404 486 Busy 7.1.1.2 Eléments fonctionnels L'architecture SIP

7.1.1.2

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.

7.1.1.2.1 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.

http://www.cru.fr/activites/groupes_travail/voip/document

Page 5 sur 39

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

17/06/08 12:24

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 :

http://www.ietf.org/rfc/rfc2617.txt

Ci-dessous, une illustration du processus d'enregistrement :

une illustration du processus d'enregistrement : 7.1.1.2.2 Proxy Un serveur Proxy sert d'intermédiaire

7.1.1.2.2 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:prenom.nom@proxy.domaine.

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 : http://www.voip-info.org/wiki-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:alice@atlanta.com), souhaite communiquer avec Bob, enregistré sur le domaine biloxi.com (sip:bob@biloxi.com). 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.

http://www.cru.fr/activites/groupes_travail/voip/document

Page 6 sur 39

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

17/06/08 12:24

 
 

A titre d'exemple de Proxy et de Registrar, on peut citer les logiciels libres OpenSER et SER.

7.1.1.2.3 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.323.

8 Quels sont les plus ?

En plus de “traditionnel” service de téléphonie, les services suivants sont possibles :

Audio Conférencede téléphonie, les services suivants sont possibles : Messagerie unifiée (message vocal transmis vers courriel)

Messagerie unifiée (message vocal transmis vers courriel)les services suivants sont possibles : Audio Conférence Services fax2mail ou mail2fax Messagerie Instantanée SMS

Services fax2mail ou mail2faxMessagerie unifiée (message vocal transmis vers courriel) Messagerie Instantanée SMS Visio Conférence  

Messagerie Instantanéevocal transmis vers courriel) Services fax2mail ou mail2fax SMS Visio Conférence   Convergence fixe mobile,

SMSServices fax2mail ou mail2fax Messagerie Instantanée Visio Conférence   Convergence fixe mobile, vous

Visio Conférence 

 

Convergence fixe mobile, vous n'avez plus qu'un seul numéro de téléphoneMessagerie Instantanée SMS Visio Conférence   http://www.cru.fr/activites/groupes_travail/voip/document

http://www.cru.fr/activites/groupes_travail/voip/document

Page 7 sur 39

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

17/06/08 12:24

 

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 procotolenaturellement porté sur SIP pour plusieurs raisons : les logiciels libres envisagés pour constituer

les logiciels libres envisagés pour constituer l'architecture supportent tous ce protocole, et certains exclusivement (SER, OpenSER)raisons : les IP-PBX en place supportent tous ce procotole En fait, bien que H.323 fût

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 01 23 45 67 89? Si l'un des IP-PBX abrite l'ensemble de la tranche de numéros 01 23 45 67 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être établi. Pour répondre à ce problème, on peut : stocker un plan de numérotation sur

stocker un plan de numérotation sur un équipement dédié à l'interconnexionun plan de numérotation sur tous les IP-PBX connectés La première méthode présente des limites évidentes

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 : http://www.openser.org. 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 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

un numéro de téléphone inclus dans une tranche de numéros connue relayer la requête vers l'IP-PBX

sinon, renvoyer un message indiquant que le numéro est inconnu - 404 Not Found 404 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 3761. 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 +33 1 23 45 67 89, une requête DNS doit être émise pour résoudre 9.8.7.6.5.4.3.2.1.3.3.e164.arpa. En réponse, une URI SIP sera renvoyée, par exemple

sip:33123456789@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

9.1.1 Centrex

http://www.cru.fr/activites/groupes_travail/voip/document

Page 8 sur 39

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

17/06/08 12:24

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

 

9.1.2 IPBX

9.1.2.1 La solution MITEL

 

MITEL est une société canadienne basée à Ottawa. Elle a été fondée en 1972. 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.

9.1.2.1.1

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) ;dans le monde des télécommunications ;   20 millions d'utilisateurs de leurs solutions répartis

20 millions d'utilisateurs de leurs solutions répartis dans 90 pays ;(gestion de nombreux protocoles de communication) ; 9.1.2.1.2 Points faibles 9.1.2.1.3 Equipements et

9.1.2.1.2 Points faibles

9.1.2.1.3 Equipements et applications associées

autocommutateur IP

autocommutateur IP

Deux modèles sont proposés : l'ICP 3300 peut gérer de 10 à 65 000 utilisateurs et l'ICP SX-200 peut gérer jusqu'à 600 utilisateurs. Les IPBX supportent le standard SIP.

 
téléphone IP

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 ;5201

5201

: téléphone SIP (il sera disponible en 2008), interface ethernet pour PC, codecs G711 et G729 ;5302

5302

: téléphone de milieu de gamme, 12 touches de ligne, mains libres (half-duplex), supporte5212

5212

 

SIP, interface ethernet pour PC, codecs G711 et G729 ;

http://www.cru.fr/activites/groupes_travail/voip/document

Page 9 sur 39

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

17/06/08 12:24

 
  5224 : téléphone de milieu de gamme, 24 touches de ligne, mains libres (full-duplex), supporte

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

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

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 ;

téléphones DECT et Wifi ;

5310 : module d'audioconférence compatible avec les modèles 5224, 5330 et 5340.

5310

: module d'audioconférence compatible avec les modèles 5224, 5330 et 5340.

applications

applications

NuPoint : application de messagerie vocale et unifiée ;  

NuPoint : application de messagerie vocale et unifiée ;

 
Teleworker : application de gestion des postes IP distants (télétravail, cf ci-dessous) ;

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

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 ;

Quick Conférence : pont d'audioconférence ;

Your Assistant : softphone et messagerie instantanée interne et sécurisée.

Your Assistant : softphone et messagerie instantanée interne et sécurisée.

9.1.2.1.4 Fonctionnalités

Supervision de lignes ;interne et sécurisée. 9.1.2.1.4 Fonctionnalités Groupe d'appels ; Audioconférence ; Transfert

Groupe d'appels ;9.1.2.1.4 Fonctionnalités Supervision de lignes ; Audioconférence ; Transfert d'appels, mise en attente

Audioconférence ;Supervision de lignes ; Groupe d'appels ; Transfert d'appels, mise en attente du correspondant.

Transfert d'appels, mise en attente du correspondant.de lignes ; Groupe d'appels ; Audioconférence ; Liste non exhaustive des fonctionnalités avancées

Liste non exhaustive des fonctionnalités avancées apportées par le PABX IP Mitel ICP 3300 :

Hot Desk (mobilité)

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

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

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

Voice Mail

Tous les messages vocaux sont envoyés en attachement d’un courrier électronique (fichier audio).

 
Serveur Teleworker

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

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

http://www.cru.fr/activites/groupes_travail/voip/document

Page 10 sur 39

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

17/06/08 12:24

pour les plates-formes les plus communes Unix, Linux, Microsoft, Mac, etc

10.1.1

Points forts

Asterisk assure tous les services communément fournis par un PABX traditionnel :

 

Contrôle des postescommunément fournis par un PABX traditionnel :   Droits d'accès Plan de numérotation Messagerie vocale

Droits d'accèspar un PABX traditionnel :   Contrôle des postes Plan de numérotation Messagerie vocale Audio conférence

Plan de numérotation:   Contrôle des postes Droits d'accès Messagerie vocale Audio conférence Menus vocaux interactifs

Messagerie vocaledes postes Droits d'accès Plan de numérotation Audio conférence Menus vocaux interactifs (IVR) Groupe

Audio conférenceDroits d'accès Plan de numérotation Messagerie vocale Menus vocaux interactifs (IVR) Groupe d'appels Détails

Menus vocaux interactifs (IVR)Plan de numérotation Messagerie vocale Audio conférence Groupe d'appels Détails des communications ( Taxation )

Groupe d'appelsvocale Audio conférence Menus vocaux interactifs (IVR) Détails des communications ( Taxation ) 10.1.2 Asterisk

Détails des communications ( Taxation )Menus vocaux interactifs (IVR) Groupe d'appels 10.1.2 Asterisk et les cartes d'interface analogique

10.1.2

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 17-24 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

http://www.cru.fr/activites/groupes_travail/voip/document

Page 11 sur 39

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

17/06/08 12:24

[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 = > 17-23 ; RTC connecté aux ports 17-23

 

;

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 = > 0123456782,1,Dial(Zap/2,10,r) ; pour un appel entrant sur la ligne 0123456782, 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 = > 0123456782,2,VoiceMail(0123456782@default) ; déclencher le répondeur si pas de réponse exten = > 0123456782,3,Hangup() ; raccrocher le canal exten = > 0123456781,1,Dial(Zap/1&SIP/0123456781) : 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

0123456781

 

exten = > 0123456781,2,VoiceMail(0123456781@default) ; déclencher le répondeur si pas de réponse exten = > 0123456781,3,Hangup() ; raccrocher le canal exten = > 0123456783,1,Dial(Zap/3&Zap/4) ; ici on fait sonner deux téléphones quand l'extension 0123456783 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 = > 0123456783,2,Hangup() ; raccrocher le canal

exten = > 0123456783,2,Hangup() ; raccrocher le canal http://www.cru.fr/activites/groupes_travail/voip/document

http://www.cru.fr/activites/groupes_travail/voip/document

Page 12 sur 39

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

17/06/08 12:24

 
 

10.2 IPBX MITEL : raccordement de SYRHANO à la maquette

 

10.2.1

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.

10.2.2

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

http://www.cru.fr/activites/groupes_travail/voip/document

Page 13 sur 39

Sommaire [Comité Réseau des Universités] 17/06/08 12:24 http://www.cru.fr/activites/groupes_travail/voip/document
Sommaire [Comité Réseau des Universités]
17/06/08 12:24
http://www.cru.fr/activites/groupes_travail/voip/document
Page 14 sur 39

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

17/06/08 12:24

 
 

10.2.3 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.17/06/08 12:24   10.2.3 Evolutions possibles raccorder d'autres sites SYRHANO à la passerelle SIP,

raccorder d'autres sites SYRHANO à la passerelle SIP, notamment les participants à l'expérimentation menée en fin d'année 2005.mis en place pour la visioconférence avec les gatekeepers. Interconnexion de sites en SIP Après avoir

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.à la plate-forme expérimentale d'interconnexion Le site doit pouvoir justifier que les plages SDA qu'il

Le site doit pouvoir justifier que les plages SDA qu'il demande à router lui sont bien attribuées.protocole SIP peut avoir accès au service SIP de RENATER. Les numéros routés sont composés de

Les numéros routés sont composés de 10 chiffres.SDA qu'il demande à router lui sont bien attribuées. Principe de fonctionnement

Principe de fonctionnement

http://www.cru.fr/activites/groupes_travail/voip/document

Page 15 sur 39

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

17/06/08 12:24

 

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 RENATERqu'une seule fois. Au moins 2 routes devront exister : une route vers l'opérateur 1. La

une route vers l'opérateurAu moins 2 routes devront exister : une route vers RENATER 1. La route vers RENATER

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 avecRENATER devra toujours être privilégiée en premier lieu. RENATER, la demande de mise en relation va

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 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, Mitelque l'accès TDM. Vue d'ensemble de la maquette ToIP Divers types de postes téléphoniques sont utilisés

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.d'un routeur SIP central : Alcatel, Asterisk, Mitel VLAN séparés Actuellement les flux voix entre les

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.aux réseaux de collecte, dédié à la téléphonie. le VPN aura aussi pour effet de mieux

le VPN aura aussi pour effet de mieux protéger le trafic voix vis-à-vis des écoutes pour les communications non chiffrées.VPN, ayant une priorité supérieure au trafic des données. Réseau local L'utilisation d'un VLAN dédié est

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

http://www.cru.fr/activites/groupes_travail/voip/document

Page 16 sur 39

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

17/06/08 12:24

Sommaire [Comité Réseau des Universités] 17/06/08 12:24 11 Architecture réseau L‘application téléphonie sur IP

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.

11.1 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.

11.1.1 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)du bâtiment dans lequel ils sont installés : Les chemins de câbles des rocades et distributions

Les chemins de câbles des rocades et distributions terminaleslocaux techniques (avec alimentation électrique secourue) Les rocades (« cuivre » ou « optique ») intra-bâtiments

Les rocades (« cuivre » ou « optique ») intra-bâtiments et inter-bâtimentschemins de câbles des rocades et distributions terminales La distribution terminale Les répartiteurs informatiques et

La distribution terminale» ou « optique ») intra-bâtiments et inter-bâtiments Les répartiteurs informatiques et téléphoniques

Les répartiteurs informatiques et téléphoniques (bandeaux, connecteurs)et inter-bâtiments La distribution terminale Les boîtiers et prises terminales Les cordons de brassage

Les boîtiers et prises terminalesinformatiques et téléphoniques (bandeaux, connecteurs) Les cordons de brassage 11.1.2 Local technique courant

Les cordons de brassage(bandeaux, connecteurs) Les boîtiers et prises terminales 11.1.2 Local technique courant faible L’application ToIP

11.1.2 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à minimiser les risques d’indisponibilité du service : Le secours électrique devra être dimensionné en tenant

Le secours électrique devra être dimensionné en tenant compte de cet aspectdu réseau électrique n’est en général pas secourue Les locaux techniques devront disposer d’une alimentation

Les locaux techniques devront disposer d’une alimentation électrique sécurisée par des groupes élec- trogènes ou une double adduction électrique par exemple. Ils seront équipés d’un secours électrique local

http://www.cru.fr/activites/groupes_travail/voip/document

Page 17 sur 39

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

17/06/08 12:24

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.

11.1.3 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 : 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 : 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 : 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 50173 et ISO/IEC 11801 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:

le type de câblage et les classes d’application: Les normes ISO et EN font référence au

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 :

http://www.cru.fr/activites/groupes_travail/voip/document

Page 18 sur 39

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

17/06/08 12:24

 
 

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.

11.2

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 ! 7

Gestion avancée de la bande passante pour optimiser les flux prioritairesautomatique en cas de panne pour une disponibilité 24 ! 7 Fonctionnalités de QoS identiques de

Fonctionnalités de QoS identiques de la périphérie au cœur du réseaude la bande passante pour optimiser les flux prioritaires Mécanismes de mise en place automatisée pour

Mécanismes de mise en place automatisée pour les infrastructures de Téléphonie sur IPde QoS identiques de la périphérie au cœur du réseau Les équipements réseaux devront donc garantir

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 :sur IP Les équipements réseaux devront donc garantir :   Avoir la tonalité Que l’appel aboutisse

 
  Avoir la tonalité

Avoir la tonalité

Que l’appel aboutisse Le minimum d’interruption en cas de panne d’un élément réseau  

Que l’appel aboutisse Le minimum d’interruption en cas de panne d’un élément réseau

 
en cas de panne d’un élément réseau     La qualité de service de bout en
 

La qualité de service de bout en bout : 

 
  Pas de distorsion, pas d’écho, pas de conversation « hachée » (latence, taux de perte,

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

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

IP automatiquement Intégration parfaite avec le WiFi   Un certain niveau de sécurité :   Protection
IP automatiquement Intégration parfaite avec le WiFi   Un certain niveau de sécurité :   Protection
 

Un certain niveau de sécurité : 

 
  Protection contre les attaques vers le serveur de signalisation Protection contres les dénis de service

Protection contre les attaques vers le serveur de signalisation Protection contres les dénis de service Gestion de la confidentialité

contres les dénis de service Gestion de la confidentialité   Une administration aisée et permettre leur
contres les dénis de service Gestion de la confidentialité   Une administration aisée et permettre leur
 

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)Deux catégories de téléphone IP sont utilisables : Téléphones logiciels (softphone)

Téléphones logiciels (softphone)IP sont utilisables : Téléphones matériels (hardphone) http://www.cru.fr/activites/groupes_travail/voip/document

http://www.cru.fr/activites/groupes_travail/voip/document

Page 19 sur 39

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

 

17/06/08 12:24

 

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.

11.3.1

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.réseau, ces équipements peuvent intégrer :   La fonctionnalité PoE (Power over Ethernet, 802.3af),

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.intéressant s’il y a pénurie de prises réseau local. Le protocole VLAN IEEE 802.1pq permettant la

Le protocole VLAN IEEE 802.1pq permettant la mise en œuvre de réseaux virtuels dédiés à la téléphonie par exemple.avec la haute disponibilité des équipements réseaux. Le protocole TLS (Transport Layer Security, RFC 2246). Il

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.réseaux virtuels dédiés à la téléphonie par exemple. Des facilités de supervision (SNMP).   Il est

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.

 

11.3.2

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 res- sources 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.

 

11.4

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 par les personnes en charge du réseau et de la ToIP.

)

doit être menée

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.

 

11.5

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.

11.6

Le bout-en-bout

http://www.cru.fr/activites/groupes_travail/voip/document

 

Page 20 sur 39

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

 

17/06/08 12:24

 

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.

 
de service pour les applications temps réel.   Sécurité et Téléphonie sur IP (ToIP)   Au

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) jamais été réalisé.

pour autant que cet exercice ait

 

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 contrôle d'accès aux ressources : physiques , VLAN, FW (stun, ice

),

proxy

la signalisation et le contrôle : SIP, H323, signalisation et le contrôle : SIP, H323,

 

le transport : (S)RTP, (S)RTCP, 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, second, les écoutes, les DOS

Dans le

se prémunir des attaques ARP 

 

mettre en place un filtrage des adresses MAC par port 

 

cloisonner via un VLAN dédié les communications VoIPen place un filtrage des adresses MAC par port   contrôle d'accès au niveau IP  

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,

).

http://www.cru.fr/activites/groupes_travail/voip/document

 

Page 21 sur 39

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

17/06/08 12:24

 

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 1889 4) puis 3550 5) . 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] :

aux délais de transmission. Description du paquet [RTP] :   Version V:     Ce champ
 

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 :

http://www.cru.fr/activites/groupes_travail/voip/document

Page 22 sur 39

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

17/06/08 12:24

É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 3711 11) .

http://www.cru.fr/activites/groupes_travail/voip/document

Page 23 sur 39

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

 

17/06/08 12: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

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, besoin.

)

et les possibilités de chiffrement -parmi d'autres- sont essentiels pour répondre à ce

 
 

“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 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 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.

 

12.1 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

- 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

http://www.cru.fr/activites/groupes_travail/voip/document

 

Page 24 sur 39

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

 

17/06/08 12:24

 

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.

12.2 Appels d'urgence

L’article L. 33-1 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. 36-6. 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.

http://www.cru.fr/activites/groupes_travail/voip/document

 

Page 25 sur 39

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

17/06/08 12:24

 

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º 91-646 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º 93-119 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º 91-646 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.des différents acteurs : au niveau de quel équipement ? 12.4 Conservation des données   Le

12.4

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 (2006-358) 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

http://www.cru.fr/activites/groupes_travail/voip/document

Page 26 sur 39

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

communication.

Tableau résumant la réglementation pour les FAI :

17/06/08 12:24

résumant la réglementation pour les FAI : 17/06/08 12:24 12.5 Points connexes Une série d'obligations, outre

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

13.1.1 Contexte

L'université a 10000 é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 ?

13.1.2 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.

http://www.cru.fr/activites/groupes_travail/voip/document

Page 27 sur 39

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

17/06/08 12:24

13.1.3

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;

 

13.1.4

Schémas des infrastructures

 
 
  13.1.4 Schémas des infrastructures   Une première phase a permis de déployer de la téléphonie

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

http://www.cru.fr/activites/groupes_travail/voip/document

Page 28 sur 39

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

17/06/08 12:24

 

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.

13.1.4.1

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.

13.1.4.2

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.

 

13.1.4.3

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.

 

13.2 Cas 2 : Rennes

13.2.1

Contexte

une université (25.000 étudiants, 5000 personnels, 12 sites) avec des autocommutateurs vieillissants, répartis sur tous les sites. 

 

un MAN et des fibres disponiblesvieillissants, répartis sur tous les sites.   un réseau régional capable de faire transiter des flux

un réseau régional capable de faire transiter des flux audiotous les sites.   un MAN et des fibres disponibles un réseau téléphonie analogique saturé et/ou

un réseau téléphonie analogique saturé et/ou vieillissantréseau régional capable de faire transiter des flux audio 13.2.2 Pourquoi une migration vers la ToIP

13.2.2

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émesure de répondre à plusieurs problématiques :   appui sur l'annuaire LDAP suppression du cablage

appui sur l'annuaire LDAPdans le système d'information de l'Université suppression du cablage spécifique téléphonie acheminement

suppression du cablage spécifique téléphoniede l'Université appui sur l'annuaire LDAP acheminement des communications intra-établissement et

acheminement des communications intra-établissement et inter-sites sans recourir aux opérateursLDAP suppression du cablage spécifique téléphonie un personnel garde le même numéro de téléphone durant

un personnel garde le même numéro de téléphone durant tout son parcours à l'université, quelque soit sa localisation ou son serviceet inter-sites sans recourir aux opérateurs à terme, utilisation de protocoles ouverts 13.2.3 Coûts

à terme, utilisation de protocoles ouvertsquelque soit sa localisation ou son service 13.2.3 Coûts A l'époque, le cout d'acquisition

13.2.3

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 gestionont remporté le marché, pour un équipement comprenant: Messagerie vocale   Call server   35 SMG

Messagerie vocalemarché, pour un équipement comprenant: Centre de gestion   Call server   35 SMG (autocom analogique/IP)

 

Call server 

 

35 SMG (autocom analogique/IP) pour raccordement des postes analogiques   

 

300 postes IP propriétairespour raccordement des postes analogiques   13.2.4 Problèmatique de déploiement

13.2.4

Problèmatique de déploiement

http://www.cru.fr/activites/groupes_travail/voip/document

Page 29 sur 39

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

17/06/08 12:24

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 QOSmise au point de la solution a nécessité environ un an : configuration réseau interaction réseau

configuration réseaula solution a nécessité environ un an : problème de QOS interaction réseau et téléphonie La

interaction réseau et téléphonieenviron un an : problème de QOS configuration réseau La situation est devenue réellement stable au

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érielsponctuels. Le bilan au bout de 6 ans est en demi-teinte : Dès que c'est un

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.très correcte concernant les aspects strictement matériels Les 35 matériels de type SMG (autocommutateur

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.la société Aastra peut prendre des mois pour le traiter. Le système de messagerie vocale (Call

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.à une autre solution est couteux ( 60Keuros ).   Le système est souple et l'administration

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.et à la chute des communications locales et nationales. Le positionnement de petits onduleurs dans quelques

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 centralenoeuds réseaux stratégiques a été impératif.   Un annuaire LDAP dédié à la téléphonie, synchronisé

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.de numérotation et sur la même infrastructure centrale 13.2.5 Problématique utilisateurs Faire comprendre que

13.2.5

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 :que sans réseau, il n'y a plus de téléphone   à 240 euros le poste IP,

à

240 euros le poste IP, de nombreuses entités ont eu des difficultés à trouver les financements.

13.2.6

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 2007. 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.

13.2.7

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.de la solution, il a été décidé de :   faire évoluer les serveurs Call Server

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) 

 

13.2.8

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étairesfait « essuyer les platres » au début du projet   Une évolution vers les solutions

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é.

http://www.cru.fr/activites/groupes_travail/voip/document

Page 30 sur 39

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

17/06/08 12:24

 

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 2006 http://www.aristote.asso.fr/Presentations/SXA/SXA20060427/P/Bourdon/IndexASSS.html

13.3.1

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 Rouend'enseignement supérieur et de recherche :   CORIA CRIHAN   Université de Rouen  

 

CORIA 

CRIHANsupérieur et de recherche : INSA de Rouen   CORIA   Université de Rouen   Université

 

Université de Rouen   

 

Université du Havre  CORIA CRIHAN   Université de Rouen   13.3.2 Pourquoi migrer vers la ToIP ? Acquérir

13.3.2

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.des systèmes de téléphonie des établissements.   Démontrer l'interopérabilité des systèmes de

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.actuellement en service dans les établissements. Préparer et vérifier l'adéquation des infrastructures

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é.limites en fonction de l'évolution de la normalisation. Préparer la convergence des services sur IP (vers

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.nécessitant une bonne qualité et une haute disponibilité. Mutualiser un nouveau service sur le réseau régional

Mutualiser un nouveau service sur le réseau régional SYRHANO pour les communications inter-sites. À terme, proposer des services applicatifs associés.les SIP-phones logiciels, le partage de documents, etc. Déployer une infrastructure SIP régionale, avec les outils

Déployer une infrastructure SIP régionale, avec les outils associés (annuaires , etc.)À terme, proposer des services applicatifs associés. Expérimenter de nouveaux usages (télétravail, mobilité).

Expérimenter de nouveaux usages (télétravail, mobilité).SIP régionale, avec les outils associés (annuaires , etc.) 13.3.3 Les difficultés rencontrées lors du déploiement

13.3.3

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.cette évolution et doivent travailler ensemble.   Formation des personnels indispensable. Formation des

Formation des personnels indispensable.vocales et routage téléphonique entre les deux autocoms. Formation des utilisateurs à l'utilisation des nouveaux

Formation des utilisateurs à l'utilisation des nouveaux équipements.les deux autocoms. Formation des personnels indispensable. Définition de l’interconnexion des PABX IP (full mesh ou

Définition de l’interconnexion des PABX IP (full mesh ou équipement central, plan de numérotation entre les sites).utilisateurs à l'utilisation des nouveaux équipements. 13.3.4 Coûts Chaque site a reçu, pour débuter

13.3.4

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 14 000 " .

 

13.3.5

Description de la maquette et configuration locale à cahque site

Le schéma ci-dessus présente la maquette mise en place sur SYRHANO :

 

http://www.cru.fr/activites/groupes_travail/voip/document

Page 31 sur 39

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

17/06/08 12:24

Sommaire [Comité Réseau des Universités] 17/06/08 12:24 Afin de minimiser les interactions entre la maquette et

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.Sommaire [Comité Réseau des Universités] 17/06/08 12:24 Les PABX IP de chacun des sites sont également

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.entre les postes existants et les nouveaux postes IP. Plan de numérotation adopté Numérotation décimale :

Plan de numérotation adopté

Numérotation décimale : pas de nom de domaine SIP pour le moment.utilisé sera SIP. Plan de numérotation adopté Utilisation des numéros SDA des sites : numérotation à

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.résilience en cas de défaillance d’un lien IP.   Différentes étapes de l'épérimentation : Etape 1

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(Minet pour Mitel et Skinny pour Cisco).   signalisation est moins riche (pas de possibilité de

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,(Cisco et Mitel pour notre expérimentation).   Chaque site a reçu : Un PABX IP avec

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.E1 (raccordement RTC et PABX conventionnel).   Les licences d’utilisation pour environ 20 boîtes

Les licences d’utilisation pour environ 20 boîtes vocales.pour mains li-bres), avec les licences d'utilisation. Des licences “HotDesk” (renvoi des appels, etc.) : cette

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.récupérer sur un autre poste téléphonique IP.   Les licences requises pour utiliser les interfaces E1.

Les licences requises pour utiliser les interfaces E1.Les licences requises pour interconnecter plusieurs PABX IP. http://www.cru.fr/activites/groupes_travail/voip/document

http://www.cru.fr/activites/groupes_travail/voip/document

Page 32 sur 39

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

17/06/08 12:24

Sommaire [Comité Réseau des Universités] 17/06/08 12:24 13.3.6 Services supplémentaires apportés La mise en place de

13.3.6 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 :

de prospoer aux utilisateurs de nouvelles fonctionnalités : Hot Desk (mobilité) Un utilisateur, disposant d’un profil

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(extension, préférences et touches personnalisées). Cette fonctionnalité permet d’enregistrer une conversion

Cette fonctionnalité permet d’enregistrer une conversion téléphonique afin de la recevoir par mail (fichier audio en pièce jointe).

de la recevoir par mail (fichier audio en pièce jointe). Mobile extension Il s'agit de la

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).

sur n’importe quel téléphone (fixe ou mobile). Voice Mail Tous les messages vocaux sont envoyés en

Voice Mail

Tous les messages vocaux sont envoyés en attachement d’un courrier électronique (fichier audio).

attachement d’un courrier électronique (fichier audio). Serveur Teleworker Il s'agit d'un proxy qui permet

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.

être joignable sur son numéro SDA depuis son domicile. Tenanting Virtualisation de l’autocom : plusieurs

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).

13.3.7 Aspect réseaux

Chaque site adopte la même politique.

http://www.cru.fr/activites/groupes_travail/voip/document

Page 33 sur 39

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

17/06/08 12:24

 
Vlan et adressage

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

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

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.

13.3.8

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.

13.3.9

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.ont été proposées aux utilisateurs.   Acquisition d'éxpérience sur ces nouvelles

Acquisition d'éxpérience sur ces nouvelles technologies.tierce pour intervenir et modifier la configuration du PABX. 13.4 CAS 4 : Migration vers la

13.4 CAS 4 : Migration vers la ToIP

Grenoble Universités Contact : Raoul Dorge GRENET

13.4.1

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.

 

13.4.2

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.

 

13.4.3

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).

 

13.4.3.1 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

http://www.cru.fr/activites/groupes_travail/voip/document

Page 34 sur 39

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

17/06/08 12:24

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.

13.4.4

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

13.4.5

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).

13.4.6

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.

13.4.7

Cohabitation de l'ancien système et du nouveau

Interconnexion par T2.

 

13.4.8

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”.

13.4.9

Schémas

http://www.cru.fr/activites/groupes_travail/voip/document

Page 35 sur 39

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

17/06/08 12:24

Sommaire [Comité Réseau des Universités] 17/06/08 12:24 http://www.cru.fr/activites/groupes_travail/voip/document Page

http://www.cru.fr/activites/groupes_travail/voip/document

Page 36 sur 39

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

17/06/08 12:24

Sommaire [Comité Réseau des Universités] 17/06/08 12:24 13.5 CAS 5 : Université de Lille1 A mettre

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.

http://www.cru.fr/activites/groupes_travail/voip/document

Page 37 sur 39

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

17/06/08 12:24

 

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.

13.6 CAS 6 : Université de Nancy2

Contact : Vincent Mathieu

13.6.1

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.

13.6.2

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.

 

13.6.3

Etude des solutions

Un appel d'offre. Seulement 2 réponses : - une offre cisco (callmanager) - une offre alcatel

 

13.6.4

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.

 

13.6.5

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.

 

http://www.cru.fr/activites/groupes_travail/voip/document

Page 38 sur 39

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

 

17/06/08 12:24

13.6.6

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.

13.6.7

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é.

13.6.8

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.

13.6.9

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, couts téléphoniques.

Nous avons du développer une application permettant une refacturation interne des

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) http://www.ietf.org 4) http://www.ietf.org/rfc/rfc1889.txt 5) http://www.ietf.org/rfc/rfc3550.txt 6) Realtime Control Transport Protocol 7) Payload Type 8) Denial of Service 9) Secure Realtime Transport Protocol 11) http://www.ietf.org/rfc/rfc3711.txt

http://www.cru.fr/activites/groupes_travail/voip/document

 

Page 39 sur 39