FR2958820A1 - Routage de requetes sip - Google Patents

Abstract

L'invention se rapporte notamment à un procédé de routage d'une requête SIP (RQ) provenant d'un dispositif source (UAC) par un serveur mandataire (PROXY) vers un dispositif destinataire (UAS), dans lequel on associe audit identifiant de destinataire (ID) au moins deux branches (BRI, BR2) en mettant en œuvre une interface de gestion SIP (SS API) du serveur mandataire (PROXY). Le serveur mandataire (PROXY) route la requête SIP (RQ) via au moins lesdites deux branches (BRI, BR2). Ladite interface de gestion identifie chacune des branches (BRI, BR2) par un identifiant unique (UID1, UID2). L'invention concerne également un serveur mandataire (PROXY) mettant en œuvre ledit procédé, ainsi qu'un système (S) comprenant un tel serveur mandataire (PROXY) et un premier et deuxième serveurs d'application (SA1, SA2).

Description

ROUTAGE DE REQUETES SIP

L'invention concerne le routage de requêtes SIP (pour « Session Initiation Protocol »).

Elle se rapporte plus spécifiquement à une mise en oeuvre d'un serveur mandataire capable de router des requêtes SIP vers plusieurs destinations.

Le protocole SIP est apparu dans les années 1990. Il a été standardisé par l'Internet Engineering Task Force (IETF). Il a connu certaines évolutions évoquées ci-dessous. Ce protocole a été conçu en réponse à une volonté de faire converger la téléphonie et l'informatique. Le protocole SIP a été conçu pour établir, modifier et terminer des sessions multimédia de toutes sortes. Le protocole SIP ne s'intéresse pas au transport des données multimédia proprement dites (qui peuvent être échangées à l'aide d'autres protocoles, tels que le protocole « Real Time Transport Protocol » ou « RTP »), mais plutôt à l'établissement de la session elle-même. Le protocole SIP s'inspire du protocole HTTP. Il partage avec ce dernier le type de codage (mode texte, à savoir codage en caractères ASCII). Toutefois, à la différence du protocole HTTP, le protocole SIP permet à chaque agent de se comporter à la fois comme client et comme serveur. Dans le contexte SIP, un client est un élément du réseau qui est à même d'envoyer des requêtes SIP. Les clients SIP peuvent ou non interagir directement avec un utilisateur humain. Les agents utilisateurs ou les serveurs mandataires SIP peuvent être des clients SIP. Dans le contexte SIP, un serveur est un élément du réseau qui est à même de recevoir des requêtes SIP afin de les traiter et de retourner une réponse à ces requêtes. Les agents utilisateurs ou les serveurs mandataires SIP peuvent également agir en tant que serveurs SIP. D'autres exemples de serveurs SIP comprennent les serveurs de redirection (« redirect servers » en anglais), qui sont capables de rediriger une requête SIP vers un destinataire autre que le destinataire initial, ou encore les registres SIP (décrits ci-dessous).

Une requête SIP est un message SIP envoyé d'un client à un serveur, dans le but d'invoquer une opération particulière du serveur. Une réponse SIP est un message SIP envoyé d'un serveur à un client, afin d'indiquer le statut de la requête envoyée du client au serveur. Dans la terminologie SIP, les messages sont des données échangées entre des éléments SIP selon le protocole SIP.

Le terme « appel » (call en anglais) est quant à lui utilisé de manière informelle pour se référer à une communication entre pairs, généralement mise en place dans le but d'effectuer une conversation multimédia. Une architecture SIP met en jeu essentiellement trois types d'acteurs que sont les registres SIP (en anglais « Registrar »), les serveurs mandataires (en anglais « Proxy »), et les agents utilisateurs (en anglais « User Agent » ou « UA »). Un registre SIP maintient une liste d'agents utilisateurs, qui doivent typiquement s'enregistrer auprès de lui. Les agents utilisateurs informent en principe le registre SIP de tout changement. Par exemple, dans le cas d'un agent utilisateur mobile, un changement de position géographique peut induire un changement d'adresse IP. La liste d'agents utilisateurs du registre SIP comprend notamment, pour chaque agent utilisateur, l'adresse IP de cet agent utilisateur ainsi que son identifiant uniforme de ressource (en anglais « Uniform Resource Identifier » ou URI). L'identifiant uniforme de ressource (par la suite URI) est une chaîne de caractères (généralement courte) permettant d'identifier une ressource de manière permanente sur un réseau. Il peut s'agir d'une ressource logicielle (telle qu'un serveur web, par exemple un serveur « Apache » particulier), ou matérielle (telle qu'un ordinateur, par exemple un serveur physique hébergeant le serveur Apache précité). La syntaxe d'un URI est spécifiée dans le RFC 3986 de janvier 2005. Dans le cadre du protocole SIP, les URI prennent une forme semblable à une adresse e-mail, par exemple : sip:user@domain.com.

