FR 2873881 A1 20060203 FR 0451728 A 20040730 2873881 1 La présente invention concerne les systèmes et procédés pour échanger des informations dans un réseau informatique entre au moins un utilisateur connecté au réseau et au moins un serveur d'application. L'expression réseau informatique doit être comprise avec un sens large et 5 le réseau informatique peut notamment être un réseau de téléphonie mobile, par exemple celui dit de troisième génération. L'invention concerne plus particulièrement un réseau informatique opérant sous le protocole de signalisation SIP (Session Initiation Protocol), c'est-à-dire dans lequel au moins un utilisateur envoie un message en utilisant ce protocole, ce message étant acheminé vers un serveur d'application. SIP est un protocole du type requête/réponse dans le sens où, pour chaque message émis par une source, il y a au moins une réponse associée au destinataire confirmant la réception du message envoyé. Le protocole SIP est décrit notamment dans Internet Engineering Task Force (IETF) Request for comments RFC 3261 (2002) qui est incorporé à la présente par référence et dans le RFC 2543 (1999). Dans la suite de la description, SIP désignera à la fois le protocole SIP défini ci-dessus et ses évolutions et dérivés. Le 3GPP a adopté le protocole SIP comme protocole de signalisation dans le réseau IMS (IP Multimedia Subsystem), défini dans les recommandations TS 22.228, TS 23.228, TS 24.229. L'IMS est la partie du réseau UMTS destinée à fournir les services multimédia sur IP. Dans l'architecture de service des réseaux de télécommunications fonctionnant avec le protocole SIP, un service est fourni par un programme appelé logique de service . Un serveur d'application a pour rôle d'héberger des logiques de service en leur offrant un environnement d'exécution. Ainsi, un serveur d'application peut héberger plusieurs logiques de service. Le serveur d'application peut résider dans le réseau IMS ou à l'extérieur de celui-ci, notamment lorsque le service est offert par un tiers. L'utilisateur peut par exemple être un terminal de téléphonie mobile, un ordinateur portable, un assistant personnel numérique, un téléphone du réseau commuté 2873881 2 PSTN, un téléphone SIP (SIP phone), un terminal d'ordinateur ou un autre serveur d'application. Un serveur SIP est l'entité chargée de router les messages. Lorsqu'un service doit être invoqué suite à la réception d'un message par le serveur SIP, ce dernier envoie ce message éventuellement modifié à un serveur d'application hébergeant la logique de service chargée de fournir le service en question. Dans la description et les revendications, on désignera par serveur SIP un serveur capable à tout le moins de comprendre et d'utiliser le protocole SIP. Ainsi, le serveur S-CSCF du réseau IMS sera considéré comme un serveur SIP au sens de la présente invention. Un serveur proxy SIP peut être considéré comme un serveur SIP. Afin de permettre l'invocation des services, le serveur SIP doit posséder un mécanisme lui permettant, lors de la réception d'un message, de savoir si un service doit être déclenché ou non, et si oui, à quel serveur d'application le message doit être envoyé. Dans le réseau IMS, le serveur SIP, appelé S-CSCF y parvient en appliquant des filtres correspondants au profil de chaque abonné, appelés iFC (Initial Filter Criteria). Un iFC définit les conditions régissant l'invocation d'un service et désigne le serveur d'application hébergeant ce service. Le serveur S-CSCF télécharge les iFC d'une base de données; appelée HSS, contenant les profils des abonnés. Lorsqu'un message SIP est transféré par un serveur SIP à un serveur 20 d'application hébergeant plusieurs logiques de service, ce dernier doit pouvoir décider à quelle logique de service ce message est destiné. Actuellement, aucune solution satisfaisante n'a été proposée. En particulier, le mécanisme permettant au serveur d'application de décider à quelle logique de service le message est destiné ne doit idéalement pas rallonger significativement le délai d'exécution du service, ni compliquer le fonctionnement du serveur d'application ou le développement des logiques de service, ni accroître de manière importante les ressources mémoire nécessaires. La présente invention vise à répondre à ce besoin grâce à une solution ne présentant pas les inconvénients mentionnés ci-dessus et a pour objet, selon un premier de ses aspects, un procédé pour permettre l'exécution d'une logique de service parmi une pluralité de logiques de service hébergées dans un serveur d'application d'un réseau opérant sous protocole SIP, ce réseau comportant un serveur SIP recevant des messages 2873881 3 provenant d'utilisateurs devant accéder à la logique de service et adressant des messages au serveur d'application, procédé dans lequel on associe à chaque logique de service une adresse URI ou un identifiant qui est inséré dans le message transféré par le serveur SIP au serveur d'application. Grâce à l'invention, le serveur d'application peut aisément affecter une logique de service à un message reçu du serveur SIP, sans que cette affectation nécessite un échange supplémentaire d'informations entre le serveur d'application et une base de données contenant les profils des utilisateurs, ce qui permet de ne pas allonger le délai d'exécution. En outre, toujours grâce à l'invention, le serveur d'application peut ne pas pouvoir interpréter les filtres appliqués par le serveur SIP et peut ne pas avoir à garder un état de la session, ce qui simplifie son fonctionnement. L'homme de l'art pourra également apprécier que l'invention permet d'éviter, par rapport à des solutions alternatives, que le serveur d'application ait à recevoir une copie de messages REGISTER avant réception des messages envoyés par le serveur SIP ou ait à stocker les iFC de tous les utilisateurs enregistrés dans le cas du réseau IMS. Lorsque l'identifiant associé à la logique de service à exécuter est inséré par le serveur SIP dans le message destiné au serveur d'application, l'identifiant peut par exemple être inséré comme valeur d'un nouveau champ d'entête, comme paramètre de l'URI du serveur d'application présent dans le champ ROUTE du message, comme paramètre de request-URI, dans le corps du message SIP ou encore comme valeur d'un entête existant. Dans un exemple de mise en oeuvre de l'invention, l'identifiant associé à la logique de service est incorporé dans les filtres utilisés par le serveur SIP concernant les conditions d'invocation des logiques de service. Par exemple, dans le cas du réseau IMS, l'identifiant d'un service peut être inclus dans un iFC. L'invention a encore pour objet un réseau, comportant: - un serveur SIP, notamment un serveur S-CSCF dans le cas du réseau IMS, - un serveur d'application comportant plusieurs logiques de service, 30 - une base de données comportant les profils des utilisateurs, ce réseau pouvant se caractériser par le fait que la base de données comporte un identifiant ou une adresse URI associé(e) à une logique de service du serveur d'application. 2873881 4 L'invention pourra être mieux comprise à la lecture de la description détaillée qui va suivre et à l'examen de la figure 1 du dessin annexé, qui représente de manière schématique un réseau 1 dans lequel l'invention peut être mise en oeuvre. Ce réseau 1 comporte au moins un utilisateur 2, un serveur SIP 3, une base de données 4 contenant les profils d'utilisateurs, et un serveur d'application 5. Comme indiqué plus haut, dans le cas du réseau IMS, le serveur SIP 3 est appelé S-CSCF, la base de données 4 est appelée HSS et les échanges d'informations s'effectuent selon le protocole de signalisation SIP. La figure 1 est schématique et dans la pratique, des éléments additionnels tels 10 que par exemple un serveur proxy I-CSCF et un serveur proxy P-CSCF peuvent être présents. Conformément à l'invention, le serveur d'application 5 héberge au moins deux logiques de service et des moyens sont prévus pour permettre au serveur d'application de connaître la logique de service qui doit être exécutée lors de la réception d'un message SIP. Dans un exemple de mise en oeuvre de l'invention, un identifiant est associé à chaque logique de service dans la base de données 4. Cet identifiant peut présenter diverses formes. Nouveau champ d'entête L'identifiant associé à une logique de service peut par exemple être une valeur 20 d'un nouveau champ d'entête appelé par exemple "ServicelD". On a donné ci-dessous un exemple d'un message INVITE transféré par le serveur 3 au serveur d'application 5 afin de déclencher un service appelé "Service PoC". INVITE sip:bob@domain.com SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 MaxForwards: 70 Route: , From: ;tag=171828 To: Cali-ID: cb03a0s09a2sdfglkj490333 Cseq: 127 INVITE Require: precondition, sec-agree ServicelD: PoCService Contact: Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Content-Type: application/sdp Content-Length: (...) Description SDP (le corps du message contient une description SDP qui n'est pas détaillée ici) Paramètre de l'URI dans le champ ROUTE L'identifiant peut également être un paramètre de l'URI du serveur d'application, présent dans le champ ROUTE du message. On a donné ci-dessous un exemple de message INVITE transféré par le serveur 3 au serveur d'application 5 afin de déclencher le service appelé "Service PoC". INVITE sip:bob@domain.com SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 MaxForwards: 70 Route: , From: ;tag=171828 To: Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 127 INVITE Require: precondition, sec-agree Contact: Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Content-Type: application/sdp Content-Length: (...) Description SDP (le corps du message contient une description SDP qui n'est pas détaillée ici) Paramètre de request-URI L'identifiant peut encore être un paramètre de request-URI. 2873881 6 On a donné ci-dessous un exemple de message INVITE transféré par le serveur 3 au serveur d'application 5 afin de déclencher le service appelé "Service PoC". Cette solution permet d'avoir une compatibilité ascendante avec l'ancienne version SIP (RFC 2543). INVITE sip: ApplicationServer1ehome.net; serviceID ="PoCService" SIP/1.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp; branch=z9hG4bKnashds7 Max-Forwards: 70 Route: , From: ;tag=171828 To: Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 127 INVITE Require: precondition, sec-agree Contact: Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Content-Type: application/sdp Content-Length: G.) Description SDP (le corps du message contient une description SDP 25 qui n'est pas détaillée ici) Insertion dans le corps du message SIP L'identifiant peut également être incorporé dans le corps du message. Lorsque l'identifiant associé à la logique de service est introduit dans le corps du message, cela peut être fait par exemple en spécifiant un nouveau type de contenu ou en utilisant une description XML. Dans le cas du réseau IMS notamment, l'identifiant de service est par exemple contenu comme nouvel élément XML appelé dans la description XML du profil de l'utilisateur. Dans ce cas, le serveur SIP 3 peut insérer l'identifiant de service sous forme d'un élément XML dans le corps du message. 2873881 7 Si le message reçu par le serveur SIP 3 contient déjà un corps, le type du contenu peut être modifié à "multipart/mixed'. Sinon, le type de contenu peut être, notamment dans le cas du réseau IMS "application/3gpp-ims+xml". On a donné ci-dessous un exemple de message INVITE transféré par le serveur 3 au serveur d'application 5 afin de déclencher le service appelé "Service PoC". INVITE sip:bob@domain.com SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 MaxForwards: 70 Route: , From: ;tag=171828 To: Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 127 INVITE Require: precondition, sec-agree Contact: Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Content-Type: application/3gpp-ims+xml Content-Length: (...) PoCService Valeur d'un champ d'entête existant L'identifiant peut encore être la valeur d'un champ d'entête (header) existant. On a donné ci-dessous un exemple de message INVITE transféré par le serveur SIP 3 au serveur d'application 5 afin de déclencher le service appelé "Service PoC". INVITE sip:bob@domain.com SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 MaxForwards: 70 Route: , From: ;tag=171828 To: 2873881 8 Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 127 INVITE Require: precondition, sec-agree Subject: PoCService Contact: Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Content-Type: application/sdp Content-Length: (...) Description SDP (le corps du message contient une description SDP qui n'est pas détaillée ici) Dans une variante de mise en oeuvre de l'invention, une adresse URI différente est associée à chaque service. Utilisation d'URI différentes Un serveur d'application aura autant d'URI que de logiques de service hébergées. Le serveur d'application peut alors se fonder sur l'URI, présente dans le champ 20 ROUTE du message SIP reçu, pour savoir à quelle logique de service ce message doit être transféré. Par exemple, si le serveur d'application héberge deux logiques de service, par exemple servicel et service2, les deux URI "sip:AS.servicel@domain. com" et sip:AS.service2@domain.com" peuvent être respectivement associées à ces services. Critères de filtrage L'identifiant associé à une logique de service introduit dans la base de données 4 et chargée par le serveur SIP 3 avec le profil de l'utilisateur peut être incorporé aux filtres permettant au serveur SIP 3 de router un message vers le serveur d'application adéquat. Dans le cas du réseau IMS, l'identifiant associé à la logique de service est avantageusement intégré aux critères de filtrage iFC transmis par la base de données 4 au serveur SIP 3, conformément à la norme TS24.229. L'identifiant peut ainsi être ajouté dans les critères de filtrage iFC et envoyé dans le message émis par le serveur SIP 3 vers le serveur d'application 5, le serveur 2873881 9 d'application 5 utilisant l'identifiant pour déterminer la logique de service devant s'exécuter pour traiter le message. L'exemple qui suit, est un extrait du fichier CxDataType.xsd associé à la spécification TS 29.228 du standard 3GPP. Ce fichier qui contient la description de types données (DataType) XML concernant le réseau IMS contenues dans la base de données 4, illustre l'ajout dans les critères de filtrage iFC d'un identifiant de service intitulé par exemple "ServicelD". Ainsi, ceux-ci comporteront en plus de l'URI du serveur d'application à invoquer, une infoitiiation supplémentaire concernant la logique de service qui doit être 10 déclenchée. Le fichier précité peut être modifié par l'ajout de comme suit: 20 Dans le cas du réseau IMS, lorsque le serveur SIP 3 applique des critères de filtrage iFC à un message SIP, si ce dernier satisfait aux critères de filtrage et si cet iFC contient un élément "ServicelD", le serveur SIP 3 ajoutera un paramètre ServicelD contenant le valeur de l'élément XML ServicelD, à l'URI du serveur d'application spécifié dans l'iFC, avant de l'insérer en entête de la liste des URI du champ ROUTE. Lorsque le serveur d'application 5 reçoit un message SIP provenant du serveur SIP 3, si son URI qui est présente en entête de la liste des URI du champ ROUTE contient le paramètre "ServicelD", le serveur d'application 5 se fondera sur la valeur de ce paramètre pour décider à quelle logique de service remettre le message. 2873881 10 Par ailleurs, dans le cadre d'utilisation d'URI différentes, le serveur d'application doit permettre d'associer une URI à chaque logique de service. Il doit aussi accepter de recevoir des messages SIP destinés à des adresses différentes. Bien entendu, l'invention n'est pas limitée aux exemples de réalisation qui 5 viennent d'être décrits, et peut s'appliquer à des réseaux autres que le réseau IMS. Dans toute la description et les revendications, l'expression "comportant un" doit être comprise comme étant synonyme de "comportant au moins un". 11 REVENDICATIONS, 1. Procédé permettant l'exécution d'une logique de service parmi une pluralité de logiques de service hébergées dans un serveur d'application (5) d'un réseau opérant sous le protocole de signalisation SIP, ce réseau comportant un serveur SIP (3), notamment un serveur S-CSCF, recevant des messages provenant d'utilisateurs (2) devant accéder à l'une des logiques de service et adressant des messages au serveur d'application, procédé dans lequel on associe à chaque logique de service, une adresse URI ou un identifiant qui est inséré dans le message transféré par le serveur SIP (3) au serveur d'application (5). 2. Procédé selon la revendication 1, caractérisé par le fait que l'identifiant est inséré par le serveur SIP (3) dans le message SIP destiné au serveur d'application (5). 3. Procédé selon la revendication 2, caractérisé par le fait que l'identifiant est inséré comme valeur d'un nouveau champ d'entête. 4. Procédé selon la revendication 2, caractérisé par le fait que l'identifiant est 15 inséré comme paramètre de l'URI du serveur d'application présent dans le champ ROUTE du message. 5. Procédé selon la revendication 2, caractérisé par le fait que l'identifiant est inséré comme paramètre de request-URI. 6. Procédé selon la revendication 2, caractérisé par le fait que l'identifiant est 20 inséré dans le corps du message SIP. 7. Procédé selon la revendication 2, caractérisé par le fait que l'identifiant est inséré comme valeur d'un champ d'entête existant. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé par le fait que l'identifiant associé à la logique de service est incorporé dans les filtres utilisés par le serveur SIP (3) concernant les conditions d'invocation des logiques de service. 9. Procédé selon l'une quelconque des revendications précédentes, caractérisé par le fait que, dans le cas du réseau IMS, l'identifiant est inclus dans l'iFC correspondant à ce service. 10. Réseau comportant: un serveur SIP (3), notamment un serveur S-CSCF, un serveur d'application (5) comportant plusieurs logiques de service, 2873881 12 - une base de données (4) comportant les profils des utilisateurs, réseau caractérisé par le fait que la base de données (4) comporte un identifiant associé à une logique de service du serveur d'application ou une adresse URI associée à une logique de service du serveur d'application. 11. Réseau selon la revendication 10, caractérisé par le fait que le réseau est le réseau IMS.