FR2952262A1

FR2952262A1 - Autorisation d'etablissement d'appels simultanes

Info

Publication number: FR2952262A1
Application number: FR1052360A
Authority: FR
Inventors: Francois-Joseph Levee; Sarah Tronet
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2010-03-30
Filing date: 2010-03-30
Publication date: 2011-05-06

Abstract

La présente invention se rapporte à l'autorisation d'établissement de sessions, dans un réseau de communication, sur réception d'une requête émise depuis un terminal à disposition d'un utilisateur. Un gestionnaire de session, associé à l'utilisateur, autorise l'établissement de la session, si un paramètre de nombre de sessions actuellement en cours relatives à l'utilisateur est inférieur à un nombre de sessions autorisées, ledit paramètre étant compris dans le gestionnaire de session. L'invention s'applique notamment aux sessions, établies selon le protocole d'initialisation de session, plus communément désigné par l'acronyme anglais « SIP » pour « Session Initiation Protocol », pour le transfert de données multimédia, et en particulier pour la téléphonie par Internet.

Description

Autorisation d'établissement d'appels simultanés La présente invention se rapporte de manière générale à l'établissement de sessions dans un système de communication. En particulier, l'invention a trait à la gestion des autorisations d'établissement de sessions d'appels simultanés initiées ou reçues par un même utilisateur, en fonction des services auxquels ce dernier a souscrit. L'invention s'applique notamment aux sessions, établies selon le protocole d'initialisation de session, plus communément désigné par l'acronyme anglais «SIP » pour « Session Initiation Protocol », pour le transfert de données multimédia, et en particulier pour la téléphonie par Internet. Les services de communication basés sur le protocole SIP, notamment les services de voix sur réseau IP, permettent à un même terminal d'établir plusieurs sessions simultanément. Or, le fournisseur de services peut souhaiter restreindre le nombre maximum de sessions simultanées autorisées pour chaque terminal, en fonction par exemple des abonnements auxquels ce dernier a souscrit et/ou des caractéristiques du système de communication. Afin d'autoriser ou refuser l'établissement d'une session, il convient alors de comptabiliser le nombre de sessions en cours pour chaque terminal, puis de le comparer au nombre maximum de sessions simultanées autorisés pour ledit terminal. Les figures la et lb représentent, par un synoptique, une architecture connue pour permettre un tel comptage. Un premier utilisateur UA dispose d'un premier terminal SIP 12, par exemple un téléphone portable, et d'un deuxième terminal SIP 14, par exemple un ordinateur, apte à se connecter à un réseau 10. Un troisième terminal SIP 16 adapté à se connecter au réseau 10 appartient à un deuxième utilisateur UB. Un quatrième terminal SIP 17 adapté à se connecter au réseau 10 appartient à un troisième utilisateur UC. Pour établir une première session d'appel Cl à la demande du premier utilisateur UA entre le premier terminal SIP 12 et le troisième terminal 16 du deuxième utilisateur UB, un serveur applicatif 18 interroge 26 un serveur de base de données 20, pour obtenir le nombre de sessions d'appel NS_UA NB actuellement ouvertes pour le premier utilisateur UA. Typiquement le serveur de base de données 20 est un système externe de gestion de base de données connecté via un réseau local au serveur applicatif 18. Le serveur de base de données 20 peut également être une base de données interne incluse dans le même contexte que celui du serveur d'application 18, par exemple un système arborescent d'annuaire implémentant une interface de programmation « JNDI » ou « Java Naming and Directory Interface » en anglais.

Sur réponse 27 du serveur de base de données 20, le serveur applicatif 18 compare le nombre de sessions d'appel NS_UA_NB pour le premier utilisateur UA au nombre maximum NS_UA_MAX de sessions d'appel simultanées autorisées pour le premier utilisateur UA. Dans l'exemple des figures la et lb, le nombre maximum NS_UA_MAX est choisi égal à 1. Aussi, comme représenté sur la figure la, le serveur applicatif 18 autorise et établit la première session d'appel Cl, car le nombre de session d'appel NS_UA_NB est égal à 0, aucune autre session d'appel n'étant en cours pour le premier utilisateur UA. Une fois établie, le serveur applicatif 18 transmet au serveur de base de données 20 une demande de mise à jour 28 du nombre de sessions d'appel NS_UA NB pour le premier utilisateur UA.