Un serveur mandataire est une entité intermédiaire qui agit à la fois en tant que serveur et client dans le but d'émettre des requêtes pour le compte d'autres clients. Un serveur mandataire SIP permet en particulier à un agent utilisateur d'atteindre d'autres agents utilisateurs en consultant une base de données de Registre SIP. Un serveur mandataire SIP permet en effet, en s'appuyant sur l'URI d'un agent utilisateur serveur (au sein d'un dispositif destinataire) fourni par un agent utilisateur client (au sein d'un dispositif source initiateur d'une session SIP), l'établissement de la session SIP, en routant une requête SIP de l'agent utilisateur initiateur de la session SIP vers l'agent utilisateur destinataire ou vers une entité «plus proche» de cet agent utilisateur destinataire. Deux agents utilisateurs pourraient éventuellement communiquer entre eux sans l'intervention d'un serveur mandataire SIP s'ils connaissaient leurs adresses IP respectives, mais c'est rarement le cas. En effet, indépendamment du fait qu'une adresse IP est pour de nombreuses personnes difficile à mémoriser (plus difficile qu'un URI, qui ressemble à une adresse email), l'adresse IP peut changer. L'adresse IP peut également être une adresse interne non routable d'un intranet. Un agent utilisateur est une entité logique qui peut agir à la fois en tant que client (agent utilisateur client ou en anglais « User Agent Client », en abrégé UAC) et en tant que serveur (agent utilisateur serveur ou en anglais «User Agent Server », en abrégé UAS). Un UAC est plus précisément une entité logique capable de créer une nouvelle requête SIP, puis d'utiliser une machine d'état de transaction client (en anglais « client transaction state machinery ») pour l'envoyer. Le rôle d'un UAC ne persiste que pendant la durée de cette transaction. En d'autres termes, si un élément de logiciel initie une requête SIP, il agit comme UAC pendant la durée de cette transaction. Si ce même élément logiciel reçoit ultérieurement une requête SIP et y répond, il assume alors le rôle d'UAS pendant le traitement de cette transaction ultérieure. Un UAS peut donc être une entité logique capable de générer une réponse SIP à une requête SIP.

La réponse SIP consiste à accepter, rejeter ou rediriger la requête SIP. Comme pour l'UAC, le rôle d'UAS ne persiste que pour la durée de la transaction courante. En d'autres termes, si un élément logiciel répond à une requête SIP, il agit comme UAS pour la durée de cette transaction. S'il génère ultérieurement une requête SIP, il assumera alors le rôle d'UAC pour cette nouvelle transaction. Un exemple particulier d'agent utilisateur est l'agent utilisateur adossé (en anglais « Back-to-Back User Agent », en abrégé B2BUA). Un B2BUA est une entité logique en mesure de recevoir une requête SIP et de la traiter en tant qu'UAS. Afin de déterminer la réponse à apporter à la requête, le B2BUA agit alors en tant qu'UAC et génère une ou plusieurs requêtes. Contrairement à un serveur mandataire, le B2BUA maintient un état du dialogue et doit participer à toutes les requêtes envoyées dans le cadre du dialogue qu'il a établi. Le B2BUA est en fait la concaténation d'un UAC et d'un UAS. Les agents utilisateurs prennent typiquement la forme d'un logiciel que l'on peut charger dans un dispositif de communication tel qu'un téléphone SIP, un « softphone » ou une passerelle SIP. Un téléphone SIP est un appareil ayant généralement l'apparence d'un téléphone fixe ou portable conventionnel mais utilisant le protocole SIP. Un « softphone » est par synecdoque un ordinateur fixe ou portable conventionnel connecté à Internet, sur lequel un logiciel de voix sur IP (en l'occurrence un logiciel agent utilisateur SIP) a été installé, lui permettant ainsi d'émettre et/ou de recevoir des appels SIP. Le terme softphone se réfère plus strictement au seul logiciel de voix sur IP, indépendamment du matériel sur lequel il a été installé. Une passerelle SIP est un équipement de réseau permettant par exemple de convertir un appel SIP en appel selon un autre protocole tel qu'un appel analogique conventionnel. Un agent utilisateur initiateur d'une session SIP envoie typiquement des messages (requêtes SIP) à un agent utilisateur destinataire, dont il attend une réponse. Les messages SIP les plus courants comprennent notamment le message INVITE, qui permet à un client de demander l'ouverture d'une session, le message ACK qui confirme l'ouverture d'une session préalablement requise, le message CANCEL qui permet d'annuler le traitement d'un message INVITE en cours, le message BYE qui permet de mettre fin à une session, le message OPTIONS qui permet d'obtenir des informations de la part d'un agent ou d'un serveur mandataire sur ses capacités (types de contenus, méthodes supportées, types de codecs, etc.), ou encore le message REGISTER qui permet notamment de créer ou de supprimer des liens.

Dans la terminologie SIP, une méthode est la fonction principale qu'une requête cherche à faire exécuter par un serveur. Une méthode SIP fait partie du message SIP lui-même. Par exemple, INVITE et BYE sont des méthodes qui font partie d'un message correspondant. Par abus de langage on parle de message INVITE ou de message BYE. Le terme « méthode » est également utilisé dans le cadre de l'interface SipServlet, il a alors un sens différent.

Une requête SIP valide formulée par un UAC doit au minimum contenir (selon le RFC 3261) les champs d'en-tête suivants: To, From, CSeq, Call-ID, Max-Forwards, et Via. Ces champs d'en-tête sont requis dans toutes les requêtes SIP. Ces six champs d'en-tête permettent, en combinaison, de fournir la plupart des services de routage, y compris l'adressage des messages, le routage des réponses, la limitation de la propagation des messages, le tri des messages, et l'identification unique des transactions. Ces champs d'en-tête complètent la ligne de requête, obligatoire, qui comprend le champ méthode, le champ Request-URI, et le champ indiquant la version de SIP. La valeur initiale du champ Request-URI d'un message SIP doit être égale à l'URI spécifié dans le champ To, sauf notamment dans le cas des messages comprenant la méthode REGISTER. Il peut également être non désirable pour des raisons de protection de la vie privée de fixer ces deux champs à la même valeur, en particulier si l'UA envoyant le message s'attend à ce que le champ Request-URI soit modifié durant le transit. Dans certaines circonstances particulières, la présence d'un ensemble de routes préexistant peut affecter le champ Request-URI d'un message. Un ensemble de routes préexistant est un ensemble ordonné d'URIs qui identifie une chaîne de serveurs auxquels un UAC doit envoyer les requêtes sortantes qui sont extérieures à un dialogue. Habituellement, cet ensemble de routes préexistant est configuré sur l'UA par un utilisateur ou un fournisseur de services, manuellement ou à travers des mécanismes sortant du cadre de SIP. Lorsqu'un fournisseur de services souhaite configurer un UA avec un serveur mandataire sortant, il est recommandé qu'il le fasse en lui fournissant un ensemble de routes préexistant avec un URI unique, à savoir celui du serveur mandataire sortant. Lorsqu'un ensemble de routes préexistant est présent, la manière de remplir le champ Request-URI et le champ en-tête Route est spécifiée à la Section 12.2.1.1 du RFC 3261, et utilise le Request-URI désiré comme URI cible distant.

Le champ d'en-tête To identifie le récepteur original de la requête tel que désigné par l'utilisateur identifié dans le champ From. Ce récepteur original peut être ou ne pas être PUAS traitant la requête, en raison par exemple de transferts d'appels ou d'autres opérations effectuées par un serveur mandataire. En revanche, le champ Request-URI identifie PUAS qui doit traiter la requête. Alors que des versions antérieures de SIP, telles que celle décrite dans le RFC 2543 de mars 1999, ne permettaient qu'un routage ultérieurement qualifié de routage strict (en anglais strict routing), la dernière version disponible, décrite dans le RFC 3261 de juin 2002 permet un mode de routage dit routage souple (en anglais loose routing). L'expression «routage strict» n'a été introduite que dans le cadre du RFC 3261, qui précise dans sa version définitive que le routage d'un serveur mandataire est qualifié de routage strict s'il suit les règles de traitement du RFC 2543 ainsi que de nombreuses versions de travail de ce RFC 3261 (avant sa finalisation). Cette règle de routage strict conduisait les serveurs mandataires à détruire le contenu du champ Request-URI quand un champ en-tête route (en anglais Route header field) était présent. Le routage strict n'est de préférence plus utilisé dans le cadre du RFC 3261, en faveur d'un routage souple. Les serveurs mandataires qui effectuent un routage strict sont parfois appelés routeurs stricts. Un serveur mandataire effectue un routage dit souple s'il suit les procédures définies dans le RFC 3261 afin de traiter le champ en-tête route. Ces procédures séparent la destination de la requête (présente dans le champ Request-URI) de l'ensemble (présent dans le champ en- tête route) des serveurs mandataires qui doivent être visités le long du trajet. Un serveur mandataire compatible avec ces mécanismes peut également être qualifié de routeur souple. Les opérateurs de téléphonie ont défini une architecture dénommée IMS (pour IP Multimedia Subsystem), permettant de fournir des services multimédias fixes et mobiles. A partir d'une implémentation 3GPP standardisée du protocole SIP, l'IMS met en place, en particulier, une technologie de voix sur IP. L'IMS supporte les technologies de commutation de paquets et de commutation de circuits existantes. Au-delà de la possibilité de mettre en place des services nouveaux sur Internet, l'IMS vise à accroître la mobilité des utilisateurs en permettant le roaming et en effaçant autant que possible la distinction entre le domicile de l'utilisateur et le monde extérieur. IMS constitue ainsi une avancée importante en matière de convergence de la téléphonie et celui de 1'lnternet. IMS combine un accès quasiment universel au réseau grâce aux technologies cellulaires, sans fil ou fixe (1'IMS se voulant indépendant du type de réseau), et une possibilité de services extrêmement large grâce aux technologies Internet.

