Le projet ETOS

1. Le projet ETOS Enterprise Telecommunication Open Suite

2. ETOS:Présentation générale

3. ETOS: qu’est-ce? • Un projet de réalisation d’une solution complète d’applications de communications voix (et plus) pour entreprise • Open source • Doit couvrir les besoins • des utilisateurs administratifs, • des centres d’appels. • Basé sur l’utilisation massive de la voix (et vidéo) sur IP, afin de minimiser le rôle du « hardware » dans la solution de communication globale Projet ETOS – Benjamin Thominet - 2003

4. ETOS, pourquoi un tel projet? • Les solution de communications d’entreprises sont de plus en plus complexes (et riches fonctionnellement) et coûteuses • Il est donc de plus en plus difficile pour les acteurs traditionnels de rentabiliser leurs investissements R&D, et pour les clients de dégager un ROI acceptable, bien que les besoins soient là. • Il faut donc trouver de nouvelles sources d’innovations dans ce domaine. L’Open Source est une réponse • Les solutions actuelles, même les plus innovantes (Cisco), sont encore largement basées sur des fournitures hardwares puisque l’infrastructure hard (voix et/ou data) est le cœur de métier de tous ces acteurs. Par exemple, toutes les solutions du marché sont orientées vers l’usage de postes téléphoniques (maintenant IP) plus que de softphones, qui sont pourtant une réponse fonctionnelle et économique (surtout en open source) intéressante pour une proportion importante d’utilisateurs. De même, les serveurs PC supportant les applications (quand ce sont des PC!) sont en général obligatoirement fournis avec le soft par le constructeur • Les fournisseurs actuels de solutions, afin d’optimiser leurs investissements et afin d’être aussi réactif que possible au marché, ont tendance à réutiliser des développements parfois anciens, ou a faire cohabiter ‘tant bien que mal’ dans une même offre des modules provenant de différentes origines (rachats…). Il en résulte des architectures télécom imparfaites, L’ajout de fonctionnalités sur une infrastructure télécom de base et la maintenance sont souvent complexes et très coûteux. L’évolution des différentes offres n’est également pas toujours facile pour les fournisseurs, compte tenu des imperfections technologiques de leurs offres • Les solutions commerciales actuelles amènent souvent à des remises en causes des investissements antérieurs. Chaque constructeur dispose pour beaucoup d’applications (notamment centres d’appels) de plusieurs offres, l’offre d’entrée de gamme permettant de capter le client, mais devant être souvent totalement poubellisée le jour ou le client désire accéder à des fonctions plus élaborées. Une base technologique suffisamment bien conçue sera capable de s’adapter aux besoins de toutes les structures (des plus petites aux plus grosses). Le coût d’acquisition d’une solution Open Source étant nul, le client peut accéder dès le démarrage (y compris pour des besoins simples) à un socle technologique haut de gamme, qui saura l’accompagner dans ses évolutions futures Projet ETOS – Benjamin Thominet - 2003

5. Aspects économiques • Evolution des coûts liés à l’acquisition d’une solution télécom sur les dernières années : • L’utilisation d’une solution de communication Open source (pour la partie logicielle) permet donc de faire jusqu’à 30% d’économie à l’investissement. Certaines économies pourront également être réalisées sur la maintenance, une partie de celle-ci reposant sur la communauté de développeurs • Le ROI direct d’une solution de communication est ainsi beaucoup plus rapide. Cela permet aux entreprises (et donc aux utilisateurs) d’accéder plus facilement et plus rapidement à des applications et services évolués, ce qui augmente d’autant la productivité • Ces solution étant bien meilleures marché que les solution commerciales, elles sont d’autant plus faciles à vendre pour les intégrateurs, qui pourront ainsi développer leur activité en se focalisant sur les services à valeur ajoutée (accompagnement, consulting, expertise, support) plutôt que sur la vente de licences à faible marges. • Les fournisseurs traditionnels de solutions télécom (Cisco, Alcatel…) conservent une part du marché: ils fournissent l’infrastructure hardware (postes et passerelles compatibles SIP, infra réseau VoIP enabled), et profitent aussi du dynamisme économique engendré par la réduction du coût global de la solution Projet ETOS – Benjamin Thominet - 2003

6. La convergence administratifs/centre d’appels

7. le principe • A l’origine, les solutions télécom étaient conçues pour les utilisateurs dits ‘administratifs’ • Puis sont apparus les centres d’appels, avec leurs besoins propres • Des solutions sont alors apparues pour répondre à ces besoins. Ces solutions sont soit autonomes (PCBX entrées de gamme), soit se connectent sur un système télécom ‘administratif’, avec lesquels ils dialoguent via un lien CTI. Mais il y a bien deux ‘socles logiciels’ différents qui cohabitent dans ces solutions haut de gamme • Une analyse technologique plus poussée montre que les applications ‘administratives’ et ‘centres d’appels’ reposent pourtant sur des bases ou ‘services’ communs, simplement utilisés différemment. • Il est donc temps de concevoir une infrastructure télécom logicielle universelle, sur laquelle se grefferont des applicatifs clients/serveurs (scénarii de routage, applications clientes), adaptés aux besoins de chaque entité de l’entreprise et chaque utilisateur Projet ETOS – Benjamin Thominet - 2003

