Programmation de services sensibles au contexte en téléphonie sur IP

Transcription

1 Programmation de services sensibles au contexte en téléphonie sur IP Présentation de mémoire Grégory Estienne Sous la supervision du Dr. Luigi Logrippo

2 Introduction La téléphonie sur IP comme support à la programmation de services personnalisés Architecture ouverte Protocoles standardisés Convergence des réseaux de communication Cohabitation des différents médias : audio, vidéo, texte,... Une nouvelle génération de services : les services sensibles au contexte (context-aware services) Utilisation d un contexte pour déterminer le comportement à adopter face à un événement 2

3 Introduction En quoi consiste la programmation de services? Si je reçois un appel provenant de alors transférer l appel à ma messagerie vocale. 3

4 Introduction Quelques définitions : Programmation de services : modifier le fonctionnement du système en remplaçant le traitement conventionnel des requêtes par un autre plus adapté à ses besoins. Service : concept global, fait référence à un mécanisme qui permet l'accès à un ensemble de fonctionnalités, ex: service de contrôle d'appel (cache les fonctions de rejet, redirection, etc.) Politiques : informations qui déterminent le comportement à adopter en fonction du contexte d'application, sans nécessiter de recompilation ou redéploiement, ex: transfert d'appel si occupé. 4

5 Introduction Quelques définitions : suite... Contexte : ensemble des paramètres caractérisant l'état et l'environnement d'une entité à un moment donné dans le temps. Notion à rapprocher du terme présence : moyen d'exprimer la capacité et la volonté d'un utilisateur à communiquer au travers d'un ensemble d'appareils. Sensibilité au contexte : capacité d'un système à collecter des informations à propos du contexte d'application et à exploiter ces données dans le but de s'adapter aux changements de l'environnement et ainsi rendre son comportement plus pertinent vis à vis de la situation. 5

6 Objectifs du projet Notre projet : Concevoir un modèle d architecture services sensibles au contexte en VoIP. Développer un langage de programmation capable d exprimer ces services. Programmer une interface utilisateur exploitant ce langage afin de faciliter la création de services. adaptée aux 6

7 Exemples de services Filtrage d'appel compte tenu de la nature de l'appelant : "refuser toutes les communications entrantes provenant des utilisateurs figurant sur ma liste noire". Sélection des appels, en fonction de leur nature : "accepter les appels urgents". Transfert d'appel suivant l'activité de l'utilisateur : "transférer tous les appels vers ma messagerie vocale lorsque je me trouve en réunion". 7

8 Exemples de services Etablissement d'appel relativement au contexte d'un autre utilisateur : "initier une communication vocale avec Alice dès qu'elle sera disponible". Programmation de notication : m'avertir par messagerie texte tous les vendredis à 16h de "Tu as encore oublié d'aller chercher les enfants à l'école!" si je me trouve encore au bureau". Et pouvoir faire des combinaisons de fonctionnalités... 8

9 Plan de la présentation 1) Mode de fonctionnement de la VoIP 2) Modèle d'architecture de services 3) Langage de description de politiques 4) Interface web utilisateur 9

10 Fonctionnement de la VoIP 10

11 Architecture de services 11

12 Architecture de services Déploiement : terminaux vs. équipement central sur le réseau, besoins : accessibilité : mobilité des utilisateurs, indépendance vis à vis du terminal ou protocole de communication employé. disponibilité : certains services s'accomodent mal des interruptions provoquées par l'arrêt du terminal sur lequel le service était justement activé, ex: transfert d'appel en cas d'absence... fiabilité : les terminaux peuvent tomber en panne et contrairement aux serveurs sur le réseau, aucune solution de secours ou "backup" n'est généralement prévue. sécurité : les serveurs, administrés par des professionnels du domaine, présentent généralement une plus faible vulnérabilité aux failles. performance : bien que les terminaux aient acquis de plus en plus de capacités au fil du temps, certains services restent encore trop exigeants pour être déployés sur des terminaux 12

13 Architecture de services 13

14 Architecture de services 14

15 Architecture de services 15

16 Architecture de services 16

17 Architecture de services Avantages de ce modèle : Ouverture : capable d'interagir avec d'autres ressources disponibles sur internet, ex: bases de données. Indépendance : protocole, terminal, serveur de VoIP. Mobilité accrue : services disponibles sur tout le réseau. Gestion facilitée : services et informations contextuelles. 17