Une fois la première session d'appel Cl établie, comme représenté sur la figure lb, le premier utilisateur UA souhaite établir une deuxième session d'appel C2 entre son deuxième terminal SIP 14 et le quatrième terminal SIP 17 du troisième utilisateur UC. Après requête 26 auprès du serveur de base de données 20, le serveur applicatif 18 va refuser l'établissement de la deuxième session d'appel C2, car après établissement de la deuxième session d'appel C2, le nombre de sessions d'appel NS_UA_NB serait alors supérieur au nombre maximum NS_UA_MAX pour le premier utilisateur UA. Dans une telle architecture, une indisponibilité du serveur de base de données 20 engendre une indisponibilité de la fonctionnalité de vérification du nombre maximum de sessions simultanées autorisées pour les utilisateurs souhaitant établir ou recevoir une session. Une telle indisponibilité peut résulter notamment d'un dysfonctionnement matériel et/ou logiciel ou encore d'une perte de connectivité entre le serveur d'application 18 et le serveur de base de données 20. Le serveur de base de données 20 ne peut alors dans pareille situation fournir le nombre de sessions en cours pour l'utilisateur concerné. Le serveur applicatif 18 ne peut plus autoriser ou refuser l'établissement d'une session selon ce critère, et doit alors par exemple prendre une décision par défaut quant à l'établissement de nouvelles sessions. En outre, lorsque le serveur de base de données 20 est à nouveau disponible, le nombre de sessions en cours pour chaque utilisateur n'est plus nécessairement correct, les données stockées pouvant être erronées. Le serveur de base de données 20 doit donc être resynchronisé. La gestion d'accès concurrents au nombre de sessions en cours pour chaque utilisateur est également problématique, notamment dans le cas où le serveur applicatif 18 est une grappe de serveurs d'application chacun susceptible de mettre à jour en parallèle pour un même utilisateur le nombre de sessions en cours. La présente invention vise à améliorer la situation. Selon un premier aspect, il est proposé un procédé d'autorisation d'établissement d'une session, dans un réseau de communication, sur réception d'une requête émise depuis un terminal à disposition d'un utilisateur. Il comporte l'étape suivante, mise en oeuvre par un gestionnaire de session associé à l'utilisateur : • autoriser l'établissement de la session si un paramètre de nombre de sessions actuellement en cours relatives à l'utilisateur est inférieur à un nombre de sessions autorisées, ledit paramètre étant compris dans le gestionnaire de session.35 Le procédé propose une solution ne nécessitant pas l'emploi d'un serveur de base de données interne ou externe pour suivre le nombre de session en cours pour chaque utilisateur. En effet, un même gestionnaire de session gère l'établissement d'appel sur réception des requêtes émises par l'utilisateur. Ainsi le gestionnaire de session peut accéder au paramètre de nombre de sessions actuellement en cours pour l'utilisateur et le comparer au nombre de sessions autorisées. Or ce paramètre est compris dans le gestionnaire de session. De fait, le procédé ne dépend plus de la disponibilité d'un serveur de base de données ou d'un annuaire pour remplir sa fonction d' autorisation.

