Les opérateurs de réseaux RTC, quant a eux, ont préféré renforcer leur infrastructure de RI afin de maintenir leur marché de services de communication de la voix et offrir une nouvelle g
Interactions de services de téléphonie IP basée sur SIP
Exemples đ IS ơ ơ .aẠ
4.2.1 CO (Camp-On) et CFB (Call Forwarding on Busy) CO permet au terminal de l’appelant de générer périodiquement des invitations a une adresse occupée jusqu’a ce qu’elle accepte lappel ou bien un intervalle de temps déterminé est écoulé CFB permet au terminal de Vappelé de rediriger lappel quand il est occupé avec un autre appel Linteraction, bien connue dans le RI, est causée par le fait que CFB empéche le signal busy d’étre envoyé 4 Vappelant ce qui a pour conséquence de ne pas déclencher Camp-On Le traitement dans le RI est relativement plus facile car les deux services sont dans le méme nœud (SCP: Service Control Point) Dans la téléphonie TP, la résolution est plus difficile car lun de ces services ou bien tous les deux pourraient étre dans les terminaux, ce qui engendre une situation de type MUMC [LEN00a]
4.2.2 La méme interaction est également difficile a traiter dans le cas ou l’un des deux services se situe dans un réseau autre que celui qui loge |’ autre service (situation MUMC).
La méme interaction devient impossible a gérer si les deux utilisateurs communiquent en mode point-a-point, en ce sens que méme ayant prévu un traitement approprié dans le réseau, il ne pourra pas détecter |’interaction.
4.2.3 Le service 911 doit empécher l’appelant d’annuler l’appel une fois établi Mais comme le terminal est capable de contrôler l’appel, l'utilisateur peut le terminer quand il veut. [LEN00a]
4.2.4 OCS (Originating Call Screening) permet a l’appelant d’interdire des appels vers certaines adresses TCS (Terminating Call Screening) permet a l’appelé de refuser des appels provenant de certaines adresses Du moment que les utilisateurs peuvent facilement changer d’adresses, ils peuvent déjouer ces deux services [LEN00a]
4.2.5 Avec SIP, un utilisateur peut toujours se donner le nom qu’il veut Ainsi, il peut changer d’identité pour déjouer le service TCS de filtrage d’appels [LEN00a]
4.2.6 Dans une requéte SIP, le terminal peut spécifier le temps aprés lequel la requéte est annulée si elle n’a pas abouti (timeout) Une interaction pourrait surgir dans le cas ou un serveur est programmé a réagir (déclencher un service, par exemple) exactement après le méme intervalle de temps [LEN00a]
4.2.7 CW (Call Waiting, mise en attente) est un service déclenchable par le message busy. Certains téléphones IP sont équipés du service CW Si l’utilisateur, par le biais d’une GUI fournie par son vendeur de services, associe au message busy le service de renvoi a un serveur vocal, 11 programme alors une interaction des deux services par maladresse.
4.33 Traitement d’IS dans architecture SIP
Comme on la déja vu, le protocole SIP permet d’éviter certaines interactions mais complique d’autres Parmi les interactions qui n’ont plus lieu avec SIP ou sont plus faciles 4 gérer on cite les suivantes :
- Les interactions qui impliquent le service opérateur n’ont pas lieu car ce service n’existe plus Par exemple, l’interaction que cause un appel via l’opérateur qui évite OCS (car l opérateur ne dispose pas de la liste des adresses interdites par OCS).
- Les interactions dues aux destinations cycliques sont facilement détectables car les serveurs SIP vérifient constamment s’1l y a une boucle Exemple : un utilisateur A qui redirige vers un utilisateur B qui, ả son tour, redirige vers A.
- Les interactions dues aux appels incompatibles (appel téléphonique vers un télécopieur, par exemple) sont faciles a détecter car les terminaux SIP échangent des informations quant a leurs capacités.
A bien regarder les difficultés ramenées par Internet et SIP, citées dans la section 4.1, on remarque que, du point de vue de traitement des IS, ces complications sont de deux types Les quatre derniéres relévent du niveau architecture et protocoles Les deux premiéres émanent du modéle commercial (la programmabilité donne aux utilisateurs le profil de fournisseurs de services) Les solutions qu’on pourrait apporter au premier type de complications relévent de la prévention des IS Il s’agit de concevoir ou corriger la conception de |’architecture et/ou des protocoles pour éviter certaines interactions dont les causes se situent à ce niveau Le deuxiéme type d’interactions peut étre géré par la détection-résolution des IS.
Lennox et Schulzrinne [LENOOa] suggérent les mesures de prévention suivantes :
Pour éviter les problémes dtis a l’abondance des adresses (identité polymorphique), il faut insister sur |’authentification des requétes Tous les progrés qu’on pourrait réaliser dans ce domaine (infrastructure adéquate, plus d’autorité d’authentification) ne pourront pas étre exploités si les utilisateurs continuent à accepter des appels non authentifiés On espére que le développement de la TI va inclure l’apparition d’une autorité d’authentification qui aurait le pouvoir d’exercer sa fonction sur une grande échelle Si les requétes non authentifiées deviennent moins nombreuses que celles authentifiées, les usagers finiront par ne plus accepter les premlères.
- Restriction administrative au niveau du réseau
La solution du probléme des connexions point-a-point est de répandre les coupes-feux (firewalls) pour limiter ce type de connexion.
Remarquons que ces mesures ne remédient pas complétement a lensemble des quatre derniéres complications citées plus haut (section 4.1).
Une autre mesure 4 prendre pour remédier aux difficultés ramenées par SIP, suggérée par Lennox et Schulzrinne, consiste 4 expliciter les actions et leurs intentions Comme SIP est extensible, on peut ajouter des paramètres pour exprimer |’intention de l’utilisateur Ces paramétres pourront alors véhiculer les intentions exprimées dans les services pour les communiquer a des utilisateurs impliqués dans l’appel Exemple : si l’intention de l’appelant est de parler 4 une personne, le service de l’appelé qui habituellement redirige vers un serveur de voix, doit retourner un message "pas disponible” au lieu d’effectuer automatiquement cette opération Ceci complique la création de services en ce sens que le concepteur doit déterminer non seulement les actions que le service doit effectuer mais aussi les réactions en fonction des intentions des autres utilisateurs.
La présente these adopte une attitude qui vise a expliciter les actions et leurs intentions Les deux autres recommandations de Lennox et Schulzrinne (l’authentification universelle et la restriction administrative au niveau du réseau) seront plutôt le résultat de progrés acquis par [industrie de la TI et qui bénéficieraient de la recherche dans le domaine d Internet.
Le type de complications causées par architecture et le modéle commercial de SIP (les cing premiéres difficultés, section 4.1), a-t-on dit, est possible a traiter par la méthode détection- résolution des IS Remarquons que ce type de complications donne lieu plutôt a des interactions de type MUMC Ce type est réputé d'être difficile a traiter Les auteurs de [LENOOb] pensent méme qu’il est impossible a traiter Les travaux conduits dans le cadre de la présente thèse [CHE02, CHE03a-e, CHE04] proposent des solutions de traitement pour ce type d’interactions qui prennent conscience du fait que la complication est due au modẻle commercial (il en sera question dans le chapitre suivant).
Il y a relativement peu de travaux qui se sont penchés sur le traitement des IS dans architecture SIP Le travail présenté dans [RIZ00] repose sur |’idée selon laquelle lorsqu’un agent d’utilisateur SIP a intention d’effectuer une action susceptible d’affecter un autre utilisateur impliqué dans la méme session d’appel, il est préférable qu’il le consulte avant d’exécuter cette action Par exemple, si l’appelé posséde CFU (Call Forwarding Unconditional), ce service ne doit pas être exécuté immédiatement, l’agent de l’appelé doit d’abord demander a celui de l’appelant s’il accepte d’étre redirigé Si ce dernier refuse d’étre redirigé, il lui propose de laisser un message vocal, supposant que l’appelé dispose d’un tel service.
Un tel mécanisme de négociation est possible a implanter, selon les auteurs, par deux techniques La premiére consiste 4 augmenter SIP en lui ajoutant une méthode (PROPOSE) et quelques entétes Un message PROPOSE est toujours envoyé par un appelé car il suit un message INVITE L’appelant répond a un PROPOSE par un INVITE étendu pour inclure un nouvel entéte qui permet d’accepter un message PROPOSE Pour exprimer un refus, le message CANCEL est utilisé La deuxiéme maniére de faire consiste à prévoir un autre protocole en paralléle avec SIP chargé de véhiculer la communication pour la négociation.
Ce que FIML n’est pas 0 eee cette eee cuc cuc kh ekesexeesxexe— 106 2 Ce qu’est FEỨML ene rete nu kh nh tie ad ke sssssxxvve— 106 3 Structure de FIML, cee ch khe
Données prImItIves_ cuc ssssssee.s.ce— TỔ§
Les valeurs booléennes sont true et false. e string
Les valeurs chaines de caractéres, écrites entre côtes (”). ¢ integer
Les valeurs du type date peuvent représenter une date ou bien un intervalle entre deux dates.
Le format adopté est “yyyy.mm.dd”.
Exemple: 2003.06.01 Un intervalle date utilise la virgule pour séparer la date de début et de fin : 2003.06.01,2003.06.19. e time
Les valeurs de ce type prennent le format “hh.mm.ss” et peuvent également exprimer un intervalle de temps Une virgule est alors utilisée pour séparer le temps de début et de fin : 12.30.00,13.15.00. e address
Une valeur address peut étre n'importe quelle adresse du format URI Elle peut représenter une seule ou bien un ensemble d’adresses séparées par des virgules. e callstate
Ce type inclut deux valeurs constantes : HOLD et PARK La premiere signifie que l'appel est mis en attente et la derniére qu'il est mis dans l'état parked, i.e mis en attente mais lié 4 un serveur de voix (qui joue de la musique, des messages publicitaires, etc.) Ce type de données pourrait être étendu en ajoutant d'autres états d'appel suivant le besoin. e useraction
L'action d'utilisateur traduit ce que l'utilisateur pourrait composer comme touches sur son terminal Les constantes de ce type de données sont : FLASH, STAR et SQUARE Cet ensemble pourrait être étendu selon le besoin. e userinformation
Exprime de l'information dont l'objet est l'utilisateur Les valeurs variables de ce type sont : name, email, phone et url On pourrait ajouter d'autres variables selon le besoin. ® userstatus
Contient deux constantes : LOGGED et UNLOGGED Cet ensemble pourrait étre étendu au besoin. e callpriority
FIML adopte les mémes valeurs constantes pour ce type que ceux de SIP : EMERGENCY,URGENT, NORMAL et NONURGENT [ROS02].
ClaSSES iiiiiaiiiiaiaaiaẳđiẳiọaậả
e Call classe appel e Address classe adresse
Les membres de classe sont des variables, des prédicats et des fonctions Ils sont décrits ci- après.
Variables 2.0.0 cee ee ne en
- any : variable primitive générique qui appartient a chaque type primitif de FIML et qui peut prendre n'importe quelle valeur constante du type correspondant Par exemple, pour spécifier une action a exécuter sur tous les appels entrants, peu importe l'adresse de l'appelant, on doit affecter la valeur any a la variable address de l'appelant.
- * - variable primitive générique dont la valeur est déterminée au cours d'appel ou bien au moment de personnaliser le service par l'utilisateur Par exemple, le service Call Deflection consiste a4 rediriger l'appel entrant vers une autre adresse Il peut être implanté de maniére a permettre a l'utilisateur de choisir l'adresse de redirection en utilisant un bouton parmi un ensemble de boutons Afin d’exprimer l'adresse de redirection, la variable * doit être utilisée car cette information n’est fournie qu'au cours de l'appel. e Variables d'objets
- thisCall, call, calll, call2, : Call; la premiére variable est réservée pour désigner l'appel en cours.
- caller, callee, a, b, c, : Address; les deux premiéres variables sont réservées pour désigner respectivement l'appelant et l'appele. se Variables membres de la classe Call
- Call subject : string ; décrit le sujet de l'appel Exemple: “Aller a la péche”.
- Call.timeout : integer ; détermine le nombre de sonneries aprés lesquelles timeout est conclu Cet événement a pour conséquence de mettre a true le prédicat callee.noReply (voir plus bas). e Variables membres de la classe Address
- Address.callPriority : callpriority ; indique la priorité de l’appel déterminée par lappelant Comme spécifié par SIP, NORMAL est la valeur par défaut.
- Address.language : string; donne la liste des langages supportés par le terminal. Exemple: “english, french”.
- Address.organization: string ; le nom d’organisation de |’utilisateur Exemple: “Poétes du Québec”.
- Address.address : address ; l’adresse téléphonique exprimée suivant les conventions adoptées par le protocole Par exemple, dans lenvironnement SIP, ce membre contiendra Vadresse SIP de l'utilisateur Par conséquent, l’objet Address désigne I’utilisateur alors que le membre address identifie son adresse téléphonique.
- Address.emailAddress : address ; l’adresse de courriel de l’utilisateur.
- Address.phoneNumber : address ; le numéro de téléphone PSTN de !’utilisateur.
- Address.web Address : address ; IˆURL de lutilisateur.
- Address.name: string ; le nom de |’utilisateur.
Les prédicats FIML sont des membres de classes On les présentera ici suivant leurs catégories sémantiques. e Etat d’appel
- Call.established(Address.address, Address.address) : boolean ; un appel a été établi avec succés entre les deux adresses Notons que Call established(a, b) = Call.established(b, a).
- Call sssEvent(callstate) : boolean ; quand le prédicat sssEvent (sss: service specific situation) est égal a la valeur true, l’appel est soit en attente ou parked, dépendamment du paramèẻtre spécifié. e Information de signalisation
- Address.busy : boolean ; le signal “occupé” envoyé.
- Address.noReply : boolean ; l’appelé ne répond pas.
- Address.ok : boolean ; l’appelé a accepté l’appel.
- Address.failure : boolean ; ’appel n’a pas été accepté pour une raison autre que celles qui mettent a true calee.busy et callee.noReply Par exemple, dans SIP, ce prédicat devient true si la requéte d’appel est rejetée a cause d’un mauvais format du message SIP, d’une erreur interne du serveur ou parce que l’appelé n’ existe pas. e Information historique
- Address.notToldSince(Address.address, integer) : boolean ; l’utilisateur n’a pas eu de conversation avec l’adresse spécifiée depuis le nombre spécifié de jours Exemple :caller.notToldSince(salim@usherbrooke.ca, 8) exprime le fait qu’appelant n’a pas eu de conversation avec Salim depuis 8 jours.
Fonctions ơ— ĐH IT]
Les fonctions FIML sont des membres de classes On les présentera ici sous leurs catégories sémantiques respectives. e Actions de l'utilisateur
- Address.onHook() ; l’action de terminer l’appel (raccrocher).
- Address.ssaAction(useraction) ; ssaAction (ssa: service specific action) signifie que Vutilisateur appuie sur le bouton spécifié en paramẻtre Exemple : caller.ssaAction(ST AR). e Services élémentaires non téléphoniques
- Address.email(Address.emailAddress, address) ; envoyer un courriel Le premier argument désigne l’adresse de destination et le deuxiéme, le fichier qui contient le message a envoyer Exemple : caller.email(callee.emailAddress, c:/myemailmessages/lunch.dat).
- Address.webPage(Address.webAddress, address) ; envoyer une page Web dont ladresse est le deuxieme paramétre vers l’adresse URL qui est le premier paramétre.Exemple: callee.webPage(caller.webAddress, c:/pages/index.html).
- Address.message(string) ; le paramétre de cette fonction donne le message a envoyer avec le prochain message SIP I y sera inséré pour être lu par le récepteur Ceci est possible avec SIP mais pourrait ne pas |’étre avec d’autres protocoles Exemple: callee.message(“Sorry, Iam busy, call you later’). e Services élémentaires téléphoniques
- Address voiceMail(Address.address, address) ; jouer un message vocal a |’utilisateur dont l’adresse est le premier paramètre Le message a jouer est contenu dans le fichier qui constitue le deuxiéme parametre Exemple : callee.voiceMail(ayoub@happyhome.com, sunnymessage wav).
- Address.tryCall(Address.address, integer, integer) ; essayer un appel vers l’adresse spécifiée, le nombre spécifié de fois, séparées par le nombre spécifié de secondes donné comme troisiéme paramẻtre Cesser d’essayer l’appel aussitôt qu’il est accepté ou que le nombre de fois spécifié est atteint Exemple : caller.tryCall(ayoub@happyhome.com, 4, 120) pour essayer 4 fois, chacune aprés 2 minutes.
- Address.nsiAction(Address.address, userinformation); nsiAction (non signalling information) signifie que lon demande la foumiture d’une information spécifiée par le deuxieme paramẻtre et qui concerne l”utilisateur dont l’adresse est le premier paramétre Si plus d’une information sont demandées, elles sont séparées par des virgules Exemple, Ứappelé demande le nom de l’appelant : callee.nsiAction(caller.address, NAME). se Traitement d’appel
- Address.ssiEvent(string) ; ssiEvent (ssi: service specific information) est vrai si Pévénement spécifié en parametre et qui est lancé si le service n’est pas exécuté, est remplacé par un autre événement qui est lancé par le service Exemple, dépendamment de son implantation, le service de mise en attente (Call Waiting) pourrait lancer une indication de mise en attente quand l’appelé est au téléphone Cet événement remplace alors le signal busy. Pour exprimer cette logique, on écrit : callee.ssiEvent(“callee busy”).
- Address.ring(address) ; le paramétre est l’adresse du fichier son qui doit étre joué sous une condition a donner, comme la venue de nouveaux appels Exemple: callee.ring(birds wav).
- Address.cancel(); Vaction d’annuler l’appel L7’utilisateur annule l’appel en raccrochant le téléphone.
- Address.forbidCallQ ; interdit l’appel sous des conditions données Cette fonction doit être utilisée dans la partie action d’une régle dont la partie condition détermine les conditions sous lesquelles l’appel est interdit Exemple, pour interdire les appels recus de Salim : caller.address = salim@usherbrooke.ca -> callee.forbidCallQ ; l’opérateur “->” sera introduit plus loin.
- Address.forbidAction() ; pour interdire certaines actions, on utilise une régle dont la partie condition contient lesdites actions et la partie action contient cette fonction Exemple, pour interdire de divulguer le nom de lappelé a l’appelant : caller.nsiAction(callee.address, NAME) -> caller forbidAction(). e Données historique
- Address.isTrying(): integer ; l’utilisateur a essayé consécutivement un appel le nombre de fois retourné par cette fonction.
- Address.told(Address.address): date; la derniére fois que lutilisateur a eu une conversation avec |’utilisateur dont l’adresse est en paramẻtre a eu lieu a la date retournée par cette fonction. e Données de présence
- Address.status(Address.address): userstatus ; retourne |’état de type userstatus dePutilisateur dont l’adresse est en paramètre.
Opérateurs ` am a a C
- -> : sert a lier les deux parties d’une régle dont le format est le suivant :
FIML autorise la présence de prédicats et de fonctions dans les deux parties d’une régle Un prédicat dans la partie condition doit étre interprété comme ayant la valeur true Une fonction présente dans l°une ou I’autre des deux parties d’une régle doit étre lue “est exécutée”.
- : opérateur de résolution utilisé pour lier un objet avec |’un de ses membres.
- & : séparateur utilisé dans la partie action d’une régle.
- >> : opérateur logique temporel x >> y veut dire que x a lieu ensuite y a lieu.
- >|: a lire : “contient” x >| y : x contient y Cet opérateur est utilisé avec les types de données string et address.
- 17.00 &&
(caller.organization >| “Microsoft” || caller.address >| Microsoft) -> callee.email(caller.emailAddress, callLater.dat)
Owner callee.address := ayoub@happyhome.ca
Wait (caller.address >| Microsoft || caller.address >| poete || caller.address >| salim) & & time < 20.00 && caller.callPriority > NORMAL -> callee.address := 8198218978
(caller.address >| Microsoft || caller.address >| poete || caller.address >| salim) && time > 20.00
-> callee.voiceMail(caller.address, callLater wav)
Owner caller.address := ayoub@happyhome.ca
Dial callee.address >| salim -> forbidCaHQ
Wait callee := any || thisCall.sssEvent(HOLD) || callee.nsiAction(caller.address, any) -> forbidAction() RespReceived
Figure V.1 Exemples de services écrits en FIML
La procédure de détection opére sur deux modéles FIML ou plus D’abord, elle fusionne les modèles pour dégager un modẻle global La fusion se fait en recopiant, sous chaque point de traitement, son contenu issu de tous les modéles considérés L’algorithme de détection se base sur la syntaxe FIML II est capable de reconnaitre les types d’interactions suivants, décrits dans le chapitre IV L’interaction 7 n’est pas vraiment une interaction mais plutôt une action de résolution On a besoin de Vinclure dans la liste des interactions pour le besoin du développement.
2.a Une action interdit une autre
2.b Deux actions causant une confusion
2.c Impossible d’exécuter les deux actions ensemble
2.d La tentative d’exécuter deux actions ensemble cause une ambiguité de systeme
7 Réaction a une interdiction en temps réel
Détection "nh
La détection d’IS qui utilise les modéles FIML se base sur la syntaxe de ce dernier Autrement dit, une interaction étant une configuration particuliére d’actions et de conditions dans lesquelles évoluent ces actions, elle se traduit, dans FIML, par une configuration particuliére d’ éléments syntaxiques La connaissance de ces configurations qui causent des interactions est une connaissance préalable qui, on a dit déja, est supposée étre acquise par des moyens autres que FIML, par des tests formels ou par expérience, par exemple Les exemples ci-aprés montrent comment la procédure de détection associée a FIML opére a travers la détection de configurations syntaxiques particuliéres.
TABLEAU V.2 EXEMPLES DE DETECTION D’IS
#1 |callee.busy -> callee busy -> callee.ssiEvent(callee.busy) := true & caller.email{callee.emailAddress, thisCall.sssEvent(HOLD) := true c:\myMessages\message | dat)
#2.a | caller.address = any -> callee.address := any -> callee.address := secretary@company.ca caller.forbidActionQ)
#2.b | caller.address >| salim -> callee.forbidCallQ callee.busy >> !callee busy -> callee.tryCall(caller.address, 1,0)
#2.¢ |callee.busy -> callee.address := callee.busy -> thisCall.sssEvent(HOLD) secretary (@company.ca
#2.d | Owner callee.address := salim@usherb.ca
#7 _ | callee.address := salim@usherb.ca
=> callee.address := secretary@usherb.ca
#3 caller.address >| “salim”TM -> ring(birds.wav) thisCall sssEvent(HOLD) -> ring(birds.wav)
#4 ~— | thisCall timeout := 6 thisCall timeout := 4 callee noReply -> callee.noReply-> callee.address := 8198228978 caller.email(callee.emailAddress, c:/myMessages/message) & thisCall.cancel()
#5 _ |caller.address = any && time > 21.00 -> callee.forbidCallQ
#6 _ |callee.address = any -> callee.address >| salim -> caller.email(callee.emailA ddress, caller.forbidCall message25.txt)
- Interaction #1 : Violation d’hypothése Action 1 appartient a l’appelé et Action 2 a lappelant Action 1 remplace le signal busy par un autre Action 2 envoie un courriel si
Vappelé est occupé Comme busy n’est pas émis bien que l’appelé soit occupé, Ì'hypothẻse de
- Interaction #2.a : une action interdit une autre Action 1, qui appartient a l’appelé, redirige les appels entrants vers l’adresse spécifiée Par Action 2, l’appelant interdit que ses appels soient redirigés vers une autre adresse Ces deux actions sont contradictoires.
- Interaction #2.b : deux actions causant une confusion pour lutilisateur Action 1 appartient a l’appelé et interdit les appels entrants de l’adresse spécifiée Action 2 appartient a l’appelé aussi Elle doit être lue : si la aligne de l’appelé est occupée ensuite libre, essayer un appel vers l’appelant une fois seulement L’ interaction consiste dans le fait que l'utilisateur qui a appelé lorsque l’appelé était occupé pourrait être celui interdit par Action 1 L’appelant recevra un message indiquant que |’appel est impossible a établir ensuite un appel de la part de Pappelé Pour l’appelé, son intention de bloquer les appels entrants n’est pas respectée.
- Interaction #2.c : impossible d’exécuter les deux actions ensemble ou bien la tentative de les exécuter ensemble cause une ambiguité de systéme Action 1 et Action 2 appartiennent a appelé Action 1 redirige les appels recus si la ligne est occupée Sous la méme condition, Action 2 met l’appel en attente Ce sont là deux actions impossibles d’exécuter ensemble.
- Interaction #2.d : destination cyclique Action] redirige |’appel vers la secrétaire, sous certaines conditions La secrétaire, détentrice de Action 2, redirige lappel au détenteur de Action | (Salim) Ces actions créent une destination cyclique.
- Interaction #3 : contenu d’événement ambigu Par Action 1, l’appelant associe une sonnerie particuliére a l’appelant Salim La méme sonnerie servira aussi comme indication que lappel a été mis en attente Il pourrait trouver confuse cette sonnerie, quand il est au téléphone, ne sachant pas si c’est un appel regu de Salim ou bien un appel mis en attente.
- Interaction #4 : Minutage Action | appartient à appelé et Action 2 à l’appelant Ces utilisateurs ont spécifié deux valeurs différentes de timeout L’interaction a lieu car la préférence de l’appelant conclut trop tôt événement no answer et envoie alors un email 4Pappelé L’appelé a demandé une redirection d’appel vers son téléphone a la maison mais trop tard, aprés 6 sonneries L‘appelant pourrait préférer parler a lappelé chez lui au lieu de lui envoyer un email.
- Interaction #5 : condition d’action trop généralisée Par Action1, |’appelé interdit tous les appels entrants aprés 21.00 Cette condition peut s’avérer trop généralisée dans le cas ou
V utilisateur a simplement oublié de faire exception pour les appels urgents.
- Interaction #6 : formulation de préférence incompléte Action 1 et Action 2 appartiennent à l’appelant Action 1 envoie un courriel aux utilisateurs appelés quels qu 1Ìs soient Action 2 bloque les appels sortants vers l’adresse spécifiée L’interaction pourrait avoir lieu si l'utilisateur a simplement oublié de bloquer les courriels vers la destination d’appel interdite.
- Interaction #7 : Action 2 consiste a rediriger l’appel Cette action pouvant étre exclue en temps réel, par exemple, par ce que l’appelant l’a interdite, une réaction adéquate a une telle situation doit étre prévue afin d’éviter une interaction.
L’expérimentation conduite a l’occasion de la présente thése, utilisant FIML et sa procédure de détection, a adopté une solution đ IS qui procéde par prévention et restriction La prévention peut étre appliquée au moment d’implanter le service SIP, qui est a la base de Parchitecture adoptée par la présente these, fournit un langage de signalisation riche qui permet d’éviter certaines IS L’implantation de services doit donc exploiter cette caractéristique Par exemple, interaction #1 peut étre évitée car SIP permet de générer le signal busy ainsi que celui spécifique du service Ainsi, l’implantation du service peut éviter a ce dernier d’inhiber le signal busy La prévention est également appliquée lorsque les utilisateurs finaux concorvent leurs propres services Comme ils ne sont pas supposés avoir suffisamment de connaissances techniques qui leur permettraient d’éviter des IS, la présente thẻse propose que l”interface a partir de laquelle les utilisateurs congoivent des services soit en mesure de les empécher de "programmer" des IS Ce type de prévention a été implanté ; les résultats seront décrits dans le chapitre VII.
La restriction a été implantée en adoptant les politiques suivantes :
- Régle 1 : faire le maximum de restrictions avant I’ exécution des services.
- Régle 2 : s'il y a une interaction entre une action préférée et une action interdite,exclure l’action préférée, ce qui revient a exécuter I’ interdiction.
- Régle 3 : s’il y a une interaction qui provient de l’exécution de deux actions ensemble, retenir celle qui devrait conduire a |’établissement de l’appel avec succés.
- Régle 4 : pour les interactions #3, #5 et #6 interroger l’utilisateur.
- Régle 5 : s’il y a un conflit de minutage, exécuter les deux actions en interaction en méme temps L’ implantation de cette règle pourrait choisir de retenir léchéance (timeout) la plus grande, la plus petite ou bien la moyenne Cela revient a retenir un fimeout de 6, 4 ou bien 5, respectivement, si l’on consideére l’exemple de |’ interaction #4 du tableau V.2.
- Régle 6 : s'il y a une action qui pourrait être exclue en temps réel interroger Putilisateur quelle action veut-il qu’on exécute dans ce cas Cette maniére de procéder constitue une nouvelle méthode de résolution que la présente thése introduit.
La régle 2 s’applique aux interactions #2.a et #2.b Notons que dans lexemple d’ interaction
#2.b (tableau V.2), la restriction est appliquée si caller.address dans Action 2 contient le nom Salim, autrement, il n’y a pas d’ interaction.
La régle 3 s’applique a |’interaction #2.c Action 1 est favorisée.
La régle 4 s’applique aux interactions #3, #5 et #6 La procédure de détection-résolution interroge l'utilisateur Ce demier pourrait alors choisir deux sonneries différentes (exemple d’interaction #3), de faire une exception pour les appels urgents (exemple d’interaction #5) et de bloquer les courriels (exemple d’interaction #6) Les interactions #5 et #6 et la régle 4 représentent une nouvelle méthode de traitement des IS introduite par [CHE03c].
La régle 5 s’applique a l’interaction #4 Ces derniẻres représentent une nouvelle méthode de traitement des IS introduite par [CHE03c].
La régle 6 s’applique a l’interaction #7 L’utilisateur est interrogé hors ligne quoi faire si son appelant a spécifié une préférence qui interdit d’étre redirigé L’implantation de cette régle a choisi de présenter a l'utilisateur une liste de réactions possibles incluant de rappeler Pappelant plus tard ou bien lui envoyer un courriel.
L’application de la régle 1 se traduit par la détection et la résolution hors ligne des IS dans chaque noeud du réseau qui abrite des services C’est la responsabilité des UFIMA correspondants Naturellement, il s’agit d’IS de type SUSC (voir le chapitre IV, section 2.4).
Exemple bee ee ee eet ete be ttt reer tttt a 150
Ce service d’arrivée filtre les appels recus L’adresse ou les adresses d’appelant a interdire sont a déterminer par l’utilisateur C’est pourquoi, dans le modéle FIML suivant, on utilise la valeur générique "*".
OffHook caller.address = * -> callee.forbidcall()
VMBL (Voice Mail on Busy Line)
Ce service redirige tous les appels recus vers un serveur de voix lorsque l°appelé est occupé.
Le fichier son qui correspond au message vocal a jouer est a déterminer par l’utilisateur. Owner callee.address := B
Wait callee.busy -> callee.voiceMail(caller.address, *)
Owner callee.address := B; {TCS } callee.address := B; {VMBL}
OffHook caller.address = * -> callee.forbidCall(); {TCS}
Wait callee.busy -> callee.voiceMail(caller.address, *); {VMBL} RespReceived
-> callee.voiceMail (caller.address, *) {VMBL}
Restriction: caller.address = * callee.busy
-> restrict callee.voiceMail (caller.address, *)
Comme on le voit dans ce rapport, le type d’interaction est donné (type 2), ensuite les deux actions qui causent |’interaction Enfin, un traitement de I’interaction est recommandé II s’agit d’une restriction sous les conditions qui déclenchent ensemble les deux actions en conflit et qui consiste a ne pas rediriger l’appel vers le serveur de voix Ceci a pour conséquence de bloquer l’appel comme prévu par TCS.
Notons que l’opérateur FIML && n’est pas utilisé comme i! devrait |’étre dans la condition de la régle de restriction inférée car on a copié ici le résultat de la procédure de détection- résolution hors-ligne qui, de par l’implantation qu’on en a faite, elle omet d’écrire cet opérateur et met les éléments de la condition sur des lignes séparées.
La détection hors-ligne a été faite sur un ensemble de services dont une partie seulement a été ensuite implantée Le sous-ensemble de services implanté a été choisi selon l’objectif de couvrir tous les types d’interactions : les différentes causes, services de départ et d’arrivée,services se trouvant dans I’agent d’utilisateur et dans le serveur mandate.
Services testés " "<<
- Orig, appel de base de départ.
- Term, appel de base d’arrivée.
- AR, Automatic Recall : Vappelé est occupé, on rappelle automatiquement |’appelant dés que l’appelé est libre.
- CD, Call Deflection : Vappelé, sans prendre l’appel regu, et en tapant une combinaison de touches donnée, le redirige pour sonner a une autre adresse.
- CFBL, Call Forwarding on Busy Line.
- CENR, Call Forwarding on No Reply.
- CFNRR, Call Forwarding on No Reply after x Rings : le nombre de sonneries est déterminé,
- CP, Call Priority: EMERGENCY, URGENT, NORMAL, NONURGENT.
- DR, Distinctive Ringing : on assigne une sonnerie spéciale aux appels venant d’une adresse déterminée.
- ENRR, Email on No Reply after x Rings : Vappelant envoie un courriel a l’appelé si celui-ci ne répond pas aprés x sonneries (nombre a détermmer par |’appelant).
- EBL, Email on Busy Line; Yappelant envoie un courriel a l’appelé si la ligne de celut- ci est occupée.
- F-CF, Forbid Call Forwarding : lV usager interdit la redirection de ses appels sortants.
- F-VM, Forbid Voice Mail: lusager interdit la redirection vers un serveur de voix de ses appels sortants.
- TCF, Time Call Forwarding : rediriger les appels recus entre 10.00 et 12.00, par exemple.
- VM, Voice Mail : on demande a tous les appelants de laisser un message vocal.
- VMBL, Voice Mail on Busy Line : on demande à tous les appelants de laisser un message vocal lorsque la ligne est occupée.
- CdND, Called Name Delivery : on fournit le nom de l’appelé a l’appelant.
- CdNR, Called Name delivery Restriction : \appelé interdit que son nom soit fourni a lappelant.
- CgND, Calling Name Delivery : on donne le nom de l’appelant a l’appelé.
- CgNR, Calling Name delivery Restriction : Vappelant interdit que son nom soit donné à appelé.
- CTO, Call TimeOut (de départ) : ’appelant détermine le nombre de sonneries aprés lesquelles il conclut un timeout.
- CTO2, Call TimeOut (d’arrivée) : Vappelé détermine le nombre de sonneries aprés lesquelles 1l conclut un timeout.
- MDN, Multiple Directory Number: Vappelé a un ensemble d’adresses qui sont essayées lune aprẻs l’autre Jusqu’a ce qu’il réponde.
2.3 Résultats de détection-résolution hors-ligne (interactions réelles et potentielles)
Avec les n = 27 services utilisés, la procédure génère n(n+1)/2 = 378 paires de modéles FIML a tester 36 interactions ont été détectées La liste suivante est un extrait du rapport de détection On y trouve l’interaction, son type ainsi que la restriction a exécuter pour la résoudre La décision d’exclure lun ou lautre des deux services en interaction est dirigée par les régles formant la politique de restriction introduites au chapitre V, section 5.2 La taxonomie des interactions utilisée est celle du méme chapitre, section 5 Notons que, selon cette taxonomie, l’interaction de type #2 contient quatre sous-types (#2.a - #2.d) La procédure ne détecte que le type #2 sans préciser de quel sous-type il s’agit Annexe 2 présente le rapport de détection complet.
Interaction: CW annule l’émission de l’événement busy et le remplace par une indication sonore que l’appel est mis en attente Par conséquent, EBL, qui est déclenchable par lévénement busy n’est pas exécuté Il y a là une violation d’hypothése.
Résolution : l’interface utilisateur de l’appelant doit l’avertir et le conseiller d’ajouter un autre événement pour déclencher EBL : la mise en attente.
Interaction : rediriger lappel (CFBL) et rappeler ensuite l’appelant (AR) sont des actions incompatibles.
Interaction : bloquer l’appel entrant (TCS) ensuite rappeler l’appelant (AR) sont des actions contradictoires.
Interaction : mettre en attente un appelant (CW) ensuite le rappeler (AR) sont des actions incompatibles car retrouver l”appel c’est déja dans la logique de CW et AR, dans ce cas, ne ferait qu’initier un appel inutile.
Interaction : |’appelant interdit de rediriger l’appel (F-CF) alors que l’appelé a l’intention de le rediriger quand sa ligne est occupée (CFBL).
Interaction : rediriger l’appel recu pour une adresse A pour le prendre d’une autre adresse B (CD) alors que B est occupée et posséde une redirection vers A (CFBL) va créer une boucle. Type d’interaction : #2.
Remarque : dans un environnement SIP, cette interaction est résolue par le serveur mandaté de SIP qui annule l’appel dès qu’il la détecte.
Lappelant et l’appelé pourraient ne pas avoir spécifié un nombre égal de sonneries aprés lequel l’événement timeout est conclu Cela pourrait engendrer des situations d’ interaction. Type d’interaction : #4.
Résolution : la résolution de cette interaction doit se faire en unifiant le nombre de sonneries pour l’appelant et ’appelé Cela est possible 4 faire lorsque les actions ou services déclenchés par V’événement timeout se situent dans le serveur mandaté qui, dans ce cas, considérera la moyenne des deux valeurs, par exemple Si les actions ou services sont dans les agents d’utilisateurs, deux options d’implantation se présentent On pourrait conclure timeout après avoir regu un message SIP approprié du serveur mandaté Dans ce cas, c’est le serveur mandaté qui unifiera le nombre de sonneries pour les deux usagers Dans la deuxiéme option, c’est lagent utilisateur qui conclut lui-méme fimeout en se servant d’une minuterie locale. Dans ce cas, |’interaction n’est pas possible a résoudre La procédure de détection de FIML ne fait que détecter cette interaction sans proposer de résolution.
Interaction : l’appelant interdit de rediriger l’appel (F-CF) Si la ligne de l’appelé, occupée, veut rediriger ẽappel, ce dernier est annulộ Dans ce cas, l’appelant pourrait avoir omis de demander de ne pas envoyer de courriel (EBL) si l’appelé tente de rediriger |’appel.
Résolution : l’interface utilisateur de l’appelant doit l’avertir Il pourrait demander de bloquer les courriels vers les utilisateurs qui tentent de rediriger son appel.
3 Création de services et de préférences
Afin de valider la solution de détection-résolution en ligne, certains services et préférences ont été implantés ou simulés. e Services de départ dans l’agent d’utilisateur
- Email : simulé, une fenétre s'affiche indiquant qu'un courriel a été envoyé à telle adresse avec tel contenu.
Services d’arrivée dans l’agent d’utilisateur
- AR : simulé, une fenétre s'affiche indiquant que le service a été déclenché.
- Email : simulé, une fenêtre s'affiche indiquant qu'un courriel a été envoyé 4 telle adresse avec tel contenu. e Services de départ dans le serveur mandaté
- CdND : implanté, le nom de l’appelé est affiché dans une fenétre.
Services d’arrivée dans le serveur mandaté
- VM : simulé, une fenétre s'affiche indiquant que le service a été déclenchẻ.
- CF : simulé, une fenétre s'affiche indiquant que le service a été déclenché.
CW : simulé, une fenêtre s'affiche indiquant que le service a été déclenché.
- CgND : implanté, le nom de l’appelant est affiché dans une fenétre.
Dans les sections suivantes, on détaillera l’algorithme général de fonctionnement de la solution introduit au chapitre VI, section 3.
4 Traitement d’IS hors-ligne dans l’agent d’utilisateur
Afin que la solution de traitement d’IS soit complete, a-t-on déja dit, la présente thése propose un traitement au niveau de l’agent d’utilisateur en sus de celui prévu dans le serveur mandaté.
Ce traitement est exécuté en deux étapes. e Premiérement, la prévention est appliquée, ensuite la restriction (figure VII.4) La prévention est exécutée par SCE en deux temps.
- L’interface utilisateur (GUI) a été concue pour être capable d’éviter certaines erreurs sémantiques FIML qui pourraient étre générées par l°utilisateur De telles erreurs se traduisent comme des associations condition-action erronées Pour chaque action choisie par |’ utilisateur, Pinterface n’autorise de la lier qu’a un certain ensemble de conditions possibles On donnera quelques exemples par la suite.
- Chaque fois qu’une régle de préférence est spécifiée, l’analyseur sémantique est invoqué afin de vérifier la présence d’erreurs sémantiques entre les conditions de la régle Si c’est le cas, la régle est annulée.
User interface: action - condition user enters a preference rule
Semantic analyzer: condition element - condition element user entered all preference rules
< Reaction to restrictions ask user
Figure VH.4 Processus de détection résolution d’IS SUSC e L/étape de restriction commence lorsque !’utilisateur finit de spécifier ses préférences La procédure de détection-résolution est alors lancée Si une IS est détectée, une instruction de restriction est inférée Deux cas peuvent se présenter La restriction peut étre conditionnée par un ou plusieurs paramétres dont les valeurs ne sont pas connues mais le seront au cours du traitement d’appel Une telle restriction est stockée dans RR pour étre exécutée lorsque sa condition devient vraie Par exemple, une restriction qui s’applique sur le filtrage d’appels en entrée n’est exécutable que lorsqu’une requéte d’appel est recue Dans le deuxiéme cas, la restriction est une action sans condition Elle doit étre exécutée immédiatement (hors ligne). Une fois les restrictions générées, la procédure pourrait interagir avec l'utilisateur pour lui demander quelles seraient les réactions a exécuter si telle ou telle de ses préférences sont exclues en temps réel afin de résoudre des IS (interaction #7, chapitre V, section 5.1).
TABLEAU VII.1 CONDITIONS D’ACTIONS POSSIBLES
Ask user information | Constante : NAME, ADDRESS
Call pnority Constante : EMERGENCY, URGENT, NORMAL,
NONURGENT Push button Constante : FLASH, SQUARE, STAR
Told since Nombre de jours
Try call Nombre de fois, intervalle de temps entre les essais
Voice mail Fichier du message a jouer
Ask user mformation Nom, numéro ou adresse courriel
Email Adresse cible, message a inclure
Try call Nombre de fois, intervalle de temps entre les essais Voice mail Fichier du message a jouer
La prévention d’IS est exécutée par l’interface utilisateur (GUI) ensuite par |’analyseur sémantique (figure VII.4) Ce sont des composantes de SCE.
Avant de spécifier ses préférences, |’ utilisateur est interrogé si les préférences sont relatives a son rôle comme appelant ou bien comme appelé Ensuite, les préférences sont entrées par luHlisateur sous la forme condition-action Ainsi, l’interface évite aux utilisateurs d’avoir a apprendre FIML pour écrire du code eux-mémes Le générateur FIML produit le code FIML qui correspond aux préférences entrées et le stocke dans SR La possibilité de combiner des conditions pour déclencher une méme action permet de spécifier des préférences complexes.
Le tableau VII.1 contient la liste des conditions qu’offre l’interface et le tableau VI.2 la liste des actions.
Certaines erreurs sémantiques sont évitées par l’interface car elle ne permet pas de lier n’importe quelle condition à n’importe quelle condition Les causes des erreurs sémantiques FIML sont les suivantes :
(1) Service élémentaire a l’arrivée considéré au départ ou I’ inverse.
(2) Tentative de contrôler des actions impossibles à contrôler ou bien d’inhiber une partie du traitement d’appel.
(3) Action auto-conditionnée : exécuter une action si elle-méme a été exécutée.
(4) Tentative d’une action qui est impossible vu I’étape du traitement d’appel supposée par sa condition.
Voici des exemples d’erreurs sémantiques relevées parmi une cinquantaine qui ont été évitées par la conception de l’interface utilisateur On les a étiquetées par les numéros de causes correspondantes.
- Rediriger l’appelé (1) ; la redirection ne s’applique qu’a un appelant.
- Interdire des actions de l’appelé : raccrocher, composer, taper une touche donnée (2).
- Essayer un appel vers une adresse si un appel vers cette adresse est en train d’étre essayé (3).
- Si le nom de l’appelé est X alors demander le nom de l’appelé (3).
- Essayer un appel vers une adresse si je suis en appel avec son détenteur (4).
- Interdire de répondre occupé, raccrocher, taper une touche donnée (2).
- Rediriger lappelant vers X s’il a été redirigé vers X (3).
- Mettre en attente l’appelant s”1l est en attente (3) ; afin de mettre un utilisateur en attente, il ne doit pas étre en attente.
- Rediriger l'appelant si ’appel a échoué (4) ; si Pappel échoue, la redirection ne peut plus étre faite.
Chaque fois qu’on spécifie une préférence, l’analyseur sémantique est invoqué pour détecter les erreurs sémantiques qui ne sont pas évitables par l’ interface De telles erreurs se produisent entre les éléments de condition Si une régle de préférence est erronée, elle est annulée et une explication est donnée a ”utilisateur.
Les causes possibles de telles erreurs sont les suivantes :
(1) Contradiction logique entre les éléments de la partie condition de la régle.
(2) Impossibilité d’étre toutes vraies en méme temps (régle jamais inférable).
(3) Impossibilité de se produire en séquence.
Les résultats d’expériences ont dégagé plus de 70 cas d’erreurs sémantiques Voici des exemples :
- Appelé occupé et pas occupé (1).
- Avoir eu un appel avec un utilisateur donné ensuite ne pas avoir eu d’appel avec lui
- Appelant redirigé vers une adresse et vers un serveur de voix (2).
Quand l’utilisateur a fini de spécifier ses préférences et leur validité sémantique a été vérifiée, létape de restriction est amorcée par le lancement de la procédure de détection-résolution. Cette derniére génére des instructions de restriction pour étre exécutées immédiatement ou bien plus tard, au cours de traitement d’appel, si elles sont conditionnées par des informations qui ne sont pas immédiatement disponibles Ces restrictions sont stockées dans RR Aprés, la procédure pourrait interroger l’utilisateur 4 propos des réactions a exécuter en cours d’appel si certaines de ses préférences sont exclues Préparer la réaction en temps réel a des restrictions est une nouvelle méthode de traitement d’IS qu’ introduit cette these.
Les actions FIML qui pourralent étre exclues par des services d’autres utilisateurs, inconditionnellement ou bien sous certaines conditions, sont les suivantes :
- Requéte d’appel : exclue si l’appelé interdit de recevoir des appels de cette adresse.Conséquence : l’appel est annulé L’appelant doit avoir préparé une réaction a lannulation d’appel.
- Redirection d’appel : exclue si l’appelant a interdit d’étre redirigé Conséquence : Pappel est annulé L’appelant et appelé doivent avoir préparé une réaction a |’annulation d’appel.
- Voicemail : exclu si l’appelant a mterdit d’étre redirigé Conséquence : |’appel est annulé L’appelant et l’appelé doivent avoir préparé une réaction a |’annulation d’appel.
- Fourniture d’information relatives a l’utilisateur : exclue si l’utilisateur concerné la interdit Conséquence : le service est annulé L’appelant et lappelé doivent avoir préparé une réaction.
On donne a l’utilisateur la possibilité de choisir entre les réactions suivantes : rappeler l’autre participant, lui envoyer un courriel ou bien aucune réaction Les résultats expérimentaux obtenus pour la dérivation des régles de restriction et la réaction aux restrictions en temps réel sont décrits ci-bas.
Si l’appelé est sur la liste noire de OCS, l’appel est bloqué mais un courriel est envoyé à lappelé Ceci pourrait violer l’intention de l’appelant s’il ne veut communiquer par aucun moyen.
Interroger l”utilisateur : envoyer un courriel méme si l’appel est bloqué Si la réponse est non, le courriel est exclu Cette restriction est exécutée en temps réel.
Interroger l°utilisateur hors ligne quoi faire s1 l’appel échoue.
Choix : rappeler, courriel, aucune réaction.
Interroger [utilisateur hors ligne quoi faire si l’appelé refuse de fournir l’information lui concemant ? *
L’interaction a lieu quand l’appelant est sur la liste noire de TCS et AR rappelle ce même utilisateur.
Exclure AR si l’appelé est dans la liste noire Exécutée en temps réel.
Avant l’appel, utilisateur est interrogé si une exception doit étre faite pour les appels urgents.
Si la réponse est oui, TCS est exclu si l’appel entrant est urgent.
Avant Vappel, Putilisateur est interrogé quoi faire si l’appelant a refusé d’étre redirigé Choix: rappeler, courriel, aucune réaction *
Avant l’appel, l’utilisateur est interrogé quoi faire si l’appelant a refusé d’étre redirigé vers le serveur de voix.
Choix: rappeler, courriel, aucune réaction *
Interroger l’utilisateur hors ligne quoi faire si ’appelant refuse de fournir ’information lui concemant ? *
Les cas suivi par le caractére (*) sont des nouvelles méthodes de traitement des IS introduites par la présente thése.
5 Traitement d’IS en-ligne dans le terminal d’utilisateur et dans le réseau