Projet CCTI VoIP&Mobility. Auteurs: Laurent Schweizer Nicolas Anagnostopoulos. Prof : Stefano Ventura

Transcription

1 Projet CCTI VoIP&Mobility Auteurs: Laurent Schweizer Nicolas Anagnostopoulos Prof : Stefano Ventura

2 Société Mandataire du projet TCOM/EIVD TCOM/EIVD Titre Nom du fichier Date 9 février 2005 Version 1 Statut Classification Auteurs Document de travail S Ventura, Nombre de pages 51 Modifications Distribution Distribution N Stefano Ventura

3 Table des matières : 1 Introduction Call Processing Language Introduction Que peut faire CPL? Création des scriptes Fonctionnement des scripts Exécution des scripts Conclusion sur CPL Common Gateway Interface, CGI Introduction Possibilité des sip-cgi Création des scripts Comparaison cgi-sip et cgi-bin Conclusion SIP Servlets API Introduction Architecture Choix de la servlet lors de l arrivée d un message Que peuvent faire les servlets SIP? Fonctionnement des servlets Création de servlets SIP Conclusion The JAIN APIs Introduction : But Architecture Les différentes APIs de JAIN JAIN et SIP JAIN Call Control Introduction Les différents modules Les composants de base Interaction entre les applications et l API Evénements... 23

4 5.6.6 Java Core Package JcpProvider Etat d un provider JcpCall JcpConnection JcpAddress Java Call Control JccProvider JccCall JccConnection Evènements et évènements bloquent JccAddress Event Filter Relation entre JCC, JCP et JTAPI JAIN Service Logic Execution Environment (JAIN SLEE) JAIN Service Creation Enviroment (JAIN SCE) OSA et Parlay Introduction Architecture OSA 3GPP Les applications clientes Le serveur d applications Les Services Capability Servers (SCS) Les Service Capability Features (SCF) Le Gateway CORBA Le groupe Parlay UML Structure des APIs Parlay Le Framework Parlay et la sécurité Les Services Parlay La spécification des données Conclusion Bibliographie

5 1 Introduction Il y a bien longtemps que l ont sait téléphoner et actuellement ceci ne nous suffit plus, en effet le monde moderne est très demandeur de nouveaux services, plusieurs de ces services peuvent et doivent être implémenté dans les terminaux ( téléphone ou client PC) ainsi ils restent sous le contrôle des utilisateurs, ils peuvent ainsi les modifier, les personnaliser ou les développer selon leurs besoins. Traditionnellement, les services de téléphonie basés réseau sont développés et gérés par des providers, typiquement créés pour des interfaces propriétaires avec des outils restreint et propriétaires, il en résulte que l utilisateur final ne peut pas ou que très peu personnaliser ces services, en ce qui concerne le développement de service spécifique, cette possibilité n existe pas. Dans l environnement d Internet ceci est différent, le but est de laisser à l utilisateur final la possibilité de créer, personnaliser, modifier ces services selon ses besoins. Pour avoir cette même souplesse dans la téléphonie VoIP, il est important de posséder des interfaces normalisées (API). Ce document a pour but de présenter quelques-unes une de ces interfaces, d expliquer leurs possibilités et leurs avantages. 5

6 2 Call Processing Language 2.1 Introduction CPL est un langage utilisé pour décrire et contrôler des services de téléphonie basée sur Internet. Ce langage basé sur du XML est de haut niveau il fait donc abstraction du protocole de signalisation utilisé. 2.2 Que peut faire CPL? Ce langage a été créé pour décrire un grand nombre de services tel que déviation en cas de non-réponse ou d occupation, ex déviation sur un répondeur en cas de non-réponse distribution intelligente des appels, ex. en fonction de l heure, l appel va être redirigé au bureau, sur un portable ou sur un répondeur renvoi d information sous la forme d une page web ex. une entreprise possède un numéro de téléphone général pour des éventuels clients. Si une personne appelle pendant les heures de bureau elle obtiendra alors sous la forme d une page web la liste des interlocuteurs disponibles avec une indication de leur secteur d activité. Dans le cas ou l appel a lieu en dehors des heures de bureau, elle obtiendra un page avec les heures durant lesquelles elle peut téléphoner. cependant il n est pas possible de tout faire, afin de garantire une certaine sécurité (pour le provider) l utilisateur ne peut que décrire un service de téléphonie, ainsi, ce langage ne dispose pas de variables, de boucles et il lui est impossible d exécuter des programmes extérieurs. 2.3 Création des scriptes Le CPL est basé sur du XML, ce langage très simple peut être créé, généré de plusieurs manières, un peut comme du HTML. A la main, Les scripts peuvent être créer avec un simple éditeur de texte par des utilisateurs avertit, la syntaxe n est pas très compliquée. Avec un script, Ces scripts peuvent être générés par d autres scripts de manière automatique Avec un outil graphique, Comme ce langage est très simple il est possible d utiliser des outils graphiques pour générer ces scripts, il est bien évident que cette solution est la plus intéressante si l on 6

7 désire mettre ce service à disposition de personnes ne sachant pas programmer. 2.4 Fonctionnement des scripts Le service que l on va créer est décrit par une collection de nœuds qui indiquent les opérations ou les choix à effectuer, un nœud peut avoir plusieurs paramètres et plusieurs sorties, elle sera choisie en fonction du résultat de l action ou du résultat de la décision. La figure 1 est une représentation graphique d un script CPL L on peut voir que ce script possède un point d entrée, il s exécute ensuite jusqu a ce qu il arrive sur un nœud sans sorties (proxy ou redirect, le proxy possède bien des sorties mais uniquement dans le cas d un timeout). Durant son déroulement, chaque action contenue dans les nœuds parcourus sera exécutée. Figure 1, représentation graphique d un script CPL 7