Aujourd'hui les communications VoIP reposent donc souvent sur le protocole SIP avec un coeur de réseau IMS. Les services mis en oeuvre dans cette infrastructure sont typiquement hébergés sur des serveurs d'applications invoqués par le coeur de réseau IMS. L'architecture des différents services invoqués par le coeur de réseau peut amener à utiliser un serveur principal (typiquement un serveur mandataire SIP tel que défini au chapitre 16 du RFC 3261) en charge de distribuer lui-même, avec le protocole SIP, les requêtes vers d'autres serveurs, typiquement des serveurs d'applications. Ce procédé est appelé « forking » en anglais. Dans le contexte de l'IMS, le routage des requêtes utilise préférentiellement une particularité de la dernière version de la norme SIP rappelée ci-dessus (RFC 3261), à savoir le routage souple. Le routage souple offre en effet un moyen robuste de router les messages SIP via les multiples éléments du réseau tout en garantissant que le champ Request-URI de la requête SIP reste inchangé tout au long de son parcours jusqu'au serveur chargé de son traitement final. Un grand nombre d'applications SIP est développé à partir d'une technologie appelée SipServlet. La version 1.0 de SipServlet date du 4 février 2003, et désormais c'est la version 1.1 du ter aout 2008 qui est la version en vigueur. La version 1.0 est donc légèrement postérieure au RFC 3261 qui a introduit le routage souple, quant à la version 1.1, elle a été publiée plus de six ans après le RFC 3261. SipServlet est une interface de haut niveau. Elle est souvent développée en langage Java. Elle fait d'ailleurs l'objet d'un "Java Specification Requests" (en abrégé JSR), plus précisément le JSR 289. En langage Java, les données (appelées «propriétés ») et les codes les manipulant (appelés «méthodes ») sont combinés dans une même entité appelée «classe d'objet ». L'interface SipServlet propose un certain nombre de fonctions qui peuvent être invoquées par des entités extérieures, et ces fonctions sont appelées « méthodes » (car elles sont en général mises en oeuvre sous forme de méthode Java). Par exemple, la méthode createProxyBranches() définie au chapitre 10.2.1 permet de créer une nouvelle branche. Il convient de bien distinguer une méthode SIP d'une méthode de l'interface SipServlet. SipServlet, en tant qu'interface de haut niveau, permet de faciliter le développement de services dans le contexte SIP, tels que des services offerts par un serveur mandataire.

SipServlet offre en effet une API simple basée sur le protocole SIP, à même de spécifier le fonctionnement des serveurs chargés d'exécuter ces services. Le mode serveur mandataire SIP est lui-même défini dans la spécification SipServlet. Cependant SipServlet, même dans sa dernière version (1.1), précise au point 10.2.4.2 (intitulé « Correlating responses to proxy branches ») que lorsqu'un serveur mandataire crée plusieurs branches et reçoit une réponse à une requête de la part d'une des branches, la branche est identifiée par le champ Request-URI du message. Certes, en raison du routage souple, on sait que ce champ est désormais inchangé (sauf en cas de fonctionnement en mode de rétrocompatibilité avec l'ancien mode de routage strict). Cependant, en raison du routage souple, un même message pourrait emprunter différentes branches, et le champ Request-URI du message n'est ainsi pas nécessairement suffisant pour identifier une branche donnée. Malheureusement, l'interface SipServlet n'est donc pas utilisable en mode de serveur mandataire, lorsque l'on souhaite router une requête vers plusieurs destinations (plusieurs "branches") séquentiellement ou en parallèle, car la méthode de création de branches est elle-même restreinte à l'identification d'une branche par le champ Request-URI du message envoyé sur cette branche. Ceci est illustré dans l'extrait de 1 0 source code Java ci-dessous montrant une création de branches typique : // récupération d'un objet proxy permettant // à l'application considérée d'agir en mode proxy Proxy proxy = theSipRequest.getProxy(); // contruction de la liste des branches vers lesquelles // l'application va router séquentiellement la requête List<URI> listOfRequestURI = new ArrayList<URI>O; 20 // création des branches dans le proxy proxy.createProxyBranches(listOfRequestURl); // envoi des requêtes proxy. startProxy(); 25 Le code ci-dessus montre que la liste des branches à fournir au serveur mandataire SIP (proxy) s'appuie sur une liste d'identifiants Request-URI, ce qui impose que les identifiants Request-URI des différentes branches soient distincts les uns des autres. Ceci n'est pas compatible avec les contraintes du mode de routage souple largement utilisé notamment dans 30 le cadre l'IMS, et dont l'usage est recommandé de façon générale depuis 2002 pour toutes les applications SIP. Le mode serveur mandataire de l'API SipServlet permet en effet un routage 15 des requêtes via différentes branche (forking) par l'ajout d'en-têtes Route dans la requête lorsque l'on utilise le routage souple (qui ne modifie pas le champ request-URI), mais ne traite pas le cas du routage souple dans le contexte de la création de branche. En particulier, chaque branche est identifiée par un identifiant dont l'unicité n'est pas garantie, ce qui rend l'interface inopérante dans ce contexte. Cette contrainte importante de la spécification SipServlet a jusqu'ici imposé aux industriels de développer les serveurs mandataires devant offrir les fonctions ci-dessus via une application beaucoup plus compliquée (de type B2BUA, dont le principe de fonctionnement a été rappelé ci-dessus) ou à utiliser une autre technologie que SipServlet, plus bas niveau (par exemple de type JAIN SLEE ou simple pile SIP). Ces alternatives sont beaucoup plus coûteuses en termes de développement. JAIN SLEE (également appelé JSLEE) est issu du programme JAIN (Java APIs for Integrated Networks). Le programme JAIN se consacre au développement d'interfaces (APIs) pour la création de services téléphoniques (voix et données). JSLEE a été standardisé dans JSR 22 and JSR 240.

