FR2972092A1 - Procede de gestion d'identites publiques par un utilisateur d'un reseau ims - Google Patents

Abstract

L'invention concerne un procédé de gestion d'identités publiques dans un réseau IMS, comprenant une étape au cours de laquelle un utilisateur envoie un message audit réseau IMS. Selon l'invention, ledit message contient au moins un paramètre spécifique dont la signification est de demander une modification spécifique du statut d'au moins une des identités publiques de l'utilisateur, et/ou de demander une liste d'identités publiques de l'utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact (AoC1, AoC2) à laquelle cette identité publique est rattachée.

Description

PROCÉDÉ DE GESTION D'IDENTITES PUBLIQUES PAR UN UTILISATEUR D'UN RESEAU IMS La présente invention concerne les réseaux de type IP (« Internet Protocol ») qui sont aptes à mettre en oeuvre des protocoles de contrôle 5 de session évolués. On rappelle que les réseaux IP permettent la diffusion de données conversationnelles, tels que « Voix sur IP », « Partage de Contenu », « Présence », ou « Messagerie Instantanée ». Dans ces réseaux, les services de communication peuvent identifier des ressources physiques 10 ou virtuelles au moyen de chaînes de caractères, par exemple des « URI » (initiales des mots anglais « Uniform Resource Identifier» signifiant « Identifiant Uniforme de Ressource »). La syntaxe des URI est définie dans le document RFC 3986 de l'IETF (Internet Engineering Task Force) ; la connaissance de l'URI d'une ressource permet d'obtenir 15 l'adresse IP d'un équipement du réseau de l'opérateur gérant cette ressource. Ces équipements peuvent par exemple être un terminal fixe ou mobile, ou une passerelle domestique ou située dans une entreprise (« Residential Gateway » en anglais), ou encore une passerelle 20 d'opérateur réseau (« Voice Gateway » en anglais), qui raccorde généralement un grand nombre de lignes analogiques ou RNIS, telle qu'un DSLAM-SIP (DSLAM sont les initiales des mots anglais « Digital Subscriber Line Access Multiplexer» signifiant « multiplexeur d'accès de lignes d'abonnés numériques » ; il s'agit d'un dispositif collectant le trafic 25 de données DSL qui transite sur un certain nombre de lignes téléphoniques). Par souci de brièveté, on utilisera fréquemment ci-dessous le terme générique de « terminal d'utilisateur », ou de « terminal » tout court, pour désigner ces divers équipements.