18 Programmation de services Deux visions s'affrontent : solutions basées sur des langages généralistes, expressifs mais peu sécuritaires vs. solutions fondées sur des langages spécialisés, limités mais sûrs. La différence : le public visé! Notre projet : définition de services destinée aux utilisateurs finaux, public de non-initiés, aucune connaissance prérequise. Solution : programmation à 2 niveaux bibliothèque de fonctions pré-programmées par des spécialistes définition des politiques par assemblage d'éléments 18

19 Programmation de services Modèle ECA : modèle de représentation sous forme de règles suivant une structure de type Event Condition Action. Format d'une règle de type ECA : " On Event If Condition Do Action " Qui signifie : lorsque l'événement spécifié survient, si la condition est vérifiée, alors exécuter l'action. 19

20 Programmation de services Structure du langage : règle ::= événements [conditions] actions événements ::= événement (événements ou événements) conditions ::= condition (conditions et conditions) (conditions ou conditions) actions ::= action (actions et actions) (structure inspirée du langage APPEL) 20

21 Programmation de services Utilisation du langage XML, langage de balisage générique extensible, pour définir les documents de règle. Définition d'un schéma XML : décrit la structure du langage de description de politiques (PDL) développé. impose les mécanismes de construction des règles spécifie les types valides des éléments Séparation du fond et de la forme : noyau général du langage (structure des règles) clairement séparé du "vocabulaire", spécialisé au problème des services de contrôle d'appel en VoIP. 21

22 Programmation de services Règle : séquence de 3 ensembles contenant chacun un type d'élément du langage (Event Condition Action) <xs:sequence> <xs:group ref="event_set"/> <xs:group ref="condition_set" minoccurs="0"/> <xs:group ref="action_set"/> </xs:sequence> Ensemble de conditions : choix entre une condition simple ou une condition composée <xs:choice> <xs:element ref="condition"/> <xs:element ref="composite_condition"/> </xs:choice> 22

23 Programmation de services Condition composée : choix au niveau de l'opérateur de combinaison, association avec deux ensembles de conditions, substituables à leur tour <xs:sequence> <xs:choice> <xs:element name="and"/> <xs:element name="or"/> </xs:choice> <xs:group ref="condition_set"/> <xs:group ref="condition_set"/> </xs:sequence> Condition : élément substituable par divers types prédéfinis <xs:element name="event" type="xs:anytype" abstract="true"/> 23

24 Programmation de services Différents types d'événements, de conditions et d'actions forment le «vocabulaire» du langage, par exemple : <xs:element name="incoming_invite" substitutiongroup="event"> <xs:complextype> <xs:sequence> <xs:element name="caller" type="caller"/> <xs:element name="protocol" type="protocol"/> <xs:element name="content" type="content"/> <xs:element name="priority" type="priority"/> <xs:element name="topic" type="xs:string"/> <xs:any namespace="##other" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:element> 24

25 Interface Utilisateur Utilisation des XForms : formulaires à base de XML présentant de nombreux avantages : Séparation stricte entre la forme, le contenu et la logique : abstraction des capacités des navigateurs employés. Typage fort : détermination des données acceptables et acceptées par le formulaire, contrôle sur la validation des règles entrées par les utilisateurs. Adaptabilité : les commandes s'ajustent aux capacités du terminal / navigateur (PDA, téléphone mobile,...). Grande réutilisabilité d'éléments génériques. des éléments : bibliothèques 25

26 Interface Utilisateur Présentation de l'interface en direct : Création de la règle suivante pas à pas : Lorsque je reçois un appel SIP provenant d'alice, de priorité normale, si la date de cet appel est comprise entre le 1er et le 7 avril et un intervalle horaire compris entre 8h et 17h et si je suis en réunion alors lui répondre par un message que je suis très occupé. 26

27 Conclusion Contributions : Elaboration d un modèle d architecture adaptée aux services Création d'un langage de définition de politiques Développement d'une interface utilisateur de programmation Comparaison avec les solutions existantes : CPL : fonctionnalités et mode de fonctionnement plus étendu LESS : modèle plus adapté aux services choisis et meilleure gestion des services et informations contextuelles APPEL : structure simplifiée / renforcée, plus flexible et évolutive avec un éventail plus vaste de paramètres. 27

28 Conclusion Travaux futurs : Interactions de fonctionnalités Acquisition, cohérence et représentation des données contextuelles Difficultés à interfacer le système de politiques développé avec les systèmes de téléphonie sur IP existants : réalisation technique non fonctionnelle 28

29 Interface Utilisateur Au cas où il y ait un ennui technique... Quelques captures d'écrans de l'interface présentant le processus de création de règle : 29

30 Architecture de services 30

31 Architecture de services 31

32 Architecture de services 32

33 Architecture de services 33

34 Architecture de services 34