8 La figure n 2 est le code de cette représentation graphique ( sans la partie Voic ) Figure 2, code CPL 2.5 Exécution des scripts Généralement les scripts CPL sont associés avec une adresse ( n de téléphone ). Quand un appel arrive au serveur CPL il recherche dans sa base de données le script à exécuter en fonction de l adresse source et de la destination. 2.6 Conclusion sur CPL Ce langage peut être utilisé pour créer de nombreux services de bases, toutefois il a une limitation importante puisqu il ne peut obtenir des données extérieures ( base de données, fichiers ) Cette limitation à été imposée afin d obtenir un maximum de sécurité pour le provider, il faut bien comprendre que le but est que chaque utilisateur puisse créer sont propre script et le télécharger sur le serveur. Avec du CPL le provider sait qu il prend peut de risque car l utilisateur ne peut que traiter des appels qu ils lui sont destinés et il ne peut pas endommager, surcharger ou détruire les données du serveur. Un autre avantage du CPL est qui peut être facilement généré à partir d outils graphiques, il est donc utilisable pour un grand nombre de personnes, ce langage se place donc en excellente position pour devenir un outil de développement pour la création de petit service de téléphonie 8

9 3 Common Gateway Interface, CGI 3.1 Introduction Les scripts sip-cgi sont là pour étendre les possibilités des proxy ou serveur de redirection SIP sans devoir changer le code du serveur. En effet ces scripts ont un contrôle total sur les messages SIP (header et body) 3.2 Possibilité des sip-cgi Contrairement au CPL, les scripts SIP-CGI n ont pas de limitation, ils peuvent obtenir des données de l extérieur ( base de données, fichiers etc.), de plus ils ont un contrôle total sur les messages SIP. les CGI peuvent être utilisés pour : La détection de boucles L authentification Dévier (occupé / pas de réponse) Le passage de firewall ( demande d ouverture d un port RTP) Les déviations intelligentes La distribution des appels ( mise en queue) Thrid-party registration, control Etc Contrairement aux scripts CPL qui sont exécuté lors d un nouvel appel, les CGI le sont à chaque message ( sauf pour ACK et CANCEL), ils peuvent ainsi retransmettre, répondre ou générer des nouveaux messages 3.3 Création des scripts Le langage utilisé pour créer ces scripts est libre ( perl, c, c++, vb script). 3.4 Comparaison cgi-sip et cgi-bin Les scripts SIP-CGI sont similaires aux scripts CGI-BIN, tous deux ne définissent pas le langage dans lequel le script est implémenté et on a un contrôle total sur les entêtes/messages, cependant il y a bien quelques différences, en effet dans le modèle HTTP la réception d un message provoque l émission d une réponse sans ce préoccuper de ce qui avait fait auparavant, avec SIP ceci n est plus possible. Il a donc fallu introduire un model de persistance de manière à pouvoir garder une trace de ce qui a été fait et de réagire en fonction des évènements passés. Ceci a été fait en ajoutant des cookies au message SIP, il s agit de lignes qui sont ajoutées à la fin du message SIP, elles ne sont pas 9

10 traitées par le serveur (il les recopie uniquement dans les réponses qu il émet ) Une autre différence importante, avec les CGI-BIN, une demande donnait lieu à une réponse, dans notre cas une demande peut induire plusieurs messages en sorties. 3.5 Conclusion Les sip-cgi sont nettement moins limitatif que les CPL mais ceci se paye au niveau de la sécurité, elle n est pas nulle mais doit être très soigneusement paramétrée au niveau de l OS. Ces scripts seront utilisés pour étendre les possibilités des serveurs, ils sont réservés à des utilisateurs sachant programmer plus particulièrement au provider. 10

11 4 SIP Servlets API 4.1 Introduction Cette api est une extension java pour les serveurs SIP, similaire au servlets HTTP elles sont prévues pour développer tout type de services. Elles peuvent interagire avec d autres sources de données tout en garantissant une bonne sécurité, il est en effet possible de confiner les servlets à n utiliser que les ressources de la machine virtuelle. 4.2 Architecture L architecture est propre à chaque serveur, si on prend celle du serveur de HP, la couche SIP se situe juste en dessus des couches Proxy et Registrar ( figure n 3) alors que dynamicsoft la place en seconde API, après Jain (figure n 4) Figure 3, architecture du serveur HP 11

12 Figure 4, architecture selon dynamicsoft 4.3 Choix de la servlet lors de l arrivée d un message Lorsque des messages SIP arrivent le serveur (redirection, proxy ) va exécuter une servlet, pour cela il dispose de règles qui lui permettent en fonction du type message SIP, de l appelant, de l appeler, de déterminer la servlet à exécuter. Figure 5, choix de la servlet 12

13 4.4 Que peuvent faire les servlets SIP? L API donne le contrôle total aux servlets SIP sur les messages (header et body), elles peuvent retransmettre, rediriger, répondre ou rejeter un message, les servlets ont aussi la possibilité d initier des requêtes. Tout comme les SIP-CGI, elles peuvent accéder à des données extérieurs par l intermédiaire des mécanismes standard de java, exemple: JDBC, pour l accès aux bases de données JNDI, pour les bases LDAP JMF, pour la manipulation de media, ex. Codecs, RTP The speech API JavaMail... Cependant la sécurité est bien meilleure qu avec les CGI, en effet on peut confiner l exécution du programme java dans l environnement de la machine virtuelle. 4.5 Fonctionnement des servlets Lors de l arrivée d un message, celui-ci est décomposé lors de son passage à travers le stack SIP, puis en fonction des règles ( voir figure 5), le message décomposé sera transmis à une des servlets, elle pourra, répondre à ce message, le transférer ou effectuer toute autre manipulation sur celui-ci. Figure 6, architecture simplifiée 13