Dans un mode de réalisation, l'établissement de la session est autorisée, en: calculant un identifiant unique propre à l'utilisateur à partir d'une information d'identification de l'utilisateur comprise dans la requête; recherchant, parmi un groupe comportant des gestionnaires de session munis chacun d'un compteur, un gestionnaire de session associé à l'identifiant ; • si un gestionnaire de session associé à l'identifiant est présent dans le groupe, sélectionner ledit gestionnaire de session associé à l'identifiant ; • dans le cas contraire, créer, dans le groupe, un gestionnaire de session associé à l'identifiant en initialisant la valeur de son compteur à zéro; comparant la valeur du compteur du gestionnaire de session associé à l'identifiant à la valeur d'un seuil, • si la valeur du compteur du gestionnaire de session associé à l'identifiant est supérieure ou égale à la valeur du seuil, rejetant la requête; • dans le cas contraire, autorisant l'établissement de la session, et : incrémentant la valeur du compteur du gestionnaire de session associé à l'identifiant, si la session est établie; décrémentant la valeur du compteur du gestionnaire de session associé à l'identifiant, en fin de session. En particulier, la requête et son traitement peuvent être conformes au protocole « Session Initiation Protocol ».

Dans ce dernier mode de réalisation, chaque fois qu'une requête est émise par un des utilisateurs, ce dernier est identifié puis le gestionnaire correspondant est sélectionné dans le groupe, ou, au besoin, créé. Il suffit alors de comparer la valeur du compteur du gestionnaire sélectionné, mise à jour à chaque établissement ou terminaison d'une session initiée par l'utilisateur, pour autoriser ou non l'établissement d'une session.

