Service pilote de téléphonie sur IP (ToIP) dans RENATER

Simon Muyal

GIP RENATER

151 bd de l'Hôpital, c/o ENSAM 75013 Paris

Bernard Tuy

GIP RENATER

151 bd de l'Hôpital, c/o ENSAM 75013 Paris

Résumé

Dans tous les secteurs d'activité, des solutions de téléphonie basées sur le protocole IP (ToIP) s'imposent à l'occasion du renouvellement des équipements et de la mise en concurrence des services de téléphonie. Cette dynamique a ouvert des perspectives quant à la fourniture d’un nouveau service aux établissements de la communauté RENATER.

Un routeur d’appels téléphoniques SIP, le standard IETF pour la ToIP, a été mis en place dans le cœur du réseau RENATER afin d’interconnecter les IPBXs des établissements ayant déployé de la ToIP. Ce nouveau service de routage permet d’acheminer les appels téléphoniques entre sites en utilisant l'infrastructure IP de RENATER et donc de s’affranchir des coûts liés au RTC ou RNIS pour ces appels internes à la communauté. Le routeur d'appels repose sur la solution logicielle open source Kamailio qui est une évolution du projet OpenSER.

Des solutions permettant de superviser ce service et d’assurer la comptabilisation des appels ont été développées en se basant sur les logiciels libres Nagios et FreeRadius.

Plusieurs évolutions sont déjà à l’étude : haute disponibilité du service, support d’IPv6, renforcement de la sécurité et mutualisation des accès téléphoniques des sites RENATER.

Mots clefs

ToIP, SIP, Kamailio, IPBX, Supervision, Comptabilisation

1Introduction

Un groupe de travail constitué d'organismes du monde académique a été créé fin 2006 afin d'acquérir des connaissances dans le domaine de la ToIP¹ et d'évaluer quel service le GIP RENATER pourrait mettre en œuvre au profit de sa communauté. Suite aux réflexions menées par ce groupe de travail, une maquette basée sur OpenSER a été installée. Elle a permis de mettre en relation les systèmes de ToIP déployés par les établissements RENATER participant à cette expérimentation.

L'expérience acquise grâce à cette maquette a permis de cerner la nature et les spécifications techniques d'un service de routage d'appels SIP². Un service pilote a été ouvert avec quelques sites volontaires. A terme, le service sera ouvert à l'ensemble des sites usagers de RENATER ayant déployé de la ToIP dans leur campus. La suite de l'article présente les caractéristiques et les choix techniques retenus, ainsi que les conditions d'accès pour les usagers. Les évolutions et les perspectives du services ToIP sont brièvement brossées.

2Le service pilote ToIP de RENATER

2.1Principe : une solution basée sur Kamailio

Afin de mettre en relation les IPBXs³ des établissements ayant déployé de la ToIP au sein de leur organisation, un routeur d'appels téléphoniques a été mis en place dans RENATER. Ce routeur d'appels permet d'acheminer les communications téléphoniques entre établissements en utilisant l'infrastructure IP et donc de s'affranchir des coûts liés au RTC ou RNIS pour les appels internes à la communauté. Seul le routeur d'appels de RENATER maintient la table de l'ensemble des numéros de téléphones (plages SDA⁴) des sites accessibles en IP. Les IPBXs des sites n'ont simplement qu'à configurer une route vers cet équipement ainsi qu'une route de « secours » vers leur lien RTC/RNIS habituel si l'équipement distant n'est pas joignable en IP.

Les IPBXs des sites provenant de constructeurs différents, un protocole standardisé est nécessaire pour assurer les communications entre eux et le routeur d'appels. Le protocole SIP, Session Initiation Protocol, est devenu ces dernières années le standard de la ToIP défini par l'IETF. C'est donc SIP qui a été retenu pour assurer la signalisation entre les IPBXs et le routeur d'appels de RENATER.

Le routeur d'appels repose sur la solution logicielle Open source Kamailio⁵ qui est une évolution du projet OpenSER.