14 Dans cet exemple figure 7, la servlet est utilisée comme proxy, elle doit donc déterminer l adresse actuelle des agents (ex. base de données avec JDBC) et transférer les messages vers celui-ci. Figure 7, servlet utilisée comme serveur de redirection / proxy Dans l exemple de la figure 8, la servlet reçoit le flux RTP, elle fait donc office d agent SIP avec la particularité de ne pas forcément rediriger le flux voie vers des haut-parleur, en effet elle pourrait traiter ce flux avec une reconnaissance vocale. Figure 8, servlet utilisée comme agent SIP 14

15 4.6 Création de servlets SIP Les servlets SIP sont basées sur une interface en java, elles devront donc être développées dans ce même langage, bien entendu il est possible de réutiliser des outils standard de développement pour java. Le développement des servlets SIP est similaire au développement de servlets HTTP, la principale différence est comme pour les CGI, le fait que pour SIP on doit maintenir un historique de ce qui a été fait. 4.7 Conclusion Les servlets SIP ont un avenir très prometteur, en effet il est possible de développer un grand nombre de services avec des accès aux sources de données extérieures tout en garantissant une bonne sécurité mais contrairement au CPL, ce type d outils pour la programmation de service reste réservé à des personnes sachant programmer (en java). Un autre avantage non négligeable est que les services développés avec cet outil sont totalement portables puisqu il ne dépend pas du serveur mais de l interface qui est implémentée par celui-ci. 15

16 5 The JAIN APIs 5.1 Introduction : JAIN est un ensemble d APIs qui permettent de développer rapidement des nouveaux services. Ces APIs ont pour but d offrire des nouveaux niveaux d abstraction, en effet avec cette ensemble d APIs il est possible de créer un service sans que l on connaisse le serveur (HP, VOVIDA, CISCO ) ou le protocole de signalisation( TCAP, SIP, MGCP) utilisée par celui-ci. Le but de JAIN n est pas seulement d intégrer les systèmes de communication basés paquets (IP, ATM) mais bien pour tous les systèmes de communication comme, les réseaux sans fil, PSTN ou paquet. Ceci peut être constaté sur la figure 9 qui donne un premier aperçu de l architecture de JAIN Figure 9, architecture de JAIN 16

17 5.2 But Actuellement les solutions viennent d un vendeur qui fournit dans une grande boite totalement propriétaire le matériel et le logiciel du serveur ainsi que les services. Les clients dépendent donc de ce vendeur, il en résulte des coûts d extensions et de maintenances élevés. Avec JAIN on obtient une solution ou les différentes parties du serveur proviennent de vendeurs différents, le client peut ainsi choisir les différentes parties en fonction de ces besoins Figure 10, transfert d'architecture 5.3 Architecture Le but de JAIN est de créer des services de nouvelles générations pouvant intégrer des communications par paquets (IP, ATM ), PSTN et WIRELESS. Il a donc été nécessaire de définir un environnement d exécution indépendant du protocole de signalisation. Pour cela, plusieurs couches d abstraction ont été créées ( voir figure n 11), il définit aussi une librairie de composant, des outils de développement et un environnement de création de services Comme nous l avons dit, JAIN définit des couches d abstractions, elles sont au nombre de trois : Network layer: Il s agit d une couche définissant le protocole de communication choisit. Télécommunication : Réseaux intelligent (AIN/IN) ou SS7 avec beaucoup de protocole ISUP,TCAP,INAP Wireless : SS7 avec des applications mobiles (MAP) 17

18 VoIP : SIP, MGCP, Megaco, H.323 Signaling layer: Il s agit d une couche représentant les logiciels chargés de la gestion des communications Télécommunication : Signaling Service Point (SSP) Wireless : Mobile Switching Centers (MSC) VoIP : Proxy, redirect serveur, H 323 gatekeeper, media gateway controllers Service layer : Il s agit d une couche représentant les services de base. Télécommunication : Service Contrôle Points (SCP) Wireless : Base Station Controllers (BSC), Home Location Registers (HLR) VoIP : Serveur d applications internet Figure 11, architecture de JAIN 18

19 5.4 Les différentes APIs de JAIN L interfaçage des différentes couches d abstraction est faite au moyen d APIs La 1 er est une interface au niveau du protocole, elle définit ce que doivent fournir les stacks de signalisation. Ces interfaces sont propres à chaque protocole, sont but est de fournir une indépendance du vendeur, il est ainsi possible d acheter un stack SIP chez CISCO, DYNAMICSOFT ou Pour que celui-ci soit compatible il suffit qu il implémente l interface JAIN La 2 ème API est la JAIN JCC/JCAT, l objectif de cette API est de fournir une abstraction du protocole de signalisation utilisé. Elle fournit les mécanismes pour la gestion, le traitement et le contrôle des communications. JCC et JCAT fournissent les outils pour pouvoir observer, initier, répondre, traiter et manipuler des appels contenant des sessions multimédia. JCC contient les mécanismes de base de JTAPI mais peut être étendu pour fournir des traitements d appel plus complexes. JCAT gère la coordination et les transactions entre les différents services, il offre des nouvelles possibilités pour pouvoir exécuter des applications avant, pendant et après le traitement d un appel, il est typiquement utilisé pour des nouveaux services tel que la gestion de firewall La 3 ème interface fournit une abstraction de l opérateur pour la création de nouveau service 5.5 JAIN et SIP Trois API ont été définies pour SIP : JAIN SIP, il s agit d une API de bas niveau basée sur le RFC 2543 elle se situe juste en dessus du stack SIP JAIN SIP Lite, il s agit d une API haut niveau fournissant une abstraction du stack SIP, elle peut être utilisée pour créer un agent SIP JAIN SIP Servelts, voir la partie consacrée au servlet Actuellement seul la spécification de JAIN SIP est disponible, elle est fournie avec une bonne documentation qui décrit toutes les méthodes de l interface. ( javadoc) La figure n 12 montre leur imbrication dans un stack SIP, comme on peut le voir, elles ne sont pas concurrentes mais fournissent des abstractions et services différents. 19