Pour répondre à d'autres exigences, l'information d'identification de l'utilisateur peut être un numéro de téléphone associé au terminal. Cette information présente l'avantage d'être généralement directement disponible dans la requête et facilement utilisable pour identifier un même utilisateur, même si ce dernier utilise différents terminaux sous un même abonnement souscrit auprès de son fournisseur de service. La valeur du seuil peut être fonction de l'utilisateur. Il devient alors possible de configurer de manière individualisée pour chaque utilisateur le nombre de sessions autorisées, en particulier en fonction des abonnements ou services souscrits. Selon un deuxième aspect, l'invention vise aussi des programmes d'ordinateur sur un support d'informations, ces programmes étant susceptibles d'être mis en oeuvre respectivement dans un ordinateur, ces programmes comportant respectivement des instructions adaptées à la mise en oeuvre des étapes des procédés selon le premier aspect. 15 Ces programmes peuvent utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. Selon un troisième aspect, il est proposé un support d'informations lisible par un ordinateur, 20 et comportant des instructions d'un programme d'ordinateur selon le deuxième aspect. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. 25 D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le 30 programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés en question. Selon un quatrième aspect, il est proposé un dispositif d'autorisation d'établissement d'une10 session, dans un réseau de communication, sur réception d'une requête émise depuis un terminal à disposition d'un utilisateur. Il comporte un module applicatif adapté pour héberger un gestionnaire de session associé à l'utilisateur, le gestionnaire de session étant configuré pour: • autoriser l'établissement de la session si un paramètre de nombre de sessions actuellement en cours relatives à l'utilisateur est inférieur à un nombre de sessions autorisées, ledit paramètre étant compris dans le gestionnaire de session. Dans un mode de réalisation, le module applicatif est adapté pour : calculer un identifiant unique propre à l'utilisateur à partir de l'information d'identification de l'utilisateur ; rechercher, parmi un groupe comportant des gestionnaires de sessions munis chacun d'un compteur, un gestionnaire de session associé à l'identifiant ; • si un gestionnaire de session associé à l'identifiant est présent dans le groupe, sélectionner ledit gestionnaire de session associé à l'identifiant ; • dans le cas contraire, créer, dans le groupe, un gestionnaire de session associé à l'identifiant en initialisant la valeur de son compteur à zéro; comparer la valeur du compteur du gestionnaire de session associé à l'identifiant à la valeur d'un seuil, • si la valeur du compteur du gestionnaire de session associé à l'identifiant est supérieure ou égale à la valeur du seuil, rejeter la requête; • dans le cas contraire, autoriser l'établissement de la session, et : incrémenter la valeur du compteur du gestionnaire de session associé à l'identifiant, si la session est établie; décrémenter la valeur du compteur du gestionnaire de session associé à l'identifiant, en fin de session. L'information d'identification de l'utilisateur est par exemple un numéro de téléphone associé au terminal. La valeur du seuil peut être fonction de l'utilisateur. Dans un mode de réalisation, la requête et son traitement peuvent être conformes au protocole Session Initiation Protocol SIP. En particulier, le module applicatif peut comprendre un 30 conteneur adapté pour accueillir au moins une servlet SIP pour mettre en oeuvre la signalisation SIP, la Servlet SIP implémentant l'interface logicielle de programmation SIP Servlet selon la spécification JSR-000289. Selon un cinquième aspect, il est proposé un système de communication comportant : 35 • un réseau de communication, 20 25 • au moins un terminal appartenant à un utilisateur et adapté pour émettre, afin d'établir une session, une requête comportant au moins une information d'identification de l'utilisateur ; • un dispositif selon le quatrième aspect couplé au réseau de communication pour traiter la requête. D'autres aspects, buts et avantages de l'invention apparaîtront à la lecture de la description d'un de ses modes de réalisation. L'invention sera également mieux comprise à l'aide des dessins, sur lesquels : - les figure la et lb, précédemment décrites, illustrent, par un synoptique, une architecture selon l'état de l'art pour gérer l'établissement de sessions d'appel ; - la figure 2, illustre, par un synoptique, un procédé, selon un mode de réalisation de l'invention, de gestion d'autorisation des sessions; - la figure 3 montre, par un schéma de principe, un système de communication comportant un serveur applicatif de gestion de session selon un mode de réalisation de l'invention. Un exemple d'un procédé de gestion d'autorisation de sessions selon un mode de réalisation, illustré sur la figure 2, va maintenant être décrit. Dans une étape 110, une requête INVITE d'établissement d'une session Cl est reçue. En particulier, la session Cl peut être une session d'appel. La requête INVITE est émise par un premier terminal appartenant à un premier utilisateur UA. La requête INVITE comporte notamment des informations INF_UA permettant d'identifier l'émetteur de ladite requête, c'est-à-dire le premier utilisateur UA. Les informations INF_UA sont par exemple un numéro d'appelant, ou un identifiant unique propre au premier utilisateur UA. La requête INVITE comprend des informations INFDEST permettant d'identifier un deuxième terminal, pour permettre l'établissement de la session Cl entre le premier terminal et le deuxième terminal. Les informations INF_DEST sont par exemple un numéro de destinataire, un identifiant unique propre au deuxième utilisateur UA, ou encore un identifiant unique propre au deuxième terminal. Dans une étape 120, un identifiant ID unique propre à l'utilisateur UA est calculé à partir des informations INF_UA. A titre d'exemple non limitatif, l'identifiant ID peut être égal ou équivalent aux informations INF_UA. Alternativement, l'identifiant ID peut être obtenu en calculant le résultat d'une fonction de hachage pour tout ou partie des informations INF_UA, la fonction de hachage étant choisie de sorte à rendre négligeable le risque de collision.

Dans une étape 130, on recherche s'il existe, parmi un groupe G de gestionnaires de session, un gestionnaire de session G_SESSION associé à l'identifiant ID. Dans la négative, dans une étape 140, un gestionnaire de session G SESSION est créé dans le groupe G et on associe ledit gestionnaire de session G_SESSION à l'identifiant ID.