8. Routage • Les solutions pour centres d’appels incluent couramment des routeurs d’appels (ACD, SVI), dont les scénarii sont totalement et facilement personnalisables à l’aide d’outils graphiques ouverts. • Les solutions télécom administratives disposent depuis toujours de divers services de routage d’appels (traducteur SDA, least cost routing, assistant vocal personnel, messagerie vocales). Ses services ont toujours été développés indépendamment, et sont généralement totalement intégrés dans le cœur de la solution, ce qui en limite les possibilités d’évolution. • Toutes ces fonctions pourraient être réalisées par un routeur universel d’appels (même de contacts), à l’image de ce qui se fait dans les centres d’appels. Un simple scénario vocal , facile à concevoir et à faire évoluer, et correspondant à chaque application, serait exécuté par le routeur universel. Projet ETOS – Benjamin Thominet - 2003

9. Login • De même, les fonctions de login se sont vraiment déployées avec les centres d’appels (l’utilisateur s’enregistre sur un poste avant de pouvoir l’utiliser, afin que le système sache qu’il peut router des appels sur ce poste, en relation avec les compétences de l’agent qui l’utilise). Puis ces fonctions sont devenues utiles pour les administratifs avec l’apparition des bureaux virtuels (l’utilisateur s’enregistre sur le poste d’un bureau qui lui est attribué temporairement afin de récupérer ses droits et sa configuration.) et de web softphone. Ces logins sont généralement distincts et incompatibles • Un système de login universel, avec différents modes de fonctionnement, et la gestion de la disponibilité de l’utilisateur vis-à-vis de différents applicatifs (revenant à activer ou désactiver des compétences) permettrait de simplifier la gestions. Un même utilisateur pourrait également cumuler plusieurs fonctions plus facilement, tout en activant celle(s) qu’il souhaite ou doit à un instant donné • Un poste pourrait fonctionner en login auto (utilisateur associé systématiquement à ce poste si le poste est branché), ou mobile (l’utilisateur doit s’enregistrer, voire s’authentifier par mot de passe sur le poste, afin de s’associer temporairement à ce poste). L’utilisateur activerait alors les compétences/services pour lequel il accepte de recevoir des appels (SDA, centre d’appels….), dans la limite de ses droits Projet ETOS – Benjamin Thominet - 2003

10. Ressources vocales • Plutôt que de disposer de diverses ressources vocales dédiées et non homogènes (SVI pour centre d’appels, récepteurs DTMF/diffuseurs de musiques d’attente pour applications administratives), un unique pool de ressources vocales (DSP) assurant les fonctions d’envoi(diffusion)/réception(enregistrement) de message vocaux, de DTMF, fax, conférence serait disponible, et piloté intégralement par le routeur d’appel, seule et unique intelligence du système. Projet ETOS – Benjamin Thominet - 2003

11. Les opératrices • Un terminal spécifique • Un mode de fonctionnement particulier, avec une mise en attente des appels, mais souvent des fonctions de gestion de l’attente basiques • De nombreux clients cherchent à rapprocher fonctionnellement les opératrices du centre d’appel: disposer de logiques de routage perfectionnées sur les opératrices, qui conservent un terminal spécifique (supervision de postes, multi-lignes, accès facile à l’annuaire….) • Ceci devient réalisable avec un routeur universel, gérant tous les appels, y compris ceux à destination du standard Projet ETOS – Benjamin Thominet - 2003

12. Le centre d’appels informel • Certains services administratifs ont de plus en plus besoin de tout ou partie des fonctions téléphoniques disponibles dans un centre d’appel (login et/ou montée de fiche et/ou gestion de l’attente et/ou statistiques) • Cependant, le coût des applicatifs centre d’appels, et leur manque d’intégration avec les autres applicatifs téléphoniques ‘administratifs’ sont en général rédhibitoires pour des populations parfois très nombreuses (backoffice regroupant 10 fois plus de personnes que la structure ‘centre d’appel’, et beaucoup moins sollicitée au téléphone par exemple) • Encore une fois, un infrastructure logique unifiée administratif/centre d’appel permet de à donner à chaque utilisateur exactement les fonctions dont il a besoin, sans être dépendant des fonctions disponibles dans tel ou tel environnement Projet ETOS – Benjamin Thominet - 2003

13. ETOS: présentation technique

