FR2988951A1 - Procede d'enregistrement d'un serveur aupres d'une pluralite de coeurs de reseau, et serveur. - Google Patents

Abstract

Conformément à l'invention, le procédé comprend : - une étape de réception d'une requête d'enregistrement d'un terminal (2) comportant des données d'identification génériques de ce terminal ; - une étape d'obtention, à l'aide des données génériques, de données d'enregistrement spécifiques du terminal associées à une pluralité de coeurs de réseau (CN1, CN2, CN3) aptes à fournir au terminal plusieurs services (S1, S2, S3) ; - une étape d'allocation dynamique à chacun des coeurs de réseau, d'un agent utilisateur (UA1, UA2, UA3) associé au terminal (2) ; et - une étape d'enregistrement au cours de laquelle chaque agent utilisateur envoie une requête d'enregistrement à destination du coeur de réseau auquel il est alloué, en utilisant les données d'enregistrement spécifiques associées à ce coeur de réseau, cette requête d'enregistrement contenant une adresse de contact de l'agent utilisateur.

Description

Arrière-plan de l'invention L'invention se rapporte au domaine général des télécommunications. Elle concerne plus particulièrement l'accès par un terminal à une pluralité de services de communication fournis par des coeurs de réseau monomédia ou multimédia distincts (regroupés dans la suite de la description sous l'appellation de « coeurs de réseau multimédia » par souci de simplification), tels que par exemple des coeurs de réseau de voix sur IP (ou VoIP pour Voice Over IP). L'invention a ainsi une application privilégiée mais non limitative dans le contexte de services offerts par des coeurs de réseau VoIP utilisant le protocole d'initiation de sessions SIP (Session Initiation Protocol) et s'appuyant sur une architecture IMS (IP Multimedia Subsystem). Toutefois, l'invention peut également s'appliquer à d'autres coeurs de réseau, mettant en oeuvre d'autres protocoles tels que par exemple les protocoles H323, XMPP (eXtensible Messaging Presence Protocol) ou Peer-to-Peer, ou s'appuyant sur d'autres architectures. L'évolution actuelle du marché des télécommunications (avec notamment l'arrivée de nouveaux opérateurs de télécommunications et la profusion d'offres gratuites de voix sur IP), le fait que de nombreux usagers disposent aujourd'hui d'au moins une offre multi-play sur un réseau d'accès fixe (ex. ADSL (Asymmetric Digital Subscriber Line), fibre optique, câble), et d'une ou de plusieurs offres de services sur un réseau d'accès mobile, ainsi que le développement croissant des terminaux intelligents de type smartphones ou tablettes, contraignent aujourd'hui les opérateurs de télécommunications à proposer à leurs usagers des services de communication convergents (ex. convergence fixe/mobile, convergence entre opérateurs, convergence entre réseaux à commutation de paquets (PS, Packet Switch) et réseaux à commutation de circuits (CS, Circuit Switch), etc.). De tels services convergents peuvent être proposés à un usager par l'intermédiaire d'applications ou de logiciels, aussi connu(e)s sous le nom de « softphones », téléchargeables ou préinstallées sur son terminal. Ces applications sont par exemple : - des applications proposant un service RCS (Rich Communication Suite) ou RCS-e (Rich Communication Suite enhanced) défini par le GSMA (GSM Association) et s'appuyant sur les standard 3GPP (Third Generation Partnership Project), permettant aux usagers de terminaux mobiles de disposer d'un répertoire enrichi sur leurs terminaux (présence des contacts, partage de fichiers/photos/vidéos en parallèle d'une communication téléphonique de type circuit, etc.), - des applications permettant à un usager d'utiliser son compte sur le réseau fixe lorsque son terminal mobile est connecté en WiFi® (Wireless Fidelity) derrière sa passerelle résidentielle ou à un point d'accès public, - des applications permettant à un usager d'utiliser l'identité publique de son terminal mobile (ex. son numéro de téléphone mobile) pour les services (ex. : appels voix, appels vidéo, messages) dont il est à l'origine, ou - des applications offrant à un usager la possibilité de configurer un ensemble (ou communauté) de numéros privilégiés (par exemple avec lesquels les appels sont gratuits), de connaître la disponibilité ou la présence de ces numéros et de mettre en place des services tels que par exemple un service de messagerie instantanée avec ces numéros.

Dans la configuration actuelle des réseaux, ces services convergents sont gérés par des serveurs d'application hébergés par des coeurs de réseaux VoIP distincts (opérés par le même opérateur ou par des opérateurs distincts). Il convient d'ailleurs de noter, qu'en dépit des contributions du standard 3GPP à la définition d'un coeur de réseau IMS unique gérant l'ensemble des services fixes/mobiles offerts par différents opérateurs, cette configuration restera une réalité pour de nombreuses années à venir. Ainsi, lorsqu'un usager d'un terminal souhaite accéder à n services distincts, il est nécessaire de télécharger, de configurer et de maintenir à jour sur ce terminal, n applications softphones distinctes correspondant respectivement à ces n services, ces n applications devant s'enregistrer auprès de coeurs de réseaux VoIP pouvant être distincts.

Du point de vue de l'usager du terminal, cela se traduit par le lancement de n applications sur le terminal, chaque application étant configurée avec des données d'enregistrement spécifiques et instanciant sa propre pile SIP pour pouvoir s'enregistrer auprès du coeur de réseau VoIP associé au service qu'elle propose. L'usager est donc amener à gérer n sessions multimédia établies en parallèle sur son terminal (une session en premier plan et n-1 sessions en arrière-plan). Autrement dit, la solution actuelle proposée à un usager pour accéder à n services de communication fournis par différents coeurs de réseau multimédia est particulièrement complexe pour l'usager et difficile à gérer.

Objet et résumé de l'invention L'invention permet de pallier cet inconvénient en proposant un procédé d'enregistrement d'un serveur auprès d'une pluralité de coeurs de réseau multimédia, chaque coeur de réseau étant apte à fournir à un terminal au moins un service, ce procédé d'enregistrement comprenant une étape de réception d'une requête d'enregistrement du terminal comportant des données d'identification dites génériques de ce terminal ; une étape d'obtention, à l'aide de ces données d'identification génériques, de données d'enregistrement dites spécifiques du terminal associées aux coeurs de réseau multimédia ; une étape d'allocation dynamique, à chacun des coeurs de réseau, d'un agent utilisateur associé au terminal et apte à communiquer avec ce coeur de réseau ; et une étape d'enregistrement au cours de laquelle chaque agent utilisateur envoie une requête d'enregistrement à destination du coeur de réseau auquel il est alloué, en utilisant les données d'enregistrement spécifiques associées à ce coeur de réseau obtenues au cours de l'étape d'obtention, cette requête d'enregistrement contenant une adresse de contact de l'agent utilisateur. Corrélativement, l'invention vise également un serveur apte à s'enregistrer auprès d'une pluralité de coeurs de réseau multimédia, chaque coeur de réseau étant apte à fournir à un terminal au moins un service, ce serveur comprenant : - des moyens de réception d'une requête d'enregistrement du terminal comportant des données d'identification dites génériques de ce terminal ; - des moyens d'obtention, à l'aide de ces données d'identification génériques, de données d'enregistrement dites spécifiques du terminal associées aux coeurs de réseau multimédia ; - des moyens d'allocation dynamique, à chacun des coeurs de réseau, d'un agent utilisateur associé au terminal et apte à communiquer avec ce coeur de réseau ; et - des moyens d'enregistrement aptes à déclencher l'envoi par chaque agent utilisateur d'une requête d'enregistrement à destination du coeur de réseau auquel il est alloué, utilisant les données d'enregistrement spécifiques associées à ce coeur de réseau obtenues par les moyens d'obtention, cette requête d'enregistrement contenant une adresse de contact de l'agent utilisateur. Par agent utilisateur alloué à un coeur de réseau, on entend ici une pile protocolaire conforme au protocole d'initiation de sessions mis en oeuvre par ce coeur de réseau. Ainsi, par exemple, si le coeur de réseau met en oeuvre le protocole d'initiation de sessions SIP, l'agent utilisateur est une pile SIP aussi connue sous le nom d'agent utilisateur. L'invention propose donc un enregistrement du terminal auprès de la pluralité de coeurs de réseau multimédia en deux temps : - dans un premier temps, le terminal, via par exemple une application dédiée lancée par l'utilisateur, s'enregistre à l'aide de données d'identification génériques du terminal auprès d'un serveur ; - puis, dans un second temps, ce serveur s'enregistre pour le compte du terminal auprès des différents coeurs de réseau, par l'intermédiaire d'une pluralité d'agents utilisateurs associés à ce terminal et alloués à ces coeurs de réseau. Ces différents enregistrements sont réalisés à l'aide de données d'enregistrement du terminal spécifiques à chaque service offert par ces coeurs de réseau, et associées au niveau du serveur ou d'une base de données avec laquelle peut communiquer le serveur, aux données d'identification génériques reçues du terminal. Les données d'enregistrement spécifiques, utilisées par chaque agent utilisateur alloué à un coeur de réseau, comprennent : - d'une part, les données d'identification (ex. identité, mot de passe, etc.) provisionnées lors de la souscription de l'usager du terminal au service offert par ce coeur de réseau, et - d'autre part, une information de joignabilité, incluant par exemple un nom de domaine et/ou une adresse de contact, cette information de joignabilité définissant un chemin de signalisation jusqu'au serveur d'enregistrement du coeur de réseau ou jusqu'à une entité du coeur de réseau participant à la fourniture du service. Les données d'identification spécifiques s'appuient par conséquent sur des « données réelles » telles qu'un numéro de téléphone public du terminal et/ou une identité privée connue du coeur de réseau, qui proviennent de données échangées entre l'usager du terminal et le ou les opérateurs des coeurs de réseau lors de la souscription de l'usager aux services. En revanche, les données d'identification génériques échangées entre le terminal et le serveur peuvent s'appuyer soit sur des données réelles comme les données d'identification spécifiques, soit sur des « données virtuelles » c'est-à-dire, créées uniquement pour les besoins de l'enregistrement du terminal auprès du serveur conformément à l'invention. Ces données d'identification génériques peuvent en effet ne correspondre à aucune donnée réelle échangée entre l'usager du terminal et les coeurs de réseau, dès lors que le serveur, conformément à l'invention, joue le rôle d'intermédiaire entre le terminal et les coeurs de réseau offrant les services. Il convient de noter qu'en fonction des protocoles d'initiation de session mis en oeuvre par les coeurs de réseau, un agent utilisateur peut être associé à un terminal unique ou en variante un même agent utilisateur peut être associé à plusieurs terminaux. Par ailleurs, les agents utilisateurs alloués au cours de l'invention peuvent être instanciés lors de l'étape d'allocation ou au cours d'une étape mise en oeuvre au préalable (notamment lorsque le serveur est situé dans un équipement d'un des coeurs de réseau).