Figure 1 - Architecture globale du service ToIP de RENATER

2.2Adressage/numéros d'appel

Afin d’assurer l’unicité des numéros de téléphone et éviter les collisions entre sites, les numéros de téléphone « publics », dits numéros E.164, fournis par les opérateurs de téléphonie classique sont utilisés. Ceci permet également aux sites de ne pas avoir à permuter le numéro appelé en cas de bascule sur le RTC/RNIS et d’utiliser un numéro unique de façon transparente.

Les formats des numéros de téléphone traités par le routeur d’appels sont :

format à 10 chiffres pour les numéros nationaux : ex : «0123456789» ;
format international (00+préfixe pays+ numéro de téléphone) : ex «0044123456789».

Un système d’annuaire tel qu’ENUM⁶ n’a pas été retenu pour le moment. ENUM permet d'utiliser un numéro de téléphone pour rechercher via le DNS différentes façons de joindre une personne. Typiquement, il est possible d'associer à un numéro de téléphone une URI⁷ SIP et ainsi joindre le correspondant en question. Cependant, l'usage d'ENUM dans la communauté académique et chez les opérateurs de ToIP demeure encore incertain aujourd’hui du fait notamment de sa complexité de mise en œuvre (cf. 7).

2.3Routage des appels

Les établissements raccordés à ce service configurent leur proxy SIP (généralement leur IPBX) de la façon suivante :

une route principale vers le routeur d’appels de RENATER ;
une route secondaire vers l'opérateur du lien RTC/RNIS ou vers un ITSP⁸. Il existe aujourd'hui des opérateurs de téléphonie sur IP (ITSP) proposant des solutions qui permettent de remplacer l'accès « traditionnel » RTC/RNIS. Il est donc possible que des sites aient opté pour ce type d'architecture.

Cette configuration simple au niveau du site permet de garder un accès de secours et de basculer vers celui-ci si nécessaire.

Lorsqu’un poste de téléphone IP tente de faire un appel, le proxy SIP du site va relayer cette requête vers le routeur d’appels de RENATER (requête SIP INVITE) :

si le numéro appelé se trouve dans la table de routage d’appels du routeur RENATER, la requête SIP INVITE sera relayée vers l’IPBX du site appelé. Plusieurs messages SIP seront alors échangés pour pouvoir établir la communication (Figure 2) ;

Figure 2 - Signalisation SIP pour un appel réussi

