le projet etos enterprise telecommunication open suite

Le projet ETOSLe projet ETOS

Enterprise Telecommunication Open Enterprise Telecommunication Open Suite Suite

ETOS:ETOS:Présentation généralePrésentation générale

Projet ETOS – Benjamin Thominet - 2003

ETOS: qu’est-ce?ETOS: qu’est-ce?

Un projet de réalisation d’une solution complète d’applications de communications voix (et plus) pour entreprise

Open sourceDoit 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


ETOS, pourquoi un tel projet?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


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.

Aspects économiquesAspects économiques

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

La convergence administratifs/centre La convergence administratifs/centre d’appelsd’appels


le principele 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


RoutageRoutage

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.


LoginLogin

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


Ressources vocalesRessources 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.


Les opératricesLes 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


Le centre d’appels informelLe 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

ETOS: présentation techniqueETOS: présentation technique


ETOS: technologiesETOS: 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


ETOS: principes d’architectureETOS: 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


Communication server cluster

Communication server cluster

Architecture ETOS: draftArchitecture ETOS: draftDevices Appliances

Terminaux• postes• Softphones• PDA…

Passelles• T0/T2 <-> SIP

Ressources de traitement• Intégrées à la passerelles ou solution logicielle sur PC

Communication router cluster

History server cluster

Data access server cluster

Configuration server cluster

Managment server cluster

Base de donnée:

MySQL ou d’entreprise

Serveur Web:Apache ou d’entreprise

Routing DesignerRouting Designer

Interfaces client léger

Reports Configurator

Reports Configurator

Configuration Manager

Configuration Manager

Solution control interface

Solution control interface

Serveur de messagerie POP3/SMTP

Exchange/dominoOu open source

Contact generatorContact

generator

H323 émulator

Communication server cluster:

SIP proxy&registrar,Message server(event/request/

user)

Communication server cluster:

SIP proxy&registrar,Message server(event/request/

user)


Les devicesLes 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)


Les appliances: généralitésLes appliances: généralités

Socle technologique de la solutionChaque module serveur est clusturisable

afin de le sécuriserAfin 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)


Les appliances: le communication server cluster 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 SIPSIP 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.


Les appliances : Le database access server Les appliances : Le database access server clustercluster

Centralise les accès aux données pour toutes les applicationsConfigurationHistorique…

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


Les appliances: Le configuration server: 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 gestiondroits 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


Les appliances: Le communication router clusterLes 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.


Les appliances: le History server clusterLes 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


Les appliances: Le Managment server clusterLes 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


Les appliances: Le contact generatorLes 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)

le projet etos enterprise telecommunication open suite

Documents