Ainsi, grâce à l'invention, l'usager du terminal n'a besoin de déclencher qu'une seule application pour accéder à différents services offerts par des coeurs de réseau distincts, cette application étant de plus configurée selon un unique compte « générique » du terminal (associé aux données d'identification génériques du terminal utilisées pour s'enregistrer auprès du serveur). L'expérience de l'usager pour accéder aux différents services hébergés par les coeurs de réseau est donc grandement facilitée par la mise en oeuvre de l'invention. Dans un mode préféré de réalisation de l'invention, le serveur est situé dans un équipement d'un réseau de télécommunications auquel est connecté le terminal. Cet équipement est par exemple un serveur dédié du réseau d'accès aux services ou un point d'entrée d'un coeur de réseau gérant le terminal, tel que par exemple un serveur P-CSCF (Proxy-Call Session Control Function) pour un coeur de réseau s'appuyant sur une architecture IMS, de sorte que le serveur se trouve préférentiellement en coupure de flux de la signalisation échangée entre le terminal et les coeurs de réseau dans le cadre des services offerts par ces coeurs de réseau. Dans ce mode de réalisation de l'invention, le terminal est configuré avec une application unique pour accéder à la pluralité de services offerts par les différents coeurs de réseau, tandis que les multiples enregistrements requis auprès de ces différents coeurs de réseau sont gérés côté réseau. L'application configurée sur le terminal peut être avantageusement téléchargée depuis un serveur unique (soit à l'initiative de l'usager soit à l'initiative de l'opérateur de l'usager), ou être préinstallée par l'opérateur sur le terminal avant sa commercialisation, ce qui simplifie à la fois l'offre de services de l'opérateur et l'accès à ces services par l'usager du terminal. L'expérience de l'usager est ainsi encore améliorée. En outre, les divers agents utilisateurs alloués pour s'enregistrer au nom du terminal auprès des différents coeurs de réseau n'étant pas gérés par le terminal lui-même, il s'ensuit une économie substantielle en termes de ressources du terminal, et notamment en termes de batterie. On observe également une simplification de la gestion de l'accès aux services pour l'opérateur du réseau auquel est connecté le terminal. En effet, le déploiement de ce serveur, son utilisation et sa maintenance est gérée directement par l'opérateur du réseau d'accès aux services.

Une telle gestion est plus simple pour l'opérateur que la mise en place d'une intervention sur le terminal de l'usager directement. Elle ne nécessite pas en outre de développement d'un serveur spécifique au terminal de l'usager. L'opérateur peut donc offrir une meilleure disponibilité de service à l'usager tout en limitant ses coûts de production et de maintenance. Dans un autre mode de réalisation de l'invention, le serveur est situé sur le terminal.

L'envoi de la requête d'enregistrement du terminal au serveur est alors un processus interne au terminal, géré via deux applications distinctes, à savoir l'application unique visible de l'usager qui s'enregistre à l'aide de données génériques et le serveur, dont la configuration et le fonctionnement sont cachés à l'usager du terminal et qui interagit avec les coeurs de réseau. Dans un mode particulier de réalisation, le procédé d'enregistrement selon l'invention comprend en outre : - une étape d'authentification du terminal par le serveur ; et - une étape d'authentification de chaque agent utilisateur auprès du coeur de réseau auquel il est alloué. L'authentification du terminal par le serveur peut se faire avantageusement à l'aide des données d'identification génériques associées au terminal et les étapes d'authentification des différents agents utilisateurs à l'aide des données d'identification spécifiques associées à chaque service. Ces étapes permettent de garantir la sécurité de l'accès aux services par le terminal. Dans une variante de réalisation, le procédé comprend en outre, si le serveur n'a pas reçu de requête de réenregistrement du terminal à l'issue d'une période de temps prédéterminée, une étape d'envoi, par chaque agent utilisateur, d'une requête de désenregistrement auprès du coeur de réseau auquel il est alloué. La non-réception de la requête de réenregistrement du terminal par le serveur peut être due à diverses raisons, comme notamment à une extinction inopinée du terminal ou à une perte de connexion réseau du terminal. Cette variante de réalisation permet de fermer proprement les contextes d'enregistrement associés aux différents agents utilisateur sur les coeurs de réseau et de libérer les ressources relatives à ces contextes d'enregistrement. On optimise ainsi les ressources des coeurs de réseau en évitant notamment un trafic inutile sur le réseau liés à la retransmission de messages due à une absence de réponse à ces messages. Dans une autre variante de réalisation, le procédé comprend en outre, si le serveur n'a pas reçu de requête de réenregistrement du terminal à l'issue d'une période de temps prédéterminée, une étape d'envoi périodique, par chaque agent utilisateur, d'une requête de réenregistrement auprès du coeur de réseau auquel il est alloué. Cette variante permet d'optimiser les performances des coeurs de réseau, en anticipant un réenregistrement du terminal dans un bref délai après la période de temps prédéterminée : on évite ainsi l'émission de codes d'erreur par les coeurs de réseau du fait de la non réception d'une requête de réenregistrement du terminal durant la période de temps prédéterminée. En d'autres mots, cette variante de réalisation permet de masquer aux coeurs de réseau les changements d'état « indus » du terminal se manifestant sur une période de temps relativement courte (« indus » dans le sens où ces changements ne sont pas souhaités par le terminal ou par son utilisateur, ou sont indépendants de sa volonté). Un tel changement d'état peut être dû par exemple à une perte momentanée de connectivité IP par le terminal. Dans un mode particulier de réalisation de l'invention dans lequel le serveur est situé sur un équipement d'un réseau auquel est connecté le terminal : - la requête d'enregistrement du terminal est associée à une première période d'expiration de l'enregistrement ; et - au moins une requête d'enregistrement d'un agent utilisateur envoyée au cours de l'étape d'enregistrement est associée à une deuxième période d'expiration de l'enregistrement supérieure à la première période d'expiration. De façon connue, lors de l'enregistrement d'un terminal auprès d'un réseau, une période d'expiration de cet enregistrement lui est allouée, qui est usuellement limitée par les contraintes du réseau d'accès utilisé par le terminal pour se connecter au réseau. Ainsi par exemple, il est nécessaire au niveau de certains équipements du réseau, de générer du trafic sur le réseau afin de maintenir à jour des tables de liaison (telles que par exemple des tables ARP Address Resolution Protocol) ou des tables de liaison NAT (Binding NAT (Network Address Translation)) : pour ce faire, des périodes d'expiration d'enregistrement relativement faibles (ex. 2 minutes pour la traduction d'adresses NAT UDP (User Datagram Protocol), 15 minutes pour les tables ARP) sont généralement allouées lors de l'enregistrement du terminal. En revanche, ces contraintes ne sont plus présentes pour l'enregistrement des agents utilisateurs auprès des différents coeurs de réseau lorsque le serveur de l'invention se trouve dans le réseau d'accès aux services (les enregistrements se font en effet via des communications entre coeurs de réseaux directement). Ce mode de réalisation est donc particulièrement avantageux car il permet de limiter les (ré)enregistrements des agents utilisateurs auprès des coeurs de réseau en leur attribuant une période d'expiration d'enregistrement plus longue. Or, ces réenregistrements occupent une charge importante du réseau. Ce mode de réalisation permet donc d'économiser les ressources des coeurs de réseau, qui peuvent en corollaire supporter beaucoup plus de clients. Dans un mode privilégié de réalisation de l'invention : le terminal, le serveur et les coeurs de réseau multimédia mettent en oeuvre le protocole d'initiation de session SIP ; et les agents utilisateurs alloués par le serveur sont des agents utilisateurs SIP. Toutefois, l'invention s'applique à d'autres contextes. Ainsi, seulement certains des coeurs de réseau multimédia peuvent mettre en oeuvre le protocole d'initiation de session SIP, tandis que les autres coeurs de réseau peuvent mettre en oeuvre d'autres protocoles d'initiation de session, tels que par exemple des protocoles propriétaires ou les protocoles XMPP, Peer2Peer, etc. Par ailleurs, un protocole distinct peut être mis en oeuvre entre d'une part le terminal et le serveur et d'autre part, entre le serveur et l'un au moins des coeurs de réseau fournissant un service. Par exemple, le protocole SIP peut être utilisé entre le terminal et le serveur, de même qu'entre le serveur et un premier coeur de réseau, tandis qu'un autre protocole tel que par exemple un protocole H323, peut être utilisé entre le serveur et un second coeur de réseau. Selon un autre aspect, l'invention vise également un procédé de traitement de messages par un serveur, suite à l'enregistrement de ce serveur auprès d'une pluralité de coeurs de réseau multimédia aptes à fournir au moins un service à un terminal, cet enregistrement étant conforme à un procédé d'enregistrement selon l'invention, le procédé de traitement de messages comprenant : une étape de réception d'un message en provenance du terminal ; une étape d'identification, à partir d'un type de ce message et/ou d'au moins un champ de ce message, d'au moins un coeur de réseau pour traiter ce message parmi la pluralité de coeurs de réseau ; et - une étape de routage vers le coeur de réseau identifié, par l'agent utilisateur alloué à ce coeur de réseau, d'un message dérivé du message reçu contenant une adresse de contact de l'agent utilisateur. Corrélativement, le serveur selon l'invention comprend en outre : des moyens de réception d'un message en provenance du terminal ; - des moyens d'identification, à partir du type de message et/ou d'au moins un champ du message, d'au moins un coeur de réseau pour traiter ce message parmi la pluralité de coeurs de réseau ; et - des moyens déclenchant le routage vers ce coeur de réseau par l'agent utilisateur alloué à ce coeur de réseau, d'un message dérivé du message reçu et contenant une adresse de contact de l'agent utilisateur. Par message dérivé du message reçu, on entend au sens de l'invention un message obtenu à partir du message reçu. Ainsi, il peut s'agir aussi bien d'un message identique ou similaire au message reçu aux ajouts, substitutions et suppressions de champs et/ou d'entêtes près effectués par le serveur, que d'un message résultant d'une fonction de conversion protocolaire appliquée au message reçu, lorsque des protocoles de communication distincts sont utilisés entre le terminal et le serveur d'une part, et entre le serveur et au moins l'un des coeurs de réseau identifiés pour traiter le message reçu d'autre part. Une telle fonction de conversion protocolaire est connue en soi. Ainsi, selon cet aspect de l'invention, le serveur gère non seulement l'enregistrement du terminal auprès des différents coeurs de réseau offrant les services multimédia, mais également l'accès à proprement parler à ces services par le terminal, en routant les messages émis par le terminal vers les coeurs de réseau aptes à traiter ces messages. L'identification du ou des coeurs de réseau aptes à traiter les messages reçus du terminal peut être réalisée sur la base de différents critères préétablis, s'appuyant notamment sur le type des messages reçus du terminal et/ou au moins un champ de ces messages. On notera que l'invention ne se limite pas à des critères définis à partir du type de message reçu et/ou d'un ou de plusieurs champ(s) de ce message. On peut également prendre en compte d'autres informations en plus de ces éléments pour router le message comme par exemple, une information de congestion d'un des coeurs de réseau susceptibles de traiter le message, des préférences utilisateurs, etc. Le routage mis en oeuvre conformément à l'invention est ainsi très flexible, et permet de prendre en compte aussi bien des contraintes ou des préférences opérateurs (congestion, politique d'équilibre de la charge ou « load balancing », commodités de facturation, etc.) que des contraintes ou des préférences liées à l'usager du terminal. Par exemple, ledit au moins un champ du message considéré lors de l'étape de routage peut être choisi parmi : un champ représentatif des services supportés par le terminal ou des capacités du terminal ; un champ représentatif d'un type de média négocié par le terminal ; un champ représentatif d'un événement auquel souscrit le terminal ; un champ représentatif d'un identifiant d'origine du message ; un champ représentatif d'un agent utilisateur du terminal ; - un champ représentatif d'un destinataire du message. Plus précisément, lorsque le message reçu en provenance du terminal est un message SIP, ledit au moins un champ du message peut être choisi parmi : - un champ « tag feature» ou « tag » présent dans une adresse de contact du message (ex. pour un routage en fonction des services identifiés dans le message) ; un champ Contact-Address (ex. pour un routage selon le nom de domaine, l'adresse IP, le protocole de transport,...) un champ Accept-Contact ; un champ P_Preferred_Identity (pour un routage en fonction de l'origine du message) ; un champ User-Agent ; un champ R-URI ; un champ « event package » ou « event » ; un champ FROM (ex. pour un routage en fonction de l'identifiant d'origine du message) ; un champ Subject ; un champ TO (ex. pour un routage en fonction du destinataire du message) ; un champ Message Body (ex. application/SDP ou Message/CPIM) ou un champ inclus dans un champ Message Body (ex. dans un champ application/SDP ou dans un champ Message/CPIM) (ex. pour un routage en fonction du type de média négocié dans le message).