14. ETOS: technologies • Système d’exploitation : Pour un projet Open source, un OS Open Source s’impose. Linux est évidemment la solution la plus réaliste pour les applications serveur. Largement supporté, il est utilisé par Alcatel dans ses dernières solutions de communications OmniPCX Office et Enterprise. Les clients devront fonctionner sous Windows ou en client léger (multi plate-forme) • Base de données: Pour des raisons d’évolutivités, il conviendra de stocker toutes les données de la solution (configuration des utilisateurs et des modules logiciels,données historiques, logs…) dans une base standard et ouverte. MySQL conviendra probablement pour les petits systèmes. Pour les grosses infrastructure, l’utilisation de DB standard permettra de se reposer sur le serveur de DB déjà en place chez le client (Oracle, MSSQL…) • Accès aux annuaires: LDAP • Le système de communication devra fonctionner nativement en SIP (afin notamment d’assurer la compatibilité avec le hardware -passerelles et postes- SIP disponibles sur la marché), et un module de compatibilité H323 serait appréciable • A partir du moment ou des opérateurs fourniront des accès à leurs services en SIP (et non RNIS), la solution ETOS pourra fonctionner en toute indépendance des hardware spécifiques • plus de passerelles, • poste téléphoniques softphones, • ressources vocales gérées sur plate forme PC (compte tenu de la montée en puissance phénoménale de ces plates formes), pour un coût et un encombrement de plus en plus raisonnables Projet ETOS – Benjamin Thominet - 2003

15. ETOS: principes d’architecture • ETOS doit être constitué d’une architecture modulaire et évolutive, • Pour être adaptée à des développements rapides, nombreux et « communautaires ». • Pour permettre une sécurisation et une extensibilité maximales par duplication des différents modules sur plusieurs PC (avec partage de charge, automatique si possible, entre tous les modules identiques de la solution mise en oeuvre). Ce principe de clustering peut être assimilé à ce que propose Cisco avec son Call Manager • L’architecture doit constituer un socle technologique universel sur lequel diverses applications téléphonique (et plus tard vidéo…. ou autre) doivent pouvoir s’appuyer. Le développement de l’application proprement dite devant être réduit au minimum. • Toutes les interfaces entre les modules doivent êtres ouvertes et documentées, et si possible s’appuyer sur des standard (XML, VXML…) • L’architecture doit être conçue afin d’éviter toute redondance dans les développements. • Il existe sur le marché une solution dont l’architecture répond particulièrement bien à ces besoins: il s’agit des solution pour centres d’appels Genesys (groupe Alcatel). Il ne faut donc pas hésiter à s’inspirer largement de l’architecture Genesys pour ETOS Projet ETOS – Benjamin Thominet - 2003

16. Architecture ETOS: draft Serveur de messagerie POP3/SMTP Exchange/domino Ou open source Devices Appliances Interfaces client léger Routing Designer Serveur Web: Apache ou d’entreprise • Terminaux • postes • Softphones • PDA… Communication server cluster Contact generator Communication router cluster History server cluster Communication server cluster: SIP proxy&registrar, Message server (event/request/ user) Reports Configurator H323 émulator • Passelles • T0/T2 <-> SIP Data access server cluster Base de donnée: MySQL ou d’entreprise Managment server cluster • Ressources de traitement • Intégrées à la passerelles ou solution logicielle sur PC Configuration server cluster Solution control interface Configuration Manager Projet ETOS – Benjamin Thominet - 2003

17. Les devices • Les terminaux: Ce sont les outils utilisés par les utilisateurs finaux: • PC et PDA Wifi sur lesquels tournent des applications de communication (softphone, chat, visio…) • Postes téléphoniques compatibles SIP (et H323) • Les passerelles: ce sont des ponts entre le monde de la communication vocale sur IP et le monde télécom traditionnel. Elle convertissent les signaux vocaux provenant de lien opérateurs (ou privés) T0/T2 en flux Voix sur IP. ETOS sera compatible avec les passerelles respectant le standard SIP • Les ressources de traitement: elles réalisent toutes sortes d’opérations automatisées sur le flux voix: • Diffuser un message (fichier .wav) à l’interlocuteur (musique d’attente…) et enregistrer un message (boite vocale), idem avec de la vidéo • Émission et réception de fax et d’email • Conférence • Détection/génération DTMF (pour menus vocaux interactifs: « tapez 1 pour ceci, 2 pour cela » ; « entrez votre code client »…) • Détection de voix et fax (VAD) Projet ETOS – Benjamin Thominet - 2003

18. Les appliances: généralités • Socle technologique de la solution • Chaque module serveur est clusturisable • afin de le sécuriser • Afin de permettre la répartition de charge (automatique si possible) sur plusieurs machines, pour répondre aux besoins des plus grosses configuration • Plusieurs modules peuvent cohabiter sur un unique serveur physique (la totalité des modules pour les petites configurations) Projet ETOS – Benjamin Thominet - 2003