L'invention vient améliorer la situation. L'invention concerne notamment un procédé de routage d'une requête SIP. La requête SIP provient d'un dispositif source. La requête SIP est routée par un serveur mandataire vers un agent utilisateur serveur destinataire identifié de manière conventionnelle par un identifiant de destinataire au sein de la requête SIP. L'agent utilisateur serveur destinataire est installé dans un dispositif destinataire. Dans le protocole SIP, l'agent utilisateur serveur destinataire n'est pas nécessairement associé de manière biunivoque à un destinataire humain ni à un dispositif destinataire. Dans le cas général un utilisateur humain peut disposer de plusieurs dispositifs (par exemple un téléphone portable très léger mais peu performant ainsi qu'un téléphone portable très performant mais plus encombrant). Inversement, un dispositif donné peut être commun à plusieurs destinataires. Les différents membres d'une famille (parents et enfants) peuvent notamment utiliser un même dispositif De surcroît, un utilisateur humain disposant d'un unique dispositif dont il est le seul utilisateur peut néanmoins disposer de plusieurs profils. Par exemple un profil peut être attaché à l'utilisateur en tant qu'employé d'une société (utilisation professionnelle), et un autre profil peut être attaché à l'utilisateur en tant que particulier (utilisation à titre privé). Chaque profil peut correspondre à une instance particulière d'un logiciel agent utilisateur serveur installé dans le terminal de télécommunication. Il est également envisageable qu'un utilisateur humain unique dispose de plusieurs versions d'un logiciel agent utilisateur serveur au sein de son terminal de télécommunication. Ceci pourrait se produire notamment en cas de mise à jour logicielle d'un agent utilisateur, la mise à jour posant des problèmes de rétrocompatibilité, lorsque l'utilisateur humain souhaite pouvoir communiquer aussi bien avec l'ancien que le nouveau système. Ceci pourrait également se produire en cas de versions différentes du logiciel agent utilisateur serveur, une version pouvant par exemple comporter plus de fonctionnalités mais ne pas être acceptée par tous les réseaux (en raison par exemple de certains pare-feu), l'autre offrant des fonctionnalités plus restreintes mais étant tolérée par un éventail plus large d'environnements réseaux. Il est également possible que différents utilisateurs humains utilisent un même identifiant de destinataire, par exemple tous les membres d'une équipe pourraient partager le même identifiant de destinataire, de même que ces membres peuvent utiliser une adresse email commune telle que equipe_x@societe-y.com. Le procédé comporte une association dudit identifiant de destinataire à au moins deux branches en mettant en oeuvre une interface de gestion SIP du serveur mandataire. Le procédé comporte un routage par le serveur mandataire de la requête SIP via au moins lesdites deux branches. Le procédé comporte une identification par ladite interface de gestion de chacune des branches par un identifiant unique. L'interface du procédé peut être avantageusement une interface de haut niveau. En effet, ce procédé permet de bénéficier d'une interface de gestion SIP simple et rapide à mettre en oeuvre, contrairement en particulier à des interfaces de bas niveau décrites plus haut, telles que les piles SIP ou les interfaces JAIN SLEE. Ce procédé évite également de recourir à des applications additionnelles spécialement développées pour pallier le problème de l'insuffisance des interfaces haut niveau existantes, et qui pourraient avoir un impact sur les performances de l'appel (durée d'établissement de l'appel, etc.). Selon un mode de réalisation possible, l'identifiant de destinataire est un identifiant de type Request-URI, et l'interface de gestion SIP est une interface de type SipServlet modifiée. Le procédé comprend une étape de création de branches par une fonction de l'interface SipServlet modifiée. Par le terme « fonction », on entend ici une « méthode » dans la terminologie SipServlet. Ladite fonction accepte en entrée un identifiant unique pour chaque branche, au lieu d'un identifiant de type Request-URI qui peut être commun à plusieurs branches. Ceci est avantageux car les interfaces de type SipServlet sont des interfaces de haut niveau et constituent un choix privilégié pour l'implémentation des serveurs mandataires, mais les limitations de cette interface la rendent impropre à l'utilisation envisagée. Ce mode de réalisation permet de concilier le routage souple avec différentes branches associées à un même champ Request-URI, et l'utilisation d'une interface SipServlet légèrement modifiée. Selon un mode de réalisation possible d'un procédé selon l'invention, l'identifiant unique est une chaîne de caractères. Ceci peut avantageusement permettre, notamment, une inspection plus aisée par un humain (par exemple pour faciliter un débogage, ou encore pour une investigation numérique légale sur un système en place qui aurait été utilisé à des fins criminelles). Ceci peut également dans une certaine mesure minimiser les modifications à l'interface, qui parfois utilise déjà, dans le cas de l'interface SipServlet notamment, un identifiant (non unique) en mode texte. Selon un mode de réalisation possible, l'identifiant unique est attribué par une application du serveur mandataire. Il peut s'agir notamment d'une application par ailleurs chargée de « forker » les requêtes. Ceci peut avantageusement éviter au serveur mandataire de dépendre d'une entité tierce avec laquelle il faudrait mettre en place un protocole de communication, protocole qui devrait en général être suffisamment sécurisé pour qu'il ne devienne pas une source potentielle d'attaques sur le réseau SIP (par exemple en redirigeant une branche critique vers un agent SIP contrôlé par un hacker), ce qui entraînerait une complexité de développement accrue. Selon un mode de réalisation possible du procédé, une première branche a pour destination un premier serveur d'application, et une deuxième branche a pour destination un deuxième serveur d'application. Ceci permet par exemple de disposer de serveurs d'applications redondants (bien que perçus comme deux serveurs logiques distincts) afin de minimiser les temps de réponse et/ou d'accroître la fiabilité en cas de panne. Les serveurs peuvent également contenir des applications non redondantes (par exemple des applications complémentaires, voire des applications totalement distinctes). En particulier, la requête SIP peut être routée séquentiellement via les premier et deuxième serveurs d'application, et le serveur mandataire peut alors ne conserver que la réponse la plus satisfaisante parmi celles obtenues de la part des serveurs d'application en réponse à la requête SIP. Ceci est avantageux en particulier lorsque les deux serveurs fournissent un service similaire, voire redondant. Une réponse peut être qualifiée de plus satisfaisante par exemple si elle permet un routage ultérieur via un nombre plus réduit d'éléments du réseau, ou si elle est associée à une qualité de service (en anglais Quality of Service ou QoS) plus élevée, etc. Alternativement, La requête SIP peut être routée parallèlement via les premier et deuxième serveurs d'application, le serveur mandataire ne conservant que la réponse obtenue le plus rapidement de la part des serveurs d'application en réponse à la requête SIP. Ceci permet par exemple de raccourcir le délai de traitement nécessaire à l'établissement d'un appel. Il se peut par exemple que les deux serveurs soient fonctionnellement similaires, mais que l'un d'eux soit plus chargé que l'autre, ou que les deux serveurs soient régulièrement sollicités pour des tâches exclusives les rendant temporairement indisponibles, l'un pouvant être disponible alors que l'autre ne l'est temporairement pas. Il est naturellement possible de mettre en oeuvre plus de deux serveurs d'application, et d'associer une branche à chacun d'eux.

Selon un mode de réalisation possible, le routage s'opère au sein d'un coeur de réseau IMS. Le coeur de réseau IMS peut invoquer des services hébergés par des serveurs d'application. Ceci est avantageux car l'IMS s'intègre bien avec le protocole SIP qui est l'une de ses composantes essentielles. L'invention concerne également un programme d'ordinateur. Le programme d'ordinateur comporte des instructions pour la mise en oeuvre du procédé précédemment décrit, lorsque ce programme est exécuté par un processeur. Il peut s'agir d'un logiciel chargeable sur un équipement informatique hébergeant le serveur mandataire SIP. L'invention concerne en particulier un support d'enregistrement sur lequel est stocké le programme d'ordinateur précité, notamment un medium de stockage non transitoire d'informations lisibles par ordinateur, tel qu'un CDROM, un DVD, une mémoire telle qu'une RAM protégée par batterie, une mémoire EEPROM, un mémoire ROM, une mémoire FLASH, une carte mémoire (SD, MMC, etc.) un disque dur ou encore une clé USB. L'invention concerne un serveur mandataire comprenant une interface de gestion SIP pour associer deux branches à un même identifiant de destinataire, et pour identifier lesdites branches par des identifiants uniques pour chaque branche. Le serveur mandataire est agencé pour router une requête SIP qui provient d'un dispositif source vers un agent utilisateur serveur destinataire identifié par ledit identifiant de destinataire au sein de la requête SIP via les deux branches. L'agent utilisateur serveur destinataire est installé dans un dispositif destinataire. Ce serveur mandataire SIP offre ainsi une interface de gestion SIP simple et rapide à mettre en oeuvre, contrairement en particulier à des interfaces de bas niveau, telles que les piles SIP ou les interfaces JAIN SLEE. Ce serveur mandataire n'impose pas de recourir à des applications additionnelles spécialement développées pour pallier le problème de l'insuffisance des interfaces haut niveau existantes, et qui pourraient avoir un impact sur les performances de l'appel.