On rappelle également que les protocoles de contrôle de session évolués classiques, tels que les protocoles H.323 et SIP, utilisent des messages dits « de signalisation », qui sont des messages permettant à un terminal de demander une connexion avec un autre terminal, ou également des messages signalant qu'une ligne téléphonique est occupée, ou signalant que le téléphone appelé sonne, ou encore signalant que tel téléphone est connecté au réseau et peut être joint de telle ou telle manière. Lorsqu'un client enregistré sur un réseau utilisant un protocole de contrôle de session évolué souhaite bénéficier d'un service multimédia offert par le réseau, il émet vers le réseau un message de signalisation précisant sa requête. Le protocole SIP (initiales des mots anglais « Session Initiation Protocol » signifiant « Protocole d'Initialisation de Session ») a été défini par l'IETF dans le document RFC 3261. Ce protocole permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Les identités SIP peuvent être de la forme « SIP-URI » telle que définie dans la RFC 3261, ou de la forme « tel-URI » telle que définie dans la RFC 3966. Une SIP-URI est de la forme « user@host » (par exemple, alice@domaine1), où la partie « host » identifie le réseau sur lequel l'utilisateur représenté par la partie « user » possède un compte. Une tel-URI est de la forme « tel:numéro_de_téléphone » (par exemple, tel:+336123456789). Ce protocole SIP est utilisé notamment dans les infrastructures de type IMS (initiales des mots anglais « IP Multimedia Subsystem » signifiant « Sous-système Multimédia sur IP »). L'IMS a été défini par les organismes de normalisation 3GPP (« 3rd Generation Partnership Project ») et TISPAN (« Telecommunications and Internet Converged Services and Protocols for Advanced Networking »). C'est une architecture de réseau introduite par le 3GPP pour les réseaux mobiles, puis reprise par TISPAN pour les réseaux fixes. Cette architecture permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients, ainsi que la réservation de ressources au niveau du réseau de transport des flux multimédias. Grâce à cette architecture, les opérateurs réseau peuvent commodément mettre en oeuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'IMS permet actuellement d'accéder à des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée, dont elle gère aussi l'interaction. Chaque utilisateur d'un réseau IMS peut y être identifié au moyen de diverses identités, dont l'IMPI (initiales des mots anglais « IP Multimedia Private Identity» signifiant « Identité Privée pour IP Multimédia ») et l'IMPU (initiales des mots anglais « IP Multimedia PUblic identity» signifiant « Identité Publique pour IP Multimédia »). L'IMPI se présente sous la forme d'une URI, et l'IMPU se présente sous la forme d'une URI ou d'un numéro court, ou encore d'un alias quelconque. L'IMPI est une identité unique affectée de manière permanente à un terminal par l'opérateur du réseau, et est utilisé, par exemple, pour l'enregistrement, l'autorisation d'accès, l'administration des services offerts à l'utilisateur, et la facturation. Un utilisateur se sert de son IMPU pour communiquer avec d'autres utilisateurs. Pour un IMPI donné, il peut y avoir plusieurs IMPU (souvent, une tel-URI et une SIP-URI). Un IMPU peut être partagé avec un autre téléphone, de manière à ce que ces téléphones puissent être tous les deux joints avec la même identité (par exemple, un numéro de téléphone unique pour toute une famille d'utilisateurs). Ces identifiants sont configurés par l'opérateur lors de la création par un utilisateur d'un compte auprès de cet opérateur, et exploités lors de l'enregistrement du terminal de l'utilisateur sur le réseau. Lorsque donc un utilisateur souhaite bénéficier des services offerts par un réseau IMS, son terminal doit, sauf exceptions (cas de certains appels d'urgence), s'enregistrer sur le réseau. Pour pouvoir enregistrer les utilisateurs, les réseaux IMS comprennent un ou plusieurs serveurs, généralement appelés « S-CSCF » (initiales des mots anglais « Serving-Call Server Control Function » signifiant « Fonction de Contrôle du Serveur d'Appels de Service »), aptes (entre autres fonctions) à gérer la procédure d'enregistrement des dispositifs connectés au réseau. En outre, ces réseaux comprennent un ou plusieurs serveurs, généralement appelés « I-CSCF » (initiales des mots anglais « Interrogating-Call Server Control Function » signifiant « Fonction de Contrôle du Serveur d'Appels d'Interrogation ») qui, au moment de l'enregistrement d'un terminal d'utilisateur, interrogent un serveur appelé « HSS » (initiales des mots anglais « Home Subscriber Server» signifiant « Serveur d'Abonné Nominal ») pour pouvoir sélectionner un serveur SCSCF possédant les caractéristiques requises pour atteindre le niveau de service souscrit par cet utilisateur.

En effet, chaque utilisateur peut, après qu'un serveur S-CSCF lui ait été ainsi attribué, envoyer une requête de souscription à certains services, notamment des services de notification d'évènements (« eventpackage » en anglais) pour la connexion en cours. Il peut s'agir par exemple d'un service de notification de dépôt de message vocal, ou d'un service de notification de présence, ce demier permettant à cet utilisateur de recevoir des informations (telles que « disponible », « occupé », ou « en réunion ») publiées par un autre utilisateur qu'il a désigné. Les serveurs S-CSCF, mentionnés ci-dessus, contribuent à la mise en ceuvre de ces divers services en gérant le routage de la signalisation, d'une part, entre chaque terminal d'utilisateur et les serveurs du réseau spécialisés dans la mise en oeuvre de tel ou tel service souscrit par l'utilisateur, et d'autre part en direction d'autres utilisateurs gérés par le même réseau ou par un réseau qui lui est relié. Pour pouvoir acheminer ces diverses requêtes au sein du réseau, 30 les serveurs de type I-CSCF ou de type S-CSCF (d'ailleurs souvent combinés en un même serveur, dénoté I/S-CSCF) échangent des informations avec un ou plusieurs serveur(s) de type HSS mentionné ci-dessus. Les serveurs HSS contiennent chacun une base de données-clients, et sont donc l'équivalent dans les réseaux IP des serveurs « HLR » (initiales des mots anglais « Home Location Register» signifiant « Registre de Localisation Nominal ») utilisés dans les réseaux GSM. Chaque serveur HSS contient le profil d'un certain nombre d'utilisateurs du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services souscrits.