si le numéro appelé ne se trouve pas dans la table de routage d’appels du routeur RENATER, le routeur d’appels génère initialement un message d’erreur SIP 404 – « User not found ». Ce message d’erreur ne traduit pas la réalité étant donné que le site est probablement accessible via le RTC. Afin que l’IPBX du site appelant puisse basculer vers son accès secondaire, l’erreur SIP 404 va être convertie par le routeur d'appels en erreur SIP 504 – « Server time out » puis relayée vers le site appelant. Le site pourra alors basculer l'appel vers sa route alternative (généralement le RTC ou RNIS ou ITSP) ;
si le numéro appelé se trouve dans la table de routage d’appels mais que l’IPBX appelé n’est pas joignable, ceci est peut-être dû à un problème réseau entre le routeur d’appels et l’IPBX appelé ou un problème au niveau de l’IPBX distant lui-même. Dans ce cas, le routeur d’appels va générer un message d’erreur SIP 408 – « Request Timeout (Couldn't find the user in time) ». Ce message correspond à un message « utilisateur » alors qu’il s’agit ici d’un problème réseau/serveur. Ce message va être relayé vers l’appelant après conversion en erreur SIP 504 par le routeur d’appels afin que l’IPBX du site appelant puisse basculer l'appel vers la liaison RTC/RNIS.

2.4La supervision du service

Comme tout service en exploitation, le service pilote ToIP doit être supervisé. L’objectif principal est d'avoir une solution de supervision qui permette de réaliser les tâches suivantes :

surveillance de l'état du service de routage des appels téléphoniques au niveau du serveur Kamailio ;
suivi des performances du routeur d'appels (charge CPU, utilisation de la mémoire, utilisation du disque dur) ;
supervision des IPBXs des sites distants interconnectés au service pilote (connectivité IP et service SIP) ;
graphes dans le temps des informations ci-dessus.

Plusieurs solutions ont été étudiées pour couvrir ces besoins :

Monit est une solution permettant de vérifier les performances d'un serveur et superviser des services réseau. L'inconvénient rencontré avec Monit fut la difficulté à superviser les IPBX distants. Cette solution n'a donc pas été retenue ;
Une autre solution est d’utiliser l’outil SIPp qui permet de générer des appels SIP en ligne de commande. Cette solution était trop limitée par rapport à nos besoins car d’autres outils auraient été nécessaires pour vérifier l’état des liens et générer des graphes. De plus, un effort important s'imposait au niveau du développement de scripts. Cet outil reste cependant intéressant pour la résolution de problèmes ou pour les tests de performances. Il peut facilement tester les performances des communications entre deux sites ;
La dernière solution étudiée est le logiciel de supervision Nagios⁹. Grâce à sa modularité et les greffons disponibles, Nagios répond parfaitement à nos besoins. Nagios permet également une évolutivité pour mutualiser la supervision des services proposés par RENATER. Le choix s'est donc porté naturellement sur Nagios. Le greffon NRPE¹⁰ a été installé pour superviser les performances du routeur d'appels. Le greffon SIP permet de s'assurer que le routeur d'appels répond correctement aux requêtes SIP et que ces requêtes sont routées vers le bon IPBX. Ces deux greffons et les outils de base intégrés dans Nagios permettent d'assurer la supervision du service ToIP aussi bien au niveau du routeur d'appels que des sites raccordés.

Figure 3 - Solution de supervision basée sur Nagios

2.5La comptabilisation des appels

Pour d’une part vérifier l’usage du service pilote et d’autre part collecter les informations nécessaires à la correction des dysfonctionnements constatés, une solution de comptabilisation (« accounting ») a été étudiée et mise en place. Cette solution permet également de satisfaire les contraintes réglementaires qui imposent de garder une trace des appels pour une durée d'un an.

Les principales fonctionnalités de cette solution sont :

l'établissement de statistiques sur les appels (réussis et échoués) traités par le routeur de RENATER ;
le suivi de ces statistiques dans le temps ;
l'agrégation des statistiques pour connaître l’usage du service pour chaque site.

Cette solution repose sur le module ACC de Kamailio¹¹ et sur le logiciel libre freeRADIUS¹². Elle est plus simple et plus précise que le journal des évènements généré par Kamailio. Une interface web permettant d’accéder aux données a été développée par le GIP RENATER.

Figure 4 - Principe de fonctionnement de FreeRADIUS avec Kamailio

Lors de la validation de cette solution, nous avons remarqué que FreeRADIUS ne permettait pas de générer les CDR¹³ pour les appels échoués, étant donné que le message SIP BYE n’est jamais reçu par le Kamailio. Le module ACC avec MySQL¹⁴ a donc été utilisé afin de pouvoir également comptabiliser les appels échoués.

3Accès des usagers RENATER au service ToIP

Tout responsable technique d’un site ayant déployé de la ToIP sur tout ou partie de son campus peut faire une demande de raccordement au service de ToIP de RENATER. Les informations à fournir pour s’y raccorder sont les suivantes :

le nom DNS de l’IPBX du site ;
les plages de SDA utilisées à l’intérieur du site qui sont susceptibles d’être routées vers des sites distants en utilisant l’infrastructure IP de RENATER. Le site doit justifier qu’il est bien « propriétaire » de ces SDA.

Le responsable technique de l’établissement doit se rendre à l’URL http://www.renater.fr/toip, sélectionner « Se connecter au service » et fournir les informations nécessaires.

Les plages de SDA, une fois vérifiées, seront ajoutées à la table de routage du routeur d’appels de RENATER.

4Les perspectives

4.1Haute disponibilité

Deux solutions permettant de redonder le routeur d’appel sont à l'étude.

La première solution repose sur la technique anycast. Les routeurs d'appels auraient la même adresse IP et les messages SIP INVITE envoyés par les IPBXs des sites seraient acheminés vers le routeur d'appels le « plus proche » en termes de routage. Cette technique permet de répartir naturellement la charge entre les différents routeurs d'appels. Elle offre également un temps de convergence très rapide (temps de convergence de l'IGP¹⁵ dans RENATER) et reste transparente pour le site qui ne configure qu'une seule entrée pour le routeur d'appels. Cependant, cette solution complexifie considérablement la supervision et la comptabilisation des appels.