Bien entendu, cette liste n'est pas exhaustive et d'autres champs du message (déjà définis dans le protocole SIP ou susceptibles d'être normalisés dans le cadre du protocole SIP) peuvent être pris en compte pour router le message vers l'un ou vers des coeurs de réseau. Dans un mode particulier de réalisation, le procédé de traitement selon l'invention comprend en outre : - une étape de réception, par un agent utilisateur alloué par le serveur à un coeur de réseau multimédia, d'un message en provenance de ce coeur de réseau ; et une étape de routage vers le terminal d'un message dérivé du message reçu. Le procédé de traitement selon l'invention comprend ainsi le traitement des messages émis par et/ou destinés au terminal.

Autrement dit, le serveur se trouve en coupure de flux de la signalisation et de messages échangés entre le terminal et les coeurs de réseau pour l'accès aux services offerts par ces coeurs de réseau. L'invention n'exclut toutefois pas que certains types de communications ou de sessions puissent être mis en oeuvre dans le cadre d'un service directement entre le terminal et le coeur de réseau fournissant ce service, telles que par exemple des sessions média.

Dans un mode particulier de réalisation, le procédé de traitement selon l'invention comprend en outre : - avant l'étape de routage vers au moins un coeur de réseau identifié, une étape de conversion du message reçu du terminal en un message conforme à un protocole de communication mis en oeuvre par ce coeur de réseau ; et/ou - avant l'étape de routage vers le terminal, une étape de conversion d'au moins un message reçu d'un coeur de réseau en un message conforme à un protocole de communication mis en oeuvre par le terminal. Ce mode de réalisation permet de gérer les situations où le protocole d'initiation de sessions utilisé entre le terminal et le serveur est différent du protocole d'initiation de sessions utilisé par l'un au moins des coeurs de réseau. Dans un autre mode de réalisation de l'invention, le procédé de traitement comprend en outre, sur réception du message en provenance du coeur de réseau : - une étape de détection au cours de laquelle le serveur détermine si une session est déjà établie entre le terminal et un coeur de réseau de la pluralité de coeurs de réseau ; et - si une session est déjà établie, une étape de vérification que le message reçu est compatible avec cette session, l'étape de routage n'étant mise en oeuvre que lorsque le message reçu est compatible avec la session établie. Par message compatible avec une session établie, on entend ici, un message qui n'interrompt pas ni ne perturbe le déroulement de cette session s'il est routé vers le terminal. Ce mode de réalisation permet donc en outre d'assurer une cohérence entre les services auxquels accède le terminal via le serveur : le serveur s'assure que les messages échangés dans le cadre de ces services ne sont pas incompatibles. Ainsi par exemple, si un premier message SIP INVITE provenant d'un premier coeur de réseau est routé vers le terminal, puis un second message SIP INVITE provenant d'un second coeur de réseau arrive au niveau du serveur selon l'invention, celui-ci peut s'assurer, avant de router le second message SIP INVITE vers le terminal, que le double appel est supporté par le terminal. Dans le cas contraire, autrement dit lorsque le second message SIP INVITE est incompatible avec la session établie avec le premier coeur de réseau (en relation avec le premier message INVITE), le second message SIP INVITE n'est pas transmis au terminal. En revanche, si le second message est un message SIP OPTIONS, auquel le terminal peut répondre de façon transparente pour les sessions en cours, autrement dit si le second message SIP OPTIONS est compatible avec la session établie en relation avec le premier message INVITE, le serveur peut router ce message SIP OPTIONS vers le terminal. Selon un autre aspect, l'invention vise également un procédé d'accès par un terminal à une pluralité de services offerts par des coeurs de réseau multimédia distincts, ce procédé comprenant : - une étape d'obtention par le terminal de données d'identification dites génériques du terminal et d'une information de joignabilité d'un serveur ; - une étape d'enregistrement auprès du serveur pour accéder à la pluralité de services, cette étape d'enregistrement comprenant l'envoi d'une requête d'enregistrement au serveur en utilisant l'information de joignabilité dudit serveur, cette requête comprenant les données d'identification génériques ; et - au moins une étape d'envoi au serveur d'au moins un message, ledit au moins un message étant associé aux services offerts par les coeurs de réseau multimédia, et le type dudit au moins un message et/ou au moins un champ dudit au moins un message permettant au serveur de router ledit au moins un message vers le ou les coeurs de réseau multimédia offrant le ou les services associés audit au moins un message. Corrélativement, l'invention vise aussi un terminal comprenant : des moyens d'obtention de données d'identification dites génériques du terminal et d'une information de joignabilité d'un serveur ; - des moyens d'enregistrement auprès du serveur pour accéder à une pluralité de services offerts par des coeurs de réseau multimédia distincts, ces moyens d'enregistrement étant aptes à utiliser l'information de joignabilité dudit serveur pour envoyer une requête d'enregistrement audit serveur, ladite requête comprenant lesdites données d'identification génériques ; et - des moyens d'envoi au serveur d'au moins un message, ledit au moins un message étant associé aux services offerts par les coeurs de réseau multimédia, et le type dudit au moins un message et/ou au moins un champ dudit au moins un message permettant au serveur de router ledit au moins un message vers le ou les coeurs de réseau multimédia offrant le ou les services associés audit au moins un message.

Ainsi, le terminal selon l'invention est remarquable en ce qu'il envoie des messages relatifs à des services offerts par des coeurs de réseau distincts à un seul et unique serveur, qui gère pour le compte du terminal les échanges avec ces différents coeurs de réseau. D'un point de vue de l'usager et du terminal, grâce au serveur de l'invention, c'est comme si un unique coeur de réseau offrait ces différents services au terminal.

Selon un autre aspect encore, l'invention vise un système de communications comprenant : - une pluralité de coeurs de réseau distincts, chaque coeur de réseau offrant au moins un service ; un terminal selon l'invention ; et un serveur selon l'invention, permettant au terminal d'accéder aux services offerts par les coeurs de réseau. Le procédé d'accès, le terminal et le système selon l'invention disposent des mêmes avantages que ceux cités précédemment pour le procédé d'enregistrement, le procédé de traitement et le serveur selon l'invention.

Dans un mode particulier de réalisation, les différentes étapes du procédé d'enregistrement, du procédé de traitement et du procédé d'accès sont déterminées par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un serveur ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé d'enregistrement ou d'un procédé de traitement tels que décrits ci-dessus. L'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre dans un terminal ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes d'un procédé d'accès à une pluralité de services tel que décrit ci-dessus. Ces programmes peuvent utiliser n'importe quel langage de programmation, et être sous la forme d'un code source, d'un code objet, ou d'un 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 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 disquette (floppy disc) 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 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 programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. On peut également envisager, dans d'autres modes de réalisation, que le procédé d'enregistrement, le procédé de traitement, le procédé d'accès à une pluralité de services, le serveur, le terminal et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.

Brève description des dessins D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : - la figure 1 représente, de façon schématique, un système de communication, un terminal et un serveur selon l'invention, dans un mode particulier de réalisation ; - les figures 2A et 2B représentent de façon schématique, l'architecture matérielle du terminal et du serveur de la figure 1 ; - la figure 3 représente, sous forme d'ordinogramme, les principales étapes d'un procédé d'accès à une pluralité de services conforme à l'invention, dans un mode particulier de réalisation dans lequel il est mis en oeuvre par le terminal de la figure 1 ; - la figure 4 représente, sous forme d'ordinogramme, les principales étapes d'un procédé d'enregistrement conforme à l'invention, dans un mode particulier de réalisation dans lequel il est mis en oeuvre par le serveur de la figure 1 ; - la figure 5 illustre un exemple de messages pouvant être échangés au sein du système de communication de la figure 1 lors de la mise en oeuvre du procédé d'enregistrement représenté à la figure 4 ; - les figures 6 et 7 représentent, sous forme d'ordinogramme, les principales étapes d'un procédé de traitement conforme à l'invention, dans un mode particulier de réalisation dans lequel il est mis en oeuvre par le serveur de la figure 1 pour le traitement d'un message en provenance du terminal ou destiné au terminal ; et - les figures 8-11 illustrent des exemples de messages SIP traités par le serveur de la figure 1 conformément à l'invention. Description détaillée d'un mode de réalisation La figure 1 représente, dans son environnement, un système 1 de communications conforme à l'invention, dans un mode particulier de réalisation. Conformément à l'invention, le système 1 comprend : une pluralité de coeurs de réseau distincts CN1, CN2, CN3, chaque coeur de réseau offrant au moins un service, noté S1, S2, S3 respectivement ; un terminal 2 conforme à l'invention ; et - un serveur 3 conforme à l'invention et permettant au terminal 2 d'accéder aux services S1, S2 et S3 offerts par les coeurs de réseau CN1, CN2 et CN3. Les services Si, S2 et S3 offerts par les coeurs de réseau CN1, CN2 et CN3 sont par exemple ici : - S1 : un service RCS-e tel que défini dans le document 3GPP intitulé « RCS-e Advanced Communications: Services and client spécification », version 1.1, 8 avril 2011 ; - S2 : un service de voix sur IP fixe ; et - S3 : un service de voix dit « communautaire », basé sur la configuration d'un ensemble de numéros privilégiés avec lesquels diverses facilités de communication multimédia sont offertes (appels gratuits, présence/disponibilité, messagerie instantanée, etc.).

On suppose que l'usager du terminal 2 a souscrit à ces trois services 51, S2 et S3. Dans le mode de réalisation décrit ici, les coeurs de réseaux CN1, CN2 et CN3 s'appuient sur une architecture IMS et mettent en oeuvre le protocole SIP d'initiation de sessions. Par ailleurs, on suppose que le terminal 2 et le serveur 3 implémentent également le protocole SIP, de sorte que les échanges entre le terminal 2, le serveur 3 et les coeurs de réseaux CN1, CN2 et CN3 sont mis en oeuvre conformément à ce protocole. Le protocole SIP est défini en détails dans le document RFC 3261 édité par le standard IETF (Internet Engineering Task Force) et intitulé « SIP: Session Initiation Protocol », Juin 2002. Cette hypothèse n'est toutefois pas limitative, l'invention peut s'appuyer sur d'autres protocoles, tels que par exemple le protocole XMPP, Peer-to-Peer, H323, ainsi que sur d'autres architectures de coeurs de réseau. Par ailleurs, l'invention s'applique également lorsqu'un ou plusieurs coeurs de réseau parmi les coeurs de réseau CN1, CN2 et CN3, et/ou le serveur 3 et/ou le terminal 2 implémentent des protocoles distincts les uns des autres, moyennant la mise en oeuvre de fonctions de conversions protocolaires connues de l'homme du métier et non détaillées ici. En outre, dans l'exemple représenté à la figure 1, on envisage trois coeurs de réseaux distincts offrant les services S1, S2 et S3 cités précédemment. L'invention s'applique bien entendu à une configuration différente du système 1 (i.e. nombre de coeurs de réseau différent, services différents, plusieurs services gérés par un même coeur de réseau, etc.), en fonction des offres de services auxquelles a souscrit l'usager du terminal 2. Le terminal 2 est ici un terminal multimédia quelconque. Il peut s'agir par exemple d'un téléphone intelligent ou smartphone, d'une tablette numérique, d'un ordinateur portable, etc.

Il dispose de l'architecture matérielle d'un ordinateur, telle que représentée à la figure 2A. Ainsi, le terminal 2 comporte notamment un processeur 2A, des moyens de communication 2B mettant en oeuvre le protocole SIP, une mémoire vive 2C, et une mémoire morte 2D. La mémoire morte 2D constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 2A et sur lequel est enregistré un programme d'ordinateur conforme à l'invention. Ce programme d'ordinateur se présente ici sous la forme d'une application softphone, qui peut être téléchargée via un serveur web notamment, ou bien avoir été préinstallée sur le terminal avant sa commercialisation, de façon connue en soi. Cette application softphone intègre les instructions nécessaires à l'exécution de la logique des services S1, S2 et S3 (i.e., instructions pour la découverte des capacités/état du distant via l'envoi d'un message SIP OPTIONS, gestion des automates d'envoi et de réceptions de messages IM ou d'appels téléphoniques, etc.), et comporte en outre des instructions pour l'exécution des étapes d'un procédé d'accès à une pluralité de services selon l'invention décrites ultérieurement en référence à la figure 3.

Par ailleurs, cette application est configurée avec un compte générique associé au terminal 2, qui comprend des données d'identification « génériques » du terminal 2, ainsi qu'une information de joignabilité du serveur 3 en charge de l'enregistrement du terminal 2, permettant de définir le chemin de signalisation jusqu'au serveur 3. Cette information de joignabilité est constituée ici du nom du domaine auquel est associé le serveur 3 et d'une adresse de contact AoCServer3 de ce serveur 3. De façon connue, l'adresse de contact d'un dispositif dans le domaine IP comprend notamment l'adresse IP du dispositif, un numéro de port associé à sa pile protocolaire (pile SIP ici), ainsi que le protocole de transport (ex. UDP (User Data Protocol), TCP (Transport Control Protocol), TLS (Transport Layer Security)) utilisé par le dispositif pour communiquer.

En variante, pour d'autres protocoles que le protocole SIP, l'information de joignabilité peut n'être constituée que d'une adresse de contact. Dans l'exemple envisagé ici, les données d'identification génériques du terminal 2 associées au compte générique comprennent une identité publique ou IMPU (IP Multimedia PUblic identity) fixe notée IMPUfixe2, une identité publique ou IMPU mobile notée IMPUmob2, une identité privée ou IMPI (IP Multimedia Private Identity) notée IMPI2, et un mot de passe, noté GenPwd2.

Par souci de simplification dans la suite de la description, on regroupera sous la notation IMPU2 les identités publiques mobile et fixe du terminal 2 (IMPUmob2 et IMPUfixe2), lorsque l'une ou l'autre de ces identités peut être utilisée indifféremment. Bien entendu, l'utilisation indifféremment de l'une ou l'autre de ces identités devra être configurée de manière correspondante au niveau du serveur 3.

Il convient de noter que l'exemple de données génériques envisagé ici comprend plusieurs identités publiques, à savoir l'identité publique fixe IMPUfixe2 et l'identité publique mobile IMPUmob2. Ceci permet au terminal de sélectionner l'identité qu'il souhaite présenter côté appelé lors de l'établissement de sessions sortantes (i.e. ici son identité publique fixe ou son identité publique mobile), par exemple en positionnant l'identité choisie dans le champ FROM des messages SIP émis. Toutefois, cette hypothèse n'est en aucun cas limitative, et on peut envisager d'inclure dans les données génériques soit un nombre plus important d'identités publiques, soit au contraire une seule identité publique. Par ailleurs, bien que les données génériques intègrent ici plusieurs identités publiques pouvant être utilisées par le terminal 2, une seule de ces identités publiques génériques est préférentiellement utilisée lors de l'enregistrement du terminal 2 auprès du serveur 3 (on utilisera alors la notation IMPU2 désignant l'une ou l'autre des identités IMPUfixe2 ou IMPUmob2), celui-ci étant toutefois configuré pour reconnaître les autres identités publiques génériques susceptibles d'être utilisées par le terminal 2. Les données d'identification génériques du terminal 2 utilisées par le terminal 2 pour s'enregistrer auprès du serveur 3 (i.e. IMPI2, IMPU2 et GenPwd2) et l'information de joignabilité permettant de définir le chemin de signalisation jusqu'au serveur 3 forment des données d'enregistrement génériques du terminal 2 au sens de l'invention. Les données d'identification génériques et l'information de joignabilité du serveur 3 peuvent être transmises dans un fichier de configuration à l'application softphone du terminal 2 de manière automatique ou « Plug and Play » en utilisant par exemple le protocole OTAP (Over The Air Protocol) ou le protocole HTTPS (Hyper Text Transfer Protocol Secure), ou encore être fournies à l'usager du terminal 2 afin qu'il configure lui-même l'application softphone par l'intermédiaire d'une interface homme-machine adaptée. On notera que ces données sont dites « génériques », dans le sens où un seul jeu de données permet au terminal 2 de s'enregistrer auprès des trois services S1, S2, S3 offerts par les coeurs de réseau CN1, CN2 et CN3. Comme mentionné précédemment, ces données génériques peuvent s'appuyer sur des données réelles (comme ici une identité publique IMPU et une identité privée telles que des numéros de téléphone), ou en variante s'appuyer sur des données virtuelles, c'est-à-dire qui ont un sens uniquement entre le terminal 2 et le serveur 3. Les données d'enregistrement génériques du terminal 2 lui permettent de s'enregistrer, conformément à l'invention, auprès du serveur 3 afin d'accéder aux services S1, S2, et S3. Dans le mode de réalisation décrit ici, le serveur 3 se trouve dans un équipement d'un réseau d'accès aux services ou d'un coeur de réseau auquel est connecté le terminal 2 (non représenté sur la figure 1). Plus précisément, le serveur 3 est situé sur un point d'entrée du réseau, de sorte à se trouver en coupure de flux des différents échanges entre le terminal 2 et le réseau, et entre le terminal 2 et la pluralité de coeurs de réseau CN1, CN2 et CN3. Il convient de noter que le réseau d'accès aux services peut être un coeur de réseau à proprement parler (soit distinct des coeurs de réseau CN1, CN2, CN3, soit l'un de ces coeurs de réseau). Si ce coeur de réseau s'appuie sur une architecture IMS, le serveur 3 se trouve alors préférentiellement intégré dans le serveur P-CSCF du coeur de réseau gérant le terminal 2.