Dans le processus de création d'un compte d'utilisateurs sur un réseau IMS, l'opérateur du réseau crée d'abord dans le HSS une souscription IMS (notée « IMS Subscription » dans les figures annexées), qui servira de fondement à la facturation. L'opérateur note ensuite, en référence à cette souscription, les identités privées IMPI et publiques IMPU des utilisateurs partageant cette souscription, déclare leurs profils de services et les IFC (initiales des mots anglais « Initial Filter Criteria » signifiant Critères de Filtrage Initiaux) associés, ainsi que de nombreuses autres informations relatives aux utilisateurs. Les figures 1 et 2, tirées de la spécification 3GPP TS 23.228, illustrent, à titre d'exemples, des données liées à des souscriptions IMS. La figure 1 illustre les données liées à la souscription IMS d'un utilisateur ayant 1 identité privée IMPI (notée « Private User Identity ») et 3 identités publiques IMPU (notées « Public User Identity 1 », « Public User Identity 2 » et « Public User Identity 3 »). Deux de ces identités publiques sont regroupées dans un IRS (initiales des mots anglais « Implicit Registration ID Set» signifiant « Ensemble Implicite d'Enregistrement d'Identités »), qui est représenté sur la figure 1 par un rectangle en pointillé. Cette notion d'IRS permet d'utiliser une identité publique pour en enregistrer aussi implicitement une autre. Par exemple, supposons que « l'utilisateur » à enregistrer soit une IPBX, à savoir un PABX (initiales des mots anglais « Private Automatic Branch eXchange » signifiant « Autocommutateur Téléphonique Privé », qui sert principalement à relier les postes téléphoniques d'un établissement avec le réseau téléphonique public) exécutant un logiciel, au lieu d'un équipement électronique indépendant et dédié ; dans ce cas, il est commode de n'avoir à enregistrer que l'une des multiples identités publiques attachées à l'IPBX pour déclarer la présence sur le réseau de l'ensemble des identités : l'IRS contient l'ensemble des identités de l'IPBX. II en serait de même pour l'enregistrement d'une passerelle offrant plusieurs accès. On utilise parfois une identité publique spécifique lors de l'enregistrement d'un IRS. Cette identité représente généralement un utilisateur tel qu'un IPBX ou une passerelle dans son ensemble, et ne peut pas être utilisée en tant que telle à des fins de routage. On parle alors de « barred identity » (mots anglais signifiant « identité non utilisable »). La figure 2 illustre, avec les mêmes conventions que la figure 1, les données liées à la souscription IMS -- un peu plus complexe -- d'un utilisateur possédant deux identités privées et six identités publiques regroupées dans trois IRS ; on notera en particulier que l'identité publique « Public User Identity 3 » est commune aux deux identités privées. La figure montre également les profils de services associés à chacune des identités publiques. Si, par exemple, l'utilisateur enregistre un terminal configuré avec l'identité privée « Private User Identity 2 » et l'identité publique « Public User Identity 5 », alors l'identité publique « Public Identity 6 » sera elle aussi (implicitement) enregistrée, car ces deux identités publiques appartiennent au même IRS (IRS3) ; l'utilisateur sera donc joignable sur son terminal à la fois via son identité publique 5 et via son identité publique 6.

Cet ensemble de données, utilisé lors de la déclaration sur le HSS, est ensuite téléchargé par le S-CSCF en charge de l'utilisateur. Ce SCSCF pourra ainsi connaître l'ensemble des identités déclarées dans la souscription IMS, savoir quelles sont celles qui sont enregistrées implicitement, et faire le lien entre les identités publiques et l'adresse de contact du terminal (telle que définie dans la RFC 3261) afin d'acheminer les appels entrants. De plus, le S-CSCF connaît l'état d'enregistrement de chaque identité publique ; selon les normes actuelles, cet état peut être « registered » (identité enregistrée), « not registered » (identité non enregistrée), ou encore « unregistered » (identité non enregistrée, mais ayant néanmoins bénéficié d'un service IMS, par exemple le traitement d'un appel destiné à cette identité publique). Selon l'état de l'art, la déclaration dans le HSS d'une souscription IMS est statique. Autrement dit, les données de la souscription IMS ne peuvent être modifiées que par le processus de « Service Livraison » de l'opérateur (i.e. le Système d'information, inaccessible aux utilisateurs). Or, il serait fort utile de pouvoir modifier de manière dynamique certaines données de souscription : c'est notamment le cas du contenu des IRS. Les trois exemples suivants illustrent l'utilité d'une gestion dynamique des IRS. Si l'IRS représente un IPBX et la souscription IMS représente le compte de souscription d'une entreprise multi-site, alors la gestion dynamique de l'IRS permettrait de déclarer aisément un utilisateur nomade sur tel ou tel site, selon son plan de route, en retrouvant à chaque fois son profil de service à l'identique. Si l'IRS représente une passerelle réseau telle qu'une « Voice Gateway» SIP, alors la gestion dynamique de l'IRS permettrait de déclarer certains accès comme indisponibles, ou bien à nouveau en service, au fil des évolutions de cette passerelle.

Si l'IRS représente un service tel que la liste « Mes adresses professionnelles », alors la gestion dynamique de l'IRS permettrait d'ajouter ou de retirer, par exemple, un téléphone mobile ou un poste fixe privé de cette liste, selon la disponibilité de leur utilisateur.

Or il n'existe pas dans l'état de l'art de possibilité de modifier dynamiquement le contenu d'un IRS. En particulier, il n'est pas possible de désenregistrer une identité publique dans l'IRS sans désenregistrer la totalité des identités publiques contenues dans cet IRS. La présente invention concerne donc un procédé de gestion d'identités publiques dans un réseau IMS, comprenant une étape au cours de laquelle un utilisateur envoie un message audit réseau IMS. Ledit procédé est remarquable en ce que ledit message contient au moins un paramètre spécifique dont la signification est de demander une modification spécifique du statut d'au moins une des identités publiques de l'utilisateur, et/ou de demander une liste d'identités publiques de l'utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée. Grâce à l'invention, on peut ajouter n'importe quelle identité publique de la souscription IMS dans n'importe quel IRS, ou transférer n'importe quelle identité publique d'une identité privée enregistrée vers n'importe quelle autre identité privée enregistrée (et donc diriger les appels de tiers vers une autre adresse de contact). On offre ainsi un maximum de flexibilité à l'utilisateur dans la gestion de sa joignabilité. Par exemple, dans le cas de la figure 2, on peut transférer dynamiquement l'IMPU « Public User Identity 1 » vers l'IRS 3 (associé à l'IMPI « Private User Identity 2 ») : le résultat de cette opération est illustré sur la figure 3. De plus, l'invention offre à l'utilisateur la possibilité de connaître le statut de l'une quelconque de ses identités publiques, compte tenu de l'adresse de contact (c'est à dire, de l'identité privée) à laquelle cette identité publique est rattachée. La notion de « statut » selon l'invention généralise la notion classique d'état d'enregistrement ; ainsi (comme illustré dans les exemples ci-dessous), le statut d'une identité publique pourra être par exemple son état d'enregistrement, ou une maintenance en cours sur cette identité publique, ou l'historique de service, et ainsi de suite. Selon des caractéristiques particulières, un serveur S-CSCF dudit réseau IMS renvoie audit utilisateur, en réponse audit message, une liste d'identités publiques de l'utilisateur en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée. Grâce à ces dispositions, l'utilisateur reçoit confirmation que sa requête a bien été prise en compte, et peut vérifier le rattachement de telle ou telle de ses identités publiques. Selon des caractéristiques encore plus particulières, ledit serveur 15 S-CSCF fournit également dans ladite réponse le statut de chacune des identités publiques de ladite liste. Grâce à ces dispositions, l'utilisateur peut également vérifier le statut actuel de telle ou telle de ses identités publiques. Corrélativement, l'invention concerne divers dispositifs. 20 Elle concerne ainsi, premièrement, un serveur S-CSCF d'un réseau IMS dans un réseau IMS. Ledit serveur S-CSCF est remarquable en ce qu'il comprend des moyens pour : enregistrer et mettre à jour le statut de chacune des identités publiques des utilisateurs dont il a la charge, en fonction, pour 25 chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée, et suite à la réception d'un message de la part d'un de ces utilisateurs, prendre en compte au moins un paramètre spécifique contenu dans ledit message et dont la signification est 30 de demander une modification spécifique du statut d'au moins une des identités publiques de l'utilisateur, et/ou de demander une liste d'identités publiques de l'utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée.

Selon des caractéristiques particulières, ledit serveur S-CSCF comprend en outre des moyens pour renvoyer audit utilisateur, en réponse audit message, une liste d'identités publiques de l'utilisateur en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée.

Selon des caractéristiques encore plus particulières, ledit serveur S-CSCF comprend en outre des moyens pour fournir également dans ladite réponse le statut de chacune des identités publiques de ladite liste. L'invention concerne aussi, deuxièmement, un équipement apte à envoyer un message à un réseau IMS. Ledit équipement est remarquable en ce qu'il possède des moyens pour inclure dans ledit message un paramètre spécifique dont la signification est de demander une modification spécifique du statut d'au moins une des identités publiques de l'utilisateur de cet équipement, et/ou de demander une liste d'identités publiques de cet utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée. Comme indiqué ci-dessus, cet équipement peut être aussi bien un terminal fixe ou mobile, qu'une passerelle domestique ou située dans une entreprise, ou encore qu'une passerelle d'opérateur réseau.

Les avantages offerts par ces dispositifs sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus. Selon des dispositions particulières, on pourra réaliser l'un quelconque des dispositifs succinctement exposés ci-dessus dans le contexte d'un circuit électronique. Ce circuit électronique pourra, par exemple, être constitué par une puce à logique câblée ou comprendre un microprocesseur. Selon d'autres dispositions particulières, on pourra réaliser l'un quelconque des dispositifs succinctement exposés ci-dessus dans le contexte d'instructions logicielles. L'invention vise donc également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes de l'un quelconque des procédés de gestion d'identités publiques succinctement exposés ci-dessus, lorsqu'il est exécuté sur un ordinateur. Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par lesdits procédés.

D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui l'accompagnent, dans lesquelles : - la figure 1, décrite ci-dessus, représente un premier exemple de 20 données liées à une souscription IMS, - la figure 2, décrite ci-dessus, représente un second exemple de données liées à une souscription IMS, et - la figure 3, décrite ci-dessus, représente les données résultant d'une modification dynamique par l'utilisateur des données de la figure 2. 25 Dans un réseau IMS, le serveur de base de données HSS est notamment interrogé : - par la fonction I-CSCF lors de l'enregistrement d'un terminal d'utilisateur afin d'allouer un serveur I/S-CSCF au terminal ou de retrouver le serveur I/S-CSCF qui lui a été déjà alloué ; - par la fonction S-CSCF lors de l'enregistrement initial du terminal afin de télécharger les données concemant les services souscrits, dont notamment les points de détection qui permettront au serveur I/S-CSCF de déterminer quel message de signalisation il doit acheminer vers quel serveur d'application (tel qu'un serveur de messagerie vocale, un serveur de présence ou un serveur de téléphonie) ; - par la fonction S-CSCF lors des enregistrements du terminal, afin d'informer le serveur HSS de l'installation ou de la prolongation d'un enregistrement sur le serveur I/S-CSCF ; et - par la fonction S-CSCF, afin de récupérer les informations nécessaires à l'authentification de la signalisation émise par le terminal. Dans l'art antérieur, le contenu de la souscription IMS d'un utilisateur est statique. Ses identités publiques sont définies à l'avance par l'opérateur, et il n'est pas possible pour un utilisateur de modifier les identités publiques par lesquelles il sera joignable dans le réseau. L'invention propose d'introduire la possibilité pour un utilisateur de gérer lui-même les identités au moyen desquelles il sera connu dans le réseau, en envoyant au réseau IMS un message approprié. Compte tenu des fortes contraintes inhérentes à la manipulation d'identités publiques, il est toutefois préférable que l'opérateur du réseau introduise un indicateur dans la souscription IMS de l'utilisateur pour déclarer si l'utilisateur est autorisé ou non à mettre en ceuvre la gestion dynamique des identités publiques selon l'invention ; cet indicateur sera par exemple configuré dans le HSS, puis copié dans le S-CSCF. L'invention introduit également la possibilité pour un serveur SCSCF d'associer à chaque identité publique d'un utilisateur dont il a la charge le statut de cette identité publique en fonction de l'adresse de contact à laquelle cette identité publique est rattachée (la même identité publique pouvant être rattachée à une ou plusieurs adresse(s) de contact). Le serveur S-CSCF selon l'invention a donc les moyens de mettre à jour ces statuts au fur et à mesure de leur évolution de service.

On va maintenant illustrer le fonctionnement et les avantages de l'invention dans le cadre de divers modes de réalisation, en s'appuyant sur la figure 2, déjà décrite ci-dessus, et dans laquelle, par exemple : - « Public User Identity 1 » est <sip:IMPU1@home.domain.com> et

- « Public User Identity 2 » est <teI:IMPU1>

en association avec l'adresse de contact <sip:AoC1> ; - « Public User Identity 4 » est <sip:IMPU3@home.domain.com>,

- « Public User Identity 5 » est <sip:IMPU4@home.domain.com> et - « Public User Identity 6 » est <sip:IMPU5@home.domain.com> en association avec l'adresse de contact <sip:AoC2> ; et

« Public User Identity 3 » est <sip:IMPU2@home.domain.com> 15 en association avec les deux adresses de contact.

Le procédé selon l'invention est déclenché par l'envoi d'un message au réseau IMS par un utilisateur de ce réseau. De manière classique, ce message contient un identifiant de l'utilisateur auprès du réseau IMS, tel que l'une des adresses de contact ou l'une des identités

20 publiques de l'utilisateur.

Considérons par exemple l'enregistrement initial de cet utilisateur sur le réseau IMS avec l'identité publique « IMPU1@home.domain.com » : 25 REGISTER sip:home.domain.com SIP/2.0 To: <sip:IMPUI@home.domain.com> From: <sip:IMPU1@home.domain.com>;tag-regtagxx Call-Id: diagxx CSeq: 1 REGISTER 30 Contact: <sip:AoCl>;[...];expires-3600 Une fois l'utilisateur enregistré, le S-CSCF prend en compte le paramètre représenté par l'adresse de contact (AoC1) mentionnée dans le message REGISTER en renvoyant de préférence à l'utilisateur l'ensemble de ses identités publiques connues et en service associées à cette adresse de contact, par exemple dans des en-têtes SIP « P-Associated-URI » : SIP/2.0 200 OK To: <sip:IMPU1@home.domain.com> From: <sip:IMPU1@home.domain.com>;tag=regtagxx Ca11-Id: diagxx CSeq: 1 REGISTER Contact: <sip:AoCl>;[_];expires=3600 P-Associated-URI: <sip:IMPUl@home.domain.com> P-Associated-URI: <tel:IMPUl> P-Associated-URI: <sip:IMPU2@home.domain.com> On notera que, contrairement à l'état de l'art, le S-CSCF ne renvoie pas l'identité publique <sip:IMPU3@home.domain.com>, en dépit du fait qu'elle appartient au même IRS (IRS2) que l'identité publique <sip:l MPU2@home.domain.com>.

Selon un premier mode de réalisation de l'invention, on utilise la 20 méthode SIP REGISTER pour véhiculer les informations de gestion dynamique des identités publiques.

Si l'utilisateur souhaite, par exemple, retirer l'identité publique

(MPU2 de la liste ci-dessus, il lui suffit (dans l'hypothèse où l'indicateur de

gestion lui autorise ce genre de manipulation) d'envoyer le message 25 REGISTER suivant, utilisant le paramètre « remove » :

REGISTER sip:home.domain.com SIP/2.0 To: <sip:IMPUl@home.domain.com> From: <sip:IMPUl@home.domain.com>;tag=regtagxx 30 Call-Id: diagxx CSeq: 1 REGISTER Contact: <sip:AoCl>;[_];remove=<sip:IMPU2@home.domain.com>: not reg;expires=3600 35 De préférence, le S-CSCF renvoie l'ensemble des identités publiques connues et en service de l'utilisateur associées à l'adresse de contact concernée afin de confirmer la modification : SIP/2.0 200 OK 40 To: <sip:IMPUl@home.domain.com> From: <sip:IMPUl@home.domain.com>;tag=regtagxx Call-Id: diagxx CSeq: 1 REGISTER Contact: <sip:AoCl>;[...];expires=3600 P-Associated-URI: <sip:IMPU1@home.domain.com> P-Associated-URI: <tel:IMPUl> On constate effectivement que le S-CSCF a bien pris en compte le

paramètre « remove » puisque l'identité publique IMPU2 n'apparaît plus. Dorénavant, cette identité publique ayant (voir requête ci-dessus) le statut de « not reg » (non enregistrée), les appels destinés à IMPU2 seront directement renvoyés sur messagerie.

Supposons maintenant que l'utilisateur souhaite ajouter une identité IMPU2 à sa liste des identités publiques dans l'IRS. Il lui suffit alors (dans l'hypothèse où l'indicateur de gestion lui autorise ce genre de manipulation) d'envoyer le message REGISTER suivant, utilisant le paramètre « add » :

REGISTER sip:home.domain.com SIP/2.0 To: <sip:IMPU1@home.domain.com> From: <sip:IMPUl@home.domain.com>;tag=regtagxx 20 Call-Id: diagxx CSeq: 1 REGISTER Contact:<sip:AoCl>;[...];add=<sip:IMPU2@home.domain.com>: active;expires=3600 25 De préférence, le S-CSCF renvoie l'ensemble des identités publiques connues et en service de l'utilisateur associées à l'adresse de contact concernée afin de confirmer la modification : SIP/2.0 200 OK 30 To: <sip:IMPUl@home.domain.com> From: <sip:IMPU1@home.domain.com>;tag=regtagxx Call-Id: diagxx CSeq: 1 REGISTER Contact: <sip:AoCl>;[...];expires=3600 35 P-Associated-URI: <sip:IMPUl@home.domain.com> P-Associated-URI: <tel:IMPUl> P-Associated-URI: <sip:IMPU2@home.domain.com> 40 On constate effectivement que le S-CSCF a bien pris en compte le paramètre « add » puisque l'identité publique IMPU2 figure bien dans cette liste, et est donc en service (paramètre « active ») conformément à la requête ci-dessus.

Supposons maintenant que l'utilisateur souhaite connaître la liste de ses identités publiques, ainsi que leur statut dans le S-CSCF. II lui suffit alors (dans l'hypothèse où l'indicateur de gestion lui autorise ce genre de manipulation) d'envoyer le message REGISTER suivant, utilisant le paramètre « list » :

REGISTER sip:home.domain.com SIP/2.0 To: <sip:IMPUl@home.domain.com> From: <sip:IMPUl@home.domain.com>;tag=regtagxx Call-Id: diagxx CSeq: 1 REGISTER Contact: list=all; Le S-CSCF renvoie alors à l'utilisateur l'ensemble de ses identités publiques connues, ainsi que leur statut respectif, eu égard, pour chacune de ces identités publiques, à l'adresse de contact concernée : SIP/2.0 200 OK To: <sip:IMPUl@home.domain.com> From: <sip:IMPU1@home.domain.com>;tag=regtagxx Call-Id: diagxx CSeq: 1 REGISTER Contact: <sip:AoCl>;[_];expires=2340 P-Associated-URI: <sip:IMPU1@home.domain.com>:active:Aocl P-Associated-URI: <tel:IMPUl>:active:Aocl P-Associated-URI: <sip:IMPU2@home.domain.com>:active:Aocl Contact: <sip:AoC2>;[_];expires=1540 P-Associated-URI: <sip:IMPU2@home.domain.com>:active:Aoc2 P-Associated-URI: <sip:IMPU3@home.domain.com>:created P-Associated-URI: <sip:IMPU4@home.domain.com>:not_reg P-Associated-URI: <sip:IMPU5@home.domain.com>:maintenance En variante, l'invention propose un nouveau paramètre, désigné ci-dessous par « pau », que le S-CSCF peut insérer dans l'en-tête « Contact » pour représenter les P-Associated-URI et leur statut respectif : SIP/2.0 200 OK To: <sip:IMPUl@home.domain.com> From: <sip:IMPU1@home.domain.com>;tag=regtagxx Call-Id: diagxx CSeq: 1 REGISTER Contact:<sip:AoCl>;[_];expires=2340; pau:<sip:IMPUl@home.domain.com>:active; pau:<tel:IMPUl>:active; pau:<sip:IMPU2@home.domain.com>:active Contact:<sip:AoC2>;[_];expires=1540; pau:<sip:IMPU2@home.domain.com>:active; pau:<sip:IMPU3@home.domain.com>:created; pau:<sip:IMPU4@home.domain.com>:not_reg; pau:<sip:IMPU5@home.domain.com>:maintenance On constate effectivement que le S-CSCF a bien pris en compte le paramètre « list=all » puisque les six identités publiques de l'utilisateur figurent dans cette liste. On note en particulier que l'identité IMPU3 est dans l'état d'enregistrement « created », qui indique que cette identité à été créée mais n'a pas encore fait l'objet d'une mise en service. Le statut « maintenance » de l'identité IMPU5, quant à lui, indique qu'une intervention sur cette identité est en cours ; elle est donc temporairement inutilisable.

L'invention s'applique naturellement aussi aux « Wilcard Public User Identifies » (mots anglais signifiant « Identités Publiques d'Utilisateur avec Joker »), lesquelles définissent simplement un ensemble, ou une gamme, d'identités publiques possibles pour une identité privée donnée. On pourra par exemple supprimer une identité publique particulière dans cet ensemble ou cette gamme.

Enfin, on notera que l'invention permet de modifier le statut d'une identité publique particulière pour l'ensemble des adresses de contact attribuées à l'utilisateur. Par exemple, si l'utilisateur souhaite activer son identité IMPU3 pour ses deux adresses de contact, il pourra (dans l'hypothèse où l'indicateur de gestion lui autorise ce genre de manipulation) utiliser le message suivant, qui utilise les paramètres « all », « add » et « active » (on utilise de préférence le paramètre « all » au lieu du paramètre « * » afin d'éviter la confusion avec les normes en vigueur, qui prévoient l'utilisation du symbole « * » pour le désenregistrement de l'ensemble des contacts) : REGISTER sip:home.domain.com SIP/2.0 To: <sip:IMPUl@home.domain.com> From: <sip:IMPUl@home.domain.com>;tag=regtagxx Call-Id: diagxx CSeq: l REGISTER Contact: all;[...];add=<sip:IMPU3@home.domain.com>:active; De préférence, le S-CSCF renvoie, pour chacune des adresses de contact de l'utilisateur, l'ensemble des identités publiques connues ainsi que leur statut associé afin de confirmer la modification : SIP/2.0 200 OK To: <sip:IMPUl@home.domain.com> From: <sip:IMPUl@home.domain.com>;tag=regtagxx Call-Id: diagxx CSeq: 1 REGISTER Contact:<sip:AoCl>;[_];expires=2340; pau:<sip:IMPU1@home.domain.com>:active; pau:<tel:IMPUl>:active; pau:<sip:IMPU2@home.domain.com>:active pau:<sip:IMPU3@home.domain.com>:active; Contact:<sip:AoC2>;[_];expires=1540; pau:<sip:IMPU1@home.domain.com>:active; pau:<sip:IMPU3@home.domain.com>:active; pau:<sip:IMPU4@home.domain.com>:not_reg; pau:<sip:IMPU5@home.domain.com>:maintenance On constate effectivement que le S-CSCF a bien pris en compte les paramètres du message REGISTER puisque l'identité publique <sip:IMPU3@home.domain.com> a été activée en référence aux adresses de contact <sip:AoCl> et <sip:AoC2>. Ainsi, par exemple, si ces adresses de contact correspondent à un téléphone fixe et à un téléphone mobile de l'utilisateur, ces deux téléphones vont sonner lorsqu'un correspondant saisit sur son propre terminal le numéro de téléphone IMPU3.

Selon un deuxième mode de réalisation de l'invention, on utilise

une nouvelle méthode spécifique dédiée, autre que la méthode 30 REGISTER, pour véhiculer les requêtes de gestion dynamique des

identités publiques selon l'invention.

Enfin, selon un troisième mode de réalisation, on utilise un « body XML » pour véhiculer les informations de gestion dynamique des identités publiques selon l'invention.

35 La mise en oeuvre de l'invention au sein, en particulier, de noeuds d'un réseau de télécommunications (notamment, les serveurs S-CSCF et les passerelles domestiques, d'entreprise ou d'opérateur) peut être réalisée au moyen de composants logiciels et/ou matériels.

Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de noeud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention conceme également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de gestion d'identités publiques selon l'invention.

En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé de gestion d'identités publiques selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur. Ce programme peut utiliser n'importe quel langage de programmation, et se présenter 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. L'invention vise aussi un support d'informations, inamovible, ou partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

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 clé USB (« USB flash drive » en anglais) ou un disque dur.

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 d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de gestion d'identités publiques selon l'invention.

Claims (12)

1. REVENDICATIONS1. Procédé de gestion d'identités publiques dans un réseau IMS, comprenant une étape au cours de laquelle un utilisateur envoie un message audit réseau IMS, caractérisé en ce que ledit message contient au moins un paramètre spécifique dont la signification est de demander une modification spécifique du statut d'au moins une des identités publiques de l'utilisateur, et/ou de demander une liste d'identités publiques de l'utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact (AoC1, AoC2) à laquelle cette identité publique est rattachée.
2. 2. Procédé de gestion d'identités publiques selon la revendication 1, caractérisé en ce qu'un serveur S-CSCF dudit réseau IMS renvoie audit utilisateur, en réponse audit message, une liste d'identités publiques de l'utilisateur en fonction, pour chacune de ces identités publiques, de l'adresse de contact (AoC1, AoC2) à laquelle cette identité publique est rattachée.
3. 3. Procédé de gestion d'identités publiques selon la revendication la revendication 2, caractérisé en ce que ledit serveur S-CSCF fournit également dans ladite réponse le statut de chacune des identités publiques de ladite liste.
4. 4. Procédé de gestion d'identités publiques selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit message prend la forme d'une méthode REGISTER, et en ce que ledit paramètre est inséré dans l'en-tête « Contact ».
5. 5. Procédé de gestion d'identités publiques selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit message prend la forme d'une méthode dédiée autre que la méthode REGISTER.
6. 6. Procédé de gestion d'identités publiques selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit message prend la forme d'un body XML.
7. 7. Serveur S-CSCF dans un réseau IMS, caractérisé en ce qu'il 5 comprend des moyens pour : enregistrer et mettre à jour le statut de chacune des identités publiques des utilisateurs dont il a la charge, en fonction, pour chacune de ces identités publiques, de l'adresse de contact (AoC1, AoC2) à laquelle cette identité publique est rattachée, et 10 suite à la réception d'un message de la part d'un de ces utilisateurs, prendre en compte au moins un paramètre spécifique contenu dans ledit message et dont 1a signification est de demander une modification spécifique du statut d'au moins une des identités publiques de l'utilisateur, et/ou de demander 15 une liste d'identités publiques de l'utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact (AoC1, AoC2) à laquelle cette identité publique est rattachée.
8. 8. Serveur S-CSCF selon la revendication 7, caractérisé en ce qu'il comprend en outre des moyens pour renvoyer audit utilisateur, en 20 réponse audit message, une liste d'identités publiques de l'utilisateur en fonction, pour chacune de ces identités publiques, de l'adresse de contact (AoC1, AoC2) à laquelle cette identité publique est rattachée.
9. 9. Serveur S-CSCF selon la revendication 8, caractérisé en ce qu'il comprend en outre des moyens pour foumir également dans ladite 25 réponse le statut de chacune des identités publiques de ladite liste.
10. 10. Equipement apte à envoyer un message à un réseau IMS, caractérisé en ce qu'il possède des moyens pour inclure dans ledit message un paramètre spécifique dont la signification est de demander une modification spécifique du statut d'au moins une des identitéspubliques de l'utilisateur de cet équipement, et/ou de demander une liste d'identités publiques de cet utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact (AoC1, AoC2) à laquelle cette identité publique est rattachée.
11. 11. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de gestion d'identités publiques selon l'une quelconque des revendications 1 à 6.
12. 12. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de gestion d'identités publiques selon l'une quelconque des revendications 1 à 6, lorsqu'il est exécuté sur un ordinateur.