La deuxième solution consiste simplement à mettre en place un routeur d'appels supplémentaire et de demander aux sites de configurer une route additionnelle au niveau de leur IPBX vers ce routeur secondaire. L'insertion de ce deuxième routeur n'introduit pas de problème majeur pour la supervision et la comptabilisation. Bien que cette solution puisse introduire un délai supplémentaire lors de l'établissement de l'appel (en cas de panne du routeur d'appels primaire), elle reste la plus simple à mettre en œuvre et à administrer.

Les derniers tests permettront de déterminer laquelle de ces deux solutions sera choisie et déployée prochainement.

4.2Sécurité

Aujourd'hui, le routeur d'appel est protégé par des filtres ne laissant communiquer que les IPBXs des sites ayant fait une demande de raccordement à ce service. Cependant, plusieurs mécanismes sont à l'étude pour sécuriser davantage le service pilote ToIP. Des recommandations portant sur la sécurisation de l’architecture ToIP au sein des sites usagers seront également proposées. L’ensemble de la chaîne allant de l'enregistrement d'un téléphone à l'établissement d'une communication sera traité :

sécurisation de l’enregistrement d’un téléphone IP auprès d’un Registrar (coté site): Cette action permettant d'authentifier les téléphones est nécessaire au niveau des sites pour éviter que des téléphones IP tiers puissent utiliser un IPBX pour émettre des appels. La première règle est d'avoir une politique de sécurité entre le Registrar (l'IPBX joue souvent ce rôle) et les téléphones IP afin d'autoriser ce type de requêtes uniquement depuis des téléphones IP connus. Dans le cas où le protocole de signalisation des téléphones est SIP, il s'agit des messages SIP REGISTER. Cette action de filtrage est souvent réalisée par un équipement réseau. Une vérification basée sur l'adresse MAC du téléphone IP peut également être faite par le Registrar ;
établissement d’un appel (SIP/TLS¹⁶): L'usage de SIP/TLS entre le routeur d'appels et les IPBX permettrait non seulement de chiffrer la signalisation mais aussi d'authentifier les IPBXs des sites ;
communication (SRTP): SRTP permet le chiffrement d'une communication voix entre deux téléphones. Cette fonctionnalité étant souvent indisponible au niveau des équipements terminaux, il est possible de la déporter au niveau d'un équipement local. Les communications vers l'extérieur du site peuvent alors être chiffrées.

4.3IPv6

Le logiciel Kamailio supporte le transport de la signalisation sur IPv6 mais cette fonctionnalité n'a pas encore été activée. Elle est actuellement en cours de validation avec un ensemble d'IPBXs et de terminaux hétérogènes afin de s'assurer que la signalisation peut se faire convenablement entre un IPBX IPv4 et un IPBX IPv6 et que la communication peut s'établir entre deux téléphones IP. Une documentation listant les scénarios possibles ainsi que des recommandations seront disponibles sous peu sur le site de RENATER.

4.4Mutualisation des accès téléphoniques

Dans la continuité de ce qui a été initié, on pourrait imaginer une évolution de ce service d'interconnexion d'IPBXs vers une mutualisation plus ou moins complète des accès RTC des sites RENATER qui le souhaitent. Dans cette perspective, il sera nécessaire de considérer les aspects techniques à résoudre mais également les aspects réglementaires.