Dans un autre mode de réalisation, le serveur 3 est embarqué sur le terminal 2, et se trouve en coupure de flux des échanges entre l'application softphone du terminal 2 mentionnée précédemment et la pluralité de coeurs de réseau CN1, CN2 et CN3. Le serveur 3 dispose ici de l'architecture matérielle d'un ordinateur, telle que représentée à la figure 2B.

Il comporte notamment un processeur 3A, des moyens de communication 3B mettant en oeuvre notamment ici le protocole SIP, une mémoire vive 3C, et une mémoire morte 3D. La mémoire morte 3D du serveur 3 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 3A et sur lequel est enregistré un programme d'ordinateur conforme à l'invention comportant des instructions pour l'exécution des étapes d'un procédé d'enregistrement et d'un procédé de traitement selon l'invention décrites ultérieurement en référence aux figures 4, 6 et 7. Le serveur 3 est par ailleurs apte à communiquer via ses moyens de communication 3B avec une base de données 4, dans laquelle sont mémorisées les données d'identification génériques du terminal 2 en association avec des données d'enregistrement dites spécifiques du terminal 2 relatives aux différents services S1, S2 et S3 offerts par les coeurs de réseau CN1, CN2 et CN3. Ces données d'enregistrement spécifiques sont notées respectivement DATAI., DATA2 et DATA3. Chaque ensemble de données d'enregistrement DATAk, pour chaque service Sk, k=1,...,3 comprend ici une identité publique du terminal 2 notée SpecIMPUk, une identité privée du terminal 2 notée SpecIMPIk, un mot de passe du terminal 2 noté SpecPwdk, et une information de joignabilité d'un serveur d'enregistrement du coeur de réseau CNk, comprenant un nom de domaine associé au coeur de réseau CNk, et une adresse de contact AoCCNk de ce serveur. Autrement dit, les données d'enregistrement spécifiques comprennent, pour chaque coeur de réseau CNk et chaque service Sk, d'une part des données d'identification spécifiques pour ce service Sk, et d'autre part, une information de joignabilité indiquant un chemin de signalisation jusqu'au serveur d'enregistrement du coeur de réseau CNk, celui-ci faisant ensuite le relais vers les entités du coeur de réseau participant à la fourniture du service Sk. On notera que l'identité publique SpecIMPUk, respectivement l'identité privée SpecIMPIk, relative au service Sk peut être identique ou au contraire distincte de l'identité publique générique IMPUfixe2 ou IMPUmob2 du terminal 2, respectivement de son identité privée générique IMPI2. Il en est de même pour le mot de passe spécifique SpecPwdk par rapport au mot de passe générique GenPwd2. Ainsi, dans l'exemple envisagé ici, on suppose que - SpecIMPU1=SpecIMPU3=IMPUmob2 ; et SpecIMPU2=IMPUfixe2. Cette base de données 4 est alimentée et/ou mise à jour lors de la souscription par l'usager du terminal 2 aux services S1, S2 et S3 et de toute nouvelle souscription à un service offert par un coeur de réseau.

Elle peut être hébergée par le serveur 3 ou par un autre équipement du réseau d'accès aux services et être accessible le cas échéant, par le serveur 3 par l'intermédiaire d'une connexion réseau. Conformément à l'invention, l'accès par le terminal 2 aux services S1, S2 et S3 offerts par les réseaux CN1, CN2 et CN3 est géré par le serveur 3.

A cette fin, une phase d'enregistrement comprenant d'une part l'enregistrement du terminal 2 auprès du serveur 3, et d'autre part l'enregistrement du serveur 3 auprès des coeurs de réseau CN1, CN2, CN3, est mise en oeuvre dans un premier temps. Cette phase d'enregistrement est décrite maintenant en référence aux figures 3, 4 et 5. Ainsi, la figure 3 représente, sous forme d'ordinogramme, les principales étapes d'un procédé d'accès à une pluralité de services conformes à l'invention mises en oeuvre par le terminal 2. La figure 4 représente, sous forme d'ordinogramme, les principales étapes d'un procédé d'enregistrement conformes à l'invention, mises en oeuvre par le serveur 3. Et la figure 5 illustre un exemple des messages susceptibles d'être échangés au cours de cette phase d'enregistrement. En référence à la figure 3 et comme décrit précédemment, l'application softphone du terminal 2 est configurée avec les données d'enregistrement génériques du terminal 2 (étape D10), par exemple via l'envoi de messages courts ou SMS (Short Message Service) techniques dans le cadre du protocole OTAP, ou via une saisie des données d'enregistrement génériques par l'usager du terminal 2.