20 Figure 12, les différentes API SIP 5.6 JAIN Call Control Introduction Cette API a été développée pour fournir un modèle d appel générique, elle reprend les aspects essentiels des modèles d appel déjà existants. Cette interface donne au programmateur une bonne abstraction pour qu il puisse facilement manipuler des appels et gérer les interactions entre ceux-ci et d autres applications. Cette interface permet de créer, gérer, manipuler, terminer des appels pour des réseaux PSTN, paquets et sans fils. Elle supporte le first-party tout comme le third-party, il est aussi possible d exécuter des applications durant les sessions, ce qui permet d appeler des services intelligents. 20

21 5.6.2 Les différents modules Cette API est spécifiée par un ensemble d objets qui modélisent différents éléments physiques et logiques impliqués dans une session. Les applications interagissent avec cette API en utilisant le modèle des l LISTNER. L API est divisée en 3 paquetages : Elementary Call Control : Java Core Package (JCP) fournit les services basiques pour initier et répondre à un appel, il est probable que ces services ne son pas assez avancés pour être utilisés pour la création de nouveaux services, néanmoins ce module représente un concept important pour l unification de JTAPI, et de JAIN. Core Call Control : JCC fournit les services pour pouvoir observer, créer, manipuler, traiter et terminer des appels, il permet aussi d exécuter des applications durant une session. Quand nous parlons d appel il faut bien comprendre qu il s agit pas que de voix, mais aussi de données et ou des sessions multimédia. Il existe encore le paquetage JCAT qui étend les possibilités du Call Control, actuellement sa spécification n est pas encore terminée elle n as donc pas encore été rendue publique. Remarque: ces différents paquetages doivent s exécuter sur la plate-forme de communication ( ex. Call agent ou softswitch) Java Call Processing (JCP) Java Call Control (JCC) Figure 13, relation entre JCP et JCC 21

22 5.6.3 Les composants de base Pour JCC et JCP l API est composée d interface, de classes, d opérations, d événements, etc L API fournit 4 éléments qui sont commun à JCP, JCC et d autres paquetages plus avancés, il s agit du : Provider : cet objet est une abstraction représentant le fournisseur de services. Il dissimule les aspects spécifiques au service du sous système et permet aux applications java d interagire avec celui-ci est ce indépendamment du protocole et de l implémentation utilisée. Call : cet objet représente un appel (voix, data ou multimédia), il représente aussi une connexion dynamique entre les entités physiques et logiques. Address : cet objet représente l adresse logique d un terminal (ex. n de téléphone, adresse IP) Connection : cet objet représente la liaison dynamique entre l objet Address et l objet Call La figure n 14 montre la relation entre les différents objets pour une relation entre 2 terminaux. Provider Call Connection Connection Address Address Figure 14, model d'objet utilisé pour une connexion entre 2 terminaux 22

23 5.6.4 Interaction entre les applications et l API Les applications qui se situent en dessus de l API font des appels synchrones aux méthodes de celle-ci. La plate-forme qui implémente l API peut informer les applications que un événement c est produit (exemple, nouvel appel ) en utilisant les événements JAVA, pour cela les applications doivent fournir des listeners correspondant aux événements qui les intéresses. Provider Listener Call Listener Connection Listener Provider Call Synchronous method calls Java Events Connection Connection JCC API Network or Platform Figure 15, interaction entre logiciel et API Evénements Différents objets peuvent générer des événements, ceux-ci peuvent être interceptés par différents Listners. La figure n 16 montre l organisation des objets Event et Listener, l objet ProviderEvent indique tout changement d état intervenu dans le JcpProvider, CallEvent indique tout changement intervenu dans l objet JcpCall et ConnectionEvent indique tout changement dans JcpConnection. Ces événements sont alors transmis à leur Listener respectif soit ProviderEvent à ListenerEvent, CallEvent à CallListener, ConnectionEvent à ConnectionListener. Event Events Listener Listeners Call Event Provider Event Call Listener Provider Listener Connection Event Connection Listener Figure 16, organisation des objets Events et Listners 23

24 5.6.6 Java Core Package Nous allons maintenant décrire les composants basic de JCP, Il s agit d un paquetage élémentaire qui est utilisé par des paquetages plus avancés. Il fournit des méthodes pour pouvoir placer et arrêter des appels. JcpProvider JcpProvider représente l entité logiciel d un central téléphonique avec ces interfaces et un sous système de téléphonie. Le système de téléphonie peut être un PBX relié à un serveur, une carte téléphone / fax dans un PC ou un central basé sur les réseaux informatique (VoIP). Etat d un provider Les providers possèdent trois états : IN_SERVICE : cet état indique que le provider et actuellement en fonctionnement et qu il est disponible OUT_OF_SERVICE : cet état indique que le provider n est actuellement pas disponible, beaucoup de méthodes du provider sont incorrectes lorsqu il se trouve dans cet état. Il peut à tout moment revenir dans l état IN_SERVICE, mais l application ne peut prendre aucune mesure directe pour causer ce changement SHUTDOWN : cet état indique que le provider n est pas disponible. La plupart des méthodes du provider sont incorrectes lorsqu il se trouve dans cet état. Les applications ont accès à une méthode pour mettre celui-ci dans cet état. IN_SERVICE SHUTDOWN OUT_OF_SERVICE Figure 17, état d'un provider Une application ne peut pas créer un provider, elle peut uniquement en obtenir un avec la méthode getprovider(). 24