Les différents modes de réalisation du procédé selon l'invention peuvent être transposés au serveur mandataire SIP selon l'invention. En particulier, l'identifiant de destinataire peut être un identifiant de type Request-URI et l'interface de gestion SIP peut être une interface de type SipServlet modifiée, comprenant une fonction de création de branches (telle qu'une méthode createProxyBranches() modifiée) qui accepte en entrée un identifiant unique pour chaque branche. L'identifiant unique peut être une chaîne de caractères. L'identifiant unique peut être attribué par une application du serveur mandataire. Une première branche peut avoir pour destination un premier serveur d'application, une deuxième branche ayant pour destination un deuxième serveur d'application. Dans ce cas, la requête SIP peut être routée séquentiellement via les premier et deuxième serveurs d'application. Il est alors possible que le serveur mandataire ne conserve que la réponse la plus satisfaisante parmi celles obtenues de la part des serveurs d'application en réponse à la requête SIP. Alternativement, la requête SIP peut être routée parallèlement via les premier et deuxième serveurs d'application. Il est alors possible que le serveur mandataire ne conserve que la réponse obtenue le plus rapidement de la part des serveurs d'application en réponse à la requête SIP. Le routage peut s'opérer au sein d'un coeur de réseau IMS. Le coeur de réseau IMS peut alors invoquer des services hébergés par les serveurs d'application. L'invention se rapporte également à un système. Le système comprend un premier serveur d'application, un deuxième serveur d'application, et un serveur mandataire. Le serveur mandataire comprend une interface de gestion SIP pour associer à un même identifiant de destinataire deux branches à destination respectivement du premier et du deuxième serveur d'application, et pour identifier lesdites branches par des identifiants uniques pour chaque branche. Le serveur mandataire est agencé pour router une requête SIP vers un agent utilisateur serveur destinataire identifié par ledit identifiant de destinataire au sein de la requête SIP via les deux branches. L'agent utilisateur serveur destinataire est installé dans un dispositif destinataire Ce système a notamment les avantages que lui confère son serveur mandataire, comme expliqué plus haut. Les différents modes de réalisation du procédé selon l'invention peuvent être transposés au système selon l'invention. En particulier, l'identifiant de destinataire peut être un identifiant de type Request-URI et l'interface de gestion SIP peut être une interface de type SipServlet modifiée, l'interface de gestion SIP comprenant une méthode de création de branches qui accepte en entrée un identifiant unique pour chaque branche. L'identifiant unique peut être une chaîne de caractères. L'identifiant unique peut être attribué par une application du serveur mandataire. La requête SIP peut être routée séquentiellement via les premier et deuxième serveurs d'application. Le serveur mandataire peut alors ne conserver que la réponse la plus satisfaisante parmi celles obtenues de la part des serveurs d'application en réponse à la requête SIP. Alternativement, la requête SIP peut être routée parallèlement via les premier et deuxième serveurs d'application. Le serveur mandataire peut alors ne conserver que la réponse obtenue le plus rapidement de la part des serveurs d'application en réponse à la requête SIP. Le routage peut s'opérer au sein d'un coeur de réseau IMS. Le coeur de réseau IMS peut alors invoquer des services hébergés par les serveurs d'application. D'autres aspects, buts et avantages de l'invention apparaîtront à la lecture de la description d'un de ses modes de réalisation. L'invention sera également mieux comprise à l'aide des dessins, sur lesquels : - la figure 1 illustre la structure d'une requête SIP utilisée dans le cadre d'un mode de réalisation de la présente invention ; - la figure 2 illustre de manière simplifiée une interface de gestion SIP de haut niveau selon un mode de réalisation de la présente invention ; - la figure 3 illustre les principales étapes d'un procédé de routage d'une requête SIP selon un mode de réalisation de la présente invention ; - la figure 4 illustre une architecture de système comprenant un premier et un deuxième serveur d'application ainsi qu'un serveur mandataire selon un mode de réalisation de la présente invention.

La figure 1 illustre la structure d'une requête RQ classique. La requête RQ comprend un en-tête ET et un corps C. L'en-tête ET comprend un identifiant ID. Le corps C de la session peut être décrit par exemple à l'aide du protocole SDP (Session Description Protocol). La requête RQ est encodée en mode texte, ce qui permet de reproduire un exemple d'en-tête ET lisible :

INVITE sip:user2@orange-ftgroup.com SIP/2.0 Via: SIP/2.0/UDP pc007.rennes.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: user2 <sip:user2@orange-ftgroup.com> From: userl <sip:userl@orange-ftgroup.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc007.rennes.com CSeq: 314159 INVITE Contact: <sip:userl@pc007.orange-ftgroup.com> Content-Type: application/sdp Content-Length: 142

La première ligne de l'en-tête ET de la requête RQ contient le nom de la méthode (en l'occurrence INVITE), suivi d'un identifiant ID, suivi par la version de protocole SIP (en l'occurrence la version 2.0). Chacun de ces trois éléments est séparé par un espace simple. L'identifiant ID s'appelle Request-URI dans le RFC 3261. En l'occurrence, l'identifiant ID (à savoir le Request-URI) est : sip:user2@orange-ftgroup.com. La notion de Request-URI a été précédemment expliquée. Le Request-URI est un URI SIP or SIPS URI, comme expliqué à la section 19.1 du RFC 3261, ou un URI général (comme spécifié dans le RFC 2396). Le Request-URI indique l'utilisateur ou le service auquel la requête RQ est adressée. Dans un mode de réalisation, l'utilisateur ou le service correspond à une instance particulière d'un logiciel agent utilisateur serveur. Cet exemple, inspiré des pages 12 et 13 du RFC 3261, contient un ensemble minimum de champs requis par le RFC 3261. Le champ Via contient l'adresse (pc007.rennes.com) à laquelle l'émetteur userl (utilisant en l'espèce un agent utilisateur client représenté sous la référence UAC sur les figures 3 et 4) souhaite recevoir une réponse à sa requête RQ. Ce champ contient un paramètre de branche qui identifie cette transaction (il sera discuté dans le cadre de la figure 2). Le champ To contient un nom affichable (user2) ainsi qu'un URI SIP ou SIPS (en l'occurrence sip:user2@orange-ftgroup.com) vers lequel la requête était originellement dirigée. Les noms affichables sont spécifiés dans le RFC 2822. Le champ From contient également un nom affichable (userl) ainsi qu'un URI SIP ou SIPS (sip:userl@orangeftgroup.com) indiquant qui est à l'origine de la requête. Ce champ contient également un paramètre «tag» contenant une chaîne de caractères aléatoires (1928301774) ajoutée à l'URI par exemple par l'agent utilisateur client UAC ci-dessus. Cette chaîne aléatoire peut être utilisée à des fins d'identification. Le champ Call-ID contient un identifiant globalement unique pour cet appel, typiquement généré par la combinaison d'une chaîne aléatoire et d'un nom ou d'une adresse IP de l'hôte (l'hôte pouvant être un softphone comprenant l'agent utilisateur client UAC ci-dessus). La combinaison des champs To, From et Call-ID définit complètement une relation SIP pair à pair entre userl et user2, ce qui est qualifié de dialogue.

