Brevet FR2906668A1 — publié le 20080404

Marqueur pour systèmes de communication composés d'une pluralité de serveurs SIP La présente invention est relative aux réseaux de communication. Plus 5 précisément, elle concerne un système de communication apte à échanger des messages de signalisation, notamment conformes au protocole SIP, avec un réseau de communication. Le protocole SIP est communément utilisé pour permettre à deux parties (typiquement, deux terminaux) d'établir une connexion à travers un 10 réseau de communication. Ce protocole est défini par le RFC 3261 de l'IETF (Internet Engineering Task Force) intitulé SIP: Session Initiation Protocol mais fait également l'objet d'extensions, elles aussi définies par des RFC de l'IETF. Le protocole SIP définit deux types de système de communication : des 15 terminaux (ou agents selon la terminologie propre au protocole SIP) et des éléments de signalisation dits Proxy . Le rôle des proxies est de faciliter la mise en relation entre les terminaux. En effet, un terminal est connu au sein d'un réseau de communication par une adresse physique, alors que les utilisateurs des terminaux sont identifiés par des adresses logiques. Lorsqu'un 20 utilisateur souhaite joindre un correspond, il ne dispose généralement que de son adresse logique. Le but des éléments de signalisation est en autres d'effectuer cette mise en correspondance entre l'adresse logique du correspondant et l'adresse physique de son terminal. Le terminal requérant l'établissement d'une communication est appelé 25 client ou UAC ( User Agent Client ). Le terminal appelé est appelé serveur (UAS pour User Agent Server ). Avec l'émergence des architectures dites IMS (pour IP Multimedia Subsystem en langue anglaise), normalisées à la fois par le 3GPP et par le 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 2 TiSpan, le protocole SIP prend davantage d'importance encore et les éléments de signalisation ont de plus en plus de messages de signalisation à traiter. Il devient donc nécessaire des proposer des solutions permettant aux différents types éléments de signalisation de traiter ce volume grossissant de messages. Il a donc été prévu de prévoir plusieurs équipements pour implémenter un élément de signalisation. De telles architectures sont utilisées dans d'autres contextes. On peut par exemple citer l'article Introduction to Server Clustering , publié sur le site internet de la société Cisco, qui présente les avantages de ces groupes (ou clusters ) d'équipements. La figure 1 illustre de façon simplifiée une architecture de ce type. Elle se base sur un équipement particulier LB qui répartit la charge parmi une pluralité d'équipements de traitement, ou serveurs, S1, S2, S3... Sn. Lorsqu'une requête de service SR parvient au groupe d'équipements, l'équipement de répartition de charge LB l'achemine vers un serveur particulier, ici S3, en fonction de règles de répartition de charge. Toutefois, l'application de cette architecture pour des éléments de signalisation (ou des terminaux) SIP pose des problèmes du fait des spécificités du fonctionnement d'une session de communication et du protocole SIP. Notamment, les solutions actuelles basées sur des groupes d'équipements prennent en compte de façon sous-optimale le fait que la gestion d'un appel nécessite l'établissement d'un contexte. En effet, lorsqu'un deuxième message de signalisation parvient à l'équipement de signalisation, il lui est nécessaire de récupérer ce contexte afin de pouvoir le traiter. Or dans ces solutions, il n'y a aucun mécanisme permettant de disposer de ce contexte : si le premier message a été traité par un équipement (par exemple S3), le contexte relatif à ce traitement et à l'appel ou session correspondant à ce message est contenu dans ce serveur S3. 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 3 Lorsqu'un second message de signalisation parvient à l'équipement de répartition de charge LB, deux ensembles de solutions sont possibles. Selon un premier ensemble de solutions, l'équipement de répartition 5 de charges se comporte comme dans les solutions générales décrites plus haut (par exemple l'article de Cisco). Un message de signalisation subséquent parvient donc à un serveur différent de celui ayant traité le message précédent. Il est alors mis en oeuvre un mécanisme pour transmettre le contexte mémorisé dans le premier serveur vers le second serveur. 10 Cette approche pose le problème de devoir transférer, de façon récurrente, le contexte d'un serveur à un autre. Ce mécanisme est également très coûteux et ne permet pas un déploiement efficace lorsque le site reçoit un grand nombre de messages de signalisation et à un rythme rapide. 15 Selon un second ensemble de solutions, l'équipement de répartition de charges mémorise des associations entre un identifiant de la session de communication et le serveur en charge de cette session. Cette association est créée lors de la réception du premier message de signalisation correspondant à cette session, et utilisée pour acheminer les messages suivants vers le même 20 serveur. Cet identifiant est typiquement formé des entêtes Cali-Id , From et To des messages de signalisation SIP. Les associations sont typiquement stockées dans une base de données mémoire de l'équipement de répartition de charge LB, afin de garantir un accès suffisamment rapide. 25 Ces solutions présentent toutefois encore au moins quatre désavantages. Premièrement, l'équipement de répartition de charge LB ne peut pas connaître la durée de la session de communication. Il est donc dès lors 30 difficile d'implémenter une stratégie d'expiration des associations mémorisées. 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 4 Si le délai d'expiration est trop court, l'association sera supprimée de la base de données alors que des messages de signalisation relative à cette session continuent d'arriver. Si le délai est trop long, il peut en résulter un engorgement de la base de données. 5 Deuxièmement, il est difficile de déployer cette solution pour qu'elle soit tolérante aux fautes de l'équipement de répartition de charge, sans trop pénaliser ses performances. En effet, si l'équipement de répartition de charge subit une panne, les 10 informations relatives aux associations contenues dans sa base de données sont perdues. Même lorsque l'équipement de répartition de charge redevient opérationnel, il ne lui est pas possible d'acheminer les messages de signalisation vers les bons serveurs. Il peut alors en résulter des interruptions des sessions de communication. 15 Pour pallier ce problème, il est possible de mémoriser les associations sur une base déportée, ou bien de mettre en place des mécanismes pour que les serveurs redirigent les messages de signalisation mal-aiguillés vers le bon serveur. Mais il s'agit-là de mécanisme coûteux à mettre en oeuvre, en terme de performances. 20 Troisièmement, certaines applications SIP combinent plusieurs sessions de communication identifiées chacune par un Cali Id différent. C'est par exemple le cas d'un élément de signalisation dit B2BUA ( back-to-back User Agent ). Un tel élément joue le rôle d'un serveur SIP vis 25 à vis de l'appelant et d'un client vis-à-vis de l'appelé. La communication de bout en bout est formée de deux sessions distinctes : une première entre l'appelant et l'élément de signalisation (considéré alors comme un serveur SIP) et une seconde entre l'élément de signalisation (considéré alors comme un client SIP) et l'appelé. 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472. doc 2906668 5 Il convient alors que les différentes sessions soient traitées par un même serveur. L'équipement de répartition de charge doit donc maintenir une double association entre les deux sessions et le serveur les traitant. Mais, notamment en cas de panne d'un serveur, il est très complexe de faire en 5 sorte que l'équipement de répartition de charges aient les informations nécessaires pour acheminer les messages de signalisation vers le serveur approprié. Ainsi, il peut arriver que les deux sessions soient re-crées sur deux serveurs différents, et il faut qu'un serveur redirige les messages de signalisation reçus vers le bon serveur. 10 Quatrièmement, il existe différentes applications basées sur le protocole SIP dans lesquelles une même session applicative peut nécessiter plusieurs sessions protocolaires : Une répartition de charge basée sur un identifiant de session comme l'entête Call-id ne peut donc pas garantir 15 que tous les messages d'une même session applicative soient traités par un même serveuer. Ce type d'applications est dit multi-appel ou mufti-cal/ , en langue anglaise. C'est par exemple le cas des éléments appelés S-CSCF ( Serving ù Call Session Control Function ) au sein d'une architecture IMS. 20 Un S-CSCF reçoit des messages de signalisation d'enregistrement de terminaux (messages Register ) puis des messages de signalisation d'invitation d'appel (messages Invite ) ou autres (messages Publish ...). Le premier message d'enregistrement permet au terminal d'être authentifié par le réseau de communication IMS, et d'être ainsi admis à émettre des 25 appels à travers ce réseau. Ces différents messages ne possèdent pas les mêmes identifiants de session Cali id , et forment en fait des sessions protocolaires différentes. Aussi, l'équipement de répartition de charge du S-CSCF ne peut pas acheminer les messages de signalisation appartenant à un même terminal (et 30 qui font parties d'une même session applicative ) vers le même serveur. Afin 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 6 de déterminer si un message de signalisation suivant ( Invite , Publish ...) correspond à un terminal ayant été précédemment authentifié par un serveur du S-CSCF, ce-dernier doit être prévu pour que les contextes puissent être transmis d'un serveur à un autre. Cet impératif ajoute bien évidemment un 5 surcoût au temps de traitement des messages de signalisation et diminue d'autant les performances générales du système IMS. Un second exemple a trait à la présence et à la gestion des messages de signalisation Publish qui permet à un client de mettre à jour ses informations de présence. Ce type de message de signalisation est décrit dans 10 le RFC 3903 de l'IETF, intitulé Session Initiation Protocol (SIP) Extension for Event State Publication et publié en octobre 2004. Un même client peut être amené à transmettre plusieurs messages Publish , en fonction de l'activité de l'utilisateur. Chacun de ses messages Publish comporte un identifiant de session Call-id différent, et forme 15 donc autant de sessions protocolaires (Du point de vue du protocole SIP, il s'agit de sessions différentes). Pourtant toutes ses sessions appartiennent à une même session applicative. Idéalement, elles devraient donc être traitées par le même serveur afin que celui-ci possède l'ensemble du contexte lié à cette session applicative. 20 Il est donc nécessaire de proposer une architecture d'un système de communication ne présentant pas ces inconvénients. L'invention a pour objet une telle architecture. 25 Plus précisément, l'invention a pour premier objet un système de communication apte à échanger des messages de signalisation, notamment conformes au protocole SIP, avec un réseau de communication. Le système de communication comporte une pluralité de serveurs pour traiter les messages de signalisation entrants et générer des messages de signalisations sortants et 30 un équipement de répartition de charge pour acheminer un message de 306472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 7 signalisation entrant vers un serveur particulier en fonction de règles de répartition de charge. Le système de communication selon l'invention se caractérise en ce que 5 les serveurs disposent des moyens pour inclure dans les messages de signalisation sortants un marqueur représentatif au moins de lui-même, et en ce que les règles de répartition de charge de l'équipement de répartition de charge contiennent des règles pour, lorsqu'un marqueur est 10 inclus dans un message de signalisation entrant, acheminer le message de signalisation entrant vers le serveur correspondant à ce marqueur. Le système de communication selon l'invention peut avoir plusieurs 15 fonctions : terminal (ou agent) client UAC, terminal serveur UAS, élément de signalisation ( proxy )... ou bien sûr une combinaison de ces fonctions. Il peut également s'agir d'un élément de signalisation de type B2BUA ( back-to-back User Agent ). 20 Ainsi, par l'utilisation d'un marqueur identifiant un serveur au sein du système de communication, les applications peuvent s'assurer que l'ensemble des messages de signalisation sera acheminé vers ce serveur. Il n'est plus nécessaire pour l'équipement de répartition de charge de maintenir une base de données des associations entre Cali Id et serveur, 25 puisque l'acheminement est basé sur un marqueur. II lui suffit d'une table d'association, de taille réduite, mettant en correspondance les valeurs du marqueur et les adresses des serveurs. II est à noter toutefois qu'il peut être utile de conserver une table de correspondance entre identifiants de session ( call Id ) et serveur pour gérer 30 les ré-émissions. En effet, le protocole SIP prévoit qu'un client doit re-émettre 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 8 sa requête tant qu'il n'a pas reçu de réponse de la part du serveur. Dans le cas des messages initiaux, pour lequel un contexte et donc un marqueur n'ont pas encore été déterminés, il est important que les messages répétés soient dirigés vers le même serveur. Une table de correspondance entre cati Id et 5 serveur semblable à celles de l'état de la technique peut donc être mise en oeuvre, mais le délai imparti pour les ré-émissions est limités par le protocole SIP, de sorte que les associations peuvent expirer au bout d'un temps connu et relativement court. La table d'association demeure donc à une taille raisonnable 10 n'engendrant pas les problèmes cités précédemment. Notamment, la problématique, mentionnée précédemment, de la détermination d'une bonne valeur d'expiration des associations ne se pose donc plus. De même, une panne de l'équipement de répartition de charge ne pose plus de véritable problème puisque celui-ci ne contient plus 15 d'informations dynamiques sur l'état du système (il est dit State-less , en langue anglaise). Lorsqu'une même communication engendre plusieurs identifiants de session, comme dans le cas de l'élément de signalisation back-toback mentionné plus haut, l'application peut naturellement faire en sorte que ces 20 sessions soient toutes traitées par le même serveur, en utilisant une même valeur de marqueur. Il en va de même pour le cas du S-CSCF : l'emploi d'un même marqueur pour les messages Register et Invite assure le traitement par un même serveur, sans qu'il soit nécessaire de procéder à des transferts de 25 contexte d'un serveur à l'autre. Le système de communication selon l'invention permet donc de résoudre de façon élégante l'ensemble des problèmes soulevés par les solutions de l'état de la technique. 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 9 Selon une mise en oeuvre de l'invention, les marqueurs contiennent au moins une première partie représentative du système de communication et l'identifiant de façon univoque au sein du réseau de communication. Les marqueurs peuvent en outre contenir une seconde partie 5 représentative des serveurs et les identifiant de façon univoque au sein du système de communication. Cette deuxième partie peut être constituée d'un identifiant abstrait basé sur l'adresse physique d'un des serveurs. Dans cette hypothèse, l'équipement de répartition de charge possède une table des serveurs mettant 10 en correspondant cet identifiant abstrait et l'adresse physique. Les marqueurs contiennent en outre une troisième partie représentative du contexte associé aux messages de signalisation. Par ailleurs, les serveurs peuvent inclure les marqueurs dans un emplacement standardisé et unique des messages de signalisation. 15 Alternativement, ils peuvent inclure ces marqueurs dans un emplacement dépendant de la fonction du système de communication. Les règles de répartition de charge de l'équipement de répartition de charge peuvent contenir des règles pour, lorsque aucun marqueur n'est inclus dans un message de signalisation entrant, affecter un serveur à ce message 20 de signalisation entrant. L'invention a pour deuxième objet un élément intermédiaire de signalisation (ou proxy ) comportant un système de communication selon le premier objet de l'invention. Les marqueurs peuvent, dans cette situation, être 25 inclus dans les entêtes Via et/ou Record route . L'invention a pour troisième objet un élément de signalisation de type B2BUA comportant un système de communication selon le premier objet de l'invention, dans lequel les marqueurs sont inclus à la fois dans l'entête 30 From et dans l'entête To avec une valeur identique. 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 10 Un quatrième objet de l'invention est un terminal de communication comportant un système de communication selon le premier objet de l'invention. Les marqueurs peuvent dans ce cas être inclus dans le champ 5 From lorsque le terminal a un rôle de client, et dans le champ To lorsqu'il a un rôle de serveur. L'invention a pour cinquième objet un réseau de communication comportant au moins un élément de signalisation conforme au deuxième 10 objet de l'invention et des moyens permettant de transmettre des messages de signalisation entre des terminaux de communication et le ou les éléments de signalisation. Les terminaux de communication peuvent optionnellement être conformes au quatrième objet de l'invention. 15 Un sixième objet de l'invention concerne un procédé de transmission de messages de signalisation entre un terminal de communication appelant et un terminal de communication serveur, mettant en oeuvre un élément de signalisation selon le deuxième objet de l'invention. 20 L'invention, dans ses différents objets, apparaîtra de façon plus claire dans la description qui va suivre, en liaison avec les figures annexées. La figure 1, précédemment commentée, représente de façon simplifiée une architecture de groupe d'équipements (ou cluster .) La figure 2 illustre de façon schématique une architecture 25 fonctionnelle possible d'un système de communication selon une mise en oeuvre de l'invention. Le système de communication selon l'invention peut être un élément de signalisation, notamment un CSCF ( Cali Session Control Function ) 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 11 d'une architecture IMS, mais également un terminal de communication client (UAC pour User Agent Client ou serveur (UAS pour User Agent Server ). Un tel système de communication est schématisé par la figure 2. 5 Le système de communication S est prévu pour échanger des messages de signalisation ms avec le réseau de communication N. Les messages de signalisation sont typiquement conformes au protocole SIP défini par l'IETF. Les messages de signalisation ms aboutissent à un équipement de 10 répartition de charge LB, dont le but est d'acheminer ces messages de signalisation vers le bon serveur S1, S2, S3... Sn. La figure 2 schématise une architecture fonctionnelle possible pour l'équipement de répartition de charge LB, mais il est important de noter qu'il s'agit là d'une architecture fonctionnelle susceptible de diverses 15 implémentations physiques. Elle est fournie principalement dans un but explicatif permettant de rendre l'invention plus claire. Selon cette mise en oeuvre, l'équipement de répartition de charge LB possède un module d'acheminement ou de routage MR qui, en coopération avec une base de règles BR, permet d'acheminer les messages de 20 signalisation entrants ms vers un serveur particulier parmi la pluralité de serveurs S1, S2, S3... Sn que possède le système de communication S. À la réception d'un message de signalisation ms, le module de routage MR vérifie la présence d'un marqueur dans le message. 25 Certaines règles R contenues dans la base BR précisent qu'en présence d'un marqueur, le message de signalisation ms doit être acheminé vers le serveur correspondant à ce marqueur. Le marqueur identifie un serveur particulier du système de communication S. Il peut s'agir de l'adresse physique de ce serveur ou bien 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 12 d'un identifiant que le module de routage MR peut mettre en correspondance avec l'adresse physique au moyen d'une table des serveurs TS. Une fois cette adresse physique déterminée, le module de routage MR peut acheminer vers le serveur correspondant. 5 Selon l'invention, tous les messages de signalisation correspondant à une même communication comportent un même marqueur et par conséquent entraînent la détermination d'une même adresse physique. Ils sont donc tous acheminés vers un même serveur et associés à un même contexte. Ce contexte représente l'ensemble des informations utilisées pour 10 traiter un message de signalisation. II dépend donc des messages de signalisation déjà reçus. Il peut aussi contenir des informations récupérées sur une base externe (serveur de présence, serveur applicatif, etc.) Autrement dit, la présence d'un marqueur indique qu'un contexte 15 existe déjà dans le système de communication pour la communication à laquelle correspond le message de signalisation ms entrant. En utilisant le marqueur pour l'acheminer, il est garanti que ce sera le serveur possédant ce contexte qui le traite. 20 Dans le cas où un message de signalisation ms ne comporte pas de marqueur, cela signifie qu'aucun contexte n'existe pour la communication correspondant à ce message entrant. Il s'agit d'un premier message de signalisation pour une communication donnée. L'équipement de répartition de charges LB possède un module 25 d'affectation Maif ayant pour but d'affecter le contexte à un serveur. II dispose pour cela de règles d'affectation Raif qui peuvent être similaires à celles existantes dans les solutions de l'état de la technique. Ces règles d'affectation peuvent simplement consister à affecter tour à tour chaque nouveau contexte au serveur d'incrément suivant : ainsi, par 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 13 exemple, le premier contexte est affecté au serveur S,, le second au serveur S2 et ainsi de suite. D'autres mécanismes plus complexes peuvent être mis en oeuvre, basés notamment sur la charge réelle des serveurs afin d'affecter un nouveau 5 contexte au serveur le moins chargé. Lorsque l'affectation est déterminée par le module d'affectation M0ff, le message de signalisation ms est acheminé au serveur correspondant. 10 Il est à noter que l'équipement de répartition de charge LB ne mémorise pas cette affectation, ni n'introduit d'information supplémentaire dans le message de signalisation ms transmis au serveur. Les serveurs disposent de moyens pour inclure dans les messages de 15 signalisation sortants un marqueur représentatif de lui-même, c'est-àdire permettant à l'équipement de répartition de charge de l'identifier parmi la pluralité de serveurs S,, S2, S3... Sn contenus dans le système de communication S. De cette façon l'autre partie recevant le message de signalisation 20 sortant aura connaissance du marqueur. En utilisant ce marqueur dans les autres messages de signalisation destinés au système de communication S, elle aura l'assurance qu'ils seront traités par le même serveur. Plus précisément, ce marqueur peut être composé de plusieurs 25 parties. Une première partie peut être représentative du système de communication S lui-même. Elle permet à l'équipement de répartition de charge LB recevant un message de signalisation de s'assurer qu'il en est le bon destinataire et que le marqueur est effectivement un marqueur le 30 concernant. 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 14 II doit donc s'agir d'une valeur identifiant de façon univoque le système de communication S au sein d'un réseau de communication. Dans le cas où ce système de communication S fait partie du réseau mondial, communément appelé Internet, la valeur donc être mondialement unique. 5 Cette première partie peut par exemple être l'adresse MAC de l'équipement de répartition de charge ou basé sur celle-ci. L'adresse MAC (pour Media Access Control ) définit en effet de façon unique un équipement de réseau. Plusieurs types d'adresses MAC existent, notamment MAC-48, EUI-48 et EUI-64 définis par l'IEEE (Institution of Electrical and 10 Electronics Engineers). Cette première partie peut aussi être l'adresse IP du système de communication S, ou bien être basée sur elle. Le marqueur peut contenir en outre une deuxième partie 15 représentative du serveur. Son rôle est d'identifier le serveur de façon univoque au sein du système de communication S, afin que l'équipement de répartition de charge LB puisse acheminer le message de signalisation entrant vers un serveur clairement déterminé. Cette deuxième partie peut être constituée de l'adresse physique du 20 serveur (adresse MAC....) ou bien d'un identifiant plus abstrait basé sur celle-ci. Dans ce dernier cas, il est supposé que l'équipement de répartition de charge LB possède une table des serveurs TS mettant en correspondance cet identifiant abstrait et l'adresse physique du serveur. Cette deuxième partie permet ainsi à l'équipement de répartition de charge LB d'acheminer les 25 messages entrants vers le bon serveur. Cette deuxième partie peut également identifier un processus logiciel (ou process en langue anglaise). La correspondance entre le processus logiciel identifié et le serveur peut être effectuée de façon transparente par l'infrastructure logicielle ( middleware ) mise en oeuvre le système de 30 communication S. Des infrastructures logicielles permettent en effet de 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 15 masquer la localisation des processus logiciels au sein d'un système distribué, en se chargeant d'aiguiller les messages adressés à un processus donné vers l'équipement sur lequel il se trouve, de façon transparente pour les applications. 5 Enfin, le marqueur peut comporter une troisième partie contenant un identifiant de l'instance de l'application SIP, et représentative du contexte de la session. Cette troisième partie représentative du contexte de la session est utile pour localiser celuici lorsque le processus logiciel ou le serveur déterminé par 10 la deuxième partie du marqueur est in-opérationnel. Cette troisième partie n'est pas nécessaire lorsque le serveur est rendu tolérant aux fautes par une redondance N-N. Dans une telle situation, l'équipement de répartition de charge LB peut en effet maintenir une table associant à chaque serveur actif un serveur redondant. Lorsqu'un serveur actif 15 devient in-opérationnel, il peut alors acheminer les messages qui lui sont adressés vers le serveur redondant qui possèdent également le contexte de l'application associée au message entrant. Dans le cas d'une redondance N+l, les contextes contenus par un serveur sont dupliqués dans l'ensemble (ou un sous-ensemble) des autres 20 serveurs. La connaissance du serveur vers lequel doit être acheminé un message ne suffit donc pas, à l'équipement de répartition de charge, pour déterminer comment acheminer ce message lors de la panne de ce serveur : il lui faut connaître le contexte. En déterminant le contexte à partir de cette troisième partie eten 25 utilisant une table de référence permettant d'associer un contexte à un serveur (ou à un processus logiciel), l'équipement de répartition de charge LB est à même d'acheminer le message de signalisation entrant vers le bon serveur au sein du système de communication S. 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 16 Le marqueur peut être inclus en différents emplacements des messages de signalisation. Selon un premier mode de réalisation, le marqueur est inclus dans un emplacement standardisé et unique des messages de signalisation (entrants et 5 sortants). Il pourrait s'agir d'un entête du protocole SIP spécifique, normalisé auprès de l'IETF. Toutefois, une telle implémentation nécessite de modifier le parc de terminaux de communication existant afin que ceux-ci soient conformes à cette nouvelle normalisation et soit à même d'interpréter les messages de signalisation reçus et d'en générer eux-mêmes. 10 L'invention propose donc également un second mode de réalisation, demeurant conforme à la normalisation actuelle du protocole SIP et ne nécessitant pas de modifier les terminaux déployés. Pour ce faire, le système de communication S est apte à inclure les 15 marqueurs dans des emplacements dépendant de sa fonction. Autrement dit, l'emplacement dans lequel les marqueurs sont inclus est différent pour un système de communication ayant une fonction de proxy , ou de terminal client ou serveur. On rappelle qu'un même système de communication peut avoir plusieurs fonctions, et donc s'adapter à la fonction qu'il prend pour une 20 session donnée. Ainsi, dans le cas d'un client UAC, le marqueur est inclus dans l'entête From des messages de signalisation sortants. Plus précisément, il peut être inclus comme paramètre au sein de cet entête. 25 Dans le cas d'un serveur UAS, le marqueur est inclus dans l'entête To des messages de signalisation sortants. Il peut également être plus précisément inclus comme paramètre au sein de cet entête Dans l'un et l'autre cas, ce paramètre peut être le paramètre tag . II peut toutefois ne pas être inclus dans le cas de messages de 30 signalisation sortants ne nécessitant pas de réponse de la part de l'autre 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 17 partie (i.e. le client UAC), c'est-à-dire des messages 100 Trying et des messages d'erreurs. Par conséquent, un terminal de communication comportant un système de communication selon l'invention peut inclure le marqueur dans le 5 champ From lorsqu'il a un rôle de client, et dans le champ To lorsqu'il a un rôle de serveur. Dans le cas d'un élément intermédiaire de signalisation SIP, ou proxy , les entêtes From et To ne peuvent généralement pas être 10 modifiés. Le marqueur est alors inclus dans le paramètre branch du dernier (chronologiquement) entête Via de chaque message de signalisation sortant. Un entête Via est utilisé par les éléments terminaux SIP pour re-15 acheminer les réponses par les mêmes noeuds que les requêtes du chemin aller. Dans certains cas, en outre, certains éléments intermédiaires de signalisation, proxy modifient les entêtes Record Route et l'acheminement d'un message de réponse dans le réseau de communication 20 se base sur ces entêtes Record Route . Dans ces cas-là, le marqueur est également inclus dans un paramètre de l'entête Record route de chaque message de signalisation sortant. L'entête Record-Route est utilisé par les éléments terminaux SIP pour router les messages subséquents par les noeuds qui en ont fait la 25 demande au chemin aller. Dans le cas d'un élément de signalisation de type B2BUA ( bock- to-bock User Agent ), on peut adopter le comporte à la fois d'un serveur UAS (par exemple vis à vis de l'appelant) et d'un client UAC (vis à vis du prochain 30 élément dans la chaîne ; par exemple l'appelé). Aussi, en tant que serveur, 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 18 l'élément de signalisation B2BUA peut insérer le marqueur dans l'entête To , et en tant que client il peut l'insérer dans l'entête From . Le marqueur étant le même dans les deux cas, le problème évoqué précédemment que deux sessions soient ouvertes au sein du même élément 5 de signalisation B2BUA est donc résolu. Le marqueur peut également être inclus dans l'entête Service Route par un élément intermédiaire de signalisation ayant le rôle d'un élément SCSCF dans une architecture IMS. Cet entête Service Route est défini dans le 10 RFC 3608 de l'IETF, intitulé Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registation et publié en octobre 2003. Cet entête Service Route est inclus dans les messages de réponse aux requêtes Register faites par les clients désirant se connecter au réseau 15 IMS. Ainsi, les messages suivants ( Invite , Publish ...) peuvent comporter ce marqueur de sorte que l'élément S-CSCF puisse identifier qu'ils appartiennent à une même session applicative et les acheminer vers le même serveur. Ce problème relatif aux éléments S-CSCF, présenté précédemment dans la partie introductive est ainsi résolu par l'insertion du marqueur. 20 De la même façon, les serveurs de présence peuvent inclure le marqueur dans l'entête Entity Tags des messages de réponse aux requêtes Publish des clients (terminaux). De la même façon que précédemment, cela permet aux clients d'utiliser le marqueur dans leurs messages suivants (autres 25 messages Publish lors d'une nouvelle mise à jour du profil de l'utilisateur, par exemple). Ainsi, le serveur de présence peut déterminer que ces messages de signalisation appartiennent tous à un même contexte applicatif et les acheminer vers un même serveur au sein du système de communication S. Le problème posé par les serveurs de présence et évoqué dans la partie 30 introductive est ainsi également résolu par l'utilisation du marqueur. 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 19 Dans tous ces cas, le marqueur peut être inséré dans l'entête par l'utilisation d'un séparateur (le ; selon la grammaire du protocole SIP) et introduit par un mot-clé spécifique (par exemple la chaîne marker= ). II 5 peut également être inséré sans usage d'un mot-clé. 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc REVENDICATIONS 1) Système de communication (S) apte à échanger des messages de signalisation, notamment conformes au protocole SIP, avec un réseau de communication (N), comportant une pluralité de serveurs (S,, S2, S3... Sn) pour traiter les messages de signalisation entrants (ms) et générer des messages de signalisations sortants et un équipement de répartition de charge (LB) pour acheminer un message de signalisation entrant vers un serveur particulier en fonction de règles de répartition de charge (R, Raff), caractérisé en ce que lesdits serveurs disposent des moyens pour inclure dans les messages de signalisation sortants un marqueur représentatif au moins de lui-même, et en ce que lesdites règles de répartition de charge dudit équipement de répartition de charge contiennent des règles (R) pour, lorsqu'un marqueur est inclus dans un message de signalisation entrant, acheminer ledit message de signalisation entrant vers le serveur correspondant audit marqueur. 2) Système de communication selon la revendication 1, dans lequel les marqueurs contiennent au moins une première partie représentative dudit système de communication et l'identifiant de façon univoque au sein dudit 20 réseau de communication. 3) Système de communication selon la revendication 2, dans lequel les marqueurs contiennent en outre une seconde partie représentative desdits serveurs et les identifiant de façon univoque au sein dudit système de 25 communication. 4) Système de communication selon la revendication précédente, dans lequel ladite deuxième partie est constituée d'un identifiant abstrait basé sur l'adresse physique d'un desdits serveurs, ledit équipement de répartition 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 21 de charge possédant une table des serveurs (TS) mettant en correspondant ledit identifiant abstrait et ladite adresse physique. 5) Système de communication selon l'une des revendications 3 ou 4, 5 dans lequel lesdits marqueurs contiennent en outre une troisième partie représentative du contexte associé aux messages de signalisation. 6) Système de communication selon l'une des revendications précédentes, dans lequel lesdits serveurs incluent les marqueurs dans un 10 emplacement standardisé et unique des messages de signalisation. 7) Système de communication selon l'une des revendications 1 à 5, dans lequel lesdits serveurs incluent lesdits marqueurs dans un emplacement dépendant de la fonction dudit système de communication. 15 8) Système de communication (S) selon l'une des revendications précédentes dans lequel lesdites règles de répartition de charge dudit équipement de répartition de charge contiennent des règles (Raft) pour, lorsque aucun marqueur n'est inclus dans un message de signalisation entrant, affecter un serveur audit message de signalisation entrant. 9) Élément intermédiaire de signalisation comportant un système de communication selon l'une des revendications précédentes. 10) Élément intermédiaire de signalisation selon la revendication précédente, dans lequel lesdits marqueurs sont inclus dans les entêtes Via et/ou Record route . 11) Élément de signalisation de type B2BUA comportant un système 30 de communication selon l'une des revendications là 8, dans lequel lesdits 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc 2906668 22 marqueurs sont inclus à la fois dans l'entête From et dans l'entête To avec une valeur identique. 12) Terminal de communication comportant un système de 5 communication selon l'une des revendications 1 à 8. 13) Terminal de communication selon la revendication précédente dans lequel lesdits marqueurs sont inclus dans le champ From lorsque ledit terminal a un rôle de client, et dans le champ To lorsqu'il a un rôle de 10 serveur. 14) Réseau de communication comportant au moins un élément de signalisation selon l'une des revendications 9 à 1 1 et des moyens permettant de transmettre des messages de signalisation entre des terminaux de 15 communication et ledit au moins un élément de signalisation. 15) Réseau de communication selon la revendication précédente dans lequel certains au moins desdits terminaux de communication sont conformes à l'une des revendications 12 ou 13. 16) Procédé de transmission de messages de signalisation entre un terminal de communication appelant et un terminal de communication serveur, mettant en oeuvre un élément de signalisation selon l'une des revendications 9 à 1 1. 25 20 106472/SYC/MSD F:\salle\F106472\PREMDEP\TEXTE\Dernier 106472.doc