25 JcpCall Cet objet représente une communication entre deux (ou plus) participants. Pour un appel sortant (que l on émet), cet objet est créé en invoquant la méthode createcall() du provider. Pour un appel entrant (que l on reçoit), cet objet est créer par la plate-forme. L objet call possède une référence sur son provider, elle est initialisé lors de la création de l appel est ne change pas durant toute la durée de celui-ci. La provider associé peut être obtenu avec la méthode getprovider() de l objet call L objet call possède plusieurs état : IDLE : c est l état initial de tout call. Dans cet état il ne possède aucune connexion. ACTIVE : un call avec une activité se trouve dans cet état. Dans cet état un call doit posséder une ou plusieurs connexions. INVALID : Il s agit de l état final d un call. Dans cet état il ne possède plus aucune connexion associée. Un call dans cet état ne peut plus être utilisé pour des actions futures. IDLE ACTIVE INVALID Figure 18, état des objets call JcpConnection Un objet connection représente un lien entre un objet call et un objet adresse, un objet connection est créé pour chaque nouvelle connexion d un call. Chaque JcpConnection possède une machine d état qui décrit la relation actuelle entre le call et l adresse. Le diagramme ci dessous décrit les différents états possibles d une connexion. Comme vous pourrez le voir, il est similaire au diagramme d état d un objet connection JTAPI. IDLE : il s agit de l état initial pour toute nouvelle connexion, les connexions qui sont dans cet état ne font pas partie d un call mais les références sur l objet call et l objet address sont correctes. Les connexions ne restent pas longtemps dans cet état. DISCONNECTED : il indique que la connexion ne fait plus parti d un appel. INPROGRESS : il indique que l objet connection a été contacté par un appel ou que l objet connection contacte actuellement le destinataire. ALERTING : cet état indique que l adresse c est fait notifier un appel entrant. 25

26 CONNECTED :cet état indique que les objet connection et address font partit d un appel, donc 2 (ou plus) personnes sont en communication. UNKNOWN : cet état indique qu il est impossible de déterminer l état actuel de la connexion. FAILED : il indique que la liaison a échoué pour une quelconque raison. Ex. l appelé est occupé. UNKNOWN * except FAILED or DISCONNECTED FAILED IDLE IN- PROGRESS ALERTING CONNECTED DIS- CONNECTED Figure 19, état des objets connection JcpAddress Un objet address représente un terminal dans une communication. Cela peut être un numéro de téléphone, une adresse , etc. Chaque objet address doit posséder un nom représenté par une chaîne de caractères. Durant une communication l objet address et mit en relation avec un appel par l intermédiaire de l objet connection. L état de celui-ci décrit la relation actuelle entre l objet call et l objet address. Il existe 2 types d objet address, local et distant. Une adresse est considérée comme local si elle appartient au domaine du provider, dans le cas contraire elle est considérée comme distante Java Call Control L API JCC a les 4 même objets que JCP, soit le Provider, Call, Connection et Address. Comme JCC hérite de JCP, chaque objet possède donc les mêmes méthodes de base, de plus des nouvelles méthodes peuvent leur être ajoutées. Indication : les objets obtiennent maintenant le préfix Jcc, cela donne donc JccCall, JccProvider JccProvider 26

27 L interface JccProvider hérite de JcpProvider, une importante nouvelle possibilité fournie par JccProvider est qu il peut fonctionner comme un créateur d objet EventFilter. La fonction des objets EventFilter et d offrir un mécanisme de filtre pour les événements. ( voir: EventFilter ) Une autre méthode fournie par JccProvider et de pouvoir ajouter des listeners sur les Objets Call afin de détecter les changements d état. JccCall JccCall hérite de JcpCall, le diagramme d états est identique pour les deux interfaces, mais JccCall possède en plus une nouvelle transition possible entre l état IDLE et INVALID ( voir figure n 20) JccCall possède aussi des nouvelles méthodes: createconnection () : cette méthode va créer un nouvel objet de type JccConection routecall() : cette méthode ne va pas juste créer un objet JccConection, elle a aussi pour conséquence l initiation de la signalisation dans le réseaux vers le point final d appel. Si cette méthode est invoquée avec succès, cela indique que l appel à été correctement routé jusqu au terminal. Elle peut être utilisée pour le First party, le Third party, la translation de numéro (ex ), la redirection, etc. release(): Cette méthode à pour but de terminer un appel et de libérer les ressources. IDLE ACTIVE INVALID Figure 20, états des objets JccCall Dans JCC comme dans JCP, une application qui veut initier un appel doit tout d abord créer un objet call, pour cela elle utilise la méthode createcall(), cette methode est fournie par l interface JccProvider. Remarque : la méthode JccProvider.createCall() retourne un objet de type JcpCall qui doit ensuite être converti en un objet de type JccCall. La prochaine étape consiste à créer une connexion, ceci se fait en invoquant la méthode createconnection () de l objet JccCall, l adresse de l objet JccTerminal à associer avec cet appel doit être donnée. JccConnection L interface JccConnection hérite de l interface JcpConnection, les méthodes importantes de JccConnection sont : routeconnection( ) : est utilisé pour router une connexion vers un terminal answer( ) : est utilisé pour répondre à un appel 27