Dans l'affirmative, dans une étape 150, le gestionnaire de session G_SESSION associé à l'identifiant ID est localisé dans le groupe G. On parle alors de gestionnaire de session G_SESSION_SEL sélectionné pour désigner, en fonction du résultat obtenu au cours de l'étape 130, soit le gestionnaire de session G_SESSION créé au cours de l'étape 140, soit alternativement le gestionnaire de session G_SESSION localisé au cours de l'étape 150. Chaque gestionnaire de session G_SESSION du groupe G comporte un compteur INF NB APPEL, dont la valeur est susceptible d'être incrémentée ou décrémentée, dont la valeur est initialisée à zéro lors de la création dudit gestionnaire de session. La valeur du compteur INF NB APPEL est initialisée à zéro lors de la création du gestionnaire de session. Le compteur INF NB APPEL est destiné à comptabiliser le nombre de sessions en cours pour l'utilisateur correspondant à l'identifiant ID associé au gestionnaire de session G_SESSION. La valeur du compteur INF NB APPEL du gestionnaire de session G_SESSION_SEL est lue, dans une étape 160, puis comparée dans une étape 170 à la valeur d'un seuil INF NBAPPEL MAX. La valeur du seuil INFNBAPPEL MAX peut être spécifique au premier utilisateur UA. Si la valeur du compteur INF NB APPEL est supérieure ou égale à celle du seuil INF NB APPEL MAX, la requête INVITE d'établissement d'une session est rejetée dans une étape 180. Un message peut être notifié à l'utilisateur UA pour l'informer du rejet de sa requête INVITE, éventuellement complété par une information relative aux raisons de ce rejet. A l'issue de l'étape 180, il est alors mis fin au procédé. Si la valeur du compteur INF NB APPEL est inférieure à celle du seuil INF NBAPPEL MAX, la requête INVITE d'établissement d'une session est acceptée, dans une étape 190. Un message peut être notifié à l'utilisateur UA et/ou à une unité chargée de l'établissement effectif de la session pour informer de l'autorisation de la requête INVITE.

Dans une étape 200, on attend la réception d'un message de statut MSG_STAT_C1 relatif à la session Cl. Le message de statut MSG_STAT_C1 est émis par l'unité en charge de la gestion des sessions. Dans une étape 210, on lit le contenu message de statut MSGSTATC1. Si le message de statut MSGSTATCl comporte une information indiquant l'échec de l'établissement effectif de la session Cl, il est mis fin au procédé à l'issue de l'étape 210. Si le message de statut MSG_STAT_C1 comporte une information confirmant l'établissement effectif de la session Cl, la valeur du compteur 1NF NB APPEL du gestionnaire de session G_SESSION_SEL sélectionné est incrémentée d'une unité au cours d'une étape 220.

Puis, on attend, dans une étape 230, un deuxième message de statut MSG2_STAT_C1 comportant une information confirmant la fin de la session Cl, émis par l'unité en charge de la gestion des sessions lorsqu'il est mis fin à la session Cl. Lorsque le deuxième message de statut MSG2STATCl est reçu, la valeur du compteur INF NB APPEL du gestionnaire de session G_SESSION_SEL sélectionné est décrémentée d'une unité au cours de l'étape 230. Il est mis fin au procédé à l'issue de l'étape 230. Ainsi, le gestionnaire de session G_SESSION_SEL sélectionné, associé à l'utilisateur, sur réception de la requête INVITE émise depuis le premier terminal à disposition du premier utilisateur UA à disposition d'un utilisateur, autorise l'établissement de la session Cl, si un paramètre de nombre de sessions actuellement en cours relatives à l'utilisateur, ici le compteur INF NB APPEL, est inférieur à un nombre de sessions autorisées, ici le seuil INF NBAPPEL MAX, ledit paramètre étant compris dans le gestionnaire de session G SESSION SEL sélectionné. Il est à noter que plusieurs instances du procédé ainsi décrits peuvent être exécutées en parallèle de sorte à traiter simultanément une pluralité de requêtes d'établissement de sessions émises pour une pluralité d'utilisateurs. Il convient alors de mettre en oeuvre des moyens de gestion d'accès concurrents au compteur INF_NB_APPEL pour chacun des gestionnaires de sessions G_SESSION, en particulier au cours des étapes 160, 220 et 230.