19. Les appliances: le communication server cluster • Le communication server cluster: c’est la brique de base de la solution. Il cumule les rôles de: • Proxy SIP • SIP registrar • Émulateur H323 (module externe) • Serveur de message instantanés (event/request/user) • Dispose d’une vue temps réel de l’ensemble des devices et des appels en cours. Il gère la structure de données (standard+custom) associée à chaque appel. Projet ETOS – Benjamin Thominet - 2003

20. Les appliances : Le database access server cluster • Centralise les accès aux données pour toutes les applications • Configuration • Historique… • Seul module à modifier pour assurer le support d’un nouveau type de base de données (transparence pour les autres modules de la solution) • Doit supporter les bases: • MYsql. • connecteur ODBC • Voire drivers dédiés MSSQL/Oracle Projet ETOS – Benjamin Thominet - 2003

21. Les appliances: Le configuration server: • Donne accès à l’ensemble des données de configuration du système • paramètres d’application, • paramètres utilisateurs, • droits de gestion • droits téléphoniques • Utilisés par toutes les applications de la solution à leur démarrage • Outil client web pour visualisation, modification et installation du système: configuration manager Projet ETOS – Benjamin Thominet - 2003

22. Les appliances: Le communication router cluster • c’est le routeur universel de communications. Lorsqu’une communication (entrante/sortante; interne ou externe) arrive sur le communication server, celui-ci interroge le communication router pour savoir sur quel device il doit la router (et éventuellement avec quel ordre dans le cas des ressources). Le scénario de routage peut être des plus simples (appel SDA) aux plus complexes (scénarii centre d’appels sur mesure). Les scénarii vocaux sont créés à partir du routing designer, outil graphique drag&drop convivial. Le routing server pilote entièrement les ressources de traitement. Le routing designer dispose donc de ‘briques’ drag and drop correspondant à chaque fonction exécutées par les ressources de traitement, en plus d’accès bases de données SQL, de branchements conditionnels, d’ordres de routage, de fonctions de manipulations de données attachées à l’appel, etc. Projet ETOS – Benjamin Thominet - 2003

23. Les appliances: le History server cluster • Récupère les informations temps réel notifiées par le Communication server, • Gère l’historisation de toutes les données dans une base, • Réalise les différents niveaux d’agrégation d’informations • Purge la base des données inutiles ou obsolètes • La configuration se fait via le Report Configurator • enregistrement de logs, pour débuging ou stockage des principales alarmes, • génération de tickets de communications détaillés et simplifiés, • Agrégations en vue de génération de rapports statistiques pour les centres d’appels • Agrégations en vue de génération de rapports de taxation pour les environnements administratifs. • La génération des rapports proprement dite (avec mise en forme, graphes…) sera basée sur un outil du marché (Brio, BO…), ou sur un développement open-source Projet ETOS – Benjamin Thominet - 2003

24. Les appliances: Le Managment server cluster • à l’image d’une station de managment SNMP, il permet de visualiser l’état de chaque module de la solution. D’arrêter/démarrer les process à distance (regroupables en « environnements »), permet de visualiser les alarmes et d’y attacher des scripts de traitement. Chaque module doit également être manageable sur une station SNMP standard. L’interface utilisateur du Managment server est Solution Control interface Projet ETOS – Benjamin Thominet - 2003

25. Les appliances: Le contact generator • Emule la création de communications par un utilisateur. • Permet de générer des appels virtuels • Automatiquement • Sur un ou plusieurs ‘device virtuel’ • À intervalles réguliers (temporisation définie au niveau de chaque device virtuel) • Utilisé pour: • générer des rappels clients suite à demandes de rappels provenant du web, ou enregistrées pendant l’attente. • générer des campagnes d’appels sortants, • Effectuer un pooling régulier d’une boite email, pour distribution automatisée de ces e-mails sur des agents, etc. • Fonctionnement: • génère un appel sur le com server, • L’appel est immédiatement pris en charge par le com router, qui déroule le scénario, par exemple: • cherche une cible (client à appeler) ou un motif (email en attente). • S’il n’en trouve pas, stoppe l’appel et envoie une demande de temporisation au contact generator (qui attend donc la fin de cette temporisation avant de lancer à nouveau des appels savant qu’il lance une nouvelle tentative (la tempo dépend du scénario) • Sinon, selon le scénario, il cherche un agent pour traiter la demande pendant que le contact generator, voyant que sa tentative abouti (et qu’il y a donc potentiellement encore du travail) continue de générer des contacts (jusqu’à envoi d’une demande de tempo par le com router) Projet ETOS – Benjamin Thominet - 2003