28 release( ) : est utilisé pour déconnecté un terminal continueprocessing( ) : cette méthode indique à la plate-forme de continuer le traitement des appels ( ex. après un événement ) getxxxadress( ) getmoredigits ( ) : indique à la plate-forme de collecter des informations supplémentaires sur le numéro composé ( lettre ou nombre) selectroute() :Cette méthode est utilisée pour la translation d adresse, exemple, lors de la composition d un numéro gratuit (0800.), celui-ci doit être convertir en un numéro routable ( ) La machine d état de JccConnection n est pas identique à celle de JcpConnection, il faut voir qu il s agit d un raffinement par l addition de transition et la séparation d état en état multiple. Pour être plus précis, les changements se situent pour les états INPROGRESS et CONNECTED qui sont divisés en plusieurs états. IDLE : il s agit de l état initial pour toute nouvelle connexion, les connexions qui sont dans cet état ne font pas partie d un call mais les références sur l objet call et l objet address sont correct. Les connexions ne restent pas longtemps dans cet état. AUTHORIZE_CALL_ATTEMPT : cet état implique que l appelant et l appelé doivent être autorisés à émettre et recevoir cet appel. ADDRESS_COLLECT : dans cet état, les informations (numéro composé) en provenance de l appelant sont collectées et analysées selon le plan de numérotation afin de déterminer la fin de l information d adressage ADDRESS_ANALYSE : pour entrer dans cet état il faut que le numéro composé en provenance de l appelant soit complet. Ce numéro est analysé et/ou translaté selon le plan de numérotation afin de déterminer l adresse de routage ainsi que le type d appel. CALL_DELIVERY : du côté de l appelant, cet état implique la sélection de la route et indique au numéro appelé que l on désire établir une communication. Du côté de l appelé, cet état implique qu il doit tester que le terminal n est pas déjà occupé, il doit aussi informer celui-ci de l arrivée d un appel. ALERTING :cet état indique que le terminal ce fait actuellement notifier un appel entrant. CONNECTED : cet état indique que cette connexion et une adresse prennent part à un appel SUSPENDED : cela indique que cette connexion a été suspendue de l appel, elle garde ces références sur l appel et sur l adresse DISCONNECTED : il indique que la connexion ne fait plus parti d un appel. UNKNOWN : cet état indique qu il est impossible de déterminer l état actuel de la connexion. FAILED : il indique que la liaison a échoué pour une quelconque raison. Ex. l appelé est occupé. 28

29 Figure 21, états de JccConnection Evènements et évènements bloquent Chaque transition (changement d état) d une connexion va générer un ou plusieurs évènements, ceux-ci seront transmit au Listener enregistré (voir Event Filter). Les évènements de l objet JccConnection peuvent être de deux types, bloquant et non bloquant. Quand un évènement est généré en mode bloquant, il est alors nécessaire de suspendre le traitement de la connexion à l origine de celui-ci. Si des nouveaux évènements arrivent pour celle-ci, ils seront mis en queue et traités lors de la réactivation de cette connexion. Exemple : une connexion est mise en suspens (évènement bloquant), durant cette suspension l abonné raccroche. Un évènement de fin d appel est généré mais il n est pas traité immédiatement, il sera mis en queue. La réactivation d une connexion se fait soit après un timeout, soit par l application, pour cela elle dispose de méthode tel que continueprocessing ( ) qui indique à la plate-forme de continuer le traitement pour cette connexion. 29

30 JccAddress JccAddress hérite de l interface JcpAddress, cette interface fournit uniquement une méthode supplémentaire qui permet d obtenir le type d adresse, celle-ci peut être du type IP, E164, URL, etc.. Event Filter Le but de cette interface est de fournir une meilleure flexibilité aux applications en pouvant spécifier les événements que leur Listener désirent recevoir de la plate-forme JCC. Ce service est important afin de minimiser les pertes de performance suite aux évènements, particulièrement si les applications interagissent avec la plate-forme JCC à travers un réseau. Quand un évènement est généré, la plate-forme JCC consulte l objet EventFilter afin de déterminer à quel Listner l évènement doit être notifié. S il doit être notifié à aucun Listener, celui-ci sera détruit. Si l évènement concerne un objet JccConnection, la plate-forme déterminera si celui-ci doit être notifié dans un mode bloquant, si tel est le cas elle bloquera l état de cette connexion. Deux types de filtres pour les évènements son disponible, les filtres pour évènement personnalisé et les filtres pour les évènements standard. Les filtres d évènements personnalisé sont créé par l application au moyen de la méthode addxxxlistener( ). La personnalisation des filtres est très flexible mais peut produire une perte significative de performance. Les filtres standard créés par la plate-forme JCC peuvent être invoqués avec la méthode createeventfilterxxx( ), ces filtres sont nettement plus performants car JCC met en place des techniques d optimisation. Ces filtres peuvent être basés sur une adresse, sur un provider, un appel, une connexion ou des combinaisons des ces objets. Les filtres fournis par la plateforme JCC sont moins flexibles mais devraient suffire à la plus part des applications JCC. 30

31 5.6.8 Relation entre JCC, JCP et JTAPI. Le diagramme si dessous montre les relations entre ces différentes API Java Call Processing (JCP) JTAPI Core Java Call Control (JCC) JTAPI Extensions Java Coordination & Transactions (JCAT) Parlay Extensions Figure 22, relation entre JCC, JCP et JTAPI L ellipse de gauche représente le call contrôle est ses extensions pour les applications de type CTI. JTAPI Core définit un modèle permettant de gérer des appels basiques, des extensions lui ont été ajoutées lui permettant d effectuer des déviations, des transferts d appel, etc. Il est principalement destiné aux call center, pour le routage d appel et les conférences multipaty. L ellipse du milieu représente les paquetages fournis par JAIN, on y retrouve JCP et JCC, JCAT est aussi inclus. Ce paquetage fournit des fonctions avancées pour le call control et pour les plates-formes IN/AIN. Des efforts ont été faits avec JAIN afin qu il reprenne les meilleurs aspects du Core de JTAPI et d autres models d appels existants afin de fournir une interface avec une famille de models. 31

32 5.7 JAIN Service Logic Execution Environment (JAIN SLEE) Sur la figure n 23 on peut constater que ce module se trouve dans la couche service, il s agit d un ensemble d APIs fournissant des fonctionnalités généralement utilisées, il est ainsi possible de développer rapidement des nouveaux services. Cet environnement offre plusieurs avantage : Il permet au développeur de se concentrer sur le service qu il désire créer sans se préoccuper de l infrastructure est des protocoles de signalisation utilisés Les services sont indépendants des changements du réseau et ou du protocole utilisé. Tout service développé pour cet environnement fonctionnera dans un autre environnement JSLEE. Il est possible de créer rapidement des nouveaux services en combinent des services existant. Figure 23, architecture de JAIN 32