Le champ CSeq (Command Sequence) contient un entier et un nom de méthode SIP (en l'occurrence la méthode INVITE). L'entier est incrémenté pour chaque nouvelle requête du dialogue est constitue un numéro de séquence traditionnel. Le champ Contact contient un URI SIP ou SIPS représentant une route directe vers le contact userl, généralement composé d'un nom d'utilisateur et d'un FQDN (fully qualified domain name). Une adresse IP peut également être utilisée en lieu et place du FQDN. Alors que le champ Via indique aux autres éléments où envoyer la réponse, le champ Contact indique aux autres éléments où envoyer de futures requêtes. Le champ Max-Forwards vise à limiter le nombre de sauts qu'une requête peut faire lors de son trajet vers sa destination. Il s'agit d'un entier qui est décrémenté à chaque saut. Le champ Content-Type contient une description du corps de message C. Le champ Content- Length contient un octet indiquant la longueur du corps du message C. La description complète de tous les champs d'en-tête possibles d'une requête SIP figure à la section 20 du RFC 3261.

La figure 2 illustre de manière simplifiée une interface SS_API de gestion SIP de haut niveau selon un mode de réalisation de la présente invention. L'interface représentée est une interface de type SipServlet version 1.1. Seul un sous ensemble des méthodes disponibles (les méthodes M1 à M6) est représenté. Ne sont pas représentés des éléments autres que les méthodes, de tels éléments pouvant être nécessaires au fonctionnement de l'interface mais n'étant pas indispensables à sa compréhension, et correspondant à ceux d'une interface SipServlet version 1.1 bien connue de l'état de l'art.

La figure 2 représente en particulier des méthodes M1 (createProxyBranchesQ) et M4 (proxyToQ), qui permettent de créer respectivement explicitement et implicitement des branches au niveau du serveur mandataire (proxy). On constate que, les paramètres des différentes méthodes n'étant pas indiqués, la figure 2 correspond également à une interface SipServlet selon l'état de l'art, ce qui illustre le caractère non disruptif des modifications apportées. Selon un mode de réalisation de l'invention, au moins l'une de ces méthodes (et de préférence les deux) est (sont) modifiée(s), et identifie(nt) les branches par un identifiant unique plutôt que par un identifiant de type Request-URI dont on a vu qu'il n'était pas nécessairement unique pour chaque branche (plusieurs branches peuvent avoir le même Request-URI). Par exemple, il est possible de remplacer la méthode M1 1 5 (createProxyBranchesQ) par une nouvelle méthode : public ProxyBranch javax.servlet.sip.Proxy.createProxyBranches (List<String> listOfBranchldentifier); Cette nouvelle méthode createProxyBranches() diffère de l'ancienne par le paramètre d'entrée qui n'est plus de type List<URI> mais de type List<String> (liste de toutes chaînes de 20 caractères). Il est possible et de créer un nouveau type correspondant au format effectivement adopté pour le nouvel identifiant unique selon ce mode de réalisation de l'invention. Ceci permet de faciliter le traitement des paramètres malformés (identifiants uniques mal construits, en raison par exemple d'une erreur, ou en raison d'une attaque par un hacker). L'identifiant unique peut être une chaîne de caractères aléatoires, qui peut être générée par le serveur 25 mandataire ou l'un de ses composant. L'identifiant unique peut également être une concaténation d'informations qui collectivement peuvent identifier une branche de façon unique, telle qu'une combinaison ou une sous combinaison de différents champs de l'en-tête ET (décrits ci-dessus en relation avec la figure 1), ou un hash d'une telle concaténation. L'identifiant unique peut être généré lors de la création de la branche (bien qu'il puisse le cas 30 échéant être généré à l'avance). Il est rare qu'il soit pertinent de le générer après création de la branche (car cela induit généralement une complexité supplémentaire), mais selon l'implémentation cette option est également envisageable. L'identifiant unique peut être totalement décorrélé du champ Request-URI. Ceci peut présenter des avantages en matière de protection de la vie privée, selon le contexte d'utilisation de l'invention. Mais il peut 35 également être corrélé. Il peut notamment être lié au Request-URI par une fonction à sens unique (telle qu'un hash) qui ne permet pas de reconstruire le Request-URI à partir de l'identifiant unique. L'identifiant de branche unique peut être l'identifiant de branche prévu pour le champ Via selon la section 8.1.1.7 du RFC 3261, tel qu'illustré sur la figure 1 (deuxième ligne de l'en-tête ET), sous réserve qu'il soit bien distinct pour chaque branche. Il peut alternativement être construit de la manière spécifiée à la section 8.1.1.7, sans nécessairement être égal à celui du champ Via. Il peut par exemple comprendre une série de caractères choisis arbitrairement de manière à confirmer la nature de l'identifiant unique. Cette série peut par exemple commencer par au moins 7 caractères, la probabilité de choisir 7 caractères identiques étant négligeable. Il peut en particulier s'agir de la série de caractères "z9hG4bK". Cependant, il peut également être judicieux d'utiliser, à la place d'une telle série prédéfinie, un CRC voire un hash (tel que SHA-1) des caractères de l'identifiant unique proprement dit. Cette série est en tout état de cause optionnelle, dans la mesure où l'interface modifiée peut s'attendre à recevoir un identifiant unique selon l'invention, et n'a dans ce cas pas besoin de le distinguer d'un identifiant alternatif qui ne serait pas unique (il n'y a en général pas de tel identifiant alternatif). Il peut même être avantageux d'éviter d'inclure une telle série afin de réduire la consommation mémoire et les traitements processeur, lorsque l'impact sur les performances n'est pas négligeable (notamment pour certains systèmes embarqués à ressources contraintes). Toutes les méthodes manipulant des branches peuvent être modifiées afin de tirer partie du mode d'identification de branche précédemment décrit. L'exemple de la méthode M1 (createProxyBranchesQ) se transpose en effet aux autres méthodes de l'interface, par exemple à la méthode M3 (getProxyBranchesQ) qui renvoie toutes les branches de niveau supérieur associées à un serveur mandataire donné: public ProxyBranch javax.servlet.sip.Proxy.getProxyBranches(String branchldentifier); La méthode M3 (getProxyBranchesQ) utilise ainsi de préférence un type String au lieu du type URI, mais comme indiqué plus haut on pouffait utiliser un nouveau type correspondant à l'identifiant utilisé. Ces méthodes modifiées permettent alors au serveur mandataire de garder le même identifiant Request-URI pour toutes les branches ou de positionner librement les identifiants Request-URI pour chaque branche. Le serveur mandataire peut également ajouter des en-têtes Route dans chaque branche pour définir un chemin souhaité pour chaque requête (le fonctionnement de l'interface SipServlet existante est alors conservé). Selon un mode de réalisation alternatif, on conserve les méthodes existantes manipulant les branches (sans les modifier), et l'on ajoute de nouvelles méthodes (ayant des noms différents) manipulant les branches de la manière décrite ci-dessus, de manière à conserver une compatibilité ascendante pour les applications n'ayant pas été développées pour l'interface SipServlet modifiée selon l'invention. De telles applications souffriront évidemment des problèmes connus de l'état de l'art, mais auront néanmoins la possibilité de fonctionner dans les situations actuellement prises en charge. Il est ainsi possible de conserver l'ancienne méthode M1 (createProxyBranchesQ) et de créer une nouvelle méthode createProxyBranchesUniquelDQ : public ProxyBranch javax.servlet.sip.Proxy.createProxyBranchesUniquelD (String branchldentifier); ou pour une autre méthode (par exemple la méthode M3) : public ProxyBranch javax.servlet.sip.Proxy.getProxyBranchUniquelD (String branchldentifier); Il n'est pas obligatoire de conserver les anciennes méthodes si l'on ne recherche par la compatibilité ascendante, on peut cependant choisir de néanmoins changer le nom des méthodes comme indiqué au paragraphe précédent. Les modifications à apporter aux applications existantes sont minimes puisque le jeu de méthode est similaire et n'implique pas de changement profond d'architecture. La figure 2 représente également des méthodes M2, M5 et M6, qui n'ont pas besoin d'être modifiées dans le cadre de l'invention. La méthode M2 (getProxyQ) permet d'obtenir une instance du serveur mandataire pour une requête donnée. La M5 (méthode setRecordRouteQ) spécifie si oui ou non une branche donnée doit incorporer un en-tête Record-Route. La méthode M6 (startProxyQ) permet notamment d'ajouter de nouvelles adresses à l'ensemble des destinataires vers lesquels le serveur mandataire peut être amené à router des requêtes.

La figure 3 illustre les principales étapes d'un procédé de routage d'une requête SIP selon un mode de réalisation de la présente invention. Y est notamment représenté un agent utilisateur client UAC, qui initie une requête RQ associée à un identifiant de destinataire ID (par exemple un identifiant de type Request-URI tel que décrit en relation avec la figure 1). L'identifiant de destinataire ID identifie un agent utilisateur serveur UAS. Cet agent utilisateur client UAC est, dans un mode de réalisation, un logiciel embarqué au sein d'un téléphone SIP avec lequel un premier utilisateur émet un appel Voix sur IP. La figure 3 montre également un serveur mandataire PROXY, chargé de router la requête RQ vers l'agent utilisateur serveur UAS, lequel est, dans un mode de réalisation possible, un logiciel embarqué au sein d'un autre téléphone SIP qu'un autre utilisateur emploie afin de recevoir l'appel Voix sur IP émis par le premier utilisateur. On constate enfin la présence de deux serveurs d'application SA1 et SA2.

La figure 3 illustre des requêtes envoyées par ordre chronologique de haut en bas (axe du temps t à droite de la figure 3). A l'instant T0, l'agent utilisateur client UAC envoie sa requête RQ vers le serveur mandataire PROXY. La requête comprend l'identifiant de destinataire ID. A l'instant Ti, le serveur mandataire envoie en parallèle la même requête RQ vers les serveurs SA1 et SA2. Cependant, le serveur mandataire a généré pour chacun de ces deux envois un identifiant unique de branche, à savoir l'identifiant UID1 pour la branche BR1 conduisant du serveur mandataire au serveur d'application SA1, et symétriquement l'identifiant UID2 pour la branche BR2 conduisant du serveur mandataire au serveur d'application SA2. Il est ainsi possible de s'appuyer sur une interface SipServlet légèrement modifiée pour gérer le serveur mandataire et en particulier pour créer les branches, bien que les deux branches se rapportent à une même requête RQ associée à un même identifiant de destinataire ID. Ceci est possible notamment à l'aide d'une méthode M1 selon la figure 2. Comme il a été vu précédemment, dans des modes de réalisation alternatifs, les deux branches BR1 et BR2 peuvent être créées séquentiellement, et non simultanément à un même instant Ti comme représenté sur la figure 3. A l'instant T2, le serveur mandataire peut enfin router la requête RQ vers son destinataire (identifié par l'identifiant de destinataire ID), à savoir l'agent utilisateur serveur UAS. Ce mode de fonctionnement du serveur mandataire est avantageux notamment dans le cadre du développement d'un SCIM (Service Capabilities Interaction Manager) tel que spécifié par le 3GPP dans le standard IMS 3GPP TR 23.002, d'un CSCF (élément coeur de l'IMS lui-même), ou de tout autre serveur mandataire comprenant des fonctions de forking dans l'IMS.

La figure 4 décrit un système S illustrant une architecture de système comprenant un premier et un deuxième serveur d'application ainsi qu'un serveur mandataire selon un mode de réalisation de la présente invention. Le système comprend notamment un premier téléphone comprenant un agent utilisateur client UAC à partir duquel un appel est initié à travers un coeur de réseau IMS NET. L'appel a pour destinataire un deuxième téléphone comprenant un agent utilisateur serveur UAS. L'appel est routé via un serveur mandataire PROXY équipé d'un microprocesseur MP. Il arrive que de nouvelles requêtes SIP soient créées de toute pièce par le coeur de réseau IMS NET. Cependant, le serveur mandataire ne crée en principe pas de nouvelles requêtes, il se contente modifier la requête en y insérant par exemple des champs additionnels afin d'indiquer des points de passage. Les serveurs d'application SA1 et SA2 peuvent fournir en particulier des services liés à l'appel. Il peut s'agir notamment de services destinés à enrichir l'appel, tels que des services d'interception d'appels anonymes, des services d'interconnexion d'appels à une messagerie, des services de transferts d'appels, des services d'écriture d'un journal d'appel, etc. Les deux serveurs peuvent offrir des services distincts, mais il peut également s'agir de services équivalents offerts d'une manière différente, par exemple des services d'écriture dans des journaux différents mais équivalents. Les serveurs d'application SA1 et SA2 ainsi que le serveur mandataire PROXY sont des serveurs logiques. Ces serveurs logiques sont exécutés par des serveurs physiques. La figure 4 illustre trois serveurs physiques hébergeant chacun l'un des trois serveurs logiques, cependant il est tout à fait possible de faire héberger les trois serveurs logiques par un même serveur physique. Il est également possible de les faire héberger par deux serveurs physiques, l'un des serveurs physiques hébergeant l'un des serveurs logiques, l'autre serveur physique hébergeant les deux autres serveurs logiques (par exemple les serveurs SA1 et SA2, cependant les autres combinaisons sont également possibles). Il est enfin possible qu'un même serveur logique soit hébergé sur plusieurs serveurs physiques, notamment à des fins de tolérance aux pannes (plusieurs serveurs physiques strictement équivalents assurant ainsi qu'en cas de panne de l'un d'eux, le serveur logique soit toujours opérationnel). Dans ce dernier cas, un seul serveur logique est visible, bien qu'il soit en réalité dupliqué.

Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ci- avant à titre d'exemple ; elle s'étend à d'autres variantes. Ainsi, il a été décrit ci-avant une réalisation dans laquelle le serveur mandataire réalise lui-même la création des branches et leur association avec un identifiant de destinataire ID en envoyant une requête RQ comprenant l'identifiant ID à deux serveurs d'application SA1 et SA2. Cependant, une autre entité telle qu'un élément du coeur de réseau IMS pourrait envoyer des instructions à l'interface de gestion SIP du serveur mandataire, voire effectuer elle-même la création des branches ainsi que leur association avec l'identifiant ID pour le compte du serveur mandataire. Il a été décrit une étape d'association distincte de l'étape de création de branche, mais les deux opérations peuvent être effectuées simultanément, l'identifiant de destinataire ID pouvant être un paramètre d'entrée lors de la création de la branche. Il a été décrit un mode de réalisation à deux branches mais il est évidemment possible de créer plus de deux branches (chacune pouvant avoir pour destination un serveur d'application distinct) et de les associer chacune à un identifiant unique. Une méthode de création de branches modifiée, requérant en paramètres d'entrée une liste d'identifiants uniques, a été décrite. Il est possible de ne pas fournir de liste d'identifiants uniques à la fonction de création de branches, mais, par exemple, de ne lui indiquer que la destination de chacune d'entre elles, la méthode de création de branches générant par la suite elle-même les identifiants uniques (ou déléguant cette tâche de génération d'identifiants uniques à une autre entité, telle qu'une entité du coeur de réseau IMS). Il a été proposé de réutiliser l'interface SipServlet car elle présente des avantages, notamment le fait qu'elle soit normalisée et largement utilisée (donc bien documentée et bien connue des développeurs), cependant toute interface de gestion SIP de haut niveau pourrait être utilisée, y compris une interface complètement propriétaire développée pour l'occasion.

Claims (12)

1. REVENDICATIONS1. Procédé de routage d'une requête SIP (RQ) dans lequel : - la requête SIP (RQ) provient d'un dispositif source, - la requête SIP (RQ) est routée par un serveur mandataire (PROXY) vers un agent utilisateur serveur destinataire (UAS), - l'agent utilisateur serveur destinataire (UAS) est installé dans un dispositif destinataire, - l'agent utilisateur serveur destinataire (UAS) est identifié par un identifiant de destinataire (ID) au sein de la requête SIP (RQ), le procédé comportant : - une association dudit identifiant de destinataire (ID) à au moins deux branches (BR1, BR2) en mettant en oeuvre une interface de gestion SIP (SS_API) du serveur 15 mandataire (PROXY), - un routage par le serveur mandataire (PROXY) de la requête SIP (RQ) via au moins lesdites deux branches (BR1, BR2), - et une identification par ladite interface de gestion du serveur mandataire de chacune des branches (BR1, BR2) par un identifiant unique (UID1, UID2). 20
2. 2. Procédé de routage selon la revendication 1, dans lequel l'identifiant de destinataire (ID) est un identifiant de type Request-URI, l'interface de gestion SIP (SS_API) est une interface de type SipServlet modifiée, dans lequel le procédé comprend une étape de création de branches par une fonction de l'interface SipServlet modifiée, et dans lequel la fonction accepte en entrée un identifiant unique (UID1, UID2) pour chaque branche (BR1, BR2). 25
3. 3. Procédé de routage selon l'une des revendications précédentes, dans lequel l'identifiant unique (UID1, UID2) est attribué par une application du serveur mandataire (PROXY).
4. 4. Procédé de routage selon l'une des revendications précédentes, dans lequel une première branche (BR1) a pour destination un premier serveur d'application (SA1), et dans lequel une deuxième branche (BR2) a pour destination un deuxième serveur d'application (SA2). 30
5. 5. Procédé de routage selon la revendication 4, dans lequel la requête SIP (RQ) est routée parallèlement via les premier et deuxième serveurs d'application (SA1, SA2), et dans lequel le serveur mandataire (PROXY) ne conserve que la réponse obtenue le plus rapidement de la part des serveurs d'application (SA1, SA2) en réponse à la requête SIP (RQ).
6. 6. Procédé de routage selon l'une des revendications précédentes, dans lequel le routage 35 s'opère au sein d'un coeur de réseau IMS (IMS NET). 10
7. 7. Programme d'ordinateur, dans lequel le programme comporte des instructions pour la mise en oeuvre du procédé selon l'une des revendications précédentes, lorsque ce programme est exécuté par un processeur (MP).
8. 8. Support d'enregistrement sur lequel est stocké le programme d'ordinateur selon la revendication 7.
9. 9. Serveur mandataire (PROXY) caractérisé en ce qu'il comprend une interface de gestion SIP (SSAPI) pour associer à un même identifiant de destinataire (ID) deux branches (BR1, BR2) et pour identifier lesdites branches (BR1, BR2) par des identifiants (UID1, UID2) uniques pour chaque branche (BR1, BR2), dans lequel le serveur mandataire (PROXY) est agencé pour router une requête SIP (RQ) qui provient d'un dispositif source vers un agent utilisateur serveur destinataire (UAS) identifié par ledit identifiant de destinataire (ID) au sein de la requête SIP (RQ) via les deux branches (BR1, BR2), dans lequel l'agent utilisateur serveur destinataire (UAS) est installé dans un dispositif destinataire.
10. 10. Serveur mandataire SIP (PROXY) selon la revendication 9, dans lequel l'identifiant de destinataire (ID) est un identifiant de type Request-URI, l'interface de gestion SIP (SSAPI) est une interface de type SipServlet modifiée, et l'interface de gestion SIP (SS_API) comprend une fonction de création de branches qui accepte en entrée un identifiant unique (UID1, UID2) pour chaque branche (BR1, BR2).
11. 11. Système (S), dans lequel le système (S) comprend un premier serveur d'application (SA1), un deuxième serveur d'application (SA2), et un serveur mandataire (PROXY), caractérisé en ce que le serveur mandataire (PROXY) comprend une interface de gestion SIP (SS_API) pour associer à un même identifiant de destinataire (ID) deux branches (BR1, BR2) à destination respectivement du premier et du deuxième serveur d'application (SA1, SA2), et pour identifier lesdites branches par des identifiants (UID1, UID2) uniques pour chaque branche, dans lequel le serveur mandataire (PROXY) est agencé pour router une requête SIP (RQ) qui provient d'un dispositif source vers un agent utilisateur serveur destinataire (UAS) identifié par ledit identifiant de destinataire (ID) au sein de la requête SIP (RQ) via les deux branches (BR1, BR2), dans lequel l'agent utilisateur serveur destinataire (UAS) est installé dans un dispositif destinataire.
12. 12. Système (S) selon la revendication 11, dans lequel l'identifiant de destinataire (ID) est un identifiant de type Request-URI l'interface de gestion SIP (SS_API) est une interface de type SipServlet modifiée, et l'interface de gestion SIP (SS_API) comprend une fonction de création de branches qui accepte en entrée un identifiant unique (UID1, UID2) pour chaque branche (BR1, BR2).35