Brevet FR2985135A1 — publié le 20130628

PROCEDE DE PROPAGATION DES ASSOCIATIONS ENTRE ADRESSES DE CONTACT ET IDENTITES PRIVEES DANS UN RESEAU IP La présente invention concerne les réseaux de type IP (« Internet 5 Protocol ») qui sont aptes à mettre en oeuvre des protocoles de contrôle 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 10 services de communication peuvent identifier des ressources physiques 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 I'IETF (Internet Engineering Task Force) ; la 15 connaissance de l'URI d'une ressource permet d'obtenir 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 d'opérateur réseau 20 (« 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 de données DSL qui 25 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 30 classiques, tels que les protocoles H.323 et SIP, utilisent des messages dits 2 9 8 5 1 3 5 2 « 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 identifiants SIP peuvent être de la forme « SIPURI » telle que définie dans la RFC 3261, ou de la forme « tel-URI » telle 15 que définie dans la RFC 3966. Une SIP-URI est de la forme « user@host » (par exemple, alice@domainel), 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_detéléphone » (par exemple, tel:+336123456789). 20 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 est défini par l'organisme de normalisation 3GPP (« 3rd Generation Partnership Project »). C'est une architecture de réseau introduite initialement pour les réseaux mobiles, puis 25 étendue à d'autres accès, dont les accès fixes à technologie xDSL. 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 30 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 divers identifiants, 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 est défini dans la spécification TS 23.228 du 3GPP. L'IMPI est un identifiant affecté de manière permanente par l'opérateur d'un réseau à une io souscription auprès de cet opérateur, et est utilisé, par exemple, pour l'enregistrement, l'autorisation d'accès, l'administration des services offerts à l'utilisateur, et la facturation (on notera qu'un utilisateur peut avoir plusieurs IMPI au sein de la même souscription ; on peut ainsi associer chaque IMPI à un terminal différent). L'IMPI a la forme d'un NAI (initiales 15 des mots anglais « Network Access Identifier » signifiant « Identifiant d'Accès Réseau »), tel que défini dans le document RFC 4282 de l'IETF. Un utilisateur se sert de son IMPU pour communiquer avec d'autres utilisateurs. L'IMPU se présente sous la forme d'une URI ou d'un numéro court, ou encore d'un alias quelconque. Pour un IMPI donné, il peut y avoir 20 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 le même identifiant (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 25 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 30 utilisateurs, les réseaux IMS comprennent un ou plusieurs serveurs, généralement appelés « S-CSCF » (initiales des mots anglais « Serving - Cali Session Control Function » signifiant « Fonction de Commande de Session d'Appel Serveuse ») ou « registrar », 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, 5 généralement appelés « I-CSCF » (initiales des mots anglais « Interrogating - Call Session Control Function » signifiant « Fonction de Commande de Session d'Appel Interrogatrice ») qui, au moment de l'enregistrement d'un terminal d'utilisateur, interrogent un serveur appelé « HSS » (initiales des mots anglais « Home Subscriber Service » signifiant « Service d'Abonné de 10 Rattachement ») pour pouvoir sélectionner un serveur S-CSCF possédant les caractéristiques requises pour atteindre le niveau de service souscrit par cet utilisateur. Les serveurs S-CSCF, mentionnés ci-dessus, contribuent à la mise en oeuvre de ces divers services en gérant le routage de la signalisation, d'une 15 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, les 20 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 25 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. 30 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 identifiants privés IMPI et publics 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 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). ro Or, en fonction des services que l'opérateur du réseau souhaite offrir, il peut souhaiter conférer aux équipements du réseau IMS (terminaux d'utilisateur, serveur de coeur de réseau, etc.) de nouvelles fonctionnalités faisant un usage plus intensif des données d'enregistrement que dans l'art antérieur. 15 La présente invention vient améliorer la situation. La présente invention vise alors un procédé de traitement de données de télécommunication comportant des données de signalisation sur un réseau IP de télécommunication, ledit procédé comprenant une étape au cours de laquelle un ensemble donné de terminaux se connecte audit réseau IP. Un 20 même identifiant public est affecté à tous les terminaux dudit ensemble, et un identifiant privé est affecté à chaque terminal de l'ensemble. Chaque terminal de l'ensemble a en outre une adresse de contact propre audit terminal permettant de contacter le terminal sur le réseau de télécommunication. Un ensemble de correspondances est enregistré au 25 sein d'un équipement de coeur de réseau, chaque correspondance de l'ensemble de correspondances mettant en correspondance l'identifiant privé d'un terminal dudit ensemble de terminaux avec une adresse de contact du terminal. Le procédé est caractérisé en ce qu'il comporte en outre une étape 30 d'émission d'un message de signalisation par l'équipement de coeur de réseau vers un équipement destinataire, ledit message de signalisation indiquant au moins une correspondance parmi ledit ensemble de correspondances. Les terminaux de l'ensemble de terminaux partagent tous le même identifiant public (par exemple, IMPU1). Bien entendu, d'autres terminaux peuvent être connectés à ce réseau sans faire partie de l'ensemble et donc sans partager l'identifiant public de l'ensemble (i.e. IMPU1). Par exemple, ces derniers peuvent avoir les identifiants publics IMPU2, IMPU3, etc. Les terminaux dudit ensemble possèdent chacun un identifiant privé, io avantageusement différents les uns des autres (par exemple, IMPI1, IMPI2, etc.), mais certains terminaux peuvent également partager le même identifiant privé. De plus, chacun de ces terminaux possède également une adresse de contact (comprenant, par exemple, l'adresse IP du terminal sur le réseau). 15 Lors de l'enregistrement d'un terminal sur le réseau (par exemple, auprès d'un serveur S-CSCF), le terminal fait notamment enregistrer la correspondance entre son adresse de contact et son identifiant privé auprès d'un équipement de coeur de réseau (par exemple, le serveur S-CSCF ou le serveur HSS décrit ci-dessus). Néanmoins, cette correspondance n'est 20 connue que d'un nombre restreint d'équipements du réseau de télécommunication. L'indication de la correspondance par le message de signalisation peut permettre à de multiples équipements réseaux de connaître les identifiants privés des terminaux connectés, de superviser leur connexion et leur 25 déconnexion indépendamment de leur adresse de contact (qui peux varier dans le temps) et de proposer de nouveaux services, comme une redirection d'appel en direction d'un terminal spécifique. De plus, le message de signalisation peut être un message émis en 30 réponse à une requête d'enregistrement ou de réenregistrement d'un terminal de l'ensemble de terminaux. Dans ce cas, ledit équipement destinataire du message est donc ce terminal. Ainsi, dès l'enregistrement d'un terminal sur le réseau, celui-ci peut disposer de la liste des identifiants privés des terminaux connectés et utilisant le même identifiant public que lui, sans avoir besoin de réaliser une nouvelle requête séparée de la requête d'enregistrement. En variante, le message de signalisation peut être un message émis en réponse à une requête d'un équipement de coeur de réseau. Dans ce cas, ledit équipement destinataire du message est donc cet équipement de coeur 10 de réseau. Comme expliqué en détail ci-dessous, cette variante peut notamment faciliter la supervision de la présence sur le réseau d'un groupe d'utilisateurs. Avantageusement, les identifiants privés desdits terminaux de l'ensemble 15 peuvent être inclus dans un entête dudit message. Les adresses de contact (des terminaux connectés et utilisant un même identifiant public) étant susceptibles d'être incluses dans l'entête des messages envoyés sur le réseau, il peut être avantageux de positionner les identifiants privés de ces terminaux également dans l'entête des messages. 20 Ce positionnement peut permettre de simplifier l'indication de la correspondance entre ces deux ensembles (ensemble d'identifiants privés et ensemble d'adresses de contact). En complément ou en variante, les identifiants privés desdits terminaux 25 de l'ensemble peuvent être inclus dans un contenu XML dudit message. Dans un mode de réalisation particulier, le procédé peut comprendre en outre une détermination préalable des données d'adresse pour lesquelles une correspondance est indiquée par le message de signalisation, cette détermination étant fonction d'au moins une règle de filtrage. En effet, il peut être souhaitable de ne pas transmettre l'ensemble des identifiants privés des terminaux connectés sur le réseau et partageant le même identifiant public, en particulier pour protéger la vie privée des utilisateurs. Certains identifiants privés peuvent donc être masqués en vertu d'une règle de filtrage. Avantageusement, la règle de filtrage peut être fonction du destinataire Io du message émis. Par exemple, il peut être utile de permettre à certains terminaux du groupe de ne connaître qu'une liste restreinte d'identifiants privés des terminaux connectés sur le réseau et partageant le même identifiant public, tandis que d'autres terminaux (terminaux administrateurs, par exemple) 15 peuvent être autorisés à connaître tous les identifiants privés sans restriction. La distinction entre les deux situations précédentes peut donc se fonder sur l'identifiant du terminal destinataire du message contenant ces identifiants privés. 20 Dans un autre mode de réalisation particulier, le message de signalisation peut indiquer lesdites correspondances au sein de l'équipement de coeur de réseau pour chaque donnée d'adresse de contact de terminaux compris dans ledit ensemble de terminaux. Ainsi, une correspondance avec un identifiant privé de terminal peut être 25 indiquée pour toutes les adresses de contact des terminaux connectés sur le réseau et partageant le même identifiant public. Cette indication de mise en correspondance peut donc être exhaustive. De plus, le réseau IP de télécommunication peut comprendre un réseau IMS. Dans ce cas, l'équipement de coeur de réseau peut notamment comprendre un serveur S-CSCF. La présente invention vise également un dispositif pour le traitement de données de télécommunication comportant des données de signalisation sur un réseau IP de télécommunication auquel est connecté un ensemble de terminaux. Un même identifiant public est affecté à tous les terminaux io dudit ensemble, et un identifiant privé étant affecté à chaque terminal de l'ensemble. Chaque terminal de l'ensemble est en outre une adresse de contact propre audit terminal permettant de contacter le terminal sur le réseau de télécommunication. Un ensemble de correspondances est enregistré au sein d'un équipement de coeur de réseau, chaque 15 correspondance de l'ensemble de correspondances mettant en correspondance l'identifiant privé d'un terminal dudit ensemble avec une adresse de contact du terminal, Le dispositif est caractérisé en ce qu'il comporte un émetteur pour l'émission d'un message de signalisation vers un équipement destinataire, 20 ledit message de signalisation indiquant au moins une correspondance parmi ledit ensemble de correspondances. La présente invention vise en outre un terminal pour le traitement de 25 données de télécommunication comportant des données de signalisation sur un réseau IP de télécommunication auquel est connecté un ensemble de terminaux, le terminal faisant partie dudit ensemble. Un même identifiant public est affecté à tous les terminaux dudit ensemble, et un identifiant privé étant affecté à chaque terminal de l'ensemble. Chaque terminal de 30 l'ensemble est en outre une adresse de contact propre audit terminal permettant de contacter le terminal sur le réseau de télécommunication. Un ensemble de correspondances est enregistré au sein d'un équipement de coeur de réseau, chaque correspondance de l'ensemble de correspondances mettant en correspondance l'identifiant privé d'un terminal dudit ensemble avec une adresse de contact du terminal, Le terminal est caractérisé en ce qu'il comporte : - un récepteur pour la réception d'un message de signalisation émis par un équipement de coeur de réseau, ledit message de signalisation indiquant au moins une correspondance parmi ledit ensemble de correspondances, et - des moyens d'affichage pour afficher des données associées aux identifiants privés du message. Les données associées aux identifiants privés du message peuvent être, 15 par exemple, un patronyme dont l'association préalable avec un identifiant privé a été effectué par l'utilisateur dans la mémoire du terminal. La présente invention vise également un programme informatique comportant des instructions pour la mise en oeuvre du procédé précédemment décrit, lorsque ce programme est exécuté par un 20 processeur. Les figures 5 et 6 décrites en détails ci-après, peuvent former l'organigramme de l'algorithme général d'un tel programme informatique. D'autres caractéristiques et avantages de l'invention apparaîtront encore 25 à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels : - la figure 1 illustre les notions d'adresse de contact, d'identifiant privé et d'identifiant public ; - la figure 2 illustre les données liées à la souscription IMS dans une 30 réalisation particulière de l'invention ; - la figure 3 illustre une organisation de données plus complexe liée à la souscription IMS ; - la figure 4 est une illustration d'une « zone de connaissance » d'un identifiant privé ; - la figure 5 est un organigramme d'un exemple de procédé au sens de l'invention exécuté par un serveur central (ou serveur de coeur de réseau), tel qu'un serveur S-CSCF ; - la figure 6 est un organigramme d'un exemple de procédé au sens de l'invention exécuté par un terminal ; - la figure 7 est une représentation d'un serveur S-CSCF apte à exécuter un procédé au sens de l'invention ; - la figure 8 est une représentation d'un terminal apte à exécuter un procédé au sens de l'invention. La figure 1 illustre les notions d'adresse de contact, d'identifiant privé et d'identifiant public dans le cadre d'un réseau de télécommunication 100 de type SIP. Le réseau de télécommunication 100 comporte trois équipements connectés : un ordinateur portable 101 et deux terminaux mobiles 102 et 103. Ces équipements 101, 102 et 103 sont configurés respectivement avec trois identifiants privés IMPI1, IMPI2 et IMPI3. Ces identifiants privés permettent notamment d'identifier (pour l'opérateur du réseau SIP) le compte client à facturer pour les services fournis. Sur le réseau de communication 100, ces équipements possèdent chacun une adresse de contact, ces adresses de contact permettant de les contacter sur le réseau. Par exemple, ces adresses de contacts comportent une adresse IP (pour « Internet Protocol » en anglais) ou un nom de domaine (par exemple « hosttdomain.com »). Dans la figure 1, les équipements 101, 102 et 103 possèdent respectivement les adresses de contact @1, en et @3. Ces adresses de contacts peuvent évoluer rapidement dans le temps, notamment en cas de changement par un 2 9 8 5 13 5 12 terminal de sous-réseau de rattachement (appelé également « roaming » en anglais). De plus, ces équipements peuvent utiliser un ou plusieurs identifiants publics. Les identifiants publics permettent d'être mis en relation avec un ou 5 plusieurs équipements, sans connaître ni leur identifiant privé, ni leur adresse de contact. Par exemple, les équipements 102 et 103 peuvent partager le même identifiant public IMPU5 tandis que l'équipement 101 possède l'identifiant public IMPU4. Si une personne demande (104) à être mis en relation avec un terminal 10 utilisant l'identifiant public IMPU5, le réseau de télécommunication 100 identifie les identifiants privés et les adresses de contacts de terminaux affectés à cet identifiant public IMPU5, c'est-à-dire, dans le cas de la figure 1, les terminaux 102 et 103. 15 La figure 2 illustre les données déclarées dans le HSS et liées à la souscription IMS 201 d'un utilisateur ayant un identifiant privé IMPI 202 (ou « Private User Identity ») et trois identifiants publics IMPU1 203 (ou « Public User Identity 1 »), IMPU2 204 (ou « Public User Identity 2 »), IMPU3 205 (ou « Public User Identity 3 »). Deux de ces identifiants publics sont 20 regroupés dans un IRS 206 (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 un identifiant public pour en enregistrer aussi implicitement une autre. Par exemple, lors de 25 l'enregistrement d'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), il peut être commode d'enregistrer de manière automatique l'un des multiples 30 identifiants publics attachés à l'IPBX pour déclarer la présence sur le réseau de l'ensemble des identifiants. L'IRS 206 contient alors l'ensemble des identifiants de l'IPBX. Il en serait de même pour l'enregistrement d'une passerelle offrant plusieurs accès. On utilise parfois un identifiant public spécifique lors de l'enregistrement d'un IRS. Cet identifiant représente généralement un utilisateur tel qu'un IPBX ou une passerelle dans son ensemble, et ne peut pas être utilisé en tant que telle à des fins de routage. On parle alors de « barred identity (mots anglais signifiant « identité non utilisable »). La figure 3 illustre, avec les mêmes conventions que la figure 1, les io données liées à la souscription IMS 301 d'un utilisateur possédant deux identifiants privés (IMPI1 302 et IMPI2 303) et six identifiants publics (IMPU1 304, IMPU2 305, IMPU3 306, IMPU4 307, IMPU5 308, et IMPU6 309), regroupés dans trois IRS (IRS1 310, IRS2 311, et IRS3 312). Les identifiants publics IMPU3 et IMPU4 sont communes aux deux 15 identifiants prives IMPI1 et IMPI2. La figure 3 montre également les profils de services associés à chacune des identifiants publics. Si, par exemple, un utilisateur enregistre un terminal configuré avec l'identifiant privé IMPI2 et l'identifiant public IMPU5, alors l'identifiant public 20 IMPU6 sera elle aussi, implicitement, enregistré. En effet, ces deux identifiants publics IMPU5 et IMPU6 appartiennent au même IRS (IRS3). L'utilisateur est donc joignable sur son terminal à la fois via son identifiant public IMPU5 et via son identifiant public IMPU6. Cet ensemble de données déclaré dans le HSS est ensuite téléchargé 25 par le S-CSCF en charge de l'utilisateur. Ce S-CSCF peut ainsi connaître l'ensemble des identifiants déclarés dans la souscription IMS, savoir quelles sont celles qui sont enregistrés implicitement, et faire le lien entre les identifiants publics et l'adresse de contact du terminal afin d'acheminer les appels entrants. De plus, le S-CSCF connaît l'état d'enregistrement de 30 chaque identifiant public. Cet état peut être « registered » (identifiant enregistré), « not registered » (identifiant non enregistré), ou encore « unregistered » (identifiant non enregistré, mais ayant néanmoins bénéficié d'un service IMS, par exemple le traitement d'un appel destiné à cet identifiant public). La figure 4 est une illustration d'une « zone de connaissance » d'un identifiant privé. Dans la figure 4, trois équipements 402, 403 et 404 sont connectés au « registrar » 400 (serveur S-CSCF). Ce dernier serveur 400 est également io interconnecté via un protocole de signalisation au serveur d'abonné nominal HSS 401 et au serveur d'applications AS 406. En outre, un serveur de proxy SIP BGCF 405 est connecté au serveur registrar 400 afin de router certains messages SIP vers un réseau externe par exemple. 15 Dans une configuration classique, lorsque le terminal 404 s'enregistre auprès du serveur S-CSCF 400, il émet une requête de la forme suivante vers le serveur S-CSCF 400 : REGISTER sip:domain SIP/2.0 To: 20 From: ;tag=regtagxx Call-Id: diagxx CSeq: 1 REGISTER WWW-Authenticate: username=+IMPI3gdomain3,... Contact: ;expires=3600 25 Il est considéré que le terminal 404 possède un identifiant privé IMPI3 et est associé à l'identifiant public IMPU1. De plus, le serveur S-CSCF 400 informe le serveur HSS 401 de cet enregistrement afin qu'une mise à jour de sa base de données puisse être effectuée. Selon l'état de l'art, les autres équipements du réseau (c'est-à-dire les 5 équipements 402, 403, 405 et 406) ne sont pas, par la suite, informés du fait que l'équipement possédant l'identifiant IMPI3 est connecté sur le réseau de communication. Dans le protocole SIP tel que défini dans le document RFC 3261, les équipements du réseau associés à un identifiant public peuvent être informés des adresses de contact des autres 10 équipements associés au même identifiant public (par exemple, contenues dans la réponse à un message d'enregistrement ou de réenregistrement d'un terminal). En effet, les réponses aux messages d'enregistrement sont de la forme : SIP/2.0 200 OK 15 To: From: ;tag=regtagxx Call-Id: diagxx CSeq: 1 REGISTER Contact: ;expires=3600 20 Contact: ;expires=2349 P-Associated-URI: P-Associated-URI: P-Associated-URI: Les champs des entêtes intitulés « Contact » comportent les adresses de 25 contact (AoC1, AoC2) des terminaux associés au même identifiant public IMPU1. Cependant il n'est pas possible, sur la base de cette simple information, de connaître quel identifiant privé et donc quel terminal ou utilisateur correspond à telle ou telle adresse de contact, et ce, d'autant moins que l'adresse de contact est susceptible d'évoluer dans le temps. Par exemple, le terminal 403 utilisant des requêtes d'enregistrement « de listage » (requêtes REGISTER sans entête Contact) pour savoir quels sont les autres terminaux connectés au réseau obtient à un instant to la liste des adresses de contact des terminaux connectés au réseau et partageant le même identifiant public que lui. Cette liste comprend deux adresses de contact : AoC1 et AoC2. Le terminal 403 obtient également à un instant ti la liste des adresses de contacts des terminaux connectés au réseau et partageant le même identifiant public que lui. Cette liste comprend alors à l'instant t1 une seule adresse de contact : AoC3. Le terminal 403 est dans l'incapacité de déterminer si l'adresse de contact AoC3 correspond à un nouveau terminal connecté sur le réseau, les deux terminaux précédents s'étant déconnectés ou bien si l'adresse de contact AoC3 correspond à un des terminaux précédemment connectés avec une des deux adresses de contact AoC1 et AoC2, l'autre terminal s'étant déconnecté. En particulier, cela peut être gênant dans un contexte d'entreprises multisites ou même dans un contexte familial si l'on désire connaître l'ensemble des terminaux connectés au réseau à un instant donné. Par exemple, un membre d'une famille recevant un appel via l'identifiant public de la famille peut souhaiter rediriger l'appel sur le terminal spécifique du père de famille. Ainsi, il a besoin de savoir si le terminal du père de famille est connecté au réseau et, le cas échéant, de pouvoir indiquer que l'appel doit être redirigé spécifiquement vers ce terminal. De même, et dans le contexte d'un centre d'appel, un responsable d'équipe peut vouloir superviser les télé-conseillers et superviser la présence de chacun à l'aide de son terminal mobile à tout instant (y compris dans le cadre d'un centre d'appel virtuel où les différents télé-conseillers ne se trouvent pas dans un même lieu physique). Cette supervision, ou d'une manière plus générale la réception d'un message de signalisation contenant une correspondance au sens de l'invention, peut être également réalisée à 2 9 8 5 1 3 5 17 l'aide d'équipements autres que des terminaux d'utilisateur, comme par exemple des serveurs de coeur de réseau (ou serveurs centraux) utilisés à des fins de supervision. Ainsi, ces équipements peuvent, par exemple, émettre régulièrement des 5 messages d'enregistrement de listage auprès du serveur S-CSCF 400 (voir ci-dessus) et analyser les réponses de ce serveur pour établir la présence ou non des équipements partageant un même identifiant public. Il est possible de prévoir que cette supervision soit réalisée par un serveur d'application AS 406. Ainsi, un récapitulatif de cette supervision io peut être fourni au travers d'une interface de type web aux utilisateurs autorisés se connectant au serveur d'application AS 406. Dans l'exemple de la figure 4, la présence du terminal IMPI3 404 sur le réseau n'est connu que du groupe (ou « zone de connaissance ») représenté par l'ensemble en pointillé 408, c'est-à-dire, le terminal lui-même 15 404, le serveur de « registrar » 400 recevant, par exemple, la requête d'enregistrement, et le HSS 401. On va décrire à présent un mode de réalisation de l'invention. Dans ce mode de réalisation, les réponses aux requêtes d'enregistrement ou de réenregistrement indiquent une correspondance 20 entre les données d'adresse contenues dans la réponse standard décrite ci-dessus et les identifiants privés des terminaux. Ainsi, les nouvelles réponses aux messages d'enregistrement peuvent être de la forme : SIP/2.0 200 OK To: 25 From: ;tag=regtagxx Call-Id: diagxx CSeq: 1 REGISTER Contact: ;expires=3600;username=+IMPI1@domain Contact: ;expires=2349;username=+IMPI2@domain Contact: ;expires=1254;username=+IMPI2@domain P-Associated-URI: P-Associated-URI: P-Associated-URI: Ainsi, les champs de l'entête « Contact » sont enrichis avec les identifiants privés des terminaux. Le terminal ayant l'adresse de contact AoC1 a comme identifiant privé IMP11. Le terminal ayant l'adresse de contact AoC2 a comme identifiant privé IMPI2. 11 est à noter que le terminal ayant l'adresse de contact AoC3 possède également le même identifiant privé que le terminal précédent, à savoir IMPI2. Au final, les terminaux associés à un identifiant public donné peuvent connaître l'ensemble des identifiants privés des terminaux connectés sur le réseau et partageant également le même identifiant public. Les messages 15 échangés entre le serveur de « registrar » et le serveur d'application AS 406 peuvent également être enrichis de cette manière. Ainsi, en référence à la figure 4, la présence du terminal IMPI3 404 sur le réseau peut être connu du nouveau groupe (ou « zone de connaissance ») représenté par l'ensemble en pointillé 409, c'est-à-dire, le terminal lui-même 20 404, le serveur de « registrar » 400 recevant, par exemple, la requête d'enregistrement, le HSS 401, mais également les autres terminaux (402 et 403) et le serveur d'application 406. Dès lors, il est possible de déporter un grand nombre de fonctionnalités (supervision des connexions, renvoi d'appel vers un terminal spécifique, etc.) auprès des équipements 25 terminaux et des serveurs centraux autres que le « regisear ». Les équipements terminaux peuvent être alors des terminaux évolués pouvant enregistrer une correspondance entre identifiants privés et patronyme (par exemple), cette correspondance enregistrée permettant, sur la base de l'indication de correspondance du message, de visualiser la liste des 30 utilisateurs connectés sur le réseau via leurs terminaux associés. La figure 5 est un organigramme d'un exemple de procédé au sens de l'invention exécuté par un serveur central tel qu'un serveur S-CSCF. Un serveur S-CSCF apte à exécuter un procédé au sens de l'invention est décrit par la figure 7. Lors de la réception d'un message d'enregistrement 700 d'un terminal par une interface 702 du serveur S-CSCF 701, ce message est transmis à un module de réponse 704. Ce module 704 extrait notamment l'identifiant public 500 du terminal de ce message 700. o Une fois extrait, il est possible de rechercher dans une mémoire 703 (par exemple, via une requête auprès du serveur central HSS du réseau IMS) la liste de l'ensemble des adresses de contact (étape 501) des terminaux connectés sur le réseau à l'instant de la recherche. De plus, en parallèle ou de manière asynchrone, il est possible de rechercher l'ensemble des 15 identifiants privés des terminaux connectés sur le réseau à l'instant de la recherche et de les mettre en correspondance avec les adresses de contact précédemment recherchées (étape 502). Le plus souvent, la mise en correspondance fait correspondre à une adresse de contact un unique identifiant privé et à un identifiant privé une unique adresse de contact. 20 Sur la base des adresses de contact correspondant aux identifiants privés des terminaux, il est possible de préparer une réponse au message reçu (étape 506) avec, par exemple, un champ dans l'entête du message préparé de manière à indiquer la correspondance entre l'adresse de contact AoCn et l'identifiant privé IMPIn@domain : 25 Contact: ;expires=3600;username=+IMPIn@domain Par ailleurs, il est également possible de filtrer certaines correspondances pour éviter que les identifiants privés de certains équipements soient transmis à un grand nombre d'autres équipements. Par exemple, il n'est pas souhaitable que les identifiants privés des hauts 30 responsables d'une entreprise soient connus des salariés de l'entreprise, 2 9 8 5 1 3 5 20 quand bien même un identifiant public commun serait partagé pour toute l'entreprise. De même, dans le cadre d'un centre d'appel dans lequel une centaine de télé-conseillers sont joignables via le même identifiant public, il n'est pas souhaitable de communiquer une centaine d'identifiants privés à 5 un terminal si le besoin est de transférer un appel à une personne disponible. Ainsi, une sélection préalable d'identifiants privés peut être réalisée en appliquant des règles de filtrages préalablement configurées. Par exemple, et de manière non limitative, ces règles peuvent être : - ne pas transmettre les identifiants privés des terminaux des io responsables d'équipes ; - transmettre seulement une sélection de dix identifiants privés sélectionnés de manière aléatoire dans la liste des terminaux non en communication ; - ne pas transmettre après 20h00 un identifiant privé donné ; 15 - transmettre seulement la liste des identifiants privés des terminaux affectés aux personnes d'une même équipe. Ces règles sont extraites de la mémoire 703 (étape 503) et un masquage des identifiants ne devant pas être transmis (conformément aux règles extraites) est réalisé (étape 504). Ce masquage peut consister dans le fait 20 de supprimer de la réponse préparée les identifiants privés devant être masqués ou bien encore dans le fait de remplacer les identifiants privés devant être masqués par des étoiles (i.e. « username :+********* », par exemple). Enfin, la réponse préparée peut être transmise au terminal ayant envoyé 25 le message 700 (étape 505), le module de réponse transmettant alors cette réponse à l'interface d'envoi 705 pour permettre son émission (message 600). La figure 6 est un organigramme d'un exemple de procédé exécuté par 30 un terminal (ou un équipement de coeur de réseau utilisé, par exemple, à des fins de supervision) sur réception d'une réponse telle que décrite dans la figure 5. Un exemple de terminal apte à exécuter un tel procédé est décrit par la figure 8. Sur réception par une interface 802 d'un terminal 801 d'une réponse 600 telle que décrite ci-dessus, cette réponse 600 est transmise à un module de traitement 803 pour permettre son analyse. Par exemple, ce module 803 peut permettre d'extraire les identifiants privés correspondant aux adresses de contact (étape 601). L'utilisateur du terminal 801 peut avoir préalablement enregistré une association entre des patronymes et des identifiants privés de terminaux au sein d'une mémoire (604 ou 804) du terminal. Par exemple, il peut avoir enregistré l'association entre : - l'identifiant privé « IMPI6544 » et le nom « M. DUPOND », - l'identifiant privé « IMPI7673 » et le nom « M. SMITH », - l'identifiant privé « IMPI8753 » et le nom « Mme. GOD ». Sur la base de cette association entre, d'une part, un patronyme et un identifiant privé et d'autre part, le contenu du message 600, il est possible de mettre en relation des patronymes avec les identifiants privés contenus dans ce message (étape 602). Ainsi, si par exemple le message comprend les identifiants privés IMPI6544, IMPI8753, « ********* » et IMPI1286, le module de traitement peut commander l'écran 805 du terminal 801 pour que celui-ci indique le nom des personnes connectées au réseau (étape 603). L'identifiant privé « ********* » correspond à un identifiant privé ayant été masqué lors de l'envoi par le registrar. Par exemple, la mention textuelle suivante peut être affichée sur l'écran 805 « M. DUPOND et Mme. GOD sont connectés au réseau. Deux autres personnes sont également connectées au réseau, mais elles ne sont pas connues ». Par ailleurs, le schéma fonctionnel présenté sur la figure 5 ou 6 est un exemple typique d'un programme dont certaines instructions peuvent être 30 réalisées auprès d'un équipement de coeur de réseau et d'autres, auprès d'un terminal d'utilisateur. A ce titre, la figure 5 ou 6 peut correspondre à 2 98513 5 22 l'organigramme de l'algorithme général d'un programme informatique au sens de l'invention. Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemples ; elle s'étend à d'autres 5 variantes. Par exemple, les messages d'enregistrement ne sont pas les seuls messages pouvant permettre l'indication de cette correspondance. Ainsi, des messages réguliers de réenregistrement ou des messages « d'enregistrement de listing » (messages sans entête 'Contact' dont le but 10 est de récupérer l'ensemble des terminaux connectés au moment de la requête et partageant le même identifiant public) peuvent permettre l'indication de cette correspondance. Par ailleurs, l'indication de la correspondance évoquée ci-dessus peut être contenue dans un entête de message comme décrit précédemment 15 mais peut également être transmise dans le corps du message, par exemple dans un contenu XML (pour « eXtensible Markup Language » en anglais) d'un message de notification relatif à la souscription au paquetage de l'état d'enregistrement « reg event » comme décrit dans le document RFC 3680. REVENDICATIONS1. Procédé de traitement de données de télécommunication comportant des données de signalisation sur un réseau IP de télécommunication, ledit procédé comprenant une étape au cours de laquelle un ensemble donné de 5 terminaux se connecte audit réseau IP, un même identifiant public étant affecté à tous les terminaux dudit ensemble, et un identifiant privé étant affecté à chaque terminal de l'ensemble, chaque terminal de l'ensemble ayant en outre une adresse de contact 10 propre audit terminal permettant de contacter le terminal sur le réseau de télécommunication, un ensemble de correspondances est enregistré au sein d'un équipement de coeur de réseau, chaque correspondance de l'ensemble de correspondances mettant en correspondance l'identifiant privé d'un terminal 15 dudit ensemble avec une adresse de contact du terminal, caractérisé en ce qu'il comporte en outre une étape d'émission d'un message de signalisation par l'équipement de coeur de réseau vers un équipement destinataire, ledit message de signalisation indiquant au moins une correspondance parmi ledit ensemble de correspondances. 20 2. Procédé selon la revendication 1, dans lequel le message de signalisation est un message émis en réponse à une requête d'enregistrement ou de réenregistrement d'un terminal dudit ensemble de terminaux. 25 3. Procédé selon la revendication 1, dans lequel le message de signalisation est un message émis en réponse à une requête d'un équipement de coeur de réseau. 4. Procédé selon l'une des revendications précédentes, dans lequel les identifiants privés desdits terminaux de l'ensemble sont inclus dans un 5 entête dudit message. 5. Procédé selon l'une des revendications précédentes, dans lequel les identifiants privés desdits terminaux de l'ensemble sont inclus dans un contenu XML dudit message. 10 6. Procédé selon l'une des revendications précédentes, dans lequel procédé comprend en outre : - une détermination préalable des données d'adresses pour lesquelles une correspondance est indiquée par le message de 15 signalisation, cette détermination étant fonction d'au moins une règle de filtrage. 7. Procédé selon l'une des revendications précédentes, dans lequel le message de signalisation indique lesdites correspondances au sein de 20 l'équipement de coeur de réseau pour chaque donnée d'adresse de contact de terminaux compris dans ledit ensemble de terminaux. 8. Procédé selon la revendication 6, dans lequel la règle de filtrage est fonction du destinataire du message émis. 25 9. Procédé selon l'une des revendications précédentes, dans lequel le réseau IP de télécommunication comprend un réseau IMS. 10. Procédé selon la revendication 9, dans lequel l'équipement de coeur de réseau comprend un serveur S-CSCF. 11. Dispositif de coeur de réseau pour le traitement de données de 5 télécommunication comportant des données de signalisation sur un réseau IP de télécommunication auquel est connecté un ensemble de terminaux, un même identifiant public étant affecté à tous les terminaux dudit ensemble, et un identifiant privé étant affecté à chaque terminal de l'ensemble, io chaque terminal de l'ensemble ayant en outre une adresse de contact propre audit terminal permettant de contacter le terminal sur le réseau de télécommunication, un ensemble de correspondances étant enregistré au sein d'un équipement de coeur de réseau, chaque correspondance de l'ensemble de 15 correspondances mettant en correspondance l'identifiant privé d'un terminal dudit ensemble avec une adresse de contact du terminal, caractérisé en ce qu'il comporte un émetteur pour l'émission d'un message de signalisation vers un équipement destinataire, ledit message de signalisation indiquant au moins une correspondance parmi ledit 20 ensemble de correspondances. 12. Terminal pour le traitement de données de télécommunication comportant des données de signalisation sur un réseau IP de télécommunication auquel est connecté un ensemble de terminaux, le 25 terminal faisant partie dudit ensemble, un même identifiant public étant affecté à tous les terminaux dudit ensemble, et un identifiant privé étant affecté à chaque terminal de l'ensemble,chaque terminal de l'ensemble ayant en outre une adresse de contact propre audit terminal permettant de contacter le terminal sur le réseau de télécommunication, un ensemble de correspondances étant enregistré au sein d'un 5 équipement de coeur de réseau, chaque correspondance de l'ensemble de correspondances mettant en correspondance l'identifiant privé d'un terminal dudit ensemble avec une adresse de contact du terminal, caractérisé en ce qu'il comporte : - un récepteur pour la réception d'un message de signalisation émis io par un équipement de coeur de réseau, ledit message de signalisation indiquant au moins une correspondance parmi ledit ensemble de correspondances, et - des moyens d'affichage pour afficher des données associées aux identifiants privés du message. 15 13. Produit programme informatique comportant des instructions pour la mise en oeuvre du procédé selon l'une des revendications 1 à 10, lorsque ce programme est exécuté par un processeur.