33 JAIN SLEE spécifie : ( voire figure n 24) Un model pour le cycle de vie des services. Un model pour les composants des différents services Les mécanismes de déploiement des différents services Les mécanismes de management des interfaces Les mécanismes de transmissions asynchrones entre application Figure 24, environnement d exécution Malheureusement il nous est difficile, pour l instant dans dire plus de cette interface, en effet sa spécification n étant pas finie, elle n a pas encore été rendue publique. 33

34 Création de service pour SLEE Comme le montre la figure n 25 il y a deux possibilités pour créer des services pour JAIN SLEE. La 1 er consiste à utiliser un éditeur conventionnel ou un outil de développement pour java puis de compiler le service et de le déployer dans l environnement JAIN SLEE. La seconde solution est d utiliser l outil SCE mis à disposition par JAIN Figure 25, création de service pour JAIN SLEE 5.8 JAIN Service Creation Enviroment (JAIN SCE) JAIN est un environnement de développement pour des services fonctionnant dans SLEE, il permet de créer des services à partir de composants ( JavaBeans, fichier XML, Servlets) déjà créés et testés. Le développement de service avec JSCE peut se faire avec différents outils : Avec des documents XML, avantages : o Ils conviennent bien à la création de service par les utilisateurs o De nombreux langages de gestion d appel basé sur du XML existent (ex. Call Processing Language, Call Policy Markup Language, Telephony Markup Language, ) il est donc possible de réutiliser des scripts déjà existants JavaBeans o Peuvent être interconnectés à un GUI afin d offrir une interface graphique Autres méthodes compatibles JSLEE 34

35 JSCE fournit aussi une gestion des services créés avec ces outils, il peut vérifier leur compatibilité et les compacter sous la forme de module qu il pourra directement déployer. Une gestion des versions et recherches des dépendances est aussi disponible. Enfin il est possible de tester avec des outils de simulation les différents services avant de les déployer. La figure n 26 nous indique le déroulement des principales étapes pour le développement d un service avec JAIN, comme ont peut le voir, il est possible de développer et tester le service avec JSCE. Lorsque que celui-ci est prêt et fonctionnel il peut être déployer dans l environnement d exécution JSLEE Figure 26, les différentes étapes pour la création d'un service 35

36 6 OSA et Parlay 6.1 Introduction A peu près au même moment où la communauté JAIN se mettait en place et débutait ses travaux, British Telecom (BT), Microsoft, Nortel, Siemens et Ulticom formaient le Parlay Group, qui a donné le jour à une panoplie d APIs orientées objet et indépendantes du langage les exploitant, afin de faciliter la création de services dans les réseaux publics de tous types. Les APIs d applications définies par le groupe Parlay doivent permettre un accès ouvert mais sécurisé à un ensemble de fonctionnalités aujourd hui rendues par les différents réseaux privés ou publics. Il est attendu de la publication de ces APIs qu elles soient utilisées par une plus grande communauté de développeurs afin de dynamiser le développement de nouveaux services de télécommunications, nous l avons déjà dit. Mais pour ce faire, les spécifications que définit Parlay ont besoin d un modèle architectural standardisé permettant aussi de prendre en compte des abonnés mobiles, et le modèle OSA développé conjointement par le 3GPP s est avéré idéal pour une mise en commun des efforts du Parlay Group avec le groupe de travail du 3GPP, qui ont dès lors collaboré à l édification d un standard commun OSA/Parlay. OSA/Parlay n offre pas seulement la possibilité aux opérateurs d ouvrir leurs réseaux à des parties tierces, mais s adresse également aux opérateurs câblés comme aux opérateurs sans fils, en proposant sans différenciation aucune une nouvelle méthode peu coûteuse, rapide et efficace pour créer leurs propres services en fonction de la demande qu ils perçoivent. Au premier abord et avec raison, le lecteur pourra penser que Parlay et JAIN sont en compétition, étant donné les nombreuses similarités dans les buts qu ils se sont fixés. Mais s ils ont été en compétition à leurs débuts, cela n a pas duré, les deux parties s étant rapidement rendues comptes que la collaboration apporterait plus à chacun que la compétition. Les deux groupes maintiennent toutefois certaines dissimilitudes, notamment sur les points suivants : Parlay ne se limite pas à une utilisation de ses API par Java mais se veut indépendant du langage utilisé. Parlay propose des APIs de services uniquement: contrairement à JAIN, Parlay ne dispose pas d APIs pour communiquer directement avec les protocoles réseaux, car ce n est pas là son but. Un autre objectif majeur de Parlay est de fournir un environnement dans lequel des acteurs tiers (third parties) puissent écrire des applications s exécutant en dehors de l espace de confiance (trusted space) du fournisseur de services, via différents mécanismes de sécurités 36

37 intégrés à Parlay. Nous allons par la suite dans cette troisième partie nous intéresser plus particulièrement à la mise en commun des spécifications mises au point par le Parlay Group avec l architecture OSA (Open Services Architecture) pour services mobiles du 3GPP, alliance à laquelle l on se réfère communément par la combinaison des deux acronymes : OSA/Parlay. 6.2 Architecture OSA 3GPP Le 3GPP représente la co-opération de différents organismes de standardisation, dont l ETSI, pour promouvoir la production de spécifications techniques pour les systèmes mobiles de 3ème génération à venir (basés sur les techniques d accès CDMA et dont UMTS est le fer de lance). Le 3GPP Technical Specification Group Core Network Workgroup 5 est à l origine de la définition OSA (Open Service Architecture, devenue Open Service Access). OSA définit une architecture donnant la possibilité aux opérateurs, fournisseurs de services et d applications de tirer parti des fonctionnalités offertes par leur réseau à travers une interface ouverte et standardisée, qui est l interface OSA. Cette interface fait le lien entre les applications et les services qu est capable d offrir le réseau, et maintient l indépendance des applications par rapport à la technologie réseau sousjacente Dans le modèle architectural OSA, cinq types d entités clés sont à retenir. Il y a : Les applications proprement dites Le serveur d applications sur lequel résident les applications Le Gateway OSA Les Service Capability Servers (SCS) Les Service Capability Features (SCF) L architecture OSA est en réalité une architecture distribuée, dont le plus haut niveau est constitué par les applications clientes, qui se trouvent dans les serveurs d applications. Le Gateway fait, lui, office de serveur situé à la frontière du domaine du fournisseur d applications. Entre les serveurs d applications clientes et le Gateway sur lequel tournent les SCS il y a du réseau, et la méthode de communication la plus couramment utilisée entre ces deux entités distantes à travers ce réseau est le recours à un bus middleware CORBA, dont nous exprimerons brièvement les caractéristiques un peu plus bas. 37

