Auteurs: Laurent Schweizer Nicolas Anagnostopoulos

Projet CCTI
VoIP&Mobility
Auteurs:
Laurent Schweizer
Nicolas Anagnostopoulos
Prof : Stefano Ventura
Société
TCOM/EIVD
Mandataire du projet
TCOM/EIVD
Titre
Nom du fichier
Date
9 février 2005
Version
1
Statut
Classification
Document de travail
Auteurs
S Ventura,
Nombre de pages
51
Modifications
Distribution
Distribution
N
Stefano Ventura
Table des matières :
1
Introduction ....................................................................................................................... 5
2
Call Processing Language ................................................................................................ 6
3
4
5
2.1
Introduction .............................................................................................................. 6
2.2
Que peut faire CPL ? ............................................................................................... 6
2.3
Création des scriptes ................................................................................................ 6
2.4
Fonctionnement des scripts ..................................................................................... 7
2.5
Exécution des scripts................................................................................................ 8
2.6
Conclusion sur CPL ................................................................................................. 8
Common Gateway Interface, CGI .................................................................................... 9
3.1
Introduction .............................................................................................................. 9
3.2
Possibilité des sip-cgi................................................................................................ 9
3.3
Création des scripts.................................................................................................. 9
3.4
Comparaison cgi-sip et cgi-bin................................................................................ 9
3.5
Conclusion............................................................................................................... 10
SIP Servlets API .............................................................................................................. 11
4.1
Introduction ............................................................................................................ 11
4.2
Architecture ............................................................................................................ 11
4.3
Choix de la servlet lors de l’arrivée d’un message .............................................. 12
4.4
Que peuvent faire les servlets SIP ?...................................................................... 13
4.5
Fonctionnement des servlets.................................................................................. 13
4.6
Création de servlets SIP......................................................................................... 15
4.7
Conclusion............................................................................................................... 15
The JAIN APIs ................................................................................................................ 16
5.1
Introduction :.......................................................................................................... 16
5.2
But............................................................................................................................ 17
5.3
Architecture ............................................................................................................ 17
5.4
Les différentes APIs de JAIN................................................................................ 19
5.5
JAIN et SIP ............................................................................................................. 19
5.6
JAIN Call Control .................................................................................................. 20
5.6.1
Introduction ...................................................................................................... 20
5.6.2
Les différents modules ..................................................................................... 21
5.6.3
Les composants de base ................................................................................... 22
5.6.4
Interaction entre les applications et l’API ........................................................ 23
5.6.5
Evénements ...................................................................................................... 23
5.6.6
Java Core Package............................................................................................ 24
JcpProvider................................................................................................................... 24
Etat d’un provider......................................................................................................... 24
JcpCall.......................................................................................................................... 25
JcpConnection .............................................................................................................. 25
JcpAddress ................................................................................................................... 26
5.6.7
Java Call Control.............................................................................................. 26
JccProvider ................................................................................................................... 26
JccCall .......................................................................................................................... 27
JccConnection .............................................................................................................. 27
Evènements et évènements bloquent............................................................................ 29
JccAddress.................................................................................................................... 30
Event Filter................................................................................................................... 30
5.6.8
Relation entre JCC, JCP et JTAPI.................................................................... 31
6
5.7
JAIN Service Logic Execution Environment (JAIN SLEE)............................... 32
5.8
JAIN Service Creation Enviroment (JAIN SCE)................................................ 34
OSA et Parlay .................................................................................................................. 36
6.1
Introduction ............................................................................................................ 36
6.2
Architecture OSA 3GPP........................................................................................ 37
6.2.1
Les applications clientes................................................................................... 38
6.2.2
Le serveur d’applications ................................................................................. 38
6.2.3
Les Services Capability Servers (SCS) ............................................................ 39
6.2.4
Les Service Capability Features (SCF) ............................................................ 39
6.2.5
Le Gateway ...................................................................................................... 39
6.2.6
CORBA ............................................................................................................ 40
©
6.3
Le groupe Parlay ................................................................................................. 41
6.3.1
UML ................................................................................................................. 43
6.3.2
Structure des APIs Parlay................................................................................. 43
6.3.3
Le Framework Parlay et la sécurité.................................................................. 44
6.3.4
Les Services Parlay .......................................................................................... 46
6.3.5
La spécification des données............................................................................ 47
7
Conclusion ....................................................................................................................... 50
8
Bibliographie ................................................................................................................... 51
4
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
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
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
La figure n° 2 est le code de cette représentation graphique ( sans la partie Voicemail)
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
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
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
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
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
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
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
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
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
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
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
5.4 Les différentes APIs de JAIN
L’interfaçage des différentes couches d’abstraction est faite au moyen d’APIs
La 1er 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
Figure 12, les différentes API SIP
5.6 JAIN Call Control
5.6.1 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
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
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
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
Provider
Listener
Listener
Call
Call
Listener
Listener
Connection
Connection
Listener
Listener
Synchronous
method calls
JCC API
Java
Events
Connection
Connection
Provider
Provider
Network
or
Platform
Call
Call
Connection
Connection
Figure 15, interaction entre logiciel et API
5.6.5 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
Call
Event
Events
Listener
Provider
Event
Call
Listener
Connection
Event
Listeners
Provider
Listener
Connection
Listener
Figure 16, organisation des objets Events et Listners
23
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
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
•
•
•
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
INPROGRESS
ALERTING
CONNECTED
DISCONNECTED
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 email, 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.
5.6.7 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
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. 0800….), 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
•
•
•
•
•
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 (024 442 …..)
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
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
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
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)
Java Call
Control
(JCC)
JTAPI
Core
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
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
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
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 1er 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
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
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
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
Figure 27 Architecture OSA
6.2.1 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.
6.2.2 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
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.
6.2.4 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.
6.2.5 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
•
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.
6.2.6 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
qu’aurait un langage de programmation orienté objet tel que C++ ou Java. Cette vue de
l’objet, qui représente le minimum de ce que doit connaître un client pour requérir les services
de l’objet en question, porte le nom d’interface. L’interface représente donc la partie
syntaxique de la transaction entre l’objet serveur et le client qui l’invoque.
Finalement, pour parfaire sa simplicité et faciliter au maximum la tache du programmeur en
lui cachant autant que possible les différentes complexités de la communication sur le réseau,
CORBA exploite la fonction de l’ORB qui est d’assurer la transparence vis-à-vis des langages
d’implantation afin de permettre à un programme client de faire référence dans n’importe quel
langage donné, par exemple Java, à un serveur implanté éventuellement sur une autre
machine, éventuellement aussi dans un autre langage.
Cela s’appelle un « mapping » vers un langage choisi de programmation, et ce procédé est
réalisable en tirant parti du fait que le langage IDL de définition des interfaces objet est
totalement neutre vis-à-vis des langages de programmation, tout en en étant proche dans sa
syntaxe, et chacun des concepts qu’il véhicule peut dès lors trouver sa représentation dans
chacun des langages de programmation envisagés. Il suffit pour cela de se donner des règles
de correspondance à appliquer systématiquement.
L’OMG l’a d’ailleurs fait pour de nombreux langages orientés objets comme Java, C++ ou
SmallTalk, mais aussi pour des langages plus traditionnels comme Ada ou même Cobol, en
normalisant l’ensemble des règles de correspondance pour chacun des langages précités.
Actuellement, CORBA est utilisé dans la grande majorité des implémentations de Gateways
OSA en tant que protocole de communication entre APIs côté serveur et client.
6.3 Le groupe Parlay
©
Le groupe Parlay est un consortium à but non lucratif fondé en 1998 qui a été constitué à
l’origine (Parlay phase 1) par British Telecom, Microsoft, Nortel Networks, Siemens et
Ulticom. Fin 2000, le groupe comprenait plus de quarante membres, et il compte aujourd’hui
plus de 65 compagnies, issues tant des télécoms que des industries de la technologie de
l’information (IT). Parmi ces dernières on peut citer: Alcatel, Ericsson, Fujitsu, HP, IBM,
Lucent, NTT, Sun Microsystems, Telcordia Technologies, Telecom Italia, Orange
Communications ou encore KPN Carrier Services et bien d’autres [www.parlay.org].
C’est un forum ouvert qui s’est fixé comme objectif de définir des API d’applications et de les
promouvoir au sein d’organismes de standardisation comme l’ETSI, mais aussi auprès
d’autres forums tels que JAIN, le 3GPP, l’OMG, le MSF (Multiservice Switching Forum) ou
encore l’IN Forum.
Les APIs Parlay font donc partie de cette catégorie de nouvelles technologies dont le but est
finalement de donner la possibilité aux opérateurs, fournisseurs de services et ASPs d’utiliser
de la même façon toutes les fonctionnalités du réseau, en offrant une solution qui en
fournissant un haut niveau d’abstraction par rapport au matériel
41
permet de développer des services simplement, économiquement et rapidement,
indépendamment du matériel utilisé.
L’abstraction proposée par l’API Parlay offre un accès sûr aux facilités de services d’un
réseau quel qu’il soit, et permet en outre à d’autres intervenants d’un genre nouveau que l’on
surnomme « tiers » (3rd party), qu’ils soient développeurs, ASPs (Application Service
Providers) ou ISVs (Independant Software Vendors), à investir le marché des télécoms en
contribuant à l’émergence d’une nouvelle classe hybride de services Telecom/IT.
Des applications tierces peuvent ainsi être hébergées au sein du réseau privé d’un fournisseur
de services, ou devenir accessibles aux abonnés d’un fournisseur de services malgré leur
localisation externe au réseau de celui-ci, par l’intermédiaire d’un gateway assurant la sécurité
de la transaction
Figure 28Le Modèle VASP
Dépendant des nécessités requises comme le dimensionnement, la redondance géographique,
la capacité, la sécurité ou encore la tolérance aux pannes, l’ASP choisira un certain type de
serveur d’applications, et prendra la décision de l’outsourcer chez un opérateur
Telecom/fournisseur de services, ou sur un autre site distant.
Le Gateway, lui, est sous l’égide de l’Opérateur/ Service Provider, et toutes les interactions
Parlay passent par lui. Il est l’élément implémentant les Service Capability Features, qui
désignent les fonctionnalités que le réseau appelé a à offrir. On trouve le plus souvent le
Gateway sous forme d’élément standalone, mais certains constructeurs télécoms l’intègrent
directement au sein d’une plateforme IN, au sein du softswitch par exemple.
42
6.3.1 UML
Afin de garantir une accessibilité à une communauté de développeurs aussi large que
possible, les APIs ne ciblent pas une technique d’implémentation particulière.
Il est important de bien concevoir que Parlay n’est pas un langage, mais une définition
d’interfaces et de méthodes regroupées au sein d’APIs d’application dont le but est de
permettre un accès ouvert mais sécurisé à un ensemble de fonctionnalités (commande d’appel,
gestion de la mobilité, interaction usager, messagerie, …) aujourd’hui rendues par les
différents réseaux publics ou privés.
Pour exprimer ces définitions, Parlay utilise la notation UML (Unified Modeling Language),
qui est un formalisme objet standardisé par l’OMG (comme CORBA et IDL) et destiné à la
modélisation d’un système, logiciel ou non, à plusieurs niveaux d’abstraction afin de le
construire, le documenter et le maintenir. Ce type de description convient donc parfaitement
aux interfaces que Parlay s’efforce de modéliser, à travers une architecture distribuée OSA.
Le plus souvent, une description UML se représente sous forme de diagramme de classes,
donnant une vue statique de la structure d’un système, de la même manière que se fait la
représentation d’un modèle Entité-Associations lors de la conception d’une base de données.
UML peut être utilisé avec la plupart des langages de programmation (orientés objet ou non),
et la plupart des architectures techniques du commerce (CORBA …). Il faut noter toutefois
qu’UML est une notation de modélisation, et qu’une démarche méthodologique de
développement doit donc lui être adjointe pour en guider l’utilisation.
Il existe une grande variété d’outils UML aujourd’hui permettant, à partir d’un simple
diagramme de modélisation, de générer directement du code Java ou C++ correspondant, mais
aussi de la documentation et, plus intéressant, des interfaces à inclure dans une définition
IDL.
6.3.2 Structure des APIs Parlay
Parlay spécifie pour le domaine IT les capacités et fonctionnalités de téléphonie usuellement
disponibles dans un réseau Telecom traditionnel. En fonction du type de fonctionnalité dont il
s’agit, celles-ci sont réparties en différents groupes, que l’on appelle communément Service
Capability Features (SCF) ou plus simplement Services, et qui sont rendues disponibles à
travers des Service Capability Servers (SCS).
43
Figure 29 Structures Parlay
A chaque SCF correspond une API (classe d’interfaces) bien définie. Parlay en regroupe un
certain nombre, réparties en deux catégories: d’un côté les interfaces de Framework, de
l’autre les interfaces de Services.
Essentiellement, la séparation entre les deux interfaces peut être vue de la manière suivante :
•
Les interfaces du Framework fournissent les outils nécessaires pour assurer que les
interfaces de Services soient accessibles de manière fiable, constante, sûre et gérable.
Le framework possède son propre SCS.
•
Les interfaces de Services offrent aux applications l’accès à toute la panoplie des
fonctionnalités du réseau. Les Services possèdent leurs propres SCSs.
Figure 30 Framework & Service
6.3.3 L
e Framework Parlay et la sécurité
La classe d’interfaces du Framework se distingue des autres interfaces, et contrairement aux
interfaces de Services, il est absolument nécessaire de l’implémenter.
Le Framework a son propre SCS, et il contrôle l’accès aux différents services depuis le
Gateway, en fournissant un ensemble de fonctions indépendantes du réseau assurant des
mécanismes d’authentification, de découverte des services, de notification d’évènements, de
44
gestion d’intégrité, d’exploitation et de maintenance.
En effet, de pair avec le déploiement des APIs OSA/Parlay, il a tout de suite été primordial
pour les fournisseurs de services de pouvoir être certain que seuls des utilisateurs de confiance
(partenaires ou clients) puissent avoir accès à leur réseau. Il fallait donc que les solutions
implémentées par des acteurs/partenaires tiers (3rd Parties) puissent garantir la continuité de
la sécurité d’accès et de l’intégrité du réseau du fournisseur hébergeant les serveurs
d’applications.
Cela est donc devenu le rôle du Framework de gérer l’authentification des applications
souhaitant pénétrer plus en avant dans le réseau, l’ authentification se faisant au niveau du
Gateway qui constitue le seul point d’accès aux services se trouvant derrière lui. Ainsi, l’accès
à un service particulier n’est permis qu’aux applications ayant été explicitement autorisée à y
accéder, après avoir passé à travers les différents mécanismes d’authentification et
d’enregistrement qui sont implémentés par le Framework.
Il devient ainsi possible d’accéder de façon sécurisée aux ressources du réseau du fournisseur
de services. Pratiquement, les interfaces du Framework accomplissent les fonctions suivantes
:
•
L’authentification sécurisée (Authentication) : elle est réalisée par encryptage des
données et autres algorithmes de signature électronique, spécialement nécessaire lors
d’une négociation entre le Gateway et un serveur d’applications qui se trouverait en
dehors du domaine du fournisseur de services.
•
L’enregistrement (Registration) : permet aux fournisseurs tiers d’applications
d’enregistrer leurs applications auprès du Framework, en temps réel.
•
Le mécanisme de découverte (Discovery) : permet à un client de découvrir parmi la
panoplie de services disponibles, le service proposé par le fournisseur offrant les
fonctionnalités les plus proches de ce que désire exactement accomplir l’application
cliente.
•
La gestion de l’intégrité (Integrity Management) : le Framework offre également des
interfaces de gestion de l’intégrité du système, dont des interfaces de gestion de la
charge et des erreurs, mais aussi un mécanisme de « battements de cœur » (heartbeat
mechanism), qui consiste en un échange de signaux entre le Framework et une
application ou un SCS, pour s’assurer de la bonne santé de ce dernier.
•
La notification d’événements (Event Notification) : cela autorise une application de
demander une notification lorsqu’un service ou une classe de services particulière se
libère.
•
Inscription à un service particulier (Service Subscription): permet à une entreprise de
gérer les comptes qu’elle autorise à accéder à un service ou pas, et de créer et gérer
des profils utilisateurs.
45
6.3.4 Les Services Parlay
Les interfaces de services rendent visibles aux applications un ensemble de fonctions rendues
par les réseaux sous-jacents. Ces services comprennent :
•
Generic Call Control Service: définit la manière dont les applications peuvent passer
des appels à travers le réseau, comment elles peuvent démarrer une conférence vocale,
comment elles sont utilisées pour router des appels à partir du réseau, comment elles
peuvent initier des appels multi-médias et détecter de nouveaux évènements.
•
Common Data Definitions : définit les objets et types utilisés tout au long des
spécifications Parlay.
•
Mobility : définit la manière dont une application peut parvenir à localiser un terminal,
et la manière dont elle peut requérir à une notification lorsqu’un terminal mobile
change de position.
•
User Interaction : définit la manière dont une application peut obtenir des
informations sur l’utilisateur, faire passer des annonces vocales, enregistrer un appel,
notifier un événement par sms, reconnaître des impulsions DTMF, etc.
•
User Location : définit la manière dont une application peut obtenir des informations
sur la localisation d’un utilisateur en temps réel.
•
User Status : définit la manière dont une application peut obtenir des informations sur
l’état d’un utilisateur : occupé, injoignable, etc.
•
• Terminal Capabilities : détermine la manière dont les applications peuvent découvrir
les capacités qu’offre un terminal.
•
Data Session Control : détermine la manière dont les applications gèrent leurs sessions
de d’échange de données initiées à partir d’un terminal.
•
Generic Messaging : détermine la manière dont les applications interagissent avec des
systèmes de messagerie tels que voice mail, Fax ou email.
•
Connectivity Management : détermine la manière dont les applications gèrent la
qualité de service et la configuration de VPNs.
•
Presence and Availability Management : détermine la manière dont les applications
affichent la présence et la disponibilité d’un utilisateur à travers des messages types.
•
Account Management : détermine la manière dont les applications interrogent les
comptes et établissent une facture en fonction de l’historique.
46
•
Policy Management : détermine la manière dont les applications interagissent avec
d’autres réseaux possédant une politique particulière.
•
Charging : détermine la manière dont les applications requièrent un paiement auprès
de l’utilisateur, ou comment elles peuvent réserver un acompte de paiement dans le
cas de communications prépayées.
Au fil des versions toujours plus évoluées des APIs Parlay, d’autres interfaces publiques de
support administratif ont été greffées et mises à disposition de l’utilisateur directement, et
d’autres fonctions encore ont été rajoutées pour permettre aux fournisseurs d’applications 3rd
Party de participer plus simplement et plus activement.
Des définitions d’interfaces propres aux applications e-Commerce sont par exemple en cours
de standardisation.
L’implémentation de toutes ces fonctionnalités n’est pas obligatoire, il n’est nécessaire
d’implémenter que celles que le réseau est à même de fournir, en fonction du type de services
qu’il propose.
Par exemple, Orange Communications est un opérateur mobile exclusivement, mais présent
au niveau international. Les capabilities sur lesquelles compte Orange sont: Call Control,
User Interaction, Mobility, Terminal Capabilities, Data Session Control, Generic Messaging,
Connectivity Management et Account Management.
De nouvelles classes de services (SCF) peuvent aussi être ajoutées au fur et à mesure.
Il est important de bien voir une SCF ou classe de services telles que celles dont nous venons
de faire la liste, comme un ensemble d’interfaces avec leurs classes et méthodes propres à la
réalisation de ladite classe de services. Ces interfaces sont aussi le plus souvent définies en
JAVA, à travers un mapping adéquat (c.f. CORBA).
6.3.5 La spécification des données
Les spécifications Parlay se sont succédées relativement rapidement depuis la création du
groupe Parlay en 1998, poussées en grande partie par les nombreuses collaborations
entretenues par le Parlay Group avec le 3GPP puis JAIN Comunity.
La première version, Parlay 1.0, a été publiée en Décembre 1998. Puis rapidement des
révisions y ont été apportées, et succédant à Parlay 2.0 (2000), Parlay 3.0 (2001), Parlay 3.3
puis Parlay 4.0, la spécification actuelle en est à la version 4.1 (qui peut être téléchargée
depuis le Parlay Group à l’url : www.parlay.org/specs/index.asp).
La structure des types de données définies par Parlay respecte une convention de noms qui
est la suivante :
47
•
Les noms de types débutent par : Tp. Exemple : TpBoolean, TpAddress.
•
Les noms d’interfaces dont les méthodes sont invoquées par les applications clientes,
débutent par : Ip. Exemple : IpCall, IpAuthentication.
•
Les noms d’interfaces devant de toute manière être implémentées par les applications
clientes débutent par : IpApp. Exemple : IpAppAccess, IpAppAuthentication.
•
Les noms d’interfaces appartenant au framework, dont les méthodes sont invoquées à
l’intérieur même d’une implémentation de Parlay, débutent par : Ipfw. Exemple :
IpFwServiceRegistration.
•
Les noms des interfaces de services, dont les méthodes sont invoquées à l’intérieur
même d’une implémentation de Parlay, débutent par : IpSvc. Exemple :
IpSvcFactory.
Un exemple de modélisation en notation UML aurait l’allure suivante :
Figure 31 Modélisation UML
Modèle auquel pourrait correspondre la description IDL suivante :
(
appInterface :
eventCriteria :
assignmentID :
in
in
out
IpAppCallControlManagerRef,
TpCallEventCriteria,
TpAssignmentIDRef
)
:TpResult
où :
48
appInterface désignerait l’instance d’une classe implémentant IpAppCallControlManager,
eventCriteria identifierait les évènements pour lesquels l’application requiert une notification,
et
assignmentID représente l’identification unique de l’évènement notifié, assigné par l’interface
Call Control.
De plus toutes les méthodes définies par Parlay se doivent de retourner une variable de type
TpResult, indiquant si l’exécution de la méthode a été un succès, ou non.
49
7 Conclusion
A travers cette petite étude, l’on peut constater que les développeurs se sont doté d’outils
performants pour la création et la gestion de services de téléphonie de nouvelle génération.
On a aussi pu voir que ces outils ne s’adressent pas seulement à des programmateurs
chevronnés. Il existe des outils assez simples pour être utilisé à travers des interfaces
graphiques et donc destiné à un tout public. Cette notion est très importante car comme
Internet, le but de ces services est d’être accessible à un maximum de personnes.
Les providers ne sont pas en restent puisqu’ils disposent aussi d’outils qui leur sont destinés.
Comme nous l’avons vu, ceux-ci offre de haut niveau d’abstraction ainsi il est possible
d’acheter ou de réutiliser des services qui n’ont pas été créés pour une architecture de réseau
semblable au leurs.
Ces différents scriptes et APIs ne doivent pas êtres considérer comme des concurrents mais
comme dans langages destinés à des utilisations, des utilisateurs différents.
8 Bibliographie
http://java.sun.com/products/jain/
http://www.sipcenter.com/
http://www.dynamicsoft.com/resources/presentations.html
CPL : A Language for User Control of Internet Telephony Services,
Draft-ieft-iptel-cpl-04.txt de Lennox / Schulzrinne
Call Processing Language Framework and Requirement,
RFC 2824 de Lennox, Schulzerinne
Programming IP Telephony Services,
de J.Rosenberg, Bell Laboratories
Programming SIP Services
de A.Kristensen, Hewlett-Packard Laboratories
Servlet, CGI and CPL
de Dynamicsoft
SIP Servlets
de Dynamicsoft
JAIN SIP, What and Why ?
de Dynamicsoft
JAIN Integrated Network APIs for the Java Plateform,
juillet 2001, de Sun.com
The Session Initiation Protocol
de H. Schulzerinne
Providing Advanced Service,
chapitre 4, 5, 6,7 de Stéphane Nicoll
JAIN and Parlay,
de M.Nilson, sun.com
Opening Up Networks with JAIN Parlay
de S. Beddus, G. Bruce, et S.Davis. IEEE Communications Magazine, April 2000
The Jain APIs,
septembre 2001, de Sun.com
Java Call Control,
de Ravi Jain et Farooq Anjum, Telecordia.
51