Dans la suite de la présente description, on considère l'exemple non limitatif de l'établissement de sessions conforme au protocole SIP, notamment les services de voix sur réseau IP. Toutefois, d'autres protocoles permettant l'établissement pour un même utilisateur d'une pluralité de sessions simultanées pourraient convenir également La figure 3 représente, par un synoptique, un système de communication selon un mode de réalisation. Un premier utilisateur UA dispose d'un premier terminal SIP 312, par exemple un téléphone portable, et d'un deuxième terminal SIP 314, par exemple un ordinateur, aptes à se connecter à un réseau 310. Un deuxième utilisateur UB est en possession d'un troisième terminal SIP 316 adapté à se connecter au réseau 310. Un quatrième terminal SIP 317 adapté à se connecter au réseau 310 appartient à un troisième utilisateur UC. Le système comporte un serveur applicatif 318. Le serveur applicatif 318 comporte par exemple une grappe composée d'au moins un ordinateur couplé au réseau 310. Le serveur applicatif est adapté pour mettre en oeuvre un environnement logiciel dans lequel un module applicatif 320 est exécuté. Le module applicatif 320 est par exemple une application de gestion de communications comprenant un conteneur logiciel pour accueillir au moins une servlet SIP 322 implémentant l'interface logicielle de programmation « SIP Servlet» dans sa version 1.1, définie dans le document « JSR-000289 SIP Servlet 1.1 ». La Servlet SIP 322 est un composant adapté pour mettre en oeuvre la signalisation SIP. La Servlet SIP 322 permet de retourner des messages de réponses SIP aux requêtes SIP émises par des terminaux SIP couplée au réseau 310. Le module applicatif 320 est configuré notamment pour mettre en oeuvre le procédé de gestion d'autorisation des sessions. Sur l'exemple de la figure 3, le premier terminal 312 de l'utilisateur UA émet une requête INVITE pour établir une session entre le premier terminal 312 et le deuxième terminal 316. La requête INVITE est reçue par la Servlet SIP 322 du serveur applicatif 318. La Servlet SIP 322 calcule alors un identifiant ID spécifique à l'utilisateur UA. Pour cela, la Servlet SIP 322 peut comporter un module de génération d'identifiant 324. Un squelette d'un mode de réalisation du module de génération d'identifiant 324 adapté pour être mis en oeuvre lorsque la Servlet SIP 322 implémentant l'interface logicielle de programmation «SIP Servlet» dans sa version 1.1, définie dans le document «JSR-000289 SIP Servlet 1.1 » est donné ci-après : @SipApplicationKey Public static String sessionKey(SipServletRequest request){ [CODE POUR CALCULER L 'INDENTIFIANT ID A PARTIR DES INFORMATIONS COMPRISES DANS LA REQUETE requestJ return (ID) } L'annotation « @SipApplicationKey », définie dans le document « JSR-000289 SIP Servlet 1.1 » permet de définir une méthode statique, dénommée "sessionKey", appelée par l'application logicielle 320 lors de la réception d'une requête INVITE.

A titre d'exemple non limitatif, l'identifiant ID retourné par le module de génération d'identifiant 324 est le numéro de téléphone du premier terminal 312. Le module applicatif 320 cherche alors s'il existe un gestionnaire de session Q SESSION associé à l'identifiant ID. Typiquement, dans la terminologie de l'interface logicielle de programmation «SIP Servlet », un gestionnaire de session correspond à un module dénommé « SipApplicationSesssion ». S'il n'existe pas de gestionnaire session G_SESSION associé à l'identifiant ID, le module applicatif. 320 créé un nouveau gestionnaire de session G_SESSION dans le groupe G, associe ledit gestionnaire de session G_SESSION à l'identifiant ID, et le sélectionne. S'il existe un gestionnaire de session G_SESSION associé à l'identifiant ID, la Servlet SIP 322 le sélectionne. Le gestionnaire de session G_SESSION_SEL sélectionné est donc soit le nouveau gestionnaire de session G_SESSION, soit le gestionnaire de session G_SESSION identifié. Chaque gestionnaire de session G_SESSION comporte un espace mémoire pour stocker une valeur de compteur INF NB_APPEL, et des moyens pour accéder à un seuil INF NBAPPEL MAX. Le seuil INF NBAPPEL MAX est par exemple stocké dans un espace mémoire du gestionnaire de session G_SESSION, et est initialisé lors de la création dudit gestionnaire, en fonction de l'identifiant Id ou de l'utilisateur correspondant et des services et/ou abonnements auxquels ce dernier a souscrit.

Le module applicatif 320 appelle le module d'établissement de session 326 pour établir la session correspondant au gestionnaire de session G_SESSION sélectionné. Dans la terminologie de l'interface logicielle de programmation « SIP Servlet », le module d'établissement de sessions 326 correspond à une méthode dénommée « dolnvite », implémentée par la servlet SIP 322 et invoquée par le module applicatif 320 sur réception d'une requête INVITE. Le module d'établissement de sessions 326 compare la valeur du seuil INF NBAPPEL MAX à la valeur de compteur INF NB APPEL du gestionnaire de session G_SESSION_SEL sélectionné. Si la valeur du compteur INF NB APPEL est supérieure ou égale à celle du seuil INF NB APPEL MAX, le module d'établissement de sessions 326 rejette la requête INVITE. Le module d'établissement de sessions 326 peut notifier à l'utilisateur à l'origine de la requête INIVTE le rejet de sa requête INVITE, éventuellement complété par une information relative aux raisons de ce rejet. Une telle situation est illustrée sur la figure 3, où une requête d'établissement d'une deuxième session C2 émis l'utilisateur UA est rejetée, car une autre session Cl est en cours et la valeur du seuil INF NB_APPEL_MAX est égale à 1. Si la valeur du compteur INF NB_APPEL est inférieure à celle du seuil INF NB APPEL MAX, le module d'établissement de sessions 326 autorise la requête INVITE, afin d'établir la session. Si la session a pu être effectivement établie, la valeur du compteur INF NB APPEL du gestionnaire de session G_SESSION_SEL sélectionné est incrémentée d'une unité par la Servlet SIP 322. Une fois la session terminée, la valeur du compteur INF NB APPEL du gestionnaire de session G_SESSION_SEL sélectionné est décrémentée d'une unité par le module d'établissement de sessions 326. Le cas d'utilisation présenté jusqu'ici a trait à l'autorisation d'un nombre maximum de session pour un utilisateur donné. Cependant, l'invention peut également être appliquée à l'ensemble des services de communications pour lesquels plusieurs sessions simultanées peuvent être ouvertes à la demande d'un même utilisateur, comme par exemple : • les services de gestion de double appel ou « Call Waiting » en anglais ; • les services de limitation d'appel simultanés ; • les services de transfert d'appels, par exemple le service de continuité d'appel vocal ou « Voice Call Continuity » en anglais.

Claims

REVENDICATIONS1. Procédé d'autorisation d'établissement d'une session (Cl, C2), dans un réseau de communication (310), sur réception (110) d'une requête émise depuis un terminal (312, 314, 316, 317) à disposition d'un utilisateur, caractérisé en ce qu'il comporte l'étape suivante, mise en oeuvre par un gestionnaire de session associé (120, 130, 140, 150) à l'utilisateur : • autoriser (190) l'établissement de la session si un paramètre de nombre de sessions actuellement en cours relatives à l'utilisateur est inférieur (160, 170) à un nombre de sessions autorisées, ledit paramètre étant compris dans le gestionnaire de session.
2. Procédé selon la revendication 1 dans lequel l'établissement de la session est autorisé en : calculant (120) un identifiant unique propre à l'utilisateur à partir d'une information d'identification de l'utilisateur comprise dans la requête; recherchant (130), parmi un groupe comportant des gestionnaires de session munis chacun d'un compteur, un gestionnaire de session associé à l'identifiant ; • si un gestionnaire de session associé à l'identifiant est présent dans le groupe, sélectionnant (150) ledit gestionnaire de session associé à l'identifiant ; • dans le cas contraire (130), créant (140), dans le groupe, un gestionnaire de session associé à l'identifiant en initialisant la valeur de son compteur à zéro; comparant (160, 170) la valeur du compteur du gestionnaire de session associé à l'identifiant à la valeur d'un seuil, • si la valeur du compteur du gestionnaire de session associé à l'identifiant est supérieure ou égale à la valeur du seuil, rejetant (180) la requête; • dans le cas contraire, autoriser (190) l'établissement de la session, et : ^ incrémentant (220) la valeur du compteur du gestionnaire de session associé à l'identifiant, si la session est établie (200, 210); ^ décrémentant (230) la valeur du compteur du gestionnaire de session associé à l'identifiant, en fin de session.
3. Procédé selon la revendication 2, dans lequel la valeur du seuil est fonction de l'utilisateur.
4. Procédé selon l'une quelconque des revendications précédentes, dans lequel la requête et son traitement sont conformes au protocole « Session Initiation Protocol ».
5. Programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé selon l'une quelconque des revendications 1 à 4 lorsque ce programme est exécuté par un processeur.
6. Support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur selon la revendication 5.
7. Dispositif d'autorisation d'établissement d'une session (Cl, C2), dans un réseau de communication (310), sur réception (110) d'une requête émise depuis un terminal (312, 314, 316, 317) à disposition d'un utilisateur, caractérisé en ce qu'il comporte un module applicatif (320) adapté pour héberger un gestionnaire de session associé à l'utilisateur, le gestionnaire de session étant configuré pour: • autoriser l'établissement de la session si un paramètre de nombre de sessions actuellement en cours relatives à l'utilisateur est inférieur à un nombre de sessions autorisées, ledit paramètre étant compris dans le gestionnaire de session.
8. Dispositif selon la revendication 7, dans lequel le module applicatif (320) est adapté pour : calculer un identifiant unique propre à l'utilisateur à partir de l'information d'identification de l'utilisateur ; rechercher, parmi un groupe comportant des gestionnaires de session munis chacun d'un compteur, un gestionnaire de session associé à l'identifiant ; • si un gestionnaire de session associé à l'identifiant est présent dans le groupe, sélectionner ledit gestionnaire de session associé à l'identifiant ; • dans le cas contraire, créer, dans le groupe, un gestionnaire de session associé à l'identifiant en initialisant la valeur de son compteur à zéro; comparer la valeur du compteur du gestionnaire de session associé à l'identifiant à la valeur d'un seuil, • si la valeur du compteur du gestionnaire de session associé à l'identifiant est supérieure ou égale à la valeur du seuil, rejeter la requête; • dans le cas contraire, autoriser l'établissement de la session, et : ^ incrémenter la valeur du compteur du gestionnaire de session associé à l'identifiant, si la session est établie; ^ décrémenter la valeur du compteur du gestionnaire de session associé à l'identifiant, en fin de session.
9. Dispositif selon la revendication 8, dans lequel la valeur du seuil est fonction de l'utilisateur.
10. Dispositif selon l'une quelconque des revendications 7 à 9, dans lequel la requête et son traitement sont conformes au protocole Session Initiation Protocol, SIP. 25 30 35
11. Dispositif selon la revendication 10, dans lequel le module applicatif (320) comprend un conteneur adapté pour accueillir au moins une servlet SIP (322) pour mettre en oeuvre la signalisation SIP, la Servlet SIP implémentant l'interface logicielle de programmation SIP Servlet selon la spécification JSR-000289.
12. Système de communication comportant : • un réseau de communication (310), • au moins un terminal (312, 314, 316, 317) appartenant à un utilisateur et adapté pour émettre, afin d'établir une session, une requête comportant au moins une information d'identification de l'utilisateur; • un dispositif selon l'une quelconque des revendications 7 à 11 couplé au réseau de communication (310) pour traiter la requête.