38 Figure 27 Architecture OSA Les applications clientes Les applications clientes résident sur des serveurs d applications et accèdent aux SCSs à travers l interface OSA et les APIs Parlay du Gateway. Ces APIs servent de liant entre les applications et les SCSs. De cette manière, les applications sont rendues indépendantes de la technologie du réseau sous-jacent Le serveur d applications Il est configuré de manière à se connecter au Gateway par l intermédiaire d une connexion TCP/IP (n importe quel PC suffisamment puissant peut faire office de serveur d applications, d une simple machine Linux à un serveur avancé et spécialisé par un constructeur). Le serveur d applications peut avoir pour rôle également de cacher l utilisation de CORBA au programmeur, en faisant appel à des «Convenience Classes», décrites dans un langage de haut niveau tel que Java. 38

39 6.2.3 Les Services Capability Servers (SCS) Les SCSs implémentent les spécifications Parlay sur l interface OSA du Gateway, et se chargent d effectuer la translation de ces APIs vers les protocoles de télécommunications spécifiques présents au plus bas niveau, cachant de cette manière la complexité du réseau aux applications. Ils mettent aussi à disposition des applications clientes les fonctionnalités OSA appelées Service Capability Features (SCFs), ou plus simplement Services Les Service Capability Features (SCF) Une SCF constitue l abstraction d un service particulier offert par le réseau et accessible au travers des APIs Parlay. Les SCF sont spécifiées en tant qu interfaces avec leurs méthodes propres. Un seul et même SCS peut être vu par les applications en tant qu une ou plusieurs SCF Le Gateway Pour communiquer avec le monde extérieur et les différents éléments entrant en jeu, les applications vont communiquer d abord à travers une interface intermédiaire qui est le Gateway OSA. Le Gateway OSA consiste en plusieurs SCS, qui ne sont autres que des entité fonctionnelles qui fournissent l implémentation des interfaces OSA/Parlay nécessaires à la communication avec l application. C est donc l élément central de l architecture OSA, et c est à travers cet équipement qu un provider ou un carrier devient en mesure de proposer une manière standardisée pour ouvrir son réseau et ses fonctionnalités à des ASPs et développeurs tiers d applications. Un Gateway intelligent cache les détails du réseau sous-jacent et protège les développeurs d applications issus du monde IT des complexités des réseaux de télécommunications. Cela est possible car le Gateway offre en résumé les fonctions suivantes : Une palette de méthodes (APIs) qui permettent de fournir un accès sécurisé aux ressources du réseau à l entrée duquel il se trouve. La communication entre les éléments réseau du domaine dans lequel se trouve le Gateway et les applications clientes se trouvant sur le serveur d applications chez le Carrier/Provider se font généralement à travers CORBA. 39

40 Ces APIs sont définies selon les standards Parlay et sont généralement décrites dans le Gateway sous forme de fichier IDL pour faciliter l interaction des méthodes Parlay avec les composants CORBA. Les développeurs d applications clientes peuvent désormais formuler directement des requêtes au Gateway à travers ces APIs. Une collection de Service Capability Servers (SCS) qui comprennent les interfaces et fonctionnalités (SCF) pour interagir avec des éléments réseaux CORBA CORBA est l acronyme de Common Object Request Broker Architecture, et désigne une infrastructure permettant une communication répartie entre objets. CORBA a été standardisé par un consortium appelé OMG (Object Management Group) en 1989, et permet en soi de remplir les même fonctions d appels de méthodes éloignées (RPC : Remote Procedure Calls) que le font d autres mécanismes de communication distribuée et répartie tels que DCOM (Microsoft) ou RMI (Java). Le but de l OMG a été de faire de CORBA une technologie d objets distribués capable d être déployée dans tout environnement, indépendamment de la plateforme, du langage et du protocole utilisé. Il s agit donc d une architecture ouverte et garantissant une grande interopérabilité entre différents composants, permettant de répartir des objets entre les composants en communication, où l objet représente en l occurrence un regroupement de données et de traitements agissant sur ces mêmes données. Ainsi n importe quel programme basé sur CORBA peut s entendre avec n importe quel autre programme aussi basé sur CORBA, même si ce dernier se situe sur une différente machine provenant d un équipementier différent, tournant sur un autre système d exploitation et décrit par un autre langage de programmation sur un autre réseau. Un élément clé de CORBA est l ORB, qui représente le bus logiciel servant d intermédiaire entre objets clients et objets serveurs. Pour qu une communication CORBA puisse s établir entre deux entités distinctes, l une cliente et l autre serveur, un ORB doit être présent sur chacune des parties. De cette manière, la transmission des requêtes entre clients et serveurs, ainsi que les résultats de ces requêtes en retour, pourront être assurées, et ce, sans que les clients aient à connaître la localisation de leur serveur, ni que les serveurs sachent où se trouvent leurs clients. C est donc l ORB qui assure la transparence relativement à la répartition. D autre part, afin de s éviter le fardeau d être lié à un seul langage de haut niveau exclusivement, CORBA utilise son propre langage normalisé par l OMG et appelé IDL (Interface Definition Language). Un fichier IDL contient la description de la vue qu a un client d un objet éloigné, d une façon très semblable à celle 40