Ces données d'enregistrement génériques comprennent d'une part des données d'identification génériques du terminal 2 (c'est-à-dire ici IMPUfixe2, IMPUmob2, IMPI2 et GenPwd2), et d'autre part, l'information de joignabilité comprenant ici le nom de domaine et l'adresse de contact AoCServer3 du serveur 3 auprès duquel le terminal 2 doit s'enregistrer pour pouvoir accéder aux services S1, S2 et S3. Dans le mode de réalisation décrit ici, une procédure d'authentification est par ailleurs mise en oeuvre au cours de la phase d'enregistrement. Cette procédure d'authentification s'appuie ici sur la méthode DIGEST, connue de l'homme du métier, et se décompose en deux parties : une première partie (référencée par « Part I » sur la figure 5), sans envoi d'éléments d'authentification, et qui vise à l'obtention d'un paramètre d'authentification valide aussi connu sous le nom de « nonce » ; puis une seconde partie (référencée par « Part II » sur la figure 5), au cours de laquelle les éléments d'authentification SIP sont échangés.

Ainsi, au cours de la phase d'enregistrement, le terminal 2 envoie une requête d'enregistrement au serveur 3 en utilisant l'information de joignabilité du serveur 3, c'est-à-dire le nom de domaine dans lequel se trouve le serveur 3 et son adresse de contact AoCServer3 (étape D20). Cette requête est ici une requête SIP REGISTER comprenant des données d'identification génériques du terminal 2 sélectionnées parmi les données génériques obtenues lors de l'étape D10 de configuration de l'application softphone. Dans l'exemple illustré à la figure 5, la requête SIP REGISTER émise par le terminal 2 comprend l'identité publique générique IMPU2 du terminal 2 (fixe ou mobile). Elle comprend en outre l'adresse de contact AoCTerminal2 du terminal 2.

En référence à la figure 4, sur réception de cette requête d'enregistrement du terminal 2 (étape E10), le serveur 3 consulte la base de données 4 à l'aide des données d'identification génériques contenues dans la requête (i.e. de l'identité publique IMPU2). Il obtient, en retour, la liste des services auxquels l'usager du terminal 2 a souscrit (liste formée ici des services S1, S2 et S3), ainsi que les données d'enregistrement spécifiques DATAI, DATA2, DATA3, associées à l'identité publique générique IMPU2 du terminal 2 et relatives aux services S1, S2 et S3 respectivement (étape E20). Le serveur 3 alloue alors dynamiquement à chaque coeur de réseau CN1, CN2 et CN3 offrant les services S1, S2 et S3, un agent utilisateur SIP associé au terminal 2 (étape E30). De façon connue, un agent utilisateur est une application cliente utilisée avec un protocole particulier : autrement dit, il s'agit d'une pile protocolaire (ici une pile SIP) permettant au serveur 3 de communiquer avec le coeur de réseau auquel elle est allouée. Ainsi : - l'agent utilisateur SIP UA1 est alloué au coeur de réseau CN1 et associé au terminal 2, - l'agent utilisateur SIP UA2 est alloué au coeur de réseau CN2 et associé au terminal 2, et - l'agent utilisateur SIP UA3 est alloué au coeur de réseau CN3 et associé au terminal 2. Il convient de noter qu'en fonction des protocoles d'initiation de session mis en oeuvre par les coeurs de réseau CN1, CN2 et CN3, un agent utilisateur peut être associé à un terminal unique ou en variante un même agent utilisateur peut être associé à plusieurs terminaux. Dans le mode de réalisation décrit ici, le protocole mis en oeuvre par les coeurs de réseau CN1, CN2 et CN3 est le protocole SIP et on alloue un agent utilisateur SIP par terminal. Toutefois, en variante, dans un autre mode de réalisation, on peut associer un agent utilisateur à plusieurs terminaux et utiliser une information discriminante dans les messages pour différencier les messages reçus ou envoyés par cet agent utilisateur et concernant le terminal 2. Par ailleurs, les agents utilisateurs alloués au cours de l'invention peuvent être instanciés (i.e. initialisés) lors de l'étape dynamique E30 d'allocation ou au cours d'une étape mise en oeuvre au préalable. Conformément à l'invention, chaque agent utilisateur associé au terminal 2 va alors émuler auprès du coeur de réseau auquel il est alloué, le comportement d'une application softphone pour le compte du terminal 2. Ainsi, chaque agent utilisateur UAk, k=1,...,3, s'enregistre pour le compte du terminal 2 auprès du coeur de réseau CNk auquel il a été alloué (étape E40), à l'aide des données d'enregistrement spécifiques DATAk obtenues au cours de l'étape E20.

Plus précisément, chaque agent utilisateur UAk envoie une requête d'enregistrement SIP REGISTER en utilisant l'information de joignabilité du serveur d'enregistrement du coeur de réseau CNk, c'est-à-dire ici le nom de domaine associé au coeur de réseau CNk et l'adresse de contact AoCCNk de ce serveur d'enregistrement ; cette requête d'enregistrement contient les données d'identification spécifiques du terminal 2 relatives au service Sk, ainsi qu'une adresse de contact AoCUAk de l'agent utilisateur UAk. A titre illustratif, dans l'exemple représenté à la figure 5 (Part I) : l'agent utilisateur UA1 s'enregistre auprès du coeur de réseau CN1 en envoyant une requête d'enregistrement SIP REGISTER à l'adresse de contact AoCCN1, contenant l'identité publique spécifique SpecIMPU1 du terminal 2 relative au service S1 et l'adresse de contact AoCUA1 ; l'agent utilisateur UA2 s'enregistre auprès du coeur de réseau CN2 en envoyant une requête d'enregistrement SIP REGISTER à l'adresse de contact AoCCN2, contenant l'identité publique spécifique SpecIMPU2 du terminal 2 relative au service S2 et l'adresse de contact AoCUA2 ; et l'agent utilisateur UA3 s'enregistre auprès du coeur de réseau CN3 en envoyant une requête d'enregistrement SIP REGISTER à l'adresse de contact AoCCN3, contenant l'identité publique spécifique SpecIMPU3 du terminal 2 relative au service S3 et l'adresse de contact AoCUA3. Dès réception d'un nonce valide d'un des coeurs de réseau au cours de la première partie (ex. réception de NonceCN2 au cours de la partie « Part I » illustrée à la figure 5), le serveur 3 envoie à son tour un nonce valide (NonceServer3 sur la figure 5) au terminal 2.

La réception de ce nonce valide déclenche la seconde partie de la procédure d'authentification (« Part II »). Ainsi, sur réception de ce nonce valide, le terminal 2 s'authentifie auprès du serveur 3 (étape E50) en lui envoyant dans une requête SIP REGISTER ses paramètres d'authentification, formés ici de son identité privée IMPI2, de son mot de passe générique GenPwd2 et du nonce valide NonceServer3. Par ailleurs, chaque agent utilisateur UAk, k=1,...,3 s'authentifie pour le compte du terminal 2 auprès du coeur de réseau CNk auquel il est alloué en lui envoyant une requête SIP REGISTER comprenant ses paramètres d'authentification, à savoir ici, l'identité privée spécifique SpecIMPIk, le mot de passe spécifique SpecPwdk et le nonce valide NonceCNk précédemment transmis par le coeur de réseau CNk (étape E50). Suite à l'authentification de l'agent utilisateur UAk qui lui est alloué, chaque coeur de réseau CNk crée un contexte d'enregistrement pour cet agent utilisateur. Il associe à la requête d'enregistrement reçue de cet agent utilisateur UAk une période EXPIRES d'expiration de l'enregistrement, et transmet cette période à l'agent utilisateur UAk dans un message SIP 200 OK. Par ailleurs, suite à l'authentification du terminal 2 et dès lors qu'au moins un agent utilisateur UAk est enregistré auprès du coeur de réseau CNk correspondant (afin qu'au moins un service soit disponible pour le terminal 2), le serveur 3 crée et mémorise un contexte d'enregistrement pour le terminal 2. Il associe par ailleurs à la requête d'enregistrement du terminal 2 une période EXPIRES d'expiration de l'enregistrement et transmet cette période au terminal 2 dans un message SIP 200 OK. Dans l'exemple illustré à la figure 5, une période EXPIRES=1/2 heure est associée à l'enregistrement du terminal 2 par le serveur 3, tandis que les coeurs de réseau CN1, CN2 et CN3 associent respectivement une période EXPIRES=2 heures, 4 heures et 8 heures aux agents utilisateurs UA1, UA2, UA3. Autrement dit, les périodes d'expiration d'enregistrement allouées aux agents utilisateurs sont plus longues que (i.e. supérieures à) la période d'expiration d'enregistrement associée au terminal 2. De cette façon, les coeurs de réseau CN1, CN2 et CN3 peuvent supporter plus de clients : en effet, plus la période d'expiration d'enregistrement est courte, plus elle occupe une charge importante du réseau.

En variante, les mêmes périodes d'expiration d'enregistrement sont associées au terminal 2 et aux agents utilisateurs UA1, UA2 et UA3. Dans le mode de réalisation décrit ici, si à l'issue de la période d'expiration d'enregistrement associée au terminal 2 (période de temps prédéterminée au sens de l'invention) (réponse oui à l'étape test E60), le serveur 3 n'a pas reçu de requête de réenregistrement du terminal 2 (réponse non à l'étape test E70), chaque agent utilisateur UAk, k=1,..,3, envoie une requête de désenregistrement auprès du coeur de réseau CNk auquel il est alloué (étape E80).

Sur réception d'une telle requête, le coeur de réseau CNk supprime le contexte d'enregistrement associé à l'agent utilisateur UAk, de sorte à libérer les ressources allouées à ce contexte. Le contexte d'enregistrement associé au terminal 2 au niveau du serveur 3 est également supprimé (E90). Si au contraire, une requête de réenregistrement du terminal 2 a été reçue par le serveur 3 avant l'issue de la période d'expiration d'enregistrement associée au terminal 2 (réponse oui à l'étape test E70), le contexte d'enregistrement associé au terminal 2 au niveau du serveur 3 est mis à jour (étape E100). Par ailleurs, à l'issue de la période d'expiration d'enregistrement associée à chaque agent utilisateur UAk, k=1,...,3, une requête de réenregistrement est émise par le serveur 3, via ces agents utilisateurs, vers les coeurs de réseau CNk. Dans un autre mode de réalisation, si le serveur 3 n'a pas reçu de requête de réenregistrement du terminal 2 à l'issue de la période d'expiration d'enregistrement associée au terminal 2, chaque agent utilisateur UAk, k=1,...,3 envoie périodiquement auprès du coeur de réseau CNk auquel il est alloué, une requête de réenregistrement, afin d'optimiser les performances de ce coeur de réseau. On notera que dans le mode de réalisation décrit ici, l'enregistrement du terminal 2, respectivement des agents utilisateurs, est réalisé en deux parties et s'appuie sur l'envoi de deux requêtes SIP REGISTER séparées, la seconde requête permettant l'authentification à proprement parler du terminal 2, respectivement des agents utilisateurs, par le serveur 3, respectivement par les coeurs de réseau. Au sens de l'invention, l'envoi de ces deux requêtes constitue une étape d'enregistrement du terminal 2 auprès du serveur 3, respectivement des agents utilisateurs auprès des coeurs de réseau, comprenant l'envoi d'une requête d'enregistrement comprenant des données génériques du terminal 2, respectivement des données spécifiques associées aux coeurs de réseau.

Dans un autre mode de réalisation, une seule requête est envoyée au serveur 3 pour l'enregistrement et l'authentification du terminal 2, cette requête comprenant les données d'enregistrement génériques précitées (i.e. IMPU2 et GenPwd2) du terminal 2. De même, une seule requête est envoyée par chaque agent utilisateur auprès du coeur de réseau auquel il est alloué pour s'enregistrer et s'authentifier, cette requête comprenant les données d'enregistrement spécifiques précitées du terminal 2 associées à ce coeur de réseau. Dans un autre mode de réalisation encore, l'enregistrement du terminal 2 et des agents utilisateurs est réalisé sans authentification, auquel cas les requêtes d'enregistrement contiennent respectivement un identifiant générique du terminal 2 et un identifiant spécifique du terminal 2 pour le coeur de réseau considéré et peuvent ne pas contenir de mot de passe ni de nonce valide. A l'issue de la phase d'enregistrement, le terminal 2 peut maintenant accéder, par l'intermédiaire du serveur 3 et des agents utilisateurs UA1, UA2 et UA3, aux services Si, S2 et S3 offerts respectivement par les coeurs de réseau CN1, CN2 et CN3. Cet accès aux services S1, S2 et S3 est mis en oeuvre via l'émission (étape D30) d'un ou de plusieurs messages associés aux services S1, S2 et S3, par le terminal 2 à destination des coeurs de réseaux CN1, CN2 et CN3, et la réception (étape D40) d'un ou de plusieurs messages associés aux services Si, S2 et S3, par le terminal 2 en provenance des coeurs de réseaux CN1, CN2 et CN3.

Plus précisément, les messages émis par le terminal 2 sont traités par le serveur 3 puis routés vers les coeurs de réseau concernés, sélectionnés par le serveur 3 en fonction de critères prédéfinis. De même, les messages reçus des coeurs de réseau par les agents utilisateurs alloués par le serveur 3 sont traités par le serveur 3 puis envoyés vers le terminal 2. Il convient de noter que conformément à l'invention, les messages émis par le terminal 2 et associés aux services Si, S2 et S3 sont envoyés vers (ou interceptés par) un même serveur, à savoir le serveur 3, et ce en dépit du fait que ces services sont offerts par des coeurs de réseau distincts. Le type des messages et/ou au moins un champ de ces messages permettent alors au serveur 3 de router ces messages vers les coeurs de réseau concernés, c'est-à-dire aptes à traiter ces messages.

Nous allons maintenant décrire plus en détails, en référence à la figure 6, le traitement mis en oeuvre par le serveur 3 sur des messages émis par le terminal 2 échangés dans le cadre des services S1, S2 et S3. Ce traitement est mis en oeuvre suite à la phase d'enregistrement présentée précédemment. On suppose que le serveur 3 reçoit un message M émis par le terminal 2 associé à un service ou à plusieurs services parmi les services S1, S2 et S3 (étape F10). Conformément à l'invention, le serveur 3 analyse le type de ce message M (c'est-à-dire s'il s'agit d'un message d'établissement d'un appel, d'un message de découverte des capacités ou de l'état du distant, d'un message de souscription à un service, etc.) et/ou au moins un champ de ce message M (étape F20). Il s'agit via cette analyse d'identifier au moins un coeur de réseau parmi les coeurs de réseau CN1, CN2 et CN3 apte à traiter ce message (étape F30) et vers lequel router ce message (ou tout du moins un message dérivé du message M). Le ou les champs examinés peuvent dépendre du type de message reçu. Plus précisément, différents champs du message M peuvent être considérés pour déterminer vers quel(s) coeur(s) de réseau router le message. Ainsi, par exemple, on peut choisir 30 notamment un champ représentatif des services supportés par le terminal 2 ou des capacités du terminal 2. Pour un message conforme au protocole SIP, un tel champ est notamment un champ « tag feature» ou « tag » présent dans une adresse de contact du message ; - un champ représentatif d'un type de média négocié par le terminal 2 dans le message. Pour 35 un message conforme au protocole SIP, un tel champ est notamment un champ Message Body ou un champ inclus dans un champ Message Body (ex. Application/SDP) du message ; - un champ représentatif d'un événement auquel souscrit le terminal. Pour un message conforme au protocole SIP, un tel champ est notamment un champ « event » ou « event package » du message ; - un champ représentatif d'un identifiant d'origine du message. Pour un message conforme au protocole SIP, un tel champ est notamment un champ FROM ou Contact-Address ou P_Preferredidentity du message ; - un champ représentatif d'un identifiant du destinataire du message. Pour un message conforme au protocole SIP, un tel champ est notamment un champ R-URI ou un champ TO du message.

Cette liste n'est bien entendu pas exhaustive et d'autres champs du message M peuvent être pris en compte par le serveur 3 pour le routage, comme par exemple, un champ Accept-Contact, User-Agent, Subject, etc. Le ou les champs examinés dépendent des critères de routage envisagés au niveau du serveur 3 pour les messages provenant du terminal 2. Ces critères peuvent être sélectionnés de sorte à optimiser l'expérience utilisateur et/ou des contraintes opérateurs, comme par exemple l'équilibre de la charge entre les coeurs de réseau, des contraintes de facturation, etc. Suite à l'identification du ou des coeurs de réseau aptes à traiter le message M, le message M est mis en forme par le serveur 3 pour être routé vers ce ou ces coeurs de réseau (étape F40).

Différentes sortes de mise en forme du message M peuvent être réalisées par le serveur 3 dans le cadre de l'invention. Ainsi, il peut s'agir : de la modification de certains champs du message afin : o d'insérer les adresses de contact de l'agent utilisateur alloué au coeur de réseau identifié au cours de l'étape F30, ou o de remplacer un identifiant générique spécifié dans le message M par un identifiant spécifique connu du coeur de réseau vers lequel est routé le message ; de la suppression d'un champ du message non pertinent pour le coeur de réseau identifié, etc.

On dérive ainsi du message M un message M' distinct pour chaque coeur de réseau identifié à l'étape F30. En variante, si le coeur de réseau identifié n'implémente pas un protocole de communication similaire au terminal 2, une telle mise en forme peut consister en outre en une conversion protocolaire du message M reçu du terminal 2 afin de le rendre conforme au protocole de communication mis en oeuvre par le coeur de réseau identifié à l'étape F30. Le message M' dérivé du message M résultant de cette étape F40 de mise en forme est alors routé vers le coeur de réseau identifié à l'étape F40, par l'intermédiaire de l'agent utilisateur alloué à ce coeur de réseau (étape F50). Si plusieurs coeurs de réseau ont été identifiés, chaque message M' dérivé pour ce coeur de réseau est routé vers celui-ci par l'agent utilisateur alloué à ce coeur de réseau. Le message M' reçu par le coeur de réseau identifié est ensuite traité par celui-ci. Nous allons maintenant décrire plus en détails, en référence à la figure 7, le traitement mis en oeuvre par le serveur 3 sur des messages destinés au terminal 2 en provenance des coeurs de réseaux CN1, CN2, CN3, et échangés dans le cadre des services S1, S2 et S3. Ce traitement est mis en oeuvre suite à la phase d'enregistrement présentée précédemment. On suppose que le serveur 3 reçoit, par l'intermédiaire de l'agent utilisateur UAk, un message M" en provenance du coeur de réseau CNk (étape G10).

Comme décrit précédemment, dans le mode de réalisation décrit ici, il existe une correspondance unique entre le terminal 2 et l'agent utilisateur UAk, de sorte que le serveur 3 identifie que ce message M" est destiné au terminal 2. En variante, si un agent utilisateur est associé à plusieurs terminaux, le message M" contient un élément discriminant permettant au serveur 3 d'identifier le terminal auquel est destiné ce message. Dans le mode de réalisation décrit ici, avant de transférer le message M" vers le terminal 2, le serveur 3 met en oeuvre une étape de détection au cours de laquelle il détermine si une session est déjà établie entre le terminal 2 et l'un des coeurs de réseau CN1, CN2 et CN3 (étape G20).

On notera que le serveur 3 se trouvant en coupure de flux des échanges entre le terminal 2 et les coeurs de réseau CN1, CN2 et CN3, il se trouve donc en coupure des flux de signalisation d'appel. Dans le mode de réalisation décrit ici, le serveur 3 conserve dans sa mémoire vive 3C les contextes des sessions établies par le terminal 2 jusqu'à ce qu'elles soient libérées (autrement dit jusqu'à ce que des messages BYE et 2000K lui parviennent pour cette session), afin de mettre en oeuvre cette étape de détection. Si le serveur 3 détecte une session établie (réponse oui à l'étape test G20), il vérifie que le message M" est compatible avec cette session (étape test G30), autrement dit il vérifie si le message M" ou un message dérivé du message M" peut être transmis au terminal 2 sans interrompre ou perturber la session déjà établie. Cette vérification peut être mise en oeuvre en vérifiant des critères de compatibilité préétablis (par exemple, « tel type de message est compatible avec telle session établie »). Ainsi, par exemple, si le message M" est un message SIP OPTIONS, il est considéré comme compatible avec une session de communication déjà établie par le terminal 2 avec un terminal 5 enregistré auprès de l'un des coeurs de réseau CN1, CN2, CN3.

Il en est de même si le message M" est un message SIP INVITE et que le terminal 2 supporte une fonctionnalité de double appel. En revanche, si le terminal 2 ne supporte pas une telle fonctionnalité, un message M" SIP INVITE n'est pas considéré comme compatible avec la session établie.

Si le serveur 3 détermine que le message M" n'est pas compatible avec la session établie (réponse non à l'étape test G30), le message M" est refusé et un message de rejet ou d'erreur est envoyé par l'agent utilisateur UAk au coeur de réseau CNk pour lui signifier ce rejet (étape G40). Aucun message n'est routé vers le terminal 2.

En revanche, si le serveur 3 détermine que le message M" est compatible avec la session établie (réponse oui à l'étape test G30), ou si aucune session n'est déjà établie pour ce terminal 2 avec l'un des coeurs de réseau CN1, CN2 et CN3 (réponse non à l'étape test G20), le message M" (ou un message M"' dérivé de ce message M") peut être routé vers le terminal 2. Le message M" est alors mis en forme par le serveur 3 avant sa transmission vers le terminal 2 (étape G50) en vue d'obtenir un message M"' dérivé du message M". Différentes sortes de mise en forme du message M" peuvent être réalisées par le serveur 3 dans le cadre de l'invention. Il peut s'agir par exemple de la modification de certains champs du message afin d'insérer l'adresse de contact du terminal 2, de remplacer un identifiant spécifique au coeur de réseau CNk par un identifiant générique du terminal 2, ou la suppression d'un champ du message non pertinent pour le terminal 2. En variante, si le terminal 2 n'implémente pas un protocole de communication similaire à celui du coeur de réseau CNk dont provient le message M", une telle mise en forme peut consister en une conversion protocolaire du message M" reçu du coeur de réseau CNk afin de le rendre conforme au protocole de communication mis en oeuvre par le terminal 2. Le message M'" dérivé du message M" et résultant de cette étape de mise en forme est alors transmis (i.e. routé) vers le terminal 2 (étape G60). Le message M"' reçu par le terminal 2 est ensuite traité par celui-ci. Nous allons maintenant illustrer, en référence aux figures 8 à 11, le traitement mis en oeuvre par le serveur 3 conformément au procédé de traitement précédemment décrit, sur différents types de messages émis par le terminal 2, ou destinés au terminal 2 et provenant des coeurs de réseau CN1, CN2 et CN3. La figure 8 illustre le traitement d'un message M de découverte des capacités et/ou de l'état du distant envoyé par le terminal 2 à l'ensemble des numéros présents dans son répertoire. Un tel message est connu en soi : il permet à un terminal d'informer un dispositif distant de ses capacités (c'est-à-dire des services qu'il supporte) et/ou de son état, et de recevoir en réponse, les capacités et/ou l'état du dispositif distant. Dans l'exemple envisagé ici, ce message M est un message SIP OPTIONS envoyé au serveur 3 (ou intercepté par le serveur 3) et destiné à un terminal 5. Il comprend différents champs dont : - des champs de destination RURI et TO du message, contenant un identifiant du terminal 5 noté IdTerminal5 ; - un champ FROM contenant un identifiant d'origine du message, à savoir ici l'identité publique générique IMPU2 du terminal 2 (i.e. son identité générique mobile ou fixe) ; - un champ AoC contenant l'adresse de contact AoCTerminal2 du terminal 2 ; et - un champ « tag feature » ou « tag » représentatif de services supportés par le terminal 2 et dans le cadre desquels un message SIP OPTIONS est envoyé, à savoir dans cet exemple, les services S1 et S3 (on notera que le message SIP OPTIONS peut ne concerner que certains des services supportés par le terminal 2). Sur réception du message M, le serveur 3 analyse en premier lieu le type de ce message. S'agissant d'un message SIP OPTIONS de découverte des capacités et/ou de l'état du distant, il analyse dans un second temps le contenu de ce message et notamment du champ « feature tag» ou « tag ». Au cours de cette étape d'analyse, le serveur 3 détecte dans le champ « feature tag» du message M la présence des services S1 et S3 gérés respectivement par les coeurs de réseau CN1 et CN3. Il en déduit que les coeurs de réseau sont concernés par ce message et aptes à le traiter. Les coeurs de réseau identifiés à l'issue de l'étape F40 sont donc les coeurs de réseau CN1 et CN3. Le serveur 3 dérive alors ici, à partir du message SIP OPTIONS M, deux messages SIP OPTIONS M'1 et M'3 tels que : - le message M1 contient comme adresse de contact, l'adresse de contact AoCUA1 de l'agent utilisateur UA1 et dans le champ « tag », le service S1 uniquement. Le champ FROM du message MI contient par ailleurs l'identité publique spécifique SpecIMPU1 ; et - le message M'3 contient comme adresse de contact, l'adresse de contact AoCUA3 de l'agent utilisateur UA3 et dans le champ « tag », le service S3 uniquement. Le champ FROM du message M'3 contient par ailleurs l'identité publique spécifique SpecIMPU3.

Les messages M'1 et M'3 sont envoyés respectivement par les agents utilisateur UA1 et UA3 vers les coeurs de réseau CN1 et CN3. Dans l'exemple illustré à la figure 8, le serveur 3 attend ensuite les réponses à ces deux messages des coeurs de réseau CN1 et CN3 avant de répondre au terminal 2, de manière à synthétiser ces réponses dans un message de réponse unique.

On suppose par ailleurs dans cet exemple que bien que le terminal 5 supporte les deux services S1 et S3, il n'est pas enregistré auprès du coeur de réseau CN3, si bien que le serveur 3 reçoit : - par l'intermédiaire de son agent utilisateur UA3 : un message M"3 = 480 Temporarily Unavailable, en réponse au message M'3, et - par l'intermédiaire de son agent utilisateur UA1 : un message M"1 = 200 OK (Tag=S1) en réponse au message M'1.

Le serveur 3 dérive alors un unique message de réponse M"' = 200 OK à partir des messages M"1 et M"3, qui contient uniquement le service S1 puisque seul ce service peut être activé entre le terminal 2 et le terminal 5. Le message M"' ainsi dérivé est routé vers le terminal 2. La figure 9 illustre le traitement d'un message M de souscription à un événement envoyé par le terminal 2. Ce message M est ici un message SIP SUBSCRIBE envoyé au serveur 3 (ou intercepté par le serveur 3), et destiné à un serveur de messagerie vocale associée à l'identité publique fixe du terminal 2 de manière à recevoir des notifications lorsqu'un message vocal est déposé ou lu. Il comprend différents champs, dont notamment : - des champs de destination RURI et TO du message contenant un identifiant « VoiceMail Fixe » du serveur de messagerie vocale ; - un champ FROM contenant un identifiant d'origine du message, à savoir ici l'identité publique générique IMPU2 du terminal 2 (ex. son identité publique générique mobile IMPUmob2) ; un champ AoC contenant l'adresse de contact AoCTerminal2 du terminal 2 ; et un champ « event package » ou « event » identifiant l'événement auquel souscrit le terminal 2 intitulé ici « Message Summary ». Sur réception du message M, le serveur 3 analyse en premier lieu le type de ce message. S'agissant d'un message SIP SUBSCRIBE, il analyse dans un second temps, le contenu de ce message et notamment du champ « RURI ».

Au cours de cette étape d'analyse, le serveur 3 détecte dans le champ « RURI » du message M, l'identifiant « VoiceMailFixe » du serveur de messagerie vocale fixe et en déduit que le message M concerne le coeur de réseau CN2 offrant le service S2 de voix sur IP fixe. Le coeur de réseau identifié à l'issue de l'étape F40 est donc le coeur de réseau CN2. Dans l'exemple illustré à la figure 9, le serveur 3 dérive à partir du message M SIP SUBSCRIBE, un message M' SIP SUBSCRIBE dans lequel il a remplacé l'adresse de contact AoCTerminal2 par l'adresse de contact AoCUA2 de l'agent utilisateur UA2, de sorte à recevoir les notifications SIP NOTIFY émises en retour par le serveur de messagerie vocale. Par ailleurs, l'identité publique spécifique SpecIMPU2 est insérée dans le champ FROM en remplacement de l'identité publique générique IMPU2 si les identités SpecIMPU2 et IMPU2 sont distinctes.

Le message M' est envoyé par l'agent utilisateur UA2 vers le coeur de réseau CN2. Les messages M" de notification SIP NOTIFY émis par le serveur de messagerie sont reçus par l'agent utilisateur UA2. Le serveur 3 relaie alors chaque message de notification M" reçu par l'agent utilisateur UA2 vers le terminal 2, éventuellement après avoir remplacé certains champs dans ce message, tel que par exemple l'identité publique IMPU spécifique SpecIMPU2 par l'identité publique générique IMPU2 si les identités SpecIMPU2 et IMPU2 sont distinctes. Le message M"' résultant routé vers le terminal 2 est un message dérivé du message M" reçu par l'agent utilisateur UA2 au sens de l'invention.

Il convient de noter que si le terminal 2 souscrit à plusieurs types d'événements proposés par le coeur de réseau CN2, le routage pourra se faire non seulement sur le champ RURI mais également sur le champ « event package ». La figure 10 illustre le traitement d'un message M d'établissement d'une communication audio à l'initiative du terminal 2. Ce message M est ici un message SIP INVITE envoyé au serveur 3 (ou intercepté par le serveur 3) et destiné à un terminal 5. Il comprend différents champs, dont notamment : des champs de destination RURI et TO du message contenant un identifiant IdTerminal5 du terminal 5 ; - un champ FROM contenant un identifiant d'origine du message, à savoir ici l'identité publique générique IMPU2 du terminal 2 ; - un champ AoC contenant l'adresse de contact AoCTerminal2 du terminal 2 ; et - un champ représentatif d'un type de média négocié par le terminal 2, à savoir un champ Application/SDP du champ Message Body du message M, positionné à « audio ». Le serveur 3 analyse en premier lieu le type de ce message. S'agissant d'un message SIP INVITE, il acquitte la réception de ce message M par un message SIP 100 Trying afin d'éviter les retransmissions de ce message par le terminal 2. Puis il analyse dans un second temps, le contenu de ce message et notamment le type de session média négociée dans le message. Dans l'exemple envisagé ici, il s'agit d'une session de protocole SDP (Session Description Protocol) portant sur un codec audio. Le serveur 3 déduit de cette analyse que la communication que le terminal 2 souhaite établir est une communication de type synchrone (ex. téléphonique ou visioconférence) et qu'il faut donc utiliser le coeur de réseau CN2 de voix sur IP fixe pour traiter ce message M. Le coeur de réseau identifié à l'issue de l'étape F40 est donc le coeur de réseau CN2. Dans l'exemple illustré à la figure 10, le serveur 3 dérive à partir du message M SIP INVITE, un message M' SIP INVITE dans lequel : - il a remplacé l'adresse de contact AoCTerminal 2 par l'adresse de contact AoCUA2 de l'agent utilisateur UA2, et - il a remplacé si nécessaire l'identité publique générique IMPU2 dans le champ FROM par l'identité publique fixe SpecIMPU2. Le message M' est routé par l'agent utilisateur UA2 vers le coeur de réseau CN2. La communication s'établit ensuite de manière standard entre le terminal 2 et le terminal 5.

Il convient de noter que tous les flux de signalisation transitent conformément à l'invention par le serveur 3. Le flux média peut être établi directement entre le terminal 2 et le coeur de réseau CN2, ou transiter via le serveur 3.

En variante, le coeur de réseau vers lequel router le message SIP INVITE peut être sélectionné en fonction du contenu du champ FROM du message, par exemple dans l'hypothèse où l'usager du terminal 2 peut sélectionner l'identifiant (fixe ou mobile) présent dans ce champ et en s'appuyant sur une grille tarifaire gérée par le serveur 3 en fonction de l'identifiant (fixe ou mobile) utilisé pour établir la communication et/ou en fonction de l'identifiant appelé. Les exemples illustrés aux figures 8 à 10 ne sont bien entendu donnés qu'à titre indicatif. D'autres critères de routage peuvent être envisagés en complément de ceux détaillés ici. Ainsi, par exemple, on peut imaginer également que le serveur 3 prenne en compte la disponibilité ou l'état des coeurs de réseau avant le routage du message.

La figure 11 illustre un exemple de traitement conformément à l'invention d'un message M" d'établissement d'une session permettant l'échange de messages textes, émis depuis un terminal 5 vers le terminal 2 et reçu du coeur de réseau CN3. Le message M" est ici un message SIP INVITE envoyé au serveur 3 (ou intercepté par le serveur 3), destiné au terminal 2 et provenant du coeur de réseau CN3.

Il comprend différents champs dont - des champs de destination RURI et TO du message contenant l'identité publique spécifique SpecIMPU2 du terminal 2 ; - un champ FROM contenant un identifiant d'origine du message, à savoir ici l'identifiant IdTerminal5 du terminal 5 ; - des paramètres SDP de négociation d'une session média, et plus particulièrement d'une session MSRP (Message Session Relay Protocol)) ; et un message textuel « Message 1 » destiné au terminal 2. Le serveur 3 analyse en premier lieu le type de ce message. S'agissant d'un message SIP INVITE, il acquitte par l'intermédiaire de l'agent utilisateur UA3 la réception de ce message M" par un message SIP 100 Trying, afin d'éviter les retransmissions de ce message par le coeur de réseau CN3. Puis il consulte la base de données 4 et vérifie que le service S3 est un service supporté par le terminal 2. Le cas échéant, il route, vers le terminal 2, un message M"' dérivé du message M" (après modification notamment du champ AOC du message, et des champs RURI et TO afin d'insérer dans ces champs l'identité publique générique IMPU2 du terminal 2 en remplacement de l'identité publique spécifique SpecIMPU2 (si SpecIMPU2 et IMPU2 sont différentes)). La session MRSP s'établit de manière standard entre le terminal 2 et le terminal 5 via le coeur de réseau CN3. L'invention permet donc à l'application softphone du terminal 2 de fonctionner de manière standard, comme si un seul coeur de réseau fournissait l'ensemble des services S1, S2 et S3. La gestion des messages réalisée par le serveur 3 est transparente pour l'usager du terminal 2. L'accès à plusieurs services offerts par des coeurs de réseau distincts est ainsi grandement simplifié par l'invention.

Claims (15)

1. REVENDICATIONS1. Procédé d'enregistrement d'un serveur (3) auprès d'une pluralité de coeurs de réseau multimédia (CN1, CN2, CN3), chaque coeur de réseau étant apte à fournir à un terminal (2) au moins un service (S1, S2, S3), ledit procédé d'enregistrement comprenant : une étape de réception (E10, E50) d'une requête d'enregistrement du terminal (2) comportant des données d'identification dites génériques de ce terminal (2) ; - une étape d'obtention (E20), à l'aide desdites données d'identification génériques, de données d'enregistrement dites spécifiques (DATAI, DATA2, DATA3) du terminal associées auxdits coeurs de réseau multimédia ; une étape d'allocation dynamique (E30) à chacun desdits coeurs de réseau (CN1, CN2, CN3), d'un agent utilisateur (UA1, UA2, UA3) associé audit terminal (2) et apte à communiquer avec ce coeur de réseau ; et une étape d'enregistrement (E40, E50) au cours de laquelle chaque agent utilisateur (UA1, UA2, UA3) envoie une requête d'enregistrement à destination du coeur de réseau auquel il est alloué, en utilisant les données d'enregistrement spécifiques associées à ce coeur de réseau obtenues au cours de l'étape d'obtention, ladite requête d'enregistrement contenant une adresse de contact (AoC1, AoC2, AoC3) de l'agent utilisateur.
2. 2. Procédé d'enregistrement selon la revendication 1 comprenant en outre, si ledit serveur (3) n'a pas reçu de requête de réenregistrement dudit terminal à l'issue d'une période de temps prédéterminée (E60, E70), une étape d'envoi (E80), par chaque agent utilisateur (UA1, UA2, UA3), d'une requête de désenregistrement auprès du coeur de réseau (CN1, CN2, CN3) auquel il est alloué.
3. 3. Procédé d'enregistrement selon la revendication 1 comprenant en outre, si ledit serveur (3) n'a pas reçu de requête de réenregistrement dudit terminal à l'issue d'une période de temps prédéterminée, une étape d'envoi périodique, par chaque agent utilisateur (UA1, UA2, UA3), d'une requête de réenregistrement auprès du coeur de réseau (CN1, CN2, CN3) auquel il est alloué.
4. 4. Procédé d'enregistrement selon la revendication 1 dans lequel, le serveur (3) étant situé dans un équipement d'un réseau de télécommunications auquel est connecté ledit terminal : - la requête d'enregistrement du terminal est associée à une première période d'expiration de l'enregistrement ; et- au moins une requête d'enregistrement d'un agent utilisateur envoyée au cours de l'étape d'enregistrement est associée à une deuxième période d'expiration de l'enregistrement supérieure à la première période d'expiration.
5. 5. Procédé d'enregistrement selon la revendication 1 dans lequel : le terminal (2), le serveur (3) et les coeurs de réseau multimédia (CN1, CN2, CN3) mettent en oeuvre le protocole d'initiation de session SIP ; et - les agents utilisateurs (UA1, UA2, UA3) alloués par le serveur (3) aux coeurs de réseau (CN1, CN2, CN3) sont des agents utilisateurs SIP.
6. 6. Procédé de traitement de messages par un serveur (3), suite à l'enregistrement de ce serveur (3) auprès d'une pluralité de coeurs de réseau multimédia (CN1, CN2, CN3) aptes à fournir au moins un service (Si, S2, S3) à un terminal (2), ledit enregistrement dudit serveur (3) étant conforme à un procédé d'enregistrement selon la revendication 1, ledit procédé de traitement de messages comprenant : une étape de réception (F10) d'un message (M) en provenance dudit terminal (2) ; une étape d'identification (F20,F30), à partir d'un type de ce message et/ou d'au moins un champ de ce message, d'au moins un coeur de réseau (CN1, CN2, CN3) pour traiter ledit message parmi la pluralité de coeurs de réseau (CN1, CN2, CN3) ; et - une étape de routage (F50) vers le coeur de réseau identifié (CN1, CN2, CN3), par l'agent utilisateur (UA1, UA2, UA3) alloué à ce coeur de réseau, d'un message (M') dérivé du message reçu (M) contenant une adresse de contact de l'agent utilisateur (AoCUAl, AoCUA2, AoCUA3).
7. 7. Procédé de traitement selon la revendication 6 comprenant en outre : - une étape de réception (G10), par un agent utilisateur (UA1, UA2, UA3) alloué par le serveur (3) à un coeur de réseau multimédia (CN1, CN2, CN3), d'un message (M") en provenance de ce coeur de réseau (CN1, CN2, CN3) ; et une étape de routage (G60) vers le terminal (2) d'un message (M"') dérivé du message reçu
8. 8. Procédé de traitement selon la revendication 7 comprenant en outre : avant l'étape de routage (F50) vers au moins un coeur de réseau identifié (CN1, CN2, CN3), une étape de conversion (F40) du message reçu (M) du terminal en un message (M') conforme à un protocole de communication mis en oeuvre par ce coeur de réseau ; et/ou avant l'étape de routage (G60) vers le terminal (2), une étape de conversion (G50) d'au moins un message reçu (M") d'un coeur de réseau (CN1, CN2, CN3) en un message (M"') conforme à un protocole de communication mis en oeuvre par le terminal (2).
9. 9. Procédé de traitement selon la revendication 7 comprenant en outre, sur réception du message en provenance du coeur de réseau : une étape de détection (G20) au cours de laquelle le serveur (3) détermine si une session est déjà établie entre le terminal (2) et un coeur de réseau (CN1, CN2, CN3) de la pluralité de coeurs de réseau ; et si une session est déjà établie, une étape de vérification (G30) que le message reçu (M") est compatible avec cette session, l'étape de routage (G60) n'étant mise en oeuvre que lorsque le message reçu (M") est compatible avec la session établie.
10. 10. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé d'enregistrement selon la revendication 1 ou du procédé de traitement de messages selon la revendication 6 lorsque ledit programme est exécuté par un ordinateur.
11. 11. Procédé d'accès par un terminal (2) à une pluralité de services (S1, S2, S3) offerts par des coeurs de réseau multimédia distincts (CN1, CN2, CN3), ledit procédé comprenant : - une étape d'obtention (D10) par ledit terminal (2) de données d'identification dites génériques dudit terminal et d'une information de joignabilité (AoCServer3) d'un serveur (3) ; - une étape d'enregistrement (D20) auprès dudit serveur (3) pour accéder à ladite pluralité de services (S1, S2, S3), cette étape d'enregistrement comprenant l'envoi d'une requête d'enregistrement audit serveur (3) en utilisant l'information de joignabilité (AoCServer3) dudit serveur, ladite requête comprenant lesdites données d'identification génériques ; et au moins une étape d'envoi (D30) au serveur (3) d'au moins un message (M), ledit au moins un message étant associé aux services (S1, S2, S3) offerts par les coeurs de réseau multimédia, et le type dudit au moins un message et/ou au moins un champ dudit au moins un message permettant au serveur (3) de router ledit au moins un message vers le ou les coeurs de réseau multimédia (CN1, CN2, CN3) offrant le ou les services (S1, S2, S3) associés audit au moins un message (M).
12. 12. Serveur (3) apte à s'enregistrer auprès d'une pluralité de coeurs de réseau multimédia (CN1, CN2, CN3), chaque coeur de réseau étant apte à fournir à un terminal (2) au moins un service (S1, S2, S3), ledit serveur (3) comprenant : - des moyens de réception (3B) d'une requête d'enregistrement du terminal comportant des données d'identification dites génériques de ce terminal ; - des moyens d'obtention (3A,3B), à l'aide desdites données d'identification génériques, de données d'enregistrement dites spécifiques du terminal associées auxdits coeurs multimédia; - des moyens d'allocation dynamique (3A) à chacun desdits coeurs de réseau (CN1, CN2, CN3), d'un agent utilisateur (UA1, UA2, UA3) associé audit terminal (2) et apte à communiquer avec ce coeur de réseau ;- des moyens d'enregistrement (3A) aptes à déclencher l'envoi par chaque agent utilisateur (UA1, UA2, UA3) d'une requête d'enregistrement à destination du coeur de réseau (CN1, CN2, CN3) auquel il est alloué, utilisant les données d'enregistrement spécifiques associées à ce coeur de réseau obtenues par les moyens d'obtention, ladite requête d'enregistrement contenant une adresse de contact (AoCUA1, AoCUA2, AoCUA3) de l'agent utilisateur (UAl, UA2, UA3).
13. 13. Serveur (3) selon la revendication 12 situé dans un équipement d'un réseau auquel est connecté ledit terminal (2).
14. 14. Terminal (2) comprenant : - des moyens d'obtention (2B) de données d'identification dites génériques dudit terminal (2) et d'une information de joignabilité (AoCServer3) d'un serveur (3) ; - des moyens d'enregistrement (2A) auprès dudit serveur (3) pour accéder à une pluralité de services (S1, S2, S3) offerts par des coeurs de réseau multimédia distincts (CN1, CN2, CN3), ces moyens d'enregistrement étant aptes à utiliser l'information de joignabilité (AoCServer3) dudit serveur (3) pour envoyer une requête d'enregistrement audit serveur, ladite requête comprenant lesdites données d'identification génériques ; et - des moyens d'envoi (2A,2B) au serveur (3) d'au moins un message (M), ledit au moins un message étant associé aux services offerts par les coeurs de réseau multimédia, et le type dudit au moins un message et/ou au moins un champ dudit au moins un message permettant au serveur de router ledit au moins un message vers le ou les coeurs de réseau multimédia offrant le ou les services associés audit au moins un message.
15. 15. Système de communications (1) comprenant - une pluralité de coeurs de réseau distincts (CN1, CN2, CN3), chaque coeur de réseau offrant au moins un service (S1, S2, S3) ; un terminal (2) selon la revendication 14 ; et - un serveur (3) selon la revendication 12, permettant au terminal d'accéder aux services offerts par